1、IETF（Internet engineering task force）是一个开放的标准组织--互联网工程任务组，负责开发和推广自愿互联网标准，特别是构成TCP/IP协议族。
2、QUIC(quic udp internet connect)一种基于 UDP 的低延迟互联网传输协议，该协议常用于游戏、流媒体和 VoIP 服务。QUIC提供默认加密能力。 详细地说，QUIC虽然使用UDP作为基础，但它涉及丢失恢复。这是因为 QUIC 的行为类似于 TCP，并在数据丢失时单独检查每个流重新传输数据。
此外，如果一个流发生错误，QUIC 可以继续独立地为其他流服务。此功能对于提高易出错链路的性能非常有用，因为在 TCP 通知丢失或丢失的数据包之前可能会收到大量额外的数据。在 QUIC 中，可以在修复流的同时自由处理这些数据。
3、MTU(maximum transmission unit)最大传输单元
4、MSS（maximum segment size）最大tcp分段大小
- MTU - (TCP 标头 + IP 标头) = MSS IPsec(internet Protocol security) 互联网协议安全
MTU 和 MSS 之间的主要区别之一是，如果数据包超过设备的 MTU，则会分解为更小的部分，或“分段”。相反，如果一个数据包超过 MSS，它就会被丢弃并且不会被传递。
TCP 为所有数据包添加一个标头，以指示每个数据包属于哪个打开的连接以及数据包进入的顺序。
5、SET化
SET化可以提升业务系统的容灾能力和水平扩展能力
*——SET化是一套解决异地容灾、异地扩展的解决方案*
*——SET化是按核心数据维度，对业务系统的部署架构和流量进行切分和互备，从而实现更灵活的扩展能力和更强的容灾能力*
6、AZ (Available Zone)（可用区）
源自AWS的概念，电力、网络相互独立的机房可以称为AZ。美团各个机房，如yf cq rz gh gq jd都可以被认为是为AZ，再比如腾讯云的北京一区、北京二区就是两个AZ
7、短连
在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接，这是一种“短连接”。
8、长连
在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求，这是一种“长连接”。在Http 1.1 中只需要在请求头配置keep-alive : true即可实现长连接。此时，服务端返回的请求头中会有 connection : keep-alive 表明这是一个长连接。Http长连接 和 TCP长连接的区别在于: TCP 的长连接需要自己去维护一套心跳策略。
9、RTT(Round-Trip Time)往返时延
表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。
单向时延=传输时延+传播时延+排队时延
10、TCP 存在队头阻塞，影响大包性能。拥塞控制算法
背景：为了达到完全有序而引入的延迟机制。
原因：发生在一个TCP分节丢失，导致其后续分节不按序到达接收端的时候。该后续分节将被接收端一直保持直到丢失的第一个分节被发送端重传并到达接收端为止。该后续分节的延迟递送确保接收应用进程能够按照发送端的发送顺序接收数据。
11、http/2和http/3 compare www.section.io/engineering…
http3-explained.haxx.se/zh/h3/h3-h2
12、http/1.1
HTTP/1.1是基于“文本分割”解析的协议 发送完上一个请求，才能发送下一个
13、http/2
HTTP/2是基于二进制“帧”的协议 HTTP/2是分帧的，请求和响应可以交错甚至可以复用。 HTTP/2的新特性之一是基于流的流量控制。
14、https、http/3
https:通常将TLS安全保护的HTTP通信，称之为HTTPS，以区别于没有TLS安全防护的HTTP明文通信。
https的通信时长计算：tcp连接时间 + tls连接时间 + http传输时间
http/3
底层使用UDP协议，在UDP的基础上增加了QUIC协议并使用TSL1.3加密，使用QPACK压缩header。
15、http/1.1队头堵塞（“应用层”队头阻塞）
举两个例子，比如超市购物，在只有一个收银渠道时，只要有一个人block了，后续的顾客会被block住；再比如高速公路，只有一个车道时，一辆车block了，后续的车辆都block住了。
对应于我们的网络也是相同的，当在数据传输的时候。假使前面传输的数据包是打包，后面的都要等待。为了解决这个问题，浏览器为每个页面打开最多6个并行连接。当然6个连接是远远不够的，于是有了多域名“分片”，将不同的资源放入不同的服务器，但是无疑这么做会增大服务器资源开销。
http/1.1队头堵塞在http/2得到了解决。它是怎么解决的呢？首先http/1.1是基于文本传输的，资源块之间不使用分割符。http/2要解决的东西也很明显，标识不同的资源块进行传输，实现资源块“调度（scheduled）”。http/2采用二进制数据帧传输，在资源块前加了数据帧，其中帧对数据进行顺序标识，每个数据帧标识了数据资源块的大小以及为每个资源字节流分配流ID。通过流ID将数据块解析到正确的资源”流“。对于同一个域名请求，实现多路复用，在一个TCP通道进行传输。同时，HTTP/2为资源传输提供了不同方法， 比如两个资源1和2进行传输，可以是如下的一种：
- 公平多路复用（例如两个渐进的 JPEGs）：12121212
- 加权多路复用（2是1的两倍）：22122122121
- 反向顺序调度（例如2是密钥服务器推送的资源）：22221111
- 部分调度（流1被中止且未完整发送）：112222
HTTP/2 的帧（frames）及其优先级设置解决了 HTTP/1.1 的队头阻塞问题。
16、TCP队头堵塞
TCP的特点：面向连接，可靠的，基于字节流的传输层协议。同时具有数据传重传，拥塞控制，可靠传输的特点。可靠传输的优点导致了TCP的队头堵塞。假设有三个数据包，TCP已经接收到了数据包1和数据包3。由于在将数据包传递给浏览器前会校验数据的完整性，这时发现丢失了数据包2，它会一直等待数据包2重传。这就导致了TCP的队头堵塞（HOL Block）。为了解决这个问题，引入了新的传输层协议QUIC（QUIC UDP INTENET CONNECT）。虽然基于UDP，但是TCP的所有特性它都有（可靠性、拥塞控制、流量控制、排序等）
17、帧
HTTP/2 中数据传输的最小单位
18、流
存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数 ID。 HTTP/2 长连接中的数据包是不按请求-响应顺序发送的，一个完整的请求或响应(称一个数据流 stream，每个数据流都有一个独一无二的编号)可能会分成非连续多次发送。它具有如下几个特点：
- 双向性：同一个流内，可同时发送和接受数据。
- 有序性：流中被传输的数据就是二进制帧 。帧在流上的被发送与被接收都是按照顺序进行的。
- 并行性：流中的 二进制帧 都是被并行传输的，无需按顺序等待。
- 流的创建：流可以被客户端或服务器单方面建立, 使用或共享。
- 流的关闭：流也可以被任意一方关闭。
- HEADERS 帧在 DATA 帧前面。
- 流的 ID 都是奇数，说明是由客户端发起的，这是标准规定的，那么服务端发起的就是偶数了。
19、Keep-Alive
一定时间内，同一域名多次请求数据，只建立一次 HTTP 请求，其他请求可复用每一次建立的连接通道，以达到提高请求效率的问题。
20、QUIC如何解决TCP队头堵塞
QUIC 支持乱序确认，QUIC采用Package Number代替tcp基于字节的Sequence Number，并且每个 Packet Number 都严格递增，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值，比如Packet N+M。这样就不会因为丢包重传将当前窗口阻塞在原地，从而解决了队头阻塞问题。那么，既然重传数据包的Packet N+M 与丢失数据包的Packet N 编号并不一致，我们怎么确定这两个数据包的内容一样呢？
使用Stream ID 来标识当前数据流属于哪个资源请求，使用Stream Offset标识当前数据包在当前Stream ID 中的字节偏移量。有了Stream ID 和Stream Offset，数据包也可以乱序传输了（HTTP/2 中仅靠Stream ID 标识，要求同属于一个Stream ID 的数据帧必须有序传输）。
总结，QUIC 通过单向递增的Packet Number，配合Stream ID 与 Offset 字段信息，可以支持非连续确认应答Ack而不影响数据包的正确组装，摆脱了TCP 必须按顺序确认应答Ack 的限制（也即不能出现非连续的空位），解决了TCP 因某个数据包重传而阻塞后续所有待发送数据包的问题（也即队头阻塞问题）。
21、TLS 协议层也存在队头阻塞
原因：TLS 协议加解密前需要对数据进行完整性校验，HTTP/2 中如果TCP 出现丢包，TLS 也会因接收到的数据不完整而无法对其进行处理，也即HTTP/2 中的TLS 协议层也存在队头阻塞问题。
既然TLS 协议是因为接收数据不完整引起的阻塞，我们只需要让TLS 加密认证过程基于一个独立的Packet，不对多个Packet 同时进行加密认证，就能解决TLS 协议层出现的队头阻塞问题，某一个Packet 丢失只会影响封装该Packet 的Record，不会让其它Record 陷入阻塞等待的情况。
22、网络切换
每个网络都有唯一的标识用来辨识不同的连接，TCP使用<Suorce IP, Source Port, Target IP, Target Port>四个信息共同标识。在移动网络中，比如LTE 和WIFI 之间切换，那么Suorce IP, Source Port就会响应切换，四个信息中的任何一个改变，都相当于TCP 连接标识改变了，也就变成了不同的连接。TCP 需要先断开旧的连接再建立新的连接，很显然连接切换或迁移过程不够顺畅高效。
QUIC解决了这一问题，QUIC 数据包结构中有一个Connection ID 字段专门标识连接，Connection ID 是一个64位的通用唯一标识UUID (Universally Unique IDentifier)。借助Connection ID，QUIC 的连接不再绑定IP 与 Port 信息，即便因为网络迁移或切换导致Source IP 和Source Port 发生变化，只要Connection ID 不变就仍是同一个连接，协议层只需要将控制块中记录的Source IP 和Source Port 信息更新即可，不需要像TCP 那样先断开连接，这就可以保证连接的顺畅迁移或切换，用户基本不会感知到连接切换过程。
23、QUIC目前的使用情况
| 公司 | 产品 | 实现方式 | 成熟度 | 支持终端平台 | 应用落地 | 收益 | 是否开源 | 备注 |
|---|---|---|---|---|---|---|---|---|
| gQUIC | QUIC发起者C/C++实现，位于Chromium内核 | 高 | Android/iOS | Chrome/Youtube等广泛落地Google 50%+的请求来自QUIC，Youtube有20%的流量来自QUIC | Google搜索延迟降低2% YouTube缓冲时间减少9% | 是 | 2019 年 2 月开始，Google 在其服务及 Chrome 中使用的 QUIC 方案逐渐靠近iQUIC | |
| Microsoft | MsQUIC | 自研，C语言实现，Windows内核集成 | 中 | Windows | Microsoft 365/.NET Core等 | 暂未得到明确数据 | 是 | |
| mvfst | 自研mvfst集成至Proxygen Mobile（Facebook的移动端网络框架） | 高 | Android/iOS | Facebook/Instagram等Facebook 75%网络流量使用QUIC | 用户请求错误率下降6%；尾延迟降低20%；视频卡顿率降低了 20% | 是 | 静态内容请求上存在问题，请求性能反而变差，所以目前没有在静态内容上应用 | |
| 阿里巴巴 | XQUIC | 早期基于Chromium二次开发，现自研 | 高 | Android/iOS | 手淘广泛落地RPC请求/直播/短视频等多个业务场景 | 在RPC请求场景，网络耗时降低15%； 在直播高峰期场景，卡顿率降低30%、秒开率提升2%；在短视频场景，卡顿率降低20% | 否宣称2020年底开源 | 需要大量裁剪才能勉强集成，在版本升级情况下难以持续迭代，因此自研 |
| 腾讯 | TQUIC | nginx+Chromium | 高 | Android/iOS | X5内核支持QQ空间/腾讯视频/腾讯云CLB等落地 | 空间首页加载速度提升10%，组件下载速率提升20%；会员页单个请求提升22%； 视频启动播放时间降低10% | 否 | 2018年的早期版本基于Chromium，目前维护状态，2020开始自研 |
| 美团 | MQUIC | 早期基于Chromium二次开发，现自研 | 低 | Android/iOS | RPC请求/直播 | 实验室弱网场景, 端到端延时降低20% | 否 | |
| 哔哩哔哩 | bvc-quic-server | 基于Chromium搭建quic-server | 低 | Android/iOS（仅webview环境） | B站点直播视频下行 | 视频首帧提升10%； 视频卡顿率降低5% | 否 | 移动端QUIC还在开发，目前要用内核支持QUIC的Web端观看B站视频 |
| 快手 | KQUIC | nginx+Chromium | 中 | Android/iOS | 快手全站全量上线 | 传输耗时平均降低 10% 以上； 服务端最大 QPS 提升 50% | 否 | 目前完全是独立的一套，演进成本较高 |
五层网络模型
应用层 HTTP、FTP
传输层 TCP、UDP、QUIC
网络层 IP
数据链路层 帧传递、纠错机制确保可靠传输
物理层 比特传输、网口、光纤规范
附录： www.cloudflare.com/zh-cn/learn…
nolaaaaa.github.io/2019/04/11/…
