传输层协议：TCP

报头
源端口号和目的端口号
4位首部长度
[ACK 确认应答机制](#ACK 确认应答机制)
序号和确认序号
捎带应答
超时重传
连接管理机制
- 三次握手
- RST
- 为什么要三次握手（面试常考题）
- 四次挥手
- TIME_WAIT
流量控制
紧急指针
滑动窗口
拥塞控制
延迟应答
面向字节流
- 粘包问题
TCP异常情况
TCP小结
基于TCP应用层协议
TCP/UDP对比
UDP实现可靠性

报头

TCP（Transmission Control Protocol）是一种面向连接的、可靠的传输层协议，位于OSI模型的第四层。它通过三次握手建立连接，确保数据有序、无差错地传输，并提供流量控制和拥塞控制机制。

我们学习TCP的各种其实就是学习其报头的：

那么现在我来逐个讲解其报头含义。

源端口号和目的端口号

这两个应当是非常直接的。TCP/IP模型采用五元组的形式标记一个通信，其中就需要到源端口号和目的端口号。

4位首部长度

除了选项以外 就是我们TCP报头的基本大小，他是固定的20字节。但是选项的大小是不固定的，可以没有也可以有。因此我们需要一个数据记录报头的大小，这个数据就是4位首部长度。

4位首首部长度的基本单位是4字节，因此它可以表示0-60字节。这说明没有选项时，默认的首部长度位0101。选项最多为40字节。

ACK 确认应答机制

在保证TCP可靠的机制中，确认应答机制是十分重要的一个。

我们在日常生活中聊天：

当我们向对方发起聊天时，并不能确保对方听到了我们说的话，我们需要对方的应答如语言应答：

这时候左边就知道对方听到了他说的第一句话，但这时候问题来了，右边无法确定左边是否听见了自己的应答。因此左边又要对右边进行应答：

同样的，对方也要应答左边的这句话，才能让左边确保对方收到了信息。

这样就陷入了死循环，也就是实际通信过程中，总有最新的一条应答是无法保证有效的。

于是我们考虑不保证应答，只保证收到应答的单边通信情况：

如上我们只考虑客户端向服务器单方向发送信息的情况时，我们只需要客户端收到服务器的应答就能确保服务器一定收到了客户端的信息，这样就确保了单向的可靠性。我们无需确保服务器知道客户端一定收到了应答。

双向通信的时候也是类似考虑。

这就是确认应答机制。报头中的ACK，即Acknowledgement标记位就是标记这组报文是否为应答报文。

序号和确认序号

我们TCP通信有两种情况，一种是上述的串行发送：

也可以是并行发送：

也就是客户端在等待应答的过程中也可以继续发送信息。事实上，这种发送情况才是常有的。

但这时就有一个问题，我怎么知道你的应答是对应哪一条发送信息呢？

因此我们需要给发送信息和应答一个标记。

首先是发送信息时，由于TCP是面向字节流的，发送信息时可以给数据的每一个字节一个编号（从1开始），这个就是序列号。

发送数据方要在报头的序号部分填发送数据的最后一个字节的序号，ack则要在确认序号部分填上收到的序号+1.

例如：客户端现在要发送3000字节的数据给服务器，分三次发送，因此三次发送的序列号分别就是1000，2000，3000.服务器要回应的确认序号就是1001，2001，3001：

这里还有一些确认序号代表的是确认序号前的数据已接收，例如1001就代表已经接受了前1000个序号的数据。

这意味着，如果1001-2000的数据丢失，服务器只收到了1-1000和2001-3000的数据，应答报文的确认序号就只有1001.

同时序号和确认序号的存在告诉我们每次通信传输的数据有一个绝对上限：2³²Byte=4GB，不过正常也用不了这么大。

捎带应答

刚才我们的序号机制和确认序号机制，明明可以只用一套序号，为什么非要搞两个序号出来，这不浪费存储吗？

实际上，我们刚刚讲的都是单向通信，但是我们实际情况是经常出现双向通信。当客户端向服务器写入数据时，服务器也能向客户端写入数据。

这时候就能将服务器要发送的数据和应答报头合并，这样能节省一个报头的通信开销，提高效率：

ps：这里报头少打了个RST

如上服务器向客户端发送200字节的数据捎带应答客户端发送的1000字节数据，就可以在序号里填200，确认序号里填1001.

这就是捎带应答机制。

超时重传

客户端向服务器发送数据没有收到应答有两种情况，一是数据丢失：

二是应答丢失：

可不管是哪种丢失，在TCP协议看来，没有应答=没收到数据。因此在发送数据之后tcp内部就会维护一个倒计时，当这个数段内没有收到应答就会重复发送。

所以服务器是很容易收到重复数据的，再根据前面的序号我们就能实现数据去重。

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

• 最理想的情况下,找到一个最小的时间,保证"确认应答一定能在这个时间内返回".

• 但是这个时间的长短,随着网络环境的不同,是有差异的.

• 如果超时时间设的太长,会影响整体的重传效率;

• 如果超时时间设的太短,有可能会频繁发送重复的包;

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

• Linux中(BSDUnix和Windows也是如此),超时以500ms 为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.

• 如果重发一次之后,仍然得不到应答,等待2500ms后再进行重传.
• 如果仍然得不到应答,等待4 500ms进行重传.依次类推,以指数形式递增.

• 累计到一定的重传次数,TCP认为网络或者对端主机出现异常,强制关闭连接.

连接管理机制

TCP的连接管理机制也是其非常复杂的一套机制，正常来说TCP要经过三次握手建立连接，四次挥手断开连接。

三次握手

我们先看三次握手过程：

这里CLOSED、LISTEN、SYN_SENT、SYN_RCVD、ESTABLISHED都是内核维护套接字和连接关系中，连接的状态。总之就是一个宏定义的状态。

联测对用的时应用层的逻辑。

首先通信双方建立连接必须征得双方的意愿。

因此建立连接发起方（通常是客户端）就会在TCP报头上标记SYN（Synchronize Sequence Number，同步序列号），发送给远端，并将连接状态标记为SYN_SENT。

服务器收到了客户端的连接请求，此时服务器是LISTEN状态，属于是来者不拒，因此他必定同意建立连接 （这里就区分断开连接时不是必定同意），必定会应答。同时他也要发送请求建立连接，因此用到捎带应答机制，同时给SYN和ACK标记。

注意当客户端收到了服务器的ACK之后，连接状态就标记成了ESTABLISHED，意思是客户端认为连接已经建立。而服务器要等到客户端的ACK才能确定连接建立。
客户端和服务器的连接建立有时间差

这意味着三次握手其实在赌最后一次ACK对方一定收到了。

这里还要说明一下，三次握手是内核级操作，connect和accept这些函数不参与三次握手，只是发起者。也算是一种常见的黑箱机制。

RST

三次握手真是一场豪赌，但要是真的没有收到最后一次ACK呢：

这时候客户端认为已经建立连接了，就会发送数据。当服务器接收到数据就会知道，对方以为连接建立了，因此服务器会发送应答+重新建立连接的请求，也就是ACK+RST：

这时客户端收到RST就会开始重新三次握手。

不止这个场景。网络通信什么意外都有可能发生，意外断开连接常有，所以RST也是常有的事。

为什么要三次握手（面试常考题）

其实我们已经知道为什么要三次握手，但脑子里没有一个系统的答案，我这里来谈谈原因。

首先讲一个不是重要的原因，就是一次握手和两次握手有明显的缺陷。

我们知道内核要维护连接状态，因此要消耗一定内存。

如果客户端发送一堆SYN请求，（SYN洪水），就会消耗服务器的大量空间维护连接状态。

三次握手并不能有效防止 SYN洪水，但能避免这么明显的缺陷。

事实上TCP协议防止SYN洪水的，TCP防止SYN洪水核心机制是SYN Cookie。这里就不详谈。

我们现在来说说三次握手的原因：

验证全双工--验证网络连通性
仔细观测三次握手的过程：

可以看到我们用了最小的通信次数，确保了通信双方都有接收和发送信息的能力。
建立双方通信的共识意愿
一开始我就说了，建立连接要征得双方同意，三次握手就是用最小的通信次数得到了双方的通信意愿。

四次挥手

三次握手之后双方连接状态都是ESTABLISHED，进入正常通信。通信结束后要断开连接就要发起四次挥手，我们来看看四次挥手的过程：

可以看到四次挥手过程的连接状态变化比三次挥手要复杂，我们要详细理解每个状态的变化。

首先是close(fd)会发起四次挥手，即发送FIN报文：

那么我们要收到对方ack对不对？问题来了，我的文件描述符都关闭了怎么收到应答报文？

这里又要回到TCP怎么实现全双工了：

是的，TCP通信过程中有两个内核缓冲区。close(fd)之后首先只是关闭了发送缓冲区，此时发送缓冲区是只读的。那么对应的连接状态就是FIN_WAIT_1。

此时客户端只有两件事还要做：等待ACK和等待服务器FIN报文。

当收到ACK时，客户端就从FIN_WAIT_1变成FIN_WAIT_2，只需等待服务器FIN报文。

那么问题来了，为什么服务器发送ACK和FIN不用捎带应答机制？就是为什么不是三次挥手而是四次挥手？

这里要明确FIN的含义是：我的资源发送完毕，将来不会发送其他资源。意味着只是不发资源，不代表不接受资源。

关闭连接也是要双方同意的，服务器可能还想继续发送数据。

因此第二次挥手和第三次挥手之间，服务器还可以继续发送数据，此时服务器的连接状态时CLOSE_WAIT意味着，远端不会再发送资源。

这时服务器发送数据完毕，就会发送FIN报文，并且本身进入LAST_ACK状态，等待对方应答？

这里又有一个问题，服务器要是不主动调用close呢？

此时客户端会不会阻塞无法关闭连接？

答案是否定的，客户端会有其他手段强制进入TIME_WAIT状态，如

shutdown强制关闭连接。

或者在报头加上SO_KEEPALIVE选项。

因此客户端一定会关闭连接。
服务器会不会阻塞无法关闭连接？

答案是会。如果服务器没有close，那么就会出现文件描述符泄漏等现象，也是一种严重的内存泄漏。

最后，服务器收到ACK就会关闭连接。

因此，如果问你为什么要四次挥手，那就是用最小的通信成本确保了双方的断开连接的意愿。

注意客户端在收到第三次挥手时，连接状态没有进入CLOSED状态而是TIME_WAIT状态。