首页 文章

http keep-alive如何工作?

提问于
浏览
33

保持活动被添加到HTTP,基本上减少了为每个新请求快速创建和关闭套接字连接的巨大开销 . 以下是它在HTTP 1.0和1.1中如何工作的摘要:HTTP 1.0 HTTP 1.0规范并没有真正深入研究Keep-Alive应该如何工作 . 基本上,支持Keep-Alive的浏览器会在请求中附加一个额外的标头:Connection:Keep-Alive当服务器处理请求并生成响应时,它还会为响应添加一个标头:Connection:Keep-Alive当这是完成后,套接字连接不像以前那样关闭,但在发送响应后保持打开状态 . 当客户端发送另一个请求时,它会重用相同的连接 . 连接将继续重用,直到客户端或服务器确定对话结束,其中一个连接断开连接 .

以上解释comes from here . 但我不明白一件事

完成此操作后,套接字连接不像以前那样关闭,但在发送响应后保持打开状态 .

据我所知,我们只是发送tcp数据包来发出请求和响应,这个 socket connection 如何帮助它以及它是如何工作的?我们仍然需要发送数据包,但它怎么能以某种方式 Build 持久连接?这看起来很不真实 .

4 回答

  • 51

    我们来做个比喻吧 . HTTP包括发送请求和获取响应 . 这类似于向某人询问问题并收到回复 .

    问题是问题和答案需要通过网络 . 要通过网络进行通信,请使用TCP(套接字) . 这类似于使用手机向某人提问并让此人回答 .

    当您加载包含2个图像的页面时,HTTP 1.0包含在

    • 打个电话

    • 询问页面

    • 获取页面

    • 结束通话

    • 打个电话

    • 要求第一张图片

    • 获取第一张图片

    • 结束通话

    • 打个电话

    • 要求第二张图片

    • 获取第二张图片

    • 结束通话

    拨打电话并结束需要时间和资源 . 控制数据(如电话号码)必须通过网络传输 . 通过一个电话来获取页面和两个图像会更有效 . 这就是keep-alive允许做的事情 . 随着保持活力,以上变为

    • 打个电话

    • 询问页面

    • 获取页面

    • 要求第一张图片

    • 获取第一张图片

    • 要求第二张图片

    • 获取第二张图片

    • 结束通话

  • 1

    这确实是网络问题,但毕竟这可能是合适的 .

    混淆源于面向分组和面向流的连接之间的区别 .

    Internet通常被称为“TCP / IP”网络 . 在低级别(IP,因特网协议),因特网是面向分组的 . 主机将数据包发送到其他主机 .

    但是,除了IP之外,我们还有TCP(传输控制协议) . 互联网这一层的全部目的是隐藏底层媒体的面向数据包的性质,并将两个主机(主机和端口,更准确)之间的连接呈现为数据流,类似于文件或管道 . 然后我们可以在OS API中打开一个套接字来表示该连接,我们可以将该套接字视为文件描述符(字面意思是Unix中的FD,非常类似于Windows中的文件HANDLE) .

    大多数其他Internet客户端 - 服务器协议(HTTP,Telnet,SSH,SMTP)都位于TCP之上 . 因此,客户端打开一个连接(套接字),将其请求(作为底层IP中的一个或多个口袋传输)写入套接字,从套接字读取响应(并且响应可以包含来自多个IP数据包的数据,如然后...然后选择是为下一个请求保持连接打开或关闭它 . Pre-KeepAlive HTTP始终关闭连接 . 新客户端和服务器可以保持打开状态 .

    KeepAlive的优点是 Build 连接很昂贵 . 对于短请求和响应,它可能比实际数据交换需要更多的数据包 .

    轻微的缺点可能是服务器现在必须告诉客户端响应结束的位置 . 服务器不能简单地发送响应并关闭连接 . 它必须告诉客户:"read 20KB and that will be the end of my response" . 因此,响应的大小必须由服务器预先知道并作为更高级协议的一部分传送给客户端(例如,HTTP中的 Content-Length: ) . 或者,服务器可以发送分隔符以指定响应的结束 - 这一切都取决于TCP之上的协议 .

  • 12

    Build 新的TCP连接(DNS查找,TCP握手,SSL / TLS握手等)存在开销 . 如果没有保持活动状态,则每个HTTP请求都必须 Build 新的TCP连接,然后在发送/接收响应后关闭连接 . 保持活动允许现有的TCP连接被重用于多个请求/响应,从而避免所有这些开销 . 这就是使连接“持久”的原因 .

    在HTTP 0.9和1.0中,默认情况下,服务器在向客户端发送响应后关闭其TCP连接的末尾 . 收到响应后,客户端必须关闭TCP连接的末尾 . 在HTTP 1.0(但不是0.9)中,客户端可以通过在请求中包含 Connection: keep-alive 标头来明确要求服务器不要关闭其连接的结尾 . 如果服务器同意,则它在响应中包含 Connection: keep-alive 标头,并且不会关闭其连接的结尾 . 然后,客户端可以重新使用相同的TCP连接来发送其下一个请求 .

    在HTTP 1.1中, keep-alive 是默认行为,除非客户端明确要求服务器通过在其请求中包含 Connection: close 标头来关闭连接,或者服务器决定在其响应中包含 Connection: close 标头 .

  • 19

    你可以这样理解它:

    HTTP使用TCP作为传输 . 在通过TCP发送和接收数据包之前,

    • 客户端需要发送连接请求

    • 服务器响应

    • 完成数据传输传输

    • 连接已关闭 .

    但是,如果我们使用保持活动功能,则在接收数据后不会关闭连接 . 连接保持活动状态 .

    这有助于提高下一次调用的性能,因为与服务器的连接已经存在,所以不会进行Connect Build . 这意味着花费的时间更少 . 虽然连接的时间很短,但它确实在每个ms计数的系统中产生很大的差异 .

相关问题