如果本文對(duì)你有幫助，歡迎關(guān)注、討論、點(diǎn)贊、收藏、轉(zhuǎn)發(fā)給朋友，讓我有持續(xù)創(chuàng)作的動(dòng)力

????這篇文章是一個(gè)我計(jì)算機(jī)網(wǎng)絡(luò)復(fù)習(xí)的大匯總，參考了許多文章，也非常感謝大佬對(duì)我這篇文章的幫助，由于內(nèi)容太多了我把它分成了上下兩篇來寫，這一篇將傳輸層協(xié)議TCP、UDP

以上是這篇文章的思維導(dǎo)圖，個(gè)人建議復(fù)習(xí)的小伙伴都可以搞一個(gè)，方便自己復(fù)習(xí)用~

TCP和UDP的區(qū)別

首先

• TCP是面向連接的、可靠的、基于字節(jié)流的傳輸層協(xié)議
• UDP是一個(gè)面向無連接的傳輸層協(xié)議

詳細(xì)的區(qū)別：

1、tcp是基于連接的，可靠性高；udp是基于無連接的，可靠性較低；

2、由于tcp是連接的通信，需要有三次握手、重新確認(rèn)等連接過程，會(huì)有延時(shí)，實(shí)時(shí)性差；由于協(xié)議所致，安全性較高；而udp無連接，無建立連接的過程，因而實(shí)時(shí)性較強(qiáng)，安全略差；

3、在傳輸相同大小的數(shù)據(jù)時(shí)，tcp首部開銷20字節(jié)；udp首部開銷只有8個(gè)字節(jié)，tcp報(bào)頭比udp復(fù)雜，故實(shí)際包含的用戶數(shù)據(jù)較少。tcp無丟包，而udp有丟包，故tcp開銷大，udp開銷較?。?/p>

4、每條tcp連接只能是點(diǎn)到點(diǎn)的；udp支持一對(duì)一、一對(duì)多、多對(duì)一、多對(duì)多的交互通信。

應(yīng)用場景的區(qū)別：

• 由于TCP和UDP的特點(diǎn)，如果對(duì)實(shí)時(shí)性要求高和高速傳輸?shù)膱鼍跋滦枰褂肬DP；
• 如果需要傳輸大量數(shù)據(jù)且對(duì)數(shù)據(jù)可靠性要求高的場景使用TCP；
• 在可靠性要求低追求效率的情況使用UDP；

TCP三大核心：

• 面向連接；所謂面向連接，指的是客戶端與服務(wù)端的連接，在雙方互相通信之前，TCP需要三次握手建立連接，而UDP沒有相應(yīng)的建立連接的過程
• 可靠性；TCP可靠性主要體現(xiàn)在1有狀態(tài)2可控制
• 面向字節(jié)流；UDP數(shù)據(jù)傳輸基于數(shù)據(jù)報(bào)，僅僅是繼承了IP層的特性，而TCP為維護(hù)狀態(tài)，將IP包變成了字節(jié)流

有狀態(tài)；TCP會(huì)精準(zhǔn)記錄哪些數(shù)據(jù)發(fā)送了，被對(duì)方接受了，哪些沒有，而保證數(shù)據(jù)按序到達(dá)，不允許差錯(cuò) 可控制；意識(shí)到丟包或者網(wǎng)絡(luò)環(huán)境差，TCP根據(jù)具體情況調(diào)整自己的行為，控制自己發(fā)送速度或重發(fā)

而UDP不可靠原因：無狀態(tài)，不可控

TCP三次握手

一次握手過程及變化、為什么不是兩次、為什么不是四次、握手過程中可以攜帶數(shù)據(jù)嗎、同時(shí)發(fā)起揮手會(huì)怎樣

TCP三次握手的過程

三次握手要確認(rèn)雙方的兩樣能力：發(fā)送能力與接收的能力。

最開始雙方都屬于CLOSED狀態(tài)。然后服務(wù)器開始監(jiān)聽某個(gè)端口，進(jìn)入LISTEN狀態(tài)。

• 客戶端注重發(fā)起連接，發(fā)送SYN，自己變成了SYN-SENT狀態(tài)
• 服務(wù)端收到，返回SYN和ACK（對(duì)應(yīng)客戶端發(fā)來的SYN），自己變成了SYN-RECD
• 客戶端再發(fā)送ACK給服務(wù)端，自己變成ESTABLISHED（established）狀態(tài)；服務(wù)端收到ACK之后，也變成這個(gè)狀態(tài)

為什么不是兩次？

根本原因：無法確認(rèn)客戶端的接收能力。 可能出現(xiàn)的問題是，兩次握手，服務(wù)端只要接收到然后發(fā)送相應(yīng)的數(shù)據(jù)包，就 默認(rèn)連接 了 ，但是事實(shí)上現(xiàn)在客戶端可能已經(jīng)斷開連接了，這樣也就帶來了連接資源的浪費(fèi) ``

為什么不是四次？

因?yàn)槿我呀?jīng)足夠確認(rèn)雙方的發(fā)送和接收的能力了，四次以及四次以上當(dāng)然就沒必要啦

三次握手過程中可以攜帶數(shù)據(jù)嗎？

可以，但是只有第三次，此時(shí)的established狀態(tài)相對(duì)安全并且夠確認(rèn)服務(wù)器的接收發(fā)送能力。

而不能在第一次握手?jǐn)y帶數(shù)據(jù)是為了防止黑客在syn中放入大量數(shù)據(jù)造成服務(wù)器資源的消耗。

四次揮手?jǐn)嚅_連接

• 首先客戶端主動(dòng)關(guān)閉，向服務(wù)器發(fā)FIN報(bào)文
• 服務(wù)端接收后通知應(yīng)用進(jìn)程并向客戶端發(fā)送ACK確認(rèn)
• 服務(wù)端處理完后被動(dòng)關(guān)閉再次向客戶端發(fā)送FIN以及ACK，進(jìn)入LAST-ACK狀態(tài)，
• 客戶端收到服務(wù)端發(fā)來的FIN后，發(fā)送 ACK 給服務(wù)端。在等待2MSL后進(jìn)入CLOSED狀態(tài)

注意了，這個(gè)時(shí)候，客戶端需要等待兩個(gè) MSL(Maximum Segment Lifetime，報(bào)文最大生存時(shí)間),在這段時(shí)間內(nèi)如果客戶端沒有收到服務(wù)端的重發(fā)請(qǐng)求，那么表示 ACK 成功到達(dá)，揮手結(jié)束，否則客戶端重發(fā) ACK。

為什么要等待 2 MSL?

• 1 個(gè) MSL 確保四次揮手中主動(dòng)關(guān)閉方最后的 ACK 報(bào)文最終能達(dá)到對(duì)端
• 1 個(gè) MSL 確保對(duì)端沒有收到 ACK 重傳的 FIN 報(bào)文可以到達(dá)

為什么是四次揮手而不是三次？

• 因?yàn)榉?wù)端在接收到FIN, 往往不會(huì)立即返回FIN, 必須等到服務(wù)端所有的報(bào)文都發(fā)送完畢了，才能發(fā)FIN。
• 因此先發(fā)一個(gè)ACK表示已經(jīng)收到客戶端的FIN，延遲一段時(shí)間才發(fā)FIN。這就造成了四次揮手。 如果是三次揮手會(huì)有什么問題？ 等于說服務(wù)端將ACK和FIN的發(fā)送合并為一次揮手，長時(shí)間的延遲可能會(huì)導(dǎo)致客戶端誤以為FIN沒有到達(dá)客戶端，從而讓客戶端不斷的重發(fā)FIN。

同時(shí)發(fā)起揮手

在發(fā)送方給接收方發(fā)SYN報(bào)文的同時(shí)，接收方也給發(fā)送方發(fā)SYN報(bào)文

上圖就是解釋同時(shí)打開情況下的狀態(tài)變遷。

• 發(fā)完SYN，兩者的狀態(tài)都變?yōu)镾YN-SENT。
• 在各自收到對(duì)方的SYN后，兩者狀態(tài)都變?yōu)镾YN-REVD。
• 接著會(huì)回復(fù)對(duì)應(yīng)的ACK + SYN，這個(gè)報(bào)文在對(duì)方接收之后，兩者狀態(tài)一起變?yōu)镋STABLISHED。

SYN Flood

半連接隊(duì)列、全連接隊(duì)列、SYN Flood攻擊過程、如何應(yīng)對(duì)這種攻擊

半連接隊(duì)列

當(dāng)客戶端發(fā)送SYN到服務(wù)端，服務(wù)端收到以后回復(fù)ACK和SYN，狀態(tài)由LISTEN變?yōu)?span style="color: #FF502C; --tt-darkmode-color: #FF502C;">SYN_RCVD，此時(shí)這個(gè)連接就被推入了SYN隊(duì)列，也就是半連接隊(duì)列。

全連接隊(duì)列

當(dāng)客戶端返回ACK, 服務(wù)端接收后，三次握手完成。這個(gè)時(shí)候連接等待被具體的應(yīng)用取走，在被取走之前，它會(huì)被推入另外一個(gè) TCP 維護(hù)的隊(duì)列，也就是全連接隊(duì)列(Accept Queue)。

SYN Flood 攻擊原理

SYN Flood 屬于典型的 DoS/DDoS 攻擊。其攻擊的原理很簡單，就是用客戶端在短時(shí)間內(nèi)偽造大量不存在的 IP地址，并向服務(wù)端瘋狂發(fā)送SYN。對(duì)于服務(wù)端而言，會(huì)產(chǎn)生兩個(gè)危險(xiǎn)的后果:

• 處理大量的SYN包并返回對(duì)應(yīng)ACK, 勢必有大量連接處于SYN_RCVD狀態(tài)，從而占滿整個(gè)半連接隊(duì)列，無法處理正常的請(qǐng)求。
• 由于是不存在的 IP，服務(wù)端長時(shí)間收不到客戶端的ACK，會(huì)導(dǎo)致服務(wù)端不斷重發(fā)數(shù)據(jù)，直到耗盡服務(wù)端的資源。

如何應(yīng)對(duì) SYN Flood 攻擊？

1. 增加 SYN 連接，也就是增加半連接隊(duì)列的容量。
2. 減少 SYN + ACK 重試次數(shù)，避免大量的超時(shí)重發(fā)。
3. 利用 SYN Cookie技術(shù)，在服務(wù)端接收到SYN后不立即分配連接資源，而是根據(jù)這個(gè)SYN計(jì)算出一個(gè)Cookie，連同第二次握手回復(fù)給客戶端，在客戶端回復(fù)ACK的時(shí)候帶上這個(gè)Cookie值，服務(wù)端驗(yàn)證Cookie 合法之后才分配連接資源。

半連接隊(duì)列和 SYN Flood 攻擊的關(guān)系

• 三次握手前，服務(wù)端的狀態(tài)從CLOSED變?yōu)?span style="color: #FF502C; --tt-darkmode-color: #FF502C;">LISTEN, 同時(shí)在內(nèi)部創(chuàng)建了兩個(gè)隊(duì)列： 半連接隊(duì)列和全連接隊(duì)列，即SYN隊(duì)列和ACCEPT隊(duì)列。
• 半連接隊(duì)列是當(dāng)客戶端發(fā)送SYN到服務(wù)端，服務(wù)端收到以后回復(fù)ACK和SYN，狀態(tài)由LISTEN變?yōu)?span style="color: #FF502C; --tt-darkmode-color: #FF502C;">SYN_RCVD，此時(shí)這個(gè)連接就被推入了SYN隊(duì)列
• SYN Flood在短時(shí)間內(nèi)偽造大量不存在的 IP地址，并向服務(wù)端瘋狂發(fā)送SYN。處理大量的SYN包并返回對(duì)應(yīng)ACK, 勢必有大量連接處于SYN_RCVD狀態(tài)，從而占滿整個(gè)半連接隊(duì)列，無法處理正常的請(qǐng)求。

剖析TCP報(bào)文首部字段

源端口、目標(biāo)端口、序列號(hào)、ISN：ISN是如何計(jì)算的，為什么、確認(rèn)號(hào)標(biāo)記位窗口大小校驗(yàn)和可選項(xiàng)

• 源端口、目標(biāo)端口

如何標(biāo)識(shí)唯一標(biāo)識(shí)一個(gè)連接？答案是 TCP 連接的四元組——源 IP、源端口、目標(biāo) IP 和目標(biāo)端口。

那 TCP 報(bào)文怎么沒有源 IP 和目標(biāo) IP 呢？這是因?yàn)樵?IP 層就已經(jīng)處理了 IP 。TCP 只需要記錄兩者的端口即可。
復(fù)制代碼

• 序列號(hào) 即Sequence number, 指的是本報(bào)文段第一個(gè)字節(jié)的序列號(hào)。

序列號(hào)在 TCP 通信的過程中有兩個(gè)作用:

在 SYN 報(bào)文中交換彼此的初始序列號(hào)。
保證數(shù)據(jù)包按正確的順序組裝。
復(fù)制代碼

• ISN

即Initial Sequence Number（初始序列號(hào)）,在三次握手的過程當(dāng)中，雙方會(huì)用過SYN報(bào)文來交換彼此的 ISN。
ISN 并不是一個(gè)固定的值，而是每 4 ms 加一，溢出則回到 0，這個(gè)算法使得猜測 ISN 變得很困難。那為什么要這么做？
如果 ISN 被攻擊者預(yù)測到，要知道源 IP 和源端口號(hào)都是很容易偽造的，當(dāng)攻擊者猜測 ISN 之后，直接偽造一個(gè) RST 后，就可以強(qiáng)制連接關(guān)閉的，這是非常危險(xiǎn)的。
而動(dòng)態(tài)增長的 ISN 大大提高了猜測 ISN 的難度。
復(fù)制代碼

• 確認(rèn)號(hào) 即ACK(Acknowledgment number)。用來告知對(duì)方下一個(gè)期望接收的序列號(hào)，小于ACK的所有字節(jié)已經(jīng)全部收到。
• 標(biāo)記位 常見的標(biāo)記位有SYN,ACK,FIN,RST,PSH。
• SYN 和 ACK 已經(jīng)在上文說過，后三個(gè)解釋如下: FIN： 即 Finish，表示發(fā)送方準(zhǔn)備斷開連接。 RST：即 Reset，用來強(qiáng)制斷開連接。 PSH： 即 Push, 告知對(duì)方這些數(shù)據(jù)包收到后應(yīng)該馬上交給上層的應(yīng)用，不能緩存。
• 窗口大小 占用兩個(gè)字節(jié)，實(shí)際上是不夠用的。因此 TCP 引入了窗口縮放的選項(xiàng)，作為窗口縮放的比例因子，這個(gè)比例因子的范圍在 0 ~ 14，比例因子可以將窗口的值擴(kuò)大為原來的 2 ^ n 次方。
• 校驗(yàn)和 占用兩個(gè)字節(jié)，防止傳輸過程中數(shù)據(jù)包有損壞，如果遇到校驗(yàn)和有差錯(cuò)的報(bào)文，TCP 直接丟棄之，等待重傳。
• 可選項(xiàng) 常用的可選項(xiàng)有以下幾個(gè): TimeStamp: TCP 時(shí)間戳，后面詳細(xì)介紹。 MSS: 指的是 TCP 允許的從對(duì)方接收的最大報(bào)文段。 SACK: 選擇確認(rèn)選項(xiàng)。 Window Scale： 窗口縮放選項(xiàng)。

不要死記，只要有個(gè)印象就行

TCP快速打開（TFO）原理

首輪三次握手、之后的三次握手、TFO優(yōu)勢

TFO 流程

首輪三次握手

就是第二次握手的時(shí)候不是立即返回SYN+ACK了，
而是返回計(jì)算得到的`SYN cookie`,
放在TCP報(bào)文的Fast Open（快速打開）選項(xiàng)中，
客戶端拿到cookie將其緩存
復(fù)制代碼

• 首先客戶端發(fā)送SYN給服務(wù)端，服務(wù)端接收到。
• 注意哦！現(xiàn)在服務(wù)端不是立刻回復(fù) SYN + ACK，而是通過計(jì)算得到一個(gè)SYN Cookie, 將這個(gè)Cookie放到 TCP 報(bào)文的 Fast Open選項(xiàng)中，然后才給客戶端返回。
• 客戶端拿到這個(gè) Cookie 的值緩存下來。后面正常完成三次握手。

首輪三次握手就是這樣的流程。而后面的三次握手就不一樣啦！

后面的三次握手

客戶端發(fā)送Cookie+SYN+HTTP請(qǐng)求，
服務(wù)端驗(yàn)證合法，先確認(rèn)，返回SYN+ACK，`返回HTTP響應(yīng)`
客戶端傳ACK
復(fù)制代碼

• 在后面的三次握手中，客戶端會(huì)將之前緩存的 Cookie、SYN 和HTTP請(qǐng)求(是的，你沒看錯(cuò))發(fā)送給服務(wù)端，服務(wù)端驗(yàn)證了 Cookie 的合法性，如果不合法直接丟棄；如果是合法的，那么就正常返回SYN + ACK。
• 重點(diǎn)來了，現(xiàn)在服務(wù)端能向客戶端發(fā) HTTP 響應(yīng)了！這是最顯著的改變，三次握手還沒建立，僅僅驗(yàn)證了 Cookie 的合法性，就可以返回 HTTP 響應(yīng)了。
• 當(dāng)然，客戶端的ACK還得正常傳過來，不然怎么叫三次握手嘛。
• 注意: 客戶端最后握手的 ACK 不一定要等到服務(wù)端的 HTTP 響應(yīng)到達(dá)才發(fā)送，兩個(gè)過程沒有任何關(guān)系。

TFO 的優(yōu)勢

拿到Cookie驗(yàn)證通過就能返回HTTP請(qǐng)求了，
利用了1個(gè)往返時(shí)延`RTT`提前進(jìn)行數(shù)據(jù)傳輸
復(fù)制代碼

TFO 的優(yōu)勢并不在與首輪三次握手，而在于后面的握手，在拿到客戶端的 Cookie 并驗(yàn)證通過以后，可以直接返回 HTTP 響應(yīng)，充分利用了1 個(gè)RTT(Round-Trip Time，往返時(shí)延)的時(shí)間提前進(jìn)行數(shù)據(jù)傳輸，積累起來還是一個(gè)比較大的優(yōu)勢。

TCP時(shí)間戳作用

• 計(jì)算往返時(shí)延RTT
• 防止序列號(hào)回繞的問題

TCP超時(shí)重傳算法

• 經(jīng)典方法
• Jacobson / Karels 算法

TCP流量控制

TCP滑動(dòng)窗口概念、流量控制過程

流量控制要做的事情，就是在通過接收緩存區(qū)的大小，控制發(fā)送端的發(fā)送。如果對(duì)方的接收緩存區(qū)滿了，就不能再繼續(xù)發(fā)送了。

具體是如何做的呢？舉個(gè)例子：

• 首先雙方三次握手，初始化各自的窗口大小，均為 200 個(gè)字節(jié)。
• 假如當(dāng)前發(fā)送端給接收端發(fā)送 100 個(gè)字節(jié)，那么此時(shí)對(duì)于發(fā)送端而言，可用窗口減少了 100 個(gè)字節(jié)。
• 現(xiàn)在這 100 個(gè)到達(dá)了接收端，被放到接收端的緩沖隊(duì)列中。不過此時(shí)由于大量負(fù)載的原因，接收端處理不了這么多字節(jié)，只能處理 40 個(gè)字節(jié)，剩下的 60 個(gè)字節(jié)被留在了緩沖隊(duì)列中。
• 上述是處理能力不夠用啦的情況，意思你發(fā)送端給我少發(fā)點(diǎn)，所以此時(shí)接收端的接收窗口應(yīng)該縮小，具體來說，縮小 60 個(gè)字節(jié)，由 200 個(gè)字節(jié)變成了 140 字節(jié)，因?yàn)?strong>緩沖隊(duì)列留下 60個(gè)字節(jié)沒被拿走。
• 因此，接收端會(huì)在 ACK 的報(bào)文首部帶上縮小后的滑動(dòng)窗口 140 字節(jié)，發(fā)送端對(duì)應(yīng)地調(diào)整發(fā)送窗口的大小為 140 個(gè)字節(jié)。
• 此時(shí)發(fā)送端情況是，已經(jīng)發(fā)送且確認(rèn)的部分增加 40 字節(jié)，右移 40 個(gè)字節(jié)，同時(shí)發(fā)送窗口縮小為 140 個(gè)字節(jié)。
• 下圖：滑動(dòng)窗口結(jié)構(gòu)（發(fā)送端） 還是搞不清，那你寫一下畫一下就想得明白了

TCP擁塞控制

慢啟動(dòng)、 擁塞避免、快速重傳和快速恢復(fù)、基于丟包的擁塞控制點(diǎn)產(chǎn)生的問題--Google的BBR擁塞控制算法

說說 TCP 的擁塞控制？

• 流量控制發(fā)生在發(fā)送端跟接收端之間
• 而TCP 的擁塞控制主要處理的問題是，整個(gè)網(wǎng)絡(luò)環(huán)境，網(wǎng)絡(luò)特別差，特別容易丟包的情況。

對(duì)于擁塞控制來說，TCP每條連接都需要維護(hù)兩個(gè)核心狀態(tài):

• 擁塞窗口（Congestion Window，cwnd）:

 是指目前自己還能傳輸?shù)臄?shù)據(jù)量大小;
	接收窗口(rwnd)是接收端給的限制
	擁塞窗口(cwnd)是發(fā)送端的限制 發(fā)送窗口大小 = min(rwnd, cwnd)
復(fù)制代碼

• 慢啟動(dòng)閾值（Slow Start Threshold，ssthresh）

涉及到的算法有這幾個(gè):

• 慢啟動(dòng)

采用一種保守的算法來慢慢地適應(yīng)整個(gè)網(wǎng)路，這種算法叫慢啟動(dòng);

過程： 1.首先，三次握手，雙方宣告自己的接收窗口大小

2.雙方初始化自己的擁塞窗口(cwnd)大小

3.在開始傳輸?shù)囊欢螘r(shí)間，發(fā)送端每收到一個(gè) ACK，擁塞窗口大小加 1，也就是說，每經(jīng)過一個(gè) RTT，擁塞窗口 翻倍。

如果說初始窗口為 10，那么第一輪 10 個(gè)報(bào)文傳完且發(fā)送端收到 ACK 后，擁塞窗口 變?yōu)?20， 第二輪變?yōu)?40，第三輪變?yōu)?80，依次類推。直到達(dá)到慢啟動(dòng)閾值

• 擁塞避免

達(dá)閾值后，如何來控制擁塞窗口的大?。?原來每收到一個(gè) ACK，擁塞窗口加1，現(xiàn)在到達(dá)閾值了，擁塞窗口只能加: 1/擁塞窗口 以前一輪 RTT 下來，cwnd翻倍，現(xiàn)在cwnd只是增加 1 而已。

慢啟動(dòng)和擁塞避免是一起作用的，是一體的。

• 快速重傳和快速恢復(fù)

快速重傳 如果發(fā)生了丟包，數(shù)據(jù)不是按序到達(dá)，接收端則重復(fù)發(fā)送之前的ACK 比如第5個(gè)包丟了，即使第6、7個(gè)包到達(dá)的接收端，接收端也一律返回第4個(gè)包的ACK。 收到 3 個(gè)重復(fù)的 ACK ，意識(shí)到丟包，馬上重傳； 選擇性重傳 ACK 報(bào)文SACK屬性，通過left edge和right edge已經(jīng)收到區(qū)間 快速恢復(fù) 發(fā)送端收到三次重復(fù)ACK之后，發(fā)現(xiàn)丟包覺得現(xiàn)網(wǎng)絡(luò)已經(jīng)有些擁塞了，會(huì)進(jìn)入快速恢復(fù)階段 發(fā)送端如下改變： 擁塞閾值降低為 cwnd 的一半、cwnd 的大小變?yōu)閾砣撝怠wnd 線性增加

結(jié)合圖片更好理解：

首先慢開始，擁塞窗口買次翻倍直到達(dá)到慢啟動(dòng)閾值，進(jìn)入擁塞避免，擁塞窗口每次加一，遇到超時(shí)的情況進(jìn)入快速重傳，擁塞閾值降為擁塞窗口的一半，重新慢啟動(dòng)和擁塞避免，當(dāng)再收到三個(gè)重復(fù)的ack時(shí)會(huì)進(jìn)入塊恢復(fù)階段