在学习TCP协议的时候,我一个最大的疑问就是,大家其实最终传输都是通过网线来传递的,不管是udp 还是tcp 对吧。那凭什么就说你tcp多握手个几次,就说我tcp就能干,我tcp就安全。我们并没有从网络中专门开辟一条线路。怎么你tcp就特别了。
然后tcp告诉我,我使用的是停止等待协议, 就是你发一条。我就确认一条,然后你才能发送下一条。
那这个时候我就感觉实际上我就使用停止等待协议就行了吗,还要搞什么tcp 协议干什么??
我个人理解的答案就是单纯的停止等待协议太简单了。功能单一,发送效率慢。那不行,需要升级一下,这么一搞tcp横空出世。
通过对tcp协议的规范,这个时候tcp能干更多的事情了,理论上2次握手(发送一次,确认一次完全可以)
考虑实际生产中,计算机的能力有限,接受端处理能力有限,不可能来者不拒,有一千个发送我就处理一千个?
这个时候就需要 握手了,握手是为了选择,
发送端,一次握手,告诉接受端 我来了,
接受端,二次握手,告诉发送端,来吧,我准备好了。
发送端,三次我握手,告诉接受端,我也准备好了。
疑问来了。为什么第二次的时候不能默认 已经完成了所谓的连接。
网络上给出的,标准答案是,使用三次,是为了避免 一次握手超时时,多次发送一次握手信息,导致接受端多次连接。
我有的疑问是,实际上我们在接受端搞个队列,当接收方这个队列里面有 发送方的发送请求的时候。,我们直接忽略不就好了。不是一样能防止吗?
真实情况是 ,接受端有2个队列,比一个还多一个,
对列1 在一次接受到发送方请求的时候(也就是一次握手的时候),将发送方的请求,放到1队列,也叫作半连接队列、
队列2,在发送方第三次请求的时候(也就第三次握手),将发送方的连接请求,放到队列2中,也叫全连接队列。
只有这个全连接队列里面的连接 才能真的发送数据。
那门问题来了。tcp协议 是个全双工协议, 实际上发送方也是能够成为接收方。
在三次握手之后,我们就能发数据了,那我发送端这个时候就能变成接受端了。那为什么,你接受端需要2次确认,发送端发出的消息,才能建立连接。
我发送端,只需要在你接受端确认消息后,就能秒变接受端??
从API上来看,发送端,客户端使用的api也不一样 已java为例子。
那么其实 安全的本质和几次握手实际上没关系。只是相对于udp的 发送不管接受,其实主要我们对发送的信息。进行回应,就理论上安全了。
那么三次握手可能就与安全无关,那么回到为什么要三次的问题。
我个人的思考是,在实际情况中,接受端作为服务器。他要接收到许多的请求。那计算机资源时有限的。我需要正确的使用我的资源,不能谁来撩我一下,我都搭理。
需要使用三次握手,也就是发送端的2次请求,才能作为最后通过的标准,服务器的计算机才会为你建立相对应的资源,
假设,计算机不能识别相同的连接请求,那么2次握手就能造成发送端因为超时而多次发送连接请求,服务端来者不拒,不停新建连接造成资源浪费。
不管哪一种,使用三次握手都能有效避免资建立 所谓的连接而造成资源浪费。
同样的,四次挥手是为什么。
假设2次挥手就行了(出于安全不考虑一次挥手)
不管我,发送端,还是接受端谁想结束,只要一端想结束了,给另外一端发送结束信号,然后等待确认信号就可以了。
这样子看 理论上也不是不可以。
理论上行,那么在实际生产中,就有另外一个问题,所作为发送端,一段连接产生,我们就也变成了 接受端,如果你不想发送了,发送了结束信号。而作为接受端可能还有信息要发送。所以我们要至少要等待 接收方 确定他自己也不发送了信息了。
从等待协议的方面考虑。也至少要2个来回。 一次是发送端结束(一发一收),一次是接受端结束(一发一收)。
主要是停止等待协议,是所谓安全的保证,也就意味着一端发送信息,另一端其实是必须要给予接受的回应。
也就意味着tcp 一次信息的发送的确认是2次握手。
那么所谓的3次握手。四次握手。就不出处于安全的考虑。 从tcp所谓面向连接。真的有连接吗?
连接是不可能连接的,我们在编程的时候,就假装是个连接。从逻辑上给他看成是连接,那么三次握手,四次挥手,都是为了维护这个连接资源,
如果说的还行,就点个赞吧
如果说的不行,请留言我们讨论讨论相互进步。
寡一个人讲,讲着讲着都不知道讲得是啥了