如何降低TCP三次握手延迟负面影响

目录

一、前言

二、HTTP长连接

三、TCP FAST OPEN

四、标准TCP协议握手报文传输数据

五、参考

一、前言

TCP传输协议是可靠性协议，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。建立TCP连接需要进行三次握手，而这个阶段不能用来传输有效负载数据。对于一些场景（HTTP短连接），频繁的新建TCP连接会增大任务延迟，减低通讯效率。下面主要是简略的介绍，详细的文档请点击第五节的参考连接。

二、HTTP长连接

HTTP使用过程中分为短连接与长连接。

如下图展示了 HTTP1.0 短连接的使用过程。客户端与服务器的每次通讯都需要新建TCP连接，并在通讯结束后断开连接。每次的通讯过程描述如下：

1、新建TCP连接（三次握手）

2、客户端发送请求到服务端，服务端根据请求进行回复

3、断开TCP连接（四次挥手）

HTTP短连接通讯过程中出现大量的TCP重建过程，通讯效率很低。

HTTP1.1响应头中引入了 connection : keep-alive 选项开关 HTTP 长连接，默认开启。HTTP长连接中减少了 TCP 连接的重建过程，即在客户端与服务端通讯过程中只需要新建一次TCP连接，并在该TCP连接上进行多次请求回复的通讯过程。在HTTP长连接通讯过程中需要TCP连接一直存活，这个主要依赖TCP的保活机制。

三、TCP FAST OPEN

标准TCP的通讯过程是在客户端和服务端建立连接后，才可以进行send和recv，而建立连接的三次握手过程中是没有负载数据的发送。TCP FAST OPEN 通过引入 cookie 机制来提高 TCP 连接的通讯效率，实现在三次握手过程中进行有效数据传输任务。 详细文档参考 RFC 7413

具体过程如下图所示。

在客户端与服务端初次建立连接时，第一次握手过程中cookie为空，之后服务端根据客户端IP生成 8 byte 的 cookie 并在第二次握手时返回给客户端，客户端会缓存 cookie 数据，之后在第三次握手时即可发送携带有效负载数据的应答。

当 TCP 连接断开后，客户端需要重新与服务端建立连接时，会在第一次握手时将之前缓存的 cookie 和 有效负载数据一同发送给服务端；服务端进行验证成功后即可正常收发数据，如果验证失败（如cookie过期等）则更新cookie，并在第二次握手时告知客户端。

TCP FAST OPEN功能由 /proc/sys/net/ipv4/tcp_fastopen 控制开关。

服务端需要对socket设置TCP_FASTOPEN选项：

客户端则可以直接使用sendto函数建立连接和发送数据

四、标准TCP协议握手报文传输数据

TCP SYN握手报文可以传输数据吗_Netfilter,iptables/OpenVPN/TCP guard:-(-CSDN博客 https://blog.csdn.net/dog250/article/details/122995484?spm=1001.2014.3001.5502

区别于在标准TCP上添加TCP FAST OPEN选项实现握手阶段传输数据。这个大神博主，提到标准TCP协议其实是支持握手阶段携带数据传输的（不考虑安全性等因素），但由于 socket API 不支持（使用顺序必须是先连接再发送数据，根本不给在握手阶段发送的数据的机会），一直不被人了解。所以之前一直讨论的三次握手的延迟是TCP协议的缺陷就有些强人所难了，TCP协议是支持的，只是其使用实现不支持。

五、参考

TFO(tcp fast open)简介_我的人生的技术博客_51CTO博客

TCP Fast Open原理和使用_罗宾王的博客-CSDN博客_fastopen

TCP SYN握手报文可以传输数据吗_Netfilter,iptables/OpenVPN/TCP guard:-(-CSDN博客

RFC Search Detail

本文由 在线网速测试 整理编辑，转载请注明出处，原文链接：https://www.wangsu123.cn/news/19123.html。