透视HTTP协议-基础篇-极客时间-笔记摘要

统一资源标识符URI

Uniform Resource Identifier，唯一的标记资源的位置

其完整形式如下：

其中scheme部分为协议名，表明应该用哪种协议来进行访问，一般有HTTP，HTTPS，FTP，FILE

“：//”仅代表分割符，无实际意义

user:passwd@这部分是身份信息，在现在的实际使用中已经抛弃这段，明文传输的账号密码容易造成安全隐患。

authority，是资源所在的主机，一般表示为host:port，主机IP加上端口号。我们经常见到的会省略端口号，因为一般客户端会更加协议来使用默认的端口号，比如HTTP的80端口和HTTPS的443端口。如果是用FILE协议访问本地资源甚至可以省略host:port。

path类似路径系统，找到资源所在的主机后，在根据路径来寻找资源。路径必须以'/'开头。服务端收到的请求头一般会将主机地址摘除出来，单独留下path。

?query查询参数，以'?'开头，以“key=value"键值对来表达，以'&'间隔不同的键值对。

#fragment片段标识符，用于在获取资源后快速定位到指定位置。该参数是不会发去服务端，只是获取资源后由客户端处理。

为了处理特殊字符和非英文语言，需要用"%"来进行转义，以英文加字母在网络中传输。

 

状态码

RFC标准将状态码分为五类：

1XX：提示信息，代表协议处理的中间状态，还需要后续处理；

2XX：成功，已收到且正确处理；

3XX：重定向，资源位置已转变，需要重新发送请求；

4XX：客户端错误，报文有误，服务器无法处理

5XX：服务端错误，服务器在内部处理请求时发生错误

除了规定的常用状态码外，还可以自定义状态码，进行扩展。

“200 OK”，常见的成功状态码。

“204 No Content”，成功，但返回报文没有BODY。

“206 Partial Content”，当前数据不完整，可用于分块传输或断点续传。

“301 Moved Permanently”，永久重定向，资源已更换位置。

“302 Found”，临时重定向，资源临时性的改变位置，比如维护升级。

“304 Not Modified”，用于缓存控制，页面未改变，可重定向到缓存页面。

“400 Bad Request”，最通用也最滥用的错误码，如果能够用更具体的错误码就不要回复该错误码。

“403 Forbidden”，服务器禁止访问资源。

“404 Not Found”，资源未找到。

“405 Method Not Allowed”，不允许使用某些方法操作资源， 例如不允许 POST 只能 GET。

“406 Not Acceptable”，资源无法满足客户端请求的条件，例如请求中文但只有英文。

“408 Request Timeout”，请求超时，服务器等待了过长的时间。

“409 Conflict”，多个请求发生了冲突，可以理解为多线程并发时的竞态。

“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”，内部错误，一般对外显示该错误即可，不用给用户暴露过多细节。

“501 Not Implemented”，暂不支持的功能

“502 Bad Gateway”，通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误。

“503 Service Unavailable”表示服务器当前很忙，暂时无法响应服务。该状态一般是暂时的，503 响应报文里通常还会有一个“Retry-After”字段，指示客户端可以在多久以后再次尝试发送请求。

 

HTTP的特点（针对HTTP /1.1)

• 无状态，每个请求都是互相独立、毫无关联的，协议不要求客户端或服务器记录请求相关的信息。
• 灵活可扩展，可以任意添加头字段实现任意功能
• 请求-应答，客户端主动发起请求，服务器被动回复请求
• 应用层协议，比 FTP、SSH 等更通用功能更多，能够传输任意数据
• 可靠传输，基于 TCP/IP 协议“尽量”保证数据的送达

HTTP 协议里的请求方法、URI、状态码、原因短语、头字段等每一个核心组成要素都没有被“写死”，允许开发者任意定制、扩充或解释。

无状态既有好处，也有坏处。好处是无状态，一方面可以减少服务器额外记录状态的开销，另一方面协议无状态就等于任意一台服务器来处理结果都是一致的，可以方便的通过增加机器来实现高并发和负载均衡。坏处则是不适用于有上下文的连贯性操作，最基础的比如论坛发帖及电商购物。

协议里的报文 header 部分不使用二进制数据，而是用简单可阅读的文本形式。直接用肉眼就可以很容易地查看或者修改，为我们的开发调试工作带来极大的便利。但这样所有信息都会暴露在“光天化日之下”，在漫长的传输链路的每一个环节上都毫无隐私可言。

在“身份认证”和“完整性校验”这两方面 HTTP 也是欠缺的。“身份认证”简单来说就是“怎么证明你就是你”。“完整性校验”，数据在传输过程中容易被窜改而无法验证真伪。

HTTP 协议基于 TCP/IP，并且使用了“请求 - 应答”的通信模式，所以性能的关键就在这两点上。现如今网络上高速高并发成为主流，TCP建立连续需要的资源消耗越来越成为瓶颈。而“请求 - 应答”模式则会造成“队头阻塞”（Head-of-line blocking）现象，当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。