前置知識(shí)（了解）：計(jì)算機(jī)基礎(chǔ)。

作為架構(gòu)師，我們所設(shè)計(jì)的系統(tǒng)很少為單機(jī)系統(tǒng)，因此有必要了解計(jì)算機(jī)和計(jì)算機(jī)之間是怎么聯(lián)系的。局域網(wǎng)的集群和混合云的網(wǎng)絡(luò)有啥區(qū)別。系統(tǒng)交互的時(shí)候網(wǎng)絡(luò)會(huì)存在什么瓶頸。

既然網(wǎng)絡(luò)層已經(jīng)能把源主機(jī)上發(fā)出的數(shù)據(jù)傳送給目的主機(jī),那么為什么還需要加上一個(gè)傳輸層呢?這就需要我們理解主機(jī)用戶應(yīng)用層通信的主體，位于兩臺(tái)網(wǎng)絡(luò)主機(jī)中真正的數(shù)據(jù)通信主體并不是這兩臺(tái)主機(jī)，而是兩臺(tái)主機(jī)中的各種網(wǎng)絡(luò)應(yīng)用進(jìn)程。同一時(shí)間一臺(tái)主機(jī)上可能有多個(gè)進(jìn)程同時(shí)運(yùn)行，這時(shí)候就需要為應(yīng)用程序提供一個(gè)標(biāo)識(shí)，那就是端口.而傳輸層就是為了提供這種端到端的服務(wù)而存在的.

端口分為知名端口和動(dòng)態(tài)端口。有些網(wǎng)絡(luò)服務(wù)會(huì)使用固定的端口，這類(lèi)端口稱(chēng)為知名端口，端口號(hào)范圍為0~1023。比如：FTP，HTTP，Telnet，SNMP服務(wù)均使用知名端口。

動(dòng)態(tài)端口范圍1024~65535，這些端口號(hào)一般不會(huì)固定分配給某個(gè)服務(wù)，也就是說(shuō)許多服務(wù)都可以使用這些端口。只要運(yùn)行的程序向系統(tǒng)提出訪問(wèn)網(wǎng)絡(luò)的申請(qǐng)，那么系統(tǒng)就可以從這些端口號(hào)中分配一個(gè)供該程序使用。

運(yùn)輸層是只有主機(jī)才有的層次，傳輸層使用網(wǎng)絡(luò)層的服務(wù)為應(yīng)用層提供通信服務(wù)。傳輸層定義了主機(jī)應(yīng)用程序之間端到端的連通性。傳輸層中最為常見(jiàn)的兩個(gè)協(xié)議分別是傳輸控制協(xié)議TCP（Transmission Control Protocol）和用戶數(shù)據(jù)報(bào)協(xié)議UDP（User Datagram Protocol）

目錄

UDP協(xié)議

TCP協(xié)議

可靠傳輸

流量控制

擁塞控制

連接管理

---

UDP協(xié)議

UDP是一種面向無(wú)連接的傳輸層協(xié)議，傳輸可靠性沒(méi)有保證。udp只在ip數(shù)據(jù)報(bào)服務(wù)之上增加了很少功能，即復(fù)用分用和差錯(cuò)檢測(cè)功能

udp的主要特點(diǎn)

1.udp是無(wú)連接的，減少開(kāi)銷(xiāo)和發(fā)送數(shù)據(jù)之前的時(shí)延

2.udp使用最大努力交付，即不保證可靠交付

3.udp是面向報(bào)文的，適合一次性傳輸少量數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用

4.udp無(wú)擁塞控制，適合很多實(shí)時(shí)應(yīng)用

5.udp首部開(kāi)銷(xiāo)小，8B，tcp20B

主機(jī)A發(fā)送數(shù)據(jù)包時(shí)，這些數(shù)據(jù)包是以有序的方式發(fā)送到網(wǎng)絡(luò)中的，每個(gè)數(shù)據(jù)包獨(dú)立地在網(wǎng)絡(luò)中被發(fā)送，所以不同的數(shù)據(jù)包可能會(huì)通過(guò)不同的網(wǎng)路徑叨叨主機(jī)B。這樣的情況下，先發(fā)送的數(shù)據(jù)包不一定先到達(dá)主機(jī)B。因?yàn)閁DP數(shù)據(jù)包沒(méi)有序號(hào)，主機(jī)B將無(wú)法通過(guò)UDP協(xié)議將數(shù)據(jù)包按照原來(lái)的順序重新組合，所以此時(shí)需要應(yīng)用程序提供報(bào)文的到達(dá)確認(rèn)，排序和流量控制等功能（也就是說(shuō)UDP報(bào)文的到達(dá)確認(rèn)，排序和流量控制是應(yīng)用程序來(lái)確定的）。通常情況下，UDP采用實(shí)時(shí)傳輸機(jī)制和時(shí)間戳來(lái)傳輸語(yǔ)音和視頻數(shù)據(jù)。

TCP協(xié)議

TCP是一種面向連接的端到端協(xié)議。TCP作為傳輸控制協(xié)議，可以為主機(jī)提供可靠的數(shù)據(jù)傳輸。TCP需要依賴網(wǎng)絡(luò)協(xié)議為主機(jī)提供可用的傳輸路徑。TCP允許一個(gè)主機(jī)同事運(yùn)行多個(gè)應(yīng)用進(jìn)程。每臺(tái)主機(jī)可以擁有多個(gè)應(yīng)用端口，每對(duì)端口號(hào)，源和目標(biāo)IP地址的組合唯一地標(biāo)識(shí)了一個(gè)會(huì)話。

可靠傳輸

ARQ協(xié)議，即自動(dòng)重傳請(qǐng)求（Automatic Repeat-reQuest），是OSI模型中數(shù)據(jù)鏈路層和傳輸層的錯(cuò)誤糾正協(xié)議之一。它通過(guò)使用確認(rèn)和超時(shí)這兩個(gè)機(jī)制，在不可靠服務(wù)的基礎(chǔ)上實(shí)現(xiàn)可靠的信息傳輸。如果發(fā)送方在發(fā)送后一段時(shí)間之內(nèi)沒(méi)有收到確認(rèn)幀，它通常會(huì)重新發(fā)送。 ARQ包括停止等待ARQ協(xié)議和連續(xù)ARQ協(xié)議，擁有錯(cuò)誤檢測(cè)（Error Detection）、正面確認(rèn)（Positive Acknowledgment）、超時(shí)重傳（Retransmission after Timeout）和 負(fù)面確認(rèn)及重傳（Negative Acknowledgment and Retransmission）等機(jī)制。

由于停止等待ARQ協(xié)議信道利用率太低，所以需要使用連續(xù)ARQ協(xié)議來(lái)進(jìn)行改善。這個(gè)協(xié)議會(huì)連續(xù)發(fā)送一組數(shù)據(jù)包，然后再等待這些數(shù)據(jù)包的ACK。發(fā)送方采用流水線傳輸。流水線傳輸就是發(fā)送方可以連續(xù)發(fā)送多個(gè)分組，不必每發(fā)完一個(gè)分組就停下來(lái)等待對(duì)方確認(rèn)。如下圖所示：

連續(xù)ARQ協(xié)議通常是結(jié)合滑動(dòng)窗口協(xié)議來(lái)使用的，發(fā)送方需要維持一個(gè)發(fā)送窗口，如下圖所示：

圖（a）是發(fā)送方維持的發(fā)送窗口，它的意義是：位于發(fā)送窗口內(nèi)的5個(gè)分組都可以連續(xù)發(fā)送出去，而不需要等待對(duì)方的確認(rèn)，這樣就提高了信道利用率。?

連續(xù)ARQ協(xié)議規(guī)定，發(fā)送方每收到一個(gè)確認(rèn)，就把發(fā)送窗口向前滑動(dòng)一個(gè)分組的位置。例如上面的圖（b），當(dāng)發(fā)送方收到第一個(gè)分組的確認(rèn)，就把發(fā)送窗口向前移動(dòng)一個(gè)分組的位置。如果原來(lái)已經(jīng)發(fā)送了前5個(gè)分組，則現(xiàn)在可以發(fā)送窗口內(nèi)的第6個(gè)分組。?

接收方一般都是采用累積確認(rèn)的方式。也就是說(shuō)接收方不必對(duì)收到的分組逐個(gè)發(fā)送確認(rèn)。而是在收到幾個(gè)分組后，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)。如果收到了這個(gè)分組確認(rèn)信息，則表示到這個(gè)分組為止的所有分組都已經(jīng)正確接收到了。?

累積確認(rèn)的優(yōu)點(diǎn)是容易實(shí)現(xiàn)，即使確認(rèn)丟失也不必重傳。但缺點(diǎn)是，不能正確的向發(fā)送方反映出接收方已經(jīng)正確收到的所以分組的信息。比如發(fā)送方發(fā)送了前5個(gè)分組，而中間的第3個(gè)分組丟失了，這時(shí)候接收方只能對(duì)前2個(gè)發(fā)出確認(rèn)。而不知道后面3個(gè)分組的下落，因此只能把后面的3個(gè)分組都重傳一次，這種機(jī)制叫Go-back-N（回退N），表示需要再退回來(lái)重傳已發(fā)送過(guò)的N個(gè)分組。

滑動(dòng)窗口協(xié)議：

規(guī)則：

（1）凡是已經(jīng)發(fā)送過(guò)的數(shù)據(jù)，在未收到確認(rèn)之前，都必須暫時(shí)保留，以便在超時(shí)重傳時(shí)使用。

（2）只有當(dāng)發(fā)送方A收到了接收方的確認(rèn)報(bào)文段時(shí)，發(fā)送方窗口才可以向前滑動(dòng)幾個(gè)序號(hào)。

（3）當(dāng)發(fā)送方A發(fā)送的數(shù)據(jù)經(jīng)過(guò)一段時(shí)間沒(méi)有收到確認(rèn)（由超時(shí)計(jì)時(shí)器控制），就要使用回退N步協(xié)議，回到最后接收到確認(rèn)號(hào)的地方，重新發(fā)送這部分?jǐn)?shù)據(jù)。

流量控制

一條TCP連接每一側(cè)主機(jī)都為該連接設(shè)置了接收緩存。當(dāng)該TCP連接收到了正確的、按序的字節(jié)后，他就將數(shù)據(jù)放入接收緩存。相關(guān)聯(lián)的應(yīng)用進(jìn)程會(huì)從該緩存中讀取數(shù)據(jù)。但不必是數(shù)據(jù)一到達(dá)就立即讀取。事實(shí)上，接收方也許正忙于其他任務(wù)，甚至要過(guò)很長(zhǎng)時(shí)間后才讀取該數(shù)據(jù)。如果某個(gè)應(yīng)用進(jìn)程讀取比較緩慢，但是發(fā)送方發(fā)送的太多、太快，發(fā)送的數(shù)據(jù)就會(huì)很容易地使該連接的接收緩存溢出。

TCP為它的應(yīng)用程序提供了流量控制服務(wù)(flow-control service)以消除發(fā)送方使接收方緩存溢出的可能性。流量控制因此是一個(gè)速度匹配服務(wù)，即發(fā)送方的發(fā)送速率與接收方應(yīng)用程序的讀取速率相匹配。

TCP通過(guò)讓發(fā)送方維護(hù)一個(gè)稱(chēng)為接收窗口(receive window)的變量(TCP報(bào)文段首部的接收窗口字段)來(lái)提供流量控制。通俗的講，接收窗口用于給發(fā)送方一個(gè)指示－－該接收方還有多少可用的緩存空間。因?yàn)門(mén)CP是全雙工通信，在連接兩端的發(fā)送方都各自維護(hù)了一個(gè)接收窗口。

擁塞控制

擁塞控制是作用于網(wǎng)絡(luò)的，它是防止過(guò)多的數(shù)據(jù)注入到網(wǎng)絡(luò)中，避免出現(xiàn)網(wǎng)絡(luò)負(fù)載過(guò)大的情況；常用的方法就是：（ 1 ）慢開(kāi)始、擁塞避免（ 2 ）快重傳、快恢復(fù)。

"擁塞窗口":是為了避免發(fā)生擁塞而設(shè)置的窗口,最終發(fā)送的字節(jié)數(shù)是接收端為發(fā)送端設(shè)置的"發(fā)送窗口"和"擁塞窗口"的最小值.

"慢啟動(dòng)閾值"(SSTHRESH):初始值是64k,即65535個(gè)字節(jié),當(dāng)發(fā)生一次數(shù)據(jù)丟失時(shí),其值變?yōu)?#34;擁塞窗口"大小的一半.

慢啟動(dòng) 擁塞避免:

主機(jī)剛開(kāi)始發(fā)送報(bào)文段時(shí)先將擁塞窗口的大小設(shè)置為一個(gè)MSS(該連接上當(dāng)前使用的最大數(shù)據(jù)段大小)。每收到一個(gè)報(bào)文段的確認(rèn)后,將擁塞窗口增加最多一個(gè)MSS的大小。以此類(lèi)推,用這樣的方法逐步增大發(fā)送端擁塞窗口的大小,使分組注入到網(wǎng)絡(luò)的速率更加合理，直到擁塞窗口的值達(dá)到慢啟動(dòng)閾值,這時(shí)候"擁塞避免"就發(fā)揮作用了.

該方案不再像慢啟動(dòng)一樣以指數(shù)速度增長(zhǎng)擁塞窗口的大小,而是到達(dá)慢啟動(dòng)閾值后,按線性規(guī)律增長(zhǎng),是網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞.

以上兩個(gè)方案配合使用,可有效減少網(wǎng)絡(luò)擁塞的影響,但不能完全避免擁塞情況,后來(lái)又提出了"快速重傳"和"快速恢復(fù)"機(jī)制

快重傳和快恢復(fù)：

快重傳算法首先要求接收方每收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)。這樣做可以讓發(fā)送方及早知道有報(bào)文段沒(méi)有到達(dá)接收方。發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)，即認(rèn)為對(duì)應(yīng)"確認(rèn)號(hào)"上的字段已丟失,TCP不等重傳定時(shí)器失效,就重傳已丟失的數(shù)據(jù),此為快速重傳，同時(shí)快速恢復(fù)發(fā)揮作用,把當(dāng)前擁塞窗口大小設(shè)置為當(dāng)前慢啟動(dòng)閾值大小的一半，以減輕網(wǎng)絡(luò)負(fù)荷,然后再執(zhí)行"擁塞避免"。不難看出，快重傳并非取消重傳計(jì)時(shí)器，而是在某些情況下可更早地重傳丟失的報(bào)文段。

連接管理

建立連接：TCP通常使用IP作為網(wǎng)絡(luò)層協(xié)議，這是TCP數(shù)據(jù)被封裝在IP數(shù)據(jù)包內(nèi)。TCP數(shù)據(jù)段由TCP Header（頭部）和TCP Data（數(shù)據(jù)）組成。TCP最多可以有60個(gè)字節(jié)的頭部，如果沒(méi)有Options字段，正常的長(zhǎng)度是20字節(jié)。

1）主機(jī)A（通常也叫客戶端）發(fā)送一個(gè)標(biāo)識(shí)了SYN數(shù)據(jù)段，標(biāo)識(shí)期望與服務(wù)器A建立連接，此數(shù)據(jù)段的序列號(hào)（seq）為a；

2）服務(wù)器A回復(fù)標(biāo)識(shí)了SYN+ACK的數(shù)據(jù)段，此數(shù)據(jù)段的序列號(hào)（seq）為b，確認(rèn)序列號(hào)為主機(jī)A的序列號(hào)加1（a+1），以此作為對(duì)主機(jī)A的SYN報(bào)文的確認(rèn)。

3）主機(jī)A發(fā)送一個(gè)標(biāo)識(shí)了ACK的數(shù)據(jù)段，此數(shù)據(jù)段的序列號(hào)（seq）為a+1，確認(rèn)序列號(hào)為服務(wù)器A的序列號(hào)加1（b+1），以此作為對(duì)服務(wù)器A的SYN報(bào)文段的確認(rèn)。

TCP是一種可靠的，面向連接的全雙工傳輸層協(xié)議。TCP連接的建立是一個(gè)三次握手的過(guò)程。

為什么是三次握手

tcp連接是全雙工的，數(shù)據(jù)在兩個(gè)方向上能同時(shí)傳遞。所以要確保雙方，同時(shí)能發(fā)數(shù)據(jù)和收數(shù)據(jù)

第一次握手：證明了發(fā)送方能發(fā)數(shù)據(jù) 第二次握手：ack確保了接收方能收數(shù)據(jù)，syn確保了接收方能發(fā)數(shù)據(jù) 第三次握手：確保了發(fā)送方能收數(shù)據(jù) 實(shí)際上是四個(gè)維度的信息交換，不過(guò)中間兩步合并為一次握手了。四次握手浪費(fèi)，兩次握手不能保證“雙方同時(shí)具備收發(fā)功能”

關(guān)閉連接：為什么是四次揮手

因?yàn)閠cp連接是全雙工的，數(shù)據(jù)在兩個(gè)方向上能同時(shí)傳遞。同時(shí)tcp支持半關(guān)閉（發(fā)送一方結(jié)束發(fā)送還能接收數(shù)據(jù)的功能）。因此每個(gè)方向都要單獨(dú)關(guān)閉，且收到關(guān)系通知需要發(fā)送確認(rèn)回復(fù)

為什么要支持半關(guān)閉

客戶端需要通知服務(wù)端，它的數(shù)據(jù)已經(jīng)傳輸完畢，同時(shí)仍要接收來(lái)自服務(wù)端的數(shù)據(jù)，使用半關(guān)閉的單連接效率要比使用兩個(gè)tcp連接更好