我有一組 SOCKS 代理，它們位于負載均衡器（具體來說是 AWS 網路負載均衡器）后面。當負載均衡器在 SOCKS 埠上收到請求時，它會將請求轉發到具有最少活動連接的 Docker 容器（代理）。
我有一個使用標準 HTTP 包的 Go 應用程式。我想使用這個包對 SOCKS 代理的內置支持，并將它指向我的負載均衡器的地址。
我的問題是，Go HTTP 客戶端是否：
- 打開并維護與我指向的 SOCKS 代理的 TCP 連接（一個 TCP 連接，用于它保持打開的所有 HTTP 連接），
- 為每個 HTTP 連接打開并維護與 SOCKS 代理的 TCP 連接（即 SOCKS 代理連接與打開/空閑 HTTP 連接的一對一關系），
- 為每個 HTTP/S 請求打開并隨后關閉到 SOCKS 代理的 TCP 連接，無論 HTTP 客戶端上的并發/空閑連接設定如何，或者
- 完全做其他事情嗎？
如果答案是 (1) 或 (2)，有沒有辦法防止這種行為并確保它總是為每個 HTTP/S 請求重新連接到 SOCKS 代理？
我想這樣做的原因是確保請求在許多代理之間保持平衡，而不是客戶端（每個客戶端可能有許多并發請求）在代理之間保持平衡。
具體來說，假設我在負載均衡器后面有 3 個代理，分別標記為 A、B 和 C。假設我有兩個應用程式，1 和 2。應用程式 1 每秒發出 5 個 HTTP 請求，應用程式 2 每秒發出 500 個 HTTP 請求。
我要避免的是讓應用程式 1 與負載平衡器建立 SOCKS 連接，并將其轉發到代理 A，并保持與代理的連接，而應用程式 2 與負載平衡器建立 SOCKS 連接并將其轉發代理 B，它也被維護。如果發生這種情況，代理 A 將處理 5 個請求/秒，而代理 B 將處理 500 個請求/秒，這顯然是嚴重不平衡的。我寧愿所有三個代理都獲得約 168 個請求/秒。
uj5u.com熱心網友回復：
SOCKS 與協議無關。它不知道 HTTP 請求是什么，而只知道代理通過隧道傳輸的 TCP 連接是什么。因此，由 HTTP 堆疊引起的每個 TCP 連接都將意味著通過代理的新連接 - 沒有重用。如果要確保每個 HTTP/S 請求都通過代理獲得自己的連接，則必須禁用 HTTP keep-alive。請參閱此問題以了解如何執行此操作。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/498115.html