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

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

以上是這篇文章的思維導圖，個人建議復習的小伙伴都可以搞一個，方便自己復習用~

TCP和UDP的區(qū)別

首先

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

詳細的區(qū)別：

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

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

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

4、每條tcp連接只能是點到點的；udp支持一對一、一對多、多對一、多對多的交互通信。

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

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

TCP三大核心：

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

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

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

TCP三次握手

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

TCP三次握手的過程

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

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

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

為什么不是兩次？

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

為什么不是四次？

因為三次已經(jīng)足夠確認雙方的發(fā)送和接收的能力了，四次以及四次以上當然就沒必要啦

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

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

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

四次揮手斷開連接

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

注意了，這個時候，客戶端需要等待兩個 MSL(Maximum Segment Lifetime，報文最大生存時間),在這段時間內如果客戶端沒有收到服務端的重發(fā)請求，那么表示 ACK 成功到達，揮手結束，否則客戶端重發(fā) ACK。

為什么要等待 2 MSL?

• 1 個 MSL 確保四次揮手中主動關閉方最后的 ACK 報文最終能達到對端
• 1 個 MSL 確保對端沒有收到 ACK 重傳的 FIN 報文可以到達

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

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

同時發(fā)起揮手

在發(fā)送方給接收方發(fā)SYN報文的同時，接收方也給發(fā)送方發(fā)SYN報文

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

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

SYN Flood

半連接隊列、全連接隊列、SYN Flood攻擊過程、如何應對這種攻擊

半連接隊列

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

全連接隊列

當客戶端返回ACK, 服務端接收后，三次握手完成。這個時候連接等待被具體的應用取走，在被取走之前，它會被推入另外一個 TCP 維護的隊列，也就是全連接隊列(Accept Queue)。

SYN Flood 攻擊原理

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

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

如何應對 SYN Flood 攻擊？

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

半連接隊列和 SYN Flood 攻擊的關系

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

剖析TCP報文首部字段

源端口、目標端口、序列號、ISN：ISN是如何計算的，為什么、確認號標記位窗口大小校驗和可選項

• 源端口、目標端口

如何標識唯一標識一個連接？答案是 TCP 連接的四元組——源 IP、源端口、目標 IP 和目標端口。

那 TCP 報文怎么沒有源 IP 和目標 IP 呢？這是因為在 IP 層就已經(jīng)處理了 IP 。TCP 只需要記錄兩者的端口即可。
復制代碼

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

序列號在 TCP 通信的過程中有兩個作用:

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

• ISN

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

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

不要死記，只要有個印象就行

TCP快速打開（TFO）原理

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

TFO 流程

首輪三次握手

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

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

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

后面的三次握手

客戶端發(fā)送Cookie+SYN+HTTP請求，
服務端驗證合法，先確認，返回SYN+ACK，`返回HTTP響應`
客戶端傳ACK
復制代碼

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

TFO 的優(yōu)勢

拿到Cookie驗證通過就能返回HTTP請求了，
利用了1個往返時延`RTT`提前進行數(shù)據(jù)傳輸
復制代碼

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

TCP時間戳作用

• 計算往返時延RTT
• 防止序列號回繞的問題

TCP超時重傳算法

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

TCP流量控制

TCP滑動窗口概念、流量控制過程

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

具體是如何做的呢？舉個例子：

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

TCP擁塞控制

慢啟動、 擁塞避免、快速重傳和快速恢復、基于丟包的擁塞控制點產生的問題--Google的BBR擁塞控制算法

說說 TCP 的擁塞控制？

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

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

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

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

• 慢啟動閾值（Slow Start Threshold，ssthresh）

涉及到的算法有這幾個:

• 慢啟動

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

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

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

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

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

• 擁塞避免

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

慢啟動和擁塞避免是一起作用的，是一體的。

• 快速重傳和快速恢復

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

結合圖片更好理解：

首先慢開始，擁塞窗口買次翻倍直到達到慢啟動閾值，進入擁塞避免，擁塞窗口每次加一，遇到超時的情況進入快速重傳，擁塞閾值降為擁塞窗口的一半，重新慢啟動和擁塞避免，當再收到三個重復的ack時會進入塊恢復階段