http 与 https

2019年3月3日 190次阅读来源: HTTP

http 协议

http 是一个基于 TCP/IP 通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）

http 协议是无状态的，同一个客户端的这次请求和上次请求是没有对应关系，对 http 服务器来说，它并不知道这两个请求来自同一个客户端。为了解决这个问题， Web 程序引入了 Cookie 机制来维护状态.

统一资源标识符（URI）

HTTP 使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接

http://<host>:<port>/<path>?<query>#<frag>
https://<host>:<port>/<path>?<query>#<frag>
默认 HTTP 的端口号为 80，HTTPS 的端口号为 443。

HTTP 报文结构（请求报文和响应报文）

《http 与 https》

request line 请求行
request header 请求头
空行
body 内容: 请求数据

请求行

GET /index.js HTTP/1.1

请求方法：

GET 获取
POST 对资源的建立或修改、
HEAD ：类似 get，只不过响应只有报头，用于节省字节
PUT ：替换对应的资源
DELETE 删除
OPTIONS 嗅探请求预检，复杂请求中跨域的时候用到

请求头

host 域名
User-Agent : 它是一个特殊字符串头，使得服务器能够识别客户使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等。
Referer 告诉服务器我是从哪个页面链接过来的，服务器基于此可以获得一些信息用于处理
Accept-Encoding 浏览器发给服务器,声明浏览器支持的编码类型 eg: gzip(一般对纯文本内容可压缩到原大小的 40%)
cookie 保存一些信息
If-Modified-Since 从何时开始是否有修改
If-None-Match 检查 MD5 之类的 hash 值
Cache-Control: no-cache

响应头

Content-Type 响应的 HTTP 内容类型
Cache-Control max-age=3600
Expires 过期时间
Access-Control-Allow-Origin 设置允许的来源，验证请求的时候会带的 Origin
Access-Control-Allow-Headers 设置允许跨域携带的 headers
Access-Control-Allow-Methods 设置允许跨域方法
ETag 被请求变量的实体值,与 Web 资源关联的记号
last-modified 标记此文件在服务器端最后被修改的时间
status 状态码
Set-Cookie 设置客户端的 cookie

状态码

1xx 消息

2xx 请求成功

200 成功
206 （Partial Content）断点续传和多线程下载

3xx 重定向

301 请求的资源永久从不同的 URI 响应请求
302 请求的资源临时从不同的 URI 响应请求
304 如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码

4xx 客户端错误

400 Bad Request （语义有误或者请求参数出错）
401 Unauthorized 需要权限验证
403 Forbidden 服务器收到请求，但是拒绝提供服务
404 not found 请求失败，请求所希望得到的资源未被在服务器上发现

5xx 服务器错误

500 Internal Server Error 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理
503 Service Unavailable 由于临时的服务器维护或者过载，服务器当前无法处理请求
504 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器或者辅助服务器（例如 DNS）收到响应。

https

HTTPS = HTTP + SSL

加密方式

对称加密，比较有代表性的就是 AES 加密算法；双方密钥相同，加解密速度快

非对称加密，经常使用到的 RSA 加密算法就是非对称加密的；公钥和私钥

http 风险

被窃听
被篡改
被冒充

基本运行原理

客户端和服务端建立 SSL 握手 _客户端通过 CA 证书来确认服务端的身份_；
互相传递三个随机数，之后通过这随机数来生成一个密钥；
互相确认密钥，然后握手结束；
数据通讯开始，都使用同一个对话密钥来加解密；

基本运行原理（详细）

首先，客户端 A 访问服务器 B ，客户端 A 会生成一个随机数 1，把随机数 1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
服务器 B 知道这些信息后，确认一下双方的加密算法，生成一个随机数 2 以及一个公钥返回给客户端 A
客户端 A 生成一个随机数 3 ，然后用公钥加密随机数 3 并传输给服务端 B 。
服务端 B 接收到后利用私钥进行解密，得到随机数 3。
最后，客户端 A 和服务端 B 都有随机数 1、随机数 2、随机数 3，然后双方都利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密。
SSL 的握手部分结束，客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。

为啥需要 CA 证书

因为在第一步的时候，我们并不清楚服务器 B 是不是真的是服务器 B。所以需要一个我们信得过的机构来告诉我们。

基本运行原理（带 CA 证书）

首先，客户端 A 访问服务器 B ，客户端 A 会生成一个随机数 1，把随机数 1 、自己支持的 SSL 版本号以及加密算法等这些信息告诉服务器 B 。
服务器 B 知道这些信息后，确认一下双方的加密算法，然后也生成一个随机数 B ，并将随机数 B 和 CA 颁发给自己的证书一同返回给客户端 A 。
客户端 A 得到 CA 证书后，会去校验该 CA 证书的有效性。校验通过后，客户端生成一个随机数 3 ，然后用证书中的公钥加密随机数 3 并传输给服务端 B 。
服务端 B 加密后的随机数 3，利用私钥进行解密，得到随机数 3。
最后，客户端 A 和服务端 B 都有随机数 1、随机数 2、随机数 3，然后双方都利用这三个随机数生成一个对话密钥。之后传输内容就是利用对话密钥来进行加解密了。这时就是利用了对称加密，一般用的都是 AES 算法。
SSL 的握手部分结束，客户端 A 和服务器 B 开始使用相同的对话密钥进行数据通讯。

浏览器验证证书的合法性