IPv4發(fā)展到今天已存在著諸多缺陷，比如地址枯竭、安全和服務(wù)質(zhì)量難以保證、路由膨脹等，這些問題將極大制約云計算等相關(guān)IT行業(yè)的發(fā)展。IPv6以其更大的地址空間、更高的安全性等特點(diǎn)，能夠很好的解決IPv4這些缺陷。

創(chuàng)新互聯(lián)專注于企業(yè)成都全網(wǎng)營銷、網(wǎng)站重做改版、劍河網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5網(wǎng)站設(shè)計、商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為劍河等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

UCloud于2018年上半年開始研發(fā)公網(wǎng)入口的IPv6轉(zhuǎn)換，依托NAT64技術(shù)和可編程P4交換機(jī)，現(xiàn)已成功推出了免費(fèi)的UCloud公網(wǎng)入口IPv6轉(zhuǎn)換服務(wù)。該產(chǎn)品功能簡潔易用，申請EIP后一鍵開啟IPv6轉(zhuǎn)換，無需任何改造，即可對外提供IPv6的訪問。目前，UCloud IPv6轉(zhuǎn)換服務(wù)已成功用于云主機(jī)、EIP、負(fù)載均衡、容器集群、堡壘機(jī)等產(chǎn)品。地域內(nèi)單集群（16臺NAT64服務(wù)器，4臺P4交換機(jī)）最高可實(shí)現(xiàn)3.2M CPS和1.6G的并發(fā)連接，且可在以后的演進(jìn)過程中平滑擴(kuò)容。

UCloud IPv6演進(jìn)戰(zhàn)略步驟

對于IPv6技術(shù)的預(yù)研與探索，UCloud早在幾年之前就已經(jīng)開始了，內(nèi)部已有完整的IPv6預(yù)研方案。但我們?nèi)孕枰逦恼J(rèn)識到網(wǎng)絡(luò)基礎(chǔ)設(shè)施的改造不是一蹴而就的，這里面不僅涉及到技術(shù)難題的攻克，其本身還是個非常巨大的工程問題。

而且最重要的是在不影響用戶現(xiàn)有業(yè)務(wù)的同時，讓用戶的業(yè)務(wù)慢慢的遷移至IPv6。正是基于這種考慮，針對IPv4到IPv6的演進(jìn)，UCloud制定了以下戰(zhàn)略：

1.2018年完成互聯(lián)網(wǎng)入口IPv6轉(zhuǎn)換服務(wù)，使UCloud超過百分之五十的產(chǎn)品能夠支持IPv6，客戶只需在EIP開啟IPv6轉(zhuǎn)換服務(wù)，無需更改任何業(yè)務(wù)即可使業(yè)務(wù)獲得對外提供IPv6訪問服務(wù)的能力，實(shí)現(xiàn)業(yè)務(wù)和IPv6網(wǎng)絡(luò)的平滑對接；

2.2018年完成管理網(wǎng)IPv6改造，使得依托于管理網(wǎng)的云產(chǎn)品諸如主機(jī)***檢測，容器鏡像庫等產(chǎn)品支持IPv6；

3.2019年完成UCloud主要產(chǎn)品支持IPv6，其中VPC、ULB（UCloud負(fù)載均衡）等重要產(chǎn)品將于2019 Q2之前支持IPv6，具備主動訪問IPv6網(wǎng)絡(luò)能力；

4.2019年完成IDC雙棧改造，使得數(shù)據(jù)中心內(nèi)部支持IPv6，提供完整的IPv6支持。

IPv6從技術(shù)到落地的過程中，UCloud做了很多工作，也遇到了比較多的挑戰(zhàn)。本文接下來將從技術(shù)的角度詳細(xì)介紹UCloud IPv6轉(zhuǎn)換服務(wù)的實(shí)現(xiàn)與優(yōu)化演進(jìn)。

UCloud IPv6轉(zhuǎn)換服務(wù)

◆ NAT64及其技術(shù)挑戰(zhàn)

在實(shí)現(xiàn)技術(shù)上，UCloud使用有狀態(tài)的NAT64技術(shù)來實(shí)現(xiàn)IPv6轉(zhuǎn)換服務(wù)，NAT64是一種通過網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）形式促成IPv6與IPv4主機(jī)間通信的IPv6轉(zhuǎn)換機(jī)制。NAT64網(wǎng)關(guān)需要至少一個IPv4地址和一個包含32位地址空間的IPv6網(wǎng)段來完成IPv4與IPv6協(xié)議間的翻譯。

NAT64將這個32bit的IPv4地址嵌入的IPv6目的地址轉(zhuǎn)換成目的IPv4地址，源IPv6地址轉(zhuǎn)換成一個特定的源IPv4地址。NAT64網(wǎng)關(guān)則創(chuàng)建IPv6與IPv4地址間的映射，這可以為手動配置，也可以自動確定。

如下圖所示，UCloud IPv6轉(zhuǎn)換功能基于NAT64實(shí)現(xiàn)，可為用戶現(xiàn)有IPv4的EIP生成一個IPv6地址，在用戶不修改現(xiàn)有IPv4網(wǎng)絡(luò)和相應(yīng)服務(wù)的情況下，相應(yīng)云資源和服務(wù)可以獲得被公網(wǎng)IPv6訪問的能力，并可使得用戶的云資源和服務(wù)被IPv4和IPv6同時訪問。

IPv6與IPv4之間的轉(zhuǎn)換是一種有狀態(tài)轉(zhuǎn)換，考慮整個系統(tǒng)層面的穩(wěn)定性與擴(kuò)展性需求，IPv6轉(zhuǎn)換服務(wù)的實(shí)現(xiàn)主要有兩大技術(shù)關(guān)鍵點(diǎn)：

高可用，由于IPv6轉(zhuǎn)換服務(wù)是有狀態(tài)服務(wù)，因此必須保證在集群內(nèi)節(jié)點(diǎn)發(fā)生變化時，不能影響已有連接（準(zhǔn)確的說影響不超過1/n，其中n標(biāo)識后端節(jié)點(diǎn)數(shù)目）；

安全防護(hù)，由于IPv6轉(zhuǎn)換服務(wù)是有狀態(tài)服務(wù)，因此當(dāng)碰到惡意***（比如DDoS），很容易導(dǎo)致服務(wù)器被打掛進(jìn)而導(dǎo)致服務(wù)不可用，因此一定的DDoS防護(hù)能力對整個系統(tǒng)來說至關(guān)重要。

◆ 系統(tǒng)架構(gòu)

根據(jù)以上關(guān)鍵點(diǎn)，我們開始著手設(shè)計基于NAT64和P4交換機(jī)實(shí)現(xiàn)IPv6轉(zhuǎn)換功能的系統(tǒng)架構(gòu)，如下圖所示，其中NAT64 Access使用P4交換機(jī)實(shí)現(xiàn)，通過NAT64 Access的一致性Hash實(shí)現(xiàn)高可用。同時在NAT64 Access對CPS進(jìn)行限速，實(shí)現(xiàn)DDoS防護(hù)。

NAT64 Access與物理交換機(jī)1組成三層網(wǎng)絡(luò)，通過BGP向物理交換機(jī)1宣告一個/96的IPv6地址段，作為該地域的IPv6 prefix。POP1與POP2中Access向外宣告的地址段相同，實(shí)現(xiàn)負(fù)荷分擔(dān)和POP點(diǎn)級別的容災(zāi)。同理，POP點(diǎn)內(nèi)兩個Access之間也是負(fù)荷分擔(dān)和容災(zāi)。

Access與物理交換機(jī)2以及NAT64服務(wù)器組成二層網(wǎng)絡(luò)，NAT64服務(wù)器北向通過BGP向Access宣告VIP，Access即可獲得VIP對應(yīng)的下一跳信息（MAC地址）。當(dāng)收到Internet流入的入向IPv6報文時，將所述報文的MAC地址設(shè)定為某個NAT64服務(wù)器的MAC地址，即可實(shí)現(xiàn)將報文送達(dá)至特定的NAT64服務(wù)器。同時NAT64服務(wù)器南向需要向物理交換機(jī)4宣告一個源地址池，實(shí)現(xiàn)回程的可達(dá)性。

需要說明的是，在實(shí)際部署中，物理交換機(jī)2和1通常合一部署，形成NAT64 Access以旁掛的形式存在。下面以云主機(jī)為例，通過業(yè)務(wù)流程來簡要說明整個系統(tǒng)的工作機(jī)制：

業(yè)務(wù)流程

由于每個NAT64服務(wù)器上會配置一個源地址池且互不重疊（其中IPv4_1是NAT64源地址池中的一個地址，IPv4_2對應(yīng)EIP）并且南向通告了該地址池，因此云主機(jī)的響應(yīng)報文（目的地址為源地址池中的地址，即IPv4_1）能夠通過路由到達(dá)相應(yīng)的NAT64服務(wù)器。

◆ 當(dāng)P4遇見NAT64

NAT64 Access支持高可用

通過上文的系統(tǒng)架構(gòu)，可以發(fā)現(xiàn)，通過物理交換機(jī)可以實(shí)現(xiàn)POP點(diǎn)級別的負(fù)荷分擔(dān)和容災(zāi)，但是實(shí)際上系統(tǒng)能夠?qū)崿F(xiàn)高可用的關(guān)鍵在于當(dāng)NAT64服務(wù)節(jié)點(diǎn)的狀態(tài)發(fā)生變化（比如擴(kuò)容或者某個節(jié)點(diǎn)down）時，系統(tǒng)需要保證已有連接不被破壞，這就要求NAT64 Access選擇后端節(jié)點(diǎn)時能夠支持一致性Hash，因此實(shí)質(zhì)上NAT64 Access的最重要屬性是一致性Hash網(wǎng)關(guān)。

在各大云計算廠商的實(shí)現(xiàn)中，一致性Hash網(wǎng)關(guān)的實(shí)現(xiàn)，DPDK是當(dāng)前主流的實(shí)現(xiàn)方案。但是DPDK也存在以下缺陷：

基于DPDK的應(yīng)用可以達(dá)到很高的包轉(zhuǎn)發(fā)速率，但這是通過多服務(wù)器、多核負(fù)載均衡實(shí)現(xiàn)的。且負(fù)載均衡算法通常是由硬件交換機(jī)或者網(wǎng)卡實(shí)現(xiàn)，并不能被軟件定義。如果網(wǎng)絡(luò)中出現(xiàn)單個大象流，無法被硬件交換機(jī)或者網(wǎng)卡的負(fù)載均衡算法很好的分發(fā)，就會造成單根網(wǎng)線或者單個CPU Core出現(xiàn)擁塞，對業(yè)務(wù)造成巨大影響。
隨著網(wǎng)絡(luò)帶寬從10G向25G、40G、50G、100G的演進(jìn)，DPDK需要更強(qiáng)力的CPU才能夠達(dá)到線速，而更強(qiáng)力的CPU通常價錢也很昂貴，不利成本。特別是單Core的主頻越高，價格越貴，且主頻增加之間和價格增加是非線性關(guān)系。
因此，我們最終決定采用P4可編程交換機(jī)（基于Barefoot Tofino芯片實(shí)現(xiàn)）來實(shí)現(xiàn)NAT64 Access，實(shí)際上UCloud早在2017年就開始預(yù)研P4可編程交換機(jī)，并且目前已有基于P4可編程交換機(jī)的GW灰度上線。相比于DPDK網(wǎng)關(guān)，P4可編程交換機(jī)具有諸多優(yōu)勢：

1.與DPDK相比，有更高的轉(zhuǎn)發(fā)性能（1.8T~6.4T）；

2.轉(zhuǎn)發(fā)性能穩(wěn)定，不受CPU Loading等影響；

3.單線100G，可以避免單線擁塞；

4.P4語言開放性好，可編程能力強(qiáng)；

5.很好的生態(tài)圈，支持P4 Runtime。

Maglev Hash

Maglev算法的選擇及驗證

在一致性Hash算法的選擇時，我們選擇了Google Maglev項目中使用的 Hash算法（下文簡稱Maglev Hash），該算法的核心優(yōu)勢在于當(dāng)后端服務(wù)節(jié)點(diǎn)發(fā)生變化時，具有極致的穩(wěn)定性。并且Lookup表的size保持不變，非常適合于P4交換機(jī)來承載Lookup表。（原始論文：Maglev: A Fast and Reliable Software Network Load Balancer）

根據(jù)該論文中對一致性Hash的介紹可以看出，Maglev Hash算法本質(zhì)上設(shè)計算法讓每個后端按照一定的規(guī)則去填滿數(shù)組Lookup表的Empty Entry，確保所構(gòu)造出來的Lookup表的元素中，所有后端服務(wù)器出現(xiàn)的次數(shù)盡可能相等（實(shí)質(zhì)上，根據(jù)算法出現(xiàn)次數(shù)最多的節(jié)點(diǎn)和最少的節(jié)點(diǎn)之間的差值最大為1），因此可以達(dá)到極致的平均性能。

Maglev Hash算法所產(chǎn)生的Lookup表，雖然有著極致的平均性能，但是也有一個缺陷，那就是當(dāng)后端服務(wù)節(jié)點(diǎn)發(fā)生變化時，會有部分連接中斷的情況（理想的一致性Hash算法中斷連接的比例為1/N，Maglev Hash可能存在略微超過1/N）。

在Maglev項目中，通過Connection Track表來彌補(bǔ)這一缺陷，然而Connection Track將帶來一系列缺點(diǎn)，使得NAT64 Access有狀態(tài)，易于收到***。從論文中可以看出，當(dāng)Lookup表的size大于后端節(jié)點(diǎn)的100倍時，連接中斷的情況低于2%。但是2%還是一個相對比較高的比例，本著嚴(yán)謹(jǐn)?shù)膽B(tài)度，我們在擴(kuò)容和縮容（縮容也對應(yīng)某臺NAT64服務(wù)器Down機(jī)）場景下又針對Lookup表size與后端節(jié)點(diǎn)的比例進(jìn)行了一系列測試與驗證。

上圖分別對應(yīng)于后端節(jié)點(diǎn)增加和減少的情況，通過上述測試可以發(fā)現(xiàn)，當(dāng)Lookup表的size較小時，該算法的穩(wěn)定性略差，以上述測試為例，當(dāng)Lookup表的size為1024時，在擴(kuò)容和縮容場景，會有將近百分之二的連接會受到影響（具體表現(xiàn)為entry改變），這點(diǎn)與論文Maglev論文中的結(jié)論基本一致。

但是隨著Lookup表的size增大，對已有連接的影響越來越小，最終逼近與1/n。具體到上述兩圖，當(dāng)Lookup表的大小超過后端服務(wù)節(jié)點(diǎn)的2000倍時，連接中斷的比例低于0.01%，但是由于沒有connection track，整個NAT64 Access是無狀態(tài)的，這就大大提升了NAT64 Access的穩(wěn)定性，并且極大的減小了實(shí)現(xiàn)復(fù)雜度。

NAT64 Access的工作原理

NAT64 Access上承載著一張Lookup表，格式如下：

需要說明的是，此處的Lookup表實(shí)際上是由Maglev中數(shù)張Lookup表構(gòu)成的，通過vip加以區(qū)分。

具體工作機(jī)制如下：

不同的NAT64集群通過BGP向NAT64 Access宣告不同的VIP， NAT64 Manager通過GRPC獲取NAT64 Access的路由表信息和鄰居表信息，獲取各個VIP以及對應(yīng)的下一跳MAC地址信息。然后遍歷所有VIP，根據(jù)每個VIP的下一跳信息調(diào)用Maglev Hash Engine生成相應(yīng)的每個集群的entry list（具體值為各個NAT64的MAC地址）。所有的entry list以及VIP構(gòu)成上述Lookup表。

當(dāng)數(shù)據(jù)面收到報文時，將根據(jù)EIP查詢到VIP（通過另外的表以及控制面相應(yīng)邏輯實(shí)現(xiàn)，在此不再展開），然后根據(jù)數(shù)據(jù)包的源IP、目的IP、源端口、目的端口、調(diào)用P4語言的Hash函數(shù)通過計算得到entry index，最后根據(jù)VIP和entry index匹配Lookup表，設(shè)置目的MAC，至此就完成了后端服務(wù)節(jié)點(diǎn)的選擇。

NAT64 Manager將持續(xù)監(jiān)控NAT64 Access的路由表以及鄰居表，一旦某個VIP的下一跳發(fā)生了改變（比如擴(kuò)容場景或者某個NAT64 Down），將重新調(diào)用Maglev Hash Engine重新生成該VIP對應(yīng)的Lookup表中對應(yīng)的那部分entry，并通過GRPC修改相應(yīng)的entry，實(shí)現(xiàn)節(jié)點(diǎn)變化時的快速響應(yīng)。

NAT64 Access DDoS安全防護(hù)

由于IPv6轉(zhuǎn)換服務(wù)本身是有狀態(tài)的，也就意味著有可能受到DDoS的***，因此我們在NAT64 Access上對每個EIP針對TCP SYN報文進(jìn)行入向和出向PPS限速。因為UCloud在公網(wǎng)接入有著強(qiáng)大的安全保護(hù)和DDoS檢測、清洗等，因此NAT64 Access上所執(zhí)行的SYN報文的限速僅僅是作為一個補(bǔ)充和二次防護(hù)。但是其優(yōu)點(diǎn)在于無需檢測分析而直接進(jìn)行限速，這可以使得在極端***場景下縮短N(yùn)AT64服務(wù)的不可用時間（安全中心完整的DDoS防護(hù)通常都存在檢測和分析等步驟，存在一定程度的滯后性）。

目前單個EIP的SYN報文的速率限制在50000，超過50000時會進(jìn)行丟包。該參數(shù)是可調(diào)的，如果用戶業(yè)務(wù)層面有超大CPS的需求，UCloud相關(guān)的技術(shù)支持人員也可以協(xié)助進(jìn)行調(diào)整。

P4表配置優(yōu)化

Tofino芯片包含4條pipeline，每個pipeline包含12個stage，目前主流的場景還是所有pipeline使用相同的表配置，即使用同一份P4代碼。但是一旦兩個表之間相互依賴，就沒辦法放入同一個stage，這是底層芯片的執(zhí)行邏輯決定的。

考慮業(yè)務(wù)邏輯的復(fù)雜性，數(shù)據(jù)面通常需要定義很多的表才可以完成整個業(yè)務(wù)邏輯，且這些表之間彼此依賴性很高。因此在實(shí)際編碼過程中出現(xiàn)了stage用光，但是每個stage資源利用率很低，具體到我們的項目，資源利用率低就會導(dǎo)致一臺NAT64 Access能夠支持的EIP數(shù)量有限。這種問題通常有以下三種解決方案：

優(yōu)化表配置，或者修改一定的業(yè)務(wù)邏輯，減少表之間的相互依賴，這樣能夠大大提高stage資源的利用率；
由于ingress和egress雖然共享stage，但是ingress和egress的表之間從硬件層面沒有任何依賴關(guān)系。因此將業(yè)務(wù)邏輯拆分，一部分放于ingress，另一部分放于egress。這種方案比較簡單易行，且通常收效明顯；
Pipeline串行，拆分業(yè)務(wù)邏輯，每個pipeline放置一部分業(yè)務(wù)邏輯，不同pipeline之間通過自定義metadata傳遞信息。這種方案也是一種行之有效的方案，且能夠提升Tofino整體的表項空間，可以預(yù)見未來可能會有很多這樣的應(yīng)用。
在NAT64項目中，我們采用了1和2結(jié)合的方案，經(jīng)過優(yōu)化后，資源利用率達(dá)到百分之七十左右（沒有優(yōu)化之前只達(dá)到百分之三十左右）。下圖是我們優(yōu)化后Tofino芯片的資源利用圖和Table占用圖。

系統(tǒng)性能測試

系統(tǒng)構(gòu)建完成后，我們針對單臺NAT64（NAT64服務(wù)器配置為CPU：32核；內(nèi)存：64GB；網(wǎng)卡： X710 10Gb * 2）服務(wù)器進(jìn)行了完整的性能測試，client是IPv6，server端是IPv4 雙向udp數(shù)據(jù)流，一應(yīng)一答。client發(fā)送請求到server，server端應(yīng)答回到client。其中最為關(guān)鍵的CPS和并發(fā)連接數(shù)指標(biāo)測試結(jié)果如下：

CPS測試結(jié)果：

并發(fā)連接數(shù)測試結(jié)果：

我們初始單set上線了16臺NAT64服務(wù)器，因此單地域最高可實(shí)現(xiàn)3.2M CPS和1.6G的并發(fā)連接。此外，整個系統(tǒng)支持平滑的無縫擴(kuò)容，支持任意添加NAT64 Access和NAT64服務(wù)器。

當(dāng)前，UCloud IPv6轉(zhuǎn)換服務(wù)處于免費(fèi)公測階段，歡迎使用。