本文为社区首发签约文章，14天内制止转载，14天后未获授权制止转载，侵权必究！
纸上得来终觉浅，绝知此事要躬行。
《如果把网络原理倒过来看，从无到有，一切都明晰了（上） 》
《如果把网络原理倒过来看，从无到有，一切都明晰了（中） 》
《如果把网络原理倒过来看，从无到有，一切都明晰了（下） 》
《用 Wireshark 让你看见 TCP 到底是什么样！》
前言
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 是第2次握手；第三个数据包标志位 ACK 是第三次握手。
（注意：如果你用Wireshark抓包程序看3次握手，你会发现SeqNum总是为0，是因为 Wireshark为了显示更友好，运用了Relative SeqNum——相对序号，你只要在右键菜单中的protocol preference 中取消掉就能够看到“Absolute SeqNum”了）
第一次握手
A主机发送一个恳求的数据包，并将SYN （树立衔接时的同步信号）置为1 ，seq置为 0 ，表示A主机恳求树立衔接。
咱们能够再通过TCP 三次握手承认的信息图示，来看A主机和B主机在三次握手中恳求和接纳的才能。
A主机向B主机第一次恳求时，所能承认的事情，只要在B主机知道，B主机一旦承认接纳到了对方的恳求，那么也就承认了自己具备接纳和对方恳求的才能。如下图所示。
第2次握手
B主机收到A主机发过来的恳求数据包后，通过SYN得知是一个树立衔接的恳求，于是响应一个承认数据包，并将 SYN 和 ACK （对收到的数据进行承认，即表示响应） 状况都置为 1。
并且将承认序列号 ACK 设置为序号 seq = 0 + 1 = 1，表示B主机收到A主机发过来的SYN。如下图示。
而在到了第2次握手后，A主机就能够承认自己和对方的恳求的才能，但B主机还有两个信息无法承认，自己的恳求和对方的恳求。
第三次握手
A 收到B的响应包后需承认序号ACK是否正确，如果正确，A主时机再向B主机发送一个数据包，数据包中将SYN置为 0， ACK 置为 1，并将承认序列号设置为 y+1 = 1，表示收到了来自 B 的 SYN。于是，A和B两头就TCP树立起三次握手的衔接。
如下图能够直观看到在第三次握手后，B主机就能承认自己的恳求和对方的接纳都是正常的。
为什么需求三次握手？两次能够吗？
这是一个好工程师，会提出想要优化的好问题。
这要说到在IP数据包中历史存在的问题，IP数据包在发送时，为了避免出现数据包不断在网络上永不终止地循环和收发，所以在数据报文中会加上数据包报文的生计时刻，也便是 TTL（time to live） 来处理这个问题。
可是在TCP中，网络报文的生计时刻往往会超过TCP恳求超时的时刻，如果两次握手来创立衔接，传输数据并开释衔接后，一旦第一个超时的衔接通过重试机制后，恳求才抵达 B 主机的话，那么 B 主时机以为是 A 创立新衔接的恳求，然后承认赞同创立衔接。就会直接导致A主机丢掉了 B 原来的承认数据，最终只要 B 主机方面创立衔接结束。
所以两次握手会恳求超时导致的脏衔接，而三次握手能够避免超时，一起确保信息对等。
看得见的 TCP 的四次挥手的过程是什么样？
接着TCP如果断开衔接， Wireshark 自然也不会放过，能够看到如下图所示。
（会发现对应上图模型是不是就很详细了）
第一次挥手
A主机想断开衔接，则在数据发送结束后，传递FIN（表示封闭衔接）信号给B主机。FIN和ACK置为1，序号seq=X=4335，承认序号ACK=Z=10615.
第2次挥手
B 主机收到FIN后，则响应 ACK，告知 A 主机能够断开，seq序号=承认序号ack=10615；并将ACK=1
第三次挥手
B 主机做好衔接封闭前的准备工作后，发再次发送FIN给A主机，此时B主机也进入半封闭状况。因为A主机可能还有没发完的数据，所以需求等B主机发送完数据会发送一个FIN + ACK进行最终的承认。
第三次挥手的序号和承认序号不需求改变，仅仅多了一个FIN来承认结束。
第四次挥手
A主机收到B主机的FIN后，会发送ACK来承认后会进入TIME-WAIT状况，通过2MSL(Maximum Segment Lifetime)后，没有收到B主机传来的报文，则确定B 主机现已收到A主机最终发送的ACK 指令，此时TCP衔接正式开释。
最终
好了，这些天就到这里了。但TCP还有许多东西，除了各种完成可靠的机制和治理交通似的算法，并且还有许多优化和变种。
想想到如今车一旦多起来，交通还是面对许多问题，你就知道TCP好像没那么简单了。
所以TCP的文章也相当多，可是不是真的是这样？就不如实际去看看。
计算机本便是一个实践性很强的的学科啊。
纸上得来终觉浅，绝知此事要躬行。
我是一颗剽悍的种子，怕什么真理无量，进一寸，有进一寸的欢欣。感谢各位同伴的：关注、点赞、保藏和谈论 ，咱们下回见！
创作不易，勿白嫖。
一颗剽悍的种子 | 文 【原创】
