我的想法是让在较慢连接上工作的Web应用程序可以回退到其他较小的资产版本（如图像，视频等）。 HTTP Live Streaming具有类似的行为，但对于视频流。
起初我想，这可以通过使用HTTP / 2服务器推送来实现。 Web服务器将在关闭连接之前发送响应，测量吞吐量并推送适当的资产版本。但这会消除服务器推送的优势，因为客户端只有在收到页面主体后才能开始下载资产。由于资产不像流一样提供服务，因此服务器应该在将HTTP响应发送到客户端之前检测到良好输出。
我还想检查是否可以从TCP堆栈获取吞吐量，例如来自慢启动的值。但我想这只有在发送回复时才可用。
有人知道Web服务器在发送响应之前如何测量吞吐量吗？
答案 0 :(得分：2)
可能还有其他情况，但是当服务器第一次看到客户端时，我可能会冒这个案例的答案。
到TCP连接建立时，服务器的操作系统基本上有一个数据点，由ACK包给出。我认为用一个数据点测量网络吞吐量是不可能的，也不是很好。并且将这些数据包与原始套接字相交，无法在应用程序中查看它们的时序。
然后你有TLS握手。对于那个，可以观察发送和接收的包的粗略时间。我说粗略是因为一旦它们在OS缓冲区中，就无法从应用程序内部知道它们何时被实际放入线路中。然后这些延迟与良好输出没有直接关系。
尽管如此，我认为你的想法是可行的，因为浏览器在获取了很多其他内容（.html本身，.css，javascript甚至是网络字体）之后很久才开始提取图像数据，这些内容通常已经过时了开始。在那个时间点，可能有机会收集足够的统计数据来建立一个良好的估计值。使用HTTP / 2，如果您想确定，可以延迟发送数据....
但是，我建议不要使用相同的URL关联两个不同的实时资源，在这种情况下您必须这样做。试想一下：用户首先在错误的连接中获取图像，然后缓存图像。下次用户从家中的坞站连接时，向他显示缓存的图像。丑陋！但是，在请求资产之前，Web应用程序可以向服务器查询一些网络吞吐量统计信息（请参阅“不需要使用PUSH”）。我想这会对视频特别有效。
对于图像，您只需使用隔行扫描/渐进式PNG或JPEG。我们are just building something进入Shimmercat来控制各个隔行扫描块的优先级。这个可能会用push ....