非常大的 HTTP 请求与许多小请求答案

【问题标题】：Very large HTTP request vs many small requests非常大的 HTTP 请求与许多小请求
【发布时间】：2011-03-09 11:28:20
【问题描述】：

我需要一个二维数组（作为 Json）从服务器发送到客户端。它的大小约为 400x400，每个条目大约有 4 个文本字符。所以它大约有 640KB 的数据。

以下哪种极端方法更好？

我相信最佳方法会处于中间位置。谁能告诉我这个数据的最佳单个请求大小是多少？

谢谢。

【问题讨论】：

【解决方案1】：

选择一个大还是几个小的几个注意事项：

在单请求的情况下，不能随着数据的到来进行渐进式的数据处理；您需要等待完整的数据包到达，然后才能执行任何操作。如果失败，您需要从头开始。
在多个请求的情况下，您可以进行渐进式数据处理。但是，您现在必须考虑发生多次故障的可能性以及如何从这些故障中恢复。
多个请求会产生每个请求的开销。这是您的应用将消耗的额外带宽。
某些 HTTP 代理会限制对同一服务器的并发请求数，您可能需要执行一些逻辑来解决此问题。
响应压缩对于单个请求的情况会更好。
多个请求不会要求您为数据分配全部内存。诚然，640KB 并不是那么大的内存块，所以这对您来说可能不是一个重要的考虑因素，具体取决于您分配它的频率。
如果进程提前终止（取消按钮或应用程序终止或浏览器离开您的页面），单个请求仍将完成完整响应下载；但是，对于多个请求的情况，您的代码尚未启动的任何请求都不会被执行。

老实说，我不会那么担心最后两个，我的选择基于 1) 渐进式数据处理很重要；和 2) 您的应用对故障和部分数据的容忍度是多少。

【讨论】：

【解决方案2】：

除非您正在处理慢速（按照当今标准非常慢速）连接并且确实需要增量更新，否则请在一个请求中完成。

【讨论】：

+1 - 你可以避免往返的开销。即使在 20 毫秒……400 个请求也会使 8000 毫秒的开销 = 8 秒。在 80 毫秒...（很远），这将浪费 32 秒。
非常感谢大卫和汤姆。那真的很有用。 :)
好吧，@TomTom 你没有考虑并行请求......！如果对并发连接没有限制，它在完美连接的开始和结束时只有 20 毫秒 :) 如果我错了，请纠正我，它只有 400 x（处理标头所花费的时间）而不是 400 x RTT
@ZekeDran — 浏览器对并发连接数施加了限制。
假设是6，最终值减少6倍，接近1.33秒；因此，如果没有渐进式处理，这1.33s仍然是浪费！

【解决方案3】：

您必须记住，服务器可能有vulnerabilities with large requests。

【讨论】：