300 likes | 411 Views
Introduction to TCP. A first look at the sockets API for ‘connection-oriented’ client/server application programs. Benefits of TCP. Communication is ‘transparently reliable’ Data is delivered in the proper sequence An application programmer does not need to worry about issues such as:
E N D
Introduction to TCP A first look at the sockets API for ‘connection-oriented’ client/server application programs
Benefits of TCP • Communication is ‘transparently reliable’ • Data is delivered in the proper sequence • An application programmer does not need to worry about issues such as: • Lost or delayed packets • Timeouts and retransmissions • Duplicated packets • Packets arriving out-of-sequence • Flow and congestion control
Overview application layer process A process B transport layer … port P … … port Q … reliable TCP byte-stream connection T C P T C P network layer I P I P unreliable IP datagrams
Transport-Layer’s duties • Create the illusion of a reliable two-way point-to-point connection linking a client application with a server application • Manage the ‘error-control’ mechanism • Manage the ‘flow-control’ mechanism • Manage the connection’s ‘persistence’ • Manage the connection’s ‘shutdown’
Interaction overview The ‘server’ application socket() bind() The ‘client’ application socket() listen() bind() 3-way handshake connect() accept() read() data flow to server write() write() data flow to client read() close() 4-way handshake close()
What is a ‘connection’? • An application’s socket is ‘connected’ if it has a defined pair of socket-addresses: • An IP-address and port-number for the ‘host’ • An IP-address and port-numbet for the ‘peer’ ‘hopper.usfca.edu’ ‘hrn23501.usfca.edu’ 138.202.171.14 138.202.192.14 port 53124 port 80 2-way data stream 138.202.192.14 138.202.171.14 port 80 port 53124 classroom workstation USF’s web-server
Layout of TCP header 32-bits source port address destination port address sequence number acknowledgment number Header Length reserved U R G A C K P S H R S T S Y N F I N window size checksum urgent pointer options and padding
Sequence number segmented stream of 1000 bytes data (256 bytes) data (256 bytes) data (256 bytes) data (232 bytes) ISN ISN + 256 ISN + 512 ISN + 768 The sequence number field defines the number being assigned to the first byte of data contained in this segment. During connection setup, each party to the connection uses a random number generator to get the value it will assign to the first byte of data it will transmit, called its initial sequence number (ISN). Thereafter, the sequence number in each succeeding segment will equal the sequence number used in the prior segment plus the number of data bytes in that prior segment. By this scheme the receiver can arrange all the incoming data bytes in the proper order, even if some segments happen to arrive out-of-order.
Acknowledgment number • This field holds the number of the byte that the source of this segment is expecting to receive next from its connection partner • This field’s value is meaningful only when this segment’s ACK control flag bit is set 9, 8, 7 6, 5 4, 3, 2, 1 sender receiver ACK 5
TCP Header Length • Like IP headers, the TCP Header’s length is expressed in multiples of 32-bits: it’s at least 5 (i.e., 20-bytes) if there aren’t any ‘TCP Options’ included in the TCP header • The amount of DATA in a TCP packet can be calculated from the IP Header’s ‘Total Length’ field, minus the number of bytes that comprise these two headers (IP header + TCP header) IP header TCP header DATA Total Length (in bytes)
Control flags 5 4 3 2 1 0 URG ACK PSH R S T SY N FIN Legend: FIN = Terminate the connection SYN = Synchronize sequence numbers RST = Reset the connection PSH = Push the data ACK = The value in the acknowledgement field is valid URG = The value in the urgent pointer field is valid
Establishing the connection timeline server application (passive) client application (active) SYN J SYN K, ACK J+1 ACK K+1 The 3-way Handshake
Exchanging data timeline server application (passive) client application (active) PSH+ACK ACK PSH+ACK ACK A typical Request and Reply transaction
Connection shutdown timeline server application (passive) client application (active) ACK+FIN ACK ACK+FIN ACK The 4-way Handshake
3-way handshake SYN ACK + SYN ACK
‘request-and-reply’ ACK+PSH ACK ACK+PSH ACK+FIN
4-way handshake ACK+FIN ACK ACK+FIN ACK
TCP Timers • To achieve transparent reliability, the TCP subsystem maintains some internal timers • One of these is the ‘Retransmission Timer’ • If a packet is sent, but its ACK does not arrive before this timer expires, then the packet will be ‘retransmitted’ • Of course, this could result in the receiver getting duplicate packets (if it’s a bit slow)
‘lost’ versus ‘late’ timeline client application server application PSH+ACK retransmit timeout ACK PSH+ACK ACK arrives late same PSH arrives twice Busy server might be ‘slow’ to acknowledge
‘piggyback’ • To reduce traffic-flow when possible, TCP delays sending an immediate ACK for an arriving data-packet, in case the receiver might soon have some data of its own to send back – in which case the ACK can ‘piggyback’ on the outgoing data PSH • This mechanism, of course, requires TCP to maintain a ‘Delayed ACK’ timer
Delayed ACK senario application layer process A write read transport layer buffer for incoming data Delayed ACK timer Retransmit timer buffer for outgoing data … port P … Window Probe timer Keep Alive timer T C P to/from the IP layer
Window Size • During the ‘connection setup’ handshake, each host communicates to its partner a ‘window size’ parameter, to let be known some information about its capacity for buffering packets • It also conveys its ‘MSS’ parameter (as a ‘TCP header option’) to inform its partner of its buffers’ Maximum Segment Size
MSS versus MTU • A diagram shows the distinction between the protocol’s MSS (Maximum Segment Size) and the interface’s MTU (Maximum Transmission Unit); no TCP packets will be sent with a segment-size that’s larger MTU MSS datalink header IP header TCP header packet DATA FCS
Main TCP option types • The TCP Header contains an options list, occupying from 0 to 11 longword values • Each option is identified by an 8-bit ‘type’: • Type 0: End of the options list: data follows this • Type 1: No option: used for alignment padding • Type 2: Maximum Segment Size (MSS) • Type 3: Window scaling option (WSOPT) • Type 4: Selective Acknowledgments supported • Type 5: Selective Acknowledgment (SACK) • Type 8: Timestamp value and echo reply (TSOPT)
Option formats • Option types 0 and 1 are single-bytes • All other option types are at least 2-bytes, with the second byte containing the length type 2 length 4 MSS value type 3 length 3 WSOPT value type 4 length 2 4 bytes 3 bytes 2 bytes type 8 length 10 timestamp value timestamp echo reply value 10 bytes
Looking at TCP options HLEN HLEN HLEN
‘Wrapped’ sequences • The TCP header’s ‘Sequence Number’ is a 32-bit value, initially chosen at random • It could happen that a large number gets selected as an Initial Sequence Number and that a large amount of data gets sent, thus causing the 32-bit field to ‘overflow’ • So how does the receiver tell a ‘wrapped sequence’ from a ‘late-arriving’ segment?
Type 8: TSOPT • The TCP timestamps have two purposes: • RTTM: Round-Trip Time Measurement • PAWS: Protect Against Wrapped Sequences 16 bits TYPE (=8) LENGTH (=10) Timestamp Value Timestamp Echo Reply
The SACK option • It conveys extended ‘acknowledgment’ information from a receiver to a sender about ‘gaps’ in the received data-stream Type (=5) Length Left Edge of first Block no gaps here Right Edge of first Block 2+n*8 bytes . . . Left Edge of n-th Block no gaps here Right Edge of n-th Block 32-bits
Demo programs • We put ‘tcpserver.cpp’ and ‘tcpclient.cpp’ on our class website, so you can watch actual TCP packets being exchanged by using our ‘nicwatch’ application (or some other packet-sniffer, e.g., ‘wireshark’) • We deliberately used loops which write to, or read from, sockets one-byte-at-a-time so that you can observe ‘TCP buffering’!