ns 3 project
1.0.0
% Alfred Tso Chun Fai 20012065g % COMP5311 專案：TCP 與 UDP 效能分析
新頁
甚至想知道為什麼 Chrome 瀏覽器在觀看 Youtube 影片時感覺比 Firefox 快得多？我這樣做了，作為一個好奇的學生，我啟動了 Wireshark 並捕獲了一些流量，我發現的是這個。
根據 wiki 1 ，從 Chrome 網路瀏覽器到 Google 伺服器的所有連線中有一半以上使用 QUIC。
QUIC 是一個旨在透過建立多個複用 UDP 來改進目前使用 TCP 2 的Web 應用程式的協議，有些人甚至稱之為「TCP/2」。據稱即將推出的 HTTP/3（截至 2021 年 2 月的網路草案）也將使用 QUIC。
等等...我們正在使用UDP 來取代TCP？我們被告知UDP不可靠，為什麼它可以被設計成「淘汰」TCP。兩種協議（TCP 和 UDP）的比較類似於比較火車與飛機，而不是比較波音與空中巴士（都是運輸）。然而，我們仍然可以將它們與一些關鍵指標進行比較，以了解 QUIC 選擇 UDP 進行改進的地方。
新頁
新頁
比較傳輸層協定並不是一件容易的事，因為有很多因素可能會影響結果：
協定中的某些參數（例如 TCP）留給實作（這會產生 TCP/IP 指紋，允許惡意行為者識別主機的作業系統等），這意味著這些差異可能會對績效衡量
封包所採取的直接路由肯定會影響結果，因此直接路由器、中間的瓶頸連結和其他流量也會影響結果。
如上所述，我們通常可能不確定這些直接連結的頻寬或只是客戶端和伺服器之間的連結。提到的一篇論文假設該連結不會發生任何衝突。
我們已經看到緩衝區可能會影響這些協定的效能，不僅軟體方面相關，硬體部分也很重要，而且通常我們無法完全控制這些較低層級的細節。
在先前大部分的工作中，作者經常實現一個自訂程式來進行實驗，我們還需要考慮這些軟體實現對結果的影響，例如發送UDP資料包的時間間隔，以及是否有限制。目的而言，所使用的語言是發送間隔。
考慮到所有這些因素，我們將使用簡單的網路拓撲，其設定盡可能接近現實。對於緩衝區佇列大小或協定等底層細節，我們將為這兩種協定使用相同的資訊。因此，我們將使用吞吐量、平均延遲和平均抖動作為效能指標，在有線一對一主機中比較 IPv4 上的 TCP 和 UDP。
我們將發送 10、100 和range(1e4, 1e5, 1e4)資料包，UDP 應用程式中的每個資料包為1472 位元組，TCP 應用程式中的位元組數相同，以觀察TCP 和UDP 應用程式的流量。
JitterSum包含流中所有接收到的封包的所有端對端延遲抖動（延遲變化）值的總和。這裡我們將資料包的抖動定義為相對於流的最後一個資料包的延遲變化，即
新頁
設計上述實驗的首要問題是模擬與否。在我們的研究中，模擬可能會更好，因為我們可以更好地控制我們提到的考慮因素。最大的缺點是我們如何確定結果是「真實的」？答案是，只要我們有明確定義的實驗範圍並經常對這些範圍進行健全性檢查，我們就可以了解結果的「真實」程度。
ns-3是一個開源的離散事件網路模擬器，主要用於用 C++ 編寫的研究或教育目的。模擬器本身有一個全面的線上文件。
就我們目前的目的而言，我們只需要了解ns-3的主要抽象
{ 寬度=75% }
它就像我們電腦中的進程一樣，它使用「套接字」將資料傳送到下層。我們將在ns-3中安裝現成的BulkSendApplication ，使用 TCP 套接字和UDPClient和UDPServer來傳送 UDP 封包，並在這兩種情況下安裝一個FlowMonitor來監視封包。
我們將以 2 微秒的間隔發送資料包，這是下面指定的底層通道的延遲
這裡指的是有效載荷。由於 MTU 是 1500，我們自然會想要使用 1500 位元組。然而，IP 標頭和 UDP 標頭需要 20 + 8 字節，因此我們應該使用 1472 而不是5 。這在模擬中得到了證實；使用 1500 位元組資料包可能會損害吞吐量效能。
BulkSendApplication「該流量產生器只是盡可能快速地發送數據，直到達到MaxBytes 或直到應用程式停止（如果MaxBytes 為零）。一旦下層發送緩衝區被填滿，它就會等待，直到空間空閒來發送更多數據，本質上是保持持續的資料流」。
我們將 MaxBytes 設定為 UDP 的總位元組數（PacketCount * PacketSize）來比較效能，並且在某些實驗中 SendSize 並不重要
也稱為InternetStackHelper ，通常包括 UDP、TCP 套接字、IPv4，對於我們目前的目的， TrafficControlLayer包括一個隊列，當隊列已滿時，它會通知上層
這對應於硬體（網路介面卡、NIC）和它們的軟體驅動程序，還包括資料包佇列，因此ns-3中有兩級排隊
它是我們可以安裝Application 、 InternetStack和NetDevice的終端主機，類似我們的電腦。我們將創建兩個Node並用類似於乙太網路電纜的東西連接它們。
為Node提供通訊通道，我們將使用 CSMA 通道（如乙太網路）。這裡的重要細節是可用來調整的這些屬性的選擇：MTU、DataRate 和 Delay。我們將使用標準 MTU（無巨型幀，有時可用於特定網路）、千兆位元和 2 微秒的延遲。 2 微秒的原因是光傳播 600m，而其他研究則使用 0 延遲。
新頁
結果如下：
我們觀察到發送的 14720、147200 位元組的 UDP 吞吐量超過了 1000Mbps（我們的頻寬是 1Gbps）。然後我們查看了資料包的遺失情況
我們可以看到，在 147200 位元組中，100 個資料包中有 97 個遺失了。可以肯定地說，我們應該放棄這兩個並進一步調查
我們還可以看到 TCP 吞吐量逐漸增加並穩定在 400Mbps 左右。
由於缺乏流量控制，UDP 封包可能「卡在」較低層的佇列中。結果也可能是由於我們快速、始終在線的發送資料包導致擁塞。需要進一步調查來確認，例如降低緩衝區以查看延遲是否實際上增加。
平均延遲在“峰值”之後出現下降，然後再次逐漸增加。這可能是由於擁塞避免中的cwnd調整。需要進一步調查，因為我們需要確認擁塞控制演算法實際上會產生這樣的模式，因為ns-3中有很多選擇（Veno、Cubic...等）
隨著系統“穩定”，平均抖動預計會減少，延遲的變化也會減少。
UDP中沒有流量控制意味著資料包將連續地壓入堆疊並在不受干擾的情況下發送，延遲的變化應該很小，而由於所述流量控制，連續資料包的資料包延遲可能很大。
新頁
BulkSendApplication確保一旦下層發送緩衝區被填滿，它就會等待。因此，我們唯一可以丟棄資料包的地方是在我們需要引入錯誤的通道中。
UDPClient沒有這樣的流量控制，因此我們可以觀察資料包的遺失情況。
可能只是吞吐量（更高的吞吐量）和抖動（更少的延遲變化）。較大的平均延遲主要是由於缺乏流量控制，QUIC 旨在將「擁塞控制演算法移至用戶空間…而不是核心空間」 1 。
https://github.com/alfredtso/ns-3-project
新頁
ns-3 培訓資源
HTTP/3 草案
快 ↩ ↩ 2
QUIC GoogleDoc ↩
Yuan-Cheng Lai、Ahsan Ali、Md. Shohrab Hossain、Ying-Dar Lin，軟體定義網路上TCP 和UDP 流的效能建模和分析，網路與電腦應用雜誌，第130 卷，2019 年，第76-88頁，ISSN 1084-8045 ↩
Jingyi He，S.-H.Gary Chan，光分組交換網絡上互聯網的 TCP 和 UDP 性能，計算機網絡，第 45 卷，第 4 期，2004 年，第 505-521 頁，ISSN 1389-1286 ↩
Eric Gamess、Rina Surós，IPv4 和 IPv6 中 TCP 和 UDP 吞吐量的上限模型，網路與電腦應用雜誌，第 31 卷，第 4 期，2008 年，第 585-602 頁，ISSN 1084-8045 ↩ ↩ 2
Shahrudin Awang Nor、Raaid Alubady、Wisam Abduladeem Kamil，4G 網路上 TCP、SCTP、DCCP 和 UDP 協議的模擬性能，Procedia 計算機科學，第 111 卷，2017 年，第 2-7 頁，ISSN 1877-0509 ↩
