TCP協議總結（理解三次握手，四次揮手）
TCP（傳輸控制協議）特點：
1.TCP是面向連線的運輸層協議
2.TCP連線是點對點的，連線端點是兩個套接字（socket=IP地址 : 埠號）
3.TCP是全雙工通訊，兩端都可以傳送接收資料
4.TCP資料傳輸是面向位元組流的。
TCP可靠傳輸的工作原理：
1.停止等待協議（傳送完一個分組之後停止傳送，收到接收方的確認後再發送下一個分組）
理想傳輸情況
接收的分組出現差錯情況
B在接收M1分組時檢測發現M1分組出現差錯，這時候B會丟棄錯誤的M1分組，不會發送確認給A，A在一段時間內收不到確認報文，就不會發送下一個M2分組，而是會重發M1分組，這個機制叫超時重傳。
需要注意的有三點：
（1）A在傳送M1時，要將M1的副本儲存在傳送快取中,要直到接收到B傳送來的確認收到M1的確認報文時才能清除M1副本。
（2）分組和確認分組都要編號，第一次傳送的M1和超時重傳的M1是通過編號區分的。
（3）超時時長，即重傳時間要稍大於保文在AB之間傳輸的平均往返時間，但是由於網路的不確定性，這個時間非常難選擇。
- 確認丟失和確認遲到
情況1：B發到M1分組後傳送給A的確認報文丟失了，A沒有接收到確認，就不知道傳送給B的M1分組是出錯還是丟失了，或者B傳送的確認丟失了。A超時重傳M1’，此時B收到了重傳的分組M1’。
此時B應該
1丟棄重複接收的分組M1’
2 向A再發送確認，因為A沒有接收到對於M1的確認。
情況2：傳輸過程沒出錯誤，但是A很晚才接收到對於M1的確認，此時A會接收到重複的確認，丟棄重複的確認，B也會收到重複的M1，也需要丟棄重複的M1，並且重傳確認分組。
（圖很醜，但是很容易懂）
2.連續ARQ協議（接收方採用累計確認的方式，對按序到達的最後一個分組傳送確認）
3.滑動視窗協議（比較複雜，難以說清楚，要弄清楚各種視窗的概念）
接下來就是TCP協議的三次握手和四次揮手了（很重要，面試題常考點，TCP可靠傳輸的關鍵知識）
先有必要了解TCP報文段格式
再解析重要欄位的意義：
- 源埠目的埠沒得說
- 序號：TCP傳輸是面向位元組流的，每一個位元組都按照順序編碼，起始序號必須在建立連線時設定，報文段序號按照傳輸順序依次+1。
- 確認號：期望收到對方下一個報文段第一個資料位元組的序號，如果A接收到B的報文中確認號為N，那麼表明，A傳輸的從起始序號到N-1為止的所有資料B都已經成功接收了。
- 資料偏移（在保留位左邊）：定義TCP首部長度。
- 確認ACK：僅當ACK=1時，確認號欄位有效，當ACK=0時，確認號無效，TCP協議通訊建立連線後所有傳送的報文段ACK必須為1。
- 復位RST，RST=1時表示連接出現嚴重差錯。
- 同步SYN:用來同步序號的，當SYN=1，ACK=0，表示請求連線報文，如果對方同意建立連線，則在響應報文段中使SYN=1，ACK=1.（知道這個看圖就稍微容易點了，之前一直不懂這兩個欄位的作用，不必過分糾結）
- 終止FIN：當FIN=1時，表示報文段的傳送方資料已經發送完了，請求釋放TCP連線。
TCP面向連線—連線建立、資料傳送、連線釋放（TCP三次握手，四次揮手正式開始）
三次握手過程
過程：
- A，B的TCP程序都能建立傳輸控制塊，A主動開啟TCP程序，向B發出連線請求報文段，此時“SYN=1，ACK=0，表示請求連線報文”，同時選擇一個初始序號seq=client_seq,SYN需要消耗掉一個序號，A的TCP程序進入SYN-SENT（同步已傳送）狀態。
- B處於Listen（監聽狀態）收到連線請求，同意建立連線，則向A傳送確認報文段，此時 ”對方同意建立連線，則在響應報文段中使SYN=1，ACK=1“，同時也為自己選擇一個初始序號seq=sever_seq,此時B已經確認收到A的請求報文段，所以確認報文段中的確認號ack=client_seq+1，表示B期望收到A的下一個報文段的序號是client_seq+1，B的TCP程序進入SYN-RCVD（同步接收狀態）。
- A收到B的確認報文之後還要向B傳送一次確認報文，ACK報文段不攜帶資料則不消耗序號，A進入已建立連線狀態。
- 當B收到A的確認，都進入建立連線狀態。
問題：為什麼A還要向B傳送一次確認？？？？
答案：防止失效的連線請求再回到B，產生錯誤
分析：假如A傳送給B的連線請求報文由於網路延遲問題沒有及時傳到B，B就無法向A傳送確認報文，A採用超時重傳重新向傳送連線請求，然後接收到了確認報文，A，B建立連線進行雙方通訊，釋放連線後，第一次傳送的連線請求報文才到達B，B誤以為A又發出一次新的連線請求，又向A發出確認報文段，同意建立連線，要是沒有第三次握手，那麼B只要發出確認，新的連線就會建立，就會浪費很多資源（第三次發出確認，B收不到確認，就知道A沒有要求請求建立連線）
四次揮手過程
這裡的變數看著亂七八糟，有些敗筆，但其實我個人認為四次揮手比三次握手更容易理解。
- A傳送完資料後TCP發出連線釋放報文段，停止傳送資料，主動關閉TCP連線，此時“當FIN=1時，表示報文段的傳送方資料已經發送完了，請求釋放TCP連線。”序號為傳送完的最後一個位元組+1，FIN會消耗一個序號，A進入終止等待1狀態。
- B收到A的請求連線釋放報文後，會發送一個確認報文，這裡不再贅述，B進入CLOSE-WAIT（關閉等待狀態），這是半關閉狀態，因為這裡已經確認A沒有資料傳送給B了，但是B可能還有資料需要傳送給A（也就是A->B方向的連線關閉了，而B->A方向還沒關閉）
- B的資料傳完之後，會向A傳送連線釋放報文段，B進入LAST-ACK(最後確認狀態)，然後等待A的確認。
- A接收到連線釋放報文後，必須對此發出確認，B接收到確認後，B進入完全關閉狀態，而A需要等待2MSL（MSL：最長報文生存時間）才能完全釋放TCP連線。
問題：為什麼A需要等待2MSL才能關閉
答案：1.為了保證A傳送的最後一個ACK報文段能到達B。 2.防止“已經失效的連線請求出現再本連線中”
總結：參考謝希仁《計算機網路-第六版》，自己畫圖真的很幸苦，但是在過程中慢慢體會這個連線關閉的過程，還是很有收穫的，記在部落格上有時間翻出來多看看，TCP的視窗滑動，流量控制，擁塞控制還需要多看看書，以後再補充。