http - 推荐的 HTTP POST 内容长度是多少？

Question

我有几个不断将数据发布到 REST 服务的客户端。 REST 服务置于网络负载均衡器之后。每个客户端每天发送 100 - 500 MB，我需要支持 500 多个客户端。

我可以 POST 非常大的数据包，这将减少 TCP/IP session 设置和 HTTP header 的开销。但是，这会将一个客户端牢固地绑定(bind)到一个特定的服务器并限制我的可扩展性选项。或者，我可以发送小的 HTTP 数据包，我可以很好地平衡负载，但我会在 TCP/IP session 设置和 HTTP header 方面获得更多开销。

HTTP POST 的推荐数据包大小是多少？或者如何为我的环境计算一个？

Answer 1

没有推荐的尺寸。

虽然 HTTP POST 大小不受 RFC 的限制，但由于 HTTP 是一种实现请求/响应类型消息传递的商品协议(protocol)，因此大多数基础设施都是围绕 TCP 连接不是特别持久/不携带大量数据的想法配置的数据的。也就是说，您无法控制的因素可能会影响服务 - 尽管 HTTP 支持响应范围请求，但没有针对请求的推论。

您可以通过使用 HTTPS 绕过其中的很多(虽然不是全部)。但是，您仍然需要考虑如何检测/管理中断 - 您愿意等待 TCP 超时吗？

假设有 500 多个客户端大量使用该系统，拥塞避免限制应该不是问题 - TCP 窗口缩放是否可能成为问题取决于系统的使用方式。除非您将请求大小限制为一些愚蠢的东西，否则 HTTP 握手应该不是问题。

如果服务高度依赖客户端将大量数据推送到您的服务器，那么我鼓励您考虑在客户端上解析数据(考虑到数据量，大概它来自文件 - 这意味着一个签名的 java applet 或具有 UniversalBrowserRead 权限的 javascript)，然后通过双向通信 channel (例如 websocket)发送它。

暂时不考虑这个问题，您可以找出客户端和服务器之间的路由将支持什么的唯一方法是对其进行测量 - 并对其进行监控。我希望 2Mb 的上传大小几乎可以在任何地方使用，而 10Mb 的大小在美国或欧洲的大部分时间都可以使用 - 只要没有移动客户端，您就可以将其增加到 50Mb。

但如果您想保持服务的有效性，您需要监控带宽、数据包丢失和丢失的连接。