从HTTP/2获得最佳的最终用户性能需要对资源优先级的良好支持。虽然大多数web服务器支持HTTP/2优先级划分，但要使其在浏览器中一直正常工作，则需要在整个网络堆栈中进行适当的协调。本文将介绍web服务器、操作系统和网络之间的一些交互，以及如何优化服务器以优化最终用户的性能。tl；dr在Linux4.9内核和更高版本上，启用BBR拥塞控制，并将tcp\u notsent_lowat设置为16KB，以使HTTP/2优先级排序可靠地工作。这可以在/etc中完成/sysctl.conf系统:net.core.default qdiscfq=定量网络ipv4.tcp_拥塞_control=bbr网络ipv4.tcp_notsent_lowat=16384浏览器和请求优先级一个单独的网页是由几十到几百个独立的内容组成的，一个web浏览器将这些内容汇集在一起，创建并呈现给用户。您正在访问的页面的主要内容（HTML）是关于如何构建页面的说明列表，浏览器从头到尾都会遍历这些说明，以确定需要加载的所有内容以及如何将它们组合在一起。每段内容都需要从浏览器向负责该内容的服务器发出单独的HTTP请求（或者，如果以前加载过，则可以从浏览器中的本地缓存加载）。在一个简单的实现中，web浏览器可以等到所有的东西都被加载和构造好之后再显示结果，但这会非常慢。并不是所有的内容对用户都是至关重要的，它们可以包括一些东西，比如页面中的图像、跟踪使用情况的分析、广告，比如按钮等。所有的浏览器在内容可用时都会以增量方式工作。这将带来更快的用户体验。当在后台加载其余内容时，可以显示页面的可见部分。决定请求内容的最佳顺序是浏览器请求优先级发挥作用的地方。如果操作正确，可见内容的显示速度会比简单的实现快得多。HTML解析器阻止文档头中样式和脚本的页面呈现。大多数现代浏览器使用类似的优先级方案，通常如下所示：按照在HTML中列出的顺序加载类似的资源（脚本、图像、样式）。先加载样式/CSS，因为在样式完成之前无法显示内容。加载阻塞脚本/JavaScript next是因为阻塞脚本会阻止浏览器在加载和执行完之前继续执行HTML中的下一条指令。加载映像和非阻塞脚本（异步/延迟）。字体是一个特殊的情况，因为它们需要在屏幕上绘制文本，但是浏览器在真正准备好将文本绘制到屏幕之前不会知道它需要加载字体。所以他们很晚才被发现。因此，一旦发现它们，它们通常会被赋予非常高的优先级，但直到加载过程中相当晚的时候才知道。Chrome还对当前浏览器视区（屏幕上可见页面的一部分）中可见的图像进行了一些特殊处理。一旦应用了样式和页面布局，它将赋予可视图像更高的优先级，并按从大到小的顺序加载它们。HTTP/1.x优先级使用HTTP/1.x，每个到服务器的连接一次可以支持一个请求（实际上，因为没有浏览器支持流水线），大多数浏览器一次最多可以打开6个到每个服务器的连接。浏览器维护其所需内容的优先列表，并在连接可用时向每个服务器发出请求。当一个高优先级的内容被发现时，它被移到列表的前面，当下一个连接可用时，它被请求。优先顺序/2 HTTP使用HTTP/2，浏览器使用单个连接，请求通过连接作为单独的"流"进行多路复用。一旦发现请求，这些请求就会连同一些优先级信息一起发送到服务器，以让服务器知道响应的首选顺序。然后由服务器尽其所能先传递最重要的响应，然后再传递优先级较低的响应。当一个高优先级请求进入服务器时，它应该立即跳到优先级较低的响应之前，甚至是中间响应之前。由HTTP/2实现的实际优先级方案允许并行下载，并在它们和更复杂的方案之间加权。目前，最简单的方法是将其视为资源的优先顺序。大多数支持优先级划分的服务器将发送具有可用数据的最高优先级响应的数据。但是，如果最重要的响应比低优先级响应生成的时间长，服务器可能最终开始为低优先级响应发送数据，然后在高优先级响应可用时中断其流。这样它就可以避免浪费可用的带宽和线路阻塞，因为慢响应会占用其他所有东西。在多个低优先级资源之后请求高优先级资源的浏览器。在一个最佳配置中，在一个有很多其他流的繁忙连接上检索最高优先级资源的时间将与在空连接上检索它的时间相同。实际上，这意味着服务器需要能够立即中断所有其他响应的响应流，而无需额外的缓冲来延迟高优先级响应（超过网络上正在传输的最小数据量，以保持连接的充分利用）。因特网上的缓冲区过度的缓冲几乎是HTTP/2的报应，因为它直接影响到服务器灵活响应优先级转移的能力。在服务器和浏览器之间存在比大多数网站都大的兆字节缓冲区是很正常的。实际上，这意味着响应将以服务器上可用的任何顺序进行传递。关键资源（如文档的中的字体或呈现块脚本）被低优先级图像的兆字节延迟并不罕见。对于最终用户来说，这意味着呈现页面的延迟时间为几秒甚至几分钟。TCP发送缓冲区服务器和浏览器之间的第一层缓冲在服务器本身。操作系统维护一个TCP发送缓冲区，服务器将数据写入该缓冲区。一旦数据在缓冲区中，操作系统就会根据需要传递数据（在发送数据时从缓冲区中提取数据，并在缓冲区需要更多数据时向服务器发送信号）。大缓冲区还可以减少CPU负载，因为它可以减少服务器对连接的写入量。发送缓冲区的实际大小需要足够大，以保留已发送到浏览器但尚未确认的所有数据的副本，以防数据包丢失和某些数据需要重新传输。缓冲区太小会使服务器无法最大限度地利用到客户端的连接带宽（这是长距离下载缓慢的常见原因）。在HTTP/1.x（以及许多其他协议）的情况下，数据以已知的顺序批量传递，将缓冲区调整为尽可能大除了增加内存使用（以内存换取CPU）之外没有其他缺点。增加TCP发送缓冲区大小是提高web服务器吞吐量的有效方法。对于HTTP/2，大型发送缓冲区的问题是，当高优先级响应可用时，它限制了服务器调整其在连接上发送的数据的灵活性。一旦响应数据被写入TCP发送缓冲区，它就超出了服务器的控制范围，并且已经承诺按照写入的顺序进行传递。在TCP发送缓冲区中，高优先级资源排在低优先级资源之后。HTTP/2的最佳发送缓冲区大小是充分利用浏览器可用带宽所需的最小数据量（对于每个连接来说，带宽是不同的，即使是单个连接也会随着时间的推移而变化）。实际上，您希望缓冲区稍微大一点，以便在服务器收到需要更多数据的信号和服务器写入额外数据之间留出一段时间。TCP发送低TCP_NOTSENT_LOWAT是一个套接字选项，允许配置发送缓冲区，使其始终是最佳大小加上固定的附加缓冲区。您可以提供一个缓冲区大小（X），这是除了充分利用连接所需的最小值之外您想要的额外大小，它动态地调整TCP发送缓冲区，使其始终比当前的连接拥塞窗口大X字节。拥塞窗口是TCP协议栈对需要在网络上传输以充分利用连接的数据量的估计。如果web服务器软件支持TCP\u NOTSENT_LOWAT，则可以在每个套接字的基础上以代码形式配置，或者使用网络ipv4.tcp不发送低位sysctl：网络ipv4.tcp_notsent_lowat=16384我们有一个补丁，我们准备上游NGINX使其可配置，但它还没有完全准备好，所以配置它的系统范围是必需的。实验证明，16384（16K）值是一个很好的平衡，在这种情况下，连接被充分利用，而额外的CPU开销可以忽略不计。这意味着，在高优先级响应中断并传递之前，将缓冲最多16KB的低优先级数据。一如既往，你的里程数可能会有所不同，值得一试。高优先级资源已准备好以最小的TCP缓冲发送。缓冲膨胀除了在服务器上进行缓冲之外，服务器和浏览器之间的网络连接也可以充当缓冲区。越来越普遍的是网络设备有大的缓冲区