Your best way to understand TCP is to open up Wireshark, download a large file using HTTP, or any TCP protocol, and look for BLACK lines saying DUP ACK, Fast Retransmit, or Retransmit to scroll across your screen.
Generally you will see some packet loss over an internet connection, and you can dig into this further on your own to see your own client sending DUP ACK's for lost packets.
Or better yet, do an upload, and you can see your client doing a Fast Retransmit after it sees 3 identical ACK's.
You can also look closer at the TCP options and see the SACK's that manbearpig alluded to.
Another good source of info about fast-retransmits is the RFC. The second paragraph answers your comment about why 3 ACK's vs 1,2,4,5.
3. Fast Retransmit
Modifications to the congestion avoidance algorithm were proposed
in 1990 . Before describing the change, realize that TCP may
generate an immediate acknowledgment (a duplicate ACK) when an out-
of-order segment is received (Section 126.96.36.199 of , with a note
that one reason for doing so was for the experimental fast-
retransmit algorithm). This duplicate ACK should not be delayed.
The purpose of this duplicate ACK is to let the other end know that a
segment was received out of order, and to tell it what sequence
number is expected.
Since TCP does not know whether a duplicate ACK is caused by a lost
segment or just a reordering of segments, it waits for a small number
of duplicate ACKs to be received. It is assumed that if there is
just a reordering of the segments, there will be only one or two
duplicate ACKs before the reordered segment is processed, which will
then generate a new ACK. If three or more duplicate ACKs are
received in a row, it is a strong indication that a segment has been
lost. TCP then performs a retransmission of what appears to be the
missing segment, without waiting for a retransmission timer to