HTTPS
HTTP + 加密 + 认证 + 完整性保护 = HTTPS
- 基于HTTP协议，通过SSL或TLS协议提供加密处理数据、验证对方身份以及数据完整性保护
- 在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版
特点
通过抓包获取到的数据不是明文传输的
- 内容加密：采用混合加密技术，中间者无法直接查看明文内容
- 验证身份：通过证书认证客户端访问的是自己的服务器
- 保护数据完整性：防止传输的内容被中间人冒充或者篡改
缺点
- 性能损耗
- 增加延时
- 消耗较多的CPU资源
优化方案
- CDN
- 会话缓存
TLS/SSL
TLS是传输层加密协议，前身是SSL协议
TLS 协议位于传输层之上，应用层之下
HTTPS 还是通过了 HTTP 来传输信息，但是信息通过 TLS 协议进行了加密
功能实现
利用非对称加密实现身份认证和密钥协商，采用对称加密算法协商的密钥对数据加密，
基于散列函数验证信息的完整性
- 散列函数 Hash:MD5,SHA,SHA256---完成校验
- 对称加密 1-1:AES,DES,RC4---信息加密
- 非对称加密 1-N:RSA,ECC,DH---身份验证秘钥协商
对称加密
对称加密就是两边拥有相同的秘钥，两边都知道如何将密文加密解密。
这种加密方式固然很好，但是问题就在于如何让双方知道秘钥。因为传输数据都是走的网络，如果将秘钥通过网络的方式传递的话，一旦秘钥被截获就没有加密的意义的。
非对称加密
有公钥私钥之分，公钥所有人都可以知道，可以将数据用公钥加密，但是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道。
这种加密方式就可以完美解决对称加密存在的问题。假设现在两端需要使用对称加密，那么在这之前，可以先使用非对称加密交换秘钥。
简单流程如下：首先服务端将公钥公布出去，那么客户端也就知道公钥了。接下来客户端创建一个秘钥，然后通过公钥加密并发送给服务端，服务端接收到密文以后通过私钥解密出正确的秘钥，这时候两端就都知道秘钥是什么了。
TLS1.2握手过程
- 客户端发出请求:
- 一个随机值(用于生成对话秘钥)
- 支持的协议
- 支持加密方式
- 支持压缩的方法
- 服务端收到客户端的请求，向客户端发出回应:
- 一个随机值(用于生成对话秘钥)
- 确定使用的协议
- 确定使用的加密方式
- 发送自己的证书（如果需要验证客户端证书需要说明）
- 客户端收到服务端的证书并验证是否有效，如果证书没问题,向服务端发送一个请求:
- 生成一个随机值(用证书公钥加密)
- 编码改变通知(随后的信息将使用双方商定的加密方法和秘钥发送)
- 客户端握手结束通知(前面发送的所有内容的hash值，用来提供给服务端校验)
- 服务端最后响应
- 服务器收到客户端的第三个随机数之后(用私钥解密)结合之前的两个明文随机数，计算生成本次会话所用的"会话密钥"
- 编码改变通知(随后的信息都将用双方商定的加密方法和密钥发送)
- 服务器握手结束通知(前面发送的所有内容的hash值，用来提供给客户端校验)
通过以上步骤可知，在 TLS 握手阶段，两端使用非对称加密的方式来通信，实现身份验证并协商对称加密使用的密钥,但是因为非对称加密损耗的性能比对称加密大，所以在正式传输数据时，两端使用对称加密的方式通信。不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取
TLS1.3
TLS1.3 中废除了非常多的加密算法,如果私钥泄露,那么中间人可以解密所有密文
TLS1.3 在 TLS1.2 的基础上废除了大量的算法，提升了安全性。同时利用会话复用节省了重新生成密钥的时间，利用 PSK 做到了0-RTT连接
HTTP2
HTTP/2 相比于 HTTP/1，大幅度提高了网页的性能
在 HTTP/1 中,浏览器限制了同一个域名下的请求数量（Chrome 下一般是限制六个连接）
当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求
特点
- HTTP/2 中引入了多路复用的技术，这个技术可以只通过一个 TCP 连接就可以传输所有的请求数据。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也间接更容易实现全速传输
- 在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP/2 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。
多路复用
在 HTTP/2 中，有两个非常重要的概念，分别是:
- 帧（frame） 代表最小的数据单位，每个帧会标识出该帧属于哪个流
- 流（stream） 是多个帧组成的数据流
多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。
通过这个技术，多个请求共享一个TCP连接，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能
Header 压缩
在 HTTP/1 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。
在 HTTP /2 中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值
服务端 Push
在 HTTP/2 中，服务端可以在客户端某个请求后，主动推送其他资源。
可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样在使用的时候就可以相对减少一点延迟时间。
设置请求优先级
- 可在新建的流所传递HEADERS帧中包含优先级priority属性
- 可单独通过PRIORITY帧专门设置流的优先级属性
使用前置条件
- 支持HTTP2的客户端与服务端
- 域名必须支持HTPPS协议（基于TLS/1.2或以上版本的加密连接）
- 服务器的openssl版本必须大于1.0.2
可通过Nginx搭建HTTP2服务器
HTTP3
HTTP/2 使用了多路复用
一般来说同一域名下只需要使用一个 TCP 连接。当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1 了
- 出现丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了
- 对于 HTTP/1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据
基于这个原因，Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上
QUIC
QUIC 基于 UDP，在原本的基础上新增了很多功能
- 多路复用
- 0-RTT
- 使用TLS1.3加密
- 流量控制
- 有序交付
- 重传
- 。。。
一种全新的基于UDP的web开发协议。可以用一个公式大致概括：
TCP + TLS + HTTP2 = UDP + QUIC + HTTP2’s API
QUIC协议虽然是基于UDP，但它不但具有TCP的可靠性、拥塞控制、流量控制等，且在TCP协议的基础上做了一些改进，比如避免了队首阻塞；
另外，QUIC协议具有TLS的安全传输特性，实现了TLS的保密功能，同时又使用更少的RTT建立安全的会话。
多路复用
无队头阻塞的多路复用
QUIC 原生实现了这个功能，并且传输的单个数据流可以保证有序交付且不会影响其他的数据流，这样的技术就解决了之前 TCP 存在的问题
QUIC 在移动端的表现也会比 TCP 好:
- 因为 TCP 是基于 IP 和端口去识别连接的，这种方式在多变的移动端网络环境下是很脆弱的
- QUIC 是通过 ID 的方式去识别一个连接，不管你网络环境如何变化，只要 ID 不变，就能迅速重连上
0-RTT
与其他协议比较
- TCP建立链接需要三次握手，每次连接需要额外的RTT
- HTTPS加入了TLS还需要额外的RTT
0-RTT情况
通过使用类似 TCP 快速打开的技术，缓存当前会话的上下文，在下次恢复会话的时候，只需要将之前的缓存传递给服务端验证通过就可以进行传输了
1-RTT情况
新的QUIC连接至少需要1 RTT才能完成握手
纠错机制
假如说这次我要发送三个包，那么协议会算出这三个包的异或值并单独发出一个校验包，也就是总共发出了四个包
当出现其中的非校验包丢包的情况时，可以通过另外三个包计算出丢失的数据包的内容。
当然这种技术只能使用在丢失一个包的情况下，如果出现丢失多个包就不能使用纠错机制了，只能使用重传的方式了
结构对比图
总结HTTP/2|3
- HTTP/2 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能，但是还是存在着一定的问题的
- QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议，但目前兼容性并不好
HTTP相关问题
1.POST和GET区别
使用场景上区分
- GET多用于无副作用，幂等
- POST多用于有副作用，不冪等
技术上
- GET会缓存，POST不会缓存
- GET请求参数会出现在url中，post相对安全一点
- URL有长度限制，会影响GET请求（浏览器规定）
- POST支持更多的编码类型，且不对数据做限制
- GET只能进行URL编码，只能接受ASCII字符
2.HTTP与HTTPS区别
- 安全：HTTP明文传输数据，HTTPS是在HTTP上建立SSL/TLS加密层，并对传输数据进行加密，更加安全
- 端口：http使用80端口，https使用443
- 速度：HTTP页面响应速度更快
- HTTP只需建立TCP连接，发送3个包
- HTTPS还需要经历TLS握手9个包需要，一共12个
3.HTTP1.1 如何解决 HTTP 的队头阻塞问题？
- 域名分片：使用多个指向同一服务器的二级域名
- 并发连接：也就是同时对一个域名发起多个长连接，用数量来解决质量的问题
- 浏览器一般会有限制
4.如果响应头Content-Length=0那么是发出来被截取了还是没发出来
结论：发出来被截取了
- Content-Length比实际的长度大, 服务端/客户端读取到消息结尾后, 会等待下一个字节,无响应直到超时
- Content-Length < 实际长度:首次请求的消息会被截取
- Content-Length如果存在且生效, 必须是正确的, 否则会发生异常
- 如果报文中包含Transfer-Encoding: chunked首部, 那么Content-Length将被忽略.
相关链接
希望各位路过大佬能指点一二
