對於我們的遊戲，我們將其靜態資產託管在剛安裝並執行 httpd 的虛擬機器上（當然還有一些本機 Linux 東西），以便提供 Web 內容。配置的 MPM 是 MaxClients 為 6400、ServerLimit 100 和 ThreadsPerChild 64 的工作執行緒。透過上述配置，所提供的靜態內容的總大小約為 20 MB，並且在我的國家（保加利亞）以及其他不同的國家/地區提供。經檢查並確認國內和國際頻寬速度沒有差異。然而，在高峰時刻，當頻寬達到最大時，我們開始收到來自遠端用戶（即來自俄羅斯）的大量投訴，表示遊戲需要 2-3 分鐘才能完全下載。每當我們從這裡檢查加載禁用快取的遊戲時，每次我們嘗試從任何電腦上都需要大約 10 秒。我們從原始 VM 映像中新增了 2 個 VM（相同的配置和內容），並執行了最快的負載平衡 - DNS 循環，總共三個 IP。投訴量有所減少，但俄羅斯用戶的載入時間仍維持在1分鐘以上。當我們再次嘗試多次從這裡下載遊戲時，仍然需要 10 秒，對我們來說沒有區別。考慮到靜態內容伺服器具有相同的國內和國際對等互連，並且當負載較低時，所有俄羅斯用戶也可以下載 10 秒，但在高峰時段卻無法下載，可能的原因是什麼？對於所有用戶來說不應該都是一樣的嗎？
PS 靜態伺服器總是有足夠的內存，產生的 httpd 進程從未超過 50，設定限制為 100
編輯：問題的簡短摘要 - 在低負載下，所有客戶端（本地和遠端）下載客戶端的時間相同（例如 15 秒）。當負載較高時，本機用戶端會再次載入 15 秒，而遠端用戶端則會載入 2-3 分鐘。可能的原因有哪些？
答案1
按照澄清這僅在頻寬達到最大時發生，這聽起來像是一種完全正常的行為，然後 - 當您最大化可用頻寬（線速）時，您可能會開始丟失資料包並有TCP視窗對於從未擴大規模以獲得最佳速度的長期客戶；頻寬延遲積成長，透過同一管道下載同一文件的時間增加；你必須做一些流量整形（換句話說，數據包排隊和優先級）如果您想讓每個人在超載期間變得更加均勻。 – 中國標準時間 10 月 6 日 4:56
答案2
答案取決於很多事情。你不能僅僅說你的國際速度是恆定的。遠端用戶的效能始終較低，具體取決於您和他們之間的網路及其負載量。
順便說一句，您確實說過您的頻寬已達到極限。您的伺服器網路連線的頻寬？那麼您確實需要 CDN 或快取反向代理。
我可以提供一些快速改進：
- 使用Nginx；它可以更有效地提供靜態內容。
- 使用像 Cloudflare 這樣的 CDN，或者如果這太複雜，您可以在俄羅斯租用虛擬機器並在其上安裝快取反向代理，讓您的 DNS 地理 IP 感知並讓俄羅斯用戶重新導向到那裡。 Cloudflare 實際上可能更容易:)
答案3
您不能真正說國內和國際流量的對等互連是相同的。
在過去的幾年裡，情況可能有所改變，但傳統上，在俄羅斯，大多數提供者從未為任何本地對等互連付費，直接從 MSK-IX 獲取，其餘流量由傳輸提供者處理。
各個方向的鏈接幾乎總是具有不同的容量，並且某些鏈接經常每隔一段時間就會保持飽和（要么是由於意外的流量峰值，要么是因為有人懶得更新其鏈接，或者為更多流量支付更多費用等） ，尤其是在高峰時段，這種情況可能會更頻繁地發生。
通常，在對等互連或中轉點，提供者會支付固定費率以獲得無限的 100Mbps、1Gbps 或 10Gbps。當流量超過支付的流量時會發生什麼？有些資料包被丟棄，有些資料包速度減慢，而且這種情況通常只發生在高峰時段，有時僅在一個方向發生（但即使發生在一個方向，兩個方向的流量仍然會減慢，因為延遲增加，並且有些ACK擁塞控制資料包也會遺失）。
我會透過運行來解決問題mtr發送到遇到此問題的俄羅斯主機之一，以及從俄羅斯的主機發送到您位於保加利亞的伺服器。我發現最有用的做法是運行每個實例 30 秒到 15 分鐘（mtr 將匯總此類運行的整個持續時間的統計資料），然後在上一次運行完成後立即再次運行它 5 到 15 分鐘。這樣，您就可以準確地看到問題發生的時間。
否則，這也可能是 Apache 的問題，可能與俄羅斯主機的較高延遲有關——nginx 在提供各種內容方面通常比 Apache 更有效，所以，也許這是嘗試 nginx 的好機會？
答案4
雖然光速是恆定的，並且數據以相同的速度通過長距離光纜傳輸，但距離源越遠，它必須經過的“跳躍”就越多。
如果您對 100 英里外的伺服器運行追蹤路由，然後將該追蹤路由與跨越地球一半的伺服器進行比較，則跨越地球一半的伺服器可能會經歷更多的躍點。
潛伏是資料在到達目的地之前經過每個路由器（跳）所花費的時間，延遲就是這裡的問題。