電腦網路 學習筆記-傳輸層：TCP協議簡介

標籤：

概述：

• TCP傳輸前先要建立串連
• TCP在傳輸層
• 點對點，一條TCP只能串連兩個端點
• 可靠傳輸、無差錯、不丟失、不重複、按順序
• 全雙工系統
• 位元組流

TCP報文段

TCP報文段的前序前20位元組是固定的，後面4n位元組是根據需要而添加的。

20位元組的固定部分：

• 源連接埠和目的連接埠：分別寫入源連接埠號碼和目的連接埠號碼
• 序號：0-(2^32-1),本報文段資料的第一個位元組的序號，用來解決亂序問題
• 確認序號：期望收到對方下一個報文段的第一個資料位元組的序號，用來解決丟包問題
• 資料位移：TCP前序長度，包括固定的20位元組和選項欄位
• 保留：均為0
• 控制位：說明報文的性質，操控TCP的狀態機器

• 視窗：指寄件者自己的接收視窗大小，流量控制
• 校正和：
• 緊急指標：當URG=1時才有效，指出本報文段緊急資料的位元組數
• 選項：

串連的建立與釋放三向交握：

(1)client發出請求串連報文段，SYN=1，Seq=x。client進入SYN-SENT狀態。

(2)server收到請求報文後，向client發送確認報文段。確認報文段的首部中SYN =1，ack = x + 1，同時為自己選擇一個初始序號Seq = y.server進入SYN-RCVD（同步收到）狀態。

(3)client收到server的確認報文後，還有給server發送一個確認報文。 確認號ack = y + 1,而自己的Seq = x + 1。這個報文段已經可以攜帶資料，如果不攜帶資料則不消耗序號，下一個報文段序號仍為Seq = x + 1。

為什麼要三向交握呢？

假設握手只有兩次，如果某次資料報由於網路延遲，從client到server時，已經中斷連線了，而此時server會認為是client想建立一個新的串連，於是發給client一個確認報文（第二次握手）就建立了新的串連了，顯然這是錯誤的。如果是三向交握，client接到這個確認報文時，不予理睬，兩者沒有完成第三向交握，所以不會建立錯誤的串連了。

 

網上有一個比較形象的說法：

第一次對話：

   老婆讓甲出去打醬油，半路碰到一個朋友乙，甲問了一句：哥們你吃飯了嗎？
結果乙帶著耳機聽歌呢，根本沒聽到，沒反應。甲心裡想：跟你說話也沒個音，不跟你說了，溝通失敗。說明乙接受不到甲傳過來的資訊的情況下溝通肯定是失敗的。
如果乙聽到了甲說的話，那麼第一次對話成功，接下來進行第二次對話。

第二次對話：

   乙聽到了甲說的話，但是他是老外，中文不好，不知道甲說的啥意思也不知道怎樣回答，於是隨便回答了一句學過的中文 ：我去廁所了。甲一聽立刻笑噴了，“去廁所吃飯”?道不同不相為謀，離你遠點吧，溝通失敗。說明乙無法做出正確應答的情況下溝通失敗。
如果乙聽到了甲的話，做出了正確的應答，並且還進行了反問：我吃飯了，你呢？那麼第二次握手成功。
通過前兩次對話證明了乙能夠聽懂甲說的話，並且能做出正確的應答。接下來進行第三次對話。

第三次對話：

甲剛和乙打了個招呼，突然老婆喊他，“你個死鬼，打個醬油咋這麼半天，看我回家咋收拾你”，甲是個妻管嚴，聽完嚇得二話不說就跑回家了，把乙自己晾那了。乙心想：這什麼人啊，得，我也回家吧，溝通失敗。說明甲無法做出應答的情況下溝通失敗。
如果甲也做出了正確的應答：我也吃了。那麼第三次對話成功，兩人已經建立起了順暢的溝通渠道，接下來開始持續的聊天。
通過第二次和第三次的對話證明了甲能夠聽懂乙說的話，並且能做出正確的應答。
可見，兩個人進行有效語言溝通，這三次對話的過程是必須的。

來源： <http://www.kaiyuanba.cn/html/1/131/147/7959.htm>  四次揮手

(1)此時TCP兩端都還處於ESTABLISHED狀態，client不再發送資料，並發送一個FIN報文段,seq = 1,進入FIN-WAIT-1狀態。

(2)server收到後回複，ack = u + 1，seq = v（v等於伺服器傳輸資料最後一位元組的序號加1），然後進入CLOSE-WAIT狀態，server如果繼續發送資料，client依然接收。 

(3)client收到確認報文後，進入FIN-WAIT-2狀態。server不再發送資料後，發出FIN，ack = u  + 1,進入LASK-ACK狀態。

(4)client收到後回複，seq = u + 1, ack = w + 1(w 等於伺服器後來繼續發送的最後一個位元組的序號加1，與v並不一定相等！)，然後進入TIME-WAIT狀態

(5)此時串連還沒有釋放，需要等待（4分鐘）兩端才會CLOSED。設定時間等待是因為有可能最後一個確認報文丟失而需要重傳。

 

為什麼要四次揮手呢？

因為當client發送FIN是，表示client沒有要傳的資料了，不代表server沒有資料要傳給client，所以server還需要發送FIN來表示它也沒資料轉送了。由於TCP是全雙工系統的，所以並不存在誰先FIN的問題。

 

SYN逾時問題：server如果在一定時間內沒有收到client的確認報文，會重發。在Linux下，預設重試次數為5次，5次重試的時間分別為1、2、4、8、16、32s。第五次都沒有收到，就會斷開這個串連。

 

SYN Flood攻擊問題：如果給伺服器發送一個SYN後，就下線了，於是伺服器就需要等63秒才會中斷連線，這樣攻擊者就可以把伺服器的SYN串連隊列耗盡。Linux下有一個叫tcp_syncookies的參數來應對這個事。當SYN隊列滿了以後，TCP會通過源地址連接埠、目標地址連接埠和時間戳記打造一個特別的Seq Number發回去（又叫cookie），如果是攻擊者則不會有相應，如果是正常串連，則會把這個SYN Cookie發回來，然後服務端可以通過cookie建立串連。千萬不要用tcp_syncookies來處理正常的大負載的串連的情況。對於正常的請求，應該調整TCP參數，第一個是：tcp_synack_retries可以用他來減少重試次數；第二個是：tcp_max_syn_backlog,可以增大SYN串連數；第三個是：tcp_abort_on_overflow處理不過來感覺直接拒絕串連！

 

TCP可靠傳輸的實現

 

• TCP報文段的長度可變，根據收發雙發緩衝、網路狀態而調整。
• TCP收到另一端資料時，會回傳確認
• TCP能夠逾時重傳
• 資料校正
• 報文段中有序號，以保證順序正確
• TCP提供流量控制

寄件者再發送一個報文段後，暫時儲存該文段的副本，收到確認後才刪除；

確認報文段也需要序號，才能明白是發出去的那個資料得到了確認；

逾時計時器比傳輸往返時間略長，但具體值不確定，根據網路情況而定(使用RTT演算法)。

連續ARQ協議

實際中為了提高效率，採用流水線傳輸：發送方可以連續發送多個報文段（連續發送的資料長度叫做視窗）。接收方也不必對收到的每個報文都做回複，而是採用累積確認方式；

流量控制和擁塞控制由於接收方緩衝限制，發送視窗不能大於接受方接受視窗。 

參考資料：《TCP那些事（上）》http://coolshell.cn/articles/11564.html

               實驗樓 TCP/IP網路通訊協定基礎 https://www.shiyanlou.com/courses/98  

電腦網路 學習筆記-傳輸層：TCP協議簡介