1. 程式人生 > >TCP堅持定時器,TCP保活定時器

TCP堅持定時器,TCP保活定時器

TCP一共有四個主要的定時器,前面已經講到了超時定時器,2MSL定時器,(MSL是指任何報文段被丟棄前在網路內的最長存活時間)另外的兩個是:

堅持定時器

1,     堅持定時器的意義;

在TCP連線雙方,均有一個接收快取,當接收快取滿時,接收端會回覆傳送端一個視窗大小為0的報文,當接收端的接收快取可用時,接收端會再次回覆一個報告視窗大小的報文,但由於ACK報文的傳遞是不可靠的,如若該視窗大小更新的ACK報文丟失,將使得傳送端永遠不會再向接收端傳送資料,因為它還一直以為接收端的快取已滿。即出現死鎖;

為了解決該問題,當接收端回覆傳送端一個視窗為0的報文時,傳送端啟動堅持定時器。定期向接收端傳送一個位元組長度的報文,以確認接收端快取是否可用。值得注意的是,該定時器永遠不會失效,一直到接收端快取可用為止。(沒傳送一次,重新定時,定時的時間採用指數退避的方法);

2,     何時啟動堅持定時器;

因為每次接收到傳送端的報文,都會有一個回覆包(恢復包包含了接收端的通告視窗大小的資訊);當然,實際中並非每一次接收到一個包回覆一個ack,可以是接收到三個包,回覆一個ack;

3,糊塗視窗綜合症

TCP的視窗協議,會引起一種通常叫做糊塗視窗綜合症的問題,具體表現為,當客戶端通告一個小的非零視窗時,伺服器立刻傳送小資料給客戶端並充滿其緩衝區,一來二去就會讓網路中充滿小TCP資料報,從而影響網路利用率。對於傳送方和接收端的這種糊塗行為。TCP給出了一些建議(或者是規定)。

  接收方不通告小視窗。通常的演算法是接收方不通告一個比當前視窗大的視窗(可以為0),除非視窗可以增加一個報文段大小(也就是將要接收的MSS)或者可以增加接收方快取空間的一半,不論實際有多少。

  傳送方避免出現糊塗視窗綜合症的措施是隻有以下條件之一滿足時才傳送資料: ( a )可以傳送一個滿長度的報文段; ( b )可以傳送至少是接收方通告視窗大小一半的報文段; ( c )可以傳送任何資料並且不希望接收ACK(也就是說,我們沒有還未被確認的資料)或者該連線上不能使用Nagle演算法。

保活定時器

在一個空閒的(idle)TCP連線上,沒有任何的資料流,許多TCP/IP的初學者都對此感到驚奇。也就是說,如果TCP連線兩端沒有任何一個程序在向對方傳送資料,那麼在這兩個TCP模組之間沒有任何的資料交換。你可能在其它的網路協議中發現有輪詢(polling),但在TCP中它不存在。言外之意就是我們只要啟動一個客戶端程序,同伺服器建立了TCP連線,不管你離開幾小時,幾天,幾星期或是幾個月,連線依舊存在。中間的路由器可能崩潰或者重啟,電話線可能go down或者back up,只要連線兩端的主機沒有重啟,連線依舊保持建立。

這就可以認為不管是客戶端的還是伺服器端的應用程式都沒有應用程式級(application-level)的定時器來探測連線的不活動狀態(inactivity),從而引起任何一個應用程式的終止。回憶在10.7結束,BGP每隔30秒就向對方傳送一個應用程式探測。這是一個應用程式定時器(application timer),與TCP存活定時器不同。

然而有的時候,伺服器需要知道客戶端主機是否已崩潰並且關閉,或者崩潰但重啟。許多實現提供了存活定時器來完成這個任務。

存活(keepalive)並不是TCP規範的一部分。在Host Requirements RFC羅列有不使用它的三個理由:(1)在短暫的故障期間,它們可能引起一個良好連線(good connection)被釋放(dropped),(2)它們消費了不必要的寬頻,(3)在以資料包計費的網際網路上它們(額外)花費金錢。然而,在許多的實現中提供了存活定時器。

存活定時器是一個包含爭議的特徵。許多人認為,即使需要這個特徵,這種對對方的輪詢也應該由應用程式來完成,而不是由TCP中實現。一些人對這個話題表現了極大的熱情,甚至達到宗教般的狂熱。

如果兩個終端系統之間的某個中間網路上有連線的暫時中斷,那麼存活選項(option)就能夠引起兩個程序間一個良好連線的終止。例如,如果正好在某個中間路由器崩潰、重啟的時候傳送存活探測,TCP就將會認為客戶端主機已經崩潰,但事實並非如此。

一些伺服器應用程式可能代表客戶端佔用資源,它們需要知道客戶端主機是否崩潰。存活定時器可以為這些應用程式提供探測服務。Telnet伺服器和Rlogin伺服器的許多版本都預設提供存活選項。

個人計算機使用者使用TCP/IP協議通過Telnet登入一臺主機,這是能夠說明需要使用存活定時器的一個常用例子。如果某個使用者在使用結束時只是關掉了電源,而沒有登出(log off),那麼他就留下了一個半開啟(half-open)的連線。在圖18.16,我們看到如何在一個半開啟連線上通過傳送資料,得到一個復位(reset)返回,但那是在客戶端,是由客戶端傳送的資料。如果客戶端消失,留給了伺服器端半開啟的連線,並且伺服器又在等待客戶端的資料,那麼等待將永遠持續下去。存活特徵的目的就是在伺服器端檢測這種半開啟連線。

       除非應用程式指明要提供保活的功能,否則就不能使用該功能,同時保活間隔是可配置的,其預設值必須不小於兩個小時;