前言
关于这个问题，网上有很多教程和博客，都大同小异。但我看了之后，并不认同。那些复杂的解释给我一种“看着答案推过程”的牵强感觉，经不住推敲。
一，连接为什么是三次握手，而不是两次握手
一次就不讨论了，连一个来回都没走，根本就验证不了两个方向的通路
我的解释：不是三次握手，而是四次握手。
只不过是第二次和第三次 因为是同一个方向，合并了。所以呈现出三次的结果。
目的就是：我问你答，你问我答，保证两个方向的“来回”都是通的。
注意：是来回，也就4次。即便是同一个方向，也要双方都走一遍才算通。就像是一条简单的路，给路痴去走，他就可能走不通。
而按照网上那些猜疑链的复杂说法，那得“无数次”握手（大家仔细想想是不是）
二，断开为什么是四次（断开和开启有什么区别）
我的解释：逻辑上，连接是瞬时的，（服务器）断开是一段时间。
为什么？有人就不认同了，如果说断开需要清理各种资源，那开启连接还需要创建各种资源的，时间上可能比断开还要更长呢。
没错，连接确实可能比断开时间还要更长。但连接和断开有个逻辑上的区别：触发连接之后，无论是客户端还是服务端“都是活的”，两边有能力有时间处理任何异常。 但断开就不一样了，自己断开，就相当于“自行了断”。
如果你想记录自己“自行了断”的全过程是，是不可能的。因为你没了，后面什么事也做不了了。保证开启，我们理论上有“无限大好时光”可以利用。但保证关闭，就得精心设计，来保证全程不会出现任何差池。
所以从逻辑上说，
开启：双方给个信号 提示一下，只要能确定路通了就行。
关闭：双方（主要是复杂的服务端）必须要全程处于另一方的监控之下完成，而客户端很简单，不太需要另一个人监控完着成断开（两个人总有一个先挂，另一个人最后孤零零的走）。
下面给一个时间分配图：
如果这一条长柱看成整个tcp的时间段的话，那么开启连接的过程就是那一条绿线，黄色的是大段的传输过程，蓝色是断开的过程。
这里把“开启”和“连接”作为一个意思，是因为：所谓开启，就是连接上，就是把开启的信息告知对方，就是打个电话告诉对方，我接下来要干什么事了。所以“打电话”相对于全过程，可以抽象为“一个时间点”。tcp断开之前也是要先连接上，告知对方我要断开了。断开这段蓝色的时间，就是服务器分两次回应的时间段。
下面说网上解释的不合理：
服务端接受到客户端端关闭消息之后，可能还还有数据要传输，所以先给个回应，确认没问题了 再次给个确认。
那我就不明白了：你还有shi没拉完，刚才怎么不说，就不能在第一个回应里就一并说了，还非要分两步。
而且大家有没有想过这个问题：客户端是什么时机选择的发送“断开连接”但请求的。它是脑子一热就跟服务器说拜拜？当然不是。就好像你拉shi拉一半，马桶突然告诉你 我要下班了，怎么可能。肯定是你说我拉完了，然后马桶才会给你发出准备关门的消息。在计算机世界里，能一步完成的事情，绝不会多此一举分成两步（通过消息长度判断，传输完成 是双方都已经知道的事情）。
服务器之所以先给个回应，然后再给个回应。那是因为在这两个回应之间是服务器关闭资源的时间（关闭的时间也许比较长）。第二个回应之后，服务器彻底安全关闭。这个过程相当于全程被客户端监控着。
反过来想想：如果服务器还没完全关闭，就给了回应，客户端就信了，然后也关门走人了。结果服务器没关上，客户端此时早已人去楼空，只剩下服务器这边孤立无援。
但这种情况在开启的时候就不会出现：服务器如果没开启成功，但客户端就站在那里。哪怕它在发送数据的时候发现 其实服务器根本没开启成功。那又如何，再重新请求一次呗。反正人在这里就好，有问题都可以解决。一旦另一方人走了，那服务器就彻底凉凉。 这就我前面为什么说：开启可以抽象为“一个瞬时的点”（因为开启的过程，理论上可以融入传输数据的过程中），而关闭是一段时间，必须安全完整处理。