高性能HTTPS服務(wù)中的TLS Record Size優(yōu)化分析

帖　軍，沙　恒

(中南民族大學(xué) 計(jì)算機(jī)科學(xué)學(xué)院，武漢 430074)

?

高性能HTTPS服務(wù)中的TLS Record Size優(yōu)化分析

帖軍，沙恒

(中南民族大學(xué) 計(jì)算機(jī)科學(xué)學(xué)院，武漢 430074)

摘要為優(yōu)化HTTPS性能，研究了TCP特性對(duì)TLS性能的影響.通過(guò)數(shù)學(xué)模型分析，指出了2種不同條件下，TLS Record Size選擇對(duì)用戶首數(shù)據(jù)響應(yīng)延時(shí)(TTFB)、首頁(yè)面響應(yīng)延時(shí)(TTFP)、網(wǎng)絡(luò)效益、吞吐率等參數(shù)指標(biāo)的影響.大的TLS Record Size提高網(wǎng)絡(luò)吞吐和利用率，但增加了用戶首數(shù)據(jù)響應(yīng)延時(shí)，適合需要高吞吐但響應(yīng)延時(shí)不敏感的場(chǎng)景；小的TLS Record Size降低用戶響應(yīng)延時(shí)卻降低了網(wǎng)絡(luò)吞吐和利用率，適合對(duì)用戶響應(yīng)時(shí)間敏感的場(chǎng)景.

關(guān)鍵詞安全傳輸層協(xié)議；安全傳輸層協(xié)議記錄協(xié)議數(shù)據(jù)塊大??；安全超文本傳輸協(xié)議；傳輸控制協(xié)議

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

人們的生活現(xiàn)在已經(jīng)越來(lái)越離不開互聯(lián)網(wǎng)，與此同時(shí)，隱私和安全問(wèn)題日益重要.國(guó)外很多網(wǎng)站包括google,facebook,twitter都支持全站HTTPS，國(guó)內(nèi)也愈發(fā)重視.特別是在BAT三巨頭的支付、網(wǎng)購(gòu)、搜索等核心業(yè)務(wù)中更有體現(xiàn).在此背景下，海量并發(fā)下的高性能HTTPS服務(wù)的研究也更具有價(jià)值.HTTPS可認(rèn)為是HTTP+TLS，TLS[1]協(xié)議為傳輸層加密協(xié)議，其工作在傳輸層協(xié)議TCP之上.TLS協(xié)議又由兩層協(xié)議構(gòu)成：TLS記錄協(xié)議(TLS Record)以及TLS握手協(xié)議，較低的一層為TLS Record協(xié)議，它的格式如圖1所示.

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

圖1TLS Record協(xié)議格式

Fig.1TLS Record structure

總體來(lái)說(shuō)，HTTPS協(xié)議提供了3個(gè)功能：(1) 內(nèi)容加密.數(shù)據(jù)以加密形式傳輸，中間者無(wú)法直接查看原始內(nèi)容；(2) 身份認(rèn)證.保證用戶訪問(wèn)的是目的服務(wù)器；(3) 數(shù)據(jù)完整性.防止傳輸?shù)膬?nèi)容被第三方冒充或者篡改.

享受安全、隱私的HTTPS服務(wù)需要付出額外的代價(jià)[2,3]，除了服務(wù)端需要額外的CPU消耗外，也會(huì)對(duì)客戶端帶來(lái)額外的響應(yīng)延時(shí)，下面針對(duì)TLS Record Size(簡(jiǎn)稱TRS)帶來(lái)的性能問(wèn)題進(jìn)行論述.

1問(wèn)題描述

Web服務(wù)的響應(yīng)時(shí)間是影響用戶體驗(yàn)的瓶頸點(diǎn).在最壞的HTTP事務(wù)場(chǎng)景下[4]，瀏覽器需要完成一次DNS尋址，TCP連接的建立，TLS握手的兩個(gè)RTT，最后需要HTTP事務(wù)的一次請(qǐng)求和響應(yīng)的RTT.所以為了得到網(wǎng)頁(yè)TTFB (time-to-first-bytes)[5]需要5個(gè)網(wǎng)絡(luò)RTT.除此之外，在HTTPS下的TTFB，有時(shí)還會(huì)增加額外的RTT，帶來(lái)不必要的延時(shí).

TLS在加密應(yīng)用層數(shù)據(jù)的時(shí)候，會(huì)將數(shù)據(jù)分割成若干上限為16KB的塊，然后每個(gè)塊會(huì)按照?qǐng)D1中TLS Record格式計(jì)算頭數(shù)據(jù)，附加頭數(shù)據(jù)后，最終形成若干塊TLS Record.當(dāng)接收端收到TLS Record序列時(shí)，會(huì)被緩存在TLS 層的緩存中，直到一個(gè)或多個(gè)完整的TLS Record可用時(shí)，其Payload才被解密，然后計(jì)算MAC并與頭部中的MAC對(duì)比，如果匹配則完成完整性校驗(yàn)，數(shù)據(jù)才會(huì)被讀到應(yīng)用層.所以若TRS為16KB，則TLS Buffer必須讀到至少一個(gè)完整的16KB數(shù)據(jù)才能進(jìn)行校驗(yàn)并提交到應(yīng)用層.任一字節(jié)的缺失都會(huì)增加RTT.

TCP的HOL問(wèn)題以及慢啟動(dòng)特性[6-10]都會(huì)造成上述額外RTT問(wèn)題，具體表現(xiàn)在以下2種情況：(1)如果一個(gè)完整的大塊TLS Record被TCP分割為多個(gè)TCP塊，其中任意一個(gè)TCP塊丟失，都會(huì)造成額外的RTT；(2)若恰好有一個(gè)TCP塊超出了當(dāng)前的擁塞窗口cwnd，超出的TCP塊將會(huì)在下一個(gè)RTT階段傳輸，從而造成額外的RTT，這種情況在TCP的慢啟動(dòng)開始階段由于擁塞窗口尚未打開，發(fā)生概率極高.典型的初始化擁塞窗口cwnd為3個(gè)標(biāo)準(zhǔn)的以太網(wǎng)MTU[11,12]，大小為4KB，而一個(gè)網(wǎng)頁(yè)的平均大小在384KB，一個(gè)完整的網(wǎng)頁(yè)傳輸需要若干個(gè)RTT，傳輸過(guò)程中上述2種情況都可能出現(xiàn).本文針對(duì)TRS大小、MTU、初始化cwnd及傳輸數(shù)據(jù)的總大小等變量建立數(shù)學(xué)模型，以分析HTTPS性能的優(yōu)化點(diǎn).

2分析模型及參數(shù)指標(biāo)

假設(shè)數(shù)據(jù)總長(zhǎng)為L(zhǎng)，記TRS為r，TLS Record協(xié)議頭部長(zhǎng)度為m1，IP/TCP頭部長(zhǎng)度為m2，記m=m1+m2，IP報(bào)文的大小上限為MTU.上述變量大小以Byte為計(jì)量單位.往返客戶端與服務(wù)器之間的時(shí)間為一個(gè)RTT.每個(gè)待轉(zhuǎn)發(fā)的TLS Record封裝完畢后的數(shù)據(jù)大小為r+m.由TLS Record協(xié)議知:r∈[0,16384].對(duì)于TLS Record的轉(zhuǎn)發(fā)存在兩種情況：每個(gè)TLS Record可被封裝在一個(gè)獨(dú)立的IP報(bào)文中，或被封裝在大于1個(gè)的IP報(bào)文中，這兩種情況表示如下.

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

(ii)MTU

對(duì)于TRS對(duì)網(wǎng)絡(luò)、服務(wù)器性能的影響，主要關(guān)注4個(gè)指標(biāo).

1)網(wǎng)絡(luò)效率：當(dāng)轉(zhuǎn)發(fā)L的數(shù)據(jù)時(shí)，有效數(shù)據(jù)占全部數(shù)據(jù)的比例；

2)TTFB(time-to-first-bytes)延時(shí)：轉(zhuǎn)發(fā)L的首個(gè)數(shù)據(jù)塊所需要的時(shí)間；

3)TTFP(time-to-first-page)延時(shí)：轉(zhuǎn)發(fā)首個(gè)用戶展現(xiàn)頁(yè)面的數(shù)據(jù)量所需要的時(shí)間；

4)吞吐率：轉(zhuǎn)發(fā)L的數(shù)據(jù)的平均速率.

對(duì)以上2種情況的性能指標(biāo)分別進(jìn)行討論.

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

L長(zhǎng)度的數(shù)據(jù)需要在L/r個(gè)IP報(bào)文中進(jìn)行轉(zhuǎn)發(fā)，于是：

(1)

對(duì)于TTFB延時(shí)TCP首包丟包的可能性很小，以現(xiàn)在的網(wǎng)絡(luò)設(shè)備而言，報(bào)文的大小對(duì)于轉(zhuǎn)發(fā)延時(shí)的影響非常小，為此不同recordsize下的TTFB延時(shí)并不會(huì)有顯著差距.如果考慮丟包，除了由于信道質(zhì)量造成的丟包外，丟包率大部分取決于網(wǎng)絡(luò)的繁忙程度，與報(bào)文長(zhǎng)度關(guān)系很小.為此，不同recordsize下的TTFB延時(shí)并不會(huì)有顯著差距.

對(duì)于TTFP延時(shí)在網(wǎng)絡(luò)情況一致的條件下，這里本質(zhì)上是在討論傳輸首頁(yè)數(shù)據(jù)所需要的時(shí)間.在慢啟動(dòng)階段[13]，假定每次發(fā)送端都發(fā)送擁塞窗口cwnd所允許的最大數(shù)據(jù)塊數(shù)量，定義b：當(dāng)接收端收到b個(gè)全尺寸的TCP數(shù)據(jù)塊后回送ACK[14].定義b-th：接收端接收到的一次滿b數(shù)量的數(shù)據(jù)流.由于接收端為每個(gè)b-th回送一個(gè)ACK，每次發(fā)送端都能得到cwnd/b個(gè)ACK.當(dāng)發(fā)送端處于慢啟動(dòng)階段，每收到一個(gè)ACK，其cwnd加1.使用cwndi代表第i個(gè)來(lái)回的擁塞窗口，用γ表示慢啟動(dòng)階段cwnd的增長(zhǎng)率，則：

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

γ·cwndi.

假定發(fā)送端的初始化擁塞窗口為ω1數(shù)據(jù)塊，那么在第i個(gè)來(lái)回發(fā)送的數(shù)據(jù)大小為sdatai，則：

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

解得：

(2)

TTFP為首頁(yè)傳輸所需的時(shí)間，所需的傳輸數(shù)據(jù)量為sdatai.由(1)式知：

(3)

兩組患者亞低溫治療前 P、CVP、MAP、CI、EVLWI、GEDVI、SVRI比較，差異無(wú)顯著性（P＞0.05）。

對(duì)于吞吐率，有兩個(gè)可能的瓶頸：網(wǎng)絡(luò)和主機(jī).如果吞吐率的瓶頸在于網(wǎng)絡(luò)帶寬有限，那么吞吐率實(shí)際上只取決于網(wǎng)絡(luò)的質(zhì)量.Record作為數(shù)據(jù)傳遞給TCP，無(wú)論是多個(gè)分片承載一個(gè)Record還是一個(gè)分片承載一個(gè)Record，TCP并不感知.只要Record的產(chǎn)生/處理速度大于TCP的傳輸能力，吞吐率并不受到TRS的影響，只取決于網(wǎng)絡(luò)本身的質(zhì)量.當(dāng)吞吐率受限于主機(jī)準(zhǔn)備或者處理數(shù)據(jù)的速率，如果TRS越小，主機(jī)準(zhǔn)備或者處理數(shù)據(jù)的速率會(huì)降低，造成吞吐率降低.為此TRS越大越好.

由以上分析可以發(fā)現(xiàn)，當(dāng)r∈[ 0,MTU-m]時(shí)，TRS越大越好.TRS越大，網(wǎng)絡(luò)效益、TTFP、吞吐率指標(biāo)會(huì)越好.此時(shí)最優(yōu)取值為MTU-m.

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

L長(zhǎng)度的數(shù)據(jù)需要被分為L(zhǎng)/r個(gè)TLSRecord，每個(gè)TLSRecord需要被分割為多個(gè)TCP的分片進(jìn)行轉(zhuǎn)發(fā).假設(shè)一個(gè)TLSRecord剛好被切分到n個(gè)最大長(zhǎng)度的TCP的分片，此時(shí)：

(4)

TCP傳輸數(shù)據(jù)L的總長(zhǎng)度為：

(5)

一個(gè)TLSRecord大小為n(MTU-m2)-m1.這時(shí)問(wèn)題轉(zhuǎn)化為分析n對(duì)于網(wǎng)絡(luò)、主機(jī)性能的影響.

對(duì)于TTFB延時(shí)，顯然n的增加，即TCP分片數(shù)量的增加，會(huì)增加丟包和重傳的可能性，而TLS必須等到一個(gè)Record的所有分片都收到才能解密報(bào)文.此時(shí)首塊數(shù)據(jù)大小為：

sdatai=n·MTU.

(6)

對(duì)于TTFP延時(shí)在網(wǎng)絡(luò)情況一致的條件下，本質(zhì)上在討論傳輸首頁(yè)數(shù)據(jù)需要的時(shí)間，由(2)、(4)、(5)式，得：

由于TLS封裝m1，TCP/IP封裝m2的額外開銷很小，所以總數(shù)據(jù)量、全部分片數(shù)量的差距是非常微小的，因此TTFP延時(shí)并不會(huì)有顯著差距.

對(duì)于吞吐率，分析同2.1，與r∈[0,MTU-m]結(jié)論無(wú)差異：當(dāng)吞吐率受限于主機(jī)時(shí)，TRS越大則吞吐率越高.

由以上分析可以發(fā)現(xiàn)，當(dāng)r∈(MTU-m,16384]時(shí)，并沒(méi)有絕對(duì)優(yōu)勢(shì)的策略來(lái)適應(yīng)所有場(chǎng)景.更小的TRS有利于降低TTFB延時(shí)，而更大的TRS有利于增加網(wǎng)絡(luò)效率和吞吐率，需要根據(jù)業(yè)務(wù)場(chǎng)景做出相應(yīng)的調(diào)優(yōu)選擇.

3結(jié)論

目前很多文獻(xiàn)已經(jīng)在HTTPS性能分析方面做了大量的工作，然而在分析TLS Record Size(TRS)對(duì)HTTPS服務(wù)質(zhì)量影響方面，文獻(xiàn)相對(duì)較少.本文在基于典型的TCP擁塞窗口的場(chǎng)景下，對(duì)用戶首塊數(shù)據(jù)響應(yīng)延時(shí)(TTFB)、首頁(yè)數(shù)據(jù)傳輸所需時(shí)間(TTFP)、網(wǎng)絡(luò)效率、吞吐率指標(biāo)所適用的最優(yōu)TRS進(jìn)行了論證和總結(jié)，得出以下結(jié)論,在用戶響應(yīng)延時(shí)敏感場(chǎng)景下，最佳策略為r=MTU-m；在網(wǎng)絡(luò)吞吐敏感場(chǎng)景下，TRS越大越好，最高取值16384Byte.在實(shí)際應(yīng)用中，基于HTTPS業(yè)務(wù)的側(cè)重點(diǎn)不同，可根據(jù)以上結(jié)論進(jìn)行動(dòng)態(tài)TRS優(yōu)化.

參考文獻(xiàn)

[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友好的無(wú)線網(wǎng)絡(luò)擁塞控制機(jī)制研究[J].計(jì)算機(jī)科學(xué),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：協(xié)議[M]. 范建華，譯. 北京：機(jī)械工業(yè)出版社，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.

中圖分類號(hào)TP393

文獻(xiàn)標(biāo)識(shí)碼A

文章編號(hào)1672-4321(2016)01-0123-04

基金項(xiàng)目國(guó)家民委科研基金資助項(xiàng)目(CMZY13010)；中南民族大學(xué)中央高校基本科研業(yè)務(wù)費(fèi)專項(xiàng)資金資助項(xiàng)目(CZZ15002)

作者簡(jiǎn)介帖軍(1976-)，男，副教授，博士，研究方向：移動(dòng)計(jì)算與分布式系統(tǒng)，E-mail: musa1976@qq.com

收稿日期2015-12-19