我有几个客户端不断将数据发布到 REST 服务。 REST 服务位于网络负载均衡器之后。每个客户端每天发送 100 - 500 MB，我需要支持 500 多个客户端。
我可以发布非常大的数据包，这将减少 TCP/IP 会话设置和 HTTP 标头的开销。但是，这会将一个客户端牢固地绑定到特定服务器并限制我的可扩展性选项。或者，我可以发送小的 HTTP 数据包，我可以很好地进行负载平衡，但我会在 TCP/IP 会话设置和 HTTP 标头方面获得更多开销。
建议的 HTTP POST 数据包大小是多少？或者我如何为我的环境计算一个？
【问题讨论】：
标签： http rest http-post load-balancing
没有推荐的尺寸。
虽然 HTTP POST 的大小不受 RFC 的限制，但由于 HTTP 是一种实现请求/响应类型消息传递的商品协议，因此大多数基础架构的配置都是围绕 TCP 连接不是特别持久/不携带大量数据的想法进行配置的数据的。即，您无法控制的因素可能会影响服务 - 尽管 HTTP 支持响应范围请求，但请求没有必然结果。
您可以通过使用 HTTPS 来解决其中的很多问题（尽管不是全部）。但是，您仍然需要考虑如何检测/管理中断 - 您愿意等待 TCP 超时吗？
假设有 500 多个客户端大量使用系统，拥塞避免限制应该不是问题 - TCP 窗口缩放是否可能成为问题取决于系统的使用方式。 HTTP 握手应该不是问题，除非您将请求大小限制在一些愚蠢的范围内。
如果该服务高度依赖于将大量数据推送到您的服务器的客户端，那么我鼓励您查看在客户端上解析数据（考虑到数量，可能它来自文件 - 暗示已签名的 java具有 UniversalBrowserRead 权限的小程序或 javascript）然后通过双向通信通道（例如 websocket）发送它。
暂且不说，找出客户端和服务器之间的路由支持的唯一方法是对其进行测量 - 并对其进行监控。我预计 2Mb 的上传大小几乎可以在任何地方使用，而 10Mb 的大小在美国或欧洲的大部分时间都可以使用 - 只要没有移动客户端，您就可以将其增加到 50Mb。
但如果您想保持服务的有效性，您需要监控带宽、数据包丢失和连接丢失。
【讨论】：