2021-11-03 http1.0 http2 https之间的发展历程

http 0.9


只有get请求,只能发送文本,响应请求后立即关闭


http 1.0


1、加强http 0.9 文本之外,还可以发送图片、文件、音乐等,引入了http header的概念,增加了状态码,以及head、post等方法。
2、响应请求后立刻断开连接(无连接):导致的问题就是无法持久连接,每次发送请求都需要进行tcp连接,性能不好。
3、队头堵塞:http 1.0 规定一个请求得到响应之后,才能发送下一个请求。如果第一个请求一直没有回来,那下一个请求就一直无法发出。


http 1.1

为了解决1.0的诸多问题,1.1出现了


1、长连接:增加Connection字段,通过设置Keep-Alive,可以保持长接连不断开,使得请求管线化成为可能。管线化使得请求能够“并行”传输。(这里的并行不是真正的并行)。因为服务器需要按照请求的先后顺序进行应答,以便客户端能够区分每个请求对应的响应内容。
2、增加put、delete等新的方法
3、允许相应数据分段
4、增加缓存处理(强缓存和协商缓存),增加字段cache-control

1、expires:最先引入的字段,值是过期时间。但是这个字段有漏洞,因为客户端的时间和服务器的时间可能不一致,会出现问题
2、cache-control(比expires优先级高)
    max-age
    no-cache // 每次都去服务端询问,看有没有变化
    no-store // 不缓存
3、协商缓存
    last-modify / if-modified-since    //在某个时间点后,是否更改过,但是只是精确到s,如果在1s内发生更改,检测不出来,所以要配合
    etag 使用,如果etag / if-none-match不一致,那么就改变了(if-none-match 优先级高于if-modified-since)。如果文件很大,生成摘要比较耗时,会简单使用弱指纹,比如last-modified + 文件长度 来判断文件是否更改。

5、不对请求头进行压缩,只对请求体进行压缩
6、传输时是纯文本格式,解析起来很麻烦


但是还是没有解决队头堵塞的问题


所以浏览器厂商采用另外一种做法,打开多个tcp会话,但是会有限制,比如同一个域名最多能打开6个tcp会话。那我们说可以多增加几个不同的域名,但是域名过多会引起dns域名解析复杂,也不推荐


https(保证密文,防止篡改)

对称加密 非对称加密 混合加密

http2

主要是提升http性能,并且兼容http1.1
问题
a. http1.1只是压缩了请求体,对请求头没有压缩
b.http1.1的管线化,也同样存在队头阻塞的问题
解决方式
1、多路复用
同一条TCP线路上可以乱序发送请求和响应,多个请求和响应之间没有顺序
(1)同域下只开一个tcp连接
(2)采用2进制格式传输数据。http1.1采用文本格式,需要处理空格、换行等。文本的表现形式具有多样性,而2进制只有0和1,体积更小,处理起来歧义也更小
(3)采用流的形式传输数据,每一帧都有编号
(4)对头部进行压缩,将请求行移动到header中,用hpack算法进行压缩
(5)服务端推送(服务端可以提前把客户端要用的数据推送到客户端)

http3 (主要解决tcp队头堵塞的问题)

tcp为了保证可靠传输,如果发生了丢包,需要一直等待发生丢包的数据重新传输,造成队头堵塞。
(1)采用QUIC协议
a、主要是将tcp协议更换为udp协议,udp是无序的,所以可以解决队头堵塞。
udp是不必经过3次握手,比tcp快;quic基于udp实现了可靠传输、流量控制、实现流和多路复用
b、支持链接迁移,不受port和ip变化而发生重连,通过connectionid进行链接
c、使用qpack进行头部压缩,因为hpack进行头部压缩有顺序,会造成队头堵塞

http 优化

image.png
Timing

queueing: 请求发送之前会根据优先级进行排队,同时每个域名最多处理6个tcp连接,超过的也要进行排队,同时操作系统分配磁盘空间也会有一定的耗时
stalled:请求发送前的等待时间(处理代理,连接复用)
dns lookup:查找dns的时间
initial connection: 建立tcp连接的时间
ssl: ssl握手的时间(ssl协商)
request sent:请求发送时间
waiting: 等待响应时间,客户端收到首个字符的时间
content download: 下载响应的时间

优化

1、减少dns的数量,dns越多,解析需要花费的时间就越多
2、减少网站中的重定向数量,重定向越多,请求就越多
3、选用高性能的web服务器nginx代理静态资源
4、资源大小优化:对资源进行压缩、合并(合并可以减少请求数量,也会产生资源缓存问题)
5、给资源增加强制缓存和协商缓存
6、升级http1.1到http2
7、将静态资源迁移到cdn

CDN

CDN全称是content delivery network,受制于网络限制,访问者离服务器越远,速度就越慢
核心就是 离你最近的服务器提供数据

  • 现在全国各地假设cdn服务器
  • 正常访问网站会通过dns解析,解析到对应的服务器
  • 解析1:我们通过cdn域名访问时,会被解析到cdn专用dns服务器上。并返回cdn负载均衡服务器的地址
  • 解析2:向全局负载均衡服务器发送请求,全局负载均衡服务器会根据用户ip分配用户区域的负载均衡服务器。并返回一台cdn服务器ip地址
  • 解析3: 用户向cdn服务器发起请求,如果服务器上不存在次稳健,则向上一级缓存服务器请求,直至查找到源服务器,返回结果,并缓存到dns服务器上。
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 200,045评论 5 468
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,114评论 2 377
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 147,120评论 0 332
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,902评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,828评论 5 360
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,132评论 1 277
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,590评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,258评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,408评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,335评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,385评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,068评论 3 315
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,660评论 3 303
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,747评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,967评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,406评论 2 346
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,970评论 2 341

推荐阅读更多精彩内容