1 信息类

html
100		Continue/继续		接受的请求正在处理，信息状态码
101		Switching Protocols/转换协议
101		SC_SWITCHING_PROTOCOLS		状态码是指服务器将按照其上的头信息变为一个不同的协议。这是
HTTP 1.1中新加入的。

2 成功类

html
200		Success		服务器已成功处理了请求
201		Created/已创建
202		Accepted/接受
204		No Content/无内容		请求处理成功，但没有任何资源可以返回给客户端，一般用户客户端不需要服务端响应新内容时使用

3 重定向

html
301		Moved Permanently		永久性重定向，表示资源已被分配新的URL
302		Found/找到		临时新重定向，表示资源临时被分配了新的URL，比如re.jd.com会自动跳转到www.jd.com
303		See Other/参见其他信息		这个状态码和301，302相似，如果最初的请求是 POST ，那么新文档（在定位头信息中给出）要用 GET 找回，这个状态码是新加入的 HTTP 1.1 中的
304		Not Modified/未修改		自从上次请求后，请求网页未修改过。服务器返回此响应时，不会返回网页内容，客户端看到的页面还是上一次请求缓存下来的页面。当客户端有一个缓存的文档，通过提供一个 IF-Modified-Since 请求头信息可指出客户端希望文档在指定日期之后有修改时才会重载此文档
307		Temporary Redirect/临时重定向		浏览器处理 307 状态的规则和 302 相同，307 状态被加入到HTTP 1.1中是由于许多浏览器在收到302响应时即使是原始消息为POST的情况下仍然执行了错误的转向。只有在收到303响应时才假定浏览器会在POST请求时重定向。添加这个新的状态码的目的很明确：在响应为303时按照GET和POST请求转向;而在307响应时则按照GET请求转向而不是POST请求。

4 客户端错误

400		Bad Request/错误请求		服务器不理解请求的语法
401		Unauthorized/未授权		表示发送的请求需要有通过 HTTP 认证的认证信息，客户端在授权头信息中没有有效的身份信息时访问受到密码保护的页面
403		Forbidden/禁止		服务器拒绝请求，意思是除非拥有授权否则服务器拒绝提供所请求的资源
404		Not Found/未找到		服务器找不到请求页面，也就是告诉客户端说给的地址无法找到如何资源
405		Method Not Allowed/方法未允许		指出请求方法（GET POST HEAD PUT DELETE等）对某些特定的资源不允许使用
406		Not Acceptable/无法访问		表示请求资源的MIME类型与客户端中Accept头信息中指定的类型不一致

5 服务器错误

500		Internal Server Error/内部服务器错误		表示服务器遇到错误，无法完成正常的请求处理，可能是web应用存在bug或某些临时崩溃了
501		Not Extended/尚未实施		表示服务器不支持当前请求所需要的某个功能
502		Bad Gateway/错误的网关		表示服务器作为网关或代理，从上游服务器收到无效响应，例如 Nginx+uWSGI，当uWSGI服务没有启动成功或异常退出，而Nginx服务是正常的情况下，就会看到502
503		Service Unavailable/服务无法获得		表示服务器处于停机维护或超负载，无法正常响应
504		Gateway Timeou/网关超时		表示扮演网关或者代理的服务器无法在规定的时间内获得想要的响应 502和504基本都是web服务器故障引起的
505		HTTP version Not Supported/HTTP 版本不支持
506		Variant Also Negotiates/变体协商		表示服务器内部配置错误
507		Insufficient Storage/存储错误		表示服务器无法存储完成请求所必须的内容，这个状况被认为是临时的，一般是数据库出问题时会看到这个状态码

总结单向认证的SSL/TLS的握手过程

1. 客户端请求服务端，携带者自己支持的SSl\TLS版本信息、随机数等
2. 服务端将证书、服务端的SSL\TLS版本信息发送给客户端，并且将自己的公钥(server_pub)放到证书中
3. 客户端对证书进行验证，验证通过后，将自己支持的对称加密算法方案发送给服务端，供服务端选择
4. 服务端选择一个优质的算法方案，然后将选择的方法明文发送给客户端
5. 客户端生成一个随机字符串pre_master_secret，通过协商好的算法计算得出对称加密的密钥secret_key，然后利用服务端的公钥server_pub对pre_master_secret进行非对称加密，得到mi_secret_key数据，然后将这个数据发送给服务端
6. 服务端利用自己的私钥对mi_secret_key进行解密，得到pre_master_secret，然后通过协商好的算法对pre_master_secret进行加密，得到密钥secret_key，然后利用选好的对称加密算法和secret_key对响应数据进行加密，然后发送给客户端
7. 客户端利用相同的对称加密算法和自己这一端保存的那个secret_key来解密得到响应数据