posted

0 Comments

作者: 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上傳輸,有更深一層的了解。