tcp/ip 协议之三次握手

     最近在沉淀往期一些懵懂的知识点，比如就http协议，作为一枚服务端开发，整天接触比较多的就是http的请求接口，然后返回个json数据，经常听到运维在群里反馈哪个机器出现丢包的现象，丢包应该是出现在http的访问上吧。

     正常随便抓个服务端程序员问，都应该接触tcp/ip的建立是经过三次握手，关闭的时候经过4次握手，今天看到一篇文章说 那知道为什么要这么设计吗，知其然也要知其所以然。

    我自己的本土化理解是 client要连接server，必须先向server发送个握手，比如

        问server "你在吗",     然后server收到后，回复说"我在"，

       这样client就可以确认server是正常的，

          接下来server也要确认一下client是否正常，也会问client "你在吗",然后client回复"我在"，server就确认client是正常的

上述描述可以理解为如下操作，但是当前是四次操作，不急，听我慢慢讲来

（备注下专业术语 ）

SYN 表示 synchronize，在建立连接时使用；

ACK 表示 acknowledge，表示“确认”收到了消息；

 在tcp/ip进行握手，为了节省网络通讯时间，（上图从上往下每条横线代表1234），我们发现第2步和第3步都是发现同一个方向，那么我们就会想是否可以合并呢，答案是可以的 ，然后就是我们常说的三次握手了，其实是四次减一了，（这个时候就突然想到为什么关闭是4次呢，很好奇吧）

如上图，网易通讯就少了1次，并且可以完成所需的功能。 当然握手肯定不是问你在不在，而是如下，根据状态传值的

  == 

===== 预留个坑，关于tcp的数据包，看着感觉有点难度，需要花时间再去处理

 

最后是关于关闭tcp的，如何正确关闭，肯定不是想关就关的。关闭是需要经过4次握手。为什么是4次

通常的答案都是：TCP 是双向通讯协议，要结束连接，双方都必须发送终止信号，告诉对方后续再没有数据发过来了，并等待对方确认，所以一共需要2+2=4 次。

FIN 表示 finish，在断开连接时使用。

 

客户端向服务端发送 FIN，表示“我这边不会继续发送数据过来了”，服务端响应 ACK，这都没有问题。但此时，服务端之前向客户端发送数据的操作可能还没有完成，服务端仍然在向客户端传输数据。如果服务端把 FIN 和 ACK 合并起来，就会出现这样的情况：客户端的数据还没有接受完，忽然收到服务端的消息“后续没有数据了，终止连接”。显然，这种情况不应当出现，所以不能把 ACK 和 FIN 合并在一起，所以终止连接必须要四步