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