第1页
阿里巴巴HTTP2实践及无 线通信协议的演进之路
阿里巴巴-移动平台 仲升(陈虓将)
第2页
更快、更省流量的标准通信
HTTP2
第3页
HTTP/2概况
Application(HTTP/2) Binary Framing
TLS SlightSSL
QUIC
TCP UDP
IP
• 二进制协议 • 流控
• 会话级别 &连接级别 • 双工通信&多路复用
• 主动下行 • 多个请求并发
POST /upload HTTP/1.1 Host:acs.m.taobao.com Content-Type:application/json
Content-Length:16 {“msg”,”taobao”}
HEADERS Frame DATA Frame
• 协议协商 • ALPN(TLS)或protocol upgrade(明文) • 连接序言
• 会话协商 • Settings Frame
• 头部压缩 • HPACK
第4页
HTTP/2 Frames
Bit 0 32 40 R …
帧格式 headers continuation
data rst_stream
settings ping
goaway window_update
0-7 Flags
8-15 Length
16-23
Stream Identifier Frame Payload
http/2的公共头部
用途 存放头部数据,用以打开一个stream
延续之前未发送完毕的包头信息 存放应用数据
异常关闭一个stream 参数协商
心跳包,用以刺探连接是否存活 发送端优雅关闭
流控,分为s tream和connectio n两 个级别
http/2的帧格式
24-31 Type
协商参数
含义
SETTINGS_HEADER_TABLE_SIZE
用于解压的头部动态压缩表最大 大小, 默认 409 6
SETTINGS_ENABLE_PUSH
用于禁止或启用服务端推送
SETTINGS_MAX_CONCURRE NT_STREAM S
最大并发流数,默认无限制
SETTINGS_INITIAL_WINDOW_SIZE
会话级别的流控的初始窗口大小 ,默认 为6 553 5
SETTINGS_MAX_FRAME_SIZE
帧的payload大小限制,默认为16384
SETTINGS_MAX_HEADER_LIST_ShIZttEp/2的SETTINGS帧压缩的前各头参部数列表的的含最义大大小,默 认无限 制
第5页
HTTP/2 Workflow
Client
Server
SYN
Settings Window_update
ACK 连接序言&会话协商
Headers Data
数据交互
FIN
PRI * HTTP/2\r\n\r\nSM\r\n\r\n init window size header table size
window increment size
init window size header table size window increment size
:method: get :path:/index.html
:status:200 :content-length= 1024
<!DOCTYPE html>… …
last stream id = 9
SYN ACK
会话协商 数据交互 会话关闭
Settings Window_update
Headers Data
Goaway
FIN ACK
第6页
HTTP/2 & HPACK
安全 DEFLATE压缩算法存在攻击风险
压缩率 通过新的算法得到进一步提升
http2 HPACK
映射表 经常出现或重复出现的Header用映射表的Index表示
静态Huffman编码 未命中映射表的Header用Huffman编码
第7页
HTTP/2的效果
单位:字节 1750 1400 1050 700 350 0
http/2
spdy
请求包头
应答包头
http/2请求和应答包头的流量下降
单位:毫秒
0 2G
http/2
spdy
3G 4G
http/2请求整体提速
WIFI
第8页
HTTP/2的优化过程
字节数 100%
百分比
1650 1100 550
52.4%
48.5%
35.3%
31.5% 50
0 spdy
下行huffman
0 动态表可协商
http2头部压缩分阶段优化
第9页
HTTP/2的实现
Nginx Patch
• 原生 • 上下行均支持静态表 • 上行支持动态表和Huffman编码 • 采用默认的动态表大小,无协商
• 扩展 • 下行动态表和Huffman编码 • 上下行动态表大小协商
无线下的调优
• 小包合并
• 连接序言/settings/headers合并成 一个TCP包
• 流控
• 会话级别下行流控
SDK支持
• 网络库SDK实现HTTP/2 • 复用网络库框架,统一上层接口 • 内部解析、封装HTTP/2
第10页
HTTP2的细节
• HPACK的动态表大小
• 上行和下行分别独立
• 均由服务端控制
• 通过控制SETTING ACK实现
• 适配两种场景
• 压缩率优先 调整至32K
• 内存优先
采用默认的4K
• HPACK动态表的更新
• 更新必须同步,否则会出错
• 请求封装完毕后必须发出
• HTTP2 VS SPDY
• 预置HPACK静态表
• 包大小
• HTTP2 40K
• SPDY 20K
• 场景选择
• PUSH场景
优选SPDY
• Req/Resp场景 优选HTTP2
• HPACK的延伸
• 统计常见字段出现的频度
• 自定义映射表,优化自定义协议
第11页
最新的压缩协议
Brotli
第12页
brotli vs gzip
性能
qps 100090,009
7,513
7,424
4,440
6,913
0 1
压缩 率
压缩率(out/in,%)
37.5
gzip brotli
30 30 27
22.5
26 24
177 11 压缩等级
7.5
0 1
26 23
实施
21 gzip brotli
热插拔式 accept-encoding:gzip,brotli
服务端控制 压缩格式自由选择,兼顾性能 和流量
11 压缩等级
效果(统计淘宝的某个大流量域名)
相对gzip节省17.5%的流量(315 字节)
第13页
无线互联网下的全站加密
SLIGHT SSL
第14页
HTTPS的挑战
Client
Server
SYN
600ms
ACK ClientHello
1800ms
ClientKeyExchange
ChangeCipherSpec Finished
3000ms
Application Data
4200ms 4800ms
0ms
SYN ACK
1200ms
ServerHello Certificate ServerHelloDone
2400ms
ChangeCipherSpec Finished
3600ms
Application Data
https complete handshake
• 特点 • 1张证书 • 4KB+ • 2-RTT的协商成本 • 加密数据前先协商会话密钥 • 3个随机数 • 两个明文,一个密文(pre master key)
• 挑战 • 流量放大攻击 • 证书下放导致上下行流量相差10倍+ • 网络时延大 • 在弱网下尤其是2g,时延不可接受(1RTT > 1S) • 硬件成本高 & 首次建连攻击 • https首次建连的性能是http的1/10
第15页
HTTPS的优化和不足
Client
Server
Client
Server
SYN 0ms
600ms
ACK ClientHello
1800ms
ClientKeyExchange ChangeCipherSpec
Finished
Application Data
3000ms
SYN ACK
1200ms
ServerHello Certificate ServerHelloDone
2400ms
ChangeCipherSpec Finished
3600ms Application Data
https false start
优势 劣势
节省一个RTT 需要端上和后台都做特殊支持
SYN 0ms
600ms
ACK ClientHello
1800ms
ChangeCipherSpec Finished
Application Data 3000ms
SYN ACK
1200ms
ServerHello ChangeCipherSpec
Finished 2400ms
Application Data
3600ms
https session ticket
优势 劣势
节省一个RTT/提升服务器性能/降低流量 有实效性,且无法解决首次建连问题
第16页
SlightSSL设计思想
证书缓存
• 证书缓存到本地
• 节省流量/时延/成本
0-RTT
• 协商报文和数据报文允许一起下发 • 兼顾前向安全
性能提升
• ECDH代替RSA
• Session Ticket会话复用
执行时间 单位:毫秒
150000 75000
RSA-1024 RSA-2048 ECDH-Prime-256 ECDH-Prime-192 ECDH-Prime-128 ECDH-Prime-112
0 1000*1 1000*10 1000*100 执行次数 ECDH性能是RSA的10倍
对称密钥长度 ECC非对称密钥长度
RSA密钥强度
80 160 112 224
1024 2048
ECDHPRIME-128
128 256
可比较密钥大小(密码分析所需计算量的角度)
第17页
SlightSSL的效果
网络制式 建连时间 鉴权时间 握手时间 总时间
Android 2G
21 2311
3G 505 691 21 1217
4G 200 236 15 451
WIFI 228 270
19 517
IOS
2G
26 2326
3G 567 723 10 1300
4G 233 239
6 478
WIFI 285 302
13 600
首次建连2G下2.5秒内完成
单位:毫秒 8000
6000 4000
https slightssl
0 网络制式 2G 3G 4G WIFI
首次建连对比HTTPS缩短60%
2G
3G https-anroid slightssl-android https-ios slightssl-ios
4G
WIFI 0
请求平均耗时对比HTTPS缩短40%
首次建连-1 会话复用-1 首次建连-20 会话复用-20
https spdy+slightssl
75 150 225
服务端性能提升50%
第18页
SlightSSL的优化
网络优化
TCP参数调整
小包精简
场景优化
• 开启TCP_NODELAY
• 私密性(AES-256-CBC)
•• 开完整启性TC(MPA_CQ或UHICMKAAC)CK
•• 适来源当可增靠大性T(C私P钥发和送预/接置公收钥缓的冲配区对) (>=64K)
• 防重放攻击(seq number)
• 去掉不必要的报文 • 多个小包合并到一个TCP报文中
• 0-RTT
• 会话复用避免SDK创建椭圆曲线 密钥对
• CDN场景
• 提高服务端send buf
• 开启0-RTT
性能优化
SessionTicket有效
• SessionTicket的性能远高于 ECDH
• 延长有效期提高会话复用度,进 而提升性能
小包精简
• 0-RTT • 断连时不发送goaway
降级策略
• 通过调度中心下发明文策略
第19页
谢谢!