1 / 94

TCP Tutorial - Part I -

TCP Tutorial - Part I -. Laboratory of Intelligent Network @ KUT ( http://link.kut.ac.kr ) Youn-Hee Han. It is licensed under a Creative Commons Attribution 2.5 License. TCP Introduction. TCP Features. (Virtual) Connection-oriented Service with Reliability

aren
Télécharger la présentation

TCP Tutorial - Part I -

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TCP Tutorial- Part I - Laboratory of Intelligent Network @ KUT (http://link.kut.ac.kr) Youn-Hee Han It is licensed under a Creative Commons Attribution 2.5 License

  2. TCP Introduction KUT

  3. TCP Features • (Virtual) Connection-oriented Service with Reliability • Information unit is a “segment” • TCP itself divides the application date into “segment” • Note: Programmer him/herself creates properly-sized UDP datagrams • Byte stream service • Two applications exchange 8-bit (byte)stream data • TCPdoes not interpreter the bytes’contents • No application-specific message boundary Five Segments KUT

  4. TCP Features • Sender TCP sets a timer whenever sending a segment • Sender waits an ACK (Acknowledgment) message after sending a segment • Receiver TCP should send an ACK message to the sender • Sender re-sends the segment if it does not receive an ACK message before the timer expires KUT

  5. TCP Features • TCPsegment is delivered as IP datagram • IP datagrammay be out of order  TCP segmentmay be out of order • Receiver TCP re-organizes the segments according to the correct sequence • Receiver TCP eliminates the duplicated segment KUT

  6. TCP Features • TCP provides flow control • TCP sender has the “SEND BUFFER” • TCP receiver has the “RECEIVE BUFFER” • e.g., if a PC sends data to a hand-held PDA that has a small “RECEIVE BUFFER” and is slowly processing received data, the PDA must regulate data flow so as to not be overwhelmed • TCP uses a sliding window flow control protocol • TCPprovides congestion control • TCP uses a number of mechanisms to avoid ‘network congestion collapse'. • TCP controls the rate of data entering the network, keeping the data flow below a rate that would trigger network congestion collapse • ACKs for data sent, or lack of ACKs, are used by senders to infer network conditions between the TCP sender and receiver. KUT

  7. TCP Features • TCP utilizes the checksum to detect an error • To assure correctness of TCP header and data, a checksum field is included in the TCP header • If the checksum is incorrect, the TCP receiver ignores the TCP segment. • TCP sender’s timer is expired • TCP sender re-transmits the same TCP segment • TCP provides 32 bit checksum within TCP header and data. • IPv4 provides 16 bit checksum within the IPv4 header. • IPv6 does provides the checksum filed within the IPv6 header. Why? KUT

  8. TCP Features • Full-duplex communication • Bi-directional data flow • Data can be transmitted while receiving • Use of "Piggyback" • Data packets can convey feedback information in the opposite direction (ACK) KUT

  9. TCP Features • TCP may delay data transfer. • If TCP has not received enough data from the application, TCP tries to aggregate data as much as possible • The aggregated data size is “MSS(Maximum Segment Size)” • When constructing a segment, TCP starts a TIMER and sends a segment of which size is “not” MSS if there is no futher application data and the TIMER is expired. • Telnet • HTTP Request (segment) KUT

  10. TCP Ports, Connections, and Endpoints • Endpoint of communication is application program • TCP uses protocol port number to identify application • TCP defines an “endpoint” to be a pair of two following integers: • TCP connection between two endpoints identified by four items • Sender’s IP address • Sender’s protocol port number • Receiver’s IP address • Receiver’s protocol port number • (host IP, port) KUT

  11. process process TCP with buffers, variables TCP with buffers, variables socket socket Socket Socket: a door between application process and transport protocol (UCP or TCP) controlled by application developer controlled by application developer controlled by operating system controlled by operating system internet host or server host or server KUT

  12. IPv4 Header 20 Octets + options : 13 fields, including 3 flag bits 0 bits 4 8 16 24 31 Ver IHL Type of Service Total Length Identifier Flags Fragment Offset Time to Live Protocol Header Checksum 32 bit Source Address 32 bit Destination Address Options and Padding KUT

  13. IPv4 Header - notes • Internet Header Length (IHL) • Unit: 4 bytes, Min: 5 (54=20 bytes), Max: 15 (154=60 bytes) • Type of Service (ToS) • RFC 2474 provides a definition of this field in terms of DS (Different Service) • Total Length • Unit: 1 bytes, Min: 20 bytes, Max: 65,535(=2^16) bytes • Identifier • If an IPv4 packet is fragmented, all of the fragments retain the same Identification values, so the destination can group them for reassembly • Flags • 0, 3: Reserved • 1: Don’t fragment • 2: More fragment • Time to Live (TTL) • When TTL becomes 0, ICMPv4 Error message is sent to the source KUT

  14. TCP Segment Header • 20 bytes + options 0 15 16 31 16-bit source port number 16-bit destination port number 32-bit sequence number Counting by bytes of data (not segments!) 32-bit acknowledgment number 4-bit header length reserved (6bits) U R G A C K P S H R S T S Y N F I N 16-bit window sizes 16-bit TCP checksum 16-bit urgent pointer options (if any) •  Maximum Segment Size (MSS) data (if any) KUT

  15. TCP Segment Header • Acknowledgment Num, Sequence Num, Window Size • Congestion Control + Flow Control • Flags • SYN, FIN, RESET, PUSH, URG, ACK • Checksum • pseudo header + TCP header + data KUT

  16. Six flags and Option • Six flag bits • URG - The urgent pointer is valid. (generally not used) • ACK - The acknowledgment number is valid • PSH - The receiver pass this data to the application as soon as possible. (generally not used) • RST - Reset the connection. • SYN - Synchronize sequence numbers to initiate a connection. • FIN - The sender is finished sending data. • Urgent pointer • Effective only if URG flag is set • Way to send an urgent out-of-band data • Option field • maximum segment size (MSS) option • MSS option is inserted when the connection is established (SYN is set) KUT

  17. TCP connection establishment • 3 way handshake (Conceptual Description) Client: “I want to talk, and I’m starting with byte number X ”. Server: “OK, I’m here and I’ll talk. My first byte will be called number Y, and I know your first byte will be number X+1”. Client: “Got it - you start at byte number Y+1”. 1 Server Client SYN ISN=X 1 2 time SYN ISN=Y, ACKN=X+1 2 3 ACKN=Y+1 3 ISN: Initial Sequence Number KUT

  18. TCP connection establishment • 3 way handshake • Initial sequence numbers, x & y, are chosen randomly • Guarantees both sides ready & know it, and sets initial sequence numbers, also sets window & mss • Once connection established, data can flow in both directions, equally well, there is no master or slave Site 2 Site 1 Send SYN seq. #=x Active win 4096, mss 1460 Rcv SYN segment Send SYN seq.#=y, ACK #=x+1 Passive win 4096, mss 1024 Rcv SYN + ACK segt Send ACK seq.#=y+1 Rcv ACK segment KUT

  19. TCP connection establishment • Active & Passive Opens • Two sides of a connection • Client • Server • One side initiates contact • A client program (Site 1) • Uses TCP’s active open • One side waits for contact • A server program (Site 2) • Uses TCP’s passive open KUT

  20. TCP close connection • Usually the application tells TCP to terminate the connection politely with a FIN segment. • TCP layer can send a RST segment that terminates a connection if something is wrong. • FIN segment • Either end of the connection can initiate termination. • Application 1 call “close()” function • A FIN is sent, which means the application is done sending data. • The FIN is ACKed by Application 2 • Application 2 call “close()” function • A FIN is also sent. • That FIN must be ACKed Application 1 KUT

  21. App2 App1 FIN SN=X 1 ACK=X+1 2 ... FIN SN=Y 3 ACK=Y+1 4 TCP close connection • Modified 3 way handshake (or 4 way termination) App1: “I have no more data for you”. App2: “OK, I understand you are done sending.” ……. pause… App2: “OK - Now I’m also done sending data”. App1: “I understand , Goodbye” 1 2 3 4 KUT

  22. TCP close connection • Modified 3 way handshake (or 4 way termination) • In Site 1, App tells TCP to close, TCP sends remaining data & waits for ACK • Receiving the ACK, then sends FIN & EOF (End of Data) • In Site 2, TCP ACKs FIN, tells its application “EOF” • In Site 2, sends FIN when its app closes connection (maybe after a long delay) • exit(0)automatically calls close() (App closes) Send FIN seq=s FIN (EOF) Rcv FIN segment Site 2 Site 1 Send ACK s+1 (inform app) Rcv ACK segment (app closes connection) Send FIN seq=t, ACK s+1 FIN (EOF) Rcv FIN + ACK seg Send ACK t+1 Receive ACK segment TIME_WAIT KUT

  23. TCP close connection • Both sides close at the same time – Case 1 (App closes) Send FIN seq=s FIN (EOF) Rcv FIN segment Site 2 Site 1 (app closes connection) Send ACK s+1 & FIN seq=t ACK + FIN (EOF) Rcv ACK+FIN segment Send ACK t+1 TIME_WAIT Receive ACK segment KUT

  24. TCP close connection • Both sides close at the same time – Case 2 (App closes) Send FIN seq=s (app closes connection) Send FIN seq=t FIN (EOF) Site 2 Site 1 FIN (EOF) Rcv FIN segment Rcv FIN seg Send ACK t+1 Send ACK s+1 (inform app) Receive ACK segment Rcv ACK segment TIME_WAIT TIME_WAIT KUT

  25. TCP close connection • Why TIME_WAIT? • This gives enough time to Client TCP so as to ensure the ACK it sent to the server was correctly received. • If the ACK the client sent is lost, the server will re-transmit FIN. • The FIN should be received by Client • TIME_WAIT = 2 * maximum segment life (MSL) Start TIME_WAIT Re-Start TIME_WAIT KUT

  26. State Transition Diagram • It shows only the states involved in opening a connection (everything above ESTABLISHED) and in closing a connection (everything below ESTABLISHED) • Everything while a connection is open—e.g., congestion control—is hidden in the ESTABLISHED state. • Each side starts in the CLOSED state • State transition according to the arcs of which is labeled with a tag of “event/action” • e.g., a server is in LISTEN and a SYN segment arrives. At this event, LISTEN is transited to SYN_RCVD and reply with an SYN+ ACK segment KUT

  27. State Transition Diagram • Two kinds of events trigger a state transition • (1) a segment arrives from peer • (2) local application process invokes an operation on TCP (e.g., active open event on arc from CLOSED to SYN_SENT) • Most of the states that involve sending a segment to the other side also schedule a timeout that eventually causes the segment to be resent if the expected response does not happen. • These retransmissions are not depicted in the state transition diagram. • If after several tries the expected response does not arrive, TCP gives up and returns to the CLOSED state. KUT

  28. State Transition Diagram • [Connection Establishment] 1. server invokes a passive open operation : CLOSED  LISTEN 2. client invokes an active open operation : client sends a SYN to server : CLOSED  SYN_SENT 3. SYN arrives at server : LISTEN  SYN_RCVD : responds with a SYN+ACK 4. SYN+ACK arrives at client : SYN_SENT  ESTABLISHED : sends ACK 5. ACK arrives at server : SYN_RCVD  ESTABLISHED KUT

  29. State Transition Diagram [NOTE about connection establishment] 1. if client’s ACK to server is lost, the connection still functions correctly - client side is already in ESTABLISHED - local process starts sending data - Each data segments will have ACK which has the correct value - server moves to ESTABLISHED when the first data segment arrives 2. there is a transition out of the LISTEN state whenever local process invokes a send operation on TCP - passive participant identifies both ends of connection (i.e., itself and remote participant are willing to have connect to it) - then changes its mind and instead actively establish connection KUT

  30. State Transition Diagram [terminating a connection] - application process on both sides of the connection must independently close its half of the connection - possibility that the two sides invoke the close operation at the same time - as well as the possibility that first one side invokes close and then, at some later time, the other side invokes close KUT

  31. State Transition Diagram • [Three Cases of “ESTABLISHED state to the CLOSED” ] • This side closes first: ESTABLISHED >> FIN_WAIT_1 >> FIN_WAIT_2 >> TIMEWAIT >> CLOSED • The other side closes first: ESTABLISHED >> CLOSE_WAIT >> LAST_ACK >> CLOSED • Both sides close at the same time: • ESTABLISHED >> FIN_WAIT_1 (>> CLOSING) >> TIME_WAIT >> CLOSED KUT

  32. MSS (Maximum Segment Size) KUT

  33. MSS (Maximum Segment Size) • Overview • Maximum Transmission Unit (MTU) is defined by the maximum payload size of the Layer 2 frame. • MTU determines the maximum size of a Layer 3 packet/fragment. • Layer 3 payload determines Layer 4 Maximum Segment Size(MSS) KUT

  34. MSS (Maximum Segment Size) • Overview • MSS: Maximum Segment Size • Largest payload size that TCP can send for this connection. • Usually, MSS is calculated by “Maximum Transmission Unit (MTU) - 40 bytes.” MAC Header (Path MTU) KUT

  35. MSS (Maximum Segment Size) • Overview • An example of MSS negotiation • In this example, both sides use 960 bytes as MSS. KUT

  36. Link MTU • Link MTU • The max packet size that can be transmitted over a link • If a router receives a packet whose size is bigger than its outbound Link MUT, it must fragment the packet. • Most modern router and link implementations now support MTUs of 1500 KUT

  37. Path MTU • Path MTU • The minimum link MTU of all links in a path between a source and a destination • Source host’s IP can fragment payloads of upper-layer protocols of which packet size is larger than the Path MTU • all IP hosts (and routers) are required to accept or reassemble fragments of which size is 576 octets  Default (and Safe) value of Path MTU is 576! • Path MTU Discovery • Used to send packets bigger than 576 bytes • Increase Path MTP • To detect increases in a path’s PMTU, a node periodically increases it. • Increasing Path MTU must not be done less than 5 minutes after ICMP has been received (Recommend : 10 minutes) • Minimal implementation can omit Path MTU Discovery as long as all packets kept  576 bytes KUT

  38. 2. ICMP Packet Too Big message (MTU =1400)(Note : Packet Discard) 1400 1500 1600 1. Source Node initially assume that…PMTU = MTU of first hop=1500 4. ICMP Packet Too Big message (MTU=576)(Note : Packet Discard) 576 1400 576 1400 1500 1500 1600 3. Source Node assume that…PMTU = MTU notified by ICMP=1400 1600 5. Source Node assume that…PMTU = MTU notified by ICMP=576 Path MTU • Path MTU Discovery 576 KUT

  39. Path MTU • How to get Path MTU by yourself? • PING <IP-Address/Domain Name> -f -l <estimated MTU - 28> • 28 represents IP Header (20 Bytes) and an ICMP-Header (8 Bytes) • -f: Don’t Fragment • -l: ICMP’s Payload Size • Ex] ping -f -l 1472 www.yahoo.com … Reply from 209.131.36.158: bytes=1472 time=141ms TTL=50 … ping -f -l 1473 www.yahoo.com … Packet needs to be fragmented but DF set … KUT

  40. Path MTU & MSS • How to determine TCP MSS • SndMSS = MIN(Path MTU - sizeof(TCPHDR) - sizeof(IPHDR), Advertised MSS) • Case I: both the IP header and the TCP header are minimum size, that is, 20 octets • SndMSS = MIN((576 - 20 - 20, Advertised MSS) = MIN(536, Advertised MSS) • Case II: if the IP Security option (11 octets) were in use • SndMSS = MIN((576 - 20 - 20 - 11, Advertised MSS) = MIN(525, Advertised MSS) • In Modern Internet, path MTU is usually 1500 and MSS can be 1460 • Self-check: http://www.speedguide.net:8080 KUT

  41. Sliding Window KUT

  42. TCP Window • TCP Window • the amount of data a TCP sender can send on a connection before it gets an ACK back from the receiver • Measured in bytes • If TCP sender’ window size is 64 KB (kilobytes), the sender can only send 64 KB of data and then it must stop and wait for an acknowledgment from the receiver /* An example of client code that sets the TCP window size */ int window_size = 128 * 1024; /* 128 kilobytes */ sock = socket(AF_INET, SOCK_STREAM, 0); /* These setsockopt()s must happen before the connect() */ setsockopt(sock, SOL_SOCKET, SO_SNDBUF, (char *) &window_size, sizeof(window_size)); setsockopt(sock, SOL_SOCKET, SO_RCVBUF, (char *) &window_size, sizeof(window_size)); connect(sock, (struct sockaddr *) &address, sizeof(address)); KUT

  43. Sliding Window • Sliding Window Used By TCP • Illustration in SEND_BUFFER • 1st and 2nd bytes are acknowledged • Bytes 3 through 6 not yet acknowledged • Bytes 7 though 9 waiting to be sent • Bytes above 9 and lie outside the window cannot be sent • TCP sliding window mechanism operates at the octet (byte) level • TCP allows the window size to vary over time • Variable size window means thatTCP provides “flow control” • Window size is related to bandwidth & RTT KUT

  44. Four sources of packet delay • Processing Delay (=Dproc ) • Time to examine the packet’s header and determine where to direct the packet • Queuing Delay (= Dqueue) • Time to exist in queue • In Input queue, it depends on the number of earlier-arriving packets that are queued • In Output queue, it depends on the number of waiting for transmission across the link • Transmission Delay (= Dtrans ) • Time to push all of the packet’s bits into the link (= Packet Length / Transmission Rate) • E.g., Packet Length: 1,500 Bits, Transmission Rate : 100 Mbps, Transmission Delay = ? • Propagation Delay (=Dprop) • Time to propagate from the beginning of the link to the end of the link (= Distance / Propagation Speed) • E.g., Distance: 1Km, Propagation Speed: 3*10^8 m/sec, Propagation Delay = ? Transmission Propagation Queuing (Input queue) Queuing (Output queue) Processing Bandwidth KUT

  45. Transmission Rate & Bandwidth • Bandwidth • typically means physical layer “net transmission bit rate” • The channel capacity • a theoretical upper bound for the maximum net bit rate Channel capacity ≥ Net bit rate (Bandwidth) KUT

  46. Propagation Speed • It is well known that… • Copper: 2.3 x 108 m/s • Fiber: 2.0 x 108 m/s • Radio: 3.0 x 108 m/s • “Speed” of the Internet is… • between 2.0 x 108 and 3.0 x 108 m/s • Let’s assume Internet propagation speed S… • S = 2.0 x 108 m/s KUT

  47. How Long Will It Take To Download? • Let’s download the following image file from a location • Assume the distance D is 5288 km • If it were just one bit! • D / S = 5288 * 1000 / 2.0 x 108 = 26.4 x 10-3 sec • Size: 62,728 bytes • D / S = 62,728 x 8 x 26.4 x 10-3 = 13,248 s = 3.7 hours! • Is this correct? 62,728 bytes KUT

  48. TCP Window Size Issue One bit at a time!  Very Poor Throughput KUT

  49. TCP Window Size Issue • Keeping the pipe full! • Maximize the throughput KUT

  50. TCP Window Size Issue Keeping the pipe full when using TCP Window ACK ACK ACK ACK ACK Window Size = 5 segments A B C D E F G H I J K L M N O Is it Correct Behavior to keep the pipe full? A B C D E F G H I J K L M N O When Sliding? KUT

More Related