TCP有6種標示:SYN(建立聯(lián)機) ACK(確認) PSH(傳送) FIN(結束) RST(重置) URG(緊急)

一、TCP三次握手

第一次握手

客戶端向服務器發(fā)出連接請求報文，這時報文首部中的同部位SYN=1，同時隨機生成初始序列號 seq=x

此時，TCP客戶端進程進入了 SYN-SENT（同步已發(fā)送狀態(tài)）狀態(tài)。TCP規(guī)定，SYN報文段（SYN=1的報文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個序號。

這個三次握手中的開始。表示客戶端想要和服務端建立連接。

第二次握手

TCP服務器收到請求報文后，如果同意連接，則發(fā)出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要為自己隨機初始化一個序列號 seq=y

此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態(tài)。這個報文也不能攜帶數(shù)據(jù)，但是同樣要消耗一個序號。這個報文帶有SYN(建立連接)和ACK(確認)標志，詢問客戶端是否準備好。

第三次握手

TCP客戶進程收到確認后，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，此時，TCP連接建立，客戶端進入ESTABLISHED（已建立連接）狀態(tài)。

TCP規(guī)定，ACK報文段可以攜帶數(shù)據(jù)，但是如果不攜帶數(shù)據(jù)則不消耗序號。這里客戶端表示我已經(jīng)準備好。

思考：為什么要三次握手呢，有人說兩次握手就好了

舉例：已失效的連接請求報文段。

client發(fā)送了第一個連接的請求報文，但是由于網(wǎng)絡不好，這個請求沒有立即到達服務端，而是在某個網(wǎng)絡節(jié)點中滯留了，直到某個時間才到達server

本來這已經(jīng)是一個失效的報文，但是server端接收到這個請求報文后，還是會想client發(fā)出確認的報文，表示同意連接。

假如不采用三次握手，那么只要server發(fā)出確認，新的建立就連接了，但其實這個請求是失效的請求，client是不會理睬server的確認信息，也不會向服務端發(fā)送確認的請求

但是server認為新的連接已經(jīng)建立起來了，并一直等待client發(fā)來數(shù)據(jù)，這樣，server的很多資源就沒白白浪費掉了

采用三次握手就是為了防止這種情況的發(fā)生，server會因為收不到確認的報文，就知道client并沒有建立連接。這就是三次握手的作用。

二、TCP數(shù)據(jù)的傳輸過程

建立連接后，兩臺主機就可以相互傳輸數(shù)據(jù)了。如下圖所示：

1）主機A初始seq為1200,滑動窗體為100,向主機B傳遞數(shù)據(jù)的過程。

2）假設主機B在完全成功接收數(shù)據(jù)的基礎上,那么主機B為了確認這一點，向主機A發(fā)送 ACK 包，并將 Ack 號設置為 1301。因此按如下的公式確認 Ack 號：

Ack號 = Seq號 + 傳遞的字節(jié)數(shù) + 1（這是在完全接受成功的情況下）

3）主機A獲得B傳來的ack(1301)后,開始發(fā)送seq為1301,滑動窗體為100的數(shù)據(jù)。
……

與三次握手協(xié)議相同，最后加 1 是為了告訴對方要傳遞的 Seq 號。上面說了，主機B完全成功接收A發(fā)來的數(shù)據(jù)才是這樣的,如果存在丟包該如何。

下面分析傳輸過程中數(shù)據(jù)包丟失的情況，如下圖所示：

上圖表示通過 Seq 1301 數(shù)據(jù)包向主機B傳遞100字節(jié)的數(shù)據(jù)，但中間發(fā)生了錯誤，主機B未收到。

經(jīng)過一段時間后，主機A仍未收到對于 Seq 1301 的ACK確認，因此嘗試重傳數(shù)據(jù)。

為了完成數(shù)據(jù)包的重傳，TCP套接字每次發(fā)送數(shù)據(jù)包時都會啟動定時器，如果在一定時間內(nèi)沒有收到目標機器傳回的 ACK 包，那么定時器超時，數(shù)據(jù)包會重傳。

上面也只是一種可能,比如數(shù)據(jù)1250丟失,那么Ack返回的就是1250,具體的可以詳細看下博客：

https://www.cnblogs.com/qdhxhz/p/10267932.html

三、TCP的四次揮手

第一次揮手

TCP發(fā)送一個FIN(結束)，用來關閉客戶到服務端的連接?？蛻舳诉M程發(fā)出連接釋放報文，并且停止發(fā)送數(shù)據(jù)。

釋放數(shù)據(jù)報文首部，F(xiàn)IN=1，其序列號為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態(tài)。TCP規(guī)定，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。

第二次揮手

服務端收到這個FIN，他發(fā)回一個ACK(確認)，確認收到序號為收到序號+1，和SYN一樣，一個FIN將占用一個序號。

服務器收到連接釋放報文，發(fā)出確認報文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態(tài)。

TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處于半關閉狀態(tài)，即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務器若發(fā)送數(shù)據(jù)，客戶端依然要接受。

這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。

客戶端收到服務器的確認請求后，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務器發(fā)送連接釋放報文（在這之前還需要接受服務器發(fā)送的最后的數(shù)據(jù)）。

第三次揮手

服務端發(fā)送一個FIN(結束)到客戶端，服務端關閉客戶端的連接。

服務器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文，F(xiàn)IN=1，ack=u+1，由于在半關閉狀態(tài)，服務器很可能又發(fā)送了一些數(shù)據(jù)

假定此時的序列號為seq=w，此時，服務器就進入了LAST-ACK（最后確認）狀態(tài)，等待客戶端的確認。

第四次揮手

客戶端發(fā)送ACK(確認)報文確認，并將確認的序號+1，這樣關閉完成。

客戶端收到服務器的連接釋放報文后，必須發(fā)出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態(tài)。

注意此時TCP連接還沒有釋放，必須經(jīng)過2??MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態(tài)。

服務器只要收到了客戶端發(fā)出的確認，立即進入CLOSED狀態(tài)。同樣，撤銷TCB后，就結束了這次的TCP連接?？梢钥吹?，服務器結束TCP連接的時間要比客戶端早一些。

思考：那么為什么是4次揮手呢？

為了確保數(shù)據(jù)能夠完成傳輸。

關閉連接時，當收到對方的FIN報文通知時，它僅僅表示對方?jīng)]有數(shù)據(jù)發(fā)送給你了；但未必你所有的數(shù)據(jù)都全部發(fā)送給對方了

所以你未必會馬上關閉SOCKET,也即你可能還需要發(fā)送一些數(shù)據(jù)給對方之后，再發(fā)送FIN報文給對方來表示你同意現(xiàn)在可以關閉連接了，所以它這里的ACK報文和FIN報文多數(shù)情況下都是分開發(fā)送的。

可能有人會有疑問，tcp我握手的時候為何ACK(確認)和SYN(建立連接)是一起發(fā)送。揮手的時候為什么是分開的時候發(fā)送呢？

因為當Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。

但是關閉連接時，當Server端收到FIN報文時，很可能并不會立即關閉 SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發(fā)的FIN報文我收到了"。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步揮手。

思考:客戶端突然掛掉了怎么辦？

正常連接時，客戶端突然掛掉了，如果沒有措施處理這種情況，那么就會出現(xiàn)客戶端和服務器端出現(xiàn)長時期的空閑。

解決辦法是在服務器端設置保活計時器，每當服務器收到客戶端的消息，就將計時器復位。超時時間通常設置為2小時。

若服務器超過2小時沒收到客戶的信息，他就發(fā)送探測報文段。若發(fā)送了10個探測報文段，每一個相隔75秒，還沒有響應就認為客戶端出了故障，因而終止該連接。

四、SYN（洪水）攻擊

背景

初始化連接的 SYN 超時問題Client發(fā)送SYN包給Server后掛了，Server回給Client的SYN-ACK一直沒收到Client的ACK確認，這個時候這個連接既沒建立起來，也不能算失敗。

這就需要一個超時時間讓Server將這個連接斷開，否則這個連接就會一直占用Server的SYN連接隊列中的一個位置，大量這樣的連接就會將Server的SYN連接隊列耗盡，讓正常的連接無法得到處理。

目前，Linux下默認會進行5次重發(fā)SYN-ACK包，重試的間隔時間從1s開始，下次的重試間隔時間是前一次的雙倍，5次的重試時間間隔為1s, 2s, 4s, 8s, 16s，總共31s，第5次發(fā)出后還要等32s都知道第5次也超時了

所以，總共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s，TCP才會把斷開這個連接。

由于，SYN超時需要63秒，那么就給攻擊者一個攻擊服務器的機會，攻擊者在短時間內(nèi)發(fā)送大量的SYN包給Server(俗稱SYN flood攻擊)，用于耗盡Server的SYN隊列。

什么是 SYN 攻擊

SYN 攻擊指的是，攻擊客戶端在短時間內(nèi)偽造大量不存在的IP地址，向服務器不斷地發(fā)送SYN包，服務器回復確認包，并等待客戶的確認。

由于源地址是不存在的，服務器需要不斷的重發(fā)直至超時，這些偽造的SYN包將長時間占用未連接隊列，正常的SYN請求被丟棄，導致目標系統(tǒng)運行緩慢，嚴重者會引起網(wǎng)絡堵塞甚至系統(tǒng)癱瘓。SYN 攻擊是一種典型的 DoS攻擊。

如何檢測 SYN 攻擊？

檢測 SYN 攻擊非常的方便，當你在服務器上看到大量的半連接狀態(tài)時，特別是源IP地址是隨機的，基本上可以斷定這是一次SYN攻擊。在 Linux/Unix 上可以使用系統(tǒng)自帶的netstats 命令來檢測 SYN 攻擊。

如何防御 SYN 攻擊？

SYN攻擊不能完全被阻止，除非將TCP協(xié)議重新設計。我們所做的是盡可能的減輕SYN攻擊的危害，常見的防御 SYN 攻擊的方法有如下幾種：

• 縮短超時（SYN Timeout）

• 時間增加最大半連接數(shù)

• 過濾網(wǎng)關防護SYN

• cookies技術

四、TCP和UDP的區(qū)別

我這里簡單列舉幾個，因為我還沒有研究UDP這個協(xié)議。

1、基于連接與無連接;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接

2、TCP保證數(shù)據(jù)正確性，UDP可能丟包，TCP保證數(shù)據(jù)順序，UDP不保證。

也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付Tcp通過校驗和，重傳控制，序號標識，滑動窗口、確認應答實現(xiàn)可靠傳輸。如丟包時的重發(fā)控制，還可以對次序亂掉的分包進行順序控制。

3、UDP具有較好的實時性，工作效率比TCP高，適用于對高速傳輸和實時性有較高的通信或廣播通信。

4、每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信。

5、TCP對系統(tǒng)資源要求較多，UDP對系統(tǒng)資源要求較少。

作者：雨點的名字

https://www.cnblogs.com/qdhxhz/p/8470997.html

特別推薦一個分享架構+算法的優(yōu)質內(nèi)容，還沒關注的小伙伴，可以長按關注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝