对在 HTTP1 和 HTTP2 中发送请求感到困惑

Question

赏金将在 3 天后到期。 此问题的答案有资格获得+150声望赏金。 Joji想引起人们对这个问题的更多关注。

我了解到，在 HTTP1.1 下，每个主机名（来源？）的默认同时持续连接的最大数量将是 6，至少对于 chrome。 我不是在询问限制的确切数量，因为我知道它因浏览器而异。 我更好奇我们何时会为新请求打开新连接 - 浏览器是否以某种方式重用相同的 TCP 连接，或者它总是启动新的 TCP 连接，除非它没有达到并发请求的限制？

假设我们使用的是 HTTP1.1 并且我们有Connection: Keep-Alive如果在 html 我们有

<script src="https://foo/foo1.js"></script>
<script src="https://foo/foo2.js"></script>
<script src="https://foo/foo3.js"></script>
<script src="https://foo/foo4.js"></script>
<script src="https://foo/foo5.js"></script>
<script src="https://foo/foo6.js"></script>
<script src="https://foo/foo7.js"></script>

每个脚本会导致建立一个新的 TCP 连接，还是所有后续请求将重用第一个脚本选项卡建立的第一个 TCP 连接？ 如果这些脚本中的每一个都导致建立一个新的 TCP 连接，鉴于浏览器的并发请求限制为 6，第 7 个请求是否必须等到第 6 个请求完成才能建立连接？

上面的例子是关于从 HTML 标签发起请求的。 从 JavaScript 发出的 api 调用怎么样？ 让我们在我们的 javascript 中

const result1 = apiCall1()
const result2 = apiCall2()
const result3 = apiCall3()
const result4 = apiCall4()
const result5 = apiCall5()
const result6 = apiCall6()
const result7 = apiCall7()

And assume the endpoint that those API calls are hitting is all api.foo.com/v1/tasks , my questions are, again: will each one of the api call result in a new TCP connection established or all the subsequent requests will reuse the第一个 api 调用建立的第一个 TCP 连接？ 如果这些 api 调用中的每一个都导致建立新的 TCP 连接，鉴于浏览器的并发请求限制为 6，那么第 7 个请求是否必须等到第 6 个请求完成才能建立连接？

我的最后一个问题是，与 http1.1 相比，http2 是否通过允许通过单个 TCP 连接同时发送多个请求来解决这个问题？

Answer 1

每个脚本会导致建立一个新的 TCP 连接，还是所有后续请求将重用第一个脚本选项卡建立的第一个 TCP 连接？

实际上这是一个不好的例子，因为默认情况下，一个<script>元素是阻塞的，所以在这种情况下，它会一个一个地执行它们，并且只有在前一个元素下载、解析和执行后才会继续执行下一个元素。 所以它只需要 1 个 TCP 连接。

但是，如果没有阻塞（例如具有async或defer属性）。 是的，它会一个一个地下载它们，并开始打开更多的 TCP 连接，最多可达 6 个。第 7 个请求必须等待其中一个连接释放后才能下载。

但现实情况是，第一个请求可能在稍后 TCP 连接打开时已经完成，因此它可能不会完全达到 6 个限制，只有 6 个或 7 个请求。

从 JavaScript 发出的 api 调用怎么样？ 让我们在我们的 javascript

完全相同的事情。 每个来源限制为 6 个。 尽管需要注意的一件事是某些 CORS 请求在没有凭据的情况下发送有效地算作另一个来源（即使它是相同的实际来源），因此获得另外 6 个连接。

我的最后一个问题是，与 http1.1 相比，http2 是否通过允许通过单个 TCP 连接同时发送多个请求来解决这个问题？

基本上是的。 由于 TCP 的工作方式，不完全同时，但尽可能接近。 在这里查看我的答案： HTTP/2 中的多路复用意味着什么

Answer 2

该过程很简单，如果您指定保持活动状态，则会记住连接以加快握手速度，因此用户可以发出许多请求，而无需重新打开昂贵的安全连接。

现在总会有 syn/ack 进程向服务器发出请求。 为了让服务器响应您的用户请求的每个项目，需要一个新的连接。 使用缓存可以绕过这一点，以帮助您提高带宽并减少对服务器的请求。 所有连接均应请求结束。

因此，在 100 个浏览器想要访问您的站点的场景中，每个请求看起来像 1.js 2.js... output 应该是有序的，但这在很大程度上取决于很多事情。 您在服务器端编写的语言、处理方式、服务方式以及您是否管理任何队列。 如果您提出需要更长时间处理的请求（将来会回复您），只要您不阻塞事件循环（归结到您的服务器），其他请求可能会提前 go 。

---

您可以在下面看到与服务器建立连接的过程，这涉及到每个请求。 TLS 的成本可以提高，但初始请求成本很高。