简单谈谈http从1.0到http3

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：表示效劳器正忙，暂时无法访问

更多http状态码可以看原来我这篇文章https://hcnote.cn/215

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缺点

不安全：

明文通信、不验身份、无法确认报文的完整性（被篡改）

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[算法]()用于考证数据的完好性。由于阅读器生成的密码是整个数据加密的关键，因而在传输的时分运用了非对称加密[算法]()对其加密。