HTTP Status Code 实战相关的小技巧

很久很久很久没写博客了，趁着最近捣鼓的一次分享，将分享内容顺带总结成一篇小博客。话很少说，Let's fighting!

关于 HTTP 状态码，相信大部分小伙伴并不陌生。

• ajax 对接后台的接口返回 200
• 后台接口报错了返回了 500
• 前端面试常常被问到的 304
• 网页找不到了返回 404
• 更多...

显而易见，HTTP 状态码“潜伏”在咱们平常工做的许多许多小细节中，那劳烦各位亲再细想一下，你对 HTTP 状态码，足够熟悉吗？

举几个例子

• 后台返回了 5xx 状态码，都是后台的锅吗？
• 有没有留意过啥时候会返回 1xx 开头的状态码？
• 永久重定向和临时重定向表现出来的差别是什么？

带着这几个例子，结合小弟我平常工做中的一些实践，浪咱们一块儿 look 一 look，HTTP 状态码在实战中，有没有神奇功效？

案例 1，如何利用 50四、502 状态码进行更精准的“甩锅”

假设在 S 公司中，有如下这几个角色：

• 小 A，咱们的前端小伙伴，负责页面开发以及调用后端数据
• 小 B，后端小伙伴，使用 go 搭建了整个业务后台
• 小 G，运维筒子，负责把先后端项目捣鼓成 docker 容器部署上线

场景 1，某一天，小 A 发现了内部开发环境中，后台接口返回了 504 状态码，并在返回的错误描述中看到了“Timeout”的关键字。因而小 A 质问小 B，大家后台有 Bug！

脆弱的小 B 受不了质疑，回复：“你的 Bug 才叫 504，你天天写的都是 504！”

本着实事求是（甩锅要有理有据）的态度，小 A 开始了推演。咱们的目的很简单：证实服务器挂了。

首先，梳理一下服务器挂了能有几种可能：

1. 服务器直接 dang 机
2. 服务器活着，可是内部某个环节出了问题，致使不响应请求
3. 后台同窗接口写错了，调用的目标接口非法或不存在
4. 代理服务器挂了（例如 Nginx）
5. more...

小 A 顺着梳理出来的这些可能，随手用 express + nginx 搭建了一套环境，开始了逐一模拟排查。

// express 中，建立一个路由
//...省略其余代码

router.get('/hello', (req, res) => {
  res.end('hello');
});
//...
复制代码

# nginx 中，添加一个路由配置
server {
    listen       80;
    server_name  ooo.test.com; # 本地host配的一个域名：127.0.0.1 ooo.test.com
    #charset koi8-r;
    access_log  /usr/local/etc/nginx/log/host.access.log  main;
	location / {
	    proxy_pass   http://127.0.0.1:3000/;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header REMOTE-HOST $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Url  "$scheme://$host$request_uri";
            proxy_read_timeout 3; #为了更快看到效果，添加3秒超时设置（nginx默认为1分钟）
	}
}
复制代码

接下来开始模拟各类场景：

0. 正常访问http://ooo.test.com/hello

   

   测试结果：符合预期，返回200而且成功打印“hello”

1. 模拟服务器dang机，关闭express服务，再访问 ooo.test.com/hello

   

   测试结果：返回502 Bad Gateway

2. 服务器活着，可是内部某个环节出了问题，致使不响应请求。咱们改一下代码，将接口返回去掉，代码以下。启动express服务，再访问网页

   router.get('/hello', (req, res) => {
     //res.end('hello');
   });
   复制代码

   

   测试结果：loading3秒后，显示504Gateway Time-out

3. 后台同窗接口写错了，调用的目标接口非法或不存在。这个比较简单，参数错误返回400、未登陆返回40一、pathname错误返回404，就不进行模拟了。

4. 代理服务器挂了（例如 Nginx）。nginx、网关服务器通常只作数据转发，挂掉的可能性微乎极微。咱们能够试着把nginx关了，访问网页。

   

经过以上测试，咱们能够直观的发现：

• 502: 服务器dang机，代理服务器没法访问业务服务
• 504: 服务器内部异常，代理服务器访问业务超时未响应

接下来小A拿着测试结论找到了小B同窗，胁迫小B同窗进行排查定位并发现后台服务内存泄漏，致使接口未响应。“甩锅”完成！

案例2，临时重定向与永久重定向

面试的时候，有时我会问同窗们，知道301和302状态码的区别吗？他们分别会在什么场景下被用到？大部分同窗都能回答，一个是临时重定向，一个是永久重定向。但再多的，就没有了。话很少说，咱们先来借助代码，看一下临时重定向与永久重定向在浏览器上表现出来的差别。

// 仍是刚刚那个express的项目


router.get('/hello', (req, res) => {
	//301，将这个路径永久重定向到百度
	res.writeHead(301, { Location: 'http://www.baidu.com/' }); 
	res.end();
})
复制代码

OK，重启一下express，访问http://ooo.test.com/hello。

能够看到返回了301的状态码，页面成功跳转到了百度。细心的同窗还会发现，多刷新几回页面，301状态码后面还会带着（from disk cache），这个有啥用呢？咱们作两个尝试：

1. 修改代码，将重定向地址改成http://www.google.com
2. 直接关闭express服务

没错，结果就是，不管你作了任何改动，访问http://ooo.test.com/hello，都仍是打开了百度首页。这就是永久缓存的“魅力”所在了——from disk cache！永久缓存将重定向信息缓存到了你的浏览器中，除非你清除浏览器缓存，不然不管你服务怎么变动，对你来讲，对不起，都无济于事。因此这也是永久缓存的可怕之处～ 慎用慎用。

相对而言，临时缓存便安全得多。咱们把上面的代码作一下稍微的修改：

router.get('/hello', (req, res) => {
	//302，将这个路径临时重定向到百度
	res.writeHead(302, { Location: 'http://www.baidu.com/' }); 
	res.end();
})
复制代码

打开浏览器访问http://ooo.test.com/hello，会发现成功跳转到百度，观察控制台；再次访问http://ooo.test.com/hello，再观察express输出多控制台日志。

会发现每次访问/hello， 服务器都会收到一个请求，因此浏览器并不会缓存临时重定向的数据。这也就是临时重定向和永久重定向表现上的本质差别啦～

**小结，**举了两个简单的小例子，分别说明了状态码在协助咱们定位问题、功能实现上的起到的小做用。写的不对的，欢迎各位同志予以批判！有其余想了解的状态码使用场景，也欢迎留言一块儿探讨一波噢！

@Author: _Jay.Lam