TCP傳輸協議

 

TCP是主機對主機層的傳輸控制協議，提供可靠的鏈接服務，採用三次握手確認創建一個鏈接，四次揮手斷開鏈接。

三次握手

是指創建一個TCP鏈接時，須要客戶端和服務端總共發送3個包以確認鏈接創建成功。在socket編程中，這一過程由客戶端執行connect來觸發。完成三次握手，隨後Client與Server之間能夠開始傳輸數據了

SYN攻擊：

在三次握手過程當中，Server發送SYN-ACK以後，收到Client的ACK以前的TCP鏈接稱爲半鏈接（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短期內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server回覆確認包，並等待Client的確認，因爲源地址是不存在的，所以，Server須要不斷重發直至超時，這些僞造的SYN包將長時間佔用未鏈接隊列，致使正常的SYN請求由於隊列滿而被丟棄，從而引發網絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式很是簡單，即當Server上有大量半鏈接狀態且源IP地址是隨機的，則能夠判定遭到SYN攻擊了，使用以下命令可讓之現行：

 #netstat -nap | grep SYN_RECV

Q : 爲何要三次握手, 兩次不能夠嗎?

A : 試想一下, A第一次發送請求鏈接, 可是在網絡某節點滯留了, A超時重傳, 而後這一次一切正常, A跟B就愉快地進行數據傳輸了. 等到鏈接釋放了之後, 那個迷失了的鏈接請求忽然到了B那, 若是是兩次握手的話, B發送確認, 它們就算是創建起了鏈接了. 事實上A並不會理會這個確認, 由於我壓根沒有要傳數據啊. 可是B卻傻傻地覺得有數據要來, 苦苦等待. 結果就是形成資源的浪費.

更加接地氣的解釋就是 : A打電話給B

第一次握手 : 你好, 我是A, 你能聽到我說話嗎第二次握手 : 聽到了, 我是B, 你能聽到我說話嗎第三次握手 : 聽到了, 咱們能夠開始聊天了三次握手其實就是爲了檢測雙方的發送和接收能力是否正常, 你說呢?

四次揮手

指斷開一個TCP鏈接時，須要客戶端和服務端總共發送4個包以確認鏈接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執行close來觸發, 因爲TCP鏈接時全雙工的，所以，每一個方向都必需要單獨進行關閉，這一原則是當一方完成數據發送任務後，發送一個FIN(finish)來終止這一方向的鏈接，收到一個FIN只是意味着這一方向上沒有數據流動了，即不會再收到數據了，可是在這個TCP鏈接上仍然可以發送數據，直到這一方向也發送了FIN。首先進行關閉的一方將執行主動關閉，而另外一方則執行被動關閉。實際中還會有出現同時發起主動關閉的狀況

Q : 爲何要四次揮手, 而不是兩次, 三次?

A :

首先, 因爲TCP的全雙工通訊, 雙方都能做爲數據發送方. A想要關閉鏈接, 必需要等數據都發送完畢, 才發送FIN給B. (此時A處於半關閉狀態)

而後, B發送確認ACK, 而且B此時若是要發送數據, 就發送(例如作一些釋放前的處理)

再者, B發送完數據以後, 發送FIN給A. (此時B處於半關閉狀態)

而後, A發送ACK, 進入TIME-WAIT狀態

最後, 通過2MSL時間後沒有收到B傳來的報文, 則肯定B收到了ACK了. (此時A, B纔算是處於徹底關閉狀態)

PS : 仔細分析以上步驟就知道爲何不能少於四次揮手了.

Q : 爲何要等待2MSL(Maximum Segment Lifetime)時間, 才從TIME_WAIT到CLOSED？

A : 在Client發送出最後的ACK回覆，但該ACK可能丟失。Server若是沒有收到ACK，將不斷重複發送FIN片斷。因此Client不能當即關閉，它必須確認Server接收到了該ACK。Client會在發送出ACK以後進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。若是在該時間內再次收到FIN，那麼Client會重發ACK並再次等待2MSL。MSL指一個片斷在網絡中最大的存活時間，2MSL就是一個發送和一個回覆所需的最大時間。若是直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP鏈接。

更加接地氣的解釋 :

第一次揮手 : A告訴B, 我沒數據發了, 準備關閉鏈接了, 你要發送數據嗎第二次揮手 : B發送最後的數據第三次揮手 : B告訴A, 我也要關閉鏈接了第四次揮手 : A告訴B你能夠關閉了, 我這邊也關閉了