每天一个知识点:HTTP 1.0、1.1、 2.0、 3.0 的特点及其区别

  • HTTP1.0

    • 特点:
      • 无状态:服务器既不跟踪每个客户单,也不记录过去的请求(无状态)。
      • 无连接:浏览器每次请求都需要与服务器建立一个TCP连接,即三次握手,服务器处理完成以后立即断开TCP连接。
      • 无 host:即没有 http request header host。
    • 存在的问题:
      • 无法复用连接: 每次发送请求,都需要进行一次TCP连接,而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
      • 队头阻塞(head of line blocking): 由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送,假设前一个请求响应一直不到达,那么下一个请求就不发送,后面的请求就阻塞了。
      • 无法断点续传:由于请求是无状态的,所以无法断点续传,也无法传输对象的一部分,必须一次性传输整个对象。
  • HTTP1.1

    • 特点:
      • 长连接:增加Connection字段,通过设置Keep-Alive保持HTTP连接不断卡。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。
      • 管道化(pipelining)— 尴尬的假并行传输,即能够“并行”发送多个请求。(注意,这里的“并行”并不是真正意义上的并行传输),服务器必须按照客户端请求的先后顺序依次回送相应的结果,以保证客户端能够区分出每次请求的响应内容。
      • 缓存处理 — 强缓存、协商缓存,启发式缓存(新增),加入了缓存处理(强缓存和协商缓存),新的字段如cache-control。
      • 支持断点传输,以及增加了Host字段(使得一个服务器能够用来创建多个Web站点)。
    • 存在的问题
      • 由于无法解决队头阻塞(head of line blocking)的问题,长连接会给服务器造成压力,而且同时“管道化”技术存在各种各样的问题,所以很多浏览器要么根本不支持它,要么直接默认关闭,并且开启的条件很苛刻。
  • HTTP2.0

    • 特点:
      • 二进制分帧:在应用层和传输层之间增加一个二进制分层帧,突破了HTTP1.1的性能限制,改进传输性能。
      • 头部压缩,使用 encoder 来减少需要传输的 header 大小,通讯双方各自维护一个header 的索引表,不需要发送值,直接发送 key 缩减头部大小,减少发送包的数量从而降低延迟。
      • 多路复用(或连接共享):所有HTTP2.0通信都在一个TCP链接上完成,这个链接可以承载任意流量的双向数据流。每个数据流以消息的形式发送,而消息由一或多个帧组成。这些帧可以乱序发送,然后再根据每个帧头部的流标识符(Stream_id)重新封装。多路复用可能会导致关键字被阻塞,HTTP2.0里每个数据流都可以设置优先级和依赖,优先级高的数据流会被服务器优先处理和返回客户端,数据流还可以依赖其他的子数据流。
      • 服务器推送(Sever push):服务器除了最初请求的响应外,服务器还可以额外向客户端推送资源,而无需客户端明确的需求。
  • HTTP3.0

    • 特点:
      • 0-RTT使用了基于 Google 的 QUIC 协议, QUIC 协议相比于 HTTP2.0 最大的优势是 0-RTT 建连,即传输层 0-RTT 就能建立连接,而加密层 0-RTT 就能建立加密连接,具体实现为缓存了当前会话的上下文,下次恢复会话的时候,只需要将之前的缓存传递给服务器,验证通过,就可以进行传输了。QUIC 协议实际上是使用 UDP 实现的。
      • 更好的移动端表现:QUIC在移动端的表现比TCP好,因为 TCP 是基于 IP 识别连接,而QUIC 是通过 ID 识别链接。 无论网络环境如何变化,只要 ID 不便,就能迅速重新连上。
      • 加密认证优化:TCP协议头没有经过任何加密和认证,在传输过程中很容易被中间网络设备篡改、注入和窃听。QUIC的 packet 可以说武装到了牙齿,除了个别报文,比如PUBLIC_RESET 和 CHLO,所有报文头部都是经过认证的,报文 Body 都是经过加密的。所以只要对 QUIC 做任何更改,接收端都能及时发现,有效地降低了安全风险
      • 优化了重传策略,一个连接上的多个stream之间没有依赖,即使丢包,只需要重发丢失的包即可,不需要重传整个连接,重传包和原包的编号不同,降低后续重传计算的消耗。
      • 向前纠错机制:QUIC协议有一个非常独特的特性,称为向前纠错(Foward Error Connec,FEC),每个数据包除了它本身的内容之外还包括了其他数据包的数据,因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。向前纠错牺牲了每个数据包可以发送数据的上限,但是带来的提升大于丢包导致的数据重传,因为数据重传将会消耗更多的时间(包括确认数据包丢失,请求重传,等待新数据包等步骤的时间消耗)。

    参考: 快速掌握HTTP 1.0 1.1 2.0 3.0 的特点及其区别

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,242评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,769评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,484评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,133评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,007评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,080评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,496评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,190评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,464评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,549评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,330评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,205评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,567评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,889评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,160评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,475评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,650评论 2 335

推荐阅读更多精彩内容