文／鄧庚盛 鄢志輝 鄒偉平 魯喆

為了降低IPv6過渡階段IPv4/IPv6 Web服務的部署難度，加快向IPv6過渡的進程，文章針對IPv6過渡的4個階段制定了Web服務基于雙棧反向代理方案和漸進式的過渡策略。通過在雙棧環(huán)境下部署反向代理服務，同時分別監(jiān)聽IPv4和IPv6服務端口，并結合DNS域名設置，來實現(xiàn)支持IPv4/IPv6雙棧的Web服務，使得純IPv4和純IPv6用戶均可訪問。文章對反向代理后Web內容可能存在跨站跨協(xié)議資源訪問的問題提出了增加過濾轉換器的解決方法。與其他常用的雙棧、網(wǎng)絡翻譯等過渡機制相比，采用基于雙棧反向代理方式對于Web應用的IPv6過渡有明顯的優(yōu)勢，無需對現(xiàn)有網(wǎng)絡進行任何變更就可以快速部署，不需要公網(wǎng)雙棧和無狀態(tài)網(wǎng)絡翻譯機制所要求的公網(wǎng)地址，而且在用戶和服務之間增加了隔離屏障，提高了服務的安全性。

自從全球地址分配機構(IANA)于2011年2月3日正式宣布，將其最后的IPv4地址平均分配到全球5個地區(qū)的互聯(lián)網(wǎng)絡信息中心后，目前僅剩下非洲互聯(lián)網(wǎng)信息中心(AFRINIC)可正常分配IPv4地址[1]。IPv4向IPv6的全面過渡更加緊迫，但由于互聯(lián)網(wǎng)的復雜性和多樣性，這個過渡必將是一個漫長的過程。由于IPv4協(xié)議和IPv6協(xié)議本質上不兼容，在過渡階段如何快速有效的向純IPv4和純IPv6用戶提供支持IPv4/IPv6的服務，最終實現(xiàn)平滑過渡，是必須要考慮和解決的問題。

本文首先介紹了IPv6過渡階段的Web服務過渡機制，然后設計了采用雙棧反向代理服務實現(xiàn)同時支持IPv4/IPv6的Web服務方案，并針對IPv6過渡的4個階段制定了雙棧反向代理的過渡策略，最后對基于雙棧反向代理的方案與其他常用過渡機制進行比較并得出結論。

IPv6過渡階段的Web服務過渡策略介紹

文獻[2]將IPv6過渡分為4個階段:純IPv4(階段0)，IPv4為主、存在少量的IPv6(階段1)，IPv6為主、存在少量的IPv4(階段2)和純IPv6(階段3)。由于階段0和階段3通信需求僅限于IPv4、IPv6同協(xié)議訪問，其中階段1和階段2的不同點在于純IPv4網(wǎng)絡、雙棧網(wǎng)絡、純IPv6網(wǎng)絡接入類型所占比例的多少。本文主要討論階段1和階段2的場景，需要同時滿足終端IPv4/IPv6用戶訪問IPv6/IPv4 Web服務的需求。見表1，只有雙棧方式接入的終端用戶能夠訪問所有的IPv4/IPv6服務，純IPv4用戶不能訪問純IPv6服務，純IPv6用戶不能訪問純IPv4服務。要滿足所有終端用戶同時能夠訪問IPv4/IPv6服務，需要終端用戶通過IPv4-over-IPv6或IPv6-over-IPv4隧道的方式建立另外一種協(xié)議的通信通道，隧道的建立需要終端用戶做一定的配置，對于情況各異的用戶來說難以大規(guī)模使用。

表1 終端用戶在IPv6過渡階段訪問IPv4/IPv6Web服務的方式

因此，需要從Web服務端實現(xiàn)純IPv4和純IPv6用戶的訪問，通常有以下兩種方法：（1）服務器基于雙棧提供Web服務，原生支持IPv4/IPv6；（2）IPv4-IPv6翻譯，通過一個翻譯模塊將IPv4 數(shù)據(jù)包和IPv6 數(shù)據(jù)包互相轉換，翻譯機制可以分為無狀態(tài)翻譯,如SIIT(stateless IP/ICMP translation)和IVI(IV stands for 4 and VI stands for 6),以及有狀態(tài)翻譯,如NAT-PT(NAT-protocol translation)和 NAT64。[3-5]

Web服務本身采用雙棧方式是首選，它可避免因轉換導致的任何復雜性，并為服務器提供最多信息。[6]雙棧方式需要整個鏈路上的設備均支持雙棧，包括服務器和應用本身，這意味著可能涉及到網(wǎng)絡改造和軟硬件設備更新，且公網(wǎng)雙棧需要消耗公網(wǎng)IPv4地址。IPv4-IPv6翻譯機制需要在邊界部署路由或網(wǎng)關，無狀態(tài)翻譯機制不需要維護會話的狀態(tài),具有一定的靈活性,但它是以消耗IPv4地址空間的代價來實現(xiàn)雙向通信，有狀態(tài)翻譯機制需要翻譯器維護一個動態(tài)的地址(地址和端口)映射和一個IPv4地址資源池。

由于公網(wǎng)雙棧方式和無狀態(tài)翻譯機制Web服務本身需要消耗公網(wǎng)IPv4地址空間，他們沒有解決IPv6協(xié)議主要解決的地址空間的問題；私網(wǎng)雙棧雖然不消耗公網(wǎng)IPv4地址但仍然需要鏈路上設備的支持；另外，私網(wǎng)雙棧和有狀態(tài)翻譯機制需要部署路由或網(wǎng)關并維護會話狀態(tài)，增加了網(wǎng)絡復雜性。因此，為了降低IPv6過渡期間Web服務部署實施的復雜度，本文提出采用雙棧反向代理的方式實現(xiàn)過渡時期對Web服務的訪問，通過將反向代理服務器部署在雙棧環(huán)境中，Web服務可以只接入純IPv4或純IPv6，不需要對現(xiàn)有網(wǎng)絡結構做任何改變，進而逐步完成向IPv6的過渡。

雙棧反向代理服務方案的設計

反向代理是指由代理服務器來接收來自互聯(lián)網(wǎng)的訪問請求，再把訪問請求轉發(fā)到對應的網(wǎng)站服務器，并從對應網(wǎng)站服務器獲取結果返回給訪問用戶。[7]對于終端用戶來說，用戶正常訪問網(wǎng)頁即可，不需要做任何改變或配置。文獻[7-10]介紹了反向代理在Web服務中的應用，并介紹了在安全、負載均衡、公網(wǎng)地址消耗等方面的優(yōu)勢，但這些文獻均未涉及IPv4/IPv6雙棧環(huán)境的場景。

雙棧反向代理的方式是指將反向代理服務器部署在雙棧環(huán)境中，同時分別監(jiān)聽IPv4和IPv6服務端口，Web服務可以只接入純IPv4或純IPv6網(wǎng)絡，純IPv4和純IPv6終端用戶可以通過反向代理服務器進行代理訪問另一協(xié)議的Web服務。由于采用雙棧代理后Web內容可能存在跨協(xié)議的資源引用問題，本文設計采用在反向代理服務內設置過濾轉換器和通用代理器來實現(xiàn)跨協(xié)議訪問。

1.雙棧反向代理服務的網(wǎng)絡設計

IPv6過渡階段雙棧反向代理部署網(wǎng)絡結構如圖1所示。雙棧反向代理服務器部署在雙棧網(wǎng)絡中，同時監(jiān)聽IPv4/IPv6的服務端口：

（1) 對于純IPv4用戶，在一側作為IPv4服務器，另一側作為IPv6客戶端，將來自IPv4客戶端的請求代理到IPv6服務器。

圖1 IPv6過渡階段雙棧反向代理部署網(wǎng)絡結構示意

（2) 對于純IPv6用戶，在一側作為IPv6服務器，另一側作為IPv4客戶端，將來自IPv6客戶端的請求代理到IPv4服務器。

雙棧反向代理服務器部署比較靈活，部署的位置取決于網(wǎng)絡的哪個部分可以支持雙棧，不需要對現(xiàn)有網(wǎng)絡結構做任何變更，又實現(xiàn)了雙棧Web服務。即使整個網(wǎng)絡沒有IPv6或IPv4，也可以在外部支持雙棧的數(shù)據(jù)中心托管自己的反向代理服務器，實現(xiàn)IPv4/IPv6的服務。由于跨協(xié)議訪問服務是由反向代理服務器中轉完成的，因此服務內容的管理維護與之前沒有變化，不需要考慮IPv4和IPv6不同的情況。

2.雙棧反向代理服務的域名服務設計

在反向代理服務的部署實施過程中，結合DNS（域名服務）配置可以更好地實現(xiàn)Web服務的快速部署。本文中Web服務域名設計如下：域名為example.com和example6.com，其中example.com域下的子域名同時配置A記錄和AAAA記錄，example6.com域下的子域名僅配置AAAA記錄，在實際應用中可以選擇不使用example6.com域名。其中A記錄是用來創(chuàng)建到IPv4地址的記錄，AAAA記錄是用來創(chuàng)建到IPv6地址的記錄。

假定雙棧反向代理服務器的IPv4和IPv6的地址分別為222.204.33.99和2001:250:6c00::3:99，以處于純IPv4網(wǎng)絡中域名為lib.example.com（ipv4地址為222.200.3.200）和處于純IPv6網(wǎng)絡中域名為6.example.com（IPv6地址為2001:250:6c00::210:201）的Web服務站點為例介紹域名設置方式。具體域名配置時將原本純IPv4服務域名lib.example.com和lib.example6.com的AAAA記錄指向反向代理服務器的IPv6地址2001:250:6c00::3:99，將原本純IPv6服務域名6.example.com對應的A記錄指向反向代理服務器的IPv4地址222.204.33.99。當純IPv4或純IPv6用戶訪問原本只有另一協(xié)議網(wǎng)絡的Web服務時，域名將解析至反向代理服務器進行代理訪問。

3. 雙棧反向代理服務的數(shù)據(jù)處理流程

雙棧反向代理服務部署后，純IPv4用戶可以通過反向代理服務器進行代理訪問原本IPv6的Web服務，純IPv6用戶也可以通過反向代理服務器進行代理訪問原本IPv4的Web服務，圖2為用戶通過雙棧反向代理訪問Web服務的數(shù)據(jù)流向示意圖。

IPv6用戶通過反向代理訪問原本IPv4服務lib.example.com的主要過程如下。

步驟1：用戶發(fā)起訪問請求，DNS解析出該域名對應的AAAA記錄2001:250:6c00::3:99，訪問請求被定位至反向代理服務器的IPv6監(jiān)聽端口，這個過程基于IPv6協(xié)議；

步驟2：反向代理服務器得到用戶訪問請求，將訪問請求轉發(fā)至原本IPv4的Web服務，請求IP為反向代理的IPv4地址222.204.33.99，服務的IP地址為222.204.31.200，這個過程基于IPv4協(xié)議；

步驟3：Web服務器接收到轉發(fā)的訪問請求，將響應內容反饋至反向代理服務器，這個過程基于IPv4協(xié)議；

圖2 雙棧反向代理數(shù)據(jù)流向示意

步驟4：反向代理服務器通過IPv6地址2001:250:6c00::3:99的服務監(jiān)聽端口將內容返回給用戶，這個過程基于IPv6協(xié)議。

類似的，IPv4用戶通過反向代理訪問原本IPv6服務6.example.com的過程如下。

步驟1：用戶發(fā)起訪問請求，DNS解析出該域名對應的A記錄222.204.33.99，訪問請求被定位至反向代理服務器的IPv4監(jiān)聽端口，這個過程基于IPv4協(xié)議；

步驟2：反向代理服務器得到用戶訪問請求，將訪問請求轉發(fā)至原本IPv6的Web服務，請求IP為反向代理的IPv6地址2001:250:6c00::3:99，服務的IPv6地址為2001:250:6c00::210:201，這個過程基于IPv6協(xié)議；

步驟3：Web服務器接收到轉發(fā)的訪問請求，將響應內容反饋至反向代理服務器，這個過程基于IPv6協(xié)議；

步驟4：反向代理服務器通過IPv4地址222.204.33.99的服務監(jiān)聽端口將內容返回給用戶，這個過程基于IPv4協(xié)議。

由于雙棧用戶訪問Web服務時只會選擇其中一種協(xié)議進行通信，在此不另做考慮。

從反向代理訪問Web服務的過程可以看到，對于用戶來說反向代理服務器就是目的服務器，用戶并不知道位于反向代理服務器之后的Web服務的真實IP地址，這樣就很好地保護了后端Web服務的資源安全。

4.雙棧反向代理服務跨站跨協(xié)議資源的處理

雙棧反向代理使得原本在單一網(wǎng)絡的Web服務有了雙棧服務能力，但是當純IPv4/IPv6用戶通過代理訪問Web服務時，如果被代理的Web服務內容中引用了外站的資源，使用代理服務后可能會遇到跨站、跨協(xié)議不能訪問的問題。例如常用的jquery的官網(wǎng)提供的CDN服務code.jquery.com僅支持IPv4，當IPv4服務lib.example.com頁面內容引用了腳本“http://code.jquery.com/jquery-3.2.1.min.js”，IPv6用戶通過反向代理訪問lib.example.com時就會遇到因引用失敗而導致頁面功能失效的問題。

為提高用戶體驗，解決此類跨站跨協(xié)議資源引用的問題，本文在反向代理服務器中設置了過濾轉換器和一個通用代理Proxy模塊，過濾轉換器主要實現(xiàn)對Web服務返回的內容進行處理，通用代理Proxy模塊主要用于實現(xiàn)代理訪問過濾轉換后的URL資源。通用代理Proxy同時監(jiān)聽IPv4和IPv6端口，同時配置域名proxy.example.com的A記錄和AAAA記錄指向反向代理服務器。

反向代理服務器處理跨站跨協(xié)議資源處理步驟如下。

步驟1：反向代理服務器接收到返回的服務內容；

步驟2：判斷是否為“text/html”格式，如果是進入步驟3，否則進入步驟5；

步驟3：檢測內容中是否包含絕對URL地址的資源引用，通常格式如src=http://a.b.c和href=http://a.b.c；

步驟4：將絕對URL地址替換為本地代理訪問的URL，如將src=http://a.b.c替換為src=http://proxy.example.com/?url=http://a.b.c；

步驟5：反向代理服務器將過濾后的內容返回終端用戶；

步驟6：用戶瀏覽器接收到返回的內容進行展示，其中的跨站跨協(xié)議的資源由于URL地址已經(jīng)替換，訪問請求將自動解析至反向代理服務器中的通用代理Proxy；

步驟7：通用代理Proxy代理訪問并將訪問結果返回用戶瀏覽器。

完成處理后，終端用戶對這部分跨站跨協(xié)議的資源訪問也通過雙棧反向代理訪問，如圖3所示。

5. 雙棧反向代理的過渡策略設計

根據(jù)Web服務區(qū)域的IPv6過渡的4個階段，可制定如下雙棧反向代理過渡策略，最終實現(xiàn)IPv6的過渡：

（1）階段0（純IPv4）：這個階段網(wǎng)絡中沒有IPv6網(wǎng)絡，此時可以將反向代理部署在外部支持雙棧的數(shù)據(jù)中心，將AAAA記錄指向反向代理服務器，IPv4用戶直接訪問原有網(wǎng)站服務，IPv6用戶通過反向代理訪問。

圖3 雙棧反向代理跨站跨協(xié)議資源訪問數(shù)據(jù)流向示意

圖4 ab -n 1OOO -c 1O時代理前后服務響應時間

（2）階段1（IPv4為主、存在少量的IPv6）和階段2(IPv6為主、存在少量的IPv4)：這兩個階段部署策略是一樣的，在雙棧區(qū)域部署反向代理，通過代理訪問純IPv6和純IPv4的Web服務。當新建Web服務或升級改造時部署至雙棧或純IPv6區(qū)域，通過改變域名的A記錄和AAAA記錄的指向，使得IPv4用戶訪問時通過反向代理訪問，IPv6用戶直接訪問，這樣逐步完成向IPv6的過渡。

（3） 階段3（純IPv6）：這個階段網(wǎng)絡中沒有IPv4網(wǎng)絡，如果需要可以將反向代理部署在外部支持雙棧的數(shù)據(jù)中心，將A記錄指向反向代理服務器，IPv6用戶直接訪問網(wǎng)站服務，IPv4用戶通過反向代理訪問。

基于雙棧反向代理過渡方式對網(wǎng)絡、設備和應用程序本身的要求不高，向IPv6過渡的Web應用可以成熟一個遷移一個，漸進式完成向IPv6的過渡。

與常用過渡機制評價比較

在IPv6過渡的前面三個階段，通過雙棧反向代理的部署，可以將原本純IPv4的Web服務快速擴展至IPv6，使得IPv4/IPv6用戶均可訪問。該方案僅需要少量配置和代碼，目前在筆者單位已經(jīng)應用近百個二級站點并正常運行多年，反向代理服務器采用開源軟件Nginx部署，過濾轉換器采用ngx_lua模塊編寫代碼實現(xiàn)，在Nginx的配置文件中配置二級域名的泛域名解析，可以實現(xiàn)在站點調整或IPv6切換時時僅需要對DNS設置進行變更。圖4是采用Apache的ab工具對代理前后壓力測試時的響應情況：可以看到由于加入了過濾轉換器，代理后響應時間稍微有些增加，1000次的請求最高響應時間為8ms，在可以接受的范圍之內。

文獻[2]提出了針對IPv6 過渡機制的統(tǒng)一評價指標體系，主要體現(xiàn)在功能、應用、性能、部署和安全5個方面，表2是與其他常用過渡機制在部署方面的評價指標的對比。

從表2可以看出，采用基于雙棧反向代理方式對于Web應用的IPv6過渡有明顯的優(yōu)勢，可無需對現(xiàn)有網(wǎng)絡進行任何變更，對設備沒有特殊要求，可以不需要公網(wǎng)雙棧和無狀態(tài)網(wǎng)絡翻譯機制所要求的公網(wǎng)地址，而且在用戶和服務之間增加了隔離屏障，提高了服務的安全性。

表2 與常用過渡機制評價比較

本文設計了IPv6過渡階段雙棧反向代理的Web服務方案和過渡機制，通過在雙棧環(huán)境下部署反向代理服務，結合DNS域名設置，為純IPv4和純IPv6環(huán)境下的Web服務快速實現(xiàn)提供雙棧服務的能力。該方案的優(yōu)點是：無需對現(xiàn)有網(wǎng)絡和設備做改變即可實現(xiàn)原本純IPv4和純IPv6的Web服務的雙棧訪問；在后端Web服務向IPv6切換時僅需要對DNS設置進行變更，易于管理和維護；反向代理服務的存在使得用戶和Web服務之間增加了一道隔離屏障，提高了服務的安全性。本文在反向代理服務中設置增加了過濾轉換器和通用代理器，用于解決代理訪問后Web內容中跨站、跨協(xié)議資源不能訪問的問題，目前過濾轉換器對于各被代理網(wǎng)站的處理都使用統(tǒng)一的代碼，后續(xù)將對過濾轉換器進行優(yōu)化和擴展，以提高過濾器的性能和實現(xiàn)對被代理的站點更細力度的處理。

（責編：楊潔）

[1] Huston G, IPv4 address report. Technical Report, 2017. http://www.potaroo.net/tools/ipv4

[2] 葛敬國, 弭偉, 吳玉磊. IPv6過渡機制:研究綜述、評價指標與部署考慮[J]. 軟件學報, 2014,25(4):896-912.

[3] Wu J， Wang JH，Yang J. CNGI-CERNET2: An IPv6 deployment in China. ACM SIGCOMM Computer Communication Review， 2011，41(2):48?52. [doi: 10.1145/1971162.1971170]

[4] Wu P， Cui Y， Wu J， Liu J， Metz C. Transition from IPv4 to IPv6: A state-of-the-art survey.IEEE Communications Surveys & Tutorials， 2012，PP(99):1?18.

[5] Aazam M，Huh E N.Impact of ipv4-ipv6 coexistence in cloud virtualization environment[J].Annals of Telecommunications，2016，69(9-10)：485-496.

[6] Netze H. IPv6 Guidance for Internet Content Providers and Application Service Providers[J]. Work in Progress, 2013.

[7] 徐華宇. APACHE反向代理在校園網(wǎng)絡中的應用[J]. 通訊世界, 2015(23):298-299.

[8] 馮貴蘭, 李正楠. Nginx反向代理在高校網(wǎng)站系統(tǒng)中的應用研究[J]. 網(wǎng)絡安全技術與應用,2017(6).

[9] 劉振昌, 陳詩明, 焦寶臣,等. 網(wǎng)站安全管理難題 用反向代理技術巧應對[J]. 中國教育網(wǎng)絡,2017(Z1):92-93.

[10]徐長君, 林濤. 基于Nginx的負載均衡方式優(yōu)化[J]. 河北工業(yè)大學學報, 2016, 45(6):48-52.