参与TCP通信只有两者，整个通信过程一共有四个角色，分别是：

客户端 （小明）

客户端TCP （小明家附近快递公司M）

服务器TCP （商店快递公司S）

服务器 （商店）

 

如果没有快递公司，小明需要亲自跑到商店买商品，然后再吭哧吭哧搬回来。小明完全可以将自己的购物清单，委托给快递公司，由快递公司将采购的物品搬回家。这种分工合作的模式产生了上文的四个角色。

 

TCP为何要三次握手？

小明将购物清单告诉家附近的快递公司M，快递公司用包裹直接将购物清单运到快递公司S的仓库里，通知商家来取快递。商家根据购物清单出货，由快递公司S运输到快递公司M的仓库，通知小明前来取走。这样可以吗？

 

当然可以。但是，这样会有一些问题：

如果不受控制与约束，客户可以随时随地将快递包裹运到S的仓库，商家快递公司S的仓库有爆棚溢出的可能。此外，不受控制的快递车辆也会将本来就很拥堵的道路堵的一塌糊涂。

 

一些恶意购买者，伪造假的购物地址向商家下单。商家忙了半天发货了，结果查无此人。这是对商家是一种严重的资源消耗，商家对此恨之入骨。

 

小明的购物清单太大了，以至于需要多辆车才可以运完。这些车辆的到达顺序发生了前后颠倒。商家收到的购物清单写着“大闸”，商家立马崩溃，“大闸”是什么物品？其实小明写的是“大闸蟹五斤”，这个购物清单被M分割在多个车辆里运输了。

 

此外，商家如果没有开门营业，也没有必要浪费道路资源将快递包裹运到S处。

 

而采用TCP三次握手几乎可以解决以上所有的问题。

 

TCP三次握手，是快递公司S与M双方在协调，需要三次消息的交互。在协调完成之前，客户的包裹只能老老实实呆着仓库里耐心等候着。

 

S：我方字节流起始编号为s，我方的仓库（window size）大小为8192，收到请确认。

M: 确认收到，我方字节流起始编号为m，我方的仓库大小为16384，收到请确认。（M掏出小本子，记下s、window = 8192，同时将TCP状态修改为“Established”）

S：确认收到。（S掏出小本子，记下m、window = 16384，同时将TCP状态修改为“Established”）

 

至此，双方的信息是同步的，TCP连接建立完成。快递公司M可以将小明放在仓库里购物清单发车了。在没有收到S的确认之前，M最多只能运输16384字节。

 

通过以上的措施，不仅可以控制进入M仓库的快递包裹的数量，还可以控制杜绝假冒的快递包裹进入M仓库。当然如果商家关门歇业了，也可以在三次握手阶段发现，从而避免快递车辆上路添堵。

 

为何TCP分手需要四次，而不是三次？

小明的采购终于完成了，小明将这个信息传递给M。

 

在M看来，这个消息意味着：

小明不会再有购物清单的产生。意味着从小明到商家这个方向不会再有用户字节流的产生。

 

1. M立马将这个消息传递给S，这个消息包含以下关键内容：

FIN状态位，表示分手的意思

我方字节流最后一个字节编号

 

S收到了这个分手的消息，能立马发出FIN状态位吗？

 

不能！

如果S发出FIN状态位，同时会发出己方的字节流最后一个字节编号。此时商家可能正在处理小明的最后的订单，那么商家处理订单而产生的这些字节流（FIN发出之后产生的）算谁的？

 

2. 既然不能发FIN，那么按照TCP协议规定，需要用ACK消息确认收到M的分手消息

 

稍后商家处理完小明的最后订单，将字节流扔到S的仓库，并通知S可以发分手信号（FIN）了。

 

3． S将最后的字节流打包，写上分手信号（FIN）状态位、以及己方字节流最后一个字节的编号，发出。

 

4．M按照TCP协议规范，必须使用ACK消息予以确认，表示收到商家的字节流的所有字节。

 

当S收到M的ACK确认消息，立马将这个TCP连接所占用的内存空间全部释放掉。M会静静地等待2MSL的时间，在等待期间，小明所占用的端口号资源依然不能释放给别的进程使用。一旦等到时间到，M会将为小明服务的内存资源，包括端口号全部释放。至此整个通信过程、资源回收过程完全结束。