web性能权威指南

第一章 网络技术概述

很多在线公司的业绩已经证实

1.网站越快，用户的黏性越高

2.网站越快，用户忠诚度更高

3.网站越快，用户转化率越高

 

延迟：分组从信息发送到目的地所需的时间

带宽：逻辑或物理通信路劲最大的吞吐量

延迟的构成

1.传播延迟(消息欧星发送端到接收端需要的时间，是信息传播距离和速度的函数)

2.传输延迟(把消息中的所有比特转移到链路中需要的时间，是消息长度和链路速度的函数)

3.处理延迟

4.排队延迟(到来的分组排队等待处理的时间)

 

光在真空中是30W公里/秒，但是传播分组中的光钎折射率在1.4到1.6之间，折射率越低速度越快

路线	距离km	时间：光在真空中	时间：光在光钎中	光钎中的往返时间（RTT)
纽约到旧金山	4148	14ms	21ms	42ms
纽约到伦敦	5885	19ms	28ms	56ms
纽约到悉尼	15993	53ms	80ms	160ms
赤道周长	40075	133.7ms	200ms	400ms

很多时候延迟中相当大的一部分往往花在了最后几公里上，而不是在横跨大洋或大陆时产生的，这就是所谓的最后一公里问题

 

 

 

 

 

第二章 TCP的构成

TCP快速打开，在linux3.7以后的内核支持，可以减少页面加载10%--40%的时间

三次握手

拥塞预防和控制，早期的时候很多往返的数据包超过了最大时间间隔，于是相应的主机会在网络中制造越来越多的数据报副本，使得整个网络陷入瘫痪

TCP每个连接都有自己的接收窗口rwnd

1.   第一次建立连接时两端都会使用系统默认设置来发送rwnd
2.   如果是浏览网页下载图片可能客户端窗口会成为瓶颈，如果是上传图片则服务端窗口会成为瓶颈
3.   如果其中一端更不上数据传输，那它可以向发送端通告一个较小的窗口，假如窗口为0，意味着必须由应用层先清空缓冲区，才能再接收剩余数据。这个过程贯穿于每个TCP连接的整个生命周期，每个ACK分组都会携带相应的最新rwnd值，以便两端动态调整数据流速，使之适应发送端和接收端的容量及处理能力

窗口缩放

最初的通告窗口大小为16位，也就是最大只能发送65535字节，而TCP窗口缩放可以将这个值提高到1G

这个值是在三次握手中完成的，在linux中通过如下命令检查和启动

sysctl net.ipv4.tcp_window_scaling
sysctl -w net.ipv4.tcp_window_scaling=1

 

慢启动

虽然流量控制可以防止发送端向接收端发过多数据，但是如果在连接刚建立的时候谁也不知道可用带宽是多少，因此需要一个估算机制，然后还要根据网络中不断变化的条件来动态改变速度

服务器通过TCP连接初始化一个新的拥塞窗口cwnd变量，将其设置为一个系统设定的保守值(initcwnd)

拥塞窗口大小(cwnd)发送端对从客户端接收确认(ACK）之前可以发送数据量的限制

客户端和服务端可以传输数据量取决于rwnd和cwnd变量中最小值

拥塞窗口是发送方使用的流量控制

滑动窗口是接收方使用的流量控制

发送方最初可以发送4个TCP数据报，之后就必须停下来等待ACK的确认，确认后发送的数据报数量*2

而当出现丢包后则数据报数量/2

因为包括HTTP在内的很多应用层协议都运行在TCP之上，无论带宽多大，每个TCP连接都必须经过慢启动阶段，也就是说我们不可能一上来就完全利用连接的最大带宽。只能每次从一个较小的拥塞窗口开始，之后每次往返都令其翻倍，从而达到吞吐量所需的时间。

cwnd大小达到N所需的时间

时间=往返时间 * [ log2 (N/初始cwnd) ]

例子:

假设接收窗口为65535字节，往返时间56ms(伦敦到纽约)，初始拥塞窗口4个TCP数据报

要达到64K限制(接收窗口大小)需要45个数据报段

65535 / 1460 = 45

56ms * [ log2 (45/4) ] = 224ms

也就是经过了4次往返224ms后才能大搞最大限制，在RFC9828中规定起始的拥塞窗口限制为10个TCP数据报

对于很多HTTP连接特别是一些短暂的突发的连接而言，常常会出现还没有达到最大窗口请求就被终止的情况。很多WEB应用的性能经常受到服务器与客户端之间往返的制约。因为慢启动限制了可用的吞吐量，而这对于小文件传输非常不利。

 

TCP还有一个SSR(slow start restart)慢启动重启机制，在连接空闲一段时间后会重置连接的拥塞窗口，原因是在连接空闲的同时，网络状况也可能发生了变化，为了避免拥塞应该将拥塞窗口重置会安全的默认值

可以通过如下命令来检查和禁用SSR

sysctl net.ipv4.tcp_slow_start_after_idle
systcl -w net.ipv4.tcp_slow_start_after_idle=0

如果是连接池中的连接(也就是连接公用的情况下) 在减少三次握手和慢启动的限制条件下性能会有大幅度提升，也行会提高200%(对于延迟很大的场景来说)

而将cwnd(拥塞窗口)修改为10也能提供很多性能

 

预防拥塞

TCP Tahoe和Reno(最早的实现)

TCP Vegas，TCP New Reno，TCP BIC，TCP CUBIC(linux的默认实现)或Compound TCP(windows实现)

TCP比列降速如果太激进那么间歇性的丢包就会对整个连接的吞吐量造成很大影响，如果不够快则会继续造成更多分组丢失

最初TCP使用AIMD(Multiplicavie Decrease and Additive Increase)倍减加速算法，即发生丢包时先将拥塞窗口减半，然后每次往返再缓慢给窗口增加一个固定的值，但是这个算法太过保守

PRR(Proportional Rate Reduction)比列降速是RFC 6937规定的一个新算法，目标是改进丢包后的恢复速度。新的算法丢包后的平均连接延迟减少了3%--10%

BDP(bandwidth delay product 带宽延迟积)

数据连接的容量与其端到端延迟的乘积。这个结果就是任意时刻处于在途未确认状态的最大数据量

 

队首阻塞

TCP对于按序交付和可靠交付有时候并不必要，反而会导致额外的延迟

每个TCP分组都会带一个唯一的序列号被发出，而所有的分组必须按顺序传送到接收端。如果中途有一个分组没能达到接收端，那么后续分组必须在接收端的TCP缓冲区，等待丢失的分组重发并到达接收端。这些对于上层应用来说都是透明的，这种效应称为TCP的队首 （HOL head of line)阻塞

对于一些音频和视频类的游戏，如果丢包在中间插一个小小的间隔就可以继续处理后来的包了，用户也不会注意，而如果继续等待就会产生糟糕的用户体验

 

针对TCP的优化建议

TCP的优化还有很多，选择性应答(SACK)，延迟应答，快速转发等，但是核心原理以及他们的影响是不变的

1.TCP的三次握手增加了整整一次往返时间

2.TCP慢启动被应用到每个新连接中

3.TCP流量及拥塞控制会影响所有连接的吞吐量

4.TCP的吞吐量由当前拥塞窗口大小控制

 

服务配置调优(升级到最新的linux内核)

1.增大TCP的初始拥塞窗口

2.慢启动重启关闭

3.窗口缩放，增加到1G

4.TCP快速打开(在某些条件下允许在第一个SYN分组中发送应用程序数据)

 

应用程序行为调优

1.再块也快不过什么不用发送，能少发就少发

2.我们不能让数据传输的更快，但可以让他们传输的距离更短

3.重用TCP连接是提升性能的关键

4.压缩要传输的数据

 

linux用户可以使用ss来查看当前打开的套接字的各种统计信息

ss --options --extended --memory --process --info

 

 

 

 

 

第三章 UDP的构成

数据报：一个完成，独立的数据实体，携带着从源节点到目的节点的足够信息，对这些节点之间的数据交换和传输网络没有任何依赖

UDP是无协议，总结一下UDP的无服务

1.不保证消息交付，不确认不重传无超时

2.不保证交付顺序，不设置包序号不重拍不会发生队首阻塞

3.不跟踪连接状态，不必建立连接或重启状态机

4.不需要拥塞控制，不内置客户端或网络反馈机制

 

UDP与网络地址转换

为了解决IPv4地址耗尽的问题，出了一个临时解决方案(NAT network address translator)而这个方案却一直被沿用下来了

每个NAT设备维护一个表，表中包含本地IP和端口到全球唯一(外网)IP和端口的映射

由于UDP没有状态不像TCP那样设备可以跟踪连接状态，这样造成UDP数据报就算丢失也没法跟踪，有个最佳做法是引入一个双向的keep-alive分组，周期性的充值传输路径上所有NAT设备中转换记录的计时器

不可预测的连接状态处理是NAT设备带来的一个严重问题，很多UDP应用需要实现端到端的双向通讯

为了解决UDP和NAT的这种不搭配，出现了很多穿透技术TURN，STUN，ICE等

 

针对UPD的优化建议

UDP的特色在于它所省略的哪些功能：连接状态，握手，重发，重组，重排，拥塞控制，拥塞预防，流量控制，甚至可选的错误检查统统没有。你的应用程序可能需要从头实现上述几个或者大部分的功能，而每项功能都必须保证与网络中的其他主机和协议共存

单播的UPD应用程序建议

1.应用程序必须容忍各种网络路径条件

2.应用程序应该控制传输速度

3.应用程序应该对所有流量进行拥塞控制

4.应用程序应该使用与TCP相近的带宽

5.应用程序应该准备基于丢发的重发计数器

6.应用程序应该不发送大于路径MTU的数据报

7.应用程序应该处理数据报丢失，重复和重排

8.应用程序应该足够稳定以支持2分钟以上的交付延迟

9.应用程序应该支持IPv4 UDP校验和，必须支持IPv6校验和

10.应用程序可以在需要时使用keep-alive(最小间隔15秒)

WebRTC就是符合这些要求的框架

 

 

 

 

 

第四章 传输层安全(TLS)

TLS协议的目的是为在它之上运行的应用提供三个基本服务：加密，身份验证和数据完成完整性。

并不是所有情况下都要同时使用这三个服务

1.加密(混淆数据的机制)

2.身份验证(验证身份表示有效性的机制)

3.完整性(检测消息是否被篡改或伪造的机制)

 

TLS握手

在三次握手之后

1.客户端发送ClientHello

2.服务端收到后发送ServerHello，同时包含Certificate和ServerHelloDone

3.客户端收到后发送ClientKeyExchange和ChangeChiperSpec以及Finished

4.服务端收到后再返回ChangeCipherSpec以及Finished

5.客户端此时可以发送应用数据了

6.服务端接收数据也发送应用数据

由于性能原因，在握手的时候使用公钥加密，而真正传输的时候使用对称密钥加密

应用层可以通过HTTP发送upgrade首部，作为应用层协商

1.客户端在ClientHello消息中追加一个新的ProtocolNameList字段包含自己支持的应用协议

2.服务端检查ProtocolNameList字段，并在ServerHello消息中以ProtocolName段返回选中的协议

 

TLS会话恢复

由于每次握手会严重影响性能，所以上一次的会话可以继续保留到下次使用

服务端简单的记录一个ticket，会话记录保存在客户端然后由服务端的私钥来解密这些数据

 

信任链与证书颁发机构

我们使用浏览器的时候可以信任的方式有

1.手工指定证书

2.证书颁发机构

3.浏览器和操作系统

站点证书-->中间证书-->根证书颁发机构证书

 

针对TLS的优化建议

1.计算成本

2.尽早完成(握手)

3.会话缓存与无状态恢复

4.TLS记录大小

5.TLS压缩

6.证书链的长度

7.OCSP封套(Online Certificate Status Protocol在线证书状态协议)

8.HTTP严格传输安全(HSTS)

 

性能检测清单

1.要最大限制提升TCP性能可以参考TCP优化建议

2.把TLS库升级到最新版本，在此基础上构建(或重新构建)服务器

3.启用并配置会话缓存和无状态恢复

4.监控会话缓存的使用情况并作出相应调整

5.在接近用户的地方完成TLS会话，尽量减少往返延迟

6.配置TLS记录带新哦啊，使其恰好能封装在一个TCP段内

7.确保证书链不会超过拥塞窗口的大小

8.从信任链中去掉不必要的证书，减少链条层次

9.禁用服务器的TLS压缩功能

10.启动服务器对SNI的支持

11.启用服务器的OCSP封套功能

12.追加HTP严格传输安全首部

 

 

 

 

 

第五章 无线网络概述

第六章 Wi-Fi

第七章 移动网络

第八章 移动网络的优化和建议

 

 

 

 

 

第九章 HTTP简史

HTTP0.9只有一行的协议

1.客户端请求是一个ASCII字符串(运行在TCP/IP之上)

2.客户端请求由一个回车符(CRLF)结尾

3.服务器响应是一个ASCII字符流

4.服务器响应的是一种超文本标记语言(HTML)

5.连接在文档传输完毕后断开

 

HTTP1.0迅速发展及参考性RFC

1.请求可以由多行首部字段构成

2.响应对象前面添加了一个响应状态行

3.响应对象也有自己的由换行符分割的首部字段

4.响应对象不局限于超文本

5.服务器与客户端之间的连接在每次请求之后都会关闭

 

HTTP1.1互联网标志(主要是优化HTTP1.0的性能)

1.请求HTML文件，及其编码，字符集和元数据

2.对原始HTML请求的分块响应

3.以ASCII十六进制数字表示的分块数据的字节数

4.在同一个TCP连接上可以发送多次请求

5.最后通知服务端断开连接

 

HTTP2.0改进传输性能

主要是为了解决HTTP1.0中的很多问题，都是跟性能相关

HTTP2.0使用了二进制协议而不是纯文本了

 

 

 

 

 

第十章 Web性能要点

宏观的看Web性能优化

1.延迟和带宽对Web性能的影响

2.传输协议TCP对HTTP的限制

3.HTTP协议自身的功能和缺陷

4.Web应用的发展趋势及性能需求

5.浏览器局限性和优化思路

 

过去几十年的发展中给我们带来了三种体验：超文本文档，富媒体网页，交互式Web应用

2013年初一个普通的Web应用由下列内容构成

1.90个请求发送到15个主机，总下载量1311KB

2.HTML 10个请求，52KB

3.图片 55个请求，812KB

4.javascript 15个请求，216KB

5.CSS 5个请求，36KB

6.其他资源 5个请求， 195KB

随着时间的推移这些数字都会变得越来越大

有研究表明页面加载时间增加一秒，会导致转化率损失7%，页面浏览量减少11%，客户端满意度降低16%

 

分析Web性能自然要谈到资源瀑布，这是我们用来分析网络性能诊断网络问题的一个最有价值的工具，很多浏览器也内置了这样的工具

一个在线的工具 WebPageTest

每一个HTTP请求都由很多独立的阶段构成：

DNS解析，TCP连接握手，TLS协商(可选)，发送HTTP请求，下载内容

Web应用执行主要涉及三个任务：取得资源，页面布局和渲染，javascript执行

带宽相对来说并不重要，延迟才是性能瓶颈

 

人造和真实用户性能度量

模拟用户场景可能非常复杂

1、场景及页面选择：很难重复真实用户的导航模式

2.浏览器缓存：用户缓存不同，性能差别很大

3.中介设施：中间代理和缓存对性能影响很大

4.硬件多样化：不同的CPU，GPU和内存比比皆是

5.浏览器多样化：各种浏览器版本，有新有旧

6.上网方式：真实连接的带宽和延迟可能不断变化

W3C Web Performance Working Group通过引入Navigation Timing API为我们做真实用户测试提供便利

 

针对浏览器的优化建议

1.基于文档的优化(尽早分派请求并取得页面，如优先获取，提前解析等)

2.推测性优化(尝试预测用户的下一次操作，预解析DNS，预连接可能的目标等)

为了提升性能，大多数浏览器利用了如下四中技术

1.资源预取和排定优先次序

2.DNS预解析

3.TCP预连接

4.页面预渲染

//预解析特定的域名
<link rel="dns-prefetch" href="//hostname_to_resolve.com"

//预取得页面后要用到的关键性资源
<link rel="subresource" href="/javascript/myapp.js">

//预取得将来导航要用的资源
<link rel="prefetch" href="/image/big.jpeg">

//根据对用户下一个目标的预测，预渲染特定页面
<link rel="prerender" href="//example.org/next_page.html">

并非所有的浏览器都支持这些，如果不支持就会当做一个空操作，所以有益无害

 

 

 

 

 

第十一章 HTTP1.x

HTTP1.0的优化策略非常简单，升级到HTTP1.1就完了

HTTP1.1的一个重要目标就是为了增强性能

1.持久化连接以支持连接重用

2.分块传输编码以支持流式响应

3.请求管道以支持并行请求处理

4.字节服务以支持基于范围的资源请求

5.改进的更好的缓存机制

 

《高性能网站建设指南》中14条有一半是针对网络优化：

1.减少DNS查询

2.减少HTTP请求(任何请求都不如没有请求快)

3.使用CDN

4.添加Expires首部并配置ETag标签(在缓存时间未到之前优先使用浏览器本地缓存)

5.Gzip资源(一般来说Gzip可以减少60%--80%的资源)

6.避免HTTP重定向

 

持久连接的优先

1.没有持久连接，每次请求都会导致两次往返延迟

2.没有持久连接，只有第一次请求会导致两次往返延迟，后续请求只会导致一次往返延迟

3.在启用持久连接情况下，N次请求节省的总延迟就是(N-1）* RTT

HTTP1.1使用Connection: Keep-Alive支持持久连接

 

HTTP管道

消除了发送请求和响应的等待时间。这种并行处理的能力对提升应用性能的帮助非常之大

可以合并发送的请求，比如请求/html和/css可以合并成一个请求，服务器可以并行的处理这些请求，然后返回

假设客户端请求了/html和/css两个页面，服务端处理如下

1.HTML和CSS请求同时达到，但先处理的是HTML请求

2.服务器并行处理两个请求，其中处理HTML用时40ms，处理CSS用时20ms

3.CSS请求先处理完成，但被缓存起来以等候发送HTML响应

4.发送完HTML响应后，再发送服务器缓冲中的CSS响应

也就是说服务端只能串行的返回这些结果不能多路复用，管道的问题

1.一个慢响应就会阻塞所有后续请求

2.并行处理请求时，服务器必须缓冲管道中的响应，从而占用服务器资源，如果有个响应非常大，则很容易形成服务器的受攻击面

3.响应失败可能终止TCP连接，从页面强迫客户端重新发送对所有后续资源的请求导致重复处理

4.由于可能存在中间代理，因此检测管道兼容性，确保可靠性很重要

5.如果中间代理部支持管道，那它可能会中断连接，也可能会把所有请求串联起来

 

使用多个TCP连接

1.大多数浏览器支持每个主机打开6个连接，这样客户端可以并行分派6个请求

2.服务器可以并行处理最多6个请求

3.一次往返可以发送的积累分组数量(TCP cwnd)增长为原来的6倍

    这样做的代价

1.更多的socket会互赞用客户端，服务器以及代理的资源，包括内存缓冲区和CPU时钟周期

2.并行TCP流之间竞争共享的带宽

3.由于处理多个套接字，实现复杂性更高

4.即使并行TCP流，应用的并行能力也受限制

    使用这些的原因

1.作为绕过应用协议HTTP限制的一个权宜之计

2.作为绕过TCP中低起始拥塞窗口的一个权宜之计

3.作为让客户端绕过不能使用TCP窗口缩放的一个权宜之计

限制每个主机最多6个连接可以让浏览器检查出无意的Dos攻击，如果没有这个限制客户端可会消耗掉服务器的所有资源

 

域名区分

浏览器对于每个主机最多6个连接，但是一般主机会包含90个独立资源，可以将这些资源不熟到多个子域名上，如shard1.example.com，shard2.example.com等等

对于域名区分需要注意

1.首先优化好TCP

2.浏览器会自动为你打开6个链接

3.资源的数量，大小和响应时间都会影响最有的分区数目

4.客户端延迟和带宽会影响最有的分区数目

5.域名分区会因为额外的DNS查询和TCP慢启动而影响性能

域名分区是一种合理但又不完美的优化手段，一定要先从最小分区数目(不分区)开始，依次增加分区并度量分区后对应用的影响

DNS查询和TCP慢启动导致的额外消耗对高延迟客户端影响最大也是3G和4G

 

度量和控制协议开销

每个浏览器发送的HTTP请求都会携带额外500--800字节的HTTP元数据

用户代理字符串，很少改变的接收和传输首部，缓存指令等等

这还不包括最大的一部分HTTP cookie

额外的HTTP开销经常会超过实际传输的数据静荷

curl --trace-ascii - -d'{"msg":"hello"}' http://www.igvita.com/api

连接和拼合

1.连接(把多个javas和CSS文件组合为一个文件)

2.拼合(把多张图片组合为一个更大的复合图片)

这样做的好处是可以减少协议的开销，因为每次HTTP请求都会带有额外的数据

同时多个响应的数据前后相继地连接在一起，消除了额外的网络延迟，也就是把管道提高了一层置入应用层

计算图片和内存的需求，每次都合并成一个大图片这些图片会一直存在浏览器中会严重占用内存

对于这两种优化需要考虑如下情况

1.你的应用在下载很多小型的资源时是否会被阻塞

2.有选择的组合一些请求对你的应用有没有好处

3.放弃缓存粒度对用户有没有负面影响

4.组合图片是否会占用过多内存

5.首次渲染时是否会遭遇延迟执行

 

嵌入资源

嵌入资源是另一种非常流行的做法，把资源嵌入文档可以减少请求的次数比如javascript和css

<img src="data:image/gif;base64R0LG-DLHAQABAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=" alt="1*1 transparent(GIF) pixel"

嵌入javascript和css后文本会比之前增加33%，在是否考虑嵌入时，可以参考如下建议

1.如果文件很小而且只有个别页面使用，可以考虑嵌入

2.如果文件很小但需要在多个页面中重用，应该考虑集中打包

3.如果小文件经常需要更新，就不要嵌入了

4.通过减少HTTP cookie的大小将协议开销最小化

 

 

 

 

 

第十二章 HTTP2.0

HTTP2.0把很多以前我们针对HTTP1.1想出来的歪招一笔购销

HTTP2.0的目的就是通过支持请求与相应的多路复用来减少延迟，通过压缩HTTP首部字段将协议开销降至最低，同时增加对请求优先级和服务器端推送的支持。还有心的流量控制，错误处理和更新机制

HTTP2.0不会改动HTTP的语义。HTTP方法，状态码，URI及首部字段都不变 

HTTP2.0和SPDY是共同进化的，SPDY最早是谷歌搞出来的为了解决HTTP性能的，后来就变成HTTP2.0的实现标准，等SPDY退役的时候HTTP2.0就可以粉墨登场了

 

二进制分帧层

流       已建立的连接上的双向字节流

消息    与逻辑消息对应的完整的一系列数据帧

帧        HTTP2.0通信的最小单位，每个帧包含帧首部，至少也会标识出当前帧所属的流

每一个连接上可以多路复用N个流，每个流又包含若干个消息，如请求消息和响应消息，一个消息包含HEADERS帧和DATA帧

HTTP2.0的基本含义

1.所有的通讯都是在一个TCP连接上完成

2.流是连接中的一个虚拟信道，可以承载双向的消息，每个流都有一个唯一的整数标识符(1,2...N)

3.消息是指逻辑上的HTTP消息，比如请求，响应等，由一个或多个帧组成

4.帧是最小的通讯单位，承载着特定类型的数据，如HTTP首部，负荷等

 

把HTTP消息分解为独立的帧交错发送，然后在另一端重新组装是HTTP2.0最重要的一项增强，这个机制会在整个Web技术栈中引发一系列连锁反应

1.可以并行交错的发送请求，请求之间互不影响

2.可以并行交错的发送响应，响应之间互不干扰

3.只使用一个连接即可并行发送多个请求和响应

4.消除不必要的延迟，从而减少页面加载的时间

5.不必再为绕过HTTP1.x限制而做很多工作

每个流都可以带一个31比特的优先值

0表示最高优先级

2^31-1表示最低优先级

 

有了新分帧机制后HTTP2.0不再依赖多个TCP连接去实现多流并行了，每个来源一个连接显著减少了相关资源的占用，连接路径上的socket管理工作少了内存占用少了，连接吞吐量大了，此外从上到下所有层面上也获得了相应的好处

1.所有数据流的优先级次序始终如一

2.压缩上下文单一使得压缩效果更好

3.由于TCP连接减少而使网络拥塞状况得以改观

4.慢启动时间减少，拥塞和丢包恢复速度更快

每来源一个连接的坏处

1.虽然消除了HTTP队首阻塞现象，但是TCP层次上仍然存在队首阻塞

2.如果TCP窗口缩放被禁用欧冠，那么带宽延迟积效应可能会限制连接的吞吐量

3.丢包时，TCP拥塞窗口会缩小

 

在同一个TCP连接诶上传输多个数据流，就需要共享带宽，HTTP2.0为数据流和连接的流量控制提供了机制

1.流量控制基于每一跳进行，而非端到端的控制

2.流量控制基于窗口更新帧进行，即接收方广播自己准备接收某个数据流的多少字节，以及对整个连接要接收多少字节

3.流量控制窗口大小通过WINDOW_UPDATE帧更新，这个字节指定了流ID和窗口大小递增值

4.流量控制有方向性 ，即接收方可能根据自己的情况为每个流乃至整个连接设置任意窗口大小

5.流量控制可以由接收方禁用，包括针对个别的流和针对整个连接

 

HTTP2.0新增的一个强大功能室服务器可以对一个客户端请求发送多个响应，服务器可以额外向客户端推送资源

1.客户端可以缓存推送过来的资源

2.客户端可以拒绝推送过来的资源

3.推送资源可以由不同的页面共享

4.服务器可以按照优先级推送资源

 

HTTP1.1每次通讯都会携带一组首部，HTTP2.0会压缩首部元数据

1.HTTP2.0有一个首部表来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送

2.首部表在HTTP2.0的连接存续期内始终存在，由客户端和服务器共同渐进的更新

3.每个新的首部键值对要么被迫追到到当前表的末尾，要么替换表中之前的流

可以使用upgrade请求头来升级请求如果服务端不支持则退回HTTP1.1

//发送
GET /page HTTP/1.1
Host: server.example.com
Connection: Upgrage,HTTP2-Settings
Upgrade: HTTP/2.0
HTTP2-Settings: (SETTINGS payload)

//返回服务端拒绝升级，继续使用HTTP1.1
HTTP/1.1 200 OK
Content-length: 243
Content-type: text/html

//服务器接受HTTP.20升级，切换到新分帧
HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: HTTP/2.0

 

 

 

 

 

第十三章 优化应用的交付

无论什么网络也不管网络协议使用什么版本，所有应用都应该致力于消除或减少不必要的网络延迟，将需要传输的数据压缩至最少，这两条标志是景点的性能优化最佳实现

1.减少DNS查找

2.重用TCP连接

3.减少HTTP重定向

4.使用CDN(内容分发网络)

5.去掉不必要的资源

 

HTTP还提供了很多额外的机制

1.客户端缓存资源

    使用Cache-Control首部用于指定缓存时间，Last-Modified和ETag首部提供验证机制

     这样客户端直接使用本地副本不会发送连接

2.传输压缩过的内容

3.消除不吸烟的请求开销

    浏览器会在每个请求中自动附加关联的cookie数据

    在HTTP1.x中包括cookie在内的所有HTTP首部都会在不压缩的状态下传输

    在HTTP2.0中这些远数据经过压缩了，但开销依然不小

    最坏情况下过大的HTTP cookie会超过初始的TCP拥塞窗口从而导致多余的网络往返

4.并行处理请求和响应

    使用持久连接，从HTTP1.0升级到HTTP1.1

    利用多个HTTP1.1连接实现并行下载

    可能的情况下利用HTTP1.1管道

    考虑升级到HTTP2.0以提升性能

    确保服务器有足够的资源并行处理请求

 

针对HTTP1.x的优化建议

1.利用HTTP管道

2.采用域名分区

3.打包资源以减少HTTP请求

4.嵌入小资源

 

针对HTTP2.0的优化建议

1.服务器的初始化cwnd应该是10个分组

2.服务器应该通过ALPN(针对SPDY则为NPN)协商支持TLS

3.服务器应该支持TLS恢复以最小化握手延迟

4.去掉对1.x的优化

    每个来源一个连接

    去掉不必要的文件合并和图片拼接

    利用服务器推送

 

双协议应用策略

1.相同应用代码，双协议部署

2.分离应用代码，双协议部署

3.动态HTTP1.x和HTTP2.0优化

4.HTTP2.0单协议部署

 

 

 

 

 

第十四章 浏览器网络概述

来源(由应用协议，域名，端口三部分组成)

套接字池(属于同一个来源的一组套接字，所有浏览器的最大池规模是6个套接字) 

自动化的套接字池管理会自动重用TCP连接，从而有效保障性呢过，除此之外还有

1.浏览器可以按照优先次序发送排队的请求

2.浏览器可以重用套接字以最小化延迟并提升吞吐量

3.浏览器可以预测请求提前打开套接字

4.浏览器可以优化合适关闭空闲套接字

5.浏览器可以优化分配给所有套接字的带宽

 

网络安全与沙箱

1.连接限制

2.请求格式化与响应处理

3.TLS协商

4.同源策略

 

应用API与协议

XHR，SSE和WebSocket的高级特性(忽略了WebRTC因为那是一种端到端的交付模型和下面几个有根本不同)

	XMLHttpRequest	Server-Sent Event	WebSocket
请求流	否	否	是
响应流	受限	是	是
分帧机制	HTTP	事件流	二进制分帧
二进制传输机制	是	否(base64)	是
压缩	是	是	受限
应用传输协议	HTTP	HTTP	WebSocket
网络传输协议	TCP	TCP	TCP

XHR是客户端主动轮询服务端，然后服务端返回数据

SSE是客户端向服务端注册事件后服务端不断的推送消息

WebSocket是类似浏览器的socket，客户端和服务端都可以任意的发送数据

 

 

 

 

 

 

参考

HTTP2.0中文版

HTTP2.0百度百科

高性能浏览器网络（High Performance Browser Networking） 第一章

高性能浏览器网络（High Performance Browser Networking） 第二章

高性能浏览器网络（High Performance Browser Networking） 第三章

高性能浏览器网络（High Performance Browser Networking） 第四章