TCP协议重点总结(万字总结-附实例)

时间:2023-01-12 09:55:56


前言

博主个人社区:开发与算法学习社区

博主个人主页:Killing Vibe的博客

欢迎大家加入,一起交流学习~~

一、网络的原生情况

网络中的数据,是经过路由器之间,一跳一跳地,接力一样地,传送到目标主机上的。

这带来了两个问题:(站在网络层的视角上讨论)

✦ 网络传送是不可靠的

  1. 你的发送了数据,对方不保证一定能收到
  2. 不能保证严格按照发送时的顺序被对方接收到

由于路可能不同,所以很难保证按照出发的顺序到达

TCP协议重点总结(万字总结-附实例)

✦ 网络传送是不安全的

  1. 你发送的所有数据,沿途的路由器都可以进行查看或者修改,窃听,篡改
  2. 别人可以伪造成你发送的数据

这两个问题需要交给网络层以上(传输层、应用层)去解决

这篇文章博主将详细总结一下传输层的TCP协议

二、TCP协议

TCP,即Transmission Control Protocol,传输控制协议。人如其名,要对数据的传输进行一个详细的控制。
TCP协议重点总结(万字总结-附实例)

2.1 TCP的特点

可靠的,有连接的,面向字节流的

什么是可靠性?

  1. TCP会尽自己所能,尽量将数据发送给对方;但并不能保证100%可以发给对方
  2. TCP会在数据发送不给对方的情况下,给应用层一个错误通知(应用层发送数据,要么发送给对方了,要么知道数据丢失了,UDP则不会
  3. TCP可以保障接收方(应用层)严格按照发送时的数据顺序接收。
  4. TCP保障数据不会出现无意间损坏(UDP也做到了这一点)
  5. TCP尽可能的在维护网络质量

2.2 TCP协议段格式

TCP协议重点总结(万字总结-附实例)

  • 源/目的端口号:表示数据是从哪个进程来,到哪个进程去;
  • 32位序号/32位确认号:下文详细讲;
  • 4位TCP报头长度:表示该TCP头部有多少个32位bit(有多少个4字节);所以TCP头部最大长度是15 * 4 = 60 字节
  • 6位标志位:
    ✭ URG:紧急指针是否有效
    ✭ ACK:确认号是否有效
    ✭ PSH:提示接收端应用程序立刻从TCP缓冲区把数据读走
    ✭ RST:对方要求重新建立连接;我们把携带RST标识的称为复位报文段
    ✭ SYN:请求建立连接;我们把携带SYN标识的称为同步报文段
    ✭ FIN:通知对方,本端要关闭了,我们称携带FIN标识的为结束报文段
  • 16位窗口大小:下文详细讲
  • 16位校验和:发送端填充,CRC校验。接收端校验不通过,则认为数据有问题。此处的检验和不光包含TCP首部,也包含TCP数据部分。
  • 16位紧急指针:标识哪部分数据是紧急数据;
  • 40字节头部选项:暂时忽略

2.3 TCP原理

TCP对数据传输提供的管控机制,主要体现在两个方面:可靠和效率。

2.3.1 确认应答机制(可靠机制)

TCP协议重点总结(万字总结-附实例)

有了确认应答机制之后,现在还遗留两个问题:

  1. 如果发送方同时发送了很多数据,怎么知道对方确认收到的是哪一份?
  2. 如果没有收到对方的确认(假定对方是处于正常工作流程的),接下来该怎么办?

答:

  1. 对数据进行编号,这样,确认也带上编号,表明确认的是哪份数据。
  2. 进行重发,重发的触发有个条件 ——— 超过一定时间没有收到确认,才要重复。(这就是超时重传机制)

接下来就是围绕上述两个问题展开。

2.3.2 序列号

TCP将每个字节的数据都进行了编号。即为序列号。

TCP协议重点总结(万字总结-附实例)
每一个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下一次你从哪里开始发。

下面围绕数据的编号以及确认的编号来讨论:

  1. 发送的数据编号 —— 序列号(Sequence Number) SN
  2. 确认的数据编号 —— 确认序列号(Acknowledge Sequence Number)ASN

编号的规则

TCP协议重点总结(万字总结-附实例)

ASN的填写规则:

填写的是要接受的下一个字节的数据(本次收到的数据的最后一个字节的下一个)
TCP协议重点总结(万字总结-附实例)

SN在发送TCP Segment 时,Header中是如何体现的?

注意:

1.TCP发送/接收的完整数据,一般称为segment(段)
2.TCP segment = header + payload

举个栗子:

因为一次可以发送多个字节的数据

byte[] data = {1,2,3,4,5}
tcp.write(data);  //一次性发送了5个字节的数据

所以,SN直接填写本次发送的数据中第一个字节的数据即可。segment会携带payload长度 SN=a

TCP由于要进行发送,也要进行确认。所以实际上 TCP Segment有两种不同的角色:

  1. send segment
  2. acknowledge segment

TCP设计的时候,一个segment可以身兼两种不同的角色。

无论何时,一个segment 都视为send segment角色。

但当某个标志位被置位(开关被打开)时,segment具备了acknowledge segment的角色。

TCP协议重点总结(万字总结-附实例)

这个开关在TCP Header是通过ack标志位进行处理的:

TCP协议重点总结(万字总结-附实例)

2.3.3 超时重传机制(可靠机制)

TCP协议重点总结(万字总结-附实例)

  • 主机A发送数据给B之后,可能因为网络拥堵等原因,数据无法到达主机B;
  • 如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会进行重发;

但是,主机A未收到B发来的确认应答,也可能是因为ACK丢失了;

TCP协议重点总结(万字总结-附实例)
因此主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包,并且把重复的丢弃掉。

这时候我们可以利用前面提到的序列号,就可以很容易做到去重的效果。

那么,如果超时的时间如何确定?

  • 最理想的情况下,找到一个最小的时间,保证 “确认应答一定能在这个时间内返回”。
  • 但是这个时间的长短,随着网络环境的不同,是有差异的。
  • 如果超时时间设的太长,会影响整体的重传效率;
  • 如果超时时间设的太短,有可能会频繁发送重复的包;

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

  • Linux中(BSD Unix和Windows也是如此),超时以500ms为一个单位进行控制,每次判定
  • 超时重发的超时时间都是500ms的整数倍。
  • 如果重发一次之后,仍然得不到应答,等待 2*500ms 后再进行重传。
  • 如果仍然得不到应答,等待4*500ms 进行重传。依次类推,以指数形式递增。
  • 累计到一定的重传次数,TCP认为网络或者对端主机出现异常,强制关闭连接。

TCP已经尽了自己最大的努力,接下来:

  1. 需要通知应用层,发送失败(一般在java中,write(…)就会以异常的形式提示)
  2. 尽自己最大的努力,再尝试联系一下对方(会发送一种叫做reset segment),对方如果收到了,就知道我这侧已经放弃了,如果对方收不到,也无所谓。

2.3.4 连接管理机制(可靠机制)

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

作为一台主机上的TCP,需要:

  1. 内部针对每一条TCP的通信链路(信道),维护一组数据
    至少:ISN、当前SN、当前ASN、发送缓冲区、接收缓冲区、五元组信息…
  2. TCP为了可靠性、为了交互交换一些信息,在正式的数据通信之前,需要和对方(TCP)进行一定的同步(synchronize)操作
  3. A把主机的一些初始重要信息告诉了B;然后B发送应答给A,让A知道B肯定也在

所以TCP就有了连接(Connection)的概念,以及连接管理(一条连接的医生= 开始创建+正式使用+销毁)

关于连接:

TCP协议重点总结(万字总结-附实例)

好了,有了如上的铺垫,接下来博主讲逐步讲解三次握手和四次挥手到底是怎么一回事:

✭ 握手阶段其实就是双方互相同步信息的阶段:

TCP协议重点总结(万字总结-附实例)

逻辑上需要四次,因为互相发同步信息(2次)都需要应答(2次)。

TCP协议重点总结(万字总结-附实例)

由于第二步和第三步是可以同时发生的,TCP也支持一个Segment同时起到(syn和ack)的作用,所以上述2和3可以合并,减少网络数据发送的次数,整体上提高性能。

TCP协议重点总结(万字总结-附实例)

✭ 同理,挥手阶段其实就是双方互相确认要断开连接的阶段:

  1. 不过由于服务器不能收到客户端的fin请求就立刻也发一个fin请求,因为服务器此时可能仍有一些未处理完的数据要处理,要等这些数据处理完才可以close。
  2. 还有种可能的情况就是双方都主动挥手close了。
  3. 还有种情况就是双方同时主动挥手。

情况一:

TCP协议重点总结(万字总结-附实例)

情况二:

TCP协议重点总结(万字总结-附实例)
情况三:
TCP协议重点总结(万字总结-附实例)

注意:

三次握手阶段是否可以携带payload?

  1. 第一次syn,不能携带数据
  2. 第二次syn+ack,不能携带数据
  3. 第三次ack,可以携带数据,但不强制

原因在于不能确认连接一定建立成功,如果携带数据,则提升发送成本,如果失败,一切白发,所以协议设计时禁止携带数据。

syn序列号的变化:虽然不能携带数据,但也会消耗一个序列号:

TCP协议重点总结(万字总结-附实例)

2.3.5 滑动窗口机制(效率机制)

这是一块重要的内容,博主直接分P详细总结并且画图逐步讲解了,链接如下:

TCP滑动窗口机制

2.4 关于缓冲区

TCP协议重点总结(万字总结-附实例)

2.5 关于ISN

TCP协议重点总结(万字总结-附实例)

2.6 关于面向字节流

  • 调用write时,数据会先写入发送缓冲区中;
  • 如果发送的字节数太长,会被拆分成多个TCP的数据包发出;
  • 如果发送的字节数太短,就会先在缓冲区里等待,等到缓冲区长度差不多了,或者其他合适的时机发送出去;
  • 接收数据的时候,数据也是从网卡驱动程序到达内核的接收缓冲区;
  • 然后应用程序可以调用read从接收缓冲区拿数据;
  • 另一方面,TCP的一个连接,既有发送缓冲区,也有接收缓冲区,那么对于这一个连接,既可以读数据,也可以写数据。这个概念叫做 全双工
  • 写100个字节数据时,可以调用一次write写100个字节,也可以调用100次write,每次写一个字节;
  • 读100个字节数据时,也完全不需要考虑写的时候是怎么写的,既可以一次read 100个字节,也可以一次read一个字节,重复100次;

三、实例演示(抓包)

用Wireshark抓包工具,抓取传输协议为TCP的包:

TCP协议重点总结(万字总结-附实例)以上就是三次握手的三个包。

下图为第一个包中的数据:(蓝色部分为TCP的部分)

TCP协议重点总结(万字总结-附实例)

TCP协议重点总结(万字总结-附实例)

现在可以根据这些数据来一一计算验证我们的TCP头:

TCP协议重点总结(万字总结-附实例)
验证如下:

16位源端口号:首先前面两个字节是 0xe542,换算成十进制就是 58690
16位目的端口号:然后就是后面的两个字节 0x22b8,换算过来就是 8888
32位SN: 0xb1e9b0e0 ,可以看出来ISN不是0。
32位ASN: 0x00000000,一开始发送的时候还没有ASN
4位首部长度: 0x8,说明协议首部长度为 8 * 4 = 32 字节(真实首部长度= 首部长度 * 4 ,像这里的8表示有8个32为bit,也就是8个4字节 = 32字节)
保留6位+标志位6位: 0x002 ,换算成二进制就是000000 000010,刚好对应的就是syn位被置为了1 .

后面的是一样计算的,博主就不一一列举了。

四、 TCP中的状态转移(重要)

以下内容博主也进行了分P总结,这块内容比较难理解,最好就是死记硬背,具体可以参考博主的图解,更容易理解,链接如下:

TCP中的状态转移(三种情况)

五、TCP异常情况

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

拓展:

进程终止和机器关机/重启:

一个进程的所有资源都是OS分配的(换言之,一个进程有哪些资源OS都是知道的),所以,即使进程内部没有关闭TCP连接,OS也会走进程资源释放流程,将TCP连接正常关闭,这个进程会作为主动关闭方,正常四次挥手

TCP协议重点总结(万字总结-附实例)

只要OS的代码能执行,连接就会正常关闭!!!

机器掉电/网线断开:

这种情况,OS的代码就不能执行了,因为机器掉电了。

此时这条连接的命运需要分开来讨论:

现在假设有两台主机 甲和乙。

  1. 首先是甲的命运:由于连接只是逻辑上的概念,表现在现实中只是内存中的一段数据。电断了,内存中的数据就没有了,所以对于甲来说连接就没了(不是关闭,直接就是消失了)
  2. 其实是乙的命运:在乙看来,连接仍然在,在没有特殊场景下,乙是不知道甲没了。(比如男女朋友的关系,男方突然挂了,女方不通过某些途径是不知道男方挂了的)
  3. 所以乙的情况就会有两种: (1)保持原状 (2) 看乙有没有可能感知到甲已经没了这条信息
  4. 如果乙发生写事件(乙尝试向甲发数据了),收不到ACK确认信息,即使超时重传了也收不到。多次尝试后,乙走异常关闭流程。(关闭该TCP连接,异常方式通知应用层,最后再发一条reset segment)
  5. 如果乙只是单纯在读数据,那么乙不知道甲已经消失了这个信息,如果乙一直read,则乙就是死连接了(一直保持established状态,但永远收不到数据了)

为了解决上述这个问题:

  1. TCP层面有keepalive机制:定期的发送一些数据给对方(payload长度为0),segment长度不是0,就可以根据对方有没有应答来判断。(用的不多)
  2. 更常见的办法是应用层自己来做这个工作:(1)read的时候,不要无限制read,而是带上超时时间(read timeout)。 (2) 定期互相报平安(定期都主动给对方发消息) ——heartbeat(心跳包)

例如QQ,在QQ断线之后,也会定期尝试重新连接。

关于RST:

TCP协议重点总结(万字总结-附实例)

六、关于粘包

  • 首先要明确,粘包问题中的 “包” ,是指的应用层的数据包。
  • 在TCP的协议头中,没有如同UDP一样的 “报文长度” 这样的字段,但是有一个序号这样的字段。
  • 站在传输层的角度,TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。
  • 站在应用层的角度,看到的只是一串连续的字节数据。
  • 那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分开始到哪个部分,是一个完整的应用层数据包。

那么如何避免粘包问题呢?归根结底就是一句话,明确两个包之间的边界

  • 对于定长的包,保证每次都按固定大小读取即可;例如上面的Request结构,是固定大小的,那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
  • 对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而就知道了包的结束位置;
  • 对于变长的包,还可以在包和包之间使用明确的分隔符(应用层协议,是程序猿自己来定的,只要保证分隔符不和正文冲突即可);

七、命令行查看TCP连接情况

使用 netstat 命令:

TCP协议重点总结(万字总结-附实例)

由于输出较多,可以结合findstr 做结果过滤:

TCP协议重点总结(万字总结-附实例)
根据任务管理器,知道 pid为29632的进程占用了端口为8080的TCP连接:

TCP协议重点总结(万字总结-附实例)

总结

以上就是TCP协议的万字总结,内容有点多,但每个知识点的细节博主都有举实例,帮助大家更好的理解,码字不易,有帮助的话大家可以点个赞收藏起来慢慢看,有什么问题可以私信博主,大家交流一下。