HTTP协议18丨四通八达:HTTP的重定向和跳转
这段文本主要介绍了HTTP协议中的重定向机制及其相关概念。重定向是服务器主动发起的跳转行为,用于将客户端重新发送到新的URL地址。文本重点讲解了以下内容:
重定向的类型:主动跳转(服务器发起)和被动跳转(客户端主动点击链接)。
状态码:301(永久重定向)和302(临时重定向)是常用的重定向状态码,分别用于永久性或临时性跳转。
Location字段:响应头中的字段用于指示目标URI,可以是绝对或相对URI。
应用场景:域名变更、服务器变更、系统维护等。
注意事项:避免性能损耗、循环跳转等问题。
总结:重定向是HTTP中重要的功能,用于服务器主动跳转客户端,通过状态码和Location字段实现目标URI的跳转,但需注意潜在问题。
超链接结构使得超文本中的内容可以通过超链接可以在文档中任意跳转,对线性文档的传统写作方式是一个彻底改变。
基于链接技术,万维网允许用户在任意位置跳转,将全球分散的文档连接成网状结构。此外,浏览器配备了前进、后退和书签等功能,使用户在文档间跳转更加便捷,具有更强的主动性和交互性。
点击页面中的“链接”会出现什么情况?比如在 Nginx 主页点击“download”链接会发生什么?
点击页面中的"链接"会出现什么情况?比如在 Nginx 主页点击"download"链接会发生什么?
结合所学知识,经过简单思考,答案便 readily available。首先,浏览器需要解析链接中的 URI 以识别其路径。
http://nginx.org/en/download.html |
|---|
复制代码
通过这个 URI,我们可以发送一个新的 HTTP 请求,响应报文获取后,页面会切换显示内容,以呈现新 URI 指向的页面。
再次使用这个 URI,启动一个新的 HTTP 请求,响应报文获取后,页面会切换显示内容,以渲染新 URI 指向的内容。
这样的跳转操作是由浏览器用户主动发起的,可被视为“主动跳转”操作。相反,有一类跳转是由服务器发起的,浏览器用户无法主动控制,因此可被视为“被动跳转”操作。在HTTP协议中,这类行为有特定术语,称为“重定向”(Redirection)。
重定向的过程
在之前的讲解中,我们已经介绍了重定向的基本概念。在第12讲中,301和302状态码时,我们已经提到过,301是“永久重定向”,302是“临时重定向”。当浏览器接收到这些状态码时,会跳转到新的URL地址。
那么,它们是如何实现功能的呢?难道仅仅依靠这两个代码就能完成页面跳转吗?
建议您首先进入实验环境,观察重定向过程的实现方式。通过 Chrome 浏览器访问 URI地址“/18-1”,该操作将执行 302 立即重定向,跳转至“/index.html”。

通过实验可以观察到,重定向过程实际上触发了两次HTTP请求。第一次响应的状态码为302,随后,第二个请求被重定向。如果没有开发者工具,用户无法直接观察到这个跳转过程,这表明,重定向过程对用户来说是'无感知的'。
我们再来看看第一个请求返回的响应报文:

在页面头部新增了一个字段,其名称为‘Location: /index.html’,这个字段是实现301/302跳转的关键因素。
Location字段属于响应字段,是必填项,必须包含在响应报文中。只有在与301或302状态码配合使用时才有意义。它标识了服务器要求重定向的目标URI,这里指定的跳转目标是index.html。
当浏览器处理301和302状态码时,会查看响应头中的'Location'字段。如果有该字段的值,就会解析出其中的URI并发起新的HTTP请求,相当于自动跳转到该链接。
在“Location”参数中,URI可以采用两种形式:完整形式和不完整形式。完整形式的URI包含了scheme、host:port、path等要素,而不完整形式仅包含path和query部分,需要通过上下文信息进行推导。
与其相比,该方案的性能表现令人印象深刻,这得益于其简洁的设计和简明的代码结构。
Location: /index.html”采用了相对URI。该方案未提及访问URI的协议和主机,但因为来自“chrono.com”的重定向响应报文,所以浏览器能够自动拼接完整的URI:
http://www.chrono.com/index.html |
|---|
复制代码
实验环境的 URI“/18-1”还可以使用 query 参数“dst=xxx”来指定重定向的目标 URI。你可以尝试使用这种形式再尝试几次重定向,以便更好地理解浏览器的工作机制。
http://www.chrono.com/18-1?dst=/15-1?name=a.json |
|
|---|---|
http://www.chrono.com/18-1?dst=/17-1 |
复制代码
在操作时,如果只是进行内部跳转,你无需担心使用相对 URI。然而,如果需要跳转到外部链接,就必须使用绝对 URI。
例如,跳转至Nginx官网时,必须在"nginx.org"前明确写出"HTTP://",否则浏览器会根据相对路径进行解析,这会导致请求指向一个不存在的URL:[http://www.chrono.com/nginx.org](http://www.chrono.com/nginx.org” "http://www.chrono.com/nginx.org””。
http://www.chrono.com/18-1?dst=nginx.org # 错误 |
|
|---|---|
http://www.chrono.com/18-1?dst=http://nginx.org # 正确 |
复制代码

那么,如果 301/302 跳转时没有 Location 字段会怎么样呢?
这个你也可以自己试一下,使用第 12 讲里的 URI“/12-1”,查询参数用“code=302”:
http://www.chrono.com/12-1?code=302 |
|---|
复制代码
重定向状态码
刚才我把重定向的过程基本讲完了,现在来说一下重定向用到的状态码。
最常用的重定向状态码是 301 和 302,此外还有少数几个不太常见的状态码,如 303、307 和 308 等。这些状态码在功能上大体一致,均会导致浏览器跳转到一个新的 URI,尽管在语义上存在细微的差别,使用时需要特别注意。
301 为HTTP状态码中的一个永久性重定向(Moved Permanently),其别名为“永久重定向”,表示原URI已不再存在,所有请求必须改用新的URI。
当浏览器检测到301重定向时,会意识到原始的URI已失效,并进行相应的优化。例如,用户的历史记录和书签会被更新,下次访问时会直接使用新的URI,避免了重复跳转的麻烦。搜索引擎的爬虫在处理301重定向时,会更新索引库,不再依赖旧的URI。
302状态码,通常被称作“临时重定向功能”(“Moved Temporarily”),其含义是原URL处于“临时维护状态”,而新的URL则充当“临时代理”,以顶替原URL直至维护期结束。
当浏览器或爬虫处理302响应时,它们将认为原始的URI仍然有效但不可用,因此仅执行简单的跳转页面,既不记录新的URI,也不会产生其他多余的操作。下次访问时仍使用原始的URI。
301/302 是最常用的重定向状态码,在 3××里剩下的几个还有:
303 See Other:类似于302,但要求重定向后的请求改为GET方法,访问结果页面,避免POST/PUT重复操作;
307 Temporary Redirect:类似于302,但重定向后的请求方法和实体不能改变,含义更加明确;
308 Permanent Redirect:类似于307,且重定向后的请求不能改变,相当于301的永久重定向。
然而这三个状态码不被广泛接受,并非所有浏览器和服务器都支持,开发时需要谨慎处理,只有在测试后才能确定浏览器的实际效果。
重定向的应用场景
我们不仅掌握了重定向的工作原理和状态码的含义,从而能够主动控制服务器行为,而且还要探索如何运用重定向技术以达到最佳效果。
使用重定向跳转,核心是要理解“重定向 ”和“永久 / 临时 ”这两个关键词。
先来看什么时候需要重定向。
一个最常见的原因就是“资源不可用 ”,需要用另一个新的 URI 来代替。
不可用的主要原因包括域名变更、服务器变更、网站改版以及系统维护等事项,这些都会导致原URL指向的资源无法正常访问。为避免出现404错误,需通过重定向将访问流量跳转至新的URL,持续为用户服务。
另一个原因是‘避免重复’,通过将多个网址重定向到一个URI,这样既增加了访问入口,也不会增加额外的工作量。
有些网站倾向于注册多个与主站名称相似的子域名,随后通过重定向指向主站。例如,你可以尝试访问QQ.com、GitHub.com、Bing.com(请确保缓存已清),以观察其重定向机制。
一旦决定要实行重定向,接下来需要考虑的问题所在,就是'永久性'和'临时性'的区分,具体来说,就是选择使用301还是302状态码。
301 的含义是“永久 ”的。
如果域名、服务器或网站架构发生了重大调整,例如更换了域名、迁移至新机房或重构网站目录结构,这些都属于永久性调整。更换后,原来的 URI 已不再有效,必须通过 301 永久重定向来更新指向,以便搜索引擎和浏览器能够及时同步相关信息,这也是 SEO 中需要考虑的重要因素之一。
302 的含义是“临时 ”的。
在某个特定时间点恢复,常见场景包括系统维护,此时会将网站跳转至通知页面,告知用户稍后即可访问。另外一种常见用法是“服务降级”,例如在双十一促销期间,会暂时关闭非核心功能入口,以确保核心服务持续运行。
重定向的相关问题
重定向的用途广泛,掌握重定向后,能够在搭建网站时获得更大的灵活性,但在实际应用中,还需注意两个问题。
性能损耗问题最为突出。重定向机制导致每次跳转产生两次请求-响应流程,相较于常规访问多了一次。
尽管301/302报文体积较小,但大量跳转对服务器带来的影响不容忽视。站内重定向问题不大,且支持长连接复用,站外重定向则需要开启两个连接,若网络连接质量不佳,成本将显著增加,用户体验也会因此受到影响。
所以重定向应当适度使用,决不能滥用。
第二个核心问题是「循环链路」。若重定向策略的设置不够周到,可能导致系统陷入「A→B→C→A」的无限循环,其后果不堪设想。
HTTP 协议明确要求浏览器必须具备检测"循环跳转"的能力,并在发现这种情况时拒绝发送请求并给出错误提示。
在实验环境中,URI“/18-2”模拟了一个循环跳转机制,该循环跳转指向“/18-1”,并借助“dst=/18-2”的参数实现自我回环,从而形成了两个 URI 之间的无限循环。
使用 Chrome 访问这个地址,会得到“该网页无法正常运作”的结果:

小结
今天我们学习了 HTTP 里的重定向和跳转,简单小结一下这次的内容:
- 服务器发起的 URL 跳转通常会自动执行,客户端需改用新的 URI 重新发送请求,用户在此过程中是无感知的;
- 301/302 是最常采用的重定向状态码,分别执行“永久重定向指令”和“临时重定向指令”;
- 响应头字段中的 Location 头字段指示了目标跳转的 URI,可以采用绝对或相对的方式表示;
- 重定向机制允许将一个 URI 映射到另一个 URI,同时支持多个 URI 指向同一个目标,应用十分广泛;
- 在使用重定向时,需特别注意可能产生的性能开销,同时应避免出现循环跳转的情况。
