vsat中的網路問題
在我的伺服器-客戶端架構中，我通過衛星鏈路將 100 MB 的文件從伺服器**多播到許多客戶端。**網路遍歷是通過 5 跳。我有 10Mbps（即每秒 1250 千字節）頻寬連結。
當我將第一個文件多播到多個客戶端時，第一跳獲得的傳入速度約為 9.0 mbps，但接收端的速度僅為約 4.2 mbps。所有客戶端都是 10mb 半雙工。
我可以看到，網路使用率很低；但我不知道具體在哪裡。如果伺服器以 ~9.0 mbps 的速度發送，那麼客戶端應該具有相同的速度。
我正在使用可靠的 UDP 進行多播。
有什麼方法可以查明每一跳（對於特定埠）的傳入和傳出頻寬使用情況是多少？是否存在任何可以達到目的的工具/實用程序/應用程序。
所有的啤酒花都在偏遠的地方，所以不可能過去。
工具
有什麼方法可以找出每一跳（對於特定埠）的傳入和傳出頻寬使用情況是多少？
除非您擁有網路元素，或者您的第三方 WAN 提供商披露了資訊，否則您只能估計網路路徑上的端到端可用入口和出口頻寬。見下文。
是否存在任何可以達到目的的工具/實用程序/應用程序。
- 對於我上面提到的路徑“可用頻寬估計”，您應該查看Sally Floyd 的端到端 TCP/IP 頻寬估計工具檔案。我最熟悉的
yaz，它是基於單播 UDP 數據包的。- 要查看您是否在任何給定的路由器躍點丟棄數據包（這是您的底線問題），您可以使用
mtr; 還有一個win-mtr客戶端，它支持 Windows。要查看我通常如何解決丟包問題的簡單範例，請參閱我在 SuperUser 上的回答。這種技術最有效地在它們發生的第一個點提供對封包遺失的可見性（因為mtr在您更正第一個點之前，不會對超出該點的下游失去提供太多可見性）。粗略估計丟包位置的一種簡單技術是
mtr在伺服器上安裝，然後在mtr傳輸 100M 文件時執行會話以跟踪單個多播客戶端的封包遺失。對於更精確的測量，您可以使用iperf飽和網路而不是 100M 文件（只要您與公司中的其他團隊適當地協調 WAN 停機時間）。圖表
我的其餘答案將使用下圖作為參考：
在圖中：
- R1 到 R5 是 IP 路由器
- S1 和 S5 是乙太網交換機
- 172.16.1.0/24 上的藍色伺服器代表您的多播伺服器。
- C51 到 C55 是多播接收器的範例（可以是任意數量的接收器）
R1 和 R5 之間的 WAN 的細節通常並不重要，我們只需要一個基線拓撲，所以我們在同一頁面上。
據我所知，您是說 R1 在 172.16.1.0/24 上的介面在您發送 100MB 文件時顯示大約 9Mbps，而 R5 在 172.16.5.0/24 上的介面在客戶端通過可靠的 UDP 多播接收時顯示大約 4.2Mbps . 當您說可靠時，我假設這意味著多播服務中內置了某種數據包排序，並且客戶端應用程序知道如何從伺服器請求重新傳輸。
診斷
如果這個描述是正確的，有幾個可能的原因：
- 正如您在問題中所斷言的那樣，在 R1 之後的某處連結擁塞。
- 路徑中任何 Rx 設備的性能限制，包括 R1 和 R5（例如達到多播複製性能限制）
- 您遇到了 10M 半雙工乙太網的吞吐量限制。
原因 1 或 2 將通過使用來揭示
mtr。但是，原因 3 值得更多討論。10M/半鏈路為單向傳輸提供最大 10Mbps。如果您在 10M/半鏈路上發送雙向流量，由於乙太網的CSMA/CD 動態，您通常會看到大大低於 10Mbps 。在半雙工鏈路上，乙太網不能同時發送和接收；如果站點嘗試這樣做，它們的幀將發生衝突，並且兩個站點將隨機延遲重傳時間。我以測試網路為生。當我測試過 10M/半鏈路的有效雙向吞吐量時，我一般看到在 3Mbps 和 4Mbps 之間。您在上面分享的數字聽起來非常相似。我沒有足夠的證據來提出指控，但是如果您的 10M/半連結是問題，我不會感到驚訝；特別是如果 R5 和 S5 之間的鏈路是 10M/半。
