Mos*_*oss 9 optimization latency httprequest web
在HTTP请求与文件大小之前已经问过这类问题？,但我希望有更好的答案.在这个相关的问题中,回答者似乎很好地用延迟+传输时间的漂亮公式回答了这个问题,估计延迟为80毫秒,传输速度为5Mb/s.但至少在一个方面似乎存在缺陷.在正常的浏览体验中,多个请求和传输不会同时发生吗？当我检查Chrome中的"网络"标签时,这就是它的样子.这是不是意味着请求延迟不是那么可怕的事情？
还有其他事情需要考虑吗？显然延迟和带宽会有所不同,但是80毫秒和5Mb/sa是经验法则吗？我想到了一个类比,我想知道它是否正确.想象一下火车站只有一个轨道和一个轨道(或者可能是两个轨道).Http请求就像发送引擎以在另一个站点获得一堆汽车.他们返回拉长列铁路车辆,代表所下载的文件.所以你可以发送一个引擎并让它带来巨大的负载.或者你可以发送多个引擎,他们每个可以带回较小的负载,当然他们都必须等待轮到他们回到车站.并且有些引擎在其他引擎进入之前无法发送出去.这是一个有缺陷的类比吗？
我想最重要的问题是你如何预测http请求中会有多少重叠,以便你可以知道,例如,在你的页面上有两个大的PNG文件或者是否有一个webp图像通常是值得的,以及不兼容浏览器的Webpjs js和swf文件.这使请求数量增加了一倍,但总文件大小减少了一半(比如节省了200kB).
你的比喻一般来说还不错.显然,如果你想在所有方面都非常精确,那么就会有过于简单或不正确的事情(但几乎所有类比都会发生这种情况).
你对80毫秒和5毫特/秒的估计可能听起来合乎逻辑,但即使我们大多数人都喜欢理论,你也应该以另一种方式管理这类问题.
为了做出好的估计,您应该测量以获取一些数据并进行分析.每个估计都取决于某些背景,你不应该忽视它.
考虑一下3G连接的估计延迟和带宽,日本的ADSL连接或技术较少的国家的ADSL连接.客户是从世界的另一端还是在同一个国家/地区访问？就像您对客户端上的同时连接的良好观察一样,如果不采取某种措施,就会有数以百万计的问题要问自己,而且很少有高质量的答案.
我知道我没有回答你的问题,因为我觉得如果没有关于这个领域的很多细节(加上约束,还有一个巨大的等等),我就无法回答.
您似乎对如何设计解决方案有一些想法.我最好的建议是实施其中的每一个并对其进行分析.进行测量,尝试确定您的瓶颈是什么,看看您是否对它们有一些控制.
在某些问题中,这类问题可能具有最优解,但在实践中,最优和次优之间的差异可以忽略不计.
这就是我正在寻找的答案。我做了一些简单的测试，以了解多个小文件与一个大文件的速度。
我创建了 html 页面，从 placekitten.com 加载了一堆随机大小的图像。我在 Chrome 中加载了它们，并打开了“网络”选项卡。
以下是一些结果：
# of imgs Total Size (KB) Time (ms)
1 465 4000, 550
1 307 3000, 800, 350, 550, 400
30 192 1200, 900, 800, 900
30 529 7000, 5000, 6500, 7500
因此，需要注意的一件重要事情是，单个文件在加载一次后会变得更快。（逗号分隔的时间列表是页面重新加载）。我进行了正常刷新以及清空缓存和硬重新加载。奇怪的是，我以哪种方式刷新似乎并没有多大区别。
我的连接有大约 120 - 130 毫秒的延迟或返回时间或其他时间，我的下载速度在 4 到 8 Mbps 之间变化。Chrome 似乎一次执行大约 6 个请求。
从这几个测试来看，至少在这个文件大小范围内，当文件大小相等时，请求越少显然越好，但是如果您可以将文件大小减少一半，即使是以增加文件大小为代价如果 http 请求数增加 30，那么这是值得的，至少对于新页面加载而言是这样。
任何评论或更好的答案将不胜感激。