基于DNS和HTTP方式的URL轉發的比較和實現

張桂香　鮑國林

摘 要：URL轉發功能是網絡世界中訪問網站和管理網站常見需求，但是實現方法各異。本文分析了DNS和HTTP協議不同層次轉發方法，提供了一種結合兩者相對優點而實現URL轉發功能的服務架構，完成互聯網用戶對域名或URL轉發要求。

關鍵詞：URL轉發；HTTP跳轉

URL（Uniform Resource Locator的縮寫），中文為“統一資源定位符”，在互聯網領域也被稱為“網址”，是因特網上標準的資源地址，最初由Sir Tim Berners-Lee發明，現已經W3C編制為因特網標準RFC 1738[1]。

根據RFC 1738，對于常用網絡訪問URL格式如下：

host：網絡主機域名或IP地址（RFC 1034/RFC 1123）；

port：連接端口號，可缺省；對HTTP缺省端口80（HTTPS：443；FTP：21）；

本文將介紹DNS和HTTP兩種轉發方法基本原理，分析各自特征，設計一種將域名或URL轉發到另一個URL的解決方案，為有URL轉發需求用戶提供解決方案。

1 URL轉發

所謂URL轉發，就是通過DNS或HTTP設置，實現當訪問網址時會自動跳轉到指定另一個網址的功能。

2 URL轉發原理

按照轉發對象需要、實現協議、實現層次不同，對于URL轉發可通過DNS或HTTP（HTTPS）設置實現。

2.1 DNS方式

僅對于主機地址（host）轉發需求，根據DNS協議[2]，可以通過CNAME（別名）實現將源域名轉發到目的域名（轉發）為主機應用服務器。在RFC中列舉示例如下：

在某個tld的zone文件中設置了如上CNAME記錄，則對于“USC-ISIC.ARPA.tld”這個域名請求，會被定向到“C.ISI.EDU.tld”上。

CNAME提供了域名（domain name）轉發方法，之后DNS領域又提供了DNAME方式[3]，實現了域（domain）轉發。

以上兩種方式可以很容易實現將源域名定向到轉發服務器，這個過程是隱性的，在DNS范圍之外無法被檢測，缺點是其轉發僅限于域名部分，對于URL中的PATH部分無法改變。

2.2 HTTP方式

超文本傳輸協議是互聯網上應用最為廣泛的一種網絡協議。關于HTTP的RFC 2616[4]，定義了HTTP協議中現今廣泛使用的一個版本—HTTP 1.1。設計HTTP最初目的是為了提供一種發布和接收HTML頁面方法。通過HTTP或者HTTPS協議請求的資源由統一資源標識符（URI）來標識。而使用HTTP協議中“狀態碼3xx”做重定向URI（轉發），是網頁瀏覽中一個常見功能。

2.2.1 HTTP狀態碼3xx轉發方式

HTTP狀態碼3xx轉發方式中，返回狀態碼以3開頭，表示瀏覽器將重定向到另一個地址。HTTP標準定義了幾種重定向狀態碼3xx定義如下：

1） 300 Multiple Choices

2） 301 moved permanently

3） 302 found

4） 303 see other

5） 304 not modified

6） 305 use proxy

7） 307 temporary redirect

下面根據不同3xx返回碼對URL轉發方式做一個詳述：

1）300 Multiple Choices

300含義：客戶請求的文檔可以在多個位置找到，這些位置已經在返回Location內列出。如果服務器提出優先選擇，則應該在Header的location指明。

按照RFC2616中說明，在header中設置了location，但是只有IE、360、opera、Firefox可以跳轉到最終頁面，對于chrome瀏覽器，不會進行重定向。

所以即使在header中的location中有指定，當index中除了重定向還有別的內容，但是有些瀏覽器不能實現重定向，不可以自動跳轉。所以URL如果使用300重定向會有部分瀏覽器無法轉發的問題。

2）301moved permanently

301為永久重定向即：請求網頁已永久移動到新位置。當URL發生變化時，使用301代碼返回后，搜索引擎會保存新的URL，所以301對SEO[5]比較友好。

RFC規定，新的URI在location頭中給出，瀏覽器應該自動訪問新的URI。但同時響應內容中最好包含一個指定新地址的超鏈接，這樣，在不支持自動轉向的瀏覽器用戶也可以通過點擊超鏈接來重定向到新的URI，盡管目前還沒有測試到不支持跳轉的瀏覽器。

3）302found

是暫時重定向（temporary redirect），只有當一個網站或網頁在24到48小時之內臨時移到其它位置情況下才能使用該命令。

在前些年不少Black Hat SEO曾廣泛應用這項技術作弊，目前各大主要搜索引擎均加強了打擊力度，像Google前些年對Business.com以及近來對BMW德國網站懲罰。即使網站客觀上不是spam，也很容易被搜尋引擎誤判為spam而遭到懲罰。由于對SEO不友好，盡可能只在臨時重定向時使用。

4）303see other

與302不同之處：如果原來請求是POST，LOCATION指定的重定向目標文檔應該通過GET提取，所以會丟棄用戶通過POST方式發送數據。RFC中提到，許多HTTP/1.1版以前的瀏覽器不能正確理解303狀態，如果需要考慮與這些瀏覽器之間的兼容性，302狀態碼可以替換303。

5）304not modified

如果客戶端有本地緩存，并發出一個條件性請求（一般是提供if-modified-since頭，表示客戶只需要指定日期后更新的文檔）。服務器告訴原緩沖文檔還可以繼續使用。如果網頁自請求者上次請求后沒有更新，則用304代碼告訴搜索引擎機器人，可節省帶寬和開銷。這個需要判斷是否發生了變化。

6）305use proxy

RFC規定，被請求資源必須通過指定代理才能被訪問。Location域中將給出指定代理所在的URI信息，接收者需要重復發送一個單獨請求，通過這個代理才能訪問相應資源。只有原始服務器才能創建305響應。但目前很多瀏覽器不支持。

7）306switch proxy

預留狀態，未使用。

8）307temporary redirect

和303相同，對于非GET和HEAD請求不能自動重定向。出現307應答時，瀏覽器可以繼續完成重定向的GET和POST請求。 但是307沒有被完全支持，opera不支持；Firefox，IE等瀏覽器可以重定向。

除了使用HTTP狀態進行轉發之外，還有另外一些巧妙方法，甚至可能實現作弊或釣魚，如下面兩個：

9）iFrame隱藏頁面

這是一種隱藏地址欄URL顯示方法，即跳轉后地址欄顯示的是源轉發地址而非目的地址。相當于做了一個頁面將目的頁面嵌入在里面。

10）meta fresh

這在2000年前比較流行，不過現在已很少見。具體實現是通過網頁中meta指令，在特定時間后重定向到新網頁。但是如果延遲時間太短（約5秒之內），會被判斷為spam。

2.2.2 HTTP轉發方式總結

在HTTP協議中3xx響應中，300、305、307都會存在瀏覽器不識別問題；303主流都支持（IE，火狐，360，opera，chrome），但可被302替代；目前301、302、304用的比較多。在使用上，304有特定應用場景，即需要對目的資源是否與客戶端上次訪問內容是否變更進行判斷。

因此，以常用的301、302以及采用iFrame的隱藏方式做實驗，分析客戶端、服務端對地址識別情況：

綜上，對HTTP轉發來說，301和302是常見、可用的HTTP轉發方式。

3 URL轉發的實現

現在根據一個常見互聯網服務提供商（Registrar）角度，實現從域名s.tld訪問到URL：http：//www.d.com/p的一種方法：

⑴轉發設置中的源地址（s.tld），目的URL（http：//www.d.com/p）需要在兩種服務器上設置生效，包括DNS解析服務器和URL轉發的服務器；

⑵互聯網用戶訪問http：//s.tld時，會首先到DNS解析服務器上，查詢到s.tld的CNAME記錄，如redirect.tld；而URL轉發WEB服務器地址就是redirect.tld；這樣第3步將會訪問URL轉發服務器；

⑶用戶訪問URL轉發WEB服務器redirect.tld時，由URL轉發WEB服務器上的查詢服務（DB/MEM等方式）查詢用戶設置源地址和目的地址，然后HTTP訪問返回301/302，并指定目的http：//www.d.com/p；

⑷用戶最終會訪問http：//www.d.com/p；

4 結束語

互聯網用戶出于各種目的，需要域名或URL轉發業務，DNS設置比較隱蔽，但是只能針對域名；而采用HTTP的URL方式轉發，特別是301、302方式，普遍用在單個網頁服務內部。而采用DNS+HTTP方式，配置靈活，入口設置方便，并且支持容量更大，因為DNS服務能力（UDP）比HTTP服務要強很多（TCP）。

本文分析了DNS設置，以及HTTP轉發（URL Forwarding）請求的幾種不同方式，設計并實現了一種服務場景，可以為互聯網用戶提供高性能、易配置和服務靈活的URL轉發功能。

[參考文獻]

[1]T.Berners-Lee，L.Masinter，M.McCahill.Uniform Resource Locators（URL）.Request for Comments：1738.December1994.

[2]P.Mockapetris，DOMAIN NAMES-CONCEPTS AND FACILITIES，November1987.Request for Comments：1034，

[3]S.Rose，W.Wijngaards，DNAME Redirection in the DNS，June 2012，ISSN：2070-1721，Request for Comments：6672

[4]R.Fielding，J.Gettys，J.Mogul，H.Frystyk，L.Masinter，P.Leach，T.Berners-Lee，June1999，Hypertext Transfer Protocol--HTTP/1.1， Request for Comments：2616

[5]"Bing–Partnering to help solve duplicate content issues–Webmaster Blog–Bing Community".www.bing.com.Retrieved October 30，2009.