跳到主要内容

前言​

TCP 建立连接是三次握手，而断开连接是四次挥手。

但事实上从你打开这篇文章，到关掉这篇文章，你是看不见这个过程的。

那 TCP 建立连接和断开连接的过程是不是真的如大多数文章所描绘的一样？

带着这些疑问，那就不如真正去实战看一下。

为了能“看见”TCP，我们需要借助 Wireshark 分析网络的利器。

Wireshark 是 Windows 最常用的网络抓包和分析工具，称得上手好剑大利器把我们对数据包一目了然。（也是分析网络性能必不可少的利器）

如果是在 Linux 上网络抓包，那可以使用 tcpdump。

（分析网络的工具还有很多，但是工具只是手段，重要的是能实现目的）

————《用 Wireshark 让你看见 TCP 到底是什么样！》

看得见的 TCP 的三次握手过程是什么样？​

如下图模型所示， TCP 建立连接过程三次握手是这样。

在 Wireshark 中我们对请求网址后，可以使用表达式，筛选出网址源地址和目标地址对应的请求信息。

ip.dst == xxx.xxx.xxx.xxx or ip.src == xxx.xxx.xxx.xxx

如下图所示，筛选后如下，就可以清楚的看到 TCP 三次握手的信息。

通过直接看标志位来看三次握手的数据包，第一个数据包标志位 SYN 是第一次握手；第二个数据包标志位 SYN,ACK 是第二次握手；第三个数据包标志位 ACK 是第三次握手。

微信截图_20221128020837.png

（注意：如果你用 Wireshark 抓包程序看 3 次握手，你会发现 SeqNum 总是为 0，是因为 Wireshark 为了显示更友好，使用了 Relative SeqNum——相对序号，你只要在右键菜单中的 protocol preference 中取消掉就可以看到“Absolute SeqNum”了）

第一次握手​

A主机发送一个请求的数据包，并将SYN （建立连接时的同步信号）置为1 ，seq置为 0 ，表示A主机请求建立连接。

image.png

我们可以再通过TCP 三次握手确认的信息图示，来看A主机和B主机在三次握手中请求和接收的能力。

A主机向B主机第一次请求时，所能确认的事情，只有在B主机知道，B主机一旦确认接收到了对方的请求，那么也就确认了自己具备接收和对方请求的能力。如下图所示。

微信截图_20221129132020.png

第二次握手​

B主机收到A主机发过来的请求数据包后，通过SYN得知是一个建立连接的请求，于是响应一个确认数据包，并将 SYN 和 ACK （对收到的数据进行确认，即表示响应） 状态都置为 1。

并且将确认序列号 ACK 设置为序号 seq = 0 + 1 = 1，表示B主机收到A主机发过来的SYN。如下图示。

51b3e9827c339b8c9907a8c3739076b.png

而在到了第二次握手后，A主机就可以确认自己和对方的请求的能力，但B主机还有两个信息无法确认，自己的请求和对方的请求。

微信截图_20221129132850.png

第三次握手​

A 收到B的响应包后需确认序号ACK是否正确，如果正确，A主机会再向B主机发送一个数据包，数据包中将SYN置为 0， ACK 置为 1，并将确认序列号设置为 y+1 = 1，表示收到了来自 B 的 SYN。于是，A和B两端就TCP建立起三次握手的连接。

36b388e69d783cb99a1d478155ec2ad.png

如下图可以直观看到在第三次握手后，B主机就能确认自己的请求和对方的接收都是正常的。

微信截图_20221129133132.png

为什么需要三次握手？两次可以吗？​

这是一个好工程师，会提出想要优化的好问题。

这要说到在 IP 数据包中历史存在的问题，IP 数据包在发送时，为了防止出现数据包不断在网络上永不终止地循环和收发，所以在数据报文中会加上数据包报文的生存时间，也就是 TTL（time to live） 来解决这个问题。

但是在TCP中，网络报文的生存时间往往会超过TCP请求超时的时间，如果两次握手来创建连接，传输数据并释放连接后，一旦第一个超时的连接通过重试机制后，请求才到达 B 主机的话，那么 B 主机会以为是 A 创建新连接的请求，然后确认同意创建连接。就会直接导致A主机丢弃了 B 原来的确认数据，最后只有 B 主机方面创建连接完毕。

所以两次握手会请求超时导致的脏连接，而三次握手可以防止超时，同时保证信息对等。

看得见的 TCP 的四次挥手的过程是什么样？​

微信截图_20221126021753.png

接着TCP如果断开连接， Wireshark 自然也不会放过，可以看到如下图所示。

（会发现对应上图模型是不是就很具体了）

31355904e191902922ebb6fe3520882.png

第一次挥手​

A主机想断开连接，则在数据发送完毕后，传递FIN（表示关闭连接）信号给B主机。FIN和ACK置为 1，序号seq=X=4335，确认序号ACK=Z=10615.

c63f3ad07a9f342b119488c9b97f4a3.png

第二次挥手​

B 主机收到FIN后，则响应 ACK，告诉 A 主机可以断开，seq序号=确认序号ack=10615；并将ACK=1

image.png

第三次挥手​

B 主机做好连接关闭前的准备工作后，发再次发送FIN给A主机，此时B主机也进入半关闭状态。因为A主机可能还有没发完的数据，所以需要等B主机发送完数据会发送一个FIN + ACK进行最后的确认。

第三次挥手的序号和确认序号不需要改变，只是多了一个FIN来确认结束。

023789eca3c586172cfc3e0d25e57e3.png

第四次挥手​

A主机收到B主机的FIN后，会发送ACK来确认后会进入TIME-WAIT状态，经过2MSL(Maximum Segment Lifetime)后，没有收到B主机传来的报文，则确定B 主机已经收到A主机最后发送的ACK 指令，此时TCP连接正式释放。

image.png

最后​

好了，这些天就到这里了。但 TCP 还有很多东西，除了各种实现可靠的机制和治理交通似的算法，而且还有很多优化和变种。

想想到如今车一旦多起来，交通还是面临很多问题，你就知道 TCP 好像没那么简单了。

所以 TCP 的文章也相当多，但是不是真的是这样？就不如实际去看看。

计算机本就是一个实践性很强的的学科啊。

纸上得来终觉浅，绝知此事要躬行。

我是一颗剽悍的种子，怕什么真理无穷，进一寸，有进一寸的欢喜。感谢各位伙伴的：关注、点赞、收藏和评论 ，我们下回见！

创作不易，勿白嫖。

一颗剽悍的种子 | 文 【原创】

信息

作者：一颗剽悍的种子 链接：https://juejin.cn/post/7171621641837871112 来源：稀土掘金 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。