为何TCP连接握手要3次,而分手却要4次?


凡是使用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会将为小明服务的内存资源,包括端口号全部释放。至此整个通信过程、资源回收过程完全结束。

微信外挂软件“海贼王”团队被判刑10年

常见端口漏洞利用总结

获取更多资讯请加入交流群


    协助本站SEO优化一下,谢谢!
    关键词不能为空
评 论
更换验证码