1
play

1 TCP seq. #s and ACKs TCP Header: Header Length Seq. #s: Host B - PDF document

Feb 27, 2024 •250 likes •460 views

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 point-to-point: full duplex data: bi-directional data flow one sender, one receiver in same connection reliable, in-order byte 7: TCP MSS: maximum segment steam: size

  1. TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 ❒ point-to-point: ❒ full duplex data: ❍ bi-directional data flow ❍ one sender, one receiver in same connection ❒ reliable, in-order byte 7: TCP ❍ MSS: maximum segment steam: size ❍ no “message boundaries” ❒ connection-oriented: like with UDP datagrams ❍ handshaking (exchange ❒ pipelined: of control msgs) init’s sender, receiver state ❍ TCP congestion and flow Last Modified: before data exchange control set window size ❒ flow and congestion 2/25/2003 8:15:19 PM ❒ send & receive buffers controlled: ❍ sender will not application application writes data reads data socket overwhelm receiver or socket door door TCP TCP network send buffer receive buffer segment 3: Transport Layer 3: Transport Layer 3b-1 3b-2 TCP segment structure Roadmap 32 bits URG: urgent data counting ❒ TCP header and segment format source port # dest port # (generally not used) by bytes sequence number ❒ Connection establishment and termination of data ACK: ACK # acknowledgement number (not segments!) valid ❒ Normal Data flow head not U A P R S rcvr window size PSH: push data now F len used # bytes (generally not used) checksum ptr urgent data rcvr willing to accept RST, SYN, FIN: Options (variable length) connection estab (setup, teardown commands) application data Internet (variable length) checksum (as in UDP) 3: Transport Layer 3: Transport Layer 3b-3 3b-4 TCP Headers: like UDP? TCP Headers: Familiar? ❒ Source and destination port numbers ❒ Sequence Number field ( 32 bit) ❍ Sequence Number field indicates number of first byte in ❒ Checksum the packet ❒ Data length? Rely on length in IP header? ❒ Receiver Window Size (16 bit) ❍ Window like for GBN or selective repeat, but window size not fixed – variable based on receiver feedback ❒ Acknowledgment Field (32 bit) ❍ The acknowledgement field contains the next sequence number it is expecting thus implicitly acknowledging all previous segments. ❍ Cumulative acks not individual acks or negative acks 3: Transport Layer 3: Transport Layer 3b-5 3b-6 1

  2. TCP seq. #’s and ACKs TCP Header: Header Length Seq. #’s: Host B Host A ❍ byte stream ❒ Header Length (4 bits) “number” of first User Seq=42, ACK=79, data = ‘C’ byte in segment’s ❍ needed because options field make header types data ‘C’ variable length host ACKs ACKs: receipt of ❍ Expressed in number of 32 bit words = 4 bytes ❍ seq # of next byte Seq=79, ACK=43, data = ‘C’ ‘C’, echoes expected from other ❍ 4 bits field => 4 bytes*2 4 = 60 bytes; 20 bytes back ‘C’ side of required header gives 40 bytes possible of ❍ cumulative ACK Q: how receiver handles host ACKs options out-of-order segments receipt S e q = ❍ Recall UDP header was 8 bytes of echoed 4 3 ❍ A: TCP spec doesn’t , A C K = 8 0 ‘C’ say, - up to implementor ❍ Can buffer or not, in time either case still ACK simple telnet scenario next in order byte expected 3: Transport Layer 3: Transport Layer 3b-7 3b-8 Implications of Field Length Implications of Field Length (cont) ❒ Advertised Window is 16 bit field => ❒ 32 bits for sequence number (and maximum window is 64 KB acknowledgement) ; 16 bits for advertised ❍ Is this enough to fill the pipeline? Not always window size ❍ Pipeline = delay*BW product ❒ Implication for maximum window size? ❍ 100 ms roundtrip and 100 Mbps => 1.19 MB Window size <= ½ SequenceNumberSpace ❒ Sequence Number is 32 bit field => 4 GB ❍ Requirement easily satisfied because receiver ❍ Wrap –around? advertised window field is 16 bits ❍ Maximum Segment Lifetime of 120 seconds • 2 32 >> 2* 2 16 ❍ Will this ever wrap too soon? Yes it might • Even if increase possible advertised window to 2 31 • 4 GB/120 sec = 273 Mbps that would still be ok • Gigabit Ethernet? STS-12 at 622 Mbps? 3: Transport Layer 3: Transport Layer 3b-10 3b-9 TCP Header: Common Options TCP Header: Flags (6 bits) ❒ Connection establishment/termination ❒ Options used to extend and test TCP ❒ Each option is: ❍ SYN – establish; sequence number field contains valid initial sequence number ❍ 1 byte of option kind ❍ FIN - terminate ❍ 1 byte of option length (except for kind = 0 for end of options and kind =1 for no operation) ❒ RESET - abort connection because one side ❒ Examples received something unexpected ❍ window scale factor: if don’t want to be limited to 2 16 ❒ PUSH - sender invoked push to send bytes in receiver advertised window ❒ URG – indicated urgent pointer field is ❍ timestamp option: if 32 bit sequence number space will valid; special data - record boundary wrap in MSL; add 32 bit timestamp to distinguish between two segments with the same sequence number ❒ ACK - indicates Acknowledgement field is ❍ Maximum Segment Size can be set in SYN packets valid 3: Transport Layer 3b-11 3: Transport Layer 3b-12 2

  3. TCP Header: ACK flag TCP Header: URG ❒ ACK flag – if on then acknowledgement ❒ If URG flag on, then URG pointer contains field valid a positive offset to be added to the sequence number field to indicate the last ❒ Once connection established no reason to byte of urgent data turn off ❒ No way to tell where urgent data starts – ❍ Acknowledgment field is always in header so left to application acknowledgements are free to send along with data ❒ TCP layer informs receiving process that there is urgent data 3: Transport Layer 3b-13 3: Transport Layer 3b-14 Out-of-band data URG ❒ URG is not really out-of-band data; ❒ How helpful is this? Receiver must continue to read byte ❒ Telnet and Rlogin use URG when user types stream till reach end of urgent data the interrupt key; FTP uses when user ❒ If multiple urgent segments received, first aborts a file transfer urgent mark is lost; just one urgent pointer ❒ Is this worth a whole header field and a flag? ❒ How to get out-of-band data if need it? ❒ Doesn’t help that implementations vary in how they interpret the urgent pointer ❍ Separate TCP connection? (point to last byte in urgent data or byte just past the last byte of urgent data) 3: Transport Layer 3b-15 3: Transport Layer 3b-16 TCP Header: PSH TCP Header: Data boundaries? ❒ Intention: use to indicate not to leave the ❒ In general with UDP, application write of X data in a TCP buffer waiting for more data bytes data results in a UDP datagram with before it is sent X bytes of data – not so with TCP ❍ In practice, programming interface rarely ❒ In TCP, the stream of bytes coming from allows application to specify an application is broken at arbitrary points ❍ Instead TCP will set if this segment used all the by TCP into the “best” size chunks to send data in its send buffer ❒ Receiver is supposed to interpret as ❒ Sender may write 10 bytes then 15 then 30 deliver to application immediately; most but this is not in general visible to the TCP/IP implementations don’t delay receiver delivery in the first place though 3: Transport Layer 3b-17 3: Transport Layer 3b-18 3

  4. Record Boundaries TCP Connection Management Three way handshake: Recall: TCP sender, receiver ❒ Could try to use URG and PSH to indicate establish “connection” Step 1: client end system before exchanging data record boundaries segments sends TCP SYN control ❍ socket interface does not notify app that push segment to server ❒ initialize TCP variables: bit or urgent bit is on though! ❍ specifies initial seq # ❍ seq. #s ❍ buffers, flow control ❒ If need record boundaries, applications Step 2: server end system info (e.g. RcvWindow ) receives SYN, replies with must always insert their own by indicating ❒ client: connection initiator SYNACK control segment it in the data (ie. Data is record len + Socket clientSocket = new ❍ ACKs received SYN Socket("hostname","port record format) ❍ allocates buffers number"); ❒ server: contacted by client ❍ specifies server-> receiver initial seq. # Socket connectionSocket = welcomeSocket.accept(); Step 3: client acknowledges servers initial seq. # 3: Transport Layer 3b-19 3: Transport Layer 3b-20 Three-Way Handshake Connection Establishment Active participant Passive participant (client) (server) ❒ Both data channels opened at once SYN, SequenceNum = x ❒ Three-way handshake used to agree on a set of parameters for this communication y , SYN + ACK, SequenceNum = channel 1 + x = t n m e g d e ❍ Initial sequence number for both sides w l o k n c A ❍ Receiver advertised window size for both sides A C K , A c k n o w l e d g m ❍ Optionally, Maximum Segment Size (MSS) for e n t = y + 1 each side; if not specified MSS of 536 bytes is assumed to fit into 576 byte datagram Note: SYNs take up a sequence number even though no data bytes 3: Transport Layer 3b-21 3: Transport Layer 3b-22 Initial Sequence Numbers Special Case: Timeout of SYN ❒ Chosen at random in the sequence number ❒ Client will send three SYN messages space? ❍ Increasing amount of time between them (ex. ❒ Well not really randomly; intention of RFC 5.8 seconds after first, 24 seconds after is for initial sequence numbers to change second) over time ❒ If no responding SYNACK received, client ❍ 32 bit counter incrementing every 4 will stop trying to open the connection microseconds ❒ Vary initial sequence number to avoid packets that are delayed in network from being delivered later and interpreted as a part of a newly established connection 3: Transport Layer 3b-23 3: Transport Layer 3b-24 4

Recommend

More recommend