Day7: TCP: connection-oriented transmission, TCP: reliable data transmission, TCP: flow control, TCP: connection management

Come on! Steal Bozi

The poems I saw today are gray

The sky is gray, the
road is gray, the
building is gray, the
rain is gray,
among the dead gray,
two children walked past,
one bright red and the
other light green-
"Feeling" July 1980

---

To the point

1. TCP: connection-oriented transmission

1. TCP: Overview (RFCs: 793, 1122, 1323, 2018, 2581)

Explanation:
· The
so-called no message boundary : the
sender sends two small messages, maybe the receiver receives one large message, or vice versa.
Send and receive buffers ,
for timeout retransmission or error detection retransmission, matching Send and Receive speeds are inconsistent
·
MTU:
Maximum Transmission Unit, the largest data transmission unit, the largest network transmission packet; the maximum Ethernet MTU is 1500B
MSS:
Maxitum segment size application process is distributed to the transport layer TCP entity segments , and processing to be segmented in accordance with the size of the TCP header information of the MSS into TCP segments (segment)
·
Therefore, (the message converted into a byte stream , And then divided into individual MSS)
MSS+TCP header information+IP header information <= MTU (such as Ethernet MTU1500B) , ("So there is no problem with fragmentation?" What fragmentation...)
·
Otherwise, if the IP datagram to be sent is larger than the MTU of the data link layer, the datagram cannot be sent.
You can also refer to this netizen’s sharing: The relationship between MSS and MTU

---

2. TCP segment structure

Make some explanation:
16bits source port, 16bits destination port,
32 bits serial number, confirmation number.
So, smart, the same can be obtained: optional 32bits; checksum and so on 16bits
byte sequence number:
for the application layer to hand over to the Message, divide the MSS of each layer, and the body of each TCP segment (segment) The part is the payload part (corresponding to MSS), and the offset (offset) of the first Byte of the payload in the entire byte stream is the byte sequence number

3. TCP serial number, confirmation number

The segments that the receiver processes out of order can be cached or dropped, and there is no regulation. Depending on ...

Explanation:

• Host A → Host B Seq=42, ACK=79, data ='C':
  Host A, the initial sequence number negotiated is Seq = 42, and it is hoped that the initial sequence number of Host B starts from 79, and the byte C is required to be echoed
• Then Host B → Host A Seq=79, ACK=43, data ='C':
  Since Host B received Seq42 before, confirm ACK=43 after processing. At the same time, ACK=43 means that Host B has received 42 and before, and hopes that Host A will start at 43.
  …So that’s it

---

4. TCP round trip delay (RTT) and timeout

Set up and measure/estimate RTT properly.

• Q: How to set TCP timeout?
   Longer than RTT  But RTT changes
   Too short : time out too early  unnecessary retransmission
   Too long: too slow to react to segment loss, negative

• Q: How to estimate RTT?
   SampleRTT: Measure the time from the sending of the message segment to the receipt of confirmation
   If there is a retransmission, ignore this measurement
   SampleRTT will change, so the estimated RTT should be smoother
   Average several recent measurements instead of Only use the current SampleRTT

TimeoutInterval is an adaptive measurement and calculation of the

current EstimatedRTT calculation:
`

" EstimatedRTT = (1-α) EstimatedRTT + α SampleRTT ": The
left side of the equal sign is the current average RTT , and the estimated RTT on the right side of the equal sign is the most recent average RTT . Before every other sampling time, one more (1-α ), the contribution to the current average decreases exponentially.
`
Estimated: adj. estimated.

This DevRTT (Deviation RTT) is very similar to the standard deviation. It is the deviation/change value between SampleRTT and EstimatedRTT.
DevRTT = (1-β) DevRTT + β (|SampleRTT-EstimatedRTT|): Calculate the difference between the smoothed RTT and the real (weighted) Moving average)

---

Next, look at TCP doing RDT

2. TCP: Reliable data transmission

TCP established rdt on the basis of IP unreliable service

•  Pipeline segment (• GBN or SR)
•  Cumulative confirmation (like GBN)
•  Single retransmission timer (like GBN)
•  Can it be accepted out of order, there is no standard

Retransmission is triggered by the following events

•  Timeout (only the earliest unconfirmed segment is retransmitted: like SR again)
•  Repeated confirmation
  • Example: Received ACK50, and then received 3 ACK50s (redundant acknowledgment)

First consider the simplified TCP sender: (point 1 below)

•  Ignore repeated confirmations
•  Ignore flow control and congestion control

---

1. TCP sender (simplified version

My explanation for the following figure:
·
Initially, establish a TCP connection. Starting from the dotted line, there is an initialized Next sequence number and SendBase,
(as the initial sender, the first byte sequence number sent is from the initial sequence number)
·
Then wait for event ,
and then look clockwise .
So wait comes , the application process comes to data, it creates the segment, and sends the front seq of the window.
Then hand it to the lower layer for ip encapsulation of datagrams and the
leading edge sliding of the sending window: ( NextSeqNum = NextSeqNum + length(data) ) If it is
not timed, the time will start
.
If timeout, only the unconfirmed segment with the smallest sequence number
like SR will be transmitted , not Pass all unacknowledged ones once
`
When ACK received, and the value of ACK is y,
if y> SendBase, then SendBase = y , which is
equivalent to sliding the back edge of the sending window to position y, and
finally there is a timer for the timer Operation, look at the picture

---

1.1TCP sender event: (ppt to the explanation of the figure above)

Receive data from the application layer:

•  Create segment with nextseq
•  The sequence number nextseq is the byte stream number of the first byte of the message segment
•  If it is not running, start the timer
  •  The timer is associated with the oldest unacknowledged segment
  •  Expiration interval: TimeOutInterval

Timeout:
 The oldest segment after retransmission
 Restart the timer

Receipt of confirmation:

•  If it is to confirm the unconfirmed segment
•  Update the sequence number of the confirmed message  If there are still unconfirmed message segments, restart the timer
  

Let’s enjoy the pseudo-code for the realization of 1.TCP sending and sending pictures

	NextSeqNum = InitialSeqNum
	SendBase = InitialSeqNum
	loop (forever) {
    
    
		switch(event) 
		event: data received from application above 
			create TCP segment with sequence number NextSeqNum 
			if (timer currently not running) 
				start timer 
			pass segment to IP 
			NextSeqNum = NextSeqNum + length(data) 
		event: timer timeout
			retransmit not-yet-acknowledged segment with smallest sequence number start timer 
		event: ACK received, with ACK field value of y 
			if (y > SendBase) {
    
     
				SendBase = y
			if (there are currently not-yet-acknowledged segments) 
				start timer 
				} 
	} /* end of loop forever */
	
	/*注释：• SendBase-1: 最后一个累积确认的字节例：
			• SendBase-1 = 71;
			y= 73, 因此接收方期望73+ ;
			y > SendBase，因此新的数据被确认
 	*/

Finally, come to another picture
to confirm the highest byte received in sequence;

---

2. Recommendations for generating TCP ACK [RFC 1122, RFC 2581]

3. Fast retransmission

Fast retransmission: Retransmit the message segment before the timer expires

---

 Detect message segment loss through repeated ACK

•  The sender usually sends a large number of segments continuously
•  If the message segment is lost, it will usually cause (receive) multiple repeated ACKs

 If the sender receives 3 redundant ACKs for the same data , (three redundant ACK50 as shown in the figure below),

• Retransmit the segment with the smallest sequence number:
• It assumes that the data following the confirmed data is lost

• The first ACK is normal;
• The second ACK of this segment is received, which means that the receiver has received an out-of-sequence segment after this segment;
• The 3rd and 4th ACKs of this segment are received, which means the receiver After receiving this segment, 2 or 3 out-of-sequence segments are very likely to be
lost

3.1 Fast retransmission algorithm:

dup: duplicate: adj. exactly the same, redundant

Three, TCP: flow control

The receiver controls the sender and
prevents the sender from sending too much or too fast,
preventing the receiver’s buffer from overflowing

TCP socket receiver buffers: TCP socket receiver buffers

Then TCP is full duplex, so:

•  The receiver "advertises" its free buffer size in the rwnd field of its TCP segment header to the sender .
  (Not a separate confirmation message, but a small mark "free buffer space" on the express box)
  •  RcvBuffer size is set by socket option (typical default size is 4096 bytes)
  •  Many operating systems automatically adjust RcvBuffer
• The sender limits the number of unacknowledged ("in-flight") bytes ≤ the rwnd value sent by the
  receiver to ensure that the receiver will not be overwhelmed

Review the receive window and receive buffer (Receive Window && Receive Buffer field)

---

Four, TCP: connection management

Before officially exchanging data, the sender and receiver shake hands to establish a communication relationship:

•  Agree to establish a connection (each party knows that the other party is willing to establish a connection)
•  Agree to the connection parameters
  

1. Agree to establish a connection

Two-way handshake failure scenario:
semi-connection, the
client host process on the left, due to acc_conn(x) timeout, retransmits a new connection request (req_conn(x)),
resulting in the server host process maintaining a semi-connection

2. TCP 3-way handshake (2-way handshake solution)

There is a flag bit SYN in TCP.
SYN = 1 represents the connection request
Seq = x represents the transmission from the x byte

Generally, the first data transfer and the third handshake are together.

2.1 Three-way handshake solution: half connection and receiving old data problems

The initialization sequence number is used as the sequence number of the TCP segment, instead of a fixed sequence number :
it can
effectively avoid
the data
of the old
connection from
causing interference to the data of the new connection.

2.2 Three-way handshake: FSM (Finite State Machine)

Send a few to see~

3.TCP: Close the connection

•  Client and server respectively close the connection on its own side (connections in both directions are separately removed)
   Send TCP segment with FIN bit = 1 (FIN = 1 means closing the connection)
•  Once the FIN is received, respond with ACK
   Upon receiving the FIN segment, ACK can be sent together with the FIN segment sent by itself
•  can handle simultaneous FIN exchange

---

There are some fun things, what
if the FIN confirmation is not received?
What if FIN can't get past at all?
What if someone forged FIN to send to the other party?
Hahaha

The release of the TCP connection is not perfect , and a timer mechanism is used to disconnect the connection.

---

End of this article