TCP三次握手与四次挥手！

最近闲来无事，看书温习下TCP的底层知识，比如三次握手之类的原理，再次发现网上有太多误导人的东西，太多的原理图都是错，竟然有很多的图在四次握手时主动方只发给被动方一个FIN，唉。。自己动手去证明吧，再网上找了俩个自己感觉比较正确的图，在后抓包测试下，结果还是挺有收获的。

三次握手：

在客户端第二次回给服务器时，ACK一定是等于Y+1的，而不是像有些图上面画的，是个Z(一会有图证明).

四次挥手：

这里，在俩次FIN包发送的时，一定是[FIN,ACK]一起的。

废话不说，用WIRESHARK抓包如下：

说明：

我本机是客户端，连接了60000端口的服务器，然后向服务器发送了三次数据，111，222，333，然后断开。

我将重要的数据制成EXCEL，方便分析，如下：

第一部分是三次握，第二部分是发送的111，222，333，第三部分是四次挥手。

其实在三部分中，序列号sequence和acknowledgement的生成规则是不一样的。

总结如下：

1.在三次握手中，ACK=Squence+1

2.开始发送时，发送方是按三次握手完成时定下的序列号和ack来进行通信的，如上面第4行与第3行是一样的。但若在第4行是服务器先发送的数据，则第4条应该是：

   s->c  seq=af f9 51 2a   ack=27 4d e9 63 ，即开始发送数据时，无论谁先发送，seq都不累加，因为对于收数据这个动作来说，它和三次握手不一样，它seq是用来标识所收的数据的，即没有数据就不对seq累加，从4-9行不难看出，客户端一直在发，客户端的seq不断的按发送字节数在累加，而服务器是应答端，seq始终不变。同理若客户端作为应答端的话，它的seq也是不变的。这个规律在之前没抓包的时候我一直以为seq都是在累加的，其实不是。

3.四次挥手时

10-13行中，12行的seq和ack与11行一样。这里一定要记住一个规则：seq的生成一定要参考上一条的数据。在这里12行要参考的应该是10行，而不是11行，因为第10行的ack表明，客户端希望服务器下次用af f9 51 2a这个序号，那么在客户端状态未改变时，服务器无论发送多少条都应该用这个号发送（当然不可能夹杂很多条的，都是一发一回答），总之，在10-12行之间，只要c->s的状态不改变，那么服务器就应该遵循c->s想要af f9 51 2a这个序号的意愿。其他发送方式都遵循此规则-------这也就解释了为什么第4行与第2行一样了，因为第4行参考的是第二行，在2-4行之间，s->c的意愿并未改变。

最后再次吐槽下CSDN，你允许我CTRL+V到编辑栏，保存时又没有图，你搞毛线呢，唉。