HTTP释放连接时候的4次握手理解

要说明一下：SOCKET接口是TCP/IP网络最为通用的API，也是在INTERNET上进行应用开发最为通用的API。SOCKET是双工通信协议，而我们的通信几乎都基于Socket来实现的。

HTTP 的3次握手是准备资源的过程；HTTP 的4次握手是释放资源的过程；

HTTP 的3次握手（建立连接时的确认机制）：按照双工通信协议，建立连接时候，也应该是4次握手的，只是为了提高通信效率，将第二次和第三次的通信合并成一次通信完成，所以就变成了3次通信了。

HTTP 的4次握手（关闭连接时的确认机制）：关闭连接就不能像3次握手那样合并通信了。
由于是双工通信，客户端和服务端各自都有 “发送”、“接收” 机制；
4次握手过程如下：
1，客户端发起第一次通信要关闭连接（其实是在告知服务端我要关闭 发送功能了）；
2，服务端接收到客户端的第一次请求后，就立马返回给客户端：我知道了。（第二次通信发出了）。于此同时服务端就会通知自己内部程序关闭接收功能；
3，服务端的内部程序知道自己的接收功能都关闭了，那么自己的发送功能也就没用了，就给客户端发通知，我也关闭发送功能了（第三次通信发出了），此时服务端并没有立刻马上关闭发送功能，而是做了一个等待客户端来信的超时机制；
4，客户端接收到服务端的要通知后，也会回复服务端：我知道了（第四次通信发出）。但是此刻客户端不会立刻马上关闭接收功能，也做一个超时机制，而且这个超时机制的时间是服务端那个超时机制的2倍时长。

解释一下超时机制：
第三次握手的超时机制是为了等待确认客户端的来信，如果在设定的时间内没有接到客户端的来信，就再给客户端发送一次通信。
第四次握手的超时机制（而却是2倍时长）是为了确保最后的一次通信能通知到服务端。

假如客户端出现了宕机，那么服务端一直会发送通知，并且等待吗？
答案是不会。当超过一定的重传和时间后，又或者出现通信校验错误都会触发TCP的reset报文机制释放资源。
（关于TCP异常终止 reset报文情况可以参考这两个博客：
http://www.vants.org/?post=22
http://blog.sina.com.cn/s/blog_62d5e6cd0100me16.html
）

此时对于第四次握手超时机制2倍时长一种现象假设：如果第一次握手发送通知的是服务器端，那么就会造成第四次握手的2倍超时等待时长会发生在服务器端，那么这个应用的端口久会释放的比平常要晚一些。此刻我也就想通了：有时候应用程序明明都停止运作了，可是端口还是不能立刻释放的情况了。

无论是3次握手，还是4次握手都是HTTP底层运作，虽然对于使用者来说都是无感知，我觉得还是有必要再挖一下比较好。

另外这个文章写的很好：https://baijiahao.baidu.com/s?id=1618114723935605183&wfr=spider&for=pc