TCP傳輸連線管理

TCP協議是可靠傳輸的 使用TCP通訊有三個階段，分別為連線建立、資料傳送、和連線釋放。
TCP連線的建立都是採用客戶伺服器的方式
主動發起連線建立的應用程序叫客戶(client)
被動等待連線建立的應用程序叫伺服器(server)

連線建立和資料傳輸

TCP的連線建立是通過三次握手來建立
syn：同步資料包 ack：確認標記 seq：序號 是一個數值
(圖片出自51韓老師課程ppt 以獲得本人同意)

客戶端要訪問一個服務 首先需要建立連線進行通訊
①A計算首先發一個同步資料包標記為1 確認標記為0 也就是說這個確認號沒有用 序號為x（一個數值可能是10也可能是1）
②計算機B收到這樣一個數據包就知道是一個要主動建立連線的資料包 於是B計算機就開始發一個數據包作為迴應
B發給A的確認號為x+1（就是收到的序列號+1）
③A收到確認之後 A再給B發一個數據包 這時的資料包就沒有syn了 確認號是1 告訴B 發給它資料包就是第x+1個位元組 確認號為y+1 告訴B下次發資料應該發y+1那個位元組了（第三次握手

）

①②足以能夠證明網路是暢通 並且足以協商所需要的引數 為什麼需要③再次確認？
當A給B發起一個建立連線的請求 但它可能選的一個比較遠的網路 傳的時間就比較長 A等了一會發現自己發了個請求沒搭理 結果又發一遍重新發個請求 這個資料包很快直接到了B B給的確認也很快 過了一會之前走遠路的也到了 B又給一個確認 這個時候這個確認A計算就不認了 但B還在等 所以造成了B計算機的資源浪費 這種情況多了B可能就癱了 這時有了第三次連線 B收到了第三次確認就不等了

各個連線的狀態
(圖片出自51韓老師課程ppt 以獲得本人同意)

①A給B發了一個建立連線的請求之後 狀態變為syn-sent（傳送synsent）
②B收到之後給個確認 這時B的狀態變為syn-rcvd
③A收到B的確認之後 A的狀態變為estab-lished
④當B再次收到A的確認之後 B的狀態變為estab-lished
⑤它們的狀態都變為estab-lished之後才開始傳輸資料

通過netstat - n可以檢視狀態
我們可以看到一些syn_sent的狀態 從上面的分析可以知道 此時對方是沒有確認的（比如我們訪問一個不存在的ip，過一會就沒了）
通過syn攻擊我們可以看到syn-rcvd狀態（這裡沒演示syn攻擊）其實就是偽造地址傳送連線請求 B收到後就傳送確認結果對方一直沒回復 所以就會出現這種syn-rcvd這種狀態
只要建立了通訊就是estab-lish狀態

連線釋放

(圖片出自51韓老師課程ppt 以獲得本人同意)

資料傳輸結束後，那麼就可以釋放了。
①A首先給B發一個數據包 FIN標記為1 就是說A要主動關閉TCP連線了
②B收到之後給個確認 這時A就不會給B發了 但B還可以給A發(B還沒說要結束)
③如果B也發了一個 FIN標記 表示B也要關了
④A收到之後 給B發個確認
各個狀態和上面建立連線的狀態一樣分析 這裡就不一 一指出了
主要是看最後一個狀態 (這裡也就會第四次揮手)

最後一個狀態time-wait得等待2MSL（報文最大生存時間 MSL一般是2分鐘 所以這裡就是4分鐘） 也就是A最後得等4分鐘才結束
為什麼要等待呢？
如果沒有等待 要是最後一個數據包丟了 那麼B又發一個過去 但這時A已經關閉了 A就不回覆了 這時B就關不了了
如果有等待 就算包丟了 A還沒關 A還能再發