去年看到過一篇文章[1]，說是通過OpenVSwitch的測試，GENEVE的性能要略優於VXLAN。我相信大多數人的反應可能跟我的第一反應一樣，這不又是一種Overlay協議嗎？為什么性能會更好？難道有什么黑科技？我們這次來分析一下GENEVE有什么不一樣。
網絡虛擬化
要說清楚來龍去脈，需要從網絡虛擬化開始說起。網絡虛擬化（Networking Virtualization）是在一個underlay網絡上划分出多個overlay網路。原本只支持一套網絡的設備，通過網絡虛擬化，現在可以用來支持多套網絡。網絡虛擬化本身不是一個新的技術，從其誕生之日起，各種各樣的協議就被提出，遠的有VLAN（IEEE 802.1Q）、MPLS（RFC3031），近的有VXLAN（RF7348）、NVGRE（RFC7637），STT。那究竟是網絡虛擬化的什么特性，導致了這么多相關的協議被提出？
如果我們把網絡中的所有節點看成一個分布式系統，那么underlay網絡為這個分布式系統的各個節點提供了網絡連接。而各種各樣的網絡虛擬化協議，則為這個分布式系統的各個節點提供了通信所使用的協議。比如說，在一個雲環境里面，所有的服務器共同組成了一個部署虛機的分布式系統。underlay網絡連接這個分布式系統的各個節點（各個服務器），而網絡虛擬化協議用來封裝各個節點之間傳遞的數據（虛機之間的網絡數據）。
虛機間的網絡數據基本都是以太幀，但是不同的應用場景，系統規模，對於協議的要求也不一樣。所以才會有這么多網絡虛擬化協議。目前的各種網絡虛擬化的協議，本質上來說都是一樣的。那就是，以一定的格式封裝原始網絡數據，再輔以一定的元數據（metadata），來實現附加的功能。元數據對於網絡虛擬化來說不是一個陌生的概念，網絡標識符（Virtual Network Identifier，VNI）就是一種元數據。通過VNI可以識別並隔離多個租戶（tenant）網絡。
現在比較流行的網路虛擬化協議是VXLAN，有24bit的VNI，可以對應1600萬個不同的tenant網絡。VXLAN的提出常常說是為了解決VLAN（12bit VNI）所提供的租戶網絡數不夠的問題。現在來看1600萬這個數字是足夠大了，但是能保證以后一直夠用嗎？因為在VLAN被提出的時候，4000多個租戶網絡已經很夠用了。只是隨着雲計算和數據中心規模的發展，漸漸變的不夠用。那么激進點看，隨着技術的發展，24bit的VNI會不會也有不夠用的一天？
退一步說，就算24bit的VNI是夠用的，現在一些新的應用需要網絡虛擬化協議里面攜帶其他的元數據。例如加入port ID來作為安全規則的識別符。假設port ID是16bit，那24bit的VNI只剩下8bit用來標識租戶網絡，這明顯是不夠用的。
所以，盡管現有的網絡虛擬化協議能滿足當前的需求，但是隨着技術的發展和使用場景的變化，並不能保證它們能夠一直滿足需求。解決辦法有兩種，一種是到時候再定義新的協議，另一種是定義一種靈活，可擴展的網絡虛擬化協議。GENEVE采用的是后者。
GENEVE
GENEVE這個單詞對應的是瑞士城市日內瓦，但是這個網絡協議本身與日內瓦應該沒什么關系。這個單詞是Generic Network Virtualization Encapsulation的簡稱，對應中文是通用網絡虛擬化封裝，由IETF草案定義[2]。
GENEVE的作者稱，他們考慮了所有可能的應用場景，發現一個固定長度的元數據（例如前面提到的VNI）不能適應所有可能的場景。同時，他們也參考了買二手游戲平台地圖其他一些常青的協議，例如BGP，LLDP，IS-IS。這些協議已經存在幾十年了，並且現在還很流行。背后的原因在於，這些協議並不是一成不變，而是隨着技術的發展，支持了新功能的擴展。例如BGP，最基本的路由選擇算法一直沒有改變，但是卻從只支持IPv4到支持IPv6，VPNv4,VPNv6等其他地址族。
所以，他們提出了一種網絡虛擬化協議，這個協議的元數據本身是可擴展的。這樣，就算需求變化了，這個協議也能擴展以滿足需求。這個協議就是GENEVE。
在實現上，GENEVE與VXLAN類似，仍然是Ethernet over UDP，也就是用UDP封裝Ethernet。VXLAN header是固定長度的（8個字節，其中包含24bit VNI），與VXLAN不同的是，GENEVE header中增加了TLV（Type-Length-Value），由8個字節的固定長度和0~252個字節變長的TLV組成。GENEVE header中的TLV代表了可擴展的元數據。我們來看一下GENEVE header：
- Version（2bit）：沒什么好說的，目前是0
- Opt Len（6bit）：以4字節為單位，表明Variable Length Options的長度。因為只有6bit，所以Variable Length Options最多是252（63*4）字節。
- O（1bit）：表明這是一個OAM包，包含了控制信息，而非數據。Endpoint可以根據這個bit來優先處理這個包。
- C（1bit）：表明在Variable Length Options里面，存在一個或者多個Critical的option。當C被置位時，Variable Length Options必須被解析，如果當前Endpoint不支持GENEVE解析，那么應該丟棄數據包。如果C沒有被置位，那么Endpoint可以根據Opt Len直接丟棄所有的Variable Length Options。
- Rsvd.（6bit）：保留字段。
- Protocol Type（16bit）：被封裝的協議類型，例如Ethernet就是0x6558。這個字段的存在，使得GENEVE封裝其他的二層協議成為可能。
- VNI（24bit）：老朋友了。
- Reserved（8bit）：保留字段。
- Variable Length Options：由TLV構成，包含了可擴展的元數據。
性能考慮
從協議格式可以看出，GENEVE與其他網絡虛擬化協議的主要區別在於一個長度可變的header。這使得GENEVE變得靈活，可擴展。但是可擴展和高性能從來都是矛盾的。因為可擴展意味着更多的元數據來支持更多的功能，而高性能卻要求更少的數據傳輸和處理。對此GENEVE定義了O和C位（參見上面協議格式分析），使得Endpoint能夠更靈活的處理數據，以減少額外的元數據對性能帶來的影響。
控制層考慮
盡管某些網絡虛擬化協議里面包含了對控制層的描述，例如VXLAN（RFC7348）就包含了一個基於組播的learn-flood控制層，但是在實際使用中，這些協議通常只被當做數據格式的描述。試問多少人知道RFC7348里面有基於組播的flood-learn？
另外，在VXLAN的使用過程中，控制層可能有很多種，例如EVPN，例如SDN controller。這兩種控制層比基於組播的控制層要流行的多。而所有這些控制層之間的差別是巨大的。
所以，GENEVE的作者認為，GENEVE應該只關注協議數據格式。他們力求設計一種適用於多種控制層的協議，而非只針對某一種控制層。這樣就算控制層變化了，協議本身也不至於被棄用。
underlay負載均衡考慮
幾乎所有的underlay網絡（例如CLOS架構）都會利用多條等價路徑（ECMP）來提高傳輸的並發性。我們把兩個虛機之間的一個傳輸層連接稱為一個數據流。為了達到最好的負載均衡的性能，不同的數據流應當被分布到不同的線路上。而相同的數據流應當被分到同一個線路上，這樣才能保證數據的順序，減少不必要的確認重傳。
對於GENEVE來說，因為Ethernet Frame被封裝在UDP里面，ECMP設備看到的不是虛機的IP/MAC，而是Tunnel Endpoint的IP/MAC。每個Tunnel Endpoint可能連接多個不同的虛機，而對於兩個相同Tunnel Endpoint之間的網絡流量，在underlay網絡上唯一能看到的不一樣的地方就是外層UDP的source port。因此，GENEVE規定，使用外層UDP的source port用來標識實際的數據流。首先，對於同一個數據流來說，外層UDP的source port應該是一樣的，其次這個UDP source port，應該根據實際的數據流計算得出，例如根據數據流的五元組。這樣，ECMP設備不需要讀取內層報文的信息，只需要根據外層UDP的source port，就能完成ECMP的路徑選擇算法。而這個時候的UDP source port，也不再標識一個UDP連接，而是用來標識overlay的數據流。為了減少重復，GENEVE協議認為應該使用source port的整個16bit（而不是常用的50000-65535）。
兼容性考慮
如果你熟悉VXLAN或者NVGRE的協議格式，你可能已經發現了，如果不考慮Variable Length Options，GENEVE與VXLAN還有NVGRE是不沖突的。特別是VXLAN，也是將Ethernet Frame封裝在UDP里面，這樣，一些現有的針對VXLAN的優化，例如硬件offload，RSS，可以直接應用在GENEVE上。
OVN
OpenVSwitch的衍生項目OVN（Open Virtual Network）應該是GENEVE的最大擁躉。本文最開始提到的文章[1]，也是出自OVN的開發人員。根據OVN的文檔[3]，OVN只支持GENEVE和STT作為網絡虛擬化協議。這是因為OVN除了24bit的VNI之外，還要在overlay數據中傳輸15bit的源網絡端口，和16bit的目的網絡端口，以支持更高效的ACL和組播。GENEVE因為是可擴展的，自然是支持傳遞額外的元數據。STT因為本身的元數據是64bit的，也放得下OVN想要傳遞的內容。至於其他的協議，例如VXLAN，NVGRE，是沒有可能滿足OVN的需求。
我們再回過頭來看看[1]，為什么測試結果顯示GENEVE性能要略優於VXLAN。由於VXLAN的普及，目前支持GENEVE的硬件不多，所以測試都是在支持VXLAN RSS的網卡上進行。並且在測試中，GENEVE還額外傳遞了OVN所需的15bit的源網絡端口，和16bit的目的網絡端口，也就是說，GENEVE傳遞的數據更多。
盡管有這些因素的存在，GENEVE的結果要好於VXLAN。首先，這個結果表明了，GENEVE能很好的兼容VXLAN，因為就算是VXLAN的主場，GENEVE最后還是贏了。但是兼容性並不能解釋最后的現象，文章本身也沒有分析原因，只是提到了UDP checksum。OVN默認打開了GENEVE上的UDP checksum。因為Linux系統內核的一些優化，使得GENEVE數據包被網卡收到之后，網卡會計算並驗證外層UDP的checksum。如果驗證通過了，網卡會匯報給系統內核。這樣系統內核在解析GENEVE時，將不再計算內層報文的任何checksum。相應的網絡數據處理會更快一些。而VXLAN協議規定外層UDP的checksum應該為0，這樣外層UDP的checksum就沒有辦法被驗證，而內層報文的checksum需要再計算一遍，相應的網絡數據處理就要慢一點。