一说起TCP，很多人立马就能想起三次握手和四次分手。
更有记忆力强者，能把整个状态变迁图记下来。
但是说起为什么要有这些机制，就不太好答上来。
下面以一个例子分析三次握手和四次分手的过程。
打个比方，你和同事在早上相约中午去xx餐厅吃饭。
由于工作比较忙，双方有可能看不到对方发的消息。
所以你们约定：
- 在看到对方发的消息时，就回复一条收到。
- 如果对方没有回复收到，自己就重新发一次。
12：00，你给同事发了一条消息：我准备去吃饭了
如果你的同事刚好活已经干完，那么会回复：收到。我也准备去吃饭了。
然后你再回复一次：收到。
看起来就像是TCP的3次握手。
但是假如你的同事在收到你的第一条消息时，工作还差一点未完成。
那时他就只能回复：收到。
而此时你看到回复之后，你只能确认对方确实收到了你的消息，而不能确认对方已经准备好了和你一起吃饭。
假设过了10分钟，你的同事把工作做完，给你发送了一条消息：我也准备去吃饭了
你回复：收到。
如此你和同事就达成了共同吃饭的协调工作，经历了4次消息传递。
所以反过来再回想一下TCP的建链过程。
client: SYN
server: SYN+ACK
client: ACK
其实真正的过程是
client: SYN
server: ACK
server: SYN
client: ACK
只不过服务端在收到SYN时，已经确定自己也要向客户端建链，而不是稍后再进行建链，所以服务端的SYN和ACK可以合并在一起发送，看起来就成了三次握手。
分析完建链过程之后，再看拆链过程，就非常好理解。
为什么需要4次交互？
因为发起的一方，表达的是：我要停止数据发送了。
然后响应的一方，往往还有数据要发（类比上面的工作差一点没有完成的同事），需要再把数据发完之后，才能发出：我也要停止数据发送了。
就好比，你和同事去吃饭，你吃完了，说一句：我吃完了。
如果同事这时也吃完了，就会说：收到，我也吃完了。
然后你回复：收到。
这样就能一起回去了。
但是大概率你的同事不会和你同时吃完。
所以听到你说吃完时，他只会回复：收到。
等他吃完后，他会说：我也吃完了，在你回复收到之后，整个同步才算完成。
总结
所以我们可以得出，通过一个不可靠的信道传输数据来同步双方，在不发生重试的情况下，最少需要3步，最多需要4步。
原因在于：
- 每次传输的数据都需要确认接收
- 另一方可能没有准备好这次的同步动作。
如果是可靠信道，只需要两步就ok了。
