HTTP,从1.0到HTTP/3

2021年8月25日20:42:42
评论
140 3666字

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[算法]()用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键,因此在传输的时候使用了非对称加密[算法]()对其加密。

您可能感兴趣的文章

匿名

发表评论

匿名网友