TCP/IP 11 chunked and interactive data streams
There are many protocols using TCP/IP at this stage, and these protocols can be roughly divided into two categories according to data throughput: (1) Interactive data types, such as telnet, ssh. (2) Data block type, such as ftp, this type of protocol requires TCP to carry data as much as possible, maximize data throughput, and improve efficiency as much as possible. For different throughputs, TCP gives two different strategies for data transmission.
1. Interactive data flow
Interactive data flow is common, such as pressing the keyboard and echoing the data. This process includes sending the data of the button -> receiving the ACK from the server -> sending the echoed data from the server -> sending the ACK of the echoed data.
At present, there are two strategies given by TCP:
One is piggybacking ACK: This strategy means that when the host receives the TCP datagram from the remote host, it usually does not send the ACK datagram immediately, but waits for a short period of time. The TCP datagram of the remote host, then the ACK datagram is "piggybacked" and sent out, and the original two TCP datagrams are integrated into one and sent. Generally, this time is 200ms. It can be clearly seen that this strategy can greatly improve the utilization of TCP datagrams.
The second is the Nagle algorithm: the principle of this algorithm is that when the host is in a state of waiting for ACK, there can only be one TCP data packet in the send buffer, and this datagram will continuously collect subsequent data packets. When the data packet is sent out at once. This can indeed reduce the network load, but this method may have high latency, because it has to wait for an ACK every time before sending. However, there is a way to turn this feature off.
2. Chunk data flow
The most common block data stream is the FTP protocol. This kind of file transfer is very concerned with throughput and is not sensitive to delay.
16bit window size is used in TCP to solve this problem
1) One ACK acknowledges multiple datagrams
Typically, a sender sends a datagram. The receiver needs to reply with an ACK, but in fact, the sender will continuously send data to fill the receiver's buffer as much as possible, and the receiver only needs to send an ACK message to respond to these data. This is the cumulative characteristic of ACK , this feature greatly reduces the burden on the sender and receiver. Think of the TCP response ACK as the next expected received packet number.
2) Sliding window
The receiver and the sender will agree on a sliding window before sending data. For example, the window size is 2k, and the sender maintains this window, which means that the maximum data sent will be 2k, which guides the receiver to receive the ACK. will continue to send. That is to say, the data here has been confirmed to arrive before continuing to send.
3) Data congestion
The above strategy is ok for intra-LAN transmission, but it may cause problems when used in WAN. The biggest problem is that when there is a bottleneck in transmission (for example, it must go through a low-speed slip link), a large amount of data is blocked. Problem (congestion), in order to solve this problem, the TCP sender needs to confirm what is the maximum data throughput of the line connecting both parties. This is the so-called congestion window.
The principle of the congestion window is very simple. The TCP sender first sends a datagram, and then waits for the response from the other party. After getting the response, it doubles the size of the window, and then sends two datagrams in succession. Doubling (first exponentially of 2, after a certain level it becomes the current growth, this is the so-called slow start), send more datagrams until a timeout error occurs, in this way, the sender knows the line load of both parties. The size of the congestion window is determined, and the sender uses the size of the congestion window to send data. It is very easy to observe this phenomenon. Generally, when we download data, the speed is slowly "rushing up".