上一篇中介紹了TCP數據傳輸中涉及的一些基本知識點。本文讓我們看看TCP中的4種定時器。

TCP定時器

對于每個TCP連接，TCP管理4個不同的定時器，下面看看對4種定時器的簡單介紹。

重傳定時器使用于當希望收到另一端的確認。

該定時器是用來決定超時和重傳的。

由于網絡環境的易變性，該定時器時間長度肯定不是固定值;該定時器時間長度的設置依據是RTT(Round Trip Time)，根據網絡環境的變化，TCP會根據這些變化并相應地改變超時時間。

堅持定時器(persist)使窗口大小信息保持不斷流動，即使另一端關閉了其接收窗口。

保活定時器(keepalive)可檢測到一個空閑連接的另一端何時崩潰或重啟。

2MSL定時器測量一個連接處于TIME_WAIT狀態的時間。

參見"動手學習TCP：TCP特殊狀態"中對TIME_WAIT的介紹

下面就介紹一下堅持定時器和?；疃〞r器。

堅持定時器

TCP通過讓接收方指明希望從發送方接收的數據字節數(即窗口大小)來進行流量控制。

如果窗口大小為 0會發生什么情況呢?這將有效地阻止發送方傳送數據，直到窗口變為非0為止。

但是，由于TCP不對ACK報文段進行確認(TCP只確認那些包含有數據的ACK報文段)，如果上圖中通知發送方窗口大于0的[ACK]丟失了，則雙方就有可能因為等待對方而使連接死鎖。接收方等待接收數據(因為它已經向發送方通告了一個非0的窗口)，而發送方在等待允許它繼續發送數據的窗口更新。

為防止這種死鎖情況的發生，發送方使用一個堅持定時器 (persist timer)來周期性地向接收方查詢，以便發現窗口是否已增大。這些從發送方發出的報文段稱為窗口探查(window probe)。

實驗代碼

下面通過Python socket實現一個快的發送端和慢的接收端，然后通過Wireshark抓包來看看窗口更新通知和窗口探查。

客戶端代碼如下，用戶輸入字符，客戶端將用戶輸入重復1000次然后發送給服務端，通過這種簡單的重復來模擬一個快的發送端： 

from socket import *
import time
HOST = "192.168.56.102"
PORT = 8081
ADDR = (HOST, PORT)
client = socket(AF_INET, SOCK_STREAM)
client.connect(ADDR)
while True:
input = raw_input()
if input:
client.send(input*1000)
else:
client.close()
break

對于服務端，通過制定一個小的接收BUFFER，以及一個延時來模擬一個慢的接收端：

import sys
from socket import *
import time
HOST = "192.168.56.102"
PORT = 8081
BUFSIZ = 100
ADDR = (HOST, PORT)
server = socket(AF_INET, SOCK_STREAM)
print "Socket created"
try:
server.bind(ADDR)
except error, msg:
print 'Bind failed. Error Code : ' + str(msg[0]) + ' Message ' + msg[1]
sys.exit()
server.listen(1)
print 'Socket now listening'
conn, addr = server.accept()
while True:
time.sleep(3)
try:
data = conn.recv(BUFSIZ)
if data:
print data
else:
conn.close()
break
except Exception, e:
print e
break

#p#

在開始運行代碼之前還需要進行一些設置，默認情況下接收端的window size很大，實驗中很難耗盡。

所以，為了看到實驗效果，需要對系統進行一些設置。打開虛擬機中的注冊表設置"regedit"，然后找到選項"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters"，設置"TcpWindowSize"為4096Bytes。

注意，實驗結束后，一定要恢復"TcpWindowSize"的原始設置，不然可能會影響正常的網絡訪問。

關于更多TCP相關的注冊表設置，可以參考這個鏈接。

運行效果

下面運行代碼，分別輸入兩個字符"a"和"b"，通過Wireshark可以看到，在進行連接確認的時候，接收端已經給出了我們跟新后的可用窗口4096Bytes。

經過***輪發送后，接收方的window size減少了1000;當兩個數據包都處理完成后，window size又恢復到了4096。

第二輪測試中，發送端發送"1234567890"十個字符，從接收端的***一個[ACK]包可以看到，***接收端window size為1393，此次傳輸到此結束。

過了一段時間，當慢接收端處理完數據之后，接收端會發送窗口更新，通知發送端可以窗口為4096Bytes。

第三輪測試中，發送端發送更多的字符"1234567890987654321"，這次接收端的可用窗口就被耗盡了，然后接收端發送一個[TCP ZeroWindow]的通知;這時，發送端停止發送，然后通過發送窗口探查。

當接收端有可用窗口的時候，接收端會發送窗口更新，數據傳輸繼續。

注意，[TCP ZeroWindowProbe]和[TCP ZeroWindowProbeAck]的Seq和Ack號。

糊涂窗口綜合癥

基于窗口的流量控制方案，會導致一種"糊涂窗口綜合癥SWS(Silly Window Syndrome)"的狀況。

當發送端應用進程產生數據很慢、或接收端應用進程處理接收緩沖區數據很慢，或二者兼而有之;就會使應用進程間傳送的報文段很小，特別是有效載荷很小。 極端情況下，有效載荷可能只有1個字節;而傳輸開銷有40字節(20字節的IP頭+20字節的TCP頭)，加上物理幀頭后，有效的數據傳輸比例就更小了，這就浪費了網絡帶寬，表現為糊涂窗口綜合癥。

糊涂窗口綜合癥可能由接收端或者發送端引起，不同的起因需要不同的解決方案，更多內容可以參考此處。

保活定時器

跟據TCP協議，當發送端和接收端都不主動釋放一個TCP連接的時候，該連接將一直保持。即使一端出現了故障，由于另一端沒有收到任何通知，TCP連接也會一直保持，這樣就會造成TCP連接資源的浪費。

TCP keepalive

為了解決這個問題，大多數的實現中都是使服務器設置?；钣嫊r器。

保活計時器通常設置為2小時。若服務器過了2小時還沒有收到客戶的信息，它就發送探測報文段。若發送了10個探測報文段(每一個相隔75秒)還沒有響應，就假定客戶出了故障，因而就終止該連接。

在Linux系統中，有三個跟TCP keepalive相關的參數：

tcp_keepalive_intvl (integer; default: 75; since Linux 2.4)
The number of seconds between TCP keep-alive probes.
tcp_keepalive_probes (integer; default: 9; since Linux 2.2)
The maximum number of TCP keep-alive probes to send before giving up and killing the connection if no
response is obtained from the other end.
tcp_keepalive_time (integer; default: 7200; since Linux 2.2)
The number of seconds a connection needs to be idle before TCP begins sending out keep-alive probes. Keep-
alives are sent only when the SO_KEEPALIVE socket option is enabled. The default value is 7200 seconds (2
hours). An idle connection is terminated after approximately an additional 11 minutes (9 probes an interval
of 75 seconds apart) when keep-alive is enabled.

在Socket編程中，可以通過設置"TCP_KEEPCNT"，"TCP_KEEPIDLE"和"TCP_KEEPINTVL"選項來更改上述的三個系統參數：

from socket import *
import time
HOST = "192.168.56.102"
PORT = 8081
ADDR = (HOST, PORT)
client = socket(AF_INET, SOCK_STREAM)
#TCP_KEEPCNT overwrite tcp_keepalive_probes，默認9(次)
#TCP_KEEPIDLE overwrite tcp_keepalive_time，默認7200(秒)
#TCP_KEEPINTVL overwrite tcp_keepalive_intvl，默認75(秒)
client.setsockopt(SOL_SOCKET, SO_KEEPALIVE, 1)
client.setsockopt(SOL_TCP, TCP_KEEPCNT, 5)
client.setsockopt(SOL_TCP, TCP_KEEPINTVL, 5)
client.setsockopt(SOL_TCP, TCP_KEEPIDLE, 10)
client.connect(ADDR)
while True:
input = raw_input()
if input:
client.send(input*1000)
else:
client.close()
break

#p#

TCP keepalive 包

下面是一段網絡上抓取的TCP keepalive包，接下來看看TCP keepalive包的內容。

根據規范，TCP keepalive?；畎粦摪瑪祿?，但也可以包含1個無意義的字節，比如0x0。

TCP保活探測包Seq號是將前一個TCP包的Seq號減去1。

當然，也有人認為保活定時器不合理，給出了不使用?；疃〞r器的理由：

在出現短暫差錯的情況下，這可能會使一個非常好的連接釋放掉

耗費了不必要的帶寬

在按分組計費的情況下會在互聯網上花掉更多的錢

HTTP Keep-Alive

在HTTP早期 ，每個HTTP請求都要求打開一個TCP連接，并且使用一次之后就斷開這個TCP連接。

這種方式會帶來一些問題，尤其是包含圖片，JS，CSS的復雜網頁，一個完整的頁面需要很多個請求才能完成，如果每一個HTTP請求都需要新建并斷開一個TCP，這樣就會消耗很多服務器的TCP連接資源。

為了緩解這個問題，HTTP 1.1中出現了Keep-Alive這個特性，開啟HTTP Keep-Alive之后，能復用已有的TCP鏈接，當前一個請求已經響應完畢，服務器端沒有立即關閉TCP鏈接，而是等待一段時間接收瀏覽器端可能發送過來的第二個請求，開啟Keep-Alive能節省的TCP建立和關閉的消耗。

下面看看我訪問一個網頁后，通過Wireshark抓取的數據包。

HTTP/1.1之后默認開啟Keep-Alive, 在HTTP的頭域中增加Connection選項。當設置為"Connection:keep-alive"表示開啟，設置為"Connection:close"表示關閉。

在上圖中，服務器經過了大概2分鐘的時間，然后發出關閉TCP連接的請求。

現在，基本所有的應用服務器都支持設置打開Keep-Alive，以及Keep-Alive timeout的設置。

總結

本文介紹了TCP中的4種定時器，并詳細的介紹了堅持定時器和保活定時器。

在?；疃〞r器的介紹中，對比介紹了HTTP的Keep-Alive特性。HTTP協議的Keep-Alive意圖在于連接復用;TCP的keepalive機制在于?；?、心跳，檢測連接錯誤，兩者的作用完全不同。

因為TCP keepalive不能滿足實時性的要求，很多應用程序會在應用層實現heart beat(心跳包)來確認TCP連接的可用性。