Flow control:
1, flow control is to manage the traffic on both ends, so as to avoid the sending over the block caused the end of overflow, or because the receiver processing too fast and waste time state. Using: Sliding window, in bytes
2, the window has 3 kinds of actions: expand (right-to-left), collapse (to the right), contraction (right to left) these three actions are controlled by the receiving side.
Close: Indicates that a confirmation of the corresponding byte has been received
Expand: Indicates that the cache is allowed to send more bytes
Shrinkage (very unwanted, some implementations are forbidden): Indicates that it could have been sent, and cannot be sent now; but if the contractions are those that have already been issued, there will be problems; To avoid this, the receiver waits until there is more cache space in the cache to communicate.
The size of the originator window depends on the window size of the receiver Rwnd (the window of the TCP packet) and the Congestion window size CWnd (see congestion control)
originator window size = min{Rwnd, CWnd};
3. Close the window: there is an exception to the window retraction, that is, sending rwnd=0 indicates that it is temporarily unwilling to receive data. In this case, the originator does not shrink the window, and the second is to stop sending the data. (in order to avoid deadlocks, you will use some detection reports to send the temptation, see the timer section)
4, the problem: At some point, due to the beginning or the end of the data is very slow, will cause a large number of 1 bytes of data deplored, wasting a lot of resources.
(1), the process of the initiation of data is very slow, from time to moment to a 1-byte data, then TCP will be 1 bytes 1 bytes of transmission, inefficient.
Workaround (Nagle algorithm):
A. Send out the first piece of data
b, then wait until the send cache has enough data (the maximum message length), or wait until the ACK of the receiver confirms to send the data.
C, the process of repeating B
(2), the end of the process due to the consumption of data is very slow, so there may be a situation, the receiver will send its window size of 1 information, and then there is 1 bytes of transmission
Solution (2 types)
A, Clark method: Declare a receive window size of 0 before half of the receiving cache becomes empty or there is enough space to put the maximum message length
B, deferred confirmation: Wait until the received message segment is confirmed enough to receive the cache, or wait until a time period (now generally defined 500ms)
Congestion Control:
1. If the load on the network (the number of packets sent to the network) is greater than the capacity on the network (the number of packets that the network can handle at the same time), it can cause congestion and determine the two factors of network congestion: latency and throughput. Congestion control mechanisms are: open-loop (prevention) and closed-loop (elimination) (See Network Principles related books, slightly)
Three strategies for TCP handling congestion: Slow start (exponential increase), congestion avoidance (addition increase), congestion detection (except 2 reduction, or multiplication reduction)
2. Slow start: exponential increase
/* Ssthresh is a slow start threshold, slow start threshold represents an upper limit, the general implementation is 65535B */
CWnd = 1; (1 indicates an MSS message segment, not a byte)
while (CWnd < Ssthresh)
If (Confirmation of the message segment sent)
CWD *= 2;
3. Congestion Avoidance: addition increases
When the Ssthresh is reached, it is the addition phase, each receiving a confirmation, CWD + = 1;
4, congestion Detection: multiplication reduction (except 2 reduction)
When the message needs to be re-transmitted, it indicates that congestion may have occurred, because there are 2 cases of retransmission, so there are two kinds of processing
(1), due to time-out retransmission, which is the likelihood of congestion is relatively large, such as the next strong reflection adjustment
A, Ssthresh/= 2;
B, CWnd = 1;
Slow Restart Process
(2), due to the retransmission of 3 duplicate ACK received, take a weak reflection:
A, Ssthresh/= 2;
B, CWnd = Ssthresh;
C. Start the congestion avoidance process
Error control:
1, TCP must ensure that the data: sequential, no errors, no partial loss, no duplication to the application layer. The method is: checksum, confirmation, time-out retransmission
2, Checksum: and UDP, the same as the practice, but also to pseudo-header, and UDP is different is that this feature is required in TCP
3, confirm: ACK confirmation mechanism (below are some principles)
A, ACK message does not need to confirm, also does not consume the serial number
b, when the end of the data sent, as far as possible to include a piggyback confirmation.
C, the receiver delay sending the ACK segment, if there is only one unconfirmed sequence message segment, delay to 500ms, or have a second packet received (to D), or when there is data to be sent (to B)
D, at any time, there can be no two (above) unconfirmed message segments (that is, if the receiver has two unconfirmed sequential message segments, immediately send an ACK message segment to confirm)
E, when the receipt of a sequence number than the expected number is larger than the message segment, immediately send an ACK, let the originator for fast retransmission
F, receive duplicate message segment, send confirmation immediately (Resolve ACK loss problem)
G, the missing message section arrives, sends the confirmation, indicates has received the lost message
4. Type of Confirmation
Cumulative confirmation: The receiver ignores all out-of-order messages, informs the originator that he expects the next received sequence number, called the positive cumulative ack. It must be said: Discarded, lost, duplicates are not reported.
Selection Confirmation (SACK): In some new TCP implementations, this thing is implemented, reporting out-of-sequence and repeating data, as part of a pseudo TCP header option field.
5, retransmission (two cases): Retransmission timer time, or the originator received a duplicate of three ACK (fast retransmission)
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.