TCP 可以使用两次握手建立连接吗？

UDP 协议,可以了解下

@rensuperk

好的，不过是哪部分？ UDP 好像没有握手和确认之类的机制，包发出去就不管了吧。好像跟我的问题没有什么关系的样子……

看看 tcp fast open

第三个包带数据好像是可以的，但是必须也要有 ack，就是三次握手和第四次数据合并在一起了而已

这是一个数学问题，大于 3 次与 3 次效果一样，小于 3 次就不一样了

TFO，SYN 包可以设 PSH bit 并且带上 data （也可以不带 PSH 但是带 data ），直接一来一回就建立连接顺便还能发点数据。

https://zh.wikipedia.org/wiki/TCP%E5%BF%AB%E9%80%9F%E6%89%93%E5%BC%80
利用三次握手的 SYN 报文来传输应用数据，更加实用。

@scriptB0y TCP 有一个 fast open 特性

我觉得这个没必要说的那么麻烦，打个比喻：
登山的时候，上面一个人拉着绳子，你在下面准备登山，你不知道他好没好，他不知道你好没好，你们必须得两个人各自一下绳子来告诉对方，这个是通知作用。

除非你知道对方好了，直接爬上去告诉他：我要爬上去了。

所以你没解释两次为啥不行？

握手没学到，学到了 [dèn]

@cloverii 解释了啊，引用的那段话，server 浪费资源。如果发起端将第三次和数据一起发是可以的。

HTTP 响应可以放在 FIN 里面

假设 A 端发起关闭连接请求， 四次挥手中第二次的作用是通知 A 端，我收到了你的关闭请求，我也准备关闭；这时 B 端写缓冲区如果有数据的话会将这些数据发送完成再发 FIN 给 A 端。 这么说是不是 B 端写缓冲区没有数据 所以将第二次和第三次挥手合并到一个报文中了

用 UDP 假装 TCP

@GjriFeu 我的理解是这样的，而且这是一个通常的做法将 2，3 合并。

> It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK.[12] This is perhaps the most common method.

https://en.wikipedia.org/wiki/Transmission_Control_Protocol

总想搞个大新闻

如果两次握手就能建立连接，那 DDoS 的高兴死了

双方互相确认的机制，保证连接建立。

@scriptB0y 那有这种需求，为什么不上 QUIC 呢？

不可以啊，协议规定的东西，不按照协议来就不是 TCP 了

@eeljiang 同学

原来楼主就是那个写怎么学 python 的大神

我看你的博客，意思是想让第三次握手的 ACK 连着下一次的数据一起发送，对吧？
但是为什么要三次握手？现在假设 A 是客户端，B 是服务器。
第一次：A->B 这个过程，B 确定了 A 的发送没问题
第二次：B->A 这个过程，A 确定了 B 的接收没问题，同时确定了 A 自己第一个过程里面发送的 ACK，B 确实收到了，即自己的发送没问题。
第三次：A->B 这个过程，同样道理，B 确定了自己发送没问题，A 的接收也没问题。
经过这 3 次，A，B 双方互相确认了对方的发送和接收都没问题，所以保证了这是一个可靠传输。才开始传输数据

自己的看法，错了轻喷

@pusidun 额 不是大神…… 也是在学习

我觉得“保证了这是一个可靠传输”这个不太准确。因为 TCP 的可靠性是靠 ACK 确认保证的。所以即使不建立链接呢，只要每一次发送都有 ACK，没有 ACK 就重传也可以保证是可靠传输。

我博客可能没说明白…… 我最后的结论是第三次 ACK 带数据发送是没有问题的，甚至第一次发送的 SYN 也是可以带数据的。

三次握手初始化连接； ACK、交验和等保证可靠传输。各司其职。