AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

阿里巴巴HTTP2实践及无线通信协议的演进之路 by 陈虓将

发布者 mobile
发布于 1467767593033  浏览 7614 关键词 互联网, HTTP2 
分享到

第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页

谢谢!



支持文件格式:*.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。