【网络协议从入门到底层原理】学习笔记汇总

HTTP/1.1协议的不足

同一时间，一个连接只能对应一个请求

• 针对同一个域名，大多数浏览器允许同时最多6个并发连接

只允许客户端主动发起请求

• 一个请求只能对应一个响应

同一个会话的多次请求中，头信息会被重复传输

• 通常会给每个传输增加 500~800 字节的开销
• 如果使用 Cookie，增加的开销有时会达到上千字节

SPDY 协议

SPDY (speedy的缩写)，是基于TCP的应用层协议，它强制要求使用 SSL/TLS

• 2009年11月，Google 宣布将 SPDY 作为提高网络速度的内部项目

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 速度对比

• http://www.http2demo.io/
• https://http2.akamai.com/demo

HTTP/2在底层传输做了很多的改进和优化，但在语意上完全与 HTTP/1.1 兼容

• 比如请求方法（如GET、POST）、Status Code、各种Headers等都没有改变
• 因此，要想升级到 HTTP/2
  开发者不需要修改任何代码
  只需要升级服务器配置、升级浏览器

HTTP/2的特性 - 二进制格式

HTTP/2 采用二进制格式传输数据，而非HTTP/1.1的文本格式；

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

HTTP/2基本概念 - 数据流、消息、帧

数据流：已建立的连接内的双向字节流，可以承载一条或多条消息

• 所有通信都在一个TCP连接上完成，此连接可以承载任意数量的双向数据流

消息：与逻辑HTTP请求或响应消息对应，由一系列帧组成

帧：HTTP/2通信的最小单位，每个帧都包含帧头（会标识出当前帧所属的数据流）

• 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装

HTTP/2的特性 - 多路复用（Multiplexing）

客户端和服务器可以将 HTTP消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来

• 并行交错地发送多个请求，请求之间互不影响
• 并行交错地发送多个响应，响应之间互不干扰
• 使用一个连接并行发送多个请求和响应
  

不必再为绕过HTTP/1.1限制而做很多工作

• 比如精灵图 (image sprites)、合并CSSJS、内嵌CSSJSBase64图片、域名分片等

精灵图 (image sprites)
image sprites（也叫做CSS Sprites），将多张小图合并成一张大图

• 最后通过CSS结合小图的位置、尺寸进行精准定位
  

HTTP/2的特性 - 优先级

HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系

• 可以向每个数据流分配一个介于1至256之间的整数
• 每个数据流与其他数据流之间可以存在显式依赖关系

客户端可以构建和传递 “优先级树”，表明它倾向于如何接收响应

服务器可以使用此信息通过控制CPU、内存和其他资源的分配设定数据流处理的优先级

• 在资源数据可用之后，确保将高优先级响应以最优方式传输至客户端

HTTP/2的特性 - 头部压缩

早期版本的 HTTP/2 和 SPDY 使用 zlib 压缩请求头和响应头

• 可以将所传输头数据的大小减小85%~88%
• 但在2012年夏天，被攻击导致会话劫持
• 后被更安全的 HPACK 取代

目前，HTTP/2使用 HPACK 压缩请求头和响应头

• 可以极大减少头部开销，进而提高性能
  
  

HTTP/2的特性 - 服务器推送（Server Push）

服务器可以对一个客户端请求发送多个响应

• 除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端额外明确地请求
  

HTTP/2的问题 - 队头阻塞（head of line blocking）

后面 HTTP/3 提出的解决方案是 QUIC…

HTTP/2的问题 - 握手延迟

RTT (Round Trip Time)：往返时延，可以简单理解为通信一来一回的时间

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

HTTP/3 的一些疑问：

1、HTTP/3 基于UDP，如何保证可靠传输？

• 由 QUIC 来保证

2、为何Google不开发一个新的不同于TCP、UDP的传输层协议？

• 目前世界上的网络设备基本只认TCP、UDP
• 如果要修改传输层，意味着操作系统的内核也要修改
• 另外，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用
• 因此，要想开发并应用一个新的传输层协议，是极其困难的一件事情

HTTP/3的特性 - 连接迁移

TCP基于4要素：源IP、源端口、目标IP、目标端口

• 切换网络时至少会有一个要素发生变化，导致连接发生变化
• 当连接发生变化时，如果还使用原来的TCP连接，则会导致连接失败，就得等原来的连接超时后重新建立连接
• 所以我们有时候发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久
• 如果实现得好，当检测到网络变化时立刻建立新的TCP连接，即使这样，建立新的连接还是需要几百毫秒的时间

QUIC的连接不受4要素的影响，当4要素发生变化时，原连接依然维持

• QUIC连接不以4要素作为标识，而是使用一组 Connection ID (连接ID) 来标识一个连接
• 即使IP或者端口发生变化，只要Connection ID没有变化，那么连接依然可以维持
• 例如：
  当设备连接到Wi-Fi时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接
  当Wi-Fi连接不再可用时，将连接转移到蜂窝网络连接

HTTP/3的问题 - 操作系统内核、CPU负载

据Google和Facebook称，与基于TLS的HTTP/2相比，它们大规模部署的QUIC需要近2倍的CPU使用量

• Linux内核的UDP部分没有像TCP那样的优化，因为传统上没有使用UDP进行如此高速的信息传输
• TCP和TLS有硬件加速，而这对于UDP很罕见，对于QUIC则基本不存在

随着时间的推移，相信这个问题会逐步得到改善

HTTP/3的特性 - 向前纠错（还未成为标准）

基于TPC协议的话，丢包以后会重传。

HTTP/3的向前纠错，丢包以后可以根据其他包推测出这个包的数据（只适合丢失少量数据）。但是目前还没有成为标准，以后是否会成为标准也不确定。

最后

以上就是精明咖啡豆为你收集整理的网络协议从入门到底层原理（9）HTTP/1.1的升级改进（HTTP/2、HTTP/3）HTTP/1.1协议的不足SPDY 协议HTTP/2HTTP/3的全部内容，希望文章能够帮你解决网络协议从入门到底层原理（9）HTTP/1.1的升级改进（HTTP/2、HTTP/3）HTTP/1.1协议的不足SPDY 协议HTTP/2HTTP/3所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。