一個IP封包如何跨越萬水千山達到目的地？本文将以阿裡雲為例，帶領大家一起探索同地域内雲上通信的全過程，完整展現雲上同地域内各種場景的IP封包之旅，深入了解雲網絡技術、産品和通信。
前言
試想一個場景，雲上北京的一台機器要通路廣州的網站（可能在當地公網，也可能在同一朵雲的廣州節點上），這個封包的生命周期會是什麼樣，它究竟會如何跨越萬水千山達到目的地？旅途中又會經過哪些不同種類裝置，這些裝置都對封包做哪些修改，為何做這些修改，為什麼需要這麼設計？
而随着目的地的不同，通信場景的不同，封包的旅途具體可以抽象出哪幾類，每一種場景裡具體要做哪些設計考慮，需要解決哪些關鍵問題。對于從事雲計算或通信行業的人來說，我想這樣的問題或多或少有思考過，尤其對于長期從事傳統網絡而對雲的這種Overlay網絡知曉相對不是很多的讀者，我想對于這樣的一系列問題心中很可能有所疑惑和一定好奇。
說到标題裡的“神奇”二字，公有雲網絡流量的走向路徑與傳統IDC網絡有較大不同。公有雲網絡一般有數十個地域，近百個可用區機房，數百款具體産品，流量之間互通的場景多種多樣，而為了提供高性能、高帶寬、低延時、擴充性強、雲原生化、高安全性、私密性等特點的轉發功能，需要在很多層面（雲産品架構、晶片架構、網絡架構等等，如下圖）進行精心設計。從這個角度看，一個IP封包在公有雲上的整個生命旅途，确有其神奇之處。而本文主要聚焦于全鍊路層面。
另外，在處理雲上疑難問題時，經常會碰到全鍊路問題，通路路徑複雜，會經過很多台裝置（包括CDN、安全裝置、各類網絡裝置、各類網關、虛機内容器節點，甚至多雲互聯等），不同裝置經常對封包做修改，以及雲計算技術本身的抽象性（提供給使用者的界面和操作很簡單，但底層的層層封裝和設計考慮往往很複雜），這些共同原因導緻很多全鍊路問題處理起來比較耗時。
整體上看，如果對一個IP封包在雲上的整個旅途有一種完整的全鍊路視角，帶着這樣的視角剖析雲上各種場景的IP封包之旅，将旅途完完整整的展示出來，不僅能加深對雲網絡技術、産品和通信的了解，也會很大程度協助排查雲上的諸多複雜全鍊路問題。
具體來說，IP封包在雲上的旅途包括非常多場景：例如同地域VPC内及VPC之間，通路公網（Public IP/EIP/NAT），通過專線通路線下IDC等混合雲場景，通路雲服務場景，通路SLB/ALB場景，CEN TR場景，雲防火牆&CEN TR結合場景，容器網絡場景等等。
本文将以阿裡雲為例，介紹同地域内雲上通信，同VPC（包括同交換機，不同交換機）及不同VPC之間流量互訪的詳細封包旅途、表項設計、封包封裝，以及相應的思考
下圖為阿裡雲網絡産品體系架構，可以通過此對阿裡雲主要雲網絡産品的總體分類有個基本認識，以及對一個封包跨越機房轉發的軌迹有個大緻的畫面。
場景一：同VPC，同VSW
2.1 背景介紹
圖中的源ECS（雲伺服器）和目的ECS是屬于同一VPC（虛拟專用網）且同VSW（虛拟交換機）。因為是同一虛拟交換機，是以肯定是在同一可用區（同一IDC機房）内。
然後ECS互相ping對方，比如左邊192.168.255.176 ping 192.168.255.169.
我們一起看下這中間，流量從起始後經過的每台Overlay節點裝置需要檢視的轉發表項和實際抓包封包細節。分為路由層面和轉發層面來看，先看路由層面。
2.2 路由層面
✪ 阿裡雲網絡通信
在檢視表項之前先看下面的兩張圖：
首先，阿裡雲網絡是一張非常龐大的Overlay網絡，雲上端到端的通信都是Overlay通信，需要特别關注VPC的tunnel-id，VPC的路由表等。而每個VPC都有一個唯一的tunnel-id。VPC的路由表預設會包括所屬每個虛拟交換機的網段，以及雲服務位址網段。
如下圖所示，阿裡雲上網絡通信的一個基本原則就是相同tunnel-id（相同VPC）的流量預設可以通信，不同tunnel-id（不同VPC）的流量預設不能通信。這也是阿裡雲為了做到不同使用者業務完全隔離的基本技術手段。當然，相同VPC内的流量也可以通過比如網絡ACL、安全組等手段來限制通信，不同VPC的流量也可以通過建立對等連接配接、加入雲企業網CEN等手段來實作互通。
✪ 源ECS 路由表項
封包從源ECS發出去，需要檢視路由表，上面是源ECS路由表項，可以看到源ECS上隻有一條預設路由，指向192.168.255.253這個網關位址，那這個是什麼位址？
這其實是個虛位址，可以大緻了解為阿裡虛拟轉發交換機vSwitch上的位址，是以下一跳需要檢視這台vSwitch的相關表項。
這裡的虛拟轉發交換機和VPC配置中的交換機含義不同，前者為一套龐大軟體元件，需要完成非常多核心轉發功能，而後者其實并不存在具體對應的某個交換機被雲執行個體所挂，隻是VPC管控層面為雲執行個體自動配置設定的一個屬性，一個交換機一個網段，這樣可以便于使用者從high-level層面進行網段規劃，業務規劃群組網設計等。
✪ 阿裡虛拟轉發交換機vSwitch（也常稱AVS）
首先它是阿裡自研虛拟交換機（可類比OVS），以軟體形态在實體伺服器内部署，承擔Overlay的封裝/解封裝、ECS安全組、路由表項查找、bps/pps等名額跟蹤、session維護等等非常多的重要功能。它是伺服器内部網絡的核心元件，整體負責伺服器内部ECS流量的轉發和交換。如下圖所示，存在Slowpath和Fastpath。
1）Slowpath：基于route/ACL和業務邏輯決定轉發行為，首包需要走Slowpath
2）Fastpath：基于Slowpath生成的session做match/action，有session之後直接走Fastpath轉發非常高效
✪ 阿裡vSwitch（AVS）表項簡要介紹
如下圖所示，在實體機内每台ECS的每個網卡會連接配接到AVS上的一個虛拟接口（接口名和ECS網卡的mac位址有映射關系），封包到達AVS後，會在AVS内部依次查找多個表項，在不考慮配置多路由表/子網路由（類似政策路由，可根據源位址段做轉換）的情況下，一般來說，主要會檢視路由表、VTEP映射表。接下來簡要說下各自的用途：
1）表1 路由表，根據tunenl-id來查找，也就是說這上面包含有多個VPC的路由表，那麼一台AVS有多少tunnel-id的VPC路由表，實際上包括該實體機上所有ECS所屬的VPC以及他們通過其他手段學習到的其他VPC的路由表。對于本VPC所屬的交換機網段位址，這些VPC路由的下一跳為0.0.0.0，即繼續查找表2。
2）表2 VTEP映射表，存放着要去往的目的位址所對應的實體機位址，用于做Overlay封裝使用。最開始，這裡面并沒有表項，但是通信第一次之後，會通過VPC Gateway學習到目的地所對應的實體機位址。
如下圖，包括所有路由表、安全組等非常多的資訊都是通過VPC管控進行下發，必要時也會和ECS管控、雲企業網CEN管控等其他控制器進行聯合工作。如前面所說，雲網絡是一種非常龐大的Overlay網絡，上層有各個産品的控制器進行管控，充分利用SDN思想的核心優勢，讓裝置配置、表項、路由表等等資訊的下發變得更加靈活，同時也得以支援超大規模雲網絡。
✪ 場景一整體通信過程梳理
當源ECS把包發給所在實體機的AVS後，AVS檢視表項，先查路由表，下一跳為0.0.0.0，接着查表2。如果已經通信過一次，那麼表2會有目的ECS與其實體機位址的映射關系。然後開始封裝Overlay封包，内層源目的為私網ip，外層的源位址為本實體機位址，目的位址為目的實體機位址。如果沒通信過，會先通過VPC Gateway進行學習映射表。
當實體機裡的vSwitch收到封包後，根據封包裡的tunnel-id查找相關VPC-id的表項（此場景下與目的ECS屬于同一VPC），因為目的位址是該VPC的交換機網段位址，是以下一跳也為0.0.0.0，接着同樣是檢視VTEP映射關系表，由于目的位址為本AVS的虛拟接口所連接配接的ECS，是以表項裡會對于目的位址為這樣位址的下一跳設為該虛拟接口，從該虛拟接口轉發給目的ECS。
✪ 回包路程
原理一模一樣，例如目的ECS的路由表項，和源ECS非常類似，也是通過預設路由發給.253的位址。然後一路傳回同樣采用Overlay技術封裝，由本實體機位址直接發送到源實體機位址。
2.3 轉發層面
✪ 源ECS&目的ECS抓包
注意ip.id 20953，辨別這個封包，後續抓包通過這個id來說明是同一個封包。
✪ 源ECS連接配接的實體機内vSwitch抓包
可以看到原始封包包在裡面，外面是一層Overlay封裝，最外面是外層源目的ip位址，為源實體機位址-->目的實體機位址，tunnel-id為源ECS所屬的VPC tunnel-id 504301.
根據ip.id可以和ECS上抓的包對應起來，是同一個封包。
✪ 目的ECS連接配接的實體機内vSwitch抓包
通過時間，内層ip.id，外層ip.id都可以看出這個包就是上面源vSwitch發出的包。
通過四個點的同時抓包可以看到，封包的走向和表項分析的路徑一樣：源ECS-源AVS-實體機1--實體機2-目的AVS-目的ECS。
2.4 通信路徑總結
簡單來說，對于同VPC，同VSW，邏輯通信路徑是：ECS1 → 源AVS → 源實體機 → (VPC Gateway) → 目的實體機 → 目的AVS → ECS2。
對于實體通信路徑，因為源和目的屬于同一可用區/機房，流量直接在機房内進行轉發，也就是近年流行的3層CLOS架構。
另外，為何封裝了外層目的位址實體機位址後，實體網絡就知道怎麼轉發，原因是實體機位址段都已通告在underlay網絡，是以underlay網絡知道如何轉發到相應實體機位址。
是以其實不管底層實體網絡跳數有多少，從上層來看，非首包是一跳到位，直接從源實體機發到目的實體機，對于首包來說則是兩跳，中間要經過VPC網關裝置。是以這也是在盡可能簡化通信，減小通信複雜度，隻是這其中各種表項的定義和學習同步需要精心設計。
場景二：同VPC，不同VSW
3.1 背景介紹
場景二裡的源ECS和目的ECS屬于同一VPC，但屬于不同虛拟交換機，即處于不同細分網段中，在這裡同時處于不同可用區/機房。
3.2 路由層面
1）從Overlay層面和檢視表項層面，其實這種場景和場景一非常類似，原因在于AVS上的表1路由表裡會有VPC管控自動下發的本VPC裡所有交換機的位址網段路由，下一跳都指向0.0.0.0，也就是表2. 是以源和目的AVS在查表1的時候都是直接指向表2，然後根據表2的表項内容進行封裝和轉發。
2）差別在于這兩種場景的實體通信路徑不一樣（如果屬于不同VSW同時也屬于不同可用區的話），因為源和目的是不同可用區，就會多經過一個專用的連接配接不同可用區做内網通信的網絡裝置，加上每個可用區機房都要經過一次3層CLOS架構的裝置，整體實體跳數會更多，延時相應的也會更大。
3.3 轉發層面
下面通過幾個節點的抓包來驗證通信路徑是否如上述分析一樣：
✪ 源ECS抓包
注意鎖定這裡的ip.id 36495
✪ 源ECS連接配接的源AVS抓包
注意ip.id 36495，可以看到同樣是和場景一一樣，外面包一層Overlay封裝，外層源目的IP是本實體機位址 → 目的實體機位址。
✪ 目的ECS連接配接的AVS上抓包
注意ip.id 36495，可以看到這就是上面那個包。
目的AVS拆掉Overlay封裝，把裡層的封包發給虛拟接口所連接配接的ECS（根據内層目的IP位址可進行路由找到出接口是連接配接目的ECS的虛拟接口）。
✪ 目的ECS上抓包
3.4 通信路徑總結
1）和場景一類似，也是首包過VPC Gateway，對于非首包，直接從源實體機到目的實體機進行Overlay封裝，并沒有額外步驟。
具體來說，路徑也是為 ECS1 → 源AVS → 源實體機 → (VPC Gateway) → 目的實體機—目的AVS → ECS2。
2）是以隻要是同一VPC内通信，不管是不是處于同一VSW虛拟交換機，是不是同一可用區，底層邏輯通信和封裝結構并沒有明顯差別。當然，實體通信路徑會多經過一些跳數（如果不同可用區），延時會更大一點。
場景三：不同VPC，同地域
4.1 背景介紹
這裡的ECS1和ECS2是同地域的不同VPC，一般來說，可以通過對等連接配接/VPC互聯，CEN1.0、CEN2.0/CEN TR這三種方式進行通信。
前兩種方式的底層通信路徑比較類似，是以這裡直接選用采取CEN1.0的方式互通進行剖析。
4.2 路由層面
✪ 源ECS路由表項
和場景一類似，到達目的地172.16.7.98會通過預設路由送往.253位址。
✪ 目的ECS路由表項
同樣和場景一類似：
✪ 源vSwitch/AVS表項
1）首先也是檢視表1路由表；
2）在這裡就和前兩種場景不同，此時的目的位址段不是源VPC裡的交換機網段位址，而是另一個VPC的位址段，那麼它是否會出現在源vSwitch的路由表裡？
這就要看源VPC是否有學習到目的VPC的路由表，學習方式一般有對等連接配接、CEN1.0、CEN 2.0 TR。對等連接配接方式需要手動在兩邊的VPC路由表裡添加到對端網段的路由，CEN方式會自動進行學習（隻要源目的VPC加入同一個CEN）。
那麼這裡，是采用CEN1.0方式學習，是以源VPC的路由表裡會出現對端VPC網段位址，下一跳為對端VPC的tunnel-id，非常關鍵，在這個場景裡為371185（源VPC tunnel-id為504301）；
3）查到下一跳為對端VPC的tunnel-id後，封包會交給CEN網關（VPC Gateway），Gateway會轉發給目的實體機；
4）同理可以推斷，目的AVS上的表項回包到源ECS位址，路由表裡下一跳是源VPC的tunnel-id 504301，也是發給網關Gateway。
4.3 轉發層面
✪ 源ECS上抓包
鎖定ip.id 17001
✪ 源vSwitch上抓包
因為這非首包，是以外層目的位址直接為目的實體機位址 11.246.47.134
要特别注意，源AVS發出去的包裡的tunnel-id為371185，而并非504301，也就是說源vSwitch發出去的包，第一步直接就把tunnel-id置為對端VPC的tunnel-id。
✪ 目的vSwitch上抓包
根據ip.id 可以和前面的包完全對上，外層源目的IP位址為源實體機位址 → 目的實體機位址。
✪ 目的ECS抓包
目的ECS收到的是目的vSwitch解掉Overlay封裝後的封包，ip.id可以對上。
4.4 通信路徑總結
1）同地域跨VPC場景和場景一二類似，也是首包過VPC Gateway同時進行路由自學習；對于非首包，直接從源實體機到目的實體機進行Overlay封裝。
2）不同的是，源vSwitch上查詢路由表項的時候，會先找到對端VPC的tunnel-id，交給CEN網關/VPC Gateway轉發給目的地。
至于為何阿裡vSwitch上有這個路由表項，原因則是通過CEN1.0學習後，相關管控會下發此表項到相應的vSwitch上。
是以vSwitch上已經有通過一些方式學習到的其他相應VPC的目的字首位址的表項，其中并非所有VPC的位址段都會存在，否則也就起不到隔離的作用。
3）以CEN1.0為例，某個VPC和哪些其他VPC一同加入同一個CEN執行個體且控制政策允許學習，那麼該VPC的tunnel-id對應的vSwitch路由表裡就會出現目的字首為其他VPC的網段，下一跳為所學習到的VPC各自的tunnel-id。
簡單來說，對于同地域不同VPC場景，邏輯overlay通信路徑和場景一二基本一緻，同樣也是：ECS1 → 源AVS → 源實體機 → (VPC Gateway) → 目的實體機 → 目的AVS → ECS2。
從實體路徑來說，隻是跨VPC，源和目的可能處于同一可用區，也可能屬于不同可用區，是否經過更多跳數并不确定，需要看是否跨可用區。
從這裡也可以看出，雲網絡的不同租戶業務隔離通過VPC實作，而VPC通過tunnel-id隔離。經過上面的探索過程，可以看到本質上，其實是通過底層裝置的路由表進行隔離，對其他VPC網段又沒有進行學習過的，vSwitch本VPC的路由表裡就不會出現那些網段的路由，是以無法把封包發到目的地，也就實作了業務隔離。
進一步思考
雲網絡兩大基礎轉發元件
雲網絡的基礎轉發元件主要包括兩部分：虛拟轉發交換機vSwitch和雲網關Gateway（也常稱XGW）。
5.1 虛拟轉發交換機vSwitch
vSwitch本質上是一種Host Overlay技術，而實際上還有硬體Overlay等其他Overlay技術，那麼這兩者有何不同，為何公有雲偏向選擇Host Overlay？
1）硬體Overlay
為了滿足雲資料中心網絡虛拟化的隔離需求，傳統網絡裝置商提供了VxLAN隧道端點在硬體裝置上實作的方案，虛拟化主機通過VLAN進行本地多租戶隔離，在接入交換機上進行VLAN和VxLAN的映射轉換，在核心層僅需完成IP轉發（對東西向流量）。這種方案和傳統網絡模型較為接近，部署運維上變化較小，但由于受限于交換機的轉發和封裝規格資源限制，該方案隻适合中型資料中心，無法滿足公有雲的大規模應用訴求。另外虛拟網絡特性釋出仍受限于硬體開發周期，對雲上網絡的進階特性如安全組、子網路由無法較好支援，是以目前僅存在于一些特性要求較為簡單的私有雲解決方案中。
2）Host Overlay
指在Hypervisor上部署虛拟化交換軟體，控制器将租戶VxLAN轉發配置下發到虛拟交換機上，在Host上軟體交換機完成VxLAN隧道端點的封裝和解封，進而完成虛拟機之間、虛拟機到邊界網絡的流量轉發。這種實作方式對實體網絡僅僅需要IP可達即可，而不再受制于實體交換機支援Overlay特性的規格限制。同時基于Host技術方案實作的Overlay相比于硬體Overlay技術方案而言更加靈活，能很好的滿足在硬體交換機上較難實作的安全組、flowlog、子網路由等特性。
5.2 雲網關Gateway
前面一直提到的雲網關Gateway實際上有多種角色，有VPC Gateway，負責VPC流量的首包兜底轉發及映射表學習，公網Gateway負責公網流量轉發，專線Gateway負責專線以及跨Region流量的彙聚和分發。因為有多種Gateway角色是以有時也把他們都統稱XGW。Gateway和AVS一起為客戶搭建一張龐大的虛拟專用網絡。
5.3 關于Gateway底層形态的演進
1）雲網關Gateway是雲網絡流量入口，也是雲網絡帶寬壓力和穩定性壓力最大的一環。
如前面所說，Gateway的流量包括公網流量、專線流量、跨Region VPC互聯流量。和雲網絡的其他元件一樣，Gateway也是從x86軟轉開始。由于Gateway的性能要求較高，阿裡雲的Gateway跳過了kernel，第一天就開始使用DPDK平台，全自研網關軟體。和其他基于x86+DPDK做軟轉發的雲網絡産品一樣，Gateway的問題也是CPU存在單核性能瓶頸，在大流量和攻擊流量場景下CPU可能會被打滿，引起故障。随着大型企業上雲增加，專線流量出現了數量級的增長，達到數十Tbps。Gateway作為雲網絡的流量入口，面臨的性能和穩定性迫切需要優化。
2）阿裡雲軟硬一體Gateway：
為應對超大流量的挑戰，雲網絡基于可程式設計交換晶片的Gateway設計，成功實作了Gateway的軟硬結合設計。
通過加速，Gateway單機bps性能提升20倍，單機pps性能提升80倍，延時降低25倍，叢集能力提升5倍，整體Capex和Opex大幅降低。硬體網關的業務價值可以歸結為以下幾個方面：
- 大流量（例如阿裡雙11/大客戶數Tbps～數十Tbps的上雲流量）
- 大單流（例如IoT場景的GRE tunnel，單流數Gbps～數十Gbps）
- 穩定性（沒有軟轉發的CPU打滿隐患）
- 低延時/低抖動（硬體網關的管道足夠粗，客戶上雲絲般柔滑，沒有卡頓，就像高速公路的車道足夠多，車輛行駛一路通暢，沒有排隊/沒有阻塞）
結尾
總結來說，雲上同地域的通信，首包要通過VPC網關轉發，同時源虛拟轉發交換機和目的虛拟轉發交換機都通過内部私有協定學習到對端ECS的VTEP映射Peer位址，這樣從第二個包開始就可以直接進行Overlay的外層封裝到目的ECS的實體機（簡單來說，後續通信是直接一跳到位），然後實體機裡的vSwitch根據封包裡的tunnel-id去查找相關VPC-id的表項，再根據封包的目的位址找到對應的虛拟接口，發給對應的目的ECS。同時在虛拟交換機内部非首包也會因為有session的存在走Fastpath性能更強延時更低。
除以上介紹，雲上通信的場景種類還有非常多，例如通路公網（如下圖1）、各種混合雲場景（專線通路線下IDC等，如下圖2）、通路SLB/ALB後端服務、雲服務通路等等，這裡面各自需要解決比如限速、導流、位址轉換、路由表規模、東西向服務鍊等等問題，IP封包在這些場景下的旅途會更加漫長和複雜，但也更加有趣和精彩。
下圖為混合雲幾種場景的拓撲圖：