我的想法是让使用较慢连接的 Web 应用程序能够回退到替代的较小资产版本（如图像、视频等）。 HTTP Live Streaming 具有类似的行为，但适用于视频流。
一开始我以为，这可以通过使用HTTP/2服务器推送来实现。 Web 服务器将在关闭连接之前发送响应、测量吞吐量并推送适当的资产版本。但这将消除服务器推送的优势，因为客户端只有在收到页面正文后才能开始下载资产。由于资产不像流一样提供服务，因此服务器应在向客户端发送 HTTP 响应之前检测好输入。
我还想检查是否可以从 TCP 堆栈获取吞吐量，例如来自慢启动的值。但我想它只有在发送响应时才可用。
有人知道网络服务器如何在发送响应之前测量好吞吐量吗？
【问题讨论】：
标签： http networking web tcp http-live-streaming
可能还有其他情况，但我可以冒险回答服务器第一次看到客户端的情况。
当TCP连接建立时，服务器的操作系统基本上有一个数据点，由ACK包给出。我不认为用一个数据点来衡量网络吞吐量真的是不可能的，也不是goodput。并且将这些数据包与原始套接字相交，无法在应用程序中查看它们的时间。
然后你就有了 TLS 握手。对于那个，可以观察发送和接收包裹的大致时间。我说粗略是因为一旦它们在操作系统缓冲区中，就无法从应用程序内部知道它们何时实际放入网络中。然后这些延迟与吞吐量没有直接关系。
尽管如此，我认为您的想法是可行的，因为浏览器在获取许多其他内容（.html 本身、.css、javascript 甚至网络字体）之后很长时间才开始获取图像数据，而且通常已经摆脱了缓慢开始。在那个时间点，可能有机会收集足够的统计数据来建立良好的估计。而使用 HTTP/2，如果你想确定的话，你可以稍微延迟发送数据......
但是，我建议不要将两个不同的实时资产与同一个 URL 相关联，在这种情况下您必须这样做。想想看：用户首先在连接不良的情况下获取图像，图像被缓存。下次用户从家里的扩展坞连接时，缓存的图像会显示给他。丑陋的！但是，Web 应用程序可以在请求资产之前向服务器查询一些网络负载统计信息（参见？不需要使用 PUSH）。我想这对视频特别有效。
对于图像，您可以简单地使用隔行扫描/逐行扫描 PNG 或 JPEG。我们将are just building something 转换为Shimmercat 来控制各个交错块的优先级。这个可能会使用 push....
【讨论】：