【当前热闻】TCP协议详解 一文读懂TCP协议段格式

发布时间:   来源:CSDN  

文章目录

TCP协议段格式TCP原理确认应答机制超时重传机制连接管理机制三次握手:四次挥手: 滑动窗口如果出现丢包,如何进行重传? 流量控制拥塞控制延迟应答捎带应答 粘包问题TCP异常情况 TCP,即Transmission Control Protocol,传输控制协议,对数据的传输进行详细的控制。


【资料图】

TCP协议段格式

源/目的端口号:表示数据从哪个进程来,到那个进程去。 源端口号表示报文的发送端口,源端口号和源IP地址组合起来可以表示报文的发送地址。 目的端口表示报文的接收端口,目的端口和目的IP地址组合起来可以表示报文的接收地址。 TCP协议就是根据IP协议的基础上传输的,TCP报文中的源端口号+源IP,与TCP报文中的目的端口号+目的IP一起,组合起来唯一性的确定一条TCP连接。 序号(Sequence Number):TCP传输过程中,在发送端出的字节流中,传输报文中的数据部分的每一个字节都有它的编号。序号(Sequence Number)占32位,发起方发送数据时,都需要标记序号。 在数据传输过程中,TCP协议通过序号(Sequence Number)对上层提供有序的数据流。发送端可以用序号来跟踪发送的数据量;接收端可以用序号识别出重复接收到的TCP包,从而丢弃重复包;对于乱序的数据包,接收端也可以依靠序号对其进行排序。 序号会根据SYN是否为1,表示不同的意思: 当SYN为1时,当前为建立连接阶段; 当SYN为0是,数据传输正式开始。 确认序号(Acknowledgment Number):确认序号标识了报文接收端期望接收的字节序列。如果设置了ACK控制位,确认序号的值表示一个准备接收的包的序列号,注意,它所指向的是准备接收的包,也就是下一个期望接收的包的序列号。 4位TCP报头长度:表示TCP头部有多少个32位bit(4字节);所以TCP头部最大长度为 15 * 4 = 60字节。 6位标志位:

URG:紧急指针是否有效;ACK:确认号是否有效,ACK置 1 ,代表起到了确认作用,需要填写确认序列号(下一次期望收到第一个字节的序列号);PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走;RST:对方要求重新建立连接,我们把携带RST标识的称为复位报文段;SYN:请求建立连接,我们把携带SYN标识的成为同步报文段;FIN:通知对方,本端要关闭了,我们称携带FIN标识的为结束报文段。

窗口大小:长度为16位,共2个字节。此字段用来进行流量控制。流量控制的单位为字节数,这个值是本端期望一次接收的字节数。 16位校验和:发送端填充,CRC校验。接收端校验不通过,则认为数据有问题,此处的检验和不光包含TCP首部,也包含TCP数据部分。 16位紧急指针:标识那部分数据是紧急数据。

TCP原理

TCP对数据传输提供的管控机制,主要体现在两个方面:安全、效率。 这些机制和多线程的设计原则类似:保证数据传输的安全前提下,尽可能地提高传续效率。

确认应答机制

TCP将每个字节的数据进行了编号,即序列号。 每一个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了那些数据,下一次你从哪里开始给我发。

超时重传机制

主机A给主机B发送了数据之后,可能会因为网络拥堵等原因,数据无法发送到B,如果A在一个特定的时间间隔内没有收到B发来的确认应答,就会重新发送。 当然,A没有收到确认应答,也可能是ACK丢了。因此,主机B会收到很多重复数据,可以利用序列号做到去重的效果。 那么超时时间如何确定?

TCP为了保证无论在任何环境下都能比较高效地通信,因此会动态计算这个最大超时时间。

连接管理机制

在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接

三次握手:

第一次握手:客户端进入SYN_SENT状态,发送一个SYN帧来主动打开传输通道,该帧的SYN标志位被设置为1,同时会带上Client分配好的SN序列号,该SN是根据时间产生的一个随机值。第二次握手:服务端在收到SYN帧之后,会进入SYN_RCVD状态,同时返回SYN+ACK帧给客户端,主要目的在于通知客户端,服务端已经收到SYN消息,现在需要进行确认。 服务端发出的SYN+ACK帧的ACK标志位被设置为1,其确认序号ASN值被设置为客户端的SN+1;SYN+ACK帧的SYN标志位被设置为1,SN值为服务端生成的SN序号。第三次握手:客户端在收到服务端的第二次握手的SYN+ACK确认帧之后,首先将自己的状态会从SYN_SENT变成ESTABLISHED,表示自己方向的连接通道已经建立成功,客户端可以发送数据给服务端了。然后,客户端发ACK帧给服务端,该ACK帧的ACK标志位被设置为1,其确认序号ASN值被设置为服务端的SN序列号+1。服务端收到客户端的ACK之后,会从SYN_RCVD状态变成ESTABLISHED状态,至此,TCP全双工连接建立完成。

四次挥手:

第一次挥手:主动断开方向对方发送一个FIN结束请求报文,此报文的FIN位被设置为1,发送完成后,主动断开方进入FIN_WAIT_1状态,这表示主动断开方没有业务数据要发送给对方,准备关闭SOCKET连接了。第二次挥手:正常情况下,在收到了主动断开方发送的FIN断开请求报文后,被动断开方会发送一个ACK响应报文,之后,被动断开方就进入了CLOSE-WAIT(关闭等待)状态,TCP协议服务会通知高层的应用进程,对方向本地方向的连接已经关闭,对方已经没有数据要发送了,若本地还要发送数据给对方,对方依然会接受。被动断开方的CLOSE-WAIT(关闭等待)还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。第三次挥手:在发送完成ACK报文后,被动断开方还可以继续完成业务数据的发送,待剩余数据发送完成后,或者CLOSE-WAIT(关闭等待)截止后,被动断开方会向主动断开方发送一个FIN+ACK结束响应报文,表示被动断开方的数据都发送完了,然后,被动断开方进入LAST_ACK状态。第四次挥手:主动断开方收在到FIN+ACK断开响应报文后,还需要进行最后的确认,向被动断开方发送一个ACK确认报文,然后,自己就进入TIME_WAIT状态,等待超时后最终关闭连接。处于TIME_WAIT状态的主动断开方,在等待完成2MSL的时间后,如果期间没有收到其他报文,则证明对方已正常关闭,主动断开方的连接最终关闭。 被动断开方在收到主动断开方的最后的ACK报文以后,最终关闭了连接。

TCP状态转换汇总:

滑动窗口

刚才我们讨论了确认应答策略,对每一个发送的数据段,都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点,就是性能较差。尤其是数据往返的时间较长的时候。 既然这样一发一收的方式性能较低,那么我们一次发送多条数据,就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。

如果出现丢包,如何进行重传?

情况一:数据包已经抵达,ACK被丢了

情况二:数据包就直接丢了

流量控制

接收端处理数据的速度是有限的。如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等等一系列连锁反应。 因此TCP支持根据接收端的处理能力,来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control)。

接收端如何把窗口大小告诉发送端呢?回忆我们的TCP首部中,有一个16位窗口字段,就是存放了窗口大小信息。

拥塞控制

TCP引入 慢启动 机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据。慢启动,只是初始时慢,增长的很快

少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞; 当TCP通信开始后,网络吞吐量会逐渐上升;随着网络发生拥堵,吞吐量会立刻下降; 拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的折中方案。

延迟应答

如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小。

每隔N个包就要应答一次,或者超过最大应答时间也要应答一次。 N一般取2,超时时间取200ms。 窗口越大,网络吞吐量就越大,传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

捎带应答

粘包问题

对于定长的包,保证每次都按固定大小读取即可;例如上面的Request结构,是固定大小的,那么就从缓冲区从头开始按sizeof(Request)依次读取即可;对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而就知道了包的结束位置;对于变长的包,还可以在包和包之间使用明确的分隔符。

TCP异常情况

进程终止:进程终止会释放文件描述符,仍然可以发送FIN。和正常关闭没有什么区别。 机器重启:和进程终止的情况相同。 机器掉电/网线断开:接收端认为连接还在,一旦接收端有写入操作,接收端发现连接已经不在了,就会进行reset。即使没有写入操作,TCP自己也内置了一个保活定时器,会定期询问对方是否还在。如果对 方不在,也会把连接释放。

另外,应用层的某些协议,也有一些这样的检测机制。例如HTTP长连接中,也会定期检测对方的状态。 例如QQ,在QQ断线之后,也会定期尝试重新连接。

TCP : 可靠、有连接、面向字节流

相关文章Related

返回栏目>>