TCP协议三次握手，四次挥手真的有必要吗

在学习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所谓面向连接。真的有连接吗？

连接是不可能连接的，我们在编程的时候，就假装是个连接。从逻辑上给他看成是连接，那么三次握手，四次挥手，都是为了维护这个连接资源，

如果说的还行，就点个赞吧
如果说的不行，请留言我们讨论讨论相互进步。
寡一个人讲，讲着讲着都不知道讲得是啥了