HTTP和HTTPS是面试常问的问题，内容比较多而且复杂，HTTPS里面的细节很多，本文只是把主要的东西写出来，想要弄懂HTTPS还是要多看几篇博文，自己动手走一遍把各个攻击的case搞明白。
1 HTTP
1.1 HTTP基本概念
HTTP 是超⽂本传输协议，也就是HyperText Transfer Protocol。
1.1.1 HTTP常见状态码
| 状态码 | 含义 | 常见状态码 |
|---|---|---|
| 1xx |
1xx 类状态码属于提示信息，是协议处理中的⼀种中间状态，实际⽤到的⽐较少。 |
|
| 2xx |
2xx 类状态码表示服务器成功处理了客户端的请求 |
200、204、206 |
| 3xx |
3xx 类状态码表示客户端请求的资源发送了变动，需要客户端⽤新的 URL 重新发送请求获取资源，也就是重定向。 |
301、302、304 |
| 4xx |
4xx 类状态码表示客户端发送的报⽂有误，服务器⽆法处理，也就是错误码的含义。 |
400、403、404 |
| 5xx |
5xx 类状态码表示客户端请求报⽂正确，但是服务器处理时内部发⽣了错误，属于服务器端的错误码。 |
500、501、502 |
1.1.2 HTTP常见字段
Host 字段：客户端发送请求时，⽤来指定服务器的域名。 Host: www.baidu.com
Content-Length 字段 ：服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。 Content-Length: 1000
Connection 字段 ：Connection 字段最常用于客户端要求服务器使⽤ TCP 持久连接，以便其他请求复⽤。 HTTP/1.1 版本的默认连接都是持久连接，但为了兼容⽼版本的 HTTP，需要指定 Connection ⾸部字段的值为Keep-Alive 。
Content-Type 字段 ：Content-Type 字段⽤于服务器回应时，告诉客户端，本次数据是什么格式 。Content-Type: text/html; charset=utf-8
Content-Encoding 字段 ：Content-Encoding 字段说明数据的压缩⽅法。表示服务器返回的数据使用了什么压缩格式 。客户端在请求时，⽤ Accept-Encoding 字段说明自己可以接受哪些压缩⽅法。 Accept-Encoding: gzip, deflate
下图为访问百度的返回字段
1.1.3 HTTP常见方法
| 方法 | 说明 |
|---|---|
| GET | GET方法用于使用给定的URI从给定服务器中检索信息，即从指定资源中请求数据。使用GET方法的请求应该只是检索数据，并且不应对数据产生其他影响。 |
| POST | POST方法用于将数据发送到服务器以创建或更新资源，它向 URI 指定的资源提交数据，数据就放在报⽂的 body 里。 |
| HEAD | HEAD方法与GET方法相同，但没有响应体，仅传输状态行和标题部分。这对于恢复相应头部编写的元数据非常有用，而无需传输整个内容。 |
| PUT | PUT方法用于将数据发送到服务器以创建或更新资源，它可以用上传的内容替换目标资源中的所有当前内容。 |
| DELETE | DELETE方法用来删除指定的资源，它会删除URI给出的目标资源的所有当前内容。 |
| CONNECT | CONNECT方法用来建立到给定URI标识的服务器的隧道；它通过简单的TCP / IP隧道更改请求连接，通常实使用解码的HTTP代理来进行SSL编码的通信。 |
| OPTIONS | OPTIONS方法用来描述了目标资源的通信选项，会返回服务器支持预定义URL的HTTP策略。 |
| TRACE | TRACE方法用于沿着目标资源的路径执行消息环回测试；它回应收到的请求，以便客户可以看到中间服务器进行了哪些（假设任何）进度或增量。 |
1.2 HTTP特性
优点
简单
HTTP 基本的报⽂格式就是 header + body ，头部信息也是 key-value 简单⽂本的形式， 易于理解，降低了学习和使⽤的⻔槛。-
灵活和易于扩展
HTTP协议⾥的各类请求⽅法、 URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发⼈员⾃定义和扩充。同时 HTTP 由于是⼯作在应⽤层（ OSI 第七层），则它下层可以随意变化。
HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层， HTTP/3 甚⾄把 TCP 层换成了基于 UDP 的QUIC。
应用广泛和跨平台
互联⽹发展⾄今， HTTP 的应⽤范围⾮常的⼴泛，从台式机的浏览器到⼿机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡， HTTP 的应⽤⽚地开花，同时天然具有跨平台的优越性。
缺点
-
无状态
⽆状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存⽤来对外提供服务。
⽆状态的坏处，既然服务器没有记忆能⼒，它在完成有关联性的操作时会⾮常麻烦。
解决方案Cookie：Cookie通过在请求和响应报⽂中写⼊ Cookie 信息来控制客户端的状态。在客户端第⼀次请求后，服务器会下发⼀个装有客户信息的「⼩贴纸」，后续客户端请求服务器的时候，带上「⼩贴纸」，服务器就能认得了了，
明文传输、不安全
1.3 HTTP版本演变
1.3.1 HTTP/1.0 → HTTP/1.1
性能提升：
- 使⽤ TCP ⻓连接的⽅式改善了 HTTP/1.0 短连接造成的性能开销。
- ⽀持管道（pipeline）网络传输，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以减少整体的响应时间。
HTTP/1.1 的性能瓶颈：
- 请求 / 响应头部未经压缩就发送，⾸部信息越多延迟越⼤。只能压缩
Body的部分； - 发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端⼀直请求不到数据，也就是队头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应。
1.3.2 HTTP/1.1 → HTTP/2
HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
性能提升：
-
头部压缩：HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会帮你消除重复的部分。
HPACK算法：在客户端和服务器同时维护⼀张头信息表，所有字段都会存⼊这个表，⽣成⼀个索引号，以后就不发送同样字段了，只发送索引号，这样就提⾼速度了。 -
二进制格式：HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）： 头信息帧和数据帧。
收到报⽂后，⽆需再将明⽂的报⽂转成二进制，⽽是直接解析二进制报⽂，这增加了数据传输的效率
-
数据流：HTTP/2 的数据包不是按顺序发送的，同⼀个连接⾥⾯连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。
每个请求或回应的所有数据包，称为⼀个数据流（ Stream ）。每个数据流都标记着⼀个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数。
客户端还可以指定数据流的优先级。优先级⾼的请求，服务器就先响应该请求。
多路复用：HTTP/2 是可以在
⼀个连接中并发多个请求或回应，⽽不用按照顺序⼀⼀对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，⼤幅度提⾼了连接的利用率。服务器推送：HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
1.3.3 HTTP/2 → HTTP/3
HTTP/2 主要的问题在于，多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的重传机制，这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
- HTTP/1.1 中的管道（ pipeline）传输中如果有⼀个请求阻塞了，那么队列后请求也统统被阻塞住了。
- HTTP/2 多个请求复⽤⼀个TCP连接，⼀旦发生丢包，就会阻塞住所有的 HTTP 请求。
这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP。
UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的⼀个丢包全部重传问题。
UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。
- QUIC 有⾃⼰的⼀套机制可以保证传输的可靠性的。
当某个流发生丢包时，只会阻塞这个流， 其他流不会受到影响。 - TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack 。
- HTTPS 要建立⼀个连接，要花费 6 次交互，先是建⽴三次握⼿，然后是 TLS/1.3 的三次握⼿。 QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数
1.3.4 HTTP各版本层次图
2 HTTPS
2.1 HTTP 与 HTTPS 的区别
- HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全风险的问题。
HTTPS 则解决 HTTP 不安全的缺陷，在TCP 和 HTTP 网络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。 - HTTP 连接建⽴相对简单， TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。
而HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。 - HTTP 的端口号是 80， HTTPS 的端口号是 443。
- HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。
2.2 HTTPS安全性实现
混合加密
HTTPS 采⽤的是对称加密和⾮对称加密结合的「混合加密」⽅式：
- 在通信建⽴前采用⾮对称加密的⽅式交换「会话秘钥」，后续就不再使⽤⾮对称加密。
- 在通信过程中全部使用对称加密的「会话秘钥」的⽅式加密明⽂数据。
采⽤「混合加密」的⽅式的原因：
- 对称加密只使⽤⼀个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
- 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发⽽私钥保密，解决了密钥交换问题但速度慢。
摘要算法
摘要算法⽤来实现完整性，能够为数据⽣成独⼀⽆⼆的「指纹」，⽤于校验数据的完整性，解决了篡改的⻛险。
客户端在发送明⽂之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」⼀同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过⽐较客户端携带的「指纹」和当前算出的「指纹」做⽐较，若「指纹」相同，说明数据是完整的。
数字证书
客户端先向服务器端索要公钥，然后⽤公钥加密信息，服务器收到密文后，⽤⾃⼰的私钥解密。这就存在些问题，如何保证公钥不被篡改和信任度？
所以这⾥就需要借助第三⽅权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。
通过数字证书的⽅式保证服务器公钥的身份，解决冒充的⻛险 。
证书签名和验证过程：
公钥加密私钥解密，私钥加密公钥解密。
CA公钥已经事先置入到了浏览器或者操作系统里。
| 步骤 | 服务端 | CA | 客户端 |
|---|---|---|---|
| 1 | 服务器把自己的公钥注册到CA
|
||
| 2 |
CA用自己的私钥将服务器的公钥和域名的其他信息加密成证书并颁发给服务器 |
||
| 3 | 客户端发起网络请求 | ||
| 4 | 客户端拿到服务器的数字证书后使用CA公钥解密，确认服务器数字证书的真实性 |
||
| 5 | 从数字证书获取服务器公钥后，使用服务器公钥对报文加密传输 |
两种情况：
如果数字证书被其他人篡改，
由于加密数据不是CA私钥加密而来，所以无法解密成功。-
如果攻击者知道A.com使用的是某家CA机构的证书，那么他也去这家CA机构申请一个合法的证书，然后在浏览器请求A.com时对返回的加密证书数据进行替换。
由于攻击者申请的证书也是由正规CA机构制作的，因此这段加密数据可以成功被解密。但CA机构在制作的证书时除了网站的公钥外，还要包含许多其他数据，用来辅助进行校验，比如说网站的域名。如果域名对不上依然检验失败。
2.3 HTTPS建立连接过程
