我有幾個不斷髮布數據到REST服務的客戶端。 REST服務放在網絡負載平衡器後面。每個客戶每天發送100-500MB，我需要支持500+客戶。建議的HTTP POST內容長度是多少？
我可以POST非常大的數據包，這將減少TCP/IP會話設置和HTTP標頭的開銷。但是，這會將一個客戶端與特定服務器緊密關聯，並限制我的可伸縮性選項。另外，我可以發送很小的HTTP數據包，我可以很好地平衡負載，但是我將爲TCP/IP會話設置和HTTP頭部獲得更多開銷。
HTTP POST推薦的數據包大小是多少？或者我怎樣才能爲我的環境計算一個呢？
沒有推薦的尺寸。
雖然HTTP POST的大小不受RFC的限制，但由於HTTP是實現請求/響應類型消息傳遞的商品協議，因此大多數基礎結構都圍繞TCP連接不是特別持久/不攜帶重要數據量。即您的控制範圍之外可能會影響服務的因素 - 儘管HTTP支持響應請求的範圍請求，但沒有任何必然的請求。
您可以通過使用HTTPS解決很多這些問題（雖然不是全部）。但是，您仍然需要考慮如何檢測/管理中斷 - 您是否樂意等待TCP超時？
由於500多個客戶端使用該系統的可能性很大，因此擁塞避免限制不應該成爲問題 - TCP窗口擴展是否可能成爲問題取決於系統的使用方式。 HTTP握手不應該成爲一個問題，除非您將請求大小限制在某種愚蠢的程度。
如果服務高度依賴於將大量數據推送到服務器的客戶端，那麼我建議您查看客戶端上的數據解析（由於卷的大小，它可能來自文件 - 意味着簽名Java小程序或帶有UniversalBrowserRead權限的javascript），然後通過雙向通信通道（例如websocket）發送它。
暫且拋開現在，只有通過測量並監視客戶端和服務器之間的路徑才能支持這一點。我預計2Mb的上傳大小几乎可以在任何地方工作，而10Mb的大小在美國或歐洲大部分時間都可以使用 - 而且只要沒有移動客戶端，您可以將其增加到50Mb。
但是，如果您想維護服務的有效性，您需要監控帶寬，數據包丟失和連接丟失。