杜旻翔

摘要摘要：超文本傳輸安全協(xié)議（Hypertext Transfer Protocol Secure，HTTPS）是近年來快速發(fā)展的網(wǎng)絡(luò)安全技術(shù)，具有網(wǎng)絡(luò)身份認(rèn)證、數(shù)據(jù)傳輸加密功能。提出對HTTPS優(yōu)化的思路，針對HTTPS底層的TCP協(xié)議中的TIME_WAIT參數(shù)進(jìn)行分析，研究TCP特性對TLS性能的影響，并建立數(shù)學(xué)模型。研究在不同TIME_WAIT時(shí)長、不同網(wǎng)絡(luò)環(huán)境下，TIME_WAIT參數(shù)對用戶響應(yīng)延時(shí)、服務(wù)器吞吐率、網(wǎng)絡(luò)效益、平均訪問時(shí)間等參數(shù)的影響。

關(guān)鍵詞關(guān)鍵詞：安全傳輸層協(xié)議；安全超文本傳輸協(xié)議；TIME_WAIT；傳輸控制協(xié)議

DOIDOI：10.11907/rjdk.162886

中圖分類號：TP393

文獻(xiàn)標(biāo)識碼：A文章編號文章編號：16727800（2017）005015503

0引言

互聯(lián)網(wǎng)無處不在，所有的網(wǎng)頁訪問都通過HTTP協(xié)議進(jìn)行，但其并不具有數(shù)據(jù)安全保障功能，該協(xié)議在安全方面最大的問題是數(shù)據(jù)明文傳輸，通過簡單抓包就能獲取隱私數(shù)據(jù)。HTTPS應(yīng)用廣泛，Google、Facebook、Twitter等都支持HTTPS服務(wù)，各大互聯(lián)網(wǎng)公司的核心業(yè)務(wù)都在大范圍應(yīng)用HTTPS。在此背景下，高并發(fā)量、高性能的HTTPS服務(wù)研究更具現(xiàn)實(shí)意義[1]。安全模塊的引入使網(wǎng)絡(luò)訪問資源消耗增大、速度變慢，如何對超文本傳輸安全協(xié)議進(jìn)行優(yōu)化是目前研究熱點(diǎn)之一[2]。 通過優(yōu)化HTTPS協(xié)議中的TLS協(xié)議與底層的TCP/IP協(xié)議能夠?qū)崿F(xiàn)HTTPS服務(wù)性能優(yōu)化。

基于網(wǎng)絡(luò)安全的結(jié)構(gòu)模型，本文重點(diǎn)分析TIME_WAIT參數(shù)在不穩(wěn)定的網(wǎng)絡(luò)環(huán)境下對超文本傳輸安全協(xié)議性能的影響與優(yōu)化。

1網(wǎng)絡(luò)模型

網(wǎng)絡(luò)安全結(jié)構(gòu)模型如圖1所示，構(gòu)成安全超文本傳輸協(xié)議握手過程如圖2所示，傳輸控制協(xié)議連接過程如圖3所示，關(guān)閉過程如圖4所示。圖1表示了研究對象在整體結(jié)構(gòu)中所處的位置，圖2在實(shí)際連接過程中位于圖3和圖4之間，是相互依賴承接的關(guān)系[3] ，本文分析的重點(diǎn)是TIME_WAIT對服務(wù)器性能及后續(xù)連接操作的影響。

總延時(shí)等于中介協(xié)議訪問延遲之和，見式（1）：

di（t）=di（tcp3）+di（tls）+di（tcp4）+di（rep）（1）

在四層網(wǎng)絡(luò)結(jié)構(gòu)中，TLS協(xié)議介于Application Lay和Transport Lay之間。其中Transport Lay中的TCP/UDP協(xié)議同時(shí)也是TLS協(xié)議基礎(chǔ)[4]，針對底層進(jìn)行上層優(yōu)化。在TCP協(xié)議完成握手之后進(jìn)入HTTPS握手階段，圖2是圖3與圖4的中間過程。本文研究的內(nèi)容就是在圖3和圖4所示建立連接與關(guān)閉連接過程中，參數(shù)的等待狀態(tài)時(shí)間長度對服務(wù)器的影響。

2基于可變參數(shù)的服務(wù)器狀態(tài)分析

2.1數(shù)學(xué)建模

首先對過程進(jìn)行描述，關(guān)閉過程：A發(fā)送CLOSE請求到B，A→TIME_WAIT狀態(tài)；接收到請求之后B→CLOSE_WAIT狀態(tài)并發(fā)送FIN_WAIT到A；接收到FIN_WAIT之后A發(fā)送ACK到B→CLOSED，結(jié)束。最后一個(gè)ACK狀態(tài)由主動關(guān)閉連接的一段發(fā)出，并且在發(fā)出之后進(jìn)入TIME_WAIT狀態(tài)。如果ACK狀態(tài)丟失，B端會重新發(fā)出FIN請求ACK，保證全雙工連接終止[5]。如果所有的TCP連接都由服務(wù)器端關(guān)閉，則每個(gè)連接都會保持一個(gè)TIME_WAIT（后文使用TW代稱）狀態(tài)并持續(xù)兩個(gè)最大分節(jié)生命周期。

假設(shè)并發(fā)數(shù)為N，記TW時(shí)長為t，服務(wù)器可承載并發(fā)總量為m1，經(jīng)過n（n>0）次TW狀態(tài)之后可用并發(fā)數(shù)為m2，任意p時(shí)間可用并發(fā)數(shù)m=m1+m2，時(shí)長t以秒為單位，按照規(guī)定可知t∈[0，240]?？蛻舳嗽L問的時(shí)間間隔為t2，對于socket pair是否重新建立連接存在兩種情況：①在客戶端建立連接時(shí)間間隔長于TW時(shí)間的時(shí)候可以重用端口；②在時(shí)間間隔長于TW時(shí)間時(shí)必須調(diào)用新的端口建立連接，這兩種情況表示如下：

0≤t≤t2=>t∈[0，t2]（2）

t2≤t≤240=>t∈[t2，240]（3）

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

（1）網(wǎng)絡(luò)連接效率：當(dāng)用戶數(shù)為N時(shí)，在正常流程下有效連接占全部連接的數(shù)據(jù)比例。

（2）可用并發(fā)數(shù)：單位時(shí)間內(nèi)可建立連接的用戶數(shù)量。

（3）TFA（time-to-first-ack）：用戶首次關(guān)閉連接耗時(shí)。

（4）TSA（time-to-second-ack）：用戶再次關(guān)閉連接耗時(shí)。

這里，每次訪問的客戶端數(shù)量為N，批次訪問數(shù)為k，訪問時(shí)間間隔為t2，假定TW狀態(tài)全部產(chǎn)生在服務(wù)器端。

2.2式（2）條件下討論

數(shù)據(jù)發(fā)送次數(shù)（假定每次連接時(shí)長都穩(wěn)定相同的情況下）= T/t1，網(wǎng)絡(luò)連接效率見式（2）。顯然在WT時(shí)間小于網(wǎng)絡(luò)傳輸間隔時(shí)，傳輸效率與服務(wù)器可承載的連接數(shù)m1有關(guān)?？梢娫趖∈[0，t2]情況下，TW參數(shù)不會對服務(wù)器負(fù)載產(chǎn)生影響，但是t2時(shí)間是不穩(wěn)定的，所以t的值應(yīng)該盡可能小。

m1*T/t2N*T/t2 =m1/N（4）

可用并發(fā)數(shù)在TW階段，每個(gè)TW狀態(tài)都會占用一個(gè)可用連接，故可用并發(fā)數(shù)和t成反比。

對于TFA延時(shí)， FIN發(fā)送與ACK返回的時(shí)間受網(wǎng)絡(luò)環(huán)境影響，按照目前的網(wǎng)絡(luò)設(shè)備與網(wǎng)絡(luò)環(huán)境而言，首次請求丟包的可能性很小。如果首次請求產(chǎn)生丟包，這個(gè)概率取決于通信質(zhì)量和網(wǎng)絡(luò)繁忙程度。由于CLOSE動作的報(bào)文長度是固定的，所以TW于TFA基本沒有關(guān)聯(lián)，不同的TW基本不會影響TFA的時(shí)間。對于TSA延時(shí)，在網(wǎng)絡(luò)條件穩(wěn)定的環(huán)境下，這個(gè)延時(shí)指接收第二個(gè)FIN消息并進(jìn)行ACK返回實(shí)現(xiàn)全雙工關(guān)閉[6]。如果TW狀態(tài)存在時(shí)間小于FIN數(shù)據(jù)包接收到的時(shí)間節(jié)點(diǎn)，或者狀態(tài)維持不到ACK丟失之后重新請求的時(shí)間階段，在B端請求重發(fā)ACK的時(shí)候A端發(fā)送RST數(shù)據(jù)，導(dǎo)致B端進(jìn)行錯(cuò)誤連接；另一種情況是連接混淆。A端正常終止之后，仍然接收到B端相同端口和句柄的數(shù)據(jù)組重復(fù)報(bào)文，此時(shí)的A端如果有新的連接建立就會導(dǎo)致連接混淆。

2.3 式（3）條件下討論

網(wǎng)絡(luò)連接效率見式（3），顯然t參數(shù)越小網(wǎng)絡(luò)連接效率越高。當(dāng)t∈[t2，240]時(shí)，t越小越好，最優(yōu)值應(yīng)該為t2。

m1*T/tN*T/t2 =m1*t2/（N*t）（5）

對于TFA延時(shí)，在網(wǎng)絡(luò)穩(wěn)定的環(huán)境下，不同的TW基本不會影響TFA時(shí)間。對于TSA延時(shí)，在網(wǎng)絡(luò)穩(wěn)定的環(huán)境下，仍然會有全雙工以及RST導(dǎo)致的錯(cuò)誤連接問題，只要在t=240時(shí)，2MSL的時(shí)長就可保證因路由器異常而延緩的數(shù)據(jù)包在網(wǎng)絡(luò)中消逝，避免連接混淆問題。

3仿真驗(yàn)證

測試環(huán)境使用模擬環(huán)境，在TLS協(xié)議上進(jìn)行改進(jìn)，并完成協(xié)議的編譯和調(diào)試。客戶端環(huán)境參數(shù)為：OS X 10.11 Beta操作系統(tǒng)、4核Intel Core i5 2.6GHz CPU、8G內(nèi)存、HTTPS服務(wù)器與靜態(tài)Web服務(wù)器。按照壓力測試工具基本設(shè)計(jì)思路和原則進(jìn)行測試。實(shí)驗(yàn)參數(shù)為相同的請求次數(shù)、客戶端數(shù)量、請求時(shí)間間隔，比對服務(wù)器上的數(shù)據(jù)吞吐率、可用連接數(shù)、并發(fā)連接數(shù)、并發(fā)用戶數(shù)、用戶平均請求時(shí)間、服務(wù)器平均請求等待時(shí)間等參數(shù)。

實(shí)驗(yàn)步驟：啟動HTTPS服務(wù)，使用digitalocean上1Mbps帶寬服務(wù)器，保持1 000個(gè)連接100個(gè)客戶端間隔5s請求服務(wù)器進(jìn)行5次請求，觀察服務(wù)器吞吐率、并發(fā)連接數(shù)、并發(fā)用戶數(shù)、用戶平均請求時(shí)間、服務(wù)器平均請求等待時(shí)間等參數(shù)變化。按照時(shí)間間隔記錄實(shí)驗(yàn)數(shù)據(jù)，再修改TIME_WAIT參數(shù)，分別按照10、30、120、240進(jìn)行對照實(shí)驗(yàn)。觀察服務(wù)器吞吐率、并發(fā)連接數(shù)、并發(fā)用戶數(shù)、用戶平均請求時(shí)間、服務(wù)器平均請求等待時(shí)間等參數(shù)變化，如圖5-7所示。

隨著單次實(shí)驗(yàn)內(nèi)請求次數(shù)增加，最長連接耗時(shí)從9 404ms逐步上升至38 883ms，在這個(gè)過程中，服務(wù)器中的TIME_WAIT數(shù)量從0逐步上升至1 649，并在達(dá)到2 048后開始下降，下降的時(shí)間節(jié)點(diǎn)在請求結(jié)束之后。

在修改TIME_WAIT時(shí)間長度值之后，服務(wù)器各項(xiàng)指標(biāo)都隨著TIME_WAIT時(shí)間長度的變化而變化，以第一次實(shí)驗(yàn)數(shù)據(jù)作為基準(zhǔn)數(shù)據(jù)，記錄之后參數(shù)的變化。

4結(jié)語

本文討論了TIME_WAIT時(shí)間長度對服務(wù)器性能指標(biāo)的影響，從兩種不同的場景進(jìn)行了分析。

一般場景下，TIME_WAIT的時(shí)間長度在[0， t2]時(shí)服務(wù)器可用并發(fā)量最優(yōu)，TIME_WAIT時(shí)間長度越短，吞吐率、并發(fā)連接數(shù)、平均響應(yīng)時(shí)間都可達(dá)到較優(yōu)秀的結(jié)果。

在移動網(wǎng)絡(luò)環(huán)境中對TCP/IP進(jìn)行優(yōu)化，考慮傳輸過程中數(shù)據(jù)包的穩(wěn)定性傳輸問題[7]，TIME_WAIT的時(shí)間長度依然符合以上論述，但這時(shí)需要更多地考慮網(wǎng)絡(luò)環(huán)境對數(shù)據(jù)包傳輸?shù)挠绊?，弱網(wǎng)絡(luò)會導(dǎo)致數(shù)據(jù)包在網(wǎng)絡(luò)中有更多的丟包和錯(cuò)誤，導(dǎo)致協(xié)議結(jié)束時(shí)產(chǎn)生更多的不確定性。因此，TIME_WAIT時(shí)長與網(wǎng)絡(luò)的狀況優(yōu)劣成反比。

參考文獻(xiàn)參考文獻(xiàn)：

[1]NAYLOR D， FINAMORE A， LEONTIADIS I， et al. The cost of the s in https[C].Proceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies. ACM， 2014： 133140.

[2]BLAKE WILSON S， MOELLER B， GUPTA V， et al. Elliptic curve cryptography （ECC） cipher suites for transport layer security （TLS）[EB/OL]. http：//www.faqs.org/rfcs/rfc4492.html.

[3]徐偉.TCP協(xié)議的性能建模研究[D].合肥：中國科學(xué)技術(shù)大學(xué)，2012.

[4]DIERKS T. The transport layer security （TLS） protocol version 1.2[EB/OL]. https：//tools.ietf.org/html/rfc5246.

[5]何泉.在繁忙服務(wù)器上避免TCPTIME_WAIT狀態(tài)的研究[J]. 小型微型計(jì)算機(jī)系統(tǒng)，2000 （6）：600602.

[6]李天科，劉正歧. 2MSL等待狀態(tài)及應(yīng)用分析[J]. 計(jì)算機(jī)與數(shù)字工程，2011 （12）：115118.

[7]MORRIS R. Scalable TCP congestion control[J]. Proceedings IEEE INFOCOM， 1970， 3（5）：11761183.

責(zé)任編輯（責(zé)任編輯：杜能鋼）