【文章內容簡介】 Halfclose 半關閉 Host A Host B 1 Send FIN (FIN,seq=X) FIN received Send ACK (ACK=X+1) Host A Host B ACK received 1 2 Send FIN (FIN,seq=X) Halfclose 全關閉 FIN received Host A Host B 1 Send FIN (FIN,seq=X) FIN received Send ACK,FIN (FIN,seq=y,ACK=X+1) Host A Host B FIN,ACK received 1 2 Send FIN (FIN,seq=X) FIN received Send ACK,FIN (FIN,seq=y,ACK=X+1) Host A Host B FIN,ACK received 1 2 Send FIN (FIN,seq=X) 3 Send ACK,FIN (FIN,ACK=Y+1) Fullclose 全關閉 連接建立與終止的時間系列 初始序列號 ISN ? 當一端為建立連接而發(fā)送它的 SYS時，它為連接選擇一個初始序號。 ISN隨時間而變化，因此每個連接都將具有不同的 ISN。 ? 在 4 . 4 B S D（和多數(shù)的伯克利的實現(xiàn)版）中，系統(tǒng)初始化時初始的發(fā)送序號被初始化為 1，這個變量每 8 ms加 1，另外，每次建立一個連接后，這個變量將增加 64000。 連接終止期間報文段的正常交換 三、 連接建立的超時 有很多情況導致無法建立連接。如： ? 服務器主機沒有處于正常狀態(tài)。 ? 服務器忙 B S D版的 T C P軟件采用一種 500 ms的定時器 ? 當我們鍵入一個命令（如 t e l n e t）后，將建立一個 6秒的定時器（ 1 2個時鐘滴答（ t i c k）），但它可能在之后的 5 . 5秒 ~ 6秒內的任意時刻超時。 ? 盡管定時器初始化為 1 2個時鐘滴答，但定時計數(shù)器會在設置后的第一個 0~500 ms中的任意時刻減 1。從那以后，定時計數(shù)器大約每隔 500 ms減 1，但在第 1個 500 ms內是可變的（我們使用限定詞 “ 大約 ” 是因為在 T C P每隔500 ms獲得系統(tǒng)控制的瞬間，系統(tǒng)內核可能會優(yōu)先處理其他中斷）。 TCP的 500 ms定時器 當?shù)未鹩嫈?shù)器為 0時， 6秒的定時器便會超時，這個定時器會在以后的 2 4秒（ 4 8個滴答）重新復位。之后的下一個定時器將更接近 2 4秒，因為當 T C P的 500 ms定時器被內核調用時，它就會被修改一次。 四、最大報文段長度 MSS ? MSS表 示 TCP報文段的數(shù)據(jù)長度 ? 當一個連接建立時，連接的雙方都要通告各自的MSS。 ? 當建立一個連接時，每一方都有用于通告它期望接收的 M S S選項（ M S S選項只能出現(xiàn)在 S Y N報文段中）。 ? 如果一方不接收來自另一方的 M S S值，則 M S S就定為默認值 5 3 6字節(jié) . MSS的大小 ? 如果沒有分段發(fā)生， MSS越大越好。 ? 當 T C P發(fā)送一個 S Y N時，或者是因為一個本地應用進程想發(fā)起一個連接，或者是因為收到了另一端主機的一個連接請求，它能將 M S S值設置為外出接口上的 M T U長度減去固定的 I P首部和T C P首部長度。 ? 如果目的 I P地址為 “ 非本地的， M S S通常的默認值為 5 3 6。 五、復位報文段 ? 一般說來，無論何時一個報文段發(fā)往基準的連接出現(xiàn)錯誤， T C P都會發(fā)出一個復位報文段。如： ? 到不存在的端口的連接請求 ? 異常終止一個連接 ? 檢測半打開連接 到不存在的端口的連接請求 ? 產生復位的一種常見情況是當連接請求到達時，目的端口沒有進程正在聽。 ? 對于 U D P，當一個數(shù)據(jù)報到達目的端口時，該端口沒在使用，它將產生一個 I C M P端口不可達的信息。 ? 而 T C P則使用復位 異常終止一個連接 ? 在排隊數(shù)據(jù)都已發(fā)送之后才發(fā)送 F I N，正常情況下沒有任何數(shù)據(jù)丟失。但也有可能發(fā)送一個復位報文段而不是 F I N來中途釋放一個連接，稱這為異常釋放。異常終止一個連接對應用程序來說有兩個優(yōu)點： ? （ 1）丟棄任何待發(fā)數(shù)據(jù)并立即發(fā)送復位報文段； ? （ 2） R S T的接收方會區(qū)分另一端執(zhí)行的是異常關閉還是正常關閉。 ? 應用程序使用的 A P I必須提供產生異常關閉而不是正常關閉的手段。 檢測半打開連接 ? 如果一方已經關閉或異常終止連接而另一方卻還不知道，我們將這樣的 T C P連接稱為半打開的。任何一端的主機異常都可能導致發(fā)生這種情況。只要不打算在半打開連接上傳輸數(shù)據(jù)，仍處于連接狀態(tài)的一方就不會檢測另一方已經出現(xiàn)異常。 ? 如果服務器突然斷電又重新啟動其 T C P ，它將丟失復位前連接的所有信息，因此它不知道數(shù)據(jù)報文段中提到的連接。 ? T C P的處理原則是接收方以復位作為應答 六、同時打開 七、同時關閉 八、 TCP選項 RFC793 RFC1323 TCP 的 狀 態(tài) 變 遷 圖 CLOSED ESTABLISHED LISTEN CLOSE_WAIT FIN_WAIT_1 SYN_RCVD FIN_WAIT_2 CLOSING TIME_WAIT SYN_SENT LAST_ACK 主動打開 被動打開 被動關閉 主動關閉 起點 被動打開 主動打開 發(fā)送 SYN 同時打開 收到 SYN，發(fā)送 SYN, ACK 收到 ACK 數(shù)據(jù)傳送 階段 關閉 發(fā)送 FIN 關閉 發(fā)送 FIN 關閉 發(fā)送 FIN 收到 RST 收到 SYN 發(fā)送 SYN, ACK 關閉 或超時 收到 ACK 收到 SYN, ACK 發(fā)送 ACK 收到 ACK 收到 ACK 收到 FIN 發(fā)送 ACK 收到 FIN, ACK 發(fā)送 ACK 收到 FIN 發(fā)送 ACK 同時關閉 收到 FIN 發(fā)送 ACK 發(fā)送 SYN 定時經過兩倍報文段壽命后 關閉 TCP正常連接建立和終止所對應的狀態(tài) TCP的數(shù)據(jù)傳輸 ? 包括 交互數(shù)據(jù)流 和 成塊數(shù)據(jù)流 ? 若按分組數(shù)量計算，約有一半的 T C P報文段包含成塊數(shù)據(jù)（如 F T P、電子郵件和 U s e n e t新聞），另一半則包含交互數(shù)據(jù)（如 Te l n e t和 R l o g i n）。 ? 若按字節(jié)計算，則成塊數(shù)據(jù)與交互數(shù)據(jù)的比例約為 9： 1 。 ? T C P需要同時處理這兩類數(shù)據(jù)，但使用的處理算法則有所不同。 一、 TCP的交互數(shù)據(jù)流 ? 輸入 Rlogin 或 Tel后會產生 4個報文段： ? （ 1）來自客戶的交互按鍵； ? （ 2）來自服務器的按鍵確認； ? （ 3）來自服務器的按鍵回顯； ? （ 4）來自客戶的按鍵回顯確認。 一般可以將報文段 2和 3進行合并 —按鍵確認與按鍵回顯一起發(fā)送（捎帶確認）。 Tel有一個選項允許客戶發(fā)送一行到服務器，通過使用這個選項可以減少網絡的負載。 ? 在象 R l o g i n這樣的連接上客戶一般每次發(fā)送一個字節(jié)到服務器，這就產生了一些 4 1字節(jié)長的分組： 2 0字節(jié)的 I P首部、 2 0字節(jié)的 T C P首部和 1個字節(jié)的數(shù)據(jù)。 ? 在局域網上，這些小分組（被稱為微小分組）通常不會引起麻煩，因為局域網一般不會出現(xiàn)擁塞。 ? 但在廣域網上，這些小分組則會增加擁塞出現(xiàn)的可能。 ? 一種簡單和好的方法就是采用 N a g l e算法 RFC 896 Nagle算法 ? 若數(shù)據(jù)是逐個字節(jié)到達發(fā)送端，則發(fā)送端就將第一個字節(jié)發(fā)送出去，并將后面到達的字節(jié)緩存起來。 ? 當收到對第一個字節(jié)的確認后，再將緩存中的所有字符組裝成一個報文發(fā)送出去，同時繼續(xù)對到達的字符進行緩存。 ? 只有在收到確認后才發(fā)送下一個報文。 ? 為解決字符到達快、網絡速度慢的情況，還規(guī)定：當?shù)竭_的字節(jié)達到窗口大小的一半或者已達到報文的最大長度時，就立即發(fā)送下一個報文。 ? 雖然 Nagle算法已被很多 TCP程序采用，但是有時候最好不用。 ? 如：在 Inter上使用 XWindows，小消息（鼠標移動）必須無時延地發(fā)送，以便為進行某種操作的交互用戶提供實時的反饋。 ? 當服務器接收到該字符后，它并不發(fā)送確認，而是繼續(xù)等待接收序列中的其他字符。 ? 對交互用戶而言，這將產生明顯的時延，使用戶無法忍受，這時最好關閉這個算法。 糊涂窗口綜合癥 ? 接受端的緩存已滿，而交互式的應用進程一次只從緩存中讀取 1個字符，然后向發(fā)送端發(fā)確認，并通知窗口為 1字節(jié)（發(fā) 40字節(jié)的 IP報文）。 ? 接著，發(fā)送端又發(fā)來 1個字節(jié)（發(fā) 41字節(jié)的 IP報文）。 ? 接收端發(fā)確認，仍然通知窗口為 1字節(jié)。如此進行下去 … ? 使得網絡效率非常低 兩種解決方法 ? Clark方法：禁止接收方發(fā)送 1字節(jié)的窗口，而是讓接收端等待一段時間，等到緩存能容納一個最長的報文段，或者空出一般的空間，才發(fā)送確認。 ? 發(fā)送端不要發(fā)送太小的報文段，而是將數(shù)據(jù)積累成足夠大的報文段，或者當接收端有一半的空閑緩存時才發(fā)送。 ? 這兩種方法可配合使用 ? 交互數(shù)據(jù)總是以小于最大報文段長度的分組發(fā)送 二、 TCP的成塊數(shù)據(jù)流 ? TCP 采用大小可變的滑動窗口進行流量控制 。 窗口大小的單位是 字節(jié) 。 ? 在 TCP 報文段首部的窗口字段寫入的數(shù)值就是當前給對方設置的發(fā)送窗口數(shù)值的上限 。 ? 發(fā)送窗口在連接建立時由雙方商定 。 但在通信的過程中 ，接收端可根據(jù)自己的資源情況 ， 隨時動態(tài)地調整對方的發(fā)送窗口上限值 (可增大或減小 )。 TCP 的可變滑動窗口 發(fā)方 收方 Window size = 3 Send 2 Window size = 3 Send 1 Window size = 3 Send 3 發(fā)方 收方 Window size = 3 Send 2 Window size = 3 Send 1 Window size = 3 Send 3 ACK 3 Window size = 2 Packet 3 is Dropped 發(fā)方 收方 Window size = 3 Send 2 Window size = 3 Send 1 Window size = 3 Send 3 ACK 3 Window size = 2 Packet 3 is Dropped Window size = 2 Send 4 Window size = 2 Send 3 發(fā)方 收方 Window size = 3 Send 2 Window size = 3 Send 1 Window size = 3 Send 3 ACK 3 Window size = 2 Packet 3 is Dropped Window size = 2 Send 4 Window size = 2 Send 3 ACK 5 Window size = 2 Window size = 3 發(fā)方 收方 收到確認即可前移