凡是使用TCP进行通信的，都是点对点（Peer to Peer）通信。所谓点对点通信，是指参与通信的只有两者（2 Peers），简称2P。三方（3P）、或多方通信，不能使用TCP，只能使用UDP作为传输协议。
参与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会将为小明服务的内存资源，包括端口号全部释放。至此整个通信过程、资源回收过程完全结束。