一个TCP连接上为啥能发起多少个HTTP请求？

Posted 2023-04-15

在 HTTP/1.0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。但是这样每次请求都会重新建立和断开 TCP 连接，代价过大。所以虽然标准中没有设定，某些服务器对 Connection: keep-alive 的 Header 进行了支持。意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。这样的好处是连接可以被重新使用，之后发送 HTTP 请求的时候不需要重新建立 TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免

久连接：既然维持 TCP 连接好处这么多，HTTP/1.1 就把 Connection 头写进标准，并且默认开启持久连接，除非请求中写明 Connection: close，那么浏览器和服务器之间是会维持一段时间的 TCP 连接，不会一个请求结束就断掉。

默认情况下建立 TCP 连接不会断开，只有在请求报头中声明 Connection: close 才会在请求完成后关闭连接。

如果维持连接，一个 TCP 连接是可以发送多个 HTTP 请求的。

参考技术A 因为可以。包容更多的可能性。 参考技术B 了解了第一个问题之后，其实这个问题已经有了答案，如果维持连接，一个 TCP 连接是可以发送多个 HTTP 请求的 参考技术C 因为技术在很快的进步啊。 参考技术D 因为一个TCP可以同时处理很多信息。

HTTP 行首阻塞：为啥响应必须按顺序返回

【中文标题】HTTP 行首阻塞：为啥响应必须按顺序返回

【英文标题】：HTTP Head of line blocking: Why responses must come back in orderHTTP 行首阻塞：为什么响应必须按顺序返回

【发布时间】：2021-04-12 07:12:21

【问题描述】：

行头阻塞（在 HTTP/1.1 术语中）通常是指每个客户端与服务器的 TCP 连接数量有限（通常每个主机名 6 个连接）并通过其中一个连接发出新请求必须等待同一连接上的前一个请求完成，然后客户端才能发出新请求。

HTTP/1.1 引入了一个名为“Pipelining”的功能，它允许客户端通过同一个 TCP 连接发送多个 HTTP 请求。然而，HTTP/1.1 仍然要求响应按顺序到达，因此它并没有真正解决 HOL 问题，并且截至今天它还没有被广泛采用。

我的问题是：在 HTTP 管道中，为什么响应必须按顺序返回？

【参考方案1】：

因为响应中没有标识符表明它属于哪个请求。

HTTP/2 使用 stream identifiers 解决了这个问题。

【参考方案2】：

HTTP/1.1 协议无法将请求与响应链接起来，除了顺序。如果响应可能乱序返回，则客户端无法知道哪个响应是对哪个请求的响应。

值得注意的是，流水线现在几乎是一个死功能，并且已从大多数流行的客户端中删除。如果您需要这样的功能，请查看确实允许乱序响应的 HTTP/2。