高性能HTTPS服務中的TIME_WAIT分析

杜旻翔

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

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

DOIDOI：10.11907/rjdk.162886

中圖分類號：TP393

文獻標識碼：A文章編號文章編號：16727800（2017）005015503

0引言

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

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

1網絡模型

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

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

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

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

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

2.1數學建模

首先對過程進行描述，關閉過程：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，結束。最后一個ACK狀態(tài)由主動關閉連接的一段發(fā)出，并且在發(fā)出之后進入TIME_WAIT狀態(tài)。如果ACK狀態(tài)丟失，B端會重新發(fā)出FIN請求ACK，保證全雙工連接終止[5]。如果所有的TCP連接都由服務器端關閉，則每個連接都會保持一個TIME_WAIT（后文使用TW代稱）狀態(tài)并持續(xù)兩個最大分節(jié)生命周期。

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

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

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

TW對網絡、服務器的性能影響主要關注4個指標：

（1）網絡連接效率：當用戶數為N時，在正常流程下有效連接占全部連接的數據比例。

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

（3）TFA（time-to-first-ack）：用戶首次關閉連接耗時。

（4）TSA（time-to-second-ack）：用戶再次關閉連接耗時。

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

2.2式（2）條件下討論

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

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

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

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

2.3 式（3）條件下討論

網絡連接效率見式（3），顯然t參數越小網絡連接效率越高。當t∈[t2，240]時，t越小越好，最優(yōu)值應該為t2。

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

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

3仿真驗證

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

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

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

在修改TIME_WAIT時間長度值之后，服務器各項指標都隨著TIME_WAIT時間長度的變化而變化，以第一次實驗數據作為基準數據，記錄之后參數的變化。

4結語

本文討論了TIME_WAIT時間長度對服務器性能指標的影響，從兩種不同的場景進行了分析。

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

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

參考文獻參考文獻：

[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].合肥：中國科學技術大學，2012.

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

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

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

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

責任編輯（責任編輯：杜能鋼）