纯属个人笔记，整理包含一些自己的理解和资源
网络技术概览###
1. 延迟与带宽
- 考虑信息传播的路径
- 300ms内响应
- cdn从物理上缩短运输时间，也就是延迟
- 延迟中相当大的部分花在最后几公里(linux下采用tracerouter -I baidu.com 查看整个路径过程)
- 带宽
RTT (Round-Trip Time)
2.TCP的构成
Transmission Control Protocol ：负责在不可靠的传输信道上提供可靠的抽象层;
TCP三次握手：
TCP三次握手过程中交换了彼此的接收窗口rwnd（包含能够保存数据的缓冲区空间大小信息）
TCP窗口缩放：可设定窗口缩放最大值（原本: 65 535B）到1G
慢启动
拥塞窗口大小 cwnd：发送端对客户端接收确认(ACK)之前可以发送数据量的限
cwnd并不是交换发送得知的（因为交换只在握手的时候嘛），基本上靠猜: 算法
*所以说时间不仅浪费在三次握手的阶段，还有慢启动，所以如果可以维持建立状态的话，就会省掉不少时间 *
带宽延迟积（发送往返时间）
队首阻塞（HOP, Head of Line）
每个TCP分组都会带着一个唯一的序列号被发出，而所有分组必须按照顺序传送到接收端，如果中途有一个分组没能到达接收端，那么后序分组必须保存在接收端的TCP缓冲区，等待丢失的分组重发并到达接收端。应用程序并不知道这些，必须等到分组全部到达时才能访问数据。在此之前，应用程序只能在通过套接字读取数据时感觉到延迟交付。
综上，优化TCP性能list如下：
- 把服务器内核升级到最新版本
- 确保cwnd大小为10
- 禁用空闲后的慢启动
- 确保启动窗口缩放
- 减少传输冗余数据
- 压缩要传输的数据
- 把服务器放到离用户最近的地方以减少往返时间
- 尽最大可能重用已建立的TCP连接
** 3.UDP构成 **
UDP -- 无协议（暂时只看到说实时视频的时候会使用: UDP的使用 )
** NAT（network address translator）IP网络地址转换器 **
1994年因为IPv4地址快用完了，所以采用NAT这种ip重用方法。就内网ip和外网ip的东东了。
因为UDP包要包含源IP和目标IP，然后它自己和NAT都没有记录自己内网IP，所以需要STUN服务器来返回内网ip
由于很容易被防火墙拦截，所以可以使用TURN协议，切换到TCP
实际上最好使用的是ICE协议，能够自动判断出最有效的通道
优化看不是很懂，基本上基于UDP无协议的特点，也就是说不管包别人收到没有，一直发一直发的特点而做出类似TCP的一些算法，提到WebRTC符合优化要求的框架（也就是真爱的意思咯）
** 4.TLS 传输层安全 **
TLS的前身是SSL（secure sockets layer 安全套接字层）
TLS协议的目的是为在它之上运行的应用提供三个基本服务： 加密，身份验证和数据完整性
websocket、spdy之类的要使用https是因为要绕过中间代理，从而实现可靠的部署。。
TLS握手（在TCP握手后还要发送自己的信息过去，然后服务器发自己证书，客户端收到再发自己证书还有对称密钥，服务器发送finished，客户端验证然后建立信道发送数据）
SSL会话是可以重用的，也就是说后面的TLS连接可以重用第一个
TLS记录： 前面提到TCP万一中间出现丢包什么的，要把有的包先放进TCP缓存里面，这个时候就需要记住它们。
优化：
- 提升TCP性能
- 把TLS升级到最新版本库
- 启用并配置会话缓存和无状态恢复
- 监控会话缓存的使用情况并做出响应调整
- 配置TLS记录大小
- 确保证书链不会超过拥塞窗口大小
- 从信任链中去掉不必要的证书
- 禁用服务器TLS压缩功能
- 启用服务器对SNI支持
- 启用服务器OCSP封套功能
- 追加HTTP严格传输安全首部
无线网络性能##
** 5.无线网络概览 **
无线网络性能基础（带宽（c = BW * log2( 1 + S / N)），信号强度， 别人家的影响等等）
** 6.wifi（802.11）**
恩，复习CSMA ‘先听后说’ 之类的（当年老师上课该听不听==）
wifi性能(看不是很懂)
** 7.移动网络 **
各种知识科普(RRC)
在4G手机上打开浏览器，输入URL，发生了：
- 初始时手机处于空闲RRC状态，所以无线电模块必须与附近信号塔同步，然后发送一个请求，建立无线通信环境，需要几次往返，花费100ms
- 设备从信号塔得到相应资源，从而以特定速度与功率传输数据。用户数据从无线电模块传输到信号塔的时间成为用户面单向延迟，4G中花费5ms。实际上，由于切换RRC，第一个分组花的时间比较多，后面只要无线电模块保持高工率状态，后序分组的延迟时间都是恒定的。
- 分组通过核心网络从SGW传输到PGW
- 向外传播到公共互联网
- 浏览器获取内容，用户查看
- 此时无线电模块空闲十几秒，RRC切换到DRX状态，此时若用户重新触发新请求，除了第一步时时间会短一点，其他都是类似了。
数据返回路线：
- PGW把入站分组路由到SGW， SGW进一步查询MME
- 如果设备处于空闲，MME会向当前跟踪区内的所有信号塔发送一条寻呼消息
- 收到消息的信号塔接着通过共享的无线信道广播一条通知，告诉设备重建无线通信环境，以便接收数据
- 设备周期性地唤醒以监听寻呼消息，如果在寻呼列表里发现自己，就会向无线电信号塔发送一条协商请求，重新建立无线通信环境
- 环境建立后，负责协商的信号塔向MME发送一条信息，表示它正在为用户服务
- MME向服务网关返回一个应答，服务网关于是把数据路由到该信号塔
- 信号塔再把数据发送给目标设备
- 无线信号塔与网关会建立一条直通信号，使得后面的数据可以跳过2-5步.
** 延迟出现在**
- 控制面延迟（RRC状态切换 空闲 -> 启动 100ms 休眠 -> 启动 50ms）
- 用户面延迟（分组从设备到无线电信号塔之间的固定时间 >5ms）
- 核心网络延迟（从无线电信号塔到分组网关时间 30~100ms）
- 互联网路由延迟（从运营商分组网关到公共互联网上的目标地址所花时间，可变）
** 8.移动网络优化建议 **
普适建议：
- 节约用电（尽量在无线电开启时传输数据，尽量把唤醒无线电以传输数据的次数降到最低）
- 消除周期性及无效的数据传输（轮询在移动网络代价极高，少用；尽可能使用推送和通知；出站和入站请求应合并和汇总；非关键性请求应当推迟到无线模块活动时进行）
- 消除不必要的长连接
- 预测网络延迟上限
- 考虑RRC状态切换
- 解耦用户交互与网络通信
- 预先获取资源
HTTP##
** 9.HTTP简史 **
HTTP 0.9
- 客户端/服务器、请求/响应协议
- ASCII协议，运行与TCP/IP上
- 设计用来传输超文本文档(HTML)
- 服务器与客户端之间的连接在每次请求后都会关闭
HTTP 1.0
- 请求可以由多行首部字段构成
- 响应对象前面添加了一个响应状态行
- 响应对象也有自己的由换行符分割的首部字段
- 响应对象不局限于超文本
- 服务器与客户端之间的连接在每次请求之后都会关闭
HTTP 1.1
- 请求HTML文件及其编码、字符集和元数据
- 对原始HTML请求的分块响应
- 以ASCII十六禁止数字表示分块数据的字节数（256字节）
- 分块数据流响应结束
- 在同一个TCP连接上请求图标文件
- 通知服务器不再使用连接了
- 图标响应，随后关闭连接
*出现了TCP重用，可以在首部明确close还有编码，cookie等等等 *
个人关于HTTP是无状态连接的疑问获得的解答：
HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间
HTTP 2.0
主要目的时为了改善传输性能，实现低延迟和高吞吐量
** 10.web性能要点 **
web应用的执行主要涉及三个任务：取得资源、页面布局和渲染、js执行
各种api：Navigation Timing、User Timing、Resource Timing
浏览器所做的功夫：
- 资源预取和排定优先次序
- DNS预解析
- TCP预连接
- 页面预渲染（通过我们提示下一个可能目标）
我们能做：
优化页面结构（css头部，js尾部，非关键js推迟）
-
在文档中嵌入提示，以触发浏览器为我们采用的其他优化机制（非全面兼容）详情
<link rel="dns-prefetch" href="xxx"> <link rel="subresource" href="xxx"> <link rel="prefetch" href="xxx"> <link rel="prerender" href="xxx">
** 11.HTTP 1.x **
- 持久连接
- HTTP管道（单纯的持久连接还是FIFO，管道使并行成为可能， 虽然如此，每个资源还是要在前一个发送并接收之后才发送第二个（TCP队首阻塞）高级选项）
- 使用多个TCP连接（最多6个了， 减弱慢启动，但是会占用更多的客户端缓冲和带宽资源）
- 域名分区
- 度量和控制协议开销（cookie、 首部之类的）
- 连接和拼合
- 嵌入资源（data uri、内联css、js等）一般来说只考虑嵌入1~2kb以下的资源
** 12.HTTP 2.0 **
前身是SPDY
- 二进制分帧层（核心）
*流 *：已建立的连接上的双向字节流
消息：与逻辑消息对应的完整的一系列数据帧
帧：HTTP 2.0通信的最小单位，每个帧包含帧首部，至少也会标志出当前帧所属流
看图应该已经一目了然
- 多请求与多响应
请求优先级
0表最高优先级
2^31-1表最低优先级
- 每个来源一个连接(TCP连接已经变持久化了，慢启动时间减少，握手也不用握很多次了)
- 流量控制
- 服务器推送
- 首部压缩
13.优化应用的交付
两个原则：（1）消除或减少不必要的网络延迟；（2）将需要传输的数据压缩至最少
- 减少DNS查找
- 重用TCP连接
- 减少HTTP重定向
- 使用CDN
- 去掉不必要的资源
- 在客户端缓存资源
- 传输压缩过的内容
- 消除不必要的请求开销（比如说cookie）
- 并行处理请求和响应
- 针对协议版本采取优化措施
在客户端缓存资源
首部包含合适的缓存字段：Cache-Control ; Last-Modified和ETag
墙裂推荐Alloy Team关于浏览器缓存机制的一系列文章
消除不必要的请求字节
浏览器一半把cookie限制在4KB内;可以制定一个专门无需cookie的来源服务器，来交付那些不需要区分客户端的共用资源
专门针对HTTP 2.0来说，要忘记域名分区，文件拼接，图片精灵等不良习惯（==）
接下来讲HTTP 1.X与HTTP 2.0过渡的问题，没有记...
浏览器API与协议##
14.浏览器网络概述
15.XMLHttpRequest
CORS(这个时候是拿不到cookie和http认证的，必须要发送withCredentials)
XHR支持数据格式
- 接收: ArrayBuffer Blob Document JSON Text
- 发送：DOMString Document FormData Blob File以及ArrayBuffer
轮询
最简单轮询：setInterval
长轮询：每次都ajax请求，请求成功后 继续请求。。
16.服务器发送事件（好像很牛逼的样子~）
Server-Sent Event: 让服务器可以向客户端流式发送文本信息
具体使用阮一峰的博客可以看一看
** 17.websocket **
比较常见啦，聊天室什么的，贴一个 用socket.io与node.js实现聊天室的教程
18.WebRTC
Web Real-Time Communication(Web实时通信)：由一组标准、协议和js API组成，用于实现浏览器之间（端到端）的音频、视频及数据共享。
通过UDP传输
