简单谈谈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:表示效劳器正忙,暂时无法响应

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

暂无评论

发送评论 编辑评论

|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇