Shulou(Shulou.com)06/02 Report--

The TCP (Transportation Control Protocol) protocol and the IP protocol are produced together. In fact, the two were originally a protocol and were later split into IP at the network layer and TCP at the transport layer. We have already introduced in UDP protocol that UDP protocol is the "puppet" of IP protocol in the transport layer, which is used to realize the communication in the form of data packets. The TCP protocol realizes the communication in the form of "stream".

TCP is very rich in content. I can't finish TCP in an article. This article mainly introduces the following aspects of TCP protocol:

The significance and realization of "flow" Communication

How to realize reliable transmission

Use sliding windows to improve efficiency

"streaming" communication

TCP protocol is a transport layer protocol, which implements port-to-port (port) communication. Further, the TCP protocol virtualizes the communication of a text stream (byte stream). As we talked about in the Linux text stream, the essence of computer data is an ordered 0max 1 sequence (called a text stream if it is in byte). The function of a computer is to store and process text streams. CPU + memory + storage device realizes the processing of text stream in the same computer. Human-computer interaction is achieved through some IO, such as the screen and keyboard, and the text stream. Furthermore, if the network communication can carry on the interaction of the text stream between different computers, then we have realized the docking with the data processing mode of the whole computer system.

IP protocol (see TCP/IP protocol for details 03, 05) and UDP protocol are transmitted in the form of data packets, and later packets may arrive early, so we can not guarantee the order of data arrival. The TCP protocol ensures that the order in which the data arrives matches the order of the text stream. When the computer reads data from the interface of the TCP protocol, the data is already a sequential "stream". For example, we have a large file to send from the local host to the remote host. If it is received according to the "stream", we can receive it and store the text stream into the file system at the same time. In this way, when the "stream" has been received, the hard disk write operation has been completed. If we adopt the UDP transmission mode, we need to wait until all the data arrives and sort it before we can assemble the large files. In this case, we have to use a lot of computer resources to store the data that has arrived, and we can't start processing until all the data has been reached.

The main point of "flow" is order, but it is not easy to achieve this. The TCP protocol is based on the IP protocol, so the final data transmission is carried out in IP packets. If a text stream is very long, it is not possible to stream the entire text into an IP packet, which may exceed the MTU. Therefore, what the TCP protocol encapsulates into the IP packet is not the whole text stream, but the segment specified by the TCP protocol. Like a previous IP or UDP packet, a TCP fragment is also divided into two parts: header and payload (the name "fragment" is more of a reminder: Hey, this is not a complete text stream). The entire text stream is sequentially divided into small segments, and each segment is placed into the data portion of the TCP fragment. A TCP fragment encapsulates an IP packet that does not exceed the minimum MTU on the entire IP relay path, thus avoiding painful fragmentation.

Segmenting the text stream is done at the sending host, while fragmentation is done at the router in the network. The router has to handle a lot of traffic, so it is quite busy. The text stream is segmented in advance on the sending host, which can avoid fragmentation on the router and greatly reduce the network burden)

Fragments and numbering

The sequence number (sequence number) of the TCP fragment is stored in the header (header) of the fragment. In this way, the receiving computer can know the order of the received fragments in the original text stream, and can also know which fragments they need to receive next to form the stream. For example, if you have received fragment 1, segment 2, and segment 3, then the receiving host starts to expect fragment 4. If an out-of-order packet is received (such as fragment 8), the receiver's TCP module can refuse to receive it, thus ensuring that the information presented to the receiving host is an ordered "stream".

Reliability.

The preliminary idea of segment numbering does not solve all our problems. The IP protocol is unreliable, so IP packets may be incorrect or lost during transmission. The IP transmission is "Best Effort", if an exception occurs, our IP packets will be easily discarded. On the other hand, if out-of-order fragments arrive, according to what we said above, the receiving host will not receive them. In this way, under the joint destruction of error fragments, missing fragments, and rejected fragments, the receiving host can only receive a text stream full of "loopholes".

Please fill in the loophole

The remedy for TCP is to send a special TCP fragment to the sender (that is, the other segment of the connection) after each correct, ordered fragment is received, to inform the sender that I have received that fragment. This particular TCP clip is called ACK reply. If the sequence number of a segment is L, the corresponding ACK reply has the reply number 1, which is the sequence number of the next sent segment that the receiver expects to receive. If the sender does not receive an ACK reply after waiting for a certain amount of time, it infers that there must be an exception in the previously sent fragment. The sender will retransmit the abnormal segment, waiting for ACK to reply, and if it has not been received, then repeat the original clip. Until the ACK reply corresponding to the fragment is received (the reply number is ACK 1).

Finally received the sending host of ACK

When the sender receives the ACK reply, it sees that the reply number is lumped 1, which is the sequence number of the next TCP segment that the sender should send. The sender infers that the previous segment has been received correctly, and then sends out the Lemma 1 segment. ACK replies may also be lost. For the sender, this is the same as the receiver refusing to send an ACK reply. The sender will send it repeatedly, and the receiver will receive the known fragment, infer that the ACK reply is lost, and resend the ACK reply.

Through the ACK reply and resend mechanism, the TCP protocol makes the fragment transmission reliable. Although the chassis is an unreliable IP protocol, TCP keeps trying and succeeds in a "spirit of not giving up". (technology can also be very inspirational.)

In the face of "setbacks", the attitude of TCP Agreement: never give up

TCP protocol and UDP protocol go to two extremes. The TCP protocol is complex but reliable, while the UDP protocol is light but unreliable. TCP is extremely responsible for handling exceptions, while UDP is indifferent. We can hack the UDP protocol by the way:

Also facing "setbacks", UDP's attitude: who cares …

Sliding window

In the above mode of operation, the sender keeps sending-> waiting for ACK- > sending-> waiting for ACK. This way of working is called stop-and-wait. Although stop-and-wait achieves the reliability of TCP communication, it also sacrifices the efficiency of network communication. During the period of waiting for ACK, our network is idle (idle). We want to have a way to send multiple clips at the same time. However, if multiple fragments are sent at the same time, because the transmission of IP packets is out of order, it is possible to generate out-of-order fragments (out-of-order), that is, later fragments arrive first. In the way stop-and-wait works, out-of-order fragments are completely rejected, which is also very inefficient. After all, disordered fragments are just fragments that arrive ahead of time. We can store it in the cache first, wait until the previous fragment has been added, and then append it. However, if a disordered fragment is really too early (too "messy"), it will take up the cache for a long time. We need a compromise to solve this problem: using the cache to retain some "less messy" clips, hoping to supplement the previous clips over a period of time (not processing for a while, but sending the corresponding ACK); for the "messy" ones, reject them (neither handle nor send the corresponding ACK).

There are always a few "out of line" clips.

Sliding window is applied to both the receiver and the sender to solve the above problems. The sender and receiver each have a sliding window. When a clip is in a sliding window, it indicates that TCP is processing the clip. There can be multiple clips in the sliding window, that is, multiple clips can be processed at the same time. The larger the window, the larger the window, the more clips it processes at the same time (of course, the computer must also allocate more cache for the window).

Process multiple fragments at the same time

We assume a sliding window that can hold three clips, and assume that the clips are arranged from left to right. For the sender, the left side of the slide window is the sequence of fragments that have been sent and ACK, and the right side of the slide window is the sequence of fragments that have not yet been sent. Clips in the slippery window (such as clips 5, 5, 6, 7) are sent out and wait for the corresponding ACK. If you receive the ACK of clip 5, the slide window moves to the right. In this way, the new clip enters the sliding window from the right, is sent out, and enters the waiting state. The slide window does not move until the ACK of fragment 5 is received, even if the ACK of fragments 6 and 7 has been received. In this way, the sequence on the left side of the sliding window is guaranteed to be a sequence of fragments that have been sent and received ACK.

For the receiver, the left side of the slide window is the clip that has been correctly received and ACK replied (for example, clip 1, 2, and 3, 4), that is, the correctly received text stream. In the sliding window are the segments that you expect to receive (such as fragments 5, 6, 7). Similarly, if clip 6 and 7 arrives first, the sliding window will not move. If clip 5 arrives first, the slide window moves to the right, waiting for a new clip to be received. If a clip outside the slide window appears, such as segment 9, the slide window will refuse to receive it.

In the following video, I try to simulate the working process of a sliding window (fixed size) that can hold three clips.

Http://v.youku.com/v_show/id_XNDg1NDUyMDUy.html

The above video is made by me using Python and matplotlib packages. Blue dots represent clips and red dots represent ACK. To illustrate the out-of-order fragments, I deliberately asked the speed of the fragments and ACK to be randomly selected from two values.

As you can see, as the sliding window slides, more and more clips are transmitted correctly. Using sliding window, we realize the cache of out-of-order data to some extent. However, data that is too out of order will still be rejected. The way we talked about stop-and-wait works like the sliding windows of both the sender and the receiver can only hold one segment.

As we will see in the future, the TCP protocol has an algorithm for real-time resizing the sliding window to achieve optimal efficiency.

Summary

TCP protocol and UDP protocol go to two extremes. The TCP protocol is complex but reliable, while the UDP protocol is light but unreliable. TCP is extremely responsible for handling exceptions, while UDP is indifferent. In TCP, segmentation and numbering achieve order; ACK and retransmission achieve reliability; and sliding window allows the above mechanism to run more efficiently. Never give up, this is the attitude of the TCP agreement.

Reprint: http://www.code123.cc/1282.html

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.