Hight Performance Brower Networking

一：网络技术概览

延迟 = 传播延迟 + 传输延迟 + 处理延迟 + 排队延迟

目标：高带宽、低延迟

CDN: 通过将内容部署到离用户最近的地方，降低传播延迟

负责在不可靠的传输信道上提供可靠的抽象层，向应用层隐藏了大多数网络通信的复杂细节：丢包重发、按序发送、拥塞控制及避免、数据完整等。

三次握手：建立 TCP 连接 alt text

重用连接称为提升 TCP 性能的关键。

队首阻塞：应用层必须等待所有分组数据全都到达才能访问数据，底层的分组重发等问题都反应为延迟交付

服务器的TCP配置实践：

UDP 只增加4字段：源端口、目标端口、分组长度和校验和

所有消息的保证都交给应用层来控制

TLS 的目标：加密、身份验证、数据加密

alt text

密钥协商、身份认证（PKI）、消息分帧（MAC，判断消息的完整性和可靠性）

由于需要提供额外的信息，需要进行 TLS 握手来建立加密信道，协商内容包括：TLS版本、加密套件、验证证书

建立 TCP 连接
客户端发送规格说明：TLS版本、支持的加密套件列表、希望使用的TLS选项
服务器从客户端提供的加密套件中选择一个，再附上自己的整数，选择相同的TLS协议，将响应发送回客户端。作为可选项，服务器也可以发送请求，要求客户端提供证书及其他TLS扩展参数
在确定共同的版本和加密套件后，客户端提供自己的证书给服务器，然后客户端生成一个新的对称密钥，用服务器的公钥加密发送给服务器
服务器解密出客户端的对称密钥，通过MAC检测完整性后，返回给客户端加密的 Finished 消息
客户端利用之前生成的对称密钥解密这条消息，验证MAC，如果一切都正确，则开始发送应用数据

ALPN 应用层协议协商：在TLS握手时，协商应用层协议，在ClientHello消息中追加一个新的ProtocolNameList字段，用来包含客户端支持的协议

TLS会话恢复：在多个连接间共享协商后的安全密钥，利用协商好的会话标识符，来重用之前协商的会话数据

TODO

HTTP 历史：HTTP0.9 —> HTTP1.0(最佳实践和共用模式的RFC)—> 标准化的 HTTP1.1 —> HTTP2(改进传输性能) —> HTTP3

HTTP性能

HTTP1.1引入了大量性能优化的特性：

持久化连接以支持连接重用: 减少建立TCP连接的时间
分块传输编码以支持流式响应
请求管道(pipeline)以支持并行请求处理: 将请求的FIFO队列从客户端迁移到服务器，服务器可以在处理完第一次请求后，立即处理第二次请求（使用多线程，可以并发或并行来处理多个请求），消除发送请求和响应的等待时间
- 缺点：只能严格串行的返回响应，只有当一个响应到达后，才会传输下一个响应（谁先请求，谁先发送）
- 队头阻塞问题：CSS和HTML同时到达，先处理CSS请求，再处理HTML请求，CSS请求需要40ms，HTML请求需要20ms，但HTML请求也需要等待CSS请求的响应到达后才能开始发送
字节服务以支持 range-based 的资源请求
改进的更好的缓存机制