12bet,的读书笔记

第1章:延迟与带宽

banwidth and lantency

1.1 速度是关键

  • 网站越快,用户的黏度越高
  • 网站越快,用户忠诚度更高
  • 网站越快,用户转化率越高

关键:提高速度

两点:12bet,延迟与带宽

1.2 延迟的构成

  • 12bet,传播延迟:信号传播距离和速度决定
  • 12博体育,传输延迟:消息长度和链路速率决定
  • 处理延迟:处理分组首部,检查位错误及确定分组目标的时间
  • 排队延迟:到来的分组排队等待处理的时间

1.3-1.7

  • 12bet,信息的传播速度是光速,但是不同材料会降低光的传播速度,但是依然会很快,主要延时在于每一跳的寻路,处理,排队和传输的延时。
  • CDN将内容分布式部署到全球各地,让用户从最近的服务器加载内容(几乎都是一跳),大幅度降低延时。
  • 延时的相当大的一部分在最后几公里,连接类型,12博体育,路由技术和部署方法不同,分组传输中的这前几跳往往要花几十毫秒的延时。
  • 12bet,通过WDM(波分复用)技术,光纤可以同时传输很多不同波长(信道)的光,一条光纤的总带宽等于每个信道的数据传输速率乘以可复用的信道数。

第2章:TCP的构成

2.1 三次握手

TCP handshake

TCP fast open:减少握手对网络总延时的影响

2.2 拥塞控制与控制

2.2.1 流量控制

flow control

TCP连接的每一方都要告知自己的接收窗口(rwnd),表示能够保存数据的缓冲区的空间大小(单位字节)。

流量控制实例

2.2.2 慢启动

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

慢启动

慢启动重启(SSR):连接空闲一段时间后重置拥塞窗口,SSR对于那些会突然出现空闲的长周期TCP连接(如HTTP的keep-alive连接)有很大影响

通过新TCP连接下载文件:

通过新连接下载文件示例

通过已有的TCP连接下载文件:

通过已有连接下载文件

2.2.3 拥塞预防

见2.2.2的图示,首先进行的是拥塞控制,如果路径中某个路由器已经拥塞了以至于必须采取删包措施。因此,必须调整窗口大小,避免造成更多的包丢失,从而保证网络畅通,这就是第二个阶段拥塞预防。

2.3-2.5

队首拥塞:如果第一个分组没有到达,那么后续分组必须保存在接收端的TCP缓冲区中,等待丢失的分组重发并到达接收端。

队首拥塞

大多数情况下TCP的瓶颈都是延时,而非带宽。

服务器配置优化:

  • 增大TCP的初始拥塞窗口:第一次往返就传输较多的数据,随后的速度提升明显加快
  • 慢启动重启:禁用,改善瞬时发送数据的长TCP连接的性能
  • 窗口缩放:启用,增大最大接收窗口的大小,让高延时的连接达到更好的吞吐量
  • TCP快速打开:某些情况下,允许在第一个SYN分组中发送应用数据(需要客户端和服务器共同支持)

应用优化:

  • 再快快不过什么都不发,能少发就少发(压缩/合并)
  • 我们不能让数据传输更快,但可以让传输距离更短(CDN)
  • 重用TCP连接是提升性能的关键(http: keep-alive)

第3章:UDP的构成

数据报:描述通过不可靠的服务传输的分组,既不保证送达,也不发送失败通知 分组:指代任何格式化的数据块

HTTP没有规定使用TCP,但是所有的HTTP实现都是使用TCP

但是WebRTC使用的是UDP

特点:

  • 不保证消息交付:不确认,部重传,无超时
  • 不保证交付顺序:不设置包序号,不重拍,不会发生队首阻塞
  • 不跟踪连接状态:不必建立连接或重启状态机
  • 不需要拥塞控制:不内置客户端或网络反馈机制

第4章:传输层安全(TLS)

SSL:Secure Socket Layer,安全套接字层 TLS:Transport Layer Security,传输层安全,SSL 3.0的规范化升级版

tls架构

4.1 加密,身份验证与完整性

  • 加密:混淆数据
  • 身份验证:验证身份标示的有效性
  • 完整性:检测消息是否被篡改或伪造

4.2 TLS握手

完整的握手过程 tls handshake

4.3 TLS会话恢复

简短的tls握手 short tls handshake

4.4-4.7

信任的证书来源

  • 手工指定证书:手工导入信任的证书
  • 证书颁发机构:共同信任的第三方
  • 浏览器和操作系统:内置的证书颁发机构的名单

证书撤销

CRL:证书撤销名单

问题:

  • 名单会随着要撤销的证书的增加而变长,每个客户端都要包含所有序列号的完整的名单
  • 无法更新刚刚被撤销的证书序列号,如果客户端先缓存了CRL,之后证书被撤销,那么到缓存过期之前,证书一直被视为有效

OCSP:在线证书状态协议,解决CRL的问题,一种实时检查证书状态的机制

问题:

  • 证书颁发机构必须实时查询
  • 证书颁发机构必须确保随时随地的访问
  • 客户端在进一步协商之前阻塞OCSP请求
  • 证书颁发机构知道客户端要访问哪个站点,因此实时查询会泄露用户隐私

TLS优化

  • 尽早握手:CDN,增加本地代理减少跳数和握手延时
  • 会话缓存与无状态恢复:SSL 2.0引入的会话标识符是TLS的会话缓存的基础
  • 调整TLS记录的大小:TLS记录会带上IP和TCP首部,小的纪录会造成浪费;如果记录太大,TLS层必须等所有TCP分组都到达才能解密数据,如果分组丢失,相应的TLS记录必须被缓存起来,这样会导致额外的延时,这种延时会使浏览器性能显著下降
  • 禁用TLS压缩:双重压缩(http也会压缩)会浪费服务器和客户端的CPU时间,而且暴露的安全漏洞也很严重
  • 证书链的长度:验证信任链需要浏览器遍历链条中的每个节点,从站点证书开始递归验证父证书,直到信任的根证书。
    • 减少中间证书颁发机构的数量
    • 不必包含根证书颁发机构。如果浏览器信任名单中没有该根证书,则说明它不被信任
    • 理想的证书应该在2kb或3kb左右
  • OCSP封套:服务器可以在证书链中包含证书颁发机构的OCSP响应,让浏览器跳过在线查询。把查询OCSP操作转移到服务器可以让服务器缓存签名的OCSP响应,从而节省很多客户端的请求
  • HTTP严格传输安全(HSTS):服务器加上首部(Strict-Transport-Sercurity: max-age=31536000)