相关疑难解决方法(0)

有人可以解释与HTTP/2相关的多路复用及其工作原理吗？

是因为它需要按照请求的顺序对客户端做出响应,导致HTTP 1.1中的行头阻塞问题？

如果每个请求花费的时间相等,那么就不会有行头阻塞和HTTP 1.1流水线操作,并且会执行与HTTP/2多路复用相同的操作吗？

(假设HTTP/2请求中没有请求优先级,并忽略HTTP/2的其他更改,例如头压缩,二进制等)

我很难理解SPDY如何解决HOL阻塞问题.

引自:http://chimera.labs.oreilly.com/books/1230000000545/ch02.html#TCP_HOL

要理解为什么会这样,请回想一下,每个TCP数据包在传输到线路时都带有唯一的序列号,并且数据必须按顺序传递给接收器(图2-8).如果其中一个数据包在路由到接收器时丢失,则所有后续数据包必须保存在接收器的TCP缓冲区中,直到重新丢失数据包并到达接收器.由于此工作是在TCP层内完成的,因此我们的应用程序无法查看TCP重新传输或排队的数据包缓冲区,并且必须等待完整序列才能访问数据.相反,它只是在尝试从套接字读取数据时看到传递延迟.这种效应称为TCP头行(HOL)阻塞.

因此,HOL阻塞存在,因为TCP保证按顺序传递.但是在这里,用户igrigorik说SPDY允许数据包以不同的顺序出现.但SPDY不仅仅是HTTP的替代品吗？这意味着它仍然在TCP上运行(从这里开始).

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

假设我们正在使用 HTTP1.1 并且我们Connection: Keep-Alive 在 html 中有 if

<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() …

IIS 10 支持 HTTP/2，但如果网站配置为使用 Windows 身份验证，它会降级到 HTTP/1.1。

我想创建一个不需要域用户登录（Windows Auth 非常适合）但仍然能够使用 HTTP/2 的 Web 应用程序。您对如何设计有想法吗？

到目前为止我自己的想法：也许我可以将应用程序外部的 Windows Auth 放入另一个创建 JWT 的服务中，然后使用该 JWT 在主应用程序上进行身份验证。

但这增加了很多复杂性：

• Chrome 目前不会在同一域中混合 HTTP/2 和 HTTP/1.1（FF 会），因此该服务必须位于不同的域中，这意味着需要额外的 SSL 证书 + DNS 配置等。
• 我需要在对服务器的任何调用期间处理 JWT 过期问题。

因此，对于它的价值来说，这可能是太多的努力。

你能想出更好的主意吗？