HTTP 是超⽂本传输协议，也就是HyperText Transfer Protocol。HTTP是⼀个在计算机世界⾥专⻔在「两点」之间「传输」⽂字、图⽚、⾳频、视频等「超⽂本」数据的「约定和规范。
HTTP的底层是TCP/IP
1、HTTP状态码
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/100
1××：提示信息，表示请求已接受，正在处理中
200：最常见的成功状态码，除了HEAD请求外响应头都会有body数据
204：请求受理成功，但是没有资源可以返回，响应头没有body数据
206：应用于分块下载或断点续传的，表示响应的数据不是全部，而是其中的一部分。
301：永久重定向，资源不在了
302：临时的重定向，资源还在。301和302都会在响应头里加上Location字段，告诉浏览器要跳转的url
304：客户端发送了一个带条件的get请求，如果请求的资源没更新就返回304。用于缓存控制的，为了提高网站访问速度，服务器给访问过的某些页面设置了缓存机制。当客户端请求这些页面时，服务器将根据缓存的内容判断页面是否更新过，如果页面未更新过，它就会返回一个304状态码，这时客户端直接调用缓存的内容，而不必进行第二次调用及下载。304状态码在一定程度上起到了降低服务器带宽、提高网站访问速度及蜘蛛爬行效率的作用。
400：表示请求的报文有误，服务端无法识别
403：请求的资源被禁止访问
404：请求的资源在服务器上不存在或者没找到
405：表明服务器禁止了使用当前 HTTP 方法的请求。
500：服务器内部错误，较宽泛。
501：服务器不支持请求的方法，因此无法被处理。get、head是必须要被支持的
502：网关错误，表示网关或代理服务器从上游服务器（tomcat、php）接收的响应是无效的
503：表示服务器正忙，暂时无法响应
2、HTTP方法
http1.0：GET, POST 和 HEAD，http1.1新增：OPTIONS, PUT, DELETE, TRACE 和 CONNECT
| 请求方式 | 描述 |
|---|---|
| GET： | 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器 |
| POST： | 用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。 |
| PUT： | 传输文件，报文主体中包含文件内容，保存到对应URI位置。 |
| HEAD： | 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有 效。 |
| PATCH： | 客户端向服务器传送的数据取代指定的文档的内容(部分取代) |
| TRACE： | 回显客户端请求服务器的原始请求报文，用于"回环"诊断 |
| DELETE： | 删除文件，与PUT方法相反，删除对应URI位置的文件。 |
| OPTIONS： | 查询相应URI支持的HTTP方法。 |
3、HTTP缺点
无状态（可以使用cookie）、不安全：
明文通信、不验证双方的身份、无法确认报文的完整性（被篡改）
4、HTTP版本
http1.0
每次请求都要建立一次tcp链接（三次握手），而且是串行请求（接收到响应后才能发下一个请求），连接断开频繁，开销大。
http1.1
采用长连接方式，并且通过管道通信使得可以并行发送请求。但是服务器响应顺序还是按照请求的顺序来，这叫队头阻塞。除此之外，请求响应头部未压缩（指HEAD部分）、没有优先级控制，请求只能从客户端开始，服务端只能被动响应。
http/2
优化了http1.1性能，首先http2基于https，保证安全，性能方面：
1、首部压缩。如果同时发送多个请求，就会通过HPACK算法进行去重（客户端和服务端维护一张表，将字段存入并且生成索引号，之后发送只发索引号降低体积，从而提速）
2、二进制分帧。1.1的时候head和body都是文本格式传输，2.0将数据以二进制的形式传输，叫做帧。分为头信息帧和数据帧。
3、数据流。2.0的数据包不是按照顺序来的，可能一个连接的数据包来自不同的数据包。因此需要对不同的数据包进行编号，每个请求或者响应的数据包成为一个数据流Stream。每个数据流都有一个独一无二的编号，默认客户端发送的数据流编号为奇数。服务端发送的数据流编号为偶数。客户端还可以指定数据流的优先级，优先级高的请求，服务端优先响应。
4、多路复用。多个HTTP请求复用一个tcp连接。一个连接中可以并发多个请求和响应，无需等待，消除了队头阻塞。对于先后的AB请求，如果A比较耗时，可以先响应A处理好的部分，再将B响应，再将A剩下的响应回去。
5、服务器推送。服务单可以在客户端刚刚请求html的时候，就主动的把js，css，图片之类的资源推送给客户端。
http/3
改用基于udp的QUIC协议实现类似tcp的可靠传输。
当某个流发⽣丢包时，只会阻塞这个流，其他流不会受到影响。
TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack
HTTPS 要建⽴⼀个连接，要花费 6 次交互，先是建⽴三次握⼿，然后是 TLS/1.3 的三次握⼿。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。
5、HTTPS
https在http和tcp之间引入了TLS协议，TLS通过混合加密、校验机制、身份证书保证安全
TLS四次握手
以RSA密匙交换算法为例
1、第一次握手
客户端发送一个Client Hello，包含客户端使⽤的 TLS 版本号、⽀持的密码套件列表，以及⽣成的客户端随机数（Client Random）
2、第二次握手
当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否⽀持，和从密码套件列表中选择⼀个密码套件，以及⽣成服务端随机数（Server Random），接着返回一个Server Hello，包含确认使用的版本号、选择的密码套件、随机数。
（密码套件包括「密钥交换算法 + 对称加密算法 + 摘要算法」）
然后服务端为了证明⾃⼰的身份，会发送「Server Certificate」给客户端，这个消息⾥含有数字证书。
随后，服务端发了「Server Hello Done」消息，⽬的是告诉客户端，我已经把该给你的东⻄都给你了，本次打招呼完毕。
CA机构签发证书流程：获取持有者的公钥、⽤途、颁发者、有效时间等信息打成⼀个包，进行hash计算，得到hash值，再用自己的私匙对hash值进行加密，⽣成 Certificate Signature，也就是 CA 对证书做了签名，并将Certificate Signature添加在⽂件证书上，形成数字证书。
客户端校验证书流程：
客户端使用同样的hash算法获取该证书的hash值，叫H1.
然后用浏览器或操作系统内置的CA证书的公匙对发过来的证书上的Certificate Signature进行解密，得到H2
比较H1和H2，相等说明这个证书是可信的，不相等说明是不可信的。
3、第三次握手
客户端验证完证书后，认为可信则继续往下⾛, 接着，客户端就会⽣成⼀个新的随机数(pre-master)，⽤服务器
的 RSA 公钥加密该随机数，通过「Change Cipher Key Exchange」消息传给服务端。
服务端收到后，⽤ RSA 私钥解密，得到客户端发来的随机数 (pre-master)。
⾄此，客户端和服务端双⽅都共享了三个随机数，分别是Client Random、Server Random、pre-master。
于是，双⽅根据已经得到的三个随机数，⽣成会话密钥（Master Secret），它是对称密钥，⽤于对后续的 HTTP请求/响应的数据加解密
⽣成完会话密钥后，然后客户端发⼀个「Change Cipher Spec」，告诉服务端开始使⽤加密⽅式发送消息。
（「Change Cipher Spec」之前传输的 TLS 握⼿数据都是明⽂，之后都是对称密钥加密的密⽂。）
然后，客户端再发⼀个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再⽤会话密钥（master secret）加密⼀下，让服务器做个验证，验证加密通信是否可⽤和之前握⼿信息是否被中途篡改过
4、第四次握手
服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双⽅都验证加密和解密没问题，那么握⼿正式完成。
最后，就⽤「会话密钥」加解密 HTTP 请求和响应了
RSA 算法的缺陷：不⽀持前向保密。⼀旦服务端的私钥泄漏了，过去被第三⽅截获的所有 TLS 通讯密⽂都会被破解。
加密过程
非对称加密[算法]()：RSA，DSA/DSS
对称加密[算法]()：AES，RC4，3DES
HASH[算法]()：MD5，SHA1，SHA256
其中非对称加密[算法]()用于在握手过程中加密生成的密码，对称加密[算法]()用于对真正传输的数据进行加密，而HASH[算法]()用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密[算法]()对其加密。
