1.UDP

用戶(hù)數(shù)據(jù)報(bào)協(xié)議 UDP（User Datagram Protocol）： 是無(wú)連接的，盡最大可能交付，沒(méi)有擁塞控制，面向報(bào)文（對(duì)于應(yīng)用程序傳下來(lái)的報(bào)文不合并也不拆分，只是添加 UDP 首部） ，支持一對(duì)一、一對(duì)多、多對(duì)一和多對(duì)多的交互通信。

1.1 UDP首部格式

首部字段只有 8 個(gè)字節(jié)，包括源端口、目的端口、長(zhǎng)度、檢驗(yàn)和。

12 字節(jié)的偽首部是為了計(jì)算檢驗(yàn)和臨時(shí)添加的。

2.TCP

傳輸控制協(xié)議 TCP（Transmission Control Protocol）： 是面向連接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通信，面向字節(jié)流（把應(yīng)用層傳下來(lái)的報(bào)文看成字節(jié)流，把字節(jié)流組織成大小不等的數(shù)據(jù)塊） ，每一條 TCP連接只能是點(diǎn)對(duì)點(diǎn)的（一對(duì)一）。

2.1 TCP首部格式

• 序號(hào) ：用于對(duì)字節(jié)流進(jìn)行編號(hào)，例如序號(hào)為 301，表示第一個(gè)字節(jié)的編號(hào)為301，如果攜帶的數(shù)據(jù)長(zhǎng)度為 100 字節(jié)，那么下一個(gè)報(bào)文段的序號(hào)應(yīng)為 401。
• 確認(rèn)號(hào) ：期望收到的下一個(gè)報(bào)文段的序號(hào)。例如 B 正確收到 A 發(fā)送來(lái)的一個(gè)報(bào)文段，序號(hào)為 501，攜帶的數(shù)據(jù)長(zhǎng)度為 200 字節(jié)，因此 B 期望下一個(gè)報(bào)文段的序號(hào)為 701，B 發(fā)送給 A 的確認(rèn)報(bào)文段中確認(rèn)號(hào)就為 701。
• 數(shù)據(jù)偏移 ：指的是數(shù)據(jù)部分距離報(bào)文段起始處的偏移量，實(shí)際上指的是首部的長(zhǎng)度。
• 確認(rèn) ACK ：當(dāng) ACK=1 時(shí)確認(rèn)號(hào)字段有效，否則無(wú)效。TCP 規(guī)定，在連接建立后所有傳送的報(bào)文段都必須把 ACK 置 1。
• 同步 SYN ：在連接建立時(shí)用來(lái)同步序號(hào)。當(dāng) SYN=1，ACK=0 時(shí)表示這是一個(gè)連接請(qǐng)求報(bào)文段。若對(duì)方同意建立連接，則響應(yīng)報(bào)文中 SYN=1，ACK=1。
• 終止 FIN ：用來(lái)釋放一個(gè)連接，當(dāng) FIN=1 時(shí)，表示此報(bào)文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢，并要求釋放連接。
• 窗口 ：窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。之所以要有這個(gè)限制，是因?yàn)榻邮辗降臄?shù)據(jù)緩存空間是有限的。

2.2?TCP 的三次握手

假設(shè) A 為客戶(hù)端，B 為服務(wù)器端。

首先 B 處于 LISTEN（監(jiān)聽(tīng)） 狀態(tài)，等待客戶(hù)的連接請(qǐng)求。

A 向 B 發(fā)送連接請(qǐng)求報(bào)文，SYN=1，ACK=0，選擇一個(gè)初始的序號(hào) x。

B 收到連接請(qǐng)求報(bào)文，如果同意建立連接，則向 A 發(fā)送連接確認(rèn)報(bào)文，SYN=1，ACK=1，確認(rèn)號(hào)為 x+1，同時(shí)也選擇一個(gè)初始的序號(hào) y。

A 收到 B 的連接確認(rèn)報(bào)文后，還要向 B 發(fā)出確認(rèn)，確認(rèn)號(hào)為 y+1，序號(hào)為x+1。

B 收到 A 的確認(rèn)后，連接建立。

2.2.1?三次握手的原因

第三次握手是為了防止失效的連接請(qǐng)求到達(dá)服務(wù)器，讓服務(wù)器錯(cuò)誤打開(kāi)連接。

• 客戶(hù)端發(fā)送的連接請(qǐng)求如果在網(wǎng)絡(luò)中滯留，那么就會(huì)隔很長(zhǎng)一段時(shí)間才能收到服務(wù)器端發(fā)回的連接確認(rèn)。
• 客戶(hù)端等待一個(gè)超時(shí)重傳時(shí)間之后，就會(huì)重新請(qǐng)求連接。
• 但是這個(gè)滯留的連接請(qǐng)求最后還是會(huì)到達(dá)服務(wù)器，如果不進(jìn)行三次握手，那么服務(wù)器就會(huì)打開(kāi)兩個(gè)連接。
• 如果有第三次握手，客戶(hù)端會(huì)忽略服務(wù)器之后發(fā)送的對(duì)滯留連接請(qǐng)求的連接確認(rèn)，不進(jìn)行第三次握手，因此就不會(huì)再次打開(kāi)連接。

2.3?TCP 的四次揮手

以下描述不討論序號(hào)和確認(rèn)號(hào)，因?yàn)樾蛱?hào)和確認(rèn)號(hào)的規(guī)則比較簡(jiǎn)單。并且不討論ACK，因?yàn)?ACK 在連接建立之后都為 1。

A 發(fā)送連接釋放報(bào)文，FIN=1。

B 收到之后發(fā)出確認(rèn)，此時(shí) TCP 屬于半關(guān)閉狀態(tài)，B 能向 A 發(fā)送數(shù)據(jù)但是 A不能向 B 發(fā)送數(shù)據(jù)。

當(dāng) B 不再需要連接時(shí)，發(fā)送連接釋放報(bào)文，FIN=1。

A 收到后發(fā)出確認(rèn)，進(jìn)入 TIME-WAIT 狀態(tài)，等待 2 MSL（最大報(bào)文存活時(shí)間） 后釋放連接。

B 收到 A 的確認(rèn)后釋放連接。

2.3.1?四次揮手的原因

客戶(hù)端發(fā)送了 FIN 連接釋放報(bào)文之后，服務(wù)器收到了這個(gè)報(bào)文，就進(jìn)入了 CLOSEWAIT 狀態(tài)。

這個(gè)狀態(tài)是為了讓服務(wù)器端發(fā)送還未傳送畢的數(shù)據(jù)，傳送完畢之后，服務(wù)器會(huì)發(fā)送 FIN 連接釋放報(bào)文。

2.3.2?TIME_WAIT

客戶(hù)端接收到服務(wù)器端的 FIN 報(bào)文后進(jìn)入此狀態(tài)，此時(shí)并不是直接進(jìn)入 CLOSED狀態(tài)，還需要等待一個(gè)時(shí)間計(jì)時(shí)器設(shè)置的時(shí)間 2MSL。這么做有兩個(gè)理由：

• 確保最后一個(gè)確認(rèn)報(bào)文能夠到達(dá)。如果 B 沒(méi)收到 A 發(fā)送來(lái)的確認(rèn)報(bào)文，那么就會(huì)重新發(fā)送連接釋放請(qǐng)求報(bào)文，A 等待一段時(shí)間就是為了處理這種情況的發(fā)生。
• 等待一段時(shí)間是為了讓本連接持續(xù)時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文都從網(wǎng)絡(luò)中消失，使得下一個(gè)新的連接不會(huì)出現(xiàn)舊的連接請(qǐng)求報(bào)文。

2.4 TCP 可靠傳輸

TCP 使用超時(shí)重傳來(lái)實(shí)現(xiàn)可靠傳輸：如果一個(gè)已經(jīng)發(fā)送的報(bào)文段在超時(shí)時(shí)間（具體時(shí)間的確定）內(nèi)沒(méi)有收到確認(rèn)，那么就重傳這個(gè)報(bào)文段。

2.5?TCP 滑動(dòng)窗口

窗口是緩存的一部分，用來(lái)暫時(shí)存放字節(jié)流。

發(fā)送方和接收方各有一個(gè)窗口：

• 接收方通過(guò) TCP 報(bào)文段中的窗口字段告訴發(fā)送方自己的窗口大小；
• 發(fā)送方根據(jù)這個(gè)值和其它信息設(shè)置自己的窗口大小。

發(fā)送窗口內(nèi)的字節(jié)都允許被發(fā)送，接收窗口內(nèi)的字節(jié)都允許被接收。

如果發(fā)送窗口左部的字節(jié)已經(jīng)發(fā)送并且收到了確認(rèn)，那么就將發(fā)送窗口向右滑動(dòng)一定距離，直到左部第一個(gè)字節(jié)不是已發(fā)送并且已確認(rèn)的狀態(tài)；

接收窗口的滑動(dòng)類(lèi)似，接收窗口左部字節(jié)已經(jīng)發(fā)送確認(rèn)并交付主機(jī)，就向右滑動(dòng)接收窗口。

接收窗口只會(huì)對(duì)窗口內(nèi)最后一個(gè)按序到達(dá)的字節(jié)進(jìn)行確認(rèn)。

例如接收窗口已經(jīng)收到的字節(jié)為 {31, 34, 35}，其中 {31} 按序到達(dá)，而 {34, 35} 就不是，因此只對(duì)字節(jié) 31進(jìn)行確認(rèn)。發(fā)送方得到一個(gè)字節(jié)的確認(rèn)之后，就知道這個(gè)字節(jié)之前的所有字節(jié)都已經(jīng)被接收。

2.6?TCP 流量控制

流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來(lái)得及接收。

接收方發(fā)送的確認(rèn)報(bào)文中的窗口字段可以用來(lái)控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。

將窗口字段設(shè)置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。

2.7 TCP 擁塞控制

如果網(wǎng)絡(luò)出現(xiàn)擁塞，分組將會(huì)丟失，此時(shí)發(fā)送方會(huì)繼續(xù)重傳，從而導(dǎo)致網(wǎng)絡(luò)擁塞程度更高。

因此當(dāng)出現(xiàn)擁塞時(shí)，應(yīng)當(dāng)控制發(fā)送方的速率。這一點(diǎn)和流量控制很像，但是出發(fā)點(diǎn)不同。

• 流量控制是為了讓接收方能來(lái)得及接收，
• 擁塞控制是為了降低整個(gè)網(wǎng)絡(luò)的擁塞程度。

2.8 TCP擁塞控制方法

TCP 主要通過(guò)四種算法來(lái)進(jìn)行擁塞控制：慢開(kāi)始、擁塞避免、快重傳、快恢復(fù)。

發(fā)送方需要維護(hù)一個(gè)叫做擁塞窗口（cwnd） 的狀態(tài)變量。

注意擁塞窗口與發(fā)送方窗口的區(qū)別：

• 擁塞窗口只是一個(gè)狀態(tài)變量
• 實(shí)際決定發(fā)送方能發(fā)送多少數(shù)據(jù)的是發(fā)送方窗口

為了便于討論，做如下假設(shè)：

• 接收方有足夠大的接收緩存，因此不會(huì)發(fā)生流量控制；
• 雖然 TCP 的窗口基于字節(jié)，但是這里設(shè)窗口的大小單位為報(bào)文段。

2.8.1?慢開(kāi)始與擁塞避免

發(fā)送的最初執(zhí)行慢開(kāi)始，令 cwnd=1，發(fā)送方只能發(fā)送 1 個(gè)報(bào)文段；

當(dāng)收到確認(rèn)后，將 cwnd 加倍，因此之后發(fā)送方能夠發(fā)送的報(bào)文段數(shù)量為：2、4、8 ...

注意到慢開(kāi)始每個(gè)輪次都將 cwnd 加倍，這樣會(huì)讓 cwnd 增長(zhǎng)速度非常快，從而使得發(fā)送方發(fā)送的速度增長(zhǎng)速度過(guò)快，網(wǎng)絡(luò)擁塞的可能也就更高。

設(shè)置一個(gè)慢開(kāi)始門(mén)限 ssthresh，當(dāng) cwnd >= ssthresh 時(shí)，進(jìn)入擁塞避免，每個(gè)輪次只將 cwnd 加 1。

如果出現(xiàn)了超時(shí)，則令 ssthresh = cwnd/2，然后重新執(zhí)行慢開(kāi)始。

2.8.2 快重傳與快恢復(fù)

在接收方，要求每次接收到報(bào)文段都應(yīng)該對(duì)最后一個(gè)已收到的有序報(bào)文段進(jìn)行確認(rèn)。

• 例如已經(jīng)接收到 M1 和 M2 ，此時(shí)收到 M 4，應(yīng)當(dāng)發(fā)送對(duì) M2 的確認(rèn)。

在發(fā)送方，如果收到三個(gè)重復(fù)確認(rèn)，那么可以知道下一個(gè)報(bào)文段丟失，此時(shí)執(zhí)行快重傳，立即重傳下一個(gè)報(bào)文段。

• 例如收到三個(gè) M2 ，則 M 3丟失，立即重傳 M 3。

在這種情況下，只是丟失個(gè)別報(bào)文段，而不是網(wǎng)絡(luò)擁塞。因此執(zhí)行快恢復(fù)，令ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此時(shí)直接進(jìn)入擁塞避免。

慢開(kāi)始和快恢復(fù)的快慢指的是 cwnd 的設(shè)定值，而不是 cwnd 的增長(zhǎng)速率。

• 慢開(kāi)始cwnd 設(shè)定為 1，
• 快恢復(fù) cwnd 設(shè)定為 ssthresh。

?

總結(jié)

以上是生活随笔為你收集整理的UDP（首部）和TCP（首部、三次握手、四次挥手、可靠传输、滑动窗口、流量控制、拥塞控制（慢开始、拥塞避免、快重传、快恢复））的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。