HTTP总结
1 请求、响应格式
1.1 请求格式
1.1.1查看方式
浏览器：F12->“网络”->“全部”
1.1.2 请求方法：
- GET
基于“URL”地址问号传参；一般用于向服务器获取资源，例如查询数据库的数据等；成功返回200 - POST
基于“请求”主体把消息发送给服务器；一般用于请求新增或修改资源，例如提交表单，新增用户等；先发送header，服务器响应100，再发送data，成功响应201 - PUT
修改资源 - DELETE
删除某个资源
1.1.3 GET、POST区别
- get重点在从服务器上获取资源；post重点在向服务器发送数据；
- get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用"?"连接，多个请求数据间用"&"连接，这个过程用户是可见的，不安全；post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的，安全性更高；
- Get传输的数据量小，因为受URL长度限制，但效率较高；Post可以传输大量数据，所以上传文件时只能用Post方式；
1.2 响应格式
2.1.1 状态码
- 1xx：指示信息--表示请求已接收，继续处理
- 2xx：成功--表示请求已被成功接收、理解、接受
- 200：请求被正常处理
- 204：请求被受理但没有资源可以返回
- 3xx：重定向--要完成请求必须进行更进一步的操作
- 301：永久性重定向，说明请求的资源已经被永久移动到了由 Location 头部指定的 url 上，是固定的不会再改变，搜索引擎会根据该响应修正。
- 302：临时重定向，表明请求的资源被 暂时 移动到了由 Location 头部指定的 URL 上。浏览器会重定向到这个 URL， 但是搜索引擎不会对该资源的链接进行更新。302 跳转有网站劫持的风险
- 4xx：客户端错误--请求有语法错误或请求无法实现
- 400：请求报文语法有误，服务器无法识别
- 403：请求的对应资源禁止被访问
- 404：服务器无法找到对应资源
- 5xx：服务器端错误--服务器未能实现合法的请求
- 500：服务器内部错误
- 503：服务器正忙
2 HTTP请求响应的流程
- 域名解析
- 发起TCP的3次握手
- 建立TCP连接后发起http请求
- 服务器响应http请求，浏览器得到html代码
- 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）
- 浏览器对页面进行渲染呈现给用户
3 HTTPS
3.1 HTTP 与 HTTPS 有哪些区别？
- 安全性: HTTP 明文传输，不对数据进行加密安全性较差。HTTPS (HTTP + SSL / TLS)的数据传输过程是加密的，安全性较好。
- 在相同网络环境中，HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。因为加了一层安全层，建立连接的过程更复杂，也要交换更多的数据，难免影响速度。
- HTTP 的端⼝号是 80，HTTPS 的端⼝号是 443。
3.2 对称加密和非对称加密结合的「混合加密」方式
可以参考：https://segmentfault.com/a/1190000021494676
HTTPS 的整个通信过程可以分为两大阶段：证书验证和数据传输阶段，数据传输阶段又可以分为非对称加密和对称加密两个阶段。
- 客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口，类似于 HTTP 的80端口)。
- 采用 HTTPS 协议的服务器必须要有一套数字 CA (Certification Authority)证书
- 服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息
- 客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码 KEY，并使用公钥A将其加密。
- 客户端把加密后的随机码 KEY 发送给服务器，作为后面对称加密的密钥。
- 服务器在收到随机码 KEY 之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
- 服务器使用密钥 (随机码 KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。
- 双方使用对称加密愉快地传输所有数据。
3..3 为什么使用混合加密？
- 对称加密：
- 优点：算法公开、计算量小、加密速度快、加密效率高，适合加密比较大的数据。
- 缺点：
- 交易双方需要使用相同的密钥，也就无法避免密钥的传输，而密钥在传输过程中无法保证不被截获，因此对称加密的安全性得不到保证。
- 每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信双方所拥有的钥匙数量急剧增长，密钥管理成为双方的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。
- 非对称加密
顾名思义，就是加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公钥对外公开；得到该公钥的乙方使用公钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的私钥对加密后的信息进行解密。
4 HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3
4.1 1.0->1.1
- 连接方式 : HTTP 1.0 为短连接，HTTP 1.1 支持长连接。
- 状态响应码 : HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种
- 带宽优化及网络连接的使用 :HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分
4.2 1.1->2
HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
- 头部压缩
HTTP/2 会压缩头（Header），如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。 - 二进制格式
HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式。 - 数据流
HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。每个请求或回应的所有数据包，称为一个数据流（Stream）。 - 多路复用
HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。
4.3 2->3
HTTP/2 主要的问题在于：多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的一个丢包全部重传问题。UDP 是不可靠传输的，但基于 UDP 的QUIC 协议可以实现类似 TCP 的可靠性传输。
5 TLS4次握手
客户端 服务端
- 客户端给服务端随机数，告诉服务端我能用哪些加密手段 -->
- 服务端给客户端随机数，告诉客户端就用哪种加密手段 <--
- 服务端给客户证书，(里面包含了ca加密的服务端公钥) <--
- 客户端把会话秘钥生成 传给服务端 (服务端公钥加密 2个随机数+premaster 搭建会话秘钥) -->
6 HTTP优化方案
- 内容缓存：将经常用到的内容进行缓存起来，那么客户端就可以直接在内存中获取相应的数据了。
- 压缩：将文本数据进行压缩，减少带宽
- SSL加速（SSL Acceleration）：***L协议对HTTP协议进行加密，在通道内加密并加速
- TCP复用：TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上，而HTTP复用则是一个客户端的多个HTTP请求通过一个TCP连接进行处理。前者是负载均衡设备的独特功能；而后者是HTTP 1.1协议所支持的新功能，目前被大多数浏览器所支持。
- TCP缓冲：通过采用TCP缓冲技术，可以提高服务器端响应时间和处理效率，减少由于通信链路问题给服务器造成的连接负担。
7 参考
WebServer服务器项目可能会被问到的问题（二）
HTTP 请求方法和应用场景
通俗讲解【重定向】及其实践
HTTPS 详解一：附带最精美详尽的 HTTPS 原理图
HTTP/1.1、HTTP/2、HTTP/3的演变
HTTP 1.0 vs HTTP 1.1（应用层）
