一、前言

本系列文章旨在温习计算机网络中心常识，进一步夯实基础，为今后参加物联网、音视频、直播、即时通讯等范畴的项目做一定的常识储藏。

文章列表:

01-计算机网络中心常识|计算机网络通识【计算机网络性能指标、网络协议分层的几种方法、OSI七层模型概念通识】
02-计算机网络中心常识|【搭建调试环境、新建Java项目、计算机通讯基础、计算机衔接方法、集线器/网桥/交换机/路由器】
03-计算机网络中心常识|【MAC地址、IP地址的组成、IP地址的分类、CIDR、子网掩码、超网】
04-计算机网络中心常识|【静态路由、动态路由、数据包的传输、ISP、服务器机房、网络分类、家用无线路由器、公网IP、
05-计算机网络中心常识|物理层/数据链路层【模拟信号&&数字信号、数据链路层】
06-计算机网络中心常识|网络层【IP数据包Packet、网络协议、Checksum、源IP地址和方针IP地址、ping】
07-计算机网络协议中心常识|【传输层-UDP】
08-计算机网络协议中心常识|【传输层-TCP之牢靠传输】
09-计算机网络中心常识|传输层TCP2【流量操控原理、拥塞操控:slow start、congestion avoidance、快速重传、快速康复】
10-计算机网络协议中心常识|【传输层-TCP衔接】
11-计算机网络协议中心常识|【运用层】
12-计算机网络中心常识|【Cookie、Session(概念、生命周期、有效期、浏览器的要求等)、跨域(概念、同源策略、跨域处理方
13-计算机网络协议中心常识|【署理/CDN/网络安全】
14-计算机网络协议中心常识|【(非)对称加密/数字签名/证书】
15-计算机网络协议中心常识|【HTTPS】
16-计算机网络中心常识|HTTPS协议【HTTP2、HTTP3】

本文首要重视：HTTP2、HTTP3各个版别之间的相关。

二、HTTP协议的不足（HTTP/1.1）

同一时间，一个衔接只能对应一个恳求（留意：不是树立多个衔接，是多个恳求只能在一个衔接内行列等待）。针对同一个域名，大多数浏览器答应同时最多6个并发衔接。
只答应客户端自动建议恳求（恳求应对形式，即一个恳求只能对应一个呼应）。
同一个会话的多次恳求中，头信息会被重复传输。通常会给每个传输增加500~800字节的开支。假如运用Cookie，增加的开支有时会达到上千字节。

1. SPDY

SPDY（speedy的缩写），是根据TCP的运用层协议，它强制要求运用SSL/TLS。2009年11月，Google宣布将SPDY作为进步网络速度的内部项目。

2. SPDY与HTTP的联系

-　SPDY并不用于取代HTTP，它只是修正了HTTP恳求与呼应的传输方法 -　只需增加一个SPDY层，现有的一切服务端运用均不用做任何修正 -　SPDY是HTTP/2的前身

2015年9月，Google宣布移除对SPDY的支撑，拥抱HTTP/2。

三、HTTP/2

HTTP/2，于2015年5月以RFC_7540正式宣布。依据W3Techs的数据，截止2019年6月，全球有36.5%的网站支撑了HTTP/2。

HTTP/1.1和HTTP/2速度比照：www.http2demo.io、https://http2.akam…

HTTP/2在底层传输做了许多的改进和优化，但在语意上完全与HTTP/1.1兼容。比方恳求方法（如GET、POST）、Status Code，各种Headers等都没有改变，因而要想晋级到HTTP/2，开发者不需求修正任何代码，只需求晋级服务器配置，晋级浏览器。

留意：SPDY强制运用TLS，但是HTTP/2文档并没有说明强制运用TLS，但在开发中仍是建议运用TLS。

1. 根本概念

数据流： 已树立的衔接内的双向字节省，能够承载一条或多条音讯。一切通讯都在一个TCP衔接上完成，同一时间内此衔接能够承载恣意数量的双向数据流。
音讯： 与逻辑HTTP恳求或呼应音讯对应，由一系列帧组成。
帧： HTTP/2通讯的最小单位，每个帧都包括帧头（会标识出当前帧所属的数据流），来自不同数据流的帧能够交织发送，然后再依据每个帧头的数据流标识符从头拼装。

2. HTTP/2的特性

2.1. 二进制格局

HTTP/2选用二进制格局传输数据，而非HTTP/1.1的文本格局。

二进制格局在协议的解析和优化扩展上带来更多的优势和可能。

2.2. 多路复用（Multiplexing）

-　客户端和服务器能够将HTTP音讯分解为互不依靠的帧，然后交织发送，最终再在另一端把它们从头拼装起来。 -　并行交织地发送多个恳求，恳求之间互不影响。 -　并行交织地发送多个呼应，呼应之间互不搅扰。 -　运用一个衔接并行发送多个恳求和呼应。 -　不用再为绕过HTTP/1.1限制而做许多工作，比方image sprites（精灵图）、兼并CSS/JS（一起放入一个文件中）、内嵌CSS/JS/Base64图片、域名分片（n个域名就能有6n个衔接）等。

精灵图是前端开发中的概念，image sprites（也叫作CSS Sprites），将多张小图兼并成一张大图，最终经过CSS（属性background:）结合小图的位置，尺寸进行精准定位。

2.3. 优先级

-　HTTP/2标准答应每个数据流都有一个相关的权重和依靠联系 -　能够向每个数据流分配一个介于1至256之间的整数 -　每个数据流与其他数据流之间能够存在显式依靠联系 -　客户端能够构建和传递“优先级树”，标明它倾向于怎么接纳呼应 -　服务器能够运用此信息经过操控CPU、内存和其他资源的分配设定数据流处理的优先级 -　在资源数据可用之后，确保将高优先级呼应以最优方法传输至客户端

应尽可能先给父数据流分配资源。同级数据流（共享相同父项）应按其权重份额分配资源。

A、B依靠于隐式“根数据流”，A取得的资源份额是12/16，B取得的资源份额是4/16。
D依靠于根数据流，C依靠于D，D应先于C取得完整资源分配。
D应先于C取得完整资源分配，C应先于A和B取得完整资源分配，B取得的资源是A所获资源的1/3。
D应先于E和C取得完整资源分配，E和C应先于A和B取得相同的资源分配，B取得的资源是A所获资源的1/3。

2.4. 头部紧缩

HTTP/2运用HPACK紧缩恳求头和呼应头，能够极大削减头部开支，进而进步性能。

早期版别的HTTP/2和SPDY运用zlib紧缩，能够将所传输头数据的巨细削减85%~88%。但在2012年夏天，被进犯导致会话绑架，后被更安全的HPACK取代。

客户端和服务端都会缓存一张恳求头静态表（Static table），当客户端发送恳求时，会检测客户端侧的恳求头表中是否有同样的头部数据，假如有，只需求向服务器发送头部对应的表中数据索引即可，这样就能削减头部的数据，达到头部紧缩方针。

2.5. 服务器推送（Server Push）

服务器能够对一个客户端恳求发送多个呼应。除了对开始恳求的呼应外，服务器还能够向客户端推送额外资源，而无需客户端额外明确地恳求。

3. HTTP/2的问题

3.1. 队头堵塞（head of line blocking）

TCP在传输数据的时分是有顺序的，而HTTP/2恳求或呼应是无序，假如TCP传输过程中，行列头部恳求丢包，后面的恳求都将无效，只能全部从头恳求或呼应。这是TCP的问题，不是HTTP的问题。

QUIC协议就处理了上面队头堵塞问题，假如发现丢包，不影响其他数据的拼装。首要原因是QUIC底层是用UDP完成的。

3.2. 握手推迟

RTT（Round Trip Time）：往返时延，能够简单理解为通讯一来一回的时间。

由于TCP本身需求3次握手，运用TLS后会推迟握手时间。QUIC由于运用的是UDP，所以不存在握手环节。

四、HTTP/3

Google觉得HTTP/2仍然不够快，于是就有了HTTP/3。

HTTP/3由Google开发，弃用TCP协议，改为运用根据UDP协议的QUIC协议完成。

QUIC（Quick UDP Internet Connections），快速UDP网络衔接。由Google开发，在2013年完成，于2018年从HTTP-over-QUIC改为HTTP/3。

队头堵塞和握手推迟是TCP的缺点，而TCP的优点是牢靠传输。UDP和TCP进行互补就有了QUIC。

1. HTTP/3的特性

1.1. 衔接迁移

TCP根据4要素（源IP、源端口、方针IP、方针端口）。切换网络时至少会有一个要素发生变化，导致衔接发生变化。当衔接发生变化时，假如还运用本来的TCP衔接，则会导致衔接失败，就得等本来的衔接超时后从头树立衔接。所以咱们有时分发现切换到一个新网络时，即便新网络状况良好，但内容仍是需求加载好久。假如完成的好，当检测到网络变化时马上树立新的TCP衔接，即便这样，树立新的衔接仍是需求几百毫秒的时间。

QUIC的衔接不受4要素的影响，当4要素发生变化时，原衔接仍然保持。QUIC衔接不以4要素作为标识，而是运用一组Connection ID（衔接ID）来标识一个衔接。即便IP或者端口发生变化，只需Connection ID没有变化，那么衔接仍然能够保持。比方当设备衔接到Wi-Fi时，将进行中的下载从蜂窝网络衔接转移到更快速的Wi-Fi衔接，当Wi-Fi衔接不再可用时，将衔接转移到蜂窝网络衔接。

1.2. 操作系统内核、CPU负载

据Google和Facebook称，与根据TLS的HTTP/2相比，它们大规模布置的QUIC需求近2倍的CPU运用量。由于Linux内核的UDP部分没有得到像TCP那样的优化，由于传统上没有运用UDP进行如此高速的信息传输。TCP和TLS有硬件加速，而这关于UDP很罕见，关于QUIC则根本不存在。

随着时间的推移，信任这个问题会逐步得到改进。

2. 疑问

-　HTTP/3根据UDP，怎么确保牢靠传输？ – 由QUIC来确保（在QUIC中加入了确保牢靠传输的算法） -　为何Google不开发一个新的不同于TCP、UDP的传输层协议？ -　首要Google是绝对有能力开发的，首要是现在世界上的网络设备根本只认TCP、UDP。假如要修正传输层，意味着操作系统的内核也要修正。 -　别的，由IETF标准化的需求TCP新特性都因缺乏广泛支撑而没有得到广泛的布置或运用。 -　因而，要想开发并运用一个新的传输层协议，是极端困难的一件工作。

HTTP/3还在优化中（不成熟），所以现在大部分公司仍是运用的HTTP/2或者HTTP/1.1。