高性能HTTPS服务中的TLS Record Size优化分析

帖　军，沙　恒

(中南民族大学 计算机科学学院，武汉 430074)



高性能HTTPS服务中的TLS Record Size优化分析

帖军，沙恒

(中南民族大学 计算机科学学院，武汉 430074)

摘要为优化HTTPS性能，研究了TCP特性对TLS性能的影响.通过数学模型分析，指出了2种不同条件下，TLS Record Size选择对用户首数据响应延时(TTFB)、首页面响应延时(TTFP)、网络效益、吞吐率等参数指标的影响.大的TLS Record Size提高网络吞吐和利用率，但增加了用户首数据响应延时，适合需要高吞吐但响应延时不敏感的场景；小的TLS Record Size降低用户响应延时却降低了网络吞吐和利用率，适合对用户响应时间敏感的场景.

关键词安全传输层协议；安全传输层协议记录协议数据块大小；安全超文本传输协议；传输控制协议

TLS Record Size Optimization Analysis of High Performance HTTPS Service

TieJun,ShaHeng

(College of Computer Science, South-Central University for Nationalities, Wuhan 430074, China)

AbstractThis paper studies the effect of TCP characteristics on the performance of TLS in order to optimize the performance of HTTPS. Through the analysis of mathematical model, it points out the influence of Record Size TLS selection on the first data response time delay (TTFB), the first page response time delay (TTFP), network efficiency, and throughput rate and other parameters in two different conditions. Large TLS Record Size blocks could improve network throughput and utilization rate, but increase user time to the first byte, which is suitable for the scenes of requiring high throughput but latency insensitive scene, while small TLS Record Size blocks could decrease the user latency but reduce network throughput and utilization rate, which is suitable for user response time sensitive scene.

KeywordsTLS；TLS Record Size；HTTPS；TCP

人们的生活现在已经越来越离不开互联网，与此同时，隐私和安全问题日益重要.国外很多网站包括google,facebook,twitter都支持全站HTTPS，国内也愈发重视.特别是在BAT三巨头的支付、网购、搜索等核心业务中更有体现.在此背景下，海量并发下的高性能HTTPS服务的研究也更具有价值.HTTPS可认为是HTTP+TLS，TLS[1]协议为传输层加密协议，其工作在传输层协议TCP之上.TLS协议又由两层协议构成：TLS记录协议(TLS Record)以及TLS握手协议，较低的一层为TLS Record协议，它的格式如图1所示.

Byte+1+2+3+40ContentType1..4VersionLength5..nPayloadn..mMACm..pPadding

图1TLS Record协议格式

Fig.1TLS Record structure

总体来说，HTTPS协议提供了3个功能：(1) 内容加密.数据以加密形式传输，中间者无法直接查看原始内容；(2) 身份认证.保证用户访问的是目的服务器；(3) 数据完整性.防止传输的内容被第三方冒充或者篡改.

享受安全、隐私的HTTPS服务需要付出额外的代价[2,3]，除了服务端需要额外的CPU消耗外，也会对客户端带来额外的响应延时，下面针对TLS Record Size(简称TRS)带来的性能问题进行论述.

1问题描述

Web服务的响应时间是影响用户体验的瓶颈点.在最坏的HTTP事务场景下[4]，浏览器需要完成一次DNS寻址，TCP连接的建立，TLS握手的两个RTT，最后需要HTTP事务的一次请求和响应的RTT.所以为了得到网页TTFB (time-to-first-bytes)[5]需要5个网络RTT.除此之外，在HTTPS下的TTFB，有时还会增加额外的RTT，带来不必要的延时.

TLS在加密应用层数据的时候，会将数据分割成若干上限为16KB的块，然后每个块会按照图1中TLS Record格式计算头数据，附加头数据后，最终形成若干块TLS Record.当接收端收到TLS Record序列时，会被缓存在TLS 层的缓存中，直到一个或多个完整的TLS Record可用时，其Payload才被解密，然后计算MAC并与头部中的MAC对比，如果匹配则完成完整性校验，数据才会被读到应用层.所以若TRS为16KB，则TLS Buffer必须读到至少一个完整的16KB数据才能进行校验并提交到应用层.任一字节的缺失都会增加RTT.

TCP的HOL问题以及慢启动特性[6-10]都会造成上述额外RTT问题，具体表现在以下2种情况：(1)如果一个完整的大块TLS Record被TCP分割为多个TCP块，其中任意一个TCP块丢失，都会造成额外的RTT；(2)若恰好有一个TCP块超出了当前的拥塞窗口cwnd，超出的TCP块将会在下一个RTT阶段传输，从而造成额外的RTT，这种情况在TCP的慢启动开始阶段由于拥塞窗口尚未打开，发生概率极高.典型的初始化拥塞窗口cwnd为3个标准的以太网MTU[11,12]，大小为4KB，而一个网页的平均大小在384KB，一个完整的网页传输需要若干个RTT，传输过程中上述2种情况都可能出现.本文针对TRS大小、MTU、初始化cwnd及传输数据的总大小等变量建立数学模型，以分析HTTPS性能的优化点.

2分析模型及参数指标

假设数据总长为L，记TRS为r，TLS Record协议头部长度为m1，IP/TCP头部长度为m2，记m=m1+m2，IP报文的大小上限为MTU.上述变量大小以Byte为计量单位.往返客户端与服务器之间的时间为一个RTT.每个待转发的TLS Record封装完毕后的数据大小为r+m.由TLS Record协议知:r∈[0,16384].对于TLS Record的转发存在两种情况：每个TLS Record可被封装在一个独立的IP报文中，或被封装在大于1个的IP报文中，这两种情况表示如下.

(i)m≤r+m≤MTU⟹r∈[0,MTU-m],

(ii)MTU

对于TRS对网络、服务器性能的影响，主要关注4个指标.

1)网络效率：当转发L的数据时，有效数据占全部数据的比例；

2)TTFB(time-to-first-bytes)延时：转发L的首个数据块所需要的时间；

3)TTFP(time-to-first-page)延时：转发首个用户展现页面的数据量所需要的时间；

4)吞吐率：转发L的数据的平均速率.

对以上2种情况的性能指标分别进行讨论.

2.1r∈[0,MTU-m]情形

L长度的数据需要在L/r个IP报文中进行转发，于是：

(1)

对于TTFB延时TCP首包丢包的可能性很小，以现在的网络设备而言，报文的大小对于转发延时的影响非常小，为此不同recordsize下的TTFB延时并不会有显著差距.如果考虑丢包，除了由于信道质量造成的丢包外，丢包率大部分取决于网络的繁忙程度，与报文长度关系很小.为此，不同recordsize下的TTFB延时并不会有显著差距.

对于TTFP延时在网络情况一致的条件下，这里本质上是在讨论传输首页数据所需要的时间.在慢启动阶段[13]，假定每次发送端都发送拥塞窗口cwnd所允许的最大数据块数量，定义b：当接收端收到b个全尺寸的TCP数据块后回送ACK[14].定义b-th：接收端接收到的一次满b数量的数据流.由于接收端为每个b-th回送一个ACK，每次发送端都能得到cwnd/b个ACK.当发送端处于慢启动阶段，每收到一个ACK，其cwnd加1.使用cwndi代表第i个来回的拥塞窗口，用γ表示慢启动阶段cwnd的增长率，则：

cwndi+1=cwndi+cwndi/b=(1+1/b)·cwndi=

γ·cwndi.

假定发送端的初始化拥塞窗口为ω1数据块，那么在第i个来回发送的数据大小为sdatai，则：

sdatai=ω1+ω1·γ+ω1·γ2+…+

解得：

(2)

TTFP为首页传输所需的时间，所需的传输数据量为sdatai.由(1)式知：

(3)

两组患者亚低温治疗前 P、CVP、MAP、CI、EVLWI、GEDVI、SVRI比较，差异无显著性（P＞0.05）。

对于吞吐率，有两个可能的瓶颈：网络和主机.如果吞吐率的瓶颈在于网络带宽有限，那么吞吐率实际上只取决于网络的质量.Record作为数据传递给TCP，无论是多个分片承载一个Record还是一个分片承载一个Record，TCP并不感知.只要Record的产生/处理速度大于TCP的传输能力，吞吐率并不受到TRS的影响，只取决于网络本身的质量.当吞吐率受限于主机准备或者处理数据的速率，如果TRS越小，主机准备或者处理数据的速率会降低，造成吞吐率降低.为此TRS越大越好.

由以上分析可以发现，当r∈[ 0,MTU-m]时，TRS越大越好.TRS越大，网络效益、TTFP、吞吐率指标会越好.此时最优取值为MTU-m.

2.2r∈(MTU-m,16384]情形

L长度的数据需要被分为L/r个TLSRecord，每个TLSRecord需要被分割为多个TCP的分片进行转发.假设一个TLSRecord刚好被切分到n个最大长度的TCP的分片，此时：

(4)

TCP传输数据L的总长度为：

(5)

一个TLSRecord大小为n(MTU-m2)-m1.这时问题转化为分析n对于网络、主机性能的影响.

对于TTFB延时，显然n的增加，即TCP分片数量的增加，会增加丢包和重传的可能性，而TLS必须等到一个Record的所有分片都收到才能解密报文.此时首块数据大小为：

sdatai=n·MTU.

(6)

对于TTFP延时在网络情况一致的条件下，本质上在讨论传输首页数据需要的时间，由(2)、(4)、(5)式，得：

由于TLS封装m1，TCP/IP封装m2的额外开销很小，所以总数据量、全部分片数量的差距是非常微小的，因此TTFP延时并不会有显著差距.

对于吞吐率，分析同2.1，与r∈[0,MTU-m]结论无差异：当吞吐率受限于主机时，TRS越大则吞吐率越高.

由以上分析可以发现，当r∈(MTU-m,16384]时，并没有绝对优势的策略来适应所有场景.更小的TRS有利于降低TTFB延时，而更大的TRS有利于增加网络效率和吞吐率，需要根据业务场景做出相应的调优选择.

3结论

目前很多文献已经在HTTPS性能分析方面做了大量的工作，然而在分析TLS Record Size(TRS)对HTTPS服务质量影响方面，文献相对较少.本文在基于典型的TCP拥塞窗口的场景下，对用户首块数据响应延时(TTFB)、首页数据传输所需时间(TTFP)、网络效率、吞吐率指标所适用的最优TRS进行了论证和总结，得出以下结论,在用户响应延时敏感场景下，最佳策略为r=MTU-m；在网络吞吐敏感场景下，TRS越大越好，最高取值16384Byte.在实际应用中，基于HTTPS业务的侧重点不同，可根据以上结论进行动态TRS优化.

参考文献

[1]Dierks T, Rescorla E. RFC 5246—the Transport Layer Security (TLS) protocol version 1.2[J]. Ietf Rfc, 2008, 31(4):5246.

[2]Apostolopoulos G, Peris V, Saha D. Transport layer security: how much does it really cost [C]// IEEE. 18th Annual Joint Conference of the IEEE Computer and Communications Societies. New York: IEEE, 1999, 2: 717-725.

[3]Naylor D, Finamore A, Leontiadis I, et al. The cost of the S in HTTPS[C]// ACM.Proceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies. New York: ACM, 2014: 133-140.

[4]Grigorik I.Optimizing TLS record size & buffering latency[EB/OL].(2013-10-24)[2015-10-20]. https://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/.

[5]Halepovic E, Pang J, Spatscheck O. Can you GET me now?:estimating the time-to-first-byte of HTTP transactions with passive measurements[C]// ACM.Proceedings of the 2012 ACM conference on Internet measurement conference. New York: ACM, 2012: 115-122.

[6]肖甫，王汝传，孙力娟，等. 基于TCP友好的无线网络拥塞控制机制研究[J].计算机科学,2010,37(7):50-53.

[7]Grigorik I. High performance browser networking[M]. Sebastopol: O′Reilly Media,2013:13-34,71-73.

[8]Steven W R. TCP/IP详解 卷1：协议[M]. 范建华，译. 北京：机械工业出版社，2000: 209-224.

[9]Allman M, Paxson V, Stevens W. TCP congestion control[J]. Acm Computer Communications Review, 1999, 29(5):308-309.

[10]Cardwell N, Savage S, Anderson T. Modeling TCP latency[C]// IEEE. 19th Annual Joint Conference of the IEEE Computer and Communications Societies. New York:IEEE, 2000, 3: 1742-1751.

[11]Allman M, Floyd S, Partridge C. Increasing TCP′s initial window[J]. Internet Rfc, 2002(1998):2414.

[12]Dukkipati N,Refice T,Cheng Y,et al. An argument for increasing TCP′s initial congestion window[J]. ACM SIGCOMM Computer Communication Review,2010,40(3): 26-33.

[13]Padhye J, Firoiu V, Towsley D, et al. Modeling TCP throughput: a simple model and its empirical validation[J]. ACM SIGCOMM Computer Communication Review, 1998, 28(4): 303-314.

[14]Braden R. RFC-1122: requirements for internet hosts′, request for comments[J]. Arabic Lexicography Its History & Its Place in the General History of Lexicography Leiden, 1989, 11(3):82-89.

中图分类号TP393

文献标识码A

文章编号1672-4321(2016)01-0123-04

基金项目国家民委科研基金资助项目(CMZY13010)；中南民族大学中央高校基本科研业务费专项资金资助项目(CZZ15002)

作者简介帖军(1976-)，男，副教授，博士，研究方向：移动计算与分布式系统，E-mail: musa1976@qq.com

收稿日期2015-12-19