基于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.