1 1 EE 122:TCP, Connection Setup, Reliability Ion Stoica TAs: Junda Liu, DK Moon, David Zats http://inst.eecs.berkeley.edu/~ee122/ (Materials with thanks to Vern Paxson, Jennifer Rexford, and colleagues at UC Berkeley) 2 Today’s Lecture How does TCP achieve correct operation? Reliability in the face of IP’s “best effort” service 3-way handshake to establish connections 3-way or 4-way handshake to terminate connections Retransmission to recover from loss We’ll only look at timeout-based retransmission today 3 TCP Service Model Reliable, in-order, byte-stream delivery and with good performance Challenges - the network can drop packets delay packets deliver packets out-of-order replicate packets Weird, but it does sometimes happen corrupt packets 4 TCP Support for Reliable Delivery Checksum Used to detect corrupted data at the receiver …leading the receiver to drop the packet Sequence numbers Used to detect missing data ... and for putting the data back in order Retransmission Sender retransmits lost or corrupted data Timeout based on estimates of round-trip time Fast retransmit algorithm for rapid retransmission2 5 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data 6 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data These should be familiar 7 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data Starting sequence number (byte offset) of data carried in this segment 8 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data Acknowledgment gives seq # just beyond highest seq. received in order. E.g., if sender sends N in-order bytes starting at seq S then ack for it will be S+N.3 9 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data Number of 4-byte words in TCP header; 5 = no options 10 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data “Must Be Zero” 6 bits reserved 11 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data We will get to these shortly 12 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data Buffer space available for receiving data. Used for TCP’s sliding window. Interpreted as offset beyond Acknowledgment field’s value.4 13 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data Used with URG flag to indicate urgent data (not discussed further) 14 TCP “Stream of Bytes” Service Byte 0 Byte 1 Byte 2 Byte 3 Byte 0 Byte 1 Byte 2 Byte 3 Host A Host B Byte 80 Byte 80 15 … Provided Using TCP “Segments” Byte 0 Byte 1 Byte 2 Byte 3 Byte 0 Byte 1 Byte 2 Byte 3 Host A Host B Byte 80 TCP Data TCP Data Byte 80 Segment sent when: 1. Segment full (Max Segment Size), 2. Not full, but times out, or 3. “Pushed” by application. 16 TCP Segment IP packet No bigger than Maximum Transmission Unit (MTU) E.g., up to 1,500 bytes on an Ethernet TCP packet IP packet with a TCP header and data inside TCP header ≥ 20 bytes long (IP Header = 20 bytes) TCP segment No more than Maximum Segment Size (MSS) bytes E.g., up to 1460 consecutive bytes from the stream IP Hdr IP Data TCP Hdr TCP Data (segment)5 17 Sequence Numbers Host A Host B TCP Data TCP Data TCP HDR TCP HDR ISN (initial sequence number) Sequence number = 1st byte ACK sequence number = next expected byte 18 Initial Sequence Number (ISN) Sequence number for the very first byte E.g., Why not just use ISN = 0? Practical issue IP addresses and port #s uniquely identify a connection Eventually, though, these port #s do get used again … there is a chance an old packet is still in flight … and might be associated with new connection ∴ TCP requires (RFC793) changing ISN over time Set from 32-bit clock that ticks every 4 microseconds … only wraps around once every 4.55 hours To establish a connection, hosts exchange ISNs 19 Connection Establishment: TCP’s Three-Way Handshake 20 Timing Diagram: 3-Way Handshaking Client (initiator) Server SYN, SeqNum = x SYN + ACK, SeqNum = y, Ack = x + 1 ACK, Ack = y + 1 Active Open Passive Open connect()!listen()!accept()!6 21 TCP Header Source port Destination port Sequence number Acknowledgment Advertised window HdrLen Flags 0 Checksum Urgent pointer Options (variable) Data Flags: SYN ACK FIN RST PSH URG See /usr/include/netinet/tcp.h on Unix Systems 22 What if the SYN Packet Gets Lost? Suppose the SYN packet gets lost Packet is lost inside the network, or: Server discards the packet (e.g., listen queue is full) Eventually, no SYN-ACK arrives Sender sets a timer and waits for the SYN-ACK … and retransmits the SYN if needed How should the TCP sender set the timer? Sender has no idea how far away the receiver is Hard to guess a reasonable length of time to wait SHOULD (RFCs 1122 & 2988) use default of 3 seconds Other implementations instead use 6 seconds 23 Tearing Down (Close) the Connection 24 Close Connection (Two-Army Problem) Goal: both sides agree to close the connection Two-army problem: “Two blue armies need to simultaneously attack the white army to win; otherwise they will be defeated. The blue army can communicate only across the area controlled by the white army which can intercept the messengers.” What is the solution?7 25 Normal Termination, One Side (A) Finish (FIN) to close and receive remaining bytes FIN
View Full Document
Unlocking...