简单了解传输层协议TCP

原创于 2026-08-17 18:14:34 发布 · 167 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

上图为TCP报头结构，由20字节固定首部+可选字段构成

其中数据偏移就是4位首部长度（记录报头长度的），基本单位为4字节（比如若首部长度为0101，就是5*4=20字节），其中可选字段部分最多40字节（15*4=60字节，60-20=40字节）

TCP叫做可靠性协议

可靠性协议的含义：尽最大努力发送报文，保证能在丢失时进行检测和重传

但是要注意可靠性不代表百分百保证对方接收到报文

假设我们要保证报文被对方百分百接收到，就有以下过程：

（首先要知道，对发出去的报文，要有应答，收到应答，就代表历史报文绝对被对方收到）

发送方需要收到接收方的应答，保证自己的发送的报文一定被对方收到了

可是同样的，接收方发回的应答报文不能保证发送方能收到，所以发送方还得发送应答报文给接收方代表它收到了，很明显如果一直这样下去，就会成为一个循环

很明显，这是错误的

所以事实上，不存在绝对可靠的协议，最新的报文，永远都不会有应答

TCP协议的可靠性在于：对于历史报文的可靠性（百分百保证发送方送给接收方的报文，接收方一定收到了）

TCP规定：A主机发送给报文B主机，B主机必须应答，这个应答报文可以不携带任何有效信息，A主机收到了就代表双方都收到了，因为不需要对应答保证可靠性

这个就叫做确认应答机制

当A主机发送给B主机的报文保证可靠，B主机发送给A主机的报文保证可靠（不包括应答报文），就是全双工的可靠性

总而言之，可靠性不代表报文百分百必须送到，而是你收到了，我得知道，没有收到，我也知道

报文丢失

如果A（假设是A发的），没有收到B的应答报文

就会分成两种情况

1、报文真的丢失了

2、应答丢失了

当A没有收到应答报文，它首先会判定是报文真的丢失了，因为不管是报文丢了还是应答丢了，对于A而言，都是没收到应答

那A怎么知道自己是没有收到任何应答，还是还没等到

A会给自己设置一个deadline

超时就是丢包，丢包就是规定出来的

如果没有收到应答，发送方就会进行重传（没有收到报文之后的补发措施）

B如果收到了报文（是应答丢了），再收到了A发的同样的报文，就会进行去重

报头中的32位序号就是用来进行去重操作的，找到序号相同的报文，B就会把旧的那一份丢掉

TCP有两种通讯方式

TCP通信，双方地位是对等的，它们的通信也是对称的

方式一：A发报文，得到B的报文，才能再发给B报文

方式二：A给B发一批报文，B需要对每个报文都做应答

真实的通信情况就是方式二

方式二的A的等待时间就可以重叠（跟发送一个报文的等待时间一样，这里只考虑超时重传）

对于方式二：B收到报文的顺序跟A发送的顺序不一定一样，这是因为从A到B的路线，其实有很多种，路径不一样就可能出现，晚出发的报文会早到

B解决乱序问题就可以通过序号来进行重新排序，保证按序到达

B发回的应答报文，也需要有序号，要不然如果有信号丢失，A就没法确定哪个的报文应答丢了，这个序号就是确认序号

确认序号：

收到的序号+1 就是确认序号

含义：该序号之前的所有数据，我全部收到了

假设确认序号是3001，就代表前面的1000 2000 3000 都收到了（注意：3001没有收到）

为什么序号和确认序号要分开成为两个

明明每次使用都只要用到一个序号，另外一个序号用不到，为什么不干脆就用一个序号

发送时只用到序号，应答时只用到确认序号

TCP是全双工的，既然需要发送应答报文，完全可以把要发送的数据也送过去

因为数据可以捎带应答

发送数据和发送确认就可以同时进行了

窗口大小

当接收方的接收缓冲区空间已经不够了，发送方发送的信息太快，接收方来不及接收，剩余的就会扔掉，让发送方重传

这无疑是对网络资源的一种浪费（网络传输也是需要消耗资源的）

就需要进行流量控制

为了进行流量控制，发送方就得知道接收方的接收能力

接收方，如何衡量自己当前的接收能力

接受能力就是接收缓冲区内，剩余空间的大小

发送方如何得知对方的接收能力

报头里面的16位窗口大小，就是用来传递接收方接收缓冲区的剩余大小

标志位

服务端会连接无数个客户端

客户端会发送无数报文给到服务端

有的报文是应答，有的是建立连接的，有的是断开连接，有的是数据报文

这意味着，报文本身是需要有类型的

TCP 协议报头中，就必须有对应的字段表明报文类型

标志位就是用来标识报文的类型（发送啥标志位就是将啥标志位置一）

ACK置1就是应答报文，由于可以捎带应答，所以大部分报文ACK标志位都是1

SYN 叫做连接建立的请求报文，比如客户端要求建立连接服务端

在TCP这里，是通过三次握手建立连接的

发送方需要先发个SYN 给到接收方，接收方表示可以连接，就会发送SYN+ACK，发送方发送应答，发回去ACK

什么是连接

不管是服务端还是客户端（客户端也可以连接多个服务端），双方os内部都会存在大量的连接，os就需要管理多个链接

TCP链接的描述结构体叫做struct tcp_sock，tcp_sock内部的第一个成员为 struct inet_connection_sock，他管理面向连接协议的通用信息，比如：全连接队列、半连接队列、重传策略等等

全连接队列：全连接队列（也叫 Accept 队列，Accept Queue）是 TCP 三次握手完成后，已经建立起完整连接，但还没来得及被应用程序调用 accept() 取走的 socket 所暂存的队列。

半连接队列：半连接队列（SYN Queue）是服务端用于暂存 “只完成了 TCP 两次握手，但还没完成第三次握手” 的连接请求的队列。（客户端还没有发送ack报文的时候）

当完成三次握手，os会创建一个struct tcp_sock 对象，放到监听 fd 对应的全连接队列内，服务端accept的时候再为它分配一个全新的 struct file

为什么要进行三次握手

要通信之前，得保证网络通畅

三次握手能保证发送方接收方各自进行一次发送和接收，验证双方都可以收和发（以最小次数，验证全双工）

两次握手保证不了，只能保证A能发数据和收数据，B只能保证能收数据，发数据保证不了

断开连接需要进行四次挥手

客户端主动发送FIN

服务端发送 ACK（同意断开）

服务端发送 FIN（我也要断开链接）

客户端发送 ACK

为什么要进行四次挥手

四次挥手，是以最小成本的方式，争的了双方的同意

断开连接是双方的事情，双方都需要收到一次FIN

四次挥手之后，连接结构体自然就被释放了，对应的文件结构体也就释放了

客户端主动发送FIN 的意思是，我再也不发了

服务端知道后，表示自己还要发消息，客户端就还会收到消息（结束全双工），直到服务端也表示不发信息了，就断开链接了

在上层的表现就是，双方都调用close()

还出现一种情况，服务端的ACK FIN 一起发给客户端

此时四次挥手就变成了三次挥手

同理，三次握手，也可以变成四次握手

（只不过建立连接时服务器都会无条件答应，所以建立连接和应答永远会压缩在一起，所以不会出现四次握手）

而断开链接时，服务器必须得在条件满足的前提下才能断开链接，所以说是四次挥手

RST标志位

RST 标志位代表“重置连接”（Reset），它的作用是立即、强制地终止一个 TCP 连接，相当于“直接把电话线拔了”。

三次握手时，最后一个ACK有没有被接收方收到是不确定的

发送到接收是有时间差

在客户端角度，只要将最后一次的ACK发出去就算是三次握手成功

而最后一个ACK 是有可能丢的

一旦服务器没收到最后一个ACK，就会重新发 SYN ACK

可是如果客户端认为自己已经链接成功（没有收到服务器发来的syn ack），会给服务端开始发送报文，服务端收到报文之后就会增加 RST 标志位，发送RST报文，要求重新链接

当然，RST标志位还有其它应用场景，要更复杂的多，这里只简单讲述这一个例子

PSH标志位

全称：push

一个极端的例子

如果接收端的接收缓冲区剩余空间大小为0，发送端就得等，可是要等多久是不确定的，发送端需要发送报头（接收缓冲区满了，也可以接收报头，不带数据就行），接收端就需要做应答，就需要重填窗口大小

如果接收端窗口大小一直为0，发送端发送了好几次，也依然是0，就会把PSH设置为1，接收端接收到它就需要立刻通知应用层把缓冲区数据立即取走

PSH标志位同样对发送端起到催促作用

在TCP的正常运作中，默认会使用一种叫 Nagle算法 的机制。它的目的是减少网络上小数据包的数量，提高网络利用率。简单说，它会尽量把多个小的数据块攒在一起，等攒到一定大小再一次性发送。

但这样会导致一种现象：延迟。比如你敲击键盘发送一个字节，Nagle算法可能会等一等，看有没有更多数据一起发，这就产生了延迟。

这时候就可以通过设置PSH标志位，来告诉TCP协议栈：“别等了，立刻把这份数据发出去，别管Nagle算法了”

URG标志位

它是紧急指针

它表示的是16位紧急指针是否有效

如果URG标志位为0，这16位紧急指针就无效

指针：只要具有一定的指向性，就可以叫做指针（比如索引）

这里的紧急指针，代表的就是偏移量

可以把发送缓冲区想象成一个char类型的buffer

每一个字节都有自己的下标（就是上文讲的32位序号的序号）

初始序号真实情况下是随机的序号（不是从0开始的），根据某种算法转成数组下标（就是从0开始的偏移量）

而数组下标就是偏移量

紧急指针：发送的报文数据的某个字节在数组里的下标（通常情况下就是一个字节）

注意：紧急指针里是什么数据根本不重要，它只需要存在，接收方就知道需要发送中断信号

正常情况下，接收端是以先进先出，如果带了URG，接收端就会优先读取对应紧急指针指向的字节

为什么需要有紧急指针

比如正在上传某段资源时，突然要求暂停上传数据，按照正常应该是先上传完，才能读到要求暂停的报文，就需要加上紧急指针，让暂停的报文插队，接收端就会优先读取这个报文

紧急指针的机制需要双方应用层都进行处理

也可以建立两条链接，一个收发数据，一个收发控制命令，就是不使用紧急指针

确认应答机制（ACK）

确认应答是确保可靠性的机制

确认序号就是下一次发送序号的起始序号

一旦发送丢包（不管是数据报文丢了，还是应答丢了），发送方都不能一直等下去，就需要设置时间间隔

一旦超时直接重传

这个特定的时间间隔，不能太短（因为报文传输也需要时间，会导致频繁重传报文）也不能太长

这个特定的时间间隔是浮动的，跟网络的健康程度有关，因此会选择动态计算这个最大超时时间

等待时间就是 500ms*2的n次方-1

n为重传的次数

意思就是第一次会等500-1ms，第二次就会等500*2-1ms，直到重传次数达到一定程度，发送端tcp就会认为网络或者对端主机出现异常，强行关闭连接

流量控制

简单来讲就是发送端利用接收端的发送过来的窗口大小来控制自己发送报文的速度

发送端不能过多依赖重传机制（就是一股脑全发出去，不管接收方有没有能力全部接受完，准备丢啥就传啥），因为依赖重传会导致电力、带宽等资源的浪费，网络传输也是需要消耗资源的

一般窗口大小就是2的16次方，但在如今64KB已经太小了，就需要有一个窗口扩大因子（这个窗口扩大因子M 就在tcp首部的选项中，所以实际窗口大小是窗口字段的值左移M 位）

滑动窗口

tcp具有可靠性，就意味着一个报文，一旦把它发送出去了，在收到应答之前，这个报文都不会被发送方丢弃，这个丢弃的时间点，应该在收到应答之后。就意味着，发送的数据会持续留在发送缓冲区内部，直到收到应答报文

同时为了效率，发送端tcp往往会选择一次性发送一批报文，假设一个报文携带1460字节（初始序号这里假设为0），总共要发送9000字节，发送端会根据窗口大小（这里假设接收端剩余空间大小为4000字节），就会一次性发送三个报文（1460、1460、1080），序列号分别为0，1460，2920。发送完成之后，发送端tcp就会等待不再发送直到接收方传来ack

而滑动窗口，指的就是这个根据窗口大小，在发送缓冲区内划定的这个区域（就是这个大小为4000字节的区域）

每一次发送，都会发送滑动窗口内的一批报文