##网络技术概览
###第1章：延迟与带宽
###第2章：TPC的构成
性能检查清单
把服务器内核升级到最新版本
确保cwnd大小为10
禁用空闲后的慢启动
确保启动窗口缩放
减少传输冗余数据
压缩要传输的数据
把服务器放到离用户近的地方以减少往返时间
尽最大可能重用已经建立的TCP连接
###第3章：UDP的构成
针对UDP的优化建议
应用程序必须容忍各种因特网路径条件
应用程序应该控制传输速度
应用程序应该对所有流量进行拥塞控制
应用程序应该使用与TCP相近的带宽
应用程序应该准备基于丢包的重发计数器
应用程序应该不发送大于路径MTU的数据报
应用程序应该处理数据包丢失、重复和重排
应用程序应该足够稳定以支持2分钟以上的交付延迟
应用程序应该支持IPv4 UDP 校验和，必须支持IPv6校验和
应用程序可以在需要时使用keep-alive（最小间隔15s）
WebRTC满足上述要求:)
###第4章：传输层安全（TLS）
TLS协议是SSL协议的升级版
TLS协议的目标是为在它之上运行的应用提供三个基本服务：加密，身份验证和数据完整性。
加密：混淆数据的机制
身份验证：验证身份标识有效性的机制
完整性：检测消息是否被篡改或伪造的机制
TLS连接在TCP连接基础上多两个连接，服务器向客户端提供它的公钥，客户端生成对称密钥并使用服务器的公钥对其加密，然后再将加密的对称密钥返回服务器。服务器继而用自己的私钥解密出客户端发来的对称密钥，验证MAC(消息认证码）。接下来，客户端与服务器间的通信就全部都使用客户端生成的共享密钥加密，这就是对称密钥加密。公钥加密系统只建立在TLS信道的会话当中。
信任链与证书颁发机构
张三与李四之间的认证：
张三和李四分别生成自己的公钥和私钥
张三和李四分别隐藏自己的私钥
张三向李四公开自己的公钥，李四也向张三公开自己的公钥
张三向李四发送一条新消息，并用自己的私钥签名
李四使用张三的公钥验证收到的消息签名。
张三未见过王五，但王五用李四的私钥签署了自己的公钥，并在消息中附上了签名，这样形成了信任链。
性能检查清单
要最大限度提升TCP性能
把TLS库升级到最新版本，在此基础上构建（或重新构建）服务器
启动并配置会话缓存和无状态恢复
监控会话缓存的使用情况并作出相应调整
在接近用户的地方完成TLS会话，尽量减少往返延迟
配置TLS记录大小，使其恰好能封装在一个TLS段内
确保证书链不会超过拥塞窗口的大小
从信任链中去掉不必要的证书，减少链条层次
禁用服务器的TLS压缩功能
启动服务器对SNI的支持
启动服务器的OCSP封套功能
追加HTTP严格传输安全首部。
##无线网络性能
###第5章：无线网络概论
影响无线网络性能的因素
收发端的距离
当前位置的背景噪音大小
来自同一网络（小区）其他用户的干扰大小
来自相邻网络（小区）其他用户的干扰大小
两端发射功率大小
处理能力及调制算法
###第6章：Wi-Fi
###第7章：移动网络
###第8章：移动网络的优化建议
1、节约用电
全功率打开无线电模块只消几个小时就可耗尽电量
对无线电功率的需求随着无线标准演进与代剧增
无线电模块的耗电量仅次于设备的屏幕
数据传输时无线电通信的耗电过程是非线性的。
2、消除周期性及无效的数据传输
轮询在移动网络中的代价极高，少用
尽可能使用推送和通知
出站和入站请求应该合并和汇总
非关键性请求应该推迟到无线模块活动时进行
（消除不必要的长连接）
3、预测网络延迟上限
考虑RRC状态切换
解耦用户交互与网络通信
4、面对多网络接口并存的现实
不要缓存或试图猜测网络状态
调度请求、监听并诊断错误
瞬态错误总会发生，不可忽视，可以采取重试策略
监听连接状态，以便采用最佳请求方式
对重试请求采用补偿算法，不要永远循环
离线时，进可能记录并在将来发送请求
利用HTML5的AppCache和localStorage实现离线应用
5、爆发传输数据并转为空闲
如果需要大型音频或视频文件，考虑提前下载整个文件，而不要以比特为单位地流式下载
预先取得应用内容，通过测量和统计工具来辨别什么内容适合提前下载
预先取得第三方内容，比如广告，通过应用逻辑提前显示并更新它们的状态。
允许设备关闭无线模块，保持其空闲，不要忘了优化和消除间歇性传输。
6、把负载转移到Wi-Fi网络
##第三部分：HTTP
###第9章：HTTP简史
###第10章：Web性能要点
性能来源：计算、渲染和网络访问
更多带宽其实不太重要
延迟是性能瓶颈
针对浏览器的优化建议
基于文档的优化：熟悉网络协议，了解文档、Css和JS解析管道，发现和优先安排关键网络资源，尽早分派请求并取得页面，使其尽快达到可交互的状态。主要方法是优先获取资源、提前解析
推测性能优化：浏览器可以学习用户的导航模式，执行推测性优化，尝试预测用户的下一次操作。然后，预先解析DNS、预先连接可能的目标
以上浏览器已经自动完成，主要利用以下4种技术
资源预取和排定优先次序：文档、Css和Js解析器可以与网络协议层沟通，声明每种资源的优先级：初始渲染必需的阻塞资源具有最高优先级，而低优先级的请求可能会被临时保存在队列中。
DNS预解析：对可能的域名进行提前解析，避免将来HTTP请求时的DNS延迟。预解析可以通过学习导航历史、用户的鼠标悬停，或其他页面信号来触发。
TCP预连接：DNS解析后，浏览器可以根据预测的HTTP请求，推测性地打开TCP连接。如果猜对的话，则可以节省一次完整的往返（TCP握手）时间。
页面预渲染：某些浏览器可以让我们提示下一个可能的目标，从而在隐藏的标签页中预先渲染整个页面。这样，当用户真的触发导航时，就能立即切换过来。
<link refl="dns-prefetch" href="//hostname_to_resolve.com">//预解析特定域名
<link refl="subresource" href="/javascript/myapp.js">//预取得页面后面要用到的关键性资源
<link refl="prefetch" href="/images/big.jpg">//预取得将来导航要用的资源
<link refl="prefetch" href="//example.org/next_page.html">//根据对用户下一个目标的预测，预渲染特定页面。
###第11章：HTTP 1.x
###第12章：HTTP 2.0
设计和技术目标
1、二进制分帧层
HTTP 1.x以换行符作为纯文本的分隔符，而HTTP2.0将所有传输的信息分割为更小的消息和帧，并对它们采用二级制格式编码。
2、流、消息和帧
流：已建立的连接上的双向字节流
消息：与逻辑消息对应的完整的一系列数据帧
帧：HTTP2.0通信的最小单位，每个帧包含首部，至少也会标识出当前帧所属的流。
所有HTTP2.0通信都在一个连接上完成，这个链接可以承载任意数量的双向数据流，相应地，每个数据流以消息的形式发送，而消息由一个或多个帧组成，这些帧可以乱序发送，然后再根据每个首部的流标识符重新组装。
所有通信都在一个TCP连接完成
流时连接中的一个虚拟信道，可以承载双向的消息；每个流都有一个唯一的整数标识符（1、2……N）
消息是指逻辑上的HTTP消息，比如请求，响应等，由一个或多个帧组成
帧是通信的最小单位，承载着特定类型的数据，如HTTP头部、负荷等等。
3、多向请求与数据
把HTTP消息分解为独立的帧，交错发送，然后在另一端重新组装。
好处：
可以并行交错地发送请求，请求之间互不影响。
可以并行交错地发送响应，响应之间互不干扰
只使用一个连接即可并行发送多个请求和响应
消除不必要的延迟，从而减少叶面加载的时间
不必再为绕过HTTP1.x限制而多做工作。
4、请求优先级
提供了一种赋予数据优先级的机制，而且要求客户端与服务器必须能够交换这些数据。
5、每个来源一个连接
好处：
所有数据流的优先次序始终如一；
压缩上下文单一使得压缩效果更好
由于TCP连接减少而使网络拥塞状况得以改观
慢启动时间减少，拥塞和丢包恢复速度更快。
6、流量控制
流量控制基于每一跳进行，而非端到端的控制
流量控制基于窗口更新帧进行，即接收方广播自己准备接受某个数据流的多少字节，以及对整个连接要接受多少字节。
流量控制窗口大小通过WINDOW_UPDATE帧更新，整个字段指定了流ID和窗口大小递增值
流量控制有方向性，即接收方可能根据自己的情况为每个流乃至只能整个连接设置任意窗口大小。
流量控制可以由接收方禁用，包括针对个别的流和针对整个连接。
7、服务器推送
好处：
客户端可以缓存推送过来的资源
客户端可以拒绝推送过来的资源
推送资源可以由不同的页面共享
服务器可以按照优先级推送资源
8、首部压缩
HTTP2.0在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对，对于相同的数据，不再通过每次请求和响应发送。
首部表在HTTP2.0的连接存续期内始终存在，由客户端和服务器共同渐进地更新
每个新的首部键-值对要么别追加到当前表的末尾，要么替换表中之前的值。
9、有效的HTTP2.0升级与发现。
###第13章：优化应用的交付
1、在客户端缓存资源
2、压缩传输的数据
3、消除不必要的请求字节
4、并行处理请求和响应
针对HTTP2.0的优化建议
1、去掉对1.x的优化
2、双协议应用策略
几种情况：
相同的应用代码，双协议部署
分离应用代码，双协议部署
动态HTTP1.x和HTTP2.0优化
HTTP2.0单情况部署
3、1.x与2.0的相互转换
基础设施标准：
负载均衡器、代理及应用的连接应该持久化
请求和响应流及多路复用应该是默认配置
与应用服务器的通信应该基于消息
客户端与应用服务器的通信应该是双向的
4、评估服务器质量与性能
5、2.0与TLS
6、负载均衡器、代理及应用服务器
##第四部分：浏览器API与协议
###第14章：浏览器网络概述
高层浏览器网络API、协议和服务
连接管理与优化
套接字是以池的形式进行管理的，即按照来源，每个池都有自己的连接限制和安全约束。自动化的套接字池管理会自动重用TCP连接
好处：
浏览器可以按照优先次序发送排队的请求
浏览器可以重用套接字以最小化延迟并提升吞吐量。
浏览器可以预测请求提前打开套接字
浏览器可以优化何时关闭空闲套接字
浏览器可以优化分配给所有套接字的带宽
网络安全与沙箱
连接限制：
请求格式化与响应处理
TLS协商
同源策略（涉及对DOM访问，cookie和会话状态管理、网络及其他浏览器组件的限制）
资源与客户端状态缓存
浏览器针对每个资源自动执行缓存指令
浏览器会尽可能恢复失效资源的有效性
浏览器会自动管理缓存大小及资源回收
应用API与协议
###第15章：XMLHTTpRequest
###第16章：服务器发送事件
Server-Sent Events（SSE），让服务器可以向客户端流式发送文本消息（单向，客户端不能发送）。设计了两个组件：浏览器中的EventSource和新的”事件流”数据格式。
通过一个长连接延迟交付
高效的浏览器消息解析，不会出现无限缓冲
自动跟踪最后看到的消息及自动重新连接
消息通知在客户端以DOM事件形式呈现
SSE提供的是一个高效、跨浏览器的XHR流实现，消息交付只使用一个长HTTP连接
###第17章：WebSocket
服务包括：
连接协商和同源策略
与既有HTTP基础设施的互操作
基于消息的通信和高效消息分帧
子协议协商及可扩展能力
WebSocket资源URL采用了自定义模式：ws表示纯文本通信，wss表示使用加密信道通信。
WebSocket协议包含两个高层组件：开放性HTTP握手协商连接参数、二进制消息分帧机制用于支持低开销的基于消息的文本和二进制数据传输。
WebSocket不支持多路复用，会有队首阻塞的情况。
唯一一个能通过同一个TCP连接实现双向通信的机制。
性能检查表
使用安全WebSocket（基于TLS的WSS）实现可靠的部署
密切关注腻子脚本的性能
利用自协议协商确定应用协议
优化二进制净荷以最小化传输数据
考虑压缩UTF-8内容以最小化传输数据
设置正确的二进制类型以接收二进制净荷
监控客户端缓冲数据的量
切分应用消息以避免队首阻塞
合用的情况下利用其它传输机制
###第18章：WebRTC
Web Real-Time Communication，用于实现浏览器之间（端到端）的音频、视频及数据共享。
能力：
MediaStream：获取音频和视频流
RTCPeerConnection：音频和视频数据通信
RTCDataChannel：任意应用数据通信
WebRTC通过UDP传输数据。
WebRTC的音频和视频引擎
通过getUserMedia获取音频和视频
mediaStream对象是实现这个功能的主要接口
MediaStream对象表示一个实时的媒体流，以便应用代码从中取得数据，操作个别的Track和控制输出
MediaStream对象包含一或多个Track（MediaStreamTrack）
MediaStream中的多个Track相互之间是同步的
输入源可以使物理设备，如麦克风、摄像头、用户硬盘或另一端远程服务器中的文件
MediaStream的输出可以被发送到一或多个目的地：本地的视频或音频元素、后期处理的Js代理，或者远程的另一端。
getUserMedia() API是从底层平台取得音频和视频流的简单API，通过它还可以指定一系列强制和可选的约束条件，以匹配应用的需求。
WebRTC 使用UDP作为传输层协议：低延时和及时性。
ICE、STUN、和TURN是通过UDP建立并维护端到端连接所必需的。DTLS用于保障传输数据的安全，SCTP和SRTP属于应用层协议，用于在UDP之上提供不同流的多路复用，拥塞和流量控制，以及部分可靠的交付和其他服务。
RTCPeerConnection API
interface represents a WebRTC connection and handles efficient streaming of data between two peers.负责维护每一个端到端连接的完整生命周期
管理穿越NAT的完整ICE工作流
发送自动（STUN）持久化信号
跟踪本地流
跟踪远程流
按需触发自动流协商
提供必要的API，以生成连接提议，接收应答，允许我们查询连接的当前状态
DataChannel API 用于实现端到端之间的任意应用数据交换。可以通过配置提供以下特征:
发送消息可靠或部分可靠的交付
发送消息有序或乱序交付
不可靠的乱序交互等同于原始UDP
端到端的连接
发送通知和协商会话： WebRTC应用可以选择已有的任何发信协议和网关，利用既有通信系统协商一次通话或视频会议。
会话描述协议（SDP）： WebRTC使用SDP描述端到端连接的参数，不包含媒体本身的任何信息，仅用于描述”会话状态”，表现为一系列连接属性：要交换的媒体类型（音频、视频及应用数据）、网络传输协议、使用的编解码器及其设置、带宽及其他元数据
过程：
1、发起方通过本地RTCPeerConnection注册一或多个流，创建提议offer，并将其设置为会话的“本地描述”：setLocalDescription。
2、把生成的会话发送给接收方
3、接收方把发送方发来的描述设置为会话的“远程描述”，setRemoteDescription，使用自己的RTCPeerConnection对象注册自己的流，生成应答的SDP描述，并将其为会话的“本地描述”。
4、接收方把会话应答回传给之前的发送方
5、之前的发送方接到SDP应答之后，再把这个应答设置为原始会话的“远程描述”
交互连接建立（iCE）：
每个RTCPeerConnection连接对象都包含一个“ICE代理”
ICE代理负责收集IP地址和端口（candidate）
ICE代理负责执行两端的连接检查
ICE代理负责发送连接持久化信息
设置好会话描述后，本地ICE代理会自动开始发现本地端所有可能的候选IP和端口进程。
ICE代理向操作系统查询本地IP地址
如果有配置，ICE代理会查询外部STUN服务器，以取得本地端的公共IP和端口号
如果有配置，ICE代理会将TURN服务器追加为最后一个候选项，假如端到端的连接失败，数据将通过指定的中间设备转发。
跟踪ICE收集和连接状态
内置的ICE框架负责选项发现、连接检查、持久化等等。
iceConnectionState属性中保存这端到端的连接状态，这个属性有可能有7个值：new、checking、connected、completed、failed、disconnected、closed。
发送过程：初始端连接和发送通道，取得并注册媒体流，发送提议，递增提交ICE候选项，最后再输出取得的媒体流。
接受过程：初始化端连接，取得并注册媒体流，发送应答，增量提交ICE候选项，最后取得的媒体流。
交付媒体和应用数据
DTLS:数据报传输层安全，用于加密传输应用数据时针对要传输的媒体数据协商加密。与TLS设计一致，本质是TLS，但为了兼容UDP数据报传输而做了微小修改。
SRTP：安全实时传输，专门传输媒体数据用于传输音频和视频流，通过SRTP和SRTCP交付媒体
上图的构架无法直接控制媒体如何优化以及如何交付给另一端，浏览器会做这个事
不用关心提供的媒体流的品质和大小，网络组件会实现自己的流和拥塞控制算法，让每个连接开始时的比特率保持较低，然后再根据带宽调整流的品质
在连接的生命周期中，浏览器中的媒体和网络引擎会动态调整流的品质，以适应不断变化的网络环境，比如带宽波动、丢包、网络抖动，等等。换句话说，WebRTC会生成自适应的比特流。
SRTP本身并不对传输数据的及时性、可靠性或数据恢复提供任何保证机制，它只负责把数字化的音频采样和视频帧用一些元数据封装起来，以辅助接收方处理这些流。
SRTP分组中包含了媒体引擎实时回放流所需的全部信息。而控制SRTP分组交付则是SRTCP协议的责任，它针对每个媒体流实现了独立的外部反馈渠道。它会跟踪发送及丢失字节和分组的数量，跟踪SRTP统计信息。它们共同完成对应用提供的音频和视频流的实时适配和优化。
SCTP：流控制传输协议，用于传输应用数据。通过DataChannel API在端到端直接传输任意应用数据。
SCTP同时具备TCP和UDP中最好的功能：面向消息的API、可配置的可靠性及交付语义，内置流量和拥塞控制机制。
DataChannel
DataChannel 支持端到端的任意应用数据交换。
DataChannel API有意照搬Websocket，但有一些重要的差别。
与WebSocket构造函数不同，它需要传入WebSocket服务器的URL，而DataChannel只是RTCPeerConnection对象的一个工厂方法
与WebSocket不同，任何一端都可以初始新的DataChannel会话，会话建立后就会触发onDataChannel回调
与WebSocket不同，它运行在可靠有序的TCP协议之上，而每个DataChannel都可以经过配置，实现自定义的交付和可靠性。
配置消息次序和可靠性：每个信道配置部分可靠性提供了两种选择
通过重传实现部分可靠支付：消息的重传次数由应用指定
通过超时实现部分可靠支付：消息的重传间隔（ms）由应用指定。
性能检查表
发信服务
使用低延迟传输机制
提供足够的容量
建立连接后，考虑使用DataChannel发信
防火墙和NAT穿越
初始化RTCPeerConnection时提供STUN服务器
尽可能使用增量ICE，虽然发信次数多，但建立连接速度快
提供STUN服务器，以备端到端连接失败后转发数据
预计并保证TURN转发时容量够用
数据分发
对于大型多方通信，考虑使用超级节点或专用的中间设备
中间设备在转发数据前，考虑对其进行优化或压缩。
数据效率
对音频和视频指定适当的媒体约束
优化通过DataChannel发送的二进制净荷
考虑压缩通过DataChannel发送的UTF-8数据
监控DataChannel缓冲数据的来量，同时注意适应网络条件变化
交付及可靠性
使用乱序交付避免队首阻塞
如果使用有序交付，把消息大小控制到最小，以降低对手阻塞的影响。
发送小消息（< 1150字节）,以便将分段应用信息造成的丢包损失将至最低
对部分可靠交付，设置适当的重传次数和超时间隔；“正确的”设置取决于消息大小、应用数据类型和端与端之间的延迟。