作为爬虫工程师，每天都要和http协议打交道，那么我先提一个问题，大家思考下http状态响应码的作用是什么？日常开发中我们也许只需要知道2xx、4xx、5xx就够了。遇到2xx，我们知道请求成功了，万事大吉。遇到4xx，我们知道客户端出错了，这时我们需要检查是链接写错了，还是该链接没有权限访问等等。而遇到5xx，则是服务端出错了，这时我们去看日志，定位问题。以上，我们只是把响应状态码当做日志使用，而响应状态码作为客户端与服务端交互的媒介，其真正的作用是指导客户端后续的行为。比如返回3xx，代表资源已转移，请客户端重定向到给定地址。返回216，代表返回的只是资源的一部分，客户端应继续请求资源的剩余部分等等。下面我们将详细介绍http常见的响应状态码。
1xx状态码实际能够用到的时候很少，我们偶尔能够见到的是"101 Switching Protocols"，即正在切换协议。例如客户端使用Upgrade头字段，提议让服务端改成其他的协议继续通信，比如WebSocket，而如果服务器也同意变更协议，就会返回状态码101，之后两端的数据传输就不会再使用HTTP协议了，而是改为协商好的WebSocket。下面这个例子是在淘宝商品搜索页搜索商品时，其中的一个请求信息，大家可以自己查看
"200 OK" 是最常见的成功状态码，表示一切正常，服务器如客户端所期望的那样返回了处理结果，如果是非HEAD请求，通常在响应头后都会有body数据；
"201 Created" 表示请求成功，并在服务器上创建了新的资源，通常是POST请求、PUT请求成功后返回的状态码；
"202 Accepted" 表示服务端已接受请求，但请求的处理尚未完成。这个状态码的设计被用来将请求交由另外一个进程或者服务器进行处理，或者是对请求进行批处理的场景。比如一个大作业无法及时完成，为了避免客户端一直等待下去，先返回此状态码，客户端接收到该状态码就可以断开连接了；
"204 No Content" 表示服务端成功处理了客户端的请求，但服务端无返回内容，没有更新的文档，客户端应该继续使用原来的文档。比如用户定期地刷新页面，而服务端可以确定客户端的文档足够新，这个状态代码是很有用的，这样可以减少不必要的数据传输；
"206 Partial Content" 是HTTP分块下载或断点续传的基础，在客户端发送“范围请求”、要求获取资源的部分数据时出现，它与200一样，也是服务器成功处理了请求，但body里的数据不是资源的全部，只是其中的一部分。状态码206通常还会伴随着头字段“Content-Range”，表示响应报文里body数据的具体范围，供客户端确认，例如“Content-Range: bytes 0-99/2000”，意思是此次获取的是总计2000个字节的前100个字节;
我们用curl命令演示下范围请求图片的过程，curl命令的使用方法后面会有单独的一节介绍
1、查看服务器是否支持范围请求，命令：curl -I ${图片地址},如上图
curl -I http://www.yka365.com/blog/images/afs01.gif
2、分两步请求图片，命令：curl --header "Range: bytes=${开始的位置}-${结束的位置}" ${图片地址} -o ${本地临时保存路径}
curl --header "Range: bytes=0-17000" http://www.yka365.com/blog/images/afs01.gif -o part1
curl --header "Range: bytes=17001-17700" http://www.yka365.com/blog/images/afs01.gif -o part2
3、将两部分合并为一张完整的图片，命令：cat ${图片的第一部分文件名} ${图片的第二部分文件名} >> ${完整的图片名}
cat part1 part2 >> full.gif
"301 Moved Permanently" 称为永久重定向，代表请求的资源已经不存在了，需要改用新的URI再次访问；
"302 Found" 称为临时重定向，代表请求的资源还在，只是暂时用另外一个URI代替；
301和302都会在响应头里使用字段 Location 指明后续要跳转的 URI，最终的效果很相似，浏览器都会重定向到新的 URI。两者的根本区别在于语义，一个是“永久”，一个是“临时”，所以用在不同的场景中;
比如你个人博客网站的域名要进行切换，原来的域名不打算用了，这就是永久重定向，这时你就应该配置301重定向，将原来的网址重定向到新的网址上。
而如果今天夜里你的博客网站要进行系统维护，服务暂时不可用，这就属于“临时”的，此时可以配置成 302 跳转，把流量临时切换到一个静态通知页面，浏览器看到这个 302 就知道这只是暂时的情况，不会做缓存优化，第二天还会访问原来的地址。
"304 Not Modified" 是服务端告诉客户端 “请求的资源没有做过更新，请继续使用客户端已缓存的资源”，即重定向到缓存。其过程是这样的，客户端发请求前，发现要请求的资源已经在缓存中了，但是不确定缓存中的内容是否已过期，于是查看缓存中资源的 Last Modified 时间，然后向服务端发送请求，请求头中加上 If-Modified-Since 参数，值为 Last Modified 时间。服务端收到请求后，比较资源的修改时间和客户端请求头中的 Last Modified 时间，若大于请求头中的Last Modified 时间则返回200状态码，并在响应体中返回最新的资源。否则只返回304状态码，这样可以减少不必要的数据传输;
"400 Bad Request" 是一个通用的错误码，表示请求报文有错误，但具体是数据格式错误、缺少请求头还是 URI 超长它没有明确说，只是一个笼统的错误。客户端看到 400 只会是一头雾水，不知所措。所以，在开发 Web 应用时应当尽量避免给客户端返回 400，而是要用其他更有明确含义的状态码；
"401 Unauthorized" 要求身份验证。对于需要登录才能访问的网页，服务器可能返回此响应；
"403 Forbidden" 实际上不是客户端的请求出错，而是表示服务器禁止访问资源。原因可能多种多样，例如信息敏感、用户本身没有权限，如果服务器友好一点，可以在 body 里详细说明拒绝请求的原因；
"404 Not Found" 是我们经常看到的一个状态码，它的意思是资源在服务器上未找到，所以无法提供给客户端；
"405 Method Not Allowed" 服务端不允许使用某些方法操作资源，例如不允许 POST 只能 GET；
"406 Not Acceptable" 资源无法满足客户端请求的条件，例如要请求中文，但服务端只有英文；
"408 Request Timeout" 请求超时，当客户端和服务端建立连接后，服务端迟迟没有收到请求数据，于是服务端主动放弃该连接；
"409 Conflict" 多个请求发生了冲突，冲突最有可能发生在对 PUT 请求的响应中。例如，当上传文件的版本比服务器上已存在的要旧，从而导致版本冲突的时候，那么就有可能收到状态码为 409 的响应；
"413 Request Entity Too Large" 请求报文里的 body 太大；
"414 Request-URI Too Long" 请求行里的 URI 太大；
"429 Too Many Requests" 客户端发送了太多的请求，通常是由于服务器的限连策略；
"431 Request Header Fields Too Large" 请求头某个字段或总体太大；
"500 Internal Server Error" 与 400 类似，也是一个通用的错误码，服务器究竟发生了什么错误我们也不知道。不过对于服务器来说这应该算是好事，通常不应该把服务器内部的详细信息，例如出错的函数调用栈告诉外界。虽然不利于调试，但能够防止黑客的窥探或者分析；
"501 Not Implemented" 表示客户端请求的功能还不支持。比如请求 findUser 这个方法，而服务端暂时还没实现这个服务，此时就可以返回501。这个错误码提示用户将来是打算提供 findUser 这个服务的，但是什么时候实现还不确定，敬请期待吧；
"502 Bad Gateway" 通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误，但具体的错误原因也是不知道的；
"503 Service Unavailable" 表示服务器当前很忙，暂时无法响应服务，我们上网时有时候遇到的“网络服务正忙，请稍后重试”的提示信息就是状态码 503。503 是一个“临时”的状态，很可能过几秒钟后服务器就不那么忙了，可以继续提供服务，所以 503 响应报文里通常还会有一个"Retry-After"字段，指示客户端可以在多久以后再次尝试发送请求；
答、两者的原因不同，429是客户端请求太多，处理不过来，而503是服务器内部的问题，不一定是客户端请求太多。
Copyright © 中年码农 all right reserved，powered by Gitbook本文更新于：
2020-11-25 20:40:13 
