作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與SD-WAN方案的介紹與推廣。

上一篇內我們討論的是UDP型態的語音 / 影像類的網路流傳輸保護，這一篇我們要就TCP型態，要確保資料可靠度，比如說交易資料、檔案傳輸等，Velocloud會如何優化呢？與前篇同樣地請大家參考下圖：

在Transactional與Bulk這兩大類，如果應用的優先權被設定為High，Velocloud就會啟用NACK (Negative Acknowledgement) 機制。要解釋NACK機制是在做什麼，我們要先複習一下TCP的基礎運作機制 :

 

  • 因為要確保可靠傳輸，TCP表頭內會有sequence number讓目的端確認傳輸的封包有沒有遺失。

 

  • TCP網路流發動時，一開始的傳輸率不會很大，但隨著封包傳輸都沒有錯誤，目的端就會告訴來源端，可以將發送的封包變更大，傳輸率就會提升。

 

  • 但如果出現了丟包，目的端就會發動TCP Retransmission機制，此時除了要求來源端重新發送遺失的封包外，也會要求降低封包大小，也就降低了傳輸率。

 

  • 也因此，如果網路鏈路上出現丟包情況，那透過TCP的機制雖然還是能夠確保可靠、正確的資料傳輸，但是傳輸的頻寬就會大幅下降了。

 

NACK機制就是要解決這個問題，但我們放到最後再來解釋。這個實驗同樣需要實驗組與對照組，網路配置像下面這樣：

從Branch-03-Linux (10.100.103.12)往右上角的 Hub-01-Linux (10.100.101.12) 間，是有建立Velocloud DMPO Tunnel（綠色虛線），受到保護與優化的線路。但從左下角的Branch-06-Linux (10.100.106.12)往Hub-01-Linux間，就是一般未受優化、未受保護的線路。

 

在這個實驗內，我們利用廣域網路模擬器，把Branch-03的Internet線路，以及Branch-06的MPLS線路都調為30 Mbps，然後分別將Packet Loss以0% / 1% / 3% / 5%來進行測試。在來源端的Linux上，我們利用scp指令，遠端複製一個約70MB的檔案回到本地。

 

首先看正常環境內，沒有受到Velocloud保護的線路（前面的Branch-06紅色線），在這樣的網路調包狀況下會有什麼情形。下面是測試結果的畫面

 

0% Packet Loss:

 

1% Packet Loss:

 

3% Packet Loss:

 

5% Packet Loss:

 

做這個測試好麻煩，時間有夠久…我們就不要談那些3% 5%的狀況了，大家可以看到，即使只有1%的掉包，傳輸頻寬與時間都會由於TCP Retransmission / TCP Windows的原因大幅受到影響。大家常常在網路線路即使只有小部分不穩，零點幾個百分底的掉包時都會跳腳覺得網路超慢，這就是很明顯的原因。

 

那受到Velocloud保護的線路呢？下圖內，我們把TCP的封包強制要求一定要走Internet線路（免得掉包嚴重時，應用透過link-steering的機制切到別的線路去），而且都配成Real-Time / Transactional （Bulk也沒問題）。在這種情形下，網路有掉包時，NACK機制會啟用：

 

 

 

做了這樣的設定後，我們在Branch-03-Linux內做與前面一模一樣的測試，結果如下：

 

0% Packet Loss:

1% Packet Loss:

 

3% Packet Loss:

5% Packet Loss:

 

有沒有發現，即使到了5%的Packet Loss（通常這個情形噢，線路都差不多被認定為不可用了），檔案傳輸的頻寬仍然有原本的六七成，有影響但沒有太大。我們把前面的測試做成表格，更是一清二楚：

 

 

在沒有Packet Loss的情形下，DMPO Tunnel傳輸的時間還比較長一點點（對，DMPO Tunnel是有overhead的）。但這樣的犧牲在線路品質有狀況時得到了巨大的回報，有Packet Loss的狀況內大檔案傳輸幾乎是不可用，但Velocloud保護的環境內只有部分的影響，說真的客戶可能完全沒有感覺。

 

為什麼能夠達成這樣的效果，簡單解釋一下NACK的機制：

 

  • 對於被設定為High / Transaction or Bulk形態的網路流，如果偵測到線路掉包出現，則啟用NACK機制。

 

  • DMPO Tunnel的串流來源端再送出封包時，DMPO表頭內會包含Sequence Number / Timestamp等等資訊。因此目的端的VCE可以透過資訊來去認是否有封包遺失。

 

  • 如果出現封包遺失，目的端VCE會直接告訴來源端VCE，請他重傳遺失的封包。目的端接收到所有封包後，還原成完全沒有掉包的網路流，再送給目的端的電腦設備。

 

  • 在上面機制內，TCP來源與目的端的應用設備都沒有發現有掉包。因此不會發動TCP Retransmission，TCP Windows調到最大，速率逼到最快。因此檔案傳輸的速率即使在掉包狀況下也不會受到太大的影響。

 

在前面幾篇我們把Velocloud的鏈路切換以及應用優化機制做了更完整的解說與展示，也希望讓大家對於SD-WAN方案為何能讓重要應用可靠且品質優良地在網域網路甚至Internet上傳輸，有更深一層的了解。