一、tcp介紹首選，tcp提供客戶端與伺服器之間的連線。tcp客戶端先與某個給定的伺服器建立乙個連線，在跨該連線與伺服器交換資料，然後終止這個連線。
1、tcp提供了可靠性，當tcp向另一端傳送資料時，它要求對端返回乙個確認，如果沒有收到確認，tcp就會自動重新傳遞資料並等待更長時間，在數次衝傳之後，tcp才放棄，如此在嘗試傳送資料上所花的總時長一般為4-10分鐘（依賴具體實現）。
（1.1）tcp並不保證資料一定會被對方端點接收到，因為這是不可能實現的。如果有可能，tcp就把資料傳遞到對方端點，否則就（通過放棄重新並中斷連線這一手段）通知使用者，這麼來說，tcp也不能被描述成為100%可靠的協議，它提供的是資料的可靠遞送或故障的可靠通知。
2、tcp含有用於動態估算客戶和伺服器之間的往返時間（ rtt）演算法，以便它知道等待乙個確認的時間，舉例來說，rtt在乙個區域網上大概是幾毫秒，跨越乙個廣域網則可能是數秒鐘，另外，因為rtt受網路流通各種變化因素，tcp還持續估計乙個給定連線的rtt。
3、tcp通過給其中每個位元組關聯乙個序列號對所傳送的資料進行排序。舉例來說，假設乙個應用寫2048位元組到乙個tcp套接字，導致tcp傳送2個資料報，第乙個包所含資料的序列號為1-1024，第二個包所含資料的序列號為1025-2048。如果這些分節非順序達到，接收端tcp將先根據它們的序列號重新排序，在把結果資料給接受應用。如果接收端tcp接收來自對端的重複資料（比如說對端認為乙個分節已丟失並因此重傳，而這個分節沒有重新丟失，只是由於網路通訊過於擁擠），它可以（根據序列號）判斷資料是重複的，從而丟棄重複資料。
udp不提供可靠性，udp本身不提供確認、序列號、rtt估算，超時和重傳的機制。如果乙個udp資料報在網路中被複製，兩份副本就可能都遞送到接收端的主機。同樣地，如果乙個udp客戶端傳送兩個資料報到同乙個目的地，他們可能被網路重新排序，顛倒順序後到達目的地。udp應用必須處理所有的這些情況。
4、再次，tcp提供流量控制（flow control）。tcp總是告知對端在任何時刻它一次能夠從對端接受多少位元組的資料，這稱之為通告視窗，在任何時候，該窗指出接受緩衝區當前可用的空間量，從而確保傳送端傳送的資料不會使接受緩衝區溢位。該視窗時刻動態變化，當接受到來傳送端的資料時，視窗大小就減少，但是當接收端應用從緩衝區中讀取資料時，視窗大小就增大，通知視窗大小減少到0是有可能的：當tcp對應某個套接字的接受緩衝區已滿，導致它必須等待應用從該緩衝區讀取資料時，方能從對端在接受資料。
udp 不提供流量控制，
5、最後 tcp 連線是全雙工的 full -duplex，這意味著在乙個給定的連線上應用可以在任何時候在進出兩個方向傳送資料又接受資料，因此，tcp必須為每個資料流方向跟蹤如序列號和通告視窗大小等資訊。
udp 可以是全雙工的。
二、tcp連線的建立和終止1、三次握手
(1) 伺服器必須準備好接受外來的連線，這通常通過呼叫socket、bind 和 listen 這三個函式來完成，我們稱之為被動開啟（passive open）。
（2）客戶通過呼叫 connect 發起主動開啟（active open）這導致客戶tcp傳送乙個syn（同步）分節，它告訴伺服器客戶將在 連線中傳送的資料的初始序列號，通常syn分接 不攜帶資料，其所在ip資料報只有乙個ip首部、乙個tcp首部及可能有的tcp選項。
（3）服務端必須確認（ack）客戶端的syn, 同時自己也得傳送乙個syn分節，它含有伺服器將在同一連線中傳送的資料的初始序列號，伺服器在單個分節點中傳送syn和對客戶端的ack(確認)、
（4）客戶端必須確認伺服器的syn。
如圖。客戶端的初始序列號為j，伺服器的初始序列號為k，ack中的確認號是傳送這個ack的一端所期待的下乙個序列號。因為syn佔據乙個位元組的序列號空間，所以每乙個syn的ack中的確認號就是該syn序列號加1，類似的，每乙個fin的結束的ack的包的fin的序列號也加1。
三、tcp 選項每乙個syn可以含有多個tcp選項。下面是常用的tcp選項。
mss 選項。傳送syn的tcp一端使用本選項通告對端的最大分節大小，既mss, 也就是它在本連線的每個tcp分節中願意接受的最大資料量。傳送端tcp使用接受端的mss值作為所傳送分節的最大大小。tcp_maxseg套接字選項提取和設定這個tcp選項。
視窗規模選項。tcp連線任何一端能夠通告對端的最大視窗大小是65535，因為在tcp首部中相應的字段佔16位。然而當今網際網路上業已普及的高速網路速度要求有更大的視窗獲得盡可能大的吞吐量。這個選項指定tcp首部中的視窗必須擴大。因此所提供的最大視窗接近1gb，在乙個tcp連線上使用視窗的前提是它的兩個端系統必須支援這個選項。我們將使用so_rcvbuf套接字選項影響這個tcp選項。
為提供與不支援這個選項的較早實現間的互操作性，需應用如下規則，tcp可以作為主動開啟的的部分內容隨它的syn傳送該選項，但是只在對端也隨它的syn傳送該選項的前提下，它才能擴大自己視窗的規模。類似的，伺服器的tcp只能接受到隨客戶端的syn達到的改選項時，才能傳送該選項。
時間戳選項，這個選項對於高速網路連線是必要的，它可以防止失而復現的分組可能造成的資料損壞，它是乙個較新的選項，也類似於視窗規模選項的方式協商處理，作為網路程式設計人員，不需要考慮這個選項。
四、tcp連線終止tcp建立乙個連線需3個分節，終止乙個連線需要4個分節。
（1）某個應用程序首先呼叫close，我們稱該端執行主動關閉（active close)，該端的tcp於是傳送了乙個fin分節，表示資料傳送完畢。
（2）接收到這個fin的對端執行被動關閉（passive close），這個fin由tcp 確認。它的接受也作為乙個檔案結束符（end-of-line），傳遞給接收端的應用程序（放在已排隊等候該應用程序接受的任何其他資料之後），因為fin的接收意味著接收端的應用在相應的連線上再無額外資料可接受。
（3）一段時間之後，接收到這個檔案結束符的應用程序將呼叫close關閉它的套接字。這導致它的tcp也傳送乙個fin。
（4）接收這個最終的fin 的原傳送端tcp（既執行主動的關閉的那一段）確認這個fin。
五、time_wait狀態任何的tcp實現都必須為msl選擇的乙個值。 rfc 的建議是2分鐘，不過源自berkeley的實現傳統上改用30秒這個值。這意味著time_wait狀態的持續時間在1分鐘到4分鐘之間。msl是任何ip資料能夠在網際網路中存活的時間。我們知道這個時間是有限的，因為每個資料報含有乙個稱為跳限 的 8位欄位，它的最大值為255，儘管這是乙個跳數限制而不是真正的時間限制，我們仍然假設：最大跳限（255）的分組在網路中存在的時間不可能超過msl秒。
分組在網路中 「迷途」通常是路由異常的結果。某個路由器崩潰或者兩個路由器之前的每個鏈路斷開時，路由協議需要花數秒鐘到數分鐘的時間才能穩定並找到一條出路。在這段時間內可能發生路由迴圈（路由器a把分組傳送給路由器b，而b在把太慢傳送給a), 我們關心的分組可能就此陷入這樣的迴圈。假設迷途的分組是乙個tcp分節，在它迷途的期間，傳送端tcp超時並重傳該分組，而重傳的分組卻通過某條候選路徑達到最終的目的地。然後不久之後（迷途的分組開始其旅程起最多msl秒以內）路由迴圈修復，在之前的分組也被重新送到給目的地。這個原來的分組稱之為迷途的重複分組或者漫遊的重複分組。tcp必須正確處理這些分組。
time_wait狀態有來兩個理由存在：
1、可靠地實現tcp全雙工連線的中斷。
2、允許老的重複分節在網路中消逝。
第乙個理由可以看到如上圖的最後乙個ack丟失來解釋。伺服器將重新傳送它的最後的fin，因此客戶必須維護狀態資訊，以允許它重新傳送那個ack。要是客戶端不維護狀態資訊，它將相應乙個rst (另一種型別的tcp分節)，該分節將被伺服器解釋成乙個錯誤。如果tcp打算執行所有的工作以徹底終止序列4個分節中任何乙個分節丟失的情況。
第二個理由，我們假設在12.106.32.254 的1500端和206.168.112.219的21埠之間有乙個tcp連線。如果我們關閉這個連線，不存在time_wait的狀態，過一段時間後在相同的ip位址和埠之前建立這個連線。埠和ip也相同。那麼就會出現包錯亂的問題，tcp必須防止來自老的重複的連線再現。所以要存在乙個time_wait的狀態。既然time_wait狀態的持續時間是msl的兩倍。這就足以讓之前已經錯亂的包丟棄。通過這個規則，我們就能保住，每次建立乙個新的tcp連線，之前的重複的連線的資料報就會在網路中消逝掉。
TCP四次揮手中的TIME WAIT狀態存在的理由
1 第一次揮手 client傳送乙個fin，用來關閉client到server的資料傳送，client進入fin wait 1狀態。2 第二次揮手 server收到fin後，傳送乙個ack給client，確認序號為收到序號 1 與syn相同，乙個fin占用乙個序號 server進入close wai...
tcp三次握手和time wait
第一次握手 建立連線時，客戶端傳送syn包和乙個隨機序列號seq x到伺服器，並進入syn send狀態，等待伺服器進行確認。syn，同 步序列編號 第二次握手，伺服器收到syn包，必須確認客戶的syn，然後伺服器傳送乙個ack 1,syn 1,seq y的隨機數和ack x 1的確認數的包傳送回去...
TCP連線的TIME WAIT狀態
time wait狀態是tcp的11個狀態其中之一，是發生在正常關閉tcp連線的時候發生的。如下圖所示 在這幅圖中我們可以明顯看出，流程是這樣的，顯示主動傳送乙個fin報文，然後接收到乙個ack報文，這樣這一方的連線已經關閉，也就是不能再傳送資料了，進入fin wait2狀態，這個狀態就是為了等待，...