張桂香　鮑國(guó)林

摘 要：URL轉(zhuǎn)發(fā)功能是網(wǎng)絡(luò)世界中訪問網(wǎng)站和管理網(wǎng)站常見需求，但是實(shí)現(xiàn)方法各異。本文分析了DNS和HTTP協(xié)議不同層次轉(zhuǎn)發(fā)方法，提供了一種結(jié)合兩者相對(duì)優(yōu)點(diǎn)而實(shí)現(xiàn)URL轉(zhuǎn)發(fā)功能的服務(wù)架構(gòu)，完成互聯(lián)網(wǎng)用戶對(duì)域名或URL轉(zhuǎn)發(fā)要求。

關(guān)鍵詞：URL轉(zhuǎn)發(fā)；HTTP跳轉(zhuǎn)

URL（Uniform Resource Locator的縮寫），中文為“統(tǒng)一資源定位符”，在互聯(lián)網(wǎng)領(lǐng)域也被稱為“網(wǎng)址”，是因特網(wǎng)上標(biāo)準(zhǔn)的資源地址，最初由Sir Tim Berners-Lee發(fā)明，現(xiàn)已經(jīng)W3C編制為因特網(wǎng)標(biāo)準(zhǔn)RFC 1738[1]。

根據(jù)RFC 1738，對(duì)于常用網(wǎng)絡(luò)訪問URL格式如下：

host：網(wǎng)絡(luò)主機(jī)域名或IP地址（RFC 1034/RFC 1123）；

port：連接端口號(hào)，可缺省；對(duì)HTTP缺省端口80（HTTPS：443；FTP：21）；

本文將介紹DNS和HTTP兩種轉(zhuǎn)發(fā)方法基本原理，分析各自特征，設(shè)計(jì)一種將域名或URL轉(zhuǎn)發(fā)到另一個(gè)URL的解決方案，為有URL轉(zhuǎn)發(fā)需求用戶提供解決方案。

1 URL轉(zhuǎn)發(fā)

所謂URL轉(zhuǎn)發(fā)，就是通過DNS或HTTP設(shè)置，實(shí)現(xiàn)當(dāng)訪問網(wǎng)址時(shí)會(huì)自動(dòng)跳轉(zhuǎn)到指定另一個(gè)網(wǎng)址的功能。

2 URL轉(zhuǎn)發(fā)原理

按照轉(zhuǎn)發(fā)對(duì)象需要、實(shí)現(xiàn)協(xié)議、實(shí)現(xiàn)層次不同，對(duì)于URL轉(zhuǎn)發(fā)可通過DNS或HTTP（HTTPS）設(shè)置實(shí)現(xiàn)。

2.1 DNS方式

僅對(duì)于主機(jī)地址（host）轉(zhuǎn)發(fā)需求，根據(jù)DNS協(xié)議[2]，可以通過CNAME（別名）實(shí)現(xiàn)將源域名轉(zhuǎn)發(fā)到目的域名（轉(zhuǎn)發(fā)）為主機(jī)應(yīng)用服務(wù)器。在RFC中列舉示例如下：

在某個(gè)tld的zone文件中設(shè)置了如上CNAME記錄，則對(duì)于“USC-ISIC.ARPA.tld”這個(gè)域名請(qǐng)求，會(huì)被定向到“C.ISI.EDU.tld”上。

CNAME提供了域名（domain name）轉(zhuǎn)發(fā)方法，之后DNS領(lǐng)域又提供了DNAME方式[3]，實(shí)現(xiàn)了域（domain）轉(zhuǎn)發(fā)。

以上兩種方式可以很容易實(shí)現(xiàn)將源域名定向到轉(zhuǎn)發(fā)服務(wù)器，這個(gè)過程是隱性的，在DNS范圍之外無法被檢測(cè)，缺點(diǎn)是其轉(zhuǎn)發(fā)僅限于域名部分，對(duì)于URL中的PATH部分無法改變。

2.2 HTTP方式

超文本傳輸協(xié)議是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。關(guān)于HTTP的RFC 2616[4]，定義了HTTP協(xié)議中現(xiàn)今廣泛使用的一個(gè)版本—HTTP 1.1。設(shè)計(jì)HTTP最初目的是為了提供一種發(fā)布和接收HTML頁(yè)面方法。通過HTTP或者HTTPS協(xié)議請(qǐng)求的資源由統(tǒng)一資源標(biāo)識(shí)符（URI）來標(biāo)識(shí)。而使用HTTP協(xié)議中“狀態(tài)碼3xx”做重定向URI（轉(zhuǎn)發(fā)），是網(wǎng)頁(yè)瀏覽中一個(gè)常見功能。

2.2.1 HTTP狀態(tài)碼3xx轉(zhuǎn)發(fā)方式

HTTP狀態(tài)碼3xx轉(zhuǎn)發(fā)方式中，返回狀態(tài)碼以3開頭，表示瀏覽器將重定向到另一個(gè)地址。HTTP標(biāo)準(zhǔn)定義了幾種重定向狀態(tài)碼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

下面根據(jù)不同3xx返回碼對(duì)URL轉(zhuǎn)發(fā)方式做一個(gè)詳述：

1）300 Multiple Choices

300含義：客戶請(qǐng)求的文檔可以在多個(gè)位置找到，這些位置已經(jīng)在返回Location內(nèi)列出。如果服務(wù)器提出優(yōu)先選擇，則應(yīng)該在Header的location指明。

按照RFC2616中說明，在header中設(shè)置了location，但是只有IE、360、opera、Firefox可以跳轉(zhuǎn)到最終頁(yè)面，對(duì)于chrome瀏覽器，不會(huì)進(jìn)行重定向。

所以即使在header中的location中有指定，當(dāng)index中除了重定向還有別的內(nèi)容，但是有些瀏覽器不能實(shí)現(xiàn)重定向，不可以自動(dòng)跳轉(zhuǎn)。所以URL如果使用300重定向會(huì)有部分瀏覽器無法轉(zhuǎn)發(fā)的問題。

2）301moved permanently

301為永久重定向即：請(qǐng)求網(wǎng)頁(yè)已永久移動(dòng)到新位置。當(dāng)URL發(fā)生變化時(shí)，使用301代碼返回后，搜索引擎會(huì)保存新的URL，所以301對(duì)SEO[5]比較友好。

RFC規(guī)定，新的URI在location頭中給出，瀏覽器應(yīng)該自動(dòng)訪問新的URI。但同時(shí)響應(yīng)內(nèi)容中最好包含一個(gè)指定新地址的超鏈接，這樣，在不支持自動(dòng)轉(zhuǎn)向的瀏覽器用戶也可以通過點(diǎn)擊超鏈接來重定向到新的URI，盡管目前還沒有測(cè)試到不支持跳轉(zhuǎn)的瀏覽器。

3）302found

是暫時(shí)重定向（temporary redirect），只有當(dāng)一個(gè)網(wǎng)站或網(wǎng)頁(yè)在24到48小時(shí)之內(nèi)臨時(shí)移到其它位置情況下才能使用該命令。

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

4）303see other

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

5）304not modified

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

6）305use proxy

RFC規(guī)定，被請(qǐng)求資源必須通過指定代理才能被訪問。Location域中將給出指定代理所在的URI信息，接收者需要重復(fù)發(fā)送一個(gè)單獨(dú)請(qǐng)求，通過這個(gè)代理才能訪問相應(yīng)資源。只有原始服務(wù)器才能創(chuàng)建305響應(yīng)。但目前很多瀏覽器不支持。

7）306switch proxy

預(yù)留狀態(tài)，未使用。

8）307temporary redirect

和303相同，對(duì)于非GET和HEAD請(qǐng)求不能自動(dòng)重定向。出現(xiàn)307應(yīng)答時(shí)，瀏覽器可以繼續(xù)完成重定向的GET和POST請(qǐng)求。 但是307沒有被完全支持，opera不支持；Firefox，IE等瀏覽器可以重定向。

除了使用HTTP狀態(tài)進(jìn)行轉(zhuǎn)發(fā)之外，還有另外一些巧妙方法，甚至可能實(shí)現(xiàn)作弊或釣魚，如下面兩個(gè)：

9）iFrame隱藏頁(yè)面

這是一種隱藏地址欄URL顯示方法，即跳轉(zhuǎn)后地址欄顯示的是源轉(zhuǎn)發(fā)地址而非目的地址。相當(dāng)于做了一個(gè)頁(yè)面將目的頁(yè)面嵌入在里面。

10）meta fresh

這在2000年前比較流行，不過現(xiàn)在已很少見。具體實(shí)現(xiàn)是通過網(wǎng)頁(yè)中meta指令，在特定時(shí)間后重定向到新網(wǎng)頁(yè)。但是如果延遲時(shí)間太短（約5秒之內(nèi)），會(huì)被判斷為spam。

2.2.2 HTTP轉(zhuǎn)發(fā)方式總結(jié)

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

因此，以常用的301、302以及采用iFrame的隱藏方式做實(shí)驗(yàn)，分析客戶端、服務(wù)端對(duì)地址識(shí)別情況：

綜上，對(duì)HTTP轉(zhuǎn)發(fā)來說，301和302是常見、可用的HTTP轉(zhuǎn)發(fā)方式。

3 URL轉(zhuǎn)發(fā)的實(shí)現(xiàn)

現(xiàn)在根據(jù)一個(gè)常見互聯(lián)網(wǎng)服務(wù)提供商（Registrar）角度，實(shí)現(xiàn)從域名s.tld訪問到URL：http：//www.d.com/p的一種方法：

⑴轉(zhuǎn)發(fā)設(shè)置中的源地址（s.tld），目的URL（http：//www.d.com/p）需要在兩種服務(wù)器上設(shè)置生效，包括DNS解析服務(wù)器和URL轉(zhuǎn)發(fā)的服務(wù)器；

⑵互聯(lián)網(wǎng)用戶訪問http：//s.tld時(shí)，會(huì)首先到DNS解析服務(wù)器上，查詢到s.tld的CNAME記錄，如redirect.tld；而URL轉(zhuǎn)發(fā)WEB服務(wù)器地址就是redirect.tld；這樣第3步將會(huì)訪問URL轉(zhuǎn)發(fā)服務(wù)器；

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

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

4 結(jié)束語(yǔ)

互聯(lián)網(wǎng)用戶出于各種目的，需要域名或URL轉(zhuǎn)發(fā)業(yè)務(wù)，DNS設(shè)置比較隱蔽，但是只能針對(duì)域名；而采用HTTP的URL方式轉(zhuǎn)發(fā)，特別是301、302方式，普遍用在單個(gè)網(wǎng)頁(yè)服務(wù)內(nèi)部。而采用DNS+HTTP方式，配置靈活，入口設(shè)置方便，并且支持容量更大，因?yàn)镈NS服務(wù)能力（UDP）比HTTP服務(wù)要強(qiáng)很多（TCP）。

本文分析了DNS設(shè)置，以及HTTP轉(zhuǎn)發(fā)（URL Forwarding）請(qǐng)求的幾種不同方式，設(shè)計(jì)并實(shí)現(xiàn)了一種服務(wù)場(chǎng)景，可以為互聯(lián)網(wǎng)用戶提供高性能、易配置和服務(wù)靈活的URL轉(zhuǎn)發(fā)功能。

[參考文獻(xiàn)]

[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.