The main characteristics of the transmission protocol is TCP byte stream oriented, reliable transmission, connection-oriented. This blog, we will focus on the TCP protocol about how to ensure the reliability of the transmission.
Way to ensure the transmission reliability of the
TCP protocol to ensure the reliability of data transmission main methods :
- Checksum
- serial number
- The acknowledgment
- Retransmission timeout
- Connection Management
- flow control
- Congestion Control
Checksum
Calculated: during data transmission, the data segments are transmitted as a 16-bit integer. These add up to an integer. And in front of the carry can not be discarded, up behind the last inversion, to obtain a checksum.
Sender: checksum calculation before transmitting data, and the checksum is filled.
The recipient: after receiving the data, the data calculated in the same manner, the checksum is determined, the transmitting side for comparison.
Note: If the receiver match the checksum is inconsistent with the sender, then the data must transmission error. However, if the recipient consistent than checksum with the sender, the transmission data is not necessarily successful.
The acknowledgment and serial number
SEQ ID NO: when the TCP transmitting each byte of data is numbered, which is a serial number.
Acknowledgment: TCP transmission process in the receiver each time data is received, the transmission side will be acknowledgment. ACK packet is sent. The ACK packet among the sequence numbers with corresponding acknowledgment tells the sender, which receives the data, where the next data is sent.
Effect effect not only the sequence number of the response, with the sequence number of the data can be received according to the sequence number order, remove duplicate data and serial number. This is also one of the reliability of TCP transmission.
Retransmission
during TCP transmission, since the sequence number and acknowledgment mechanisms, data that is transmitted as part of the sender will wait for an ACK packet sent by the receiver, and parsing ACK packet, determining whether the data transmission was successful. If the sender sends the data, the delay did not wait for ACK packet receiver, which is how to do it? But did not receive any ACK packet may be due to it?
First, the sender does not introduce ACK packet response to the reason might be two:
- Data during transmission due to network reasons of direct loss of all, there is no recipient received.
- The receiving side receives the response data, but the ACK message sent in response to network reasons but because of the loss.
TCP in solving this issue introduces a new mechanism, called a timeout retransmission mechanism. Simple to understand the sender after sending a data waiting time, time of arrival ACK packet is not received, then the data just transmitted is retransmitted. If it is just the first reason, after the receiver receives the second retransmission data, it will be ACK response. If it is the second reason, the receiver finds that the received data is present (that is, the presence judgment in accordance with the sequence number, so that the role of the above as well as removing duplicate sequence number data), then directly discarded, still send ACK response.
So after the sender has been sent the waiting time is how much? If the wait is too long, it will affect the overall efficiency of the TCP transport, if the waiting time is too short will cause frequent sending duplicate packets. How to weigh?
Since guaranteed to have a high performance in any environment communication transmission TCP, so that the maximum timeout (i.e. waiting time) is calculated dynamically.
(Under BSD Unix and Windows, too) to time out in 500ms in Linux is a control unit, each determination of an integer multiple of the timeout retransmission timeout period of 500ms it is. After a retransmission, it does not respond, then 2 * 500ms wait time, once again the retransmission. 4 * 500ms wait time continues retransmission. In the form of an exponential growth. Accumulated to a certain number of retransmissions, TCP network or considered abnormal end occurs to force close the connection.
Connection Management
Connection Management is a three-way handshake with the four waving in front of the talked about this process in detail, not repeat them here. Ensure reliable connection, it is to ensure the reliability of the premise.
Flow control
receiving terminal after receiving the data, processes it. If the sender is sending too fast, leading to the end of the buffer receiving end quickly filled full of. At this point if the sender is still sending data, then the next transmitted data packet loss will in turn lead to a chain reaction of packet loss, retransmission timeout ah what. The receiving end of the TCP data processing capability, determines the transmission speed of the transmitting side, that is, the flow control mechanism.
在TCP协议的报头信息当中，有一个16位字段的窗口大小。在介绍这个窗口大小时我们知道，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。
注：16位的窗口大小最大能表示65535个字节（64K），但是TCP的窗口大小最大并不是64K。在TCP首部中40个字节的选项中还包含了一个窗口扩大因子M，实际的窗口大小就是16为窗口字段的值左移M位。每移一位，扩大两倍。
拥塞控制
TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。
所以TCP引入了慢启动的机制，在开始发送数据时，先发送少量的数据探路。探清当前的网络状态如何，再决定多大的速度进行传输。这时候就引入一个叫做拥塞窗口的概念。发送刚开始定义拥塞窗口为 1，每次收到ACK应答，拥塞窗口加 1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小比对，取较小的值作为实际发送的窗口。
拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。在慢启动开始的时候，慢启动的阈值等于窗口的最大值，一旦造成网络拥塞，发生超时重传时，慢启动的阈值会为原来的一半（这里的原来指的是发生网络拥塞时拥塞窗口的大小），同时拥塞窗口重置为 1。
拥塞控制是TCP在传输时尽可能快的将数据传输，并且避免拥塞造成的一系列问题。是可靠性的保证，同时也是维护了传输的高效性。
————————————————
版权声明：本文为CSDN博主「LChanceea8」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/liuchenxia8/article/details/80428157