Http 协议基础

Question

http 协议有什么特点？

简单快速，灵活、无连接、无状态

每一个资源对应一个 URI，请求只要输入资源地址 uri 就可以了；
在每一个 http 头部协议中都有一个数据类型，通过一个 http 协议就可以完成不同类型数据的传输；
链接一次就会断开；
每一次链接不会记住链接状态的，服务器不区分两次链接的身份；

http 报文组成部分？

请求报文

请求报文：请求行、请求头、空行、请求体
请求行：HTTP 请求方法、页面地址、协议版本等
请求头：key,value 值，告诉服务端我要什么内容、要什么数据类型
空行：分割请求头和请求体的，遇到空行，服务器就知道，请求头结束了，接下来是请求体了
请求体：就是给服务端的一些入参数据；
我所了解的请求体有两种格式，Content-Type: application/x-www-form-urlencoded 和 payload 和 json

相应报文

状态行、响应头、空行、响应体

状态行：协议版本 状态码 状态
其他的一样的

通信协议？

建立在 TCP 之上的

常见请求头数据和相应头数据（以 github 某请求为例子）

Request Headers

Accept: */*                         // 告诉服务器，客户机支持的数据类型
Accept-Encoding: gzip, deflate, br  // 告诉服务器，客户机支持的数据压缩格式
Accept-Language: zh-CN,zh;q=0.9     // 编码格式
Connection: keep-alive              // 是否支持场链接
Content-Length: 12308               // 获取文件的总大小
Content-Type: application/json      // 返回数据格式
Host: api.github.com
Origin: https://github.com
Referer: https://github.com/yanlele/node-index/blob/master/book/05%E3%80%81%E5%9F%BA%E7%A1%80%E7%9F%A5%E8%AF%86%E7%82%B9%E4%B8%93%E9%A2%98/01_01%E3%80%81%E5%9F%BA%E7%A1%80%E7%9F%A5%E8%AF%86%E9%83%A8%E5%88%861-10.md
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Response Headers:

Access-Control-Allow-Origin: *                          // 允许跨域策略
Access-Control-Expose-Headers: ETag, Link, Location...  // 列出了哪些首部可以作为响应的一部分暴露给外部
Cache-Control: no-cache                                 // 缓存失效时间
Content-Length: 5                                       // 获取文件的总大小
Content-Security-Policy: default-src 'none'             // 配置内容安全策略涉
Content-Type: application/json; charset=utf-8           // 返回数据格式
Date: Wed, 21 Nov 2018 09:55:47 GMT
Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
Server: GitHub.com
Status: 200 OK                                          // 状态码
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: deny
X-GitHub-Media-Type: github.v3; format=json
X-GitHub-Request-Id: A3D4:2AE5:13372C:19E45C:5BF52BA3
X-XSS-Protection: 1; mode=block

HTTP 方法相关？

GET 请求资源、post 传输资源、put 更新资源、delete 删除资源、head 获取报文首部

get 和 post 区别

• get 只能 url 编码、post 支持多种编码方式
• get 在传输参数有长度限制的，而 post 是没有长度限制的
• get 通过 url 传递，post 放在 request body 中
• get 不安全，post 是一种安全的传输协议方式
• get 会把参数保存到浏览器记录里，而 post 中的参数不会保存
• get 会被浏览器缓存

http 常见状态码有哪些？

1.XX:指示信息-表示请求已经接受，继续处理

2.XX:成功
200：请求成功
206：客户端发送一个 range 头的 get 请求，服务器完成了他

3.XX：重定向
301：请求的页面转移到新的 url;
302:临时转移到新的 url
304：客户端缓存的文件并发出了一个条件性的请求，服务器告诉客户，原来缓冲的文档还可以继续使用

4.XX：客户端错误
400：语法错误
401：请求未授权
403：请求禁止访问
404：请求资源不存在

5.XX：服务端错误
500：服务器发生不可预期的错误
503：服务器请求未完成

什么是 HTTP 持久链接？

http 采用的是 "请求-应答" 模式
当使用 keep-Alive 模式（又称持久链接、链接重用）时、http1.1 版本才支持的
Connection: keep-alive

什么是管线化？

持久链接下：链接传递消息类似于请求 1->响应 1->请求 2->响应 2->请求 3->响应 3
管线化：请求 1-》请求 2-》请求 3-》响应 1-》响应 2-》响应 3
需要通过持久链接完成，所以仅 HTTP1.1 版本支持
只有 get 和 head 请求支持管线化，post 请求是有所限制的

深入研究 HTTPS

Https 涉及到的主体

1、客户端。通常是浏览器(Chrome、IE、FireFox 等)，也可以自己编写的各种语言的客户端程序。
2、服务端。一般指支持 Https 的网站，比如 github、支付宝。
3、CA(Certificate Authorities)机构。Https 证书签发和管理机构，比如 Symantec、Comodo、GoDaddy、GlobalSign。

图示这三个角色：

发明 Https 的动机

认证正在访问的网站。 什么叫认证网站？比如你正在访问支付宝，怎样确定你正在访问的是阿里巴巴提供的支付宝而不是假冒伪劣的钓鱼网站呢？

保证所传输数据的私密性和完整性。 众所周知，Http 是明文传输的，所以处在同一网络中的其它用户可以通过网络抓包来窃取和篡改数据包的内容，甚至运营商或者 wifi 提供者，有可能会篡改 http 报文，添加广告等信息以达到盈利的目的。

Https 的工作流程

可以看到工作流程，基本分为三个阶段：

1、 认证服务器。 浏览器内置一个受信任的 CA 机构列表，并保存了这些 CA 机构的证书。

第一阶段服务器会提供经 CA 机构认证颁发的服务器证书，如果认证该服务器证书的 CA 机构，存在于浏览器的受信任 CA 机构列表中，并且服务器证书中的信息与当前正在访问的网站（域名等）一致，那么浏览器就认为服务端是可信的，并从服务器证书中取得服务器公钥，用于后续流程。

否则，浏览器将提示用户，根据用户的选择，决定是否继续。

当然，我们可以管理这个受信任 CA 机构列表，添加我们想要信任的 CA 机构，或者移除我们不信任的 CA 机构。

2、 协商会话密钥。 客户端在认证完服务器，获得服务器的公钥之后，利用该公钥与服务器进行加密通信，协商出两个会话密钥，分别是用于加密客户端往服务端发送数据的客户端会话密钥，用于加密服务端往客户端发送数据的服务端会话密钥。

在已有服务器公钥，可以加密通讯的前提下，还要协商两个对称密钥的原因，是因为非对称加密相对复杂度更高，在数据传输过程中，使用对称加密，可以节省计算资源。

另外，会话密钥是随机生成，每次协商都会有不一样的结果，所以安全性也比较高。

3、 加密通讯。 **此时客户端服务器双方都有了本次通讯的会话密钥，之后传输的所有 Http 数据，都通过会话密钥加密。

这样网路上的其它用户，将很难窃取和篡改客户端和服务端之间传输的数据，从而保证了数据的私密性和完整性。

总结

说是讨论 Https，事实上 Https 就是 Http 跑在 SSL 或者 TLS 上，所以本文讨论的原理和流程其实是 SSL 和 TLS 的流程，对于其它使用 SSL 或者 TLS 的应用层协议，本文内容一样有效。

本文只讨论了客户端验证服务端，服务端也可以给客户端颁发证书并验证客户端，做双向验证，但应用没有那么广泛，原理类似。由于采用了加密通讯，Https 无疑要比 Http 更耗费服务器资源，这也是很多公司明明支持 Https 却默认提供 Http 的原因。