端口号調研、URG和PSH、及TCP的計時器

端口号

端口号是用來辨別目的主機當中的唯一網絡程序，是以IP位址+端口号=》套接字；套接字可以确定唯一的一個程序。

Tcp/Ip協定中引入一種叫做“套接字”的應用程式軟體，有了這樣一種技術，一台電腦就可以與任意一台具有套接字的電腦通信。

端口的分類：

從性質來分：

1）公認端口：0—1024，緊密綁定一些特定的服務，這類端口不可重新定義它的作用對象，例如80号端口對應http，23号端口對應Telnet服務

2）注冊端口：1025-49151，這些端口多數沒有明确的定義服務對象，不同程式可以根據實際需要自己定義，

3）動态和/或私有端口：49152-65535，不應把常用服務配置設定在這些端口上，一些木馬程式非常喜歡用這些端口；

根據所提供的服務方式不同可以分為TCP相關端口和UDP相關端口；

TCP類的有：

1）FTP：21号檔案傳輸端口；下載下傳檔案，上傳首頁；

2）Telnet:23遠端登陸端口，使用者可以以自己的身份遠端登陸到電腦上，通過這種端口可以提供一種Dos服務下的通信模式；

3）SMTP：25簡單郵件傳送協定；

4）POP3：110端口，和SMTP類似，用于接受郵件；

UDP類的有：

1）HTTP:80号超文本傳輸協定，常用的“WWW服務”，“web服務”就是這個端口

2）DNS：53号，域名解析服務；

3）SNMP：161号，簡單網絡管理協定；

4）OICQ:既接收服務又提供服務；OICQ伺服器采用8000号端口，傾聽是否有資訊到來，OICQ則采用4000号端口，向外發送資訊；

URG和PSH

1、URG推送位

緊急資料的起始點=序号；

緊急資料的終止點=序号+緊急指針；

（綜上，緊急指針就是記錄緊急資料的位元組數，緊急指針永遠為正數）

1）在緊急資料後面的資料為普通資料，需要按序緩存

2）視窗為0也可以發送緊急資料

3）緊急資料都處理完成後，tcp就告訴程序恢複到正常操作

例如，已經發送了很長的一個程式要在遠地的主機上運作。但後來發現了一些問題，需要取消程式的運作。是以使用者從鍵盤發出中斷指令（Ctrl+C）。如果不使用緊急資料，那麼這兩個字元會被存儲在接受TCP的緩存末尾。隻有在所有的資料被處理完畢後這兩個字元才會被傳遞給接收方。這樣就浪費了很多時間。

URG強調的是直接讀取資料,我們不會将該資料複制到緩存中,我個人認為,這個資料(緊急指針指向的資料)并不是真正意義上的”資料”,而是對真正意義上”資料”的一種操作.

2、PSH推送位

PSH=1，該封包希望，到達對端時，将這個封包及緩存區之間緩存尚未傳遞的資料一并傳遞給程序。

1)PSH的資料=本封包資料+緩存區資料

2)PSH的方向—>單方向（接收PSH封包的一端）

PSH強調的是盡快将資料傳遞給上層(協定),而不需要經過強迫資料互動(預設tcp/ip是将資料緩存到一定的上限,再将資料遞交給上層,以提高網絡性能).可見,該部分資料是需要複制到緩存中的

3、差別

URG傳遞給程序的資料：隻有緊急資料

PSH傳遞給程序的資料：緩沖區排好序的資料及目前封包中的資料

兩者的共同點：都是一種對資料的處理方式.隻不過URG是處理在前端(收到資料後立馬對真正意義上”資料”進行操作,是以說”緊急.而PSH是在處理的後端,告訴核心,不用等待”滿了”再遞交資料遞交到上層.

TCP的計時器

TCP使用四種定時器(Timer，也稱為“計時器”)：

重傳計時器：Retransmission Timer

堅持計時器：Persistent Timer

保活計時器：Keeplive Timer

時間等待計時器：Time_Wait Timer。

1、重傳計時器：Retransmission Timer

重傳定時器：為了控制丢失的封包段或丢棄的封包段，也就是對封包段确認的等待時間。當TCP發送封包段時，就建立這個特定封包段的重傳計時器，可能發生兩種情況：若在計時器逾時之前收到對封包段的确認，則撤銷計時器;若在收到對特定封包段的确認之前計時器逾時，則重傳該封包，并把計時器複位;重傳時間=2*RTT;

RTT的值應該動态計算。常用的公式是：RTT=previous RTT*i + (1-i)*current RTT。i的值通常取90%，即新的RTT是以前的RTT值的90%加上目前RTT值的10%.

Karn算法：對重傳封包，在計算新的RTT時，不考慮重傳封包的RTT。因為無法推理出：發送端所收到的确認是對上一次封包段的确認還是對重傳封包段的确認。幹脆不計入。

2、堅持計時器：persistent timer

專門為對付零視窗通知而設立的。

當發送端收到零視窗的确認時，就啟動堅持計時器，當堅持計時器截止期到時，發送端TCP就發送一個特殊的封包段，叫探測封包段，這個封包段隻有一個位元組的資料。探測封包段有序号，但序号永遠不需要确認，甚至在計算對其他部分資料的确認時這個序号也被忽略。探測封包段提醒接收端TCP，确認已丢失，必須重傳。

堅持計時器的截止期設定為重傳時間的值，但若沒有收到從接收端來的響應，則發送另一個探測封包段，并将堅持計時器的值加倍和并複位，發送端繼續發送探測封包段，将堅持計時器的值加倍和複位，知道這個值增大到門檻值為止(通常為60秒)。之後，發送端每隔60s就發送一個封包段，直到視窗重新打開為止;補充：

堅持定時器的原理是簡單的，當TCP伺服器收到了用戶端的0滑動視窗封包的時候，就啟動一個定時器來計時，并在定時器溢出的時候向向用戶端查詢視窗是否已經增大，如果得到非零的視窗就重新開始發送資料，如果得到0視窗就再開一個新的定時器準備下一次查詢。通過觀察可以得知，TCP的堅持定時器使用1，2，4，8，16……64秒這樣的普通指數退避序列來作為每一次的溢出時間。

糊塗視窗綜合症

TCP的視窗協定，會引起一種通常叫做糊塗視窗綜合症的問題，具體表現為，當用戶端通告一個小的非零視窗時，伺服器立刻發送小資料給用戶端并充滿其緩沖區，一來二去就會讓網絡中充滿小TCP資料報，進而影響網絡使用率。對于發送方和接收端的這種糊塗行為。

再次補充：

TCP通過讓接收方指明希望從發送方接收的資料位元組數(即視窗大小)來進行流量控制。如果視窗大小為 0會發生什麼情況呢?這将有效地阻止發送方傳送資料，直到視窗變為非0為止。

TCP不對ACK封包段進行确認， TCP隻确認那些包含有資料的ACK封包段。

如果一個确認丢失了(這個确認是”接收方“向”發送方“發送的ACK，通知”發送方“自己的視窗已經非0了)，則雙方就有可能因為等待對方而使連接配接終止：接收方等待接收資料(因為它已經向發送方通告了一個非 0的視窗)，而發送方在等待允許它繼續發送資料的視窗更新。為防止這種死鎖情況的發生，發送方使用一個堅持定時器 (persist timer)來周期性地向接收方查詢，以便發現視窗是否已增大。這些從發送方發出的封包段稱為視窗探查 (window probe)。

3、保活計時器：keeplive timer

每當伺服器收到客戶的資訊，就将keeplive timer複位，逾時通常設定2小時，若伺服器超過2小時還沒有收到來自客戶的資訊，就發送探測封包段，若發送了10個探測封包段(沒75秒發送一個)還沒收到響應，則終止連接配接。

補充：

保活定時器更加的簡單，還記得FTP或者Http伺服器都有Sesstion Time機制麼?因為TCP是面向連接配接的，是以就會出現隻連接配接不傳送資料的“半開放連接配接”，伺服器當然要檢測到這種連接配接并且在某些情況下釋放這種連接配接，這就是保活定時器的作用。其時限根據伺服器的實作不同而不通。另外要提到的是，當其中一端如果崩潰并重新啟動的情況下，如果收到該端“前生”的保活探察，則要發送一個RST資料封包幫助另一端結束連接配接。

4、時間等待計時器：Time_Wait Timer

在連接配接終止期使用，當TCP關閉連接配接時，并不認為這個連接配接就真正關閉了，在時間等待期間，連接配接還處于一種中間過度狀态。這樣就可以時重複的fin封包段在到達終點後被丢棄，這個計時器的值通常設定為一格封包段壽命期望值的兩倍。