回顾HTTP2.0

HTTP1.1在应用层以纯文本的形式进行通信,每次通信都要带完整的HTTP的头,而且不考虑pipeli模式的化,每次的过程总是像上面描述的那样一去一回。那样在实时性、并发想上都存在问题

头部压缩:HTTP2.0会对HTTP的头进行一定的压缩,将原来每次都要携带的大量key value在两端建立一个索引表,对相同的头只发送索引表中的索引

HTTP2.0协议将一个TCP的连接中,切分成多个流。每个流都有自己的ID,而且流可以是客户端发服务端,也可以是服务端发客户端,它其实只是一个虚拟的通道。流是有优先级的

HTTP2.0还将所有的传输信息分割为更小的信息和帧,并对它们采用二进制格式编码。常见的帧有Header帧,用于传输Header内容,并且会开启一个新的流,再就是Data帧,用来传输正文实体。多个Data帧属于一个流

通过这两种机制,http2.0的客户端可以将对个请求不同的流中,然后将请求内容拆成帧,进行二进制传输。这些真可以打散乱序发送,然后根据每个帧首部的流标识符重新组装,并且可以根据优先级,决定先处理那个流的数据

二进制传输就是以上

例子:

假设一个页面要发送三个独立的请求,一个获取css,一个获取js,一个获取图片jpg。如果使用HTTP1.1就是串行的,但是如果使用HTTP2.0,就可以在一个连接里,客户端和服务端都可以同时发送多个请求或回应,而且不用按照顺序一对一对应

http2.0成功解决了http1.1的队首阻塞问题,同时,也不需要通过http1.x的pipeline机制用多条tcp连接来实现并行请求和响应;减少了tcp连接数对服务器性能的影响,同时将页面的多个数据css,js,jpg等通过一个数据链接进行传输,能够加快页面组件的传输速度。

QUIC协议

HTTP2.0 也是基于TCP协议的,tcp协议在处理包时是有严格顺序的

当其中一个数据包遇到问题,TCP连接需要等待找个包完成重传之后才能继续进行,虽然HTTP2.0通过多个stream,使得逻辑上一个tcp连接上的并行内容,进行多路数据的传输,然而这中间没有关联的数据,一前一后,前面stream2的帧没有收到,后面stream1的帧也会因此堵塞

于是google的 QUIC协议从TCP切换到UDP

  • 机制一:自定义连接机制
    一条tcp连接是由四元组标识的,分别是源ip、源端口、目的端口,一旦一个元素发生变化时,就会断开重连,重新连接。在次进行三次握手,导致一定的延时

在TCP是没有办法的,但是基于UDP,就可以在QUIC自己的逻辑里面维护连接的机制,不再以四元组标识,而是以一个64
位的随机数作为ID来标识,而且UDP是无连接的,所以当ip或者端口变化的时候,只要ID不变,就不需要重新建立连接

  • 机制二:自定义重传机制
    tcp为了保证可靠性,通过使用序号和应答机制,来解决顺序问题和丢包问题

任何一个序号的包发过去,都要在一定的时间内得到应答,否则一旦超时,就会重发这个序号的包,通过自适应重传算法(通过采样往返时间RTT不断调整)

但是,在TCP里面超时的采样存在不准确的问题。例如发送一个包,序号100,发现没有返回,于是在发送一个100,过一阵返回ACK101.客户端收到了,但是往返的时间是多少,没法计算。是ACK到达的时候减去第一还是第二。

QUIC也有个序列号,是递增的,任何宇哥序列号的包只发送一次,下次就要加1,那样就计算可以准确了

但是有一个问题,就是怎么知道包100和包101发送的是同样的内容呢?quic定义了一个offset概念。QUIC既然是面向连接的,也就像TCP一样,是一个数据流,发送的数据在这个数据流里面有个偏移量offset,可以通过offset查看数据发送到了那里,这样只有这个offset的包没有来,就要重发。如果来了,按照offset拼接,还是能够拼成一个流。

  • 机制三: 无阻塞的多路复用

有了自定义的连接和重传机制,就可以解决上面HTTP2.0的多路复用问题

同HTTP2.0一样,同一条 QUIC连接上可以创建多个stream,来发送多个HTTP请求,但是,QUIC是基于UDP的,一个连接上的多个stream之间没有依赖。这样,假如stream2丢了一个UDP包,后面跟着stream3的一个UDP包,虽然stream2的那个包需要重新传,但是stream3的包无需等待,就可以发给用户。

  • 机制四:自定义流量控制

TCP的流量控制是通过滑动窗口协议。QUIC的流量控制也是通过window_update,来告诉对端它可以接受的字节数。但是QUIC的窗口是适应自己的多路复用机制的,不但在一个连接上控制窗口,还在一个连接中的每个steam控制窗口。

在TCP协议中,接收端的窗口的起始点是下一个要接收并且ACK的包,即便后来的包都到了,放在缓存里面,窗口也不能右移,因为TCP的ACK机制是基于序列号的累计应答,一旦ACK了一个序列号,就说明前面的都到了,所以是要前面的没到,后面的到了也不能ACK,就会导致后面的到了,也有可能超时重传,浪费带宽

QUIC的ACK是基于offset的,每个offset的包来了,进了缓存,就可以应答,应答后就不会重发,中间的空档会等待到来或者重发,而窗口的起始位置为当前收到的最大offset,从这个offset到当前的stream所能容纳的最大缓存,是真正的窗口的大小,显然,那样更加准确。

HTTP3.0(QUIC的实现机制)的更多相关文章

  1. 解决EF 4.0 中数据缓存机制

    EF4.0默认开启缓存机制,如果想要禁用缓存机制的话,则须加上一句话:_db.CreateObjectSet().MergeOption = MergeOption.OverwriteChanges; ...

  2. FreeBSD 5.0中强制访问控制机制的使用与源代码分析【转】

    本文主要讲述FreeBSD 5.0操作系统中新增的重要安全机制,即强制访问控制机制(MAC)的使用与源代码分析,主要包括强制访问控制框架及多级安全(MLS)策略两部分内容.这一部分讲述要将MAC框架与 ...

  3. QUIC协议和HTTP3.0技术研究

    QUIC:基于UDP的安全可靠的HTTP/2传输协议 摘要 QUIC(Quick UDP Internet Connection)是一个新的基于UDP的管线化技术和安全传输协议. QUIC提供: 和H ...

  4. ENode 1.0 - 消息的重试机制的设计思路

    项目开源地址:https://github.com/tangxuehua/enode 上一篇文章,简单介绍了enode框架中消息队列的设计思路,本文介绍一下enode框架中关系消息的重试机制的设计思路 ...

  5. Unity2.0容器自动注册机制

    现如今可能每个人都会在项目中使用着某种 IoC 容器,并且我们的意识中已经形成一些固定的使用模式,有时会很难想象如果没有 IoC 容器工作该怎么进展. IoC 容器通过某种特定设计的配置,用于在运行时 ...

  6. 结合源码看nginx-1.4.0之nginx多进程机制详解

    目录 0. 摘要 1. nginx多进程设计思想 2. nginx多进程设计数据结构 3. nginx进程间通信机制 4. 一个简单的多进程例子 5. 小结 6. 参考源码

  7. 结合源码看nginx-1.4.0之nginx异步机制详解

    目录 0. 摘要 1. nginx异步设计思想 2. nginx异步设计数据结构 3. nginx异步机制源码解析 4. 一个简单的应用异步例子 5. 小结 6. 参考源码

  8. 结合源码看nginx-1.4.0之nginx事件驱动机制详解

    目录 0. 摘要 1. nginx事件模块组织结构 2. nginx事件模块数据结构及类图 3. nginx事件模块运行机制 4. 练习:一个简单的事件驱动模块 5. 小结 6. 参考源码

  9. Kafka 0.8 副本同步机制理解

    Kafka的普及在很大程度上归功于它的设计和操作简单,如何自动调优Kafka副本的工作,挑战之一:如何避免follower进入和退出同步副本列表(即ISR).如果某些topic的部分partition ...

随机推荐

  1. 优化tableView性能(针对滑动时出现卡的现象)

    优化tableView性能(针对滑动时出现卡的现象) 在iOS应用中,UITableView应该是使用率最高的视图之一了.iPod.时钟.日历.备忘录.Mail.天气.照片.电话.短信. Safari ...

  2. python 错误问题解决

    获取天气信息 #encoding:UTF-8 import urllib.request import re def getHtml(url): page=urllib.request.urlopen ...

  3. C++的队列和pair

    C++队列的成员函数: back()返回最后一个元素 empty()如果队列空则返回真 front()返回第一个元素 pop()删除第一个元素 push()在末尾加入一个元素 size()返回队列中元 ...

  4. 转:比较spring cloud和dubbo,各自的优缺点是什么

    原文:https://blog.csdn.net/u010664947/article/details/80007767 dubbo由于是二进制的传输,占用带宽会更少 springCloud是http ...

  5. 转:SpringCloud服务注册中心比较:Consul vs Zookeeper vs Etcd vs Eureka

    原文链接地址:http://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/ 这里就平时经常用到的服务发现的 ...

  6. tcp客户端socket

    import socket # 和udp的区别显而易见,udp发送和接收的是一个元祖,因为udp是不建立连接的,只有得到了对方的端口和ip才能进行沟通. # 而tcp不是,tcp发送和接受的是一个字符 ...

  7. MySQL另类的备份恢复方法——innodb可传输表空间

      Preface       There're many ways in backing up or migrating data from one server to another one.Lo ...

  8. httpd虚拟主机、站点访问控制、基于用户的访问控制、持久链接等应用配置实例

    httpd配置内容 httpd2.2 配置文件: /etc/httpd/conf/httpd.conf /etc/httpd/conf.d/*.conf 服务脚本: /etc/rc.d/init.d/ ...

  9. openldap完整版本搭建记录

    文档信息 目        的:搭建一套完整的OpenLDAP系统,实现账号的统一管理.                     1:OpenLDAP服务端的搭建                   ...

  10. 2、spring boot 配置文件

    配置文件 SpringBoot使用一个全局的配置文件,配置文件名是固定的: •application.properties •application.yml 配置文件的作用:修改SpringBoot自 ...