0


【计算机网络】TCP协议详解

1. TCP协议头部格式

  • 源/目的端口:表示数据从哪个进程发送,发送到哪个进程去
  • 32位序号:发送的数据按照一个字节一个编号存放进去
  • 32位确认号:用于给对方的响应,值为收到TCP报文段的序号值加1
  • 4位TCP报头长度:表示TCP头部有4个字节(32位),所以TCP头部最大长度为15*4=60
  • 6个boolean值标志位:

URG:紧急指针是否有效
ACK:确认号是否有效
PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走
RST:对方要求重新建立连接,把携带RST标识的称为复位报文段
SYN:请求建立连接,把携带SYN标识的称为同步报文段
FIN:通知对方,要关闭连接了,把携带FIN标识的称为结束报文

  • 16位窗口大小:进行流量窗口控制
  • 16位校验和:检验数据是否一致
  • 16位紧急指针:标识哪部分数据是紧急数据

2. TCP协议原理

TCP协议是对数据传输提供的一个管控机制,主要体现在可靠和效率两个方面,即在保证数据可靠传输的情况下尽可能的提高效率

2.1 可靠传输机制

2.1.1 确认应答机制

向对方发送一个数据报,对方要返回一个确认应答的数据报

实现的方式:

说明:

  • 发送的数据是基于TCP报头中的“32位序号”来保存的,一个字节对应一个序号
  • 确认应答的数据是基于TCP报头中的“32位确认序号”来保存的,ack(确认信息)标志位置为1,返回某个序列号,说明某个序列号之前的数据全部接收到
  • 有了确认应答,它才可以继续发送后边的数据

2.1.2 超时重传机制

发送的数据报可能因为网络拥堵等原因,超过一定时间,还没有收到确认应答的数据报,就需要重新发送

  • 没有收到确认应答,可能是因为发送数据时候就已经发生了丢包

  • 也可能是因为ACK丢包了

这种情况,主机B可能会接收到许多重复的数据,基于TCP协议报头中的“32位序号”可以识别到哪些包是重复的包,并把重复的包丢掉,达到去重的效果

超时时间如何确定?

如果超时时间设置的太长,会导致重传的效率
如果超时时间设置的太短,会导致频繁发送重复的数据

因此TCP协议为了保证在任何环境中都能有较高性能的通信,系统会动态的计算这个超时时间

  • 超时以500ms为一个单位,每次判定超时重发的时间都是500ms的整数倍
  • 重发一次,仍然不能收到应答,等待2*500ms后再进行重传
  • 仍然等不到应答,等待4*500ms进行重传,以此类推,以指数形式增长
  • 累积到一定重传次数,TCP协议认为网络或者对端主机出现异常,强制关闭连接

2.1.3 连接管理机制(三次握手,四次挥手)

真正发送数据之前,要先通过三次握手建立连接,不需要发送数据了,通过四次挥手断开连接

三次握手

  1. 客户端向服务端发送SYN,申请建立客户端到服务端的连接
  2. 服务端返回ACK(第一次SYN的应答)和SYN,申请建立服务端到客户端的连接
  3. 客户端收到数据,状态置为ESTABLISHED,表示客户端到服务端连接建立完成,并且发送ACK(第二次SYN的应答),服务端收到数据,状态置为ESTABLISHED,表示服务端到客户端的连接建立完成

四次挥手

说明:关闭的时候服务端申请关闭或者客户端申请关闭都可以

  1. 客户端发送FIN到服务端,申请关闭客户端到服务端的连接
  2. 服务端收到FIN状态置为CLOSE_WAIT,并返回ACK应答(这个动作是系统实现TCP协议栈默认执行的,不需要程序来调用代码)
  3. 服务端发送FIN到客户端,申请关闭服务端到客户端的连接(程序手动调用socket.close发送)
  4. 客户端收到FIN返回ACK应答,并进入TIME_WAIT时间等待状态,客户端等待一段时间后,状态置为CLOSED,服务端收到应答后,状态置为CLOSED

思考:

  • 为什么服务端不将ACK和FIN合并一起发送,形成三次挥手呢?

答:因为服务端状态置为CLOSED_WAIT说明服务端准备关闭连接,但是服务端可能还在继续发送数据,得处理完之前的数据,还可以执行一些关闭连接前的工作,如消耗资源等 ,所以是先给客户端发送应答,再处理完数据再向客户端发送FIN申请关闭连接

  • 为什么客户端要等待一段时间状态才置为CLOSED,而不之间将状态置为CLOSED?

答:如果客户端给服务端的ACK丢包后,服务端得重新给和客户端发送FIN,此时客户端得给服务端应答,所以此时状态不能置为CLOSED,得等待一段时间确保服务端收到客户端的应答

2.1.4 流量控制

接收端主机处理数据的速度有限,如果发送端发送数据太快,导致接收端缓冲区被填满,这时,发送端继续发送数据的话就会造成丢包,继而引起丢包重传等一些列连锁反应,因此TCP协议根据接收端接收数据的能力,来决定发送端发送数据的速度,这个机制就叫作流量控制

  • 接收端将自己剩余缓冲区大小存入TCP头部中的“16位窗口大小”字段 ,通过ACK通知发送端
  • 窗口大小越大,说明网络吞吐量越高
  • 发送端根据接收到这个窗口的大小,控制自己的发送速度
  • 如果接收缓冲区满了,就会将窗口设置为0,这时,发送端不在发送数据,而是定期的发送一个窗口探测数据段,让接收端将窗口大小告诉发送端

2.1.5 拥塞控制

刚开始,发送端网络状况不明,如果贸然发送大量数据,就会造成大量丢包,所以TCP协议引入慢启动的方式,先发少量数据探探路,再决定按照多大速度发送数据

此处引入拥塞窗口,刚开始时,拥塞窗口设置为1,每收到一个ACK时,拥塞窗口加1,每次发送数据的时候,拥塞窗口和流量窗口的较小的值作为实际发送的窗口,即滑动窗口的大小

注意:上述增长方式是指数级别的,“慢启动”只是开始时慢,但是增长速度非常迅速

拥塞窗口变化的方式

为了不增长那摩快,引入一个慢启动的阈值,当拥塞窗口的大小超过了这个阈值,不在按照指数方式增长,而是按照线性方式增长,如下图所示:

开始时,慢启动的阈值为窗口的最大值
网络拥塞时,拥塞窗口置1,慢启动阈值变为拥塞窗口/2,重新开始增长

2.2 效率机制

2.2.1 滑动窗口

前面的确认应答机制指出,对每一个发送的数据都对应有一个ACK确认应答,这样采取一发一收的方式有一个很大的缺点就是效率太差,为了提高效率采用滑动窗口,即一次性发送多个数据

  • 窗口大小:指无需等待而可以继续发送数据的最大值,上图的窗口大小为4000个字节(四个段)
  • 具体如何设置窗口大小:min(流量窗口的大小,拥塞窗口的大小)
  • 窗口如何滑动:接收到的ACK下一个是n,滑动到n-1的位置

操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有哪些数据没有应答,只有应答过的数据才能从缓冲区中删掉

如果出现了丢包,如何确保可靠传输?

  • 情况一:数据已经收到,返回的ACK应答丢包

这种情况下,部分ACK丢了不要紧,因为可以通过后续的ACK进行确认

  • 情况二:发送数据的时候就已经丢包

说明:

  • 当1001~2000这段报文丢失后,发送端一直会收到1001这样的ACK
  • 如果发送端主机连续三次收到相同的ACK如1001应答,那发送端主机就会重新发送1001~2000数据
  • 此时,接收端收到10012000数据后,再次返回的ACK应答就是7001了,因为20017000数据都已经接收到了,被放到接收端操作系统内核的接收缓冲区了

这种机制,即时不超时也会发生重传,称作“高速重发控制”也叫“快重传机制”

2.2.2 延迟应答

如果接收端主机接收到数据时,立刻返回ACK应答,这时候返回的流量窗口就比较小,但是流量窗口越大,网络吞吐量越大,传输效率就越高,所以等待一部分时间,待接收端处理完一部分数据 ,就可以将流量窗口设置为大一点的值,这样网咯吞吐量大,效率高

延迟是为了高吞吐量,但是也不能无限延迟

  • 数量限制,每隔n个包就应答一次
  • 时间限制,超过最大延迟时间,就应答一次

具体的数量和时间,不同操作系统有差异,一般n取2,超时时间取200ms

2.2.3 捎带应答

服务端接收到客户端的消息后,要返回一个ACK有时候可能需要返回一个响应,此时ACK可以搭载顺风车,和响应合并为一个数据返回,不用再将ACK和响应数据分开发送

3. 粘包问题

TCP是面向字节流的,可以多次的接收和发送,对于应用层来说,一连串的字节数据,不知道从哪到哪算一个完整的应用层数据包,对应发送多少次算一个应用层完整格式的数据,和接收多少次算一个应用层完整格式的数据就不知道了

如何解决粘包问题?明确包的边界

  • 对于定长的包,每次都按照固定大小读取即可
  • 对于变长的包,可以在包与包之间明确分隔符(应用协议,程序员自己定,只要保证分隔符和正文不起冲突即可)

4. TCP的异常情况

  • 进程终止:进程终止会释放文件描述符,仍然可以发送FIN。和正常关闭没有什么区别
  • 机器重启:和进程终止的情况相同
  • 机器掉电/网线断开:接收端认为连接还在,一旦接收端有写入操作,接收端发现连接已经不在了就会进行reset,即使没有写入操作,TCP自己也内置了一个保活定时器,会定期询问对方是否还在,如果对方不在,也会把连接释放
  • 另外,应用层的某些协议,也有一些这样的检测机制,例如HTTP长连接中,也会定期检测对方的状态,例如QQ,在QQ断线之后,也会定期尝试重新连接

5. TCP协议特点总结

  • 有连接:通过三次握手建立连接后才可接发数据,TCP协议是全双工的,即每端既可以发也可以收
  • 可靠传输:网络数据传输是一跳一跳的,经过路途中的设备可能发生数据丢失,可靠传输是可能发生数据丢失但有机制保证对方能接收到
  • 面向字节流:可以多次的收发数据(连接没有关闭时,可以多次的接收和发送数据)
  • 有接收缓冲区和发送缓冲区:发送数据时,是先写到发送缓冲区,再刷新缓冲区(flush)
  • 大小不受限制:多次的收发数据,每次的数据可以很大

6. 基于TCP的应用层协议

  • HTTP
  • HTTPS
  • SSH
  • Telnet
  • FTP
  • SMTP

也包括自己写TCP程序时自定义的应用层协议

标签: tcp 网络协议 网络

本文转载自: https://blog.csdn.net/qq_58710208/article/details/126042653
版权归原作者 Java猿~ 所有, 如有侵权,请联系我们删除。

“【计算机网络】TCP协议详解”的评论:

还没有评论