HTTP Keep-Alive是啥？如何工作

Posted 2023-05-09

参考技术A HTTP协议是在TCP协议之上的，所以建立一个HTTP连接就需要一次三次握手的过程。但是HTTP有持续连接和非持久连接的区分，就是看HTTP请求首部里面的Connection字段，Connection:Keep-Alive表示持续连接，除非一方主动断开，客户端和服务器的网络连接是持续的，期间会有一个保持连接的数据信号，而且连接期间多个HTTP请求都是使用这一个网络连接，这样可以节省请求连接和断开连接的开销，但是维持连接也可能增加服务器的负担；如果是Connection:close，一个HTTP请求在获得HTTP响应后连接就会断开，在下一次HTTP请求时就会有另外一次HTTP连接，也就会再有一个三次握手的过程。

HTTP/1.1 客户端如何知道在存在“Connection: keep-alive”头字段但没有“Content-Length”的情况下消息在哪里结束？

【中文标题】HTTP/1.1 客户端如何知道在存在“Connection: keep-alive”头字段但没有“Content-Length”的情况下消息在哪里结束？

【英文标题】：How does a HTTP/1.1 client know where a message ends in presence of `Connection: keep-alive` header field but absence of `Content-Length`?

【发布时间】：2018-08-29 06:43:26

【问题描述】：

特别是，我有一个来自 nginx 服务器的响应头：

HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Tue, 20 Mar 2018 10:28:24 GMT
Content-Type: text/html
Last-Modified: Thu, 28 Jan 2016 10:50:21 GMT
Connection: keep-alive
ETag: W/"56a9f26d-2d97"
Content-Encoding: gzip

随后是大约 3352 字节的压缩数据。我正在尝试找出客户端如何知道此消息的正文在哪里结束以及新的响应开始的位置。

【问题讨论】：

我认为gzip 包含标题中的大小

【参考方案1】：

它没有。响应需要 Content-Length 响应头字段，或者必须使用“Transfer-Encoding: chunked”。

【讨论】：

你是对的。我用curl -I <URL>（发送HEAD请求）instead of curl -sD - <URL> -o /dev/null生成了上面的HTTP头，所以响应缺少Transfer-Encoding: chunked头字段。