Skip to content

Latest commit

 

History

History
238 lines (186 loc) · 19.4 KB

HTTP.md

File metadata and controls

238 lines (186 loc) · 19.4 KB

HTTP

HTTP 协议基本工作模式

请求 - 应答
一发一收

请求报文


HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成：

  1. 起始行（start line）：描述请求或响应的基本信息；
  2. 请求行
  3. 状态行
  4. 头部字段集合（header）：使用 key-value 形式更详细地说明报文；        
  5.  请求头
  6. 响应头        
  7. 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据
  8. 请求体
  9. 响应体

HTTP 协议规定报文必须有 header，但可以没有 body，而且在 header 之后必须要有一个“空行”，也就是“CRLF”，十六进制的“0D0A”。

请求行

请求报文里的起始行也就是请求行（request line），它简要地描述了客户端想要如何操作服务器端的资源。

请求行由三部分构成：

  1. 请求方法：是一个动词，如 GET/POST，表示对资源的操作；
  2. 请求目标：通常是一个 URI，标记了请求方法要操作的资源；
  3. 版本号：表示报文使用的 HTTP 协议版本。

这三个部分通常使用空格（space）来分隔，最后要用 CRLF 换行表示结束。

GET / HTTP/1.1

状态行

响应报文里的起始行，叫“状态行”（status line），意思是服务器响应的状态。

比起请求行来说，状态行要简单一些，同样也是由三部分构成：

  1. 版本号：表示报文使用的 HTTP 协议版本；
  2. 状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误；
  3. 原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因。

HTTP/1.1 200 OK

头部字段

请求行或状态行再加上头部字段集合就构成了 HTTP 报文里完整的请求头或响应头。
对 HTTP 报文的解析和处理实际上主要就是对头字段的处理，理解了头字段也就理解了 HTTP 报文。

HTTP 头字段非常灵活，不仅可以使用标准里的 Host、Connection 等已有头，也可以任意添加自定义头，这就给 HTTP 协议带来了无限的扩展可能。

不过使用头字段需要注意下面几点：

  1. 字段名不区分大小写，例如“Host”也可以写成“host”，但首字母大写的可读性更好；
  2. 字段名里不允许出现空格，可以使用连字符“-”，但不能使用下划线“_”。例如，“test-name”是合法的字段名，而“test name”“test_name”是不正确的字段名；
  3. 字段名后面必须紧接着“:”，不能有空格，而“:”后的字段值前可以有多个空格；
  4. 字段的顺序是没有意义的，可以任意排列不影响语义；
  5. 字段原则上不能重复，除非这个字段本身的语义允许，例如 Set-Cookie。

常用头字段

HTTP 协议规定了非常多的头部字段，实现各种各样的功能，但基本上可以分为四大类：

  1. 通用字段：在请求头和响应头里都可以出现；
  2. 请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；
  3. 响应字段：仅能出现在响应头里，补充说明响应报文的信息；
  4. 实体字段：它实际上属于通用字段，但专门描述 body 的额外信息。

Host（请求字段）
Host 字段告诉服务器这个请求应该由哪个主机来处理，当一台计算机上托管了多个虚拟主机的时候，服务器端就需要用 Host 字段来选择，有点像是一个简单的“路由重定向”。

User-Agent（请求字段）
它使用一个字符串来描述发起 HTTP 请求的客户端，服务器可以依据它来返回最合适此浏览器显示的页面。

Date（通用字段）
但通常出现在响应头里，表示 HTTP 报文创建的时间，客户端可以使用这个时间再搭配其他字段决定缓存策略。

Server（响应字段）
它告诉客户端当前正在提供 Web 服务的软件名称和版本号。

**Content-Length **(实体字段)
它表示报文里 body 的长度，也就是请求头或响应头空行后面数据的长度。服务器看到这个字段，就知道了后续有多少数据，可以直接接收。

请求方法

HTTP 协议里为什么要有“请求方法”这个东西呢？
HTTP的作者最初的设想是使用HTTP 协议构建一个超链接文档系统，使用 URI 来定位这些文档，也就是资源。那么，该怎么在协议里操作这些资源呢？很显然，需要有某种“动作的指示”，告诉操作这些资源的方式。所以，就这么出现了“请求方法”。它的实际含义就是客户端发出了一个“动作指令”，要求服务器端对 URI 定位的资源执行这个动作。

目前 HTTP/1.1 规定了八种方法，单词都必须是大写的形式。

  1. GET：获取资源，可以理解为读取或者下载数据；
  2. HEAD：获取资源的元信息；
  3. POST：向资源提交数据，相当于写入或上传数据；
  4. PUT：类似 POST；
  5. DELETE：删除资源；
  6. CONNECT：建立特殊的连接隧道；
  7. OPTIONS：列出可对资源实行的方法；
  8. TRACE：追踪请求 - 响应的传输路径。

HTTP method 有点像对文件或数据库的“增删改查”操作，只不过这些动作操作的目标不是本地资源，而是远程服务器上的资源，所以只能由客户端“请求”或者“指示”服务器来完成。
既然请求方法是一个“指示”，那么客户端自然就没有决定权，服务器掌控着所有资源，也就有绝对的决策权力。它收到 HTTP 请求报文后，看到里面的请求方法，可以执行也可以拒绝，或者改变动作的含义，毕竟 HTTP 是一个“协议”，两边都要“商量着来”。这也是为什么 GET 和 POST 方法最为常用，经常只使用 GET 和 POST 方法就完成了资源的增删改查。

请求方法是客户端发出的、要求服务器执行的、对资源的一种操作；
请求方法是对服务器的“指示”，真正应如何处理由服务器来决定。

GET

GET方法应该是 HTTP 协议里最知名的请求方法了，也应该是用的最多的，自 0.9 版出现并一直被保留至今。
它的含义是请求从服务器获取资源，这个资源既可以是静态的文本、页面、图片、视频，也可以是由 PHP、Java 动态生成的页面或者其他格式的数据。
GET 方法虽然基本动作比较简单，但搭配 URI 和其他头字段就能实现对资源更精细的操作。

HEAD

HEAD方法与 GET 方法类似，也是请求从服务器获取资源，服务器的处理机制也是一样的，但服务器不会返回请求的实体数据，只会传回响应头，也就是资源的“元信息”。HEAD 方法可以看做是 GET 方法的一个“简化版”或者“轻量版”。因为它的响应头与 GET 完全相同，所以可以用在很多并不真正需要资源的场合，避免传输 body 数据的浪费。比如，想要检查一个文件是否存在，只要发个 HEAD 请求就可以了，没有必要用 GET 把整个文件都取下来。再比如，要检查文件是否有最新版本，同样也应该用 HEAD，服务器会在响应头里把文件的修改时间传回来。

POST

POST 和 PUT 方法向 URI 指定的资源提交数据，数据就放在报文的 body 里。
POST 也是一个经常用到的请求方法，使用频率应该是仅次于 GET，应用的场景也非常多，只要向服务器发送数据，用的大多数都是 POST。

PUT

PUT 的作用与 POST 类似，也可以向服务器提交数据，但与 POST 存在微妙的不同，通常 POST 表示的是“新建”“create”的含义，而 PUT 则是“修改”“update”的含义。
在实际应用中，PUT 用到的比较少。而且，因为它与 POST 的语义、功能太过近似，有的服务器甚至就直接禁止使用 PUT 方法，只用 POST 方法上传数据。

DELETE

**DELETE **方法指示服务器删除资源，因为这个动作危险性太大，所以通常服务器不会执行真正的删除操作，而是对资源做一个删除标记。当然，更多的时候服务器就直接不处理 DELETE 请求。

CONNECT

**CONNECT **是一个比较特殊的方法，要求服务器为客户端和另一台远程服务器建立一条特殊的连接隧道，这时 Web 服务器在中间充当了代理的角色。

OPTIONS

**OPTIONS **方法要求服务器列出可对资源实行的操作方法，在响应头的 Allow 字段里返回。它的功能很有限，用处也不大，有的服务器（例如 Nginx）干脆就没有实现对它的支持。
**为了 WEB 安全，有时会要求关闭服务器的 **OPTIONS **** 方法支持，防止暴露可对资源实行的操作方法。

TRACE

**TRACE **方法多用于对 HTTP 链路的测试或诊断，可以显示出请求 - 响应的传输路径。它的本意是好的，但存在漏洞，会泄漏网站的信息，所以 Web 服务器通常也是禁止使用。

安全与幂等

安全

在 HTTP 协议里，所谓的“安全”是指请求方法不会“破坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。
按照这个定义，只有 GET 和 HEAD 方法是“安全”的，因为它们是“只读”操作，只要服务器不故意曲解请求方法的处理方式，无论 GET 和 HEAD 操作多少次，服务器上的数据都是“安全的”。
而 POST/PUT/DELETE 操作会修改服务器上的资源，增加或删除数据，所以是“不安全”的。

幂等

幂等意思是多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”。
GET 和 HEAD 既是安全的也是幂等的；
DELETE 可以多次删除同一个资源，效果都是“资源不存在”，所以也是幂等的；
POST 是“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等的；
PUT 是“替换或更新数据”，多次更新一个资源，资源还会是第一次更新的状态，所以是幂等的。

URI

URI，也就是统一资源标识符（Uniform Resource Identifier）。因为它经常出现在浏览器的地址栏里，所以俗称为“网络地址”，简称“网址”。
严格地说，URI 不完全等同于网址，它包含有 URL 和 URN 两个部分，在 HTTP 世界里用的网址实际上是 URL——统一资源定位符（Uniform Resource Locator）。但因为 URL 实在是太普及了，所以常常把这两者简单地视为相等。
URI 本质上是一个字符串，这个字符串的作用是唯一地标记资源的位置或者名字。

URI 的组成

  1. URI 通常由 scheme、host:port、path 和 query 四个部分组成，有的可以省略；
  2. scheme 叫“方案名”或者“协议名”，表示资源应该使用哪种协议来访问；
  3. host:port 表示资源所在的主机名和端口号；
  4. path 标记资源所在的位置；
  5. query 表示对资源附加的额外要求；使用“协议名 + 主机名 + 路径”的方式，已经可以精确定位网络上的任何资源了。但这还不够，很多时候我们还想在操作资源的时候附加一些额外的修饰参数(查询参数)。

URI 的编码

在 URI 里对“@&/”等特殊字符和汉字必须要做编码，否则服务器收到 HTTP 报文后会无法正确处理。

URI 转义的规则有点“简单粗暴”，直接把非 ASCII 码或特殊字符转换成十六进制字节值，然后前面再加上一个“%”(浏览器为了保证URI的可读性做了优化，可以将URL copy 到其他地方，此时会变成编码之后的内容)。

http://nginx.org
http://www.chrono.com:8080/11-1
https://tools.ietf.org/html/rfc7230
file:///D:/http_study/www/

状态码

状态码（Status Code）是一个十进制数字，以代码的形式表示服务器对请求的处理结果，就像我们通常编写程序时函数返回的错误码一样。
目前 RFC 标准里规定的状态码是三位数，所以取值范围就是从 000 到 999。RFC 标准里总共有 41 个状态码，但状态码的定义是开放的，允许自行扩展。RFC 标准把状态码分成了五类，用数字的第一位表示分类，而 099 不用，这样状态码的实际可用范围就大大缩小了，由 000999 变成了 100~599。
这五类的具体含义是：

  • 1××：提示信息，表示目前是协议处理的中间状态，还需要后续的操作；
  • 2××：成功，报文已经收到并被正确处理；
  • 3××：重定向，资源位置发生变动，需要客户端重新发送请求；
  • 4××：客户端错误，请求报文有误，服务器无法处理；
  • 5××：服务器错误，服务器在处理请求时内部发生了错误。
状态码 状态码英文名称 中文描述
100 Continue 继续。客户端应继续其请求
101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200 OK 请求成功。一般用于GET与POST请求
201 Created 已创建。成功请求并创建了新的资源
202 Accepted 已接受。已经接受请求，但未处理完成
203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205 Reset Content 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206 Partial Content 部分内容。服务器成功处理了部分GET请求
300 Multiple Choices 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303 See Other 查看其它地址。与301类似。使用GET和POST请求查看
304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305 Use Proxy 使用代理。所请求的资源必须通过代理访问
306 Unused 已经被废弃的HTTP状态码
307 Temporary Redirect 临时重定向。与302类似。使用GET请求重定向
400 Bad Request 客户端请求的语法错误，服务器无法理解
401 Unauthorized 请求要求用户的身份认证
402 Payment Required 保留，将来使用
403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求
404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405 Method Not Allowed 客户端请求中的方法被禁止
406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求
407 Proxy Authentication Required 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408 Request Time-out 服务器等待客户端发送的请求时间过长，超时
409 Conflict 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突
410 Gone 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411 Length Required 服务器无法处理客户端发送的不带Content-Length的请求信息
412 Precondition Failed 客户端请求信息的先决条件错误
413 Request Entity Too Large 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414 Request-URI Too Large 请求的URI过长（URI通常为网址），服务器无法处理
415 Unsupported Media Type 服务器无法处理请求附带的媒体格式
416 Requested range not satisfiable 客户端请求的范围无效
417 Expectation Failed 服务器无法满足Expect的请求头信息
500 Internal Server Error 服务器内部错误，无法完成请求
501 Not Implemented 服务器不支持请求的功能，无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求
505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本，无法完成处理