深入理解 HTTP 协议
简介
HTTP 协议(超文本传输协议 HyperText Transfer Protocol), 它是基于 TCP 协议的应用层传输协议, 简单来说就是客户端和服务端进行数据传输的一种规则.
注意: 客户端与服务器的角色不是固定的, 一端充当客户端, 也可能在某次请求中充当服务器. 这取决与请求的发起端. HTTP 协议属于应用层, 建立在传输层协议 TCP 之上. 客户端通过与服务器建立 TCP 连接, 之后发送 HTTP 请求与接收 HTTP 响应都是通过访问 Socket 接口来调用 TCP 协议实现.
HTTP 是一种无状态 (stateless) 协议, HTTP 协议本身不会对发送过的请求和相应的通信状态进行持久化处理. 这样做的目的是为了保持 HTTP 协议的简单性, 从而能够快速处理大量的事务, 提高效率.
然而, 在许多应用场景中, 我们需要保持用户登录的状态或记录用户购物车中的商品. 由于 HTTP 是无状态协议, 所以必须引入一些技术来记录管理状态, 例如 Cookie.
正文
HTTP URL
HTTP URL 包含了用于查找某个资源的详细信息, 格式如下:
http://host[":"port][abs_path]
HTTP 请求
下图是在网上找的一张图, 觉得能很好的表达 HTTP 请求的所发送的数据格式.
由上图可以看到, http 请求由请求行, 消息报头, 请求正文三部分构成.
HTTP 请求状态行
请求行由请求 Method, URL 字段和 HTTP Version 三部分构成, 总的来说请求行就是定义了本次请求的请求方式, 请求的地址, 以及所遵循的 HTTP 协议版本例如:
GET /example.html HTTP/1.1 (CRLF)
HTTP 协议的方法有:
GET: 请求获取 Request-URI 所标识的资源
POST: 在 Request-URI 所标识的资源后增加新的数据
HEAD: 请求获取由 Request-URI 所标识的资源的响应消息报头
PUT: 请求服务器存储或修改一个资源, 并用 Request-URI 作为其标识
DELETE: 请求服务器删除 Request-URI 所标识的资源
TRACE: 请求服务器回送收到的请求信息, 主要用于测试或诊断
CONNECT: 保留将来使用
OPTIONS: 请求查询服务器的性能, 或者查询与资源相关的选项和需求
HTTP 请求头
消息报头由一系列的键值对组成, 允许客户端向服务器端发送一些附加信息或者客户端自身的信息, 主要包括:
| Header | 解释 | 示例 |
|---|---|---|
| Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/HTML |
| Accept-Charset | 浏览器可以接受的字符编码集 | Accept-Charset: iso-8859-5,utf-8 |
| Accept-Encoding | 指定浏览器可以支持的 web 服务器返回内容压缩编码类型 | Accept-Encoding: compress, gzip |
| Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
| Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
| Authorization | HTTP 授权的授权证书类型 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久连接（HTTP 1.1 默认进行持久连接） | Connection: close |
| Cookie | HTTP 请求发送时，会把保存在该请求域名下的所有 cookie 值一起发送给 Web 服务器 | Cookie: $Version=1; Skin=new; |
| Content-Length | 请求的内容长度 | Content-Length: 348 |
| Content-Type | 请求的与实体对应的 MIME 信息 | Content-Type: application/x-www-form-urlencoded |
| Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 请求的特定的服务器行为 | Expect: 100-continue |
| From | 发出请求的用户的 Email | From: mailto:user@email.com |
| Host | 指定请求的服务器的域名和端口号 | Host: http://www.zcmhi.com |
| If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回 304 代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果内容未改变返回 304 代码，参数为服务器先前发送的 Etag，与服务器回应的 Etag 比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为 Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制信息通过代理和网关传送的时间 | Max-Forwards: 10 |
| Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
| Proxy-Authorization | 连接到代理的授权证书 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只请求实体的一部分，指定范围 | Range: bytes=500-999 |
| Referer | 先前网页的地址，当前请求网页紧随其后, 即来路 | Referer: http://www.zcmhi.com/archives/71.HTML |
| TE | 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息 | TE: trailers,deflate;q=0.5 |
| Upgrade | 向服务器指定某种传输协议以便服务器进行转换（如果支持） | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | User-Agent 的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | 通知中间网关或代理服务器地址，通信协议 | Via: 1.0 fred, 1.1 http://nowhere.com (Apache/1.1) |
| Warning | 关于消息实体的警告信息 | Warn: 199 Miscellaneous warning |
HTTP 请求正文
只有在发送 POST 请求时才会有请求正文, GET 方法并没有请求正文.
HTTP 请求报文
HTTP 响应
与 HTTP 请求类似, 先上一张图:
HTTP 响应也由三部分组成, 包括状态行, 消息报头, 响应正文.
HTTP 响应状态行
状态行也由三部分组成, 包括 HTTP 协议的版本, 状态码, 以及对状态码的文本描述. 例如:
HTTP/1.1 200 OK (CRLF)
HTTP 响应状态码
状态代码有三位数字组成, 第一个数字定义了响应的类别, 且有五种可能取值:
1xx: 指示信息 - 表示请求已接收, 继续处理
2xx: 成功 - 表示请求已被成功接收, 理解, 接受
3xx: 重定向 - 要完成请求必须进行更进一步的操作
4xx: 客户端错误 - 请求有语法错误或请求无法实现
5xx: 服务器端错误 - 服务器未能实现合法的请求
常见状态代码, 状态描述, 说明:
200
: OK - 客户端请求成功
400
: Bad Request - 客户端请求有语法错误, 不能被服务器所理解
401
: Unauthorized - 请求未经授权, 这个状态代码必须和 WWW-Authenticate 报头域一起使用
403
: Forbidden - 服务器收到请求, 但是拒绝提供服务
404
: Not Found - 请求资源不存在, eg: 输入了错误的 URL
500
: Internal Server Error - 服务器发生不可预期的错误
503
: Server Unavailable - 服务器当前不能处理客户端的请求, 一段时间后, 可能恢复正常
HTTP 响应状态码说明
| StatusCode | StatusCode 语义 | 中文描述 |
|---|---|---|
| 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 Larg | 请求的 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 协议的版本，无法完成处理 |
HTTP 响应报文
HTTP 协议详解
HTTP 的五大特点
支持客户 / 服务器模式.
简单快速: 客户向服务器请求服务时, 只需传送请求方法和路径. 请求方法常用的有 GET,HEAD,POST. 每种方法规定了客户与服务器联系的类型不同. 由于 HTTP 协议简单, 使得 HTTP 服务器的程序规模小, 因而通信速度很快.
灵活: HTTP 允许传输任意类型的数据对象. 正在传输的类型由 Content-Type 加以标记.
无连接: 无连接的含义是限制每次连接只处理一个请求. 服务器处理完客户的请求, 并收到客户的应答后, 即断开连接. 采用这种方式可以节省传输时间. 早期这么做的原因是请求资源少, 追求快. 后来通过
Connection: Keep-Alive
实现长连接
无状态: HTTP 协议是无状态协议. 无状态是指协议对于事务处理没有记忆能力. 缺少状态意味着如果后续处理需要前面的信息, 则它必须重传, 这样可能导致每次连接传送的数据量增大. 另一方面, 在服务器不需要先前信息时它的应答就较快.
非持久连接和持久连接
在实际的应用中, 客户端往往会发出一系列请求, 接着服务器端对每个请求进行响应. 对于这些请求 | 响应, 如果每次都经过一个单独的 TCP 连接发送, 称为非持久连接. 反之, 如果每次都经过相同的 TCP 连接进行发送, 称为持久连接.
非持久连接在每次请求 | 响应之后都要断开连接, 下次再建立新的 TCP 连接, 这样就造成了大量的通信开销. 例如前面提到的往返时间(RTT) 就是在建立 TCP 连接的过程中的代价.
非持久连接给服务器带来了沉重的负担, 每台服务器可能同时面对数以百计甚至更多的请求. 持久连接就是为了解决这些问题, 其特点是一直保持 TCP 连接状态, 直到遇到明确的中断要求之后再中断连接. 持久连接减少了通信开销, 节省了通信量.
HTTP 和 HTTPS
HTTP 的不足
通信使用明文(不加密), 内容可能会被窃听
不验证通信方的身份, 因此有可能遭遇伪装
无法证明报文的完整性, 所以有可能已遭篡改
HTTPS 介绍
HTTP 协议中没有加密机制, 但可以通 过和 SSL(Secure Socket Layer, 安全套接层 )或 TLS(Transport Layer Security, 安全层传输协议)的组合使用, 加密 HTTP 的通信内容. 属于通信加密, 即在整个通信线路中加密.
HTTP + 加密 + 认证 + 完整性保护 = HTTPS(HTTP Secure )
HTTPS 采用共享密钥加密 (对称) 和公开密钥加密 (非对称) 两者并用的混合加密机制. 若密钥能够实现安全交换, 那么有可能会考虑仅使用公开密钥加密来通信. 但是公开密钥加密与共享密钥加密相比, 其处理速度要慢.
所以应充分利用两者各自的优势, 将多种方法组合起来用于通信. 在交换密钥阶段使用公开密钥加密方式, 之后的建立通信交换报文阶段 则使用共享密钥加密方式.
HTTPS 握手过程的简单描述如下:
浏览器将自己支持的一套加密规则发送给网站.
服务器获得浏览器公钥
网站从中选出一组加密算法与 HASH 算法, 并将自己的身份信息以证书的形式发回给浏览器. 证书里面包含了网站地址, 加密公钥, 以及证书的颁发机构等信息.
浏览器获得服务器公钥
获得网站证书之后浏览器要做以下工作:
(a). 验证证书的合法性(颁发证书的机构是否合法, 证书中包含的网站地址是否与正在访问的地址一致等), 如果证书受信任, 则浏览器栏里面会显示一个小锁头, 否则会给出证书不受信的提示.
(b). 如果证书受信任, 或者是用户接受了不受信的证书, 浏览器会生成一串随机数的密码(接下来通信的密钥), 并用证书中提供的公钥加密(共享密钥加密).
(c) 使用约定好的 HASH 计算握手消息, 并使用生成的随机数对消息进行加密, 最后将之前生成的所有信息发送给网站.
浏览器验证 -> 随机密码
服务器的公钥加密 -> 通信的密钥
通信的密钥 -> 服务器
网站接收浏览器发来的数据之后要做以下的操作:
(a). 使用自己的私钥将信息解密取出密码, 使用密码解密浏览器发来的握手消息, 并验证 HASH 是否与浏览器发来的一致.
(b). 使用密码加密一段握手消息, 发送给浏览器.
服务器用自己的私钥解出随机密码 -> 用密码解密握手消息(共享密钥通信)-> 验证 HASH 与浏览器是否一致(验证浏览器)
HTTPS 的不足
加密解密过程复杂, 导致访问速度慢
加密需要认向证机构付费
整个页面的请求都要使用 HTTPS
来源: https://juejin.im/post/5ba65296f265da0ac8493503