The second of TCP/IP: Streaming data interaction

and UDP This "ball" type of protocol is different (a data is a UDP packet), TCP transmits data in the message segment, its size is limited by the network link. The maximum message length (MSS) is communicated to each other in the SYN message segment. So the data delivered by the business layer is split/merged into the appropriate segment by TCP (which is why the TCP data flows with no boundaries).

For each segment of the message, it is like the "ball" of UDP, no guarantee of order, no guaranteed arrival. TCP will reorder the received messages before handing them over to the application layer. When a message segment is emitted, a timer is started, waiting for the ACK acknowledgement to be received, or the message will be re-transmitted. Due to retransmission mechanism, the message segment may be duplicated, and the receiving end must discard duplicate messages. This TCP realizes its own reliability.

How do you implement this reliable system efficiently?

"Ack Confirmation"

The first is the ACK design, the most straightforward way: we usually write asynchronous IO very similar, send a copy of the data, waiting for the other party to confirm, and then send the next copy.

Because TCP is a dual-work, both ends can have data interaction, the end of the ACK can be combined into its normal message segment, reduce the amount of interaction. This is the "acknowledgement of delay"-typically TCP does not send an ACK immediately when it receives the data, instead it defers sending so that the ACK is sent along with the data that needs to be sent in that direction.

Furthermore, the ACK is a confirmation of the received byte sequence, not necessarily every message must be ACK, can be one ACK multiple data. For example, two consecutive message segments were received "PSH 1:1025; PSH 1025:2049 ", just reply to an" Ack 2049 ". This is: "Separate message segment Confirmation" policy--the receiver does not have to confirm each received packet, the ACK is cumulative, and they indicate that receiver pays has correctly received a sequence of all bytes to confirm the number minus one.

"Nagle Algorithm and sliding window"

Secondly, we have broadband, if the user to send the number of hair, it will be very wasteful. It's like 200 people flying with two people. The solution is also simple:

One, the limit of the number of packets (Nagle algorithm, the connection can only have an unconfirmed small group, the packet ack can not be sent before the other small group, the algorithm is adaptive, the faster the ACK received the faster);

Second, the buffer, the cache user data, and then distributed to the IP layer of the transmission, the corresponding to the end also want to receive buffer, the two buffers work together to ensure the correctness of sending and receiving.

This is the "sliding window" of the TCP Maximum feature.

The current window size is advertised in the TCP header of each message segment, and the sending side learns how many bytes of buffer can be reserved for the application layer. Specific workflow such as (Please ignore fonts, thank you):

The notification window is 0, showing that the receiving party has received all the data, but its application layer has not been read from Tcprecvbuff in time and the sender stops sending.

When the application layer reads the data, the window is re-idle and the sender is notified (window Update) under Zero window. A separate active ACK that does not confirm the data and only reports the new window size.

　　

"Stick to the timer"

"Separate active ack", with the general ACK is not the same, remember the general has lost the ACK how to re-preach it? What if the goods are lost?

TCP Four timers (retransmission, persistence, keepalive, 2MSL) adhere to the timing to fix.

Zero window, the sender stop sending data, and set its insistence timer, if the timeout is not received before the Windows Update, then send a special probe message, to learn the size of the end window. The probe contains 1 bytes, but is not confirmed by ACK and repeats all the time.

"Confused Windows syndrome"

Well, we have the Nagle algorithm, with a sliding window, is it completely done with broadband efficient use it?

Consider a scenario in which the receiver pays application only takes 1 bytes per copy, triggers a window update, ACK win 1, updates the right edge of the sender window, sends 1 bytes of data, stops, and so on the next wave of window updates ... loop (PS: The actual impossibility is just 1 bytes, TCP headers are 20 bytes)

The corresponding solution:

1) The receiver does not advertise the small window unless the window is added to the MSS (maximum message length), or to half of the buffer space of the receiving party.

2) The sender only sends data if one of the following conditions is met:

(a) A full-length message segment can be sent

(b) The message segment can be sent at least half the receiver window size

(c) No unconfirmed data and the ability to send all buffered data

(d) Connection closes the Nagle algorithm

　　

"Congestion avoidance, slow start"

Do you have any questions? Before because of the broadband utilization problem, we have to slide the window to avoid frequent small packets, similarly, because of the routing problem, we have to avoid too rough.

Assuming that the connection is established (the window is idle) to send a large amount of data, plug the network, and the link rate is slow-the intermediate routers must be cached packet, once the routing storage space is exhausted, the subsequent groupings will be discarded directly, TCP throughput is severely reduced.

"Slow start, congestion avoidance" play--congestion window (congestion windows, as CWnd), slow start threshold (Ssthresh).

　　

When a TCP connection is established, the Ssthresh is initialized to 65535 bytes, and the congestion window is initialized to 1 segment (MSS), and a packet size is added for each ack,cwnd received. The sender takes min (Congestion window, sliding window) as the sending limit.

The sending party first sends a message segment, such as ACK, received after the CWnd increased to 2, can send two pieces of message. When the ACK of these two segments is received, CWnd increases to 4 ... Exponential rise (slow start).

climbed to a certain value after the arrival of network capacity, intermediate routes dropped packets, the sender retransmission timer timeout, know that CWnd caused congestion, CWnd was reset to 1 pieces of message, Ssthresh is set to the current half of the CWnd.

There is also a congestion indication: A duplicate ACK is received, such as a damaged intermediate message. Only Ssthresh = CWND/2 is set at this time, and CWnd is not rewritten.

If CWnd <= Ssthresh, then slow start, CWnd update by index; otherwise congestion avoidance, CWnd grows linearly (each ACK increases the 1/cwnd, a maximum of one segment is added in a RTT, regardless of the number of ACK times received).

The second of TCP/IP: Streaming data interaction