TCP握手/挥手的过程

详解：

1. tcp报文里有个syn位，第一次握手syn位置1
2. 第二次握手，ack和syn位都置1（报文编号为第一次编号+1）
3. 第三次握手：客户端回应服务器的连接请求（报文编号为第二次+1）

为什么3次握手？（为什么不能改成两次）
假设我们不进行第三次握手，（这导致整个过程中，服务器不再能确认对方是否接收正常，自己发送是否正常）

我想的是：如果规定仅仅为前两次握手，那么在第二次握手信号丢失的情况下，客户端就不能确定自己收发正常，也不能确定服务器收发正常。这个时候可以设定客户端重发第一次握手信号，这样一来两次握手就可以了啊
实际上：这样只能让客户端确认一切正常，服务器始终没确认自己发送是否正常，也无法确定客户端的接收是否正常

为什么四次挥手？
任意一方A调用close，底层发出fin关闭请求（第一次挥手）
B放方收到A方fin请求，B方立刻回复ack（第二次挥手）（编号为第一次挥手+1）
B方应用层receive收到0长度数据包，导致B方调用close，导致发送给A方fin
A方再回复ack（编号为第三次挥手编号+1）

问：为什么ack和fin不合在一起？
时间差问题，由于recv收到0长数据报才发送fin，但当B第一次收到fin就可以发送ack

第一次close半关闭，当A方发送完第二个ack，彻底关闭；在第一次关闭时，应用层不再能send，但底层还可以发送，接收

如果在四次挥手过程中，在A刚发送了FIN，B就被ctrl+c则导致，无法bind。（因为没被完全释放，bind时会显示原端口已经绑定）
5，6分钟之后会自动释放
（原因：为了防止服务器在运行过程中重启，宕机时，再启动还需要重新连接。）

参考：https://blog.csdn.net/qq_28959087/article/details/104715030