傳輸層協(xié)議（TCP, UDP）

簡介

傳輸層定義了主機(jī)應(yīng)用程序之間端到端的連通性。傳輸層中最為常見的兩個(gè)協(xié)議分別是傳輸控制協(xié)議TCP（Transmission Control Protocol）和用戶數(shù)據(jù)報(bào)協(xié)議UDP（User Datagram Protocol）。

為了簡化問題說明，本課程以Telnet為例描述相關(guān)技術(shù)。設(shè)備支持通過Telnet協(xié)議和Stelnet協(xié)議登錄。使用Telnet，Stelnet v1協(xié)議存在安全風(fēng)險(xiǎn)，建議你使用STelnet v2登錄設(shè)備。
為了簡化問題說明，本課程以FTP為例來描述相關(guān)技術(shù)。設(shè)備支持通過FTP協(xié)議，TFTP以及SFTP傳輸文件。使用FTP，TFTP，SFTP v1協(xié)議存在風(fēng)險(xiǎn)，建議使用SFTP v2方式進(jìn)行文件操作。

TCP

TCP是一種面向連接的傳輸層協(xié)議，提供可靠的傳輸服務(wù)。

圖片.png

TCP是一種面向連接的端到端協(xié)議。TCP作為傳輸控制協(xié)議，可以為主機(jī)提供可靠的數(shù)據(jù)傳輸。TCP需要依賴網(wǎng)絡(luò)協(xié)議為主機(jī)提供可用的傳輸路徑。

圖片.png

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ì)話。端口分為知名端口和動(dòng)態(tài)端口。有些網(wǎng)絡(luò)服務(wù)會(huì)使用固定的端口，這類端口稱為知名端口，端口號(hào)范圍為0~1023。
比如：FTP，HTTP，Telnet，SNMP服務(wù)均使用知名端口。
動(dòng)態(tài)端口范圍1024~65535，這些端口號(hào)一般不會(huì)固定分配給某個(gè)服務(wù)，也就是說許多服務(wù)都可以使用這些端口。只要運(yùn)行的程序向系統(tǒng)提出訪問網(wǎng)絡(luò)的申請(qǐng)，那么系統(tǒng)就可以從這些端口號(hào)中分配一個(gè)供該程序使用。

TCP頭部

圖片.png

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é)的頭部，如果沒有Options字段，正常的長度是20字節(jié)。

TCP Header是由如上圖標(biāo)識(shí)一些字段組成，這里列出幾個(gè)常用字段。

1.16位源端口號(hào)：源主機(jī)的應(yīng)用程序使用的端口號(hào)。
2.16位目的端口號(hào)：目的主機(jī)的應(yīng)用程序使用的端口號(hào)。每個(gè)TCP頭都包含源和目的端口號(hào)，這兩個(gè)值加上IP頭部中的源IP地址和目的IP地址可以唯一確定一個(gè)TCP連接。
3.32位序列號(hào)：用于標(biāo)識(shí)從發(fā)送端發(fā)出的不同的TCP數(shù)據(jù)段的序號(hào)。數(shù)據(jù)段在網(wǎng)絡(luò)中傳輸時(shí)，它們的順序可能會(huì)發(fā)生變化；接受端依據(jù)此序列號(hào)，便可按照正確的順序重組數(shù)據(jù)。
4.32位確認(rèn)序列號(hào)：英語標(biāo)識(shí)接受端確認(rèn)收到的數(shù)據(jù)段。確認(rèn)序列號(hào)為成功收到的數(shù)據(jù)序列號(hào)加1。
5.4位頭部長度：表示頭部占32比特字的數(shù)目，它能表達(dá)的TCP頭部最大長度為60字節(jié)。
6.16位窗口大?。罕硎窘邮芏似谕ㄟ^單次確認(rèn)而收到的數(shù)據(jù)的大小。由于該字段為16位，所以窗口大小的最大值為`65535`字節(jié)，該機(jī)制通常用來進(jìn)行瀏覽控制。
7.16位校驗(yàn)和：校驗(yàn)整個(gè)TCP報(bào)文段，包括TCP頭部和TCP數(shù)據(jù)。該值由發(fā)送端計(jì)算和記錄并由接收端進(jìn)行驗(yàn)證。
圖片.png

注意：

① Send SYN: seq=a
②Send SYN + ACK: seq = b, ack = a+1
③Send ACK: seq=a+1, ack=b+1

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è)三次握手的過程。

TCP傳輸過程

圖片.png

TCP的可靠傳輸還提現(xiàn)在TCP使用了確認(rèn)技術(shù)來確保目的設(shè)備收到了從源設(shè)備發(fā)來的數(shù)據(jù)，并且是準(zhǔn)確無誤的。
確認(rèn)技術(shù)的工作原理如下：
目的設(shè)備接收到源設(shè)備發(fā)送的數(shù)據(jù)段時(shí)，會(huì)向源端發(fā)送確認(rèn)報(bào)文，源設(shè)備收到確認(rèn)報(bào)文后，繼續(xù)發(fā)送數(shù)據(jù)段，如此重復(fù)。
如圖所示，主機(jī)A向服務(wù)器A發(fā)送TCP數(shù)據(jù)段，為描述方便假設(shè)每個(gè)數(shù)據(jù)段的長度都是500個(gè)字節(jié)。
當(dāng)服務(wù)器A成功收到序列號(hào)是M+1499的字節(jié)以及之前的所有字節(jié)時(shí)，會(huì)以序列號(hào)M+1400+1=M+1500進(jìn)行確認(rèn)。另外，由于數(shù)據(jù)段N+3傳輸失敗，所以服務(wù)器A未能收到序列號(hào)為M+1500的字節(jié)，因此服務(wù)器A還會(huì)再次以序列號(hào)M+1500進(jìn)行確認(rèn)。

注意：上面說到，數(shù)據(jù)段N+3傳輸失敗，那么第二次確認(rèn)號(hào)M+1500，主機(jī)A會(huì)將N+3，N+4，N+5全部發(fā)送一次。

TCP流量控制

圖片.png

TCP滑動(dòng)窗口技術(shù)通過動(dòng)態(tài)改變窗口大小來實(shí)現(xiàn)對(duì)端到端設(shè)備之間的數(shù)據(jù)傳輸進(jìn)行流量控制。
如圖所示，主機(jī)A和服務(wù)器A之間通過滑動(dòng)窗口來實(shí)現(xiàn)流量控制。為了方便理解，此例中只考慮主機(jī)A發(fā)送數(shù)據(jù)給服務(wù)器A時(shí)，服務(wù)器A通過滑動(dòng)窗口進(jìn)行流量控制。

例子中：
主機(jī)A向服務(wù)器發(fā)送4個(gè)長度為1024字節(jié)的數(shù)據(jù)段，其中主機(jī)的窗口大小為4096個(gè)字節(jié)。服務(wù)器A收到第3個(gè)字節(jié)之后，緩存區(qū)滿，第4個(gè)數(shù)據(jù)段被丟棄。服務(wù)器以ACK3073（1024*3=3072）響應(yīng)，窗口大小調(diào)整為3072，表明服務(wù)器的緩沖區(qū)只能處理3072個(gè)字節(jié)的數(shù)據(jù)段。于是主機(jī)A改變其發(fā)送速率，發(fā)送窗口大小為3072的數(shù)據(jù)段。

TCP關(guān)閉連接

圖片.png

主機(jī)在關(guān)閉連接之前，要確認(rèn)收到來自對(duì)方的ACK。

TCP支持全雙工模式傳輸數(shù)據(jù)，這意味著統(tǒng)一時(shí)刻兩個(gè)方向都可以進(jìn)行數(shù)據(jù)的傳輸。在傳輸數(shù)據(jù)之前，TCP通過三次握手建立的實(shí)際上是兩個(gè)方向的連接，一次在傳輸完畢后，兩個(gè)方向的連接必須都關(guān)閉。
TCP連接的建立是一個(gè)三次握手過程，而TCP連接的終止則要經(jīng)過四次揮別。

如圖：
1.主機(jī)A想終止連接，于是發(fā)送一個(gè)標(biāo)識(shí)了FIN，ACK的數(shù)據(jù)段，序列號(hào)為a，確認(rèn)序列號(hào)為b。
2.服務(wù)器A回應(yīng)一個(gè)標(biāo)識(shí)了ACK的數(shù)據(jù)段，序列號(hào)為b，確認(rèn)序號(hào)為a+1，作為對(duì)主機(jī)A的FIN報(bào)文的確認(rèn)。
3.服務(wù)器A想終止連接，于是向主機(jī)A發(fā)送一個(gè)標(biāo)識(shí)了FIN，ACK的數(shù)據(jù)段，序列號(hào)為b，確認(rèn)好為a+1。
4.主機(jī)A回應(yīng)一個(gè)標(biāo)識(shí)了ACK的數(shù)據(jù)段，序列號(hào)為a+1，確認(rèn)序號(hào)為b+1，作為對(duì)服務(wù)器A的FIN報(bào)文的確認(rèn)。
以上四次交互完成了兩個(gè)方向連接的關(guān)閉。

圖片.png

TCP斷開連接的步驟，這個(gè)比較詳細(xì)：
https://blog.csdn.net/ctrl_qun/article/details/52518479

UDP

UDP是一種面向無連接的傳輸層協(xié)議，傳輸可靠性沒有保證。


圖片.png

當(dāng)應(yīng)用程序?qū)鬏數(shù)目煽啃砸蟛桓邥r(shí)，但是對(duì)傳輸速度和延遲要求較高時(shí)，可以用UDP協(xié)議來替代TCP協(xié)議在傳輸層控制數(shù)據(jù)的轉(zhuǎn)發(fā)。UDP將數(shù)據(jù)從源端發(fā)送到目的端時(shí)，無需事先建立連接。UDP采用了簡單，容易操作的機(jī)制在應(yīng)用程序間傳輸數(shù)據(jù)，沒有使用TCP中的確認(rèn)技術(shù)或滑動(dòng)窗口機(jī)制，因此UDP不能保證數(shù)據(jù)傳輸?shù)目煽啃?，也無法避免接受到重復(fù)數(shù)據(jù)的情況。

UDP頭部

圖片.png

UDP頭部僅占8個(gè)字節(jié)，傳輸數(shù)據(jù)時(shí)沒有確認(rèn)機(jī)制（注意，但是有校驗(yàn)和）。

UDP報(bào)文分為UDP報(bào)文頭和UDP數(shù)據(jù)區(qū)域兩個(gè)部分。報(bào)頭由源端口，目的端口，報(bào)文長度以及校驗(yàn)和組成。UDP適合于實(shí)時(shí)數(shù)據(jù)傳輸，比如語音和視頻通信。相比TCP，UDP的傳輸效率更高，開銷更小，但是無法保證數(shù)據(jù)傳輸可靠性。UDP頭部的標(biāo)識(shí)如下：
1）16位源端口號(hào)：源主機(jī)的應(yīng)用程序使用的端口號(hào)。
2）16位目的端口號(hào)：目的主機(jī)的應(yīng)用程序使用的端口號(hào)。
3）16位UDP長度：是指UDP頭部和UDP數(shù)據(jù)的字節(jié)長度。因?yàn)閁DP頭部長度是8字節(jié)，所以字段的最小值為8。
4）16位UDP校驗(yàn)和：該字段提供了與TCP校驗(yàn)字段同樣的功能；該字段是可選的。

UDP傳輸過程

圖片.png

使用UDP傳輸數(shù)據(jù)時(shí)，由應(yīng)用程序根據(jù)需要提供報(bào)文到達(dá)確認(rèn)，排序，流量控制等功能。

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

UDP傳輸過程

圖片.png
  • UDP不提供重傳機(jī)制，占用資源小，處理效率高。
  • 一些時(shí)延敏感的流量，如語音，視頻等，通常使用UDP作為傳輸層協(xié)議。

UDP適合傳輸對(duì)延遲敏感的流量，如語音和視頻。
在使用TCP協(xié)議傳輸數(shù)據(jù)時(shí)，如果一個(gè)數(shù)據(jù)段丟失或者接受端對(duì)某個(gè)數(shù)據(jù)段沒有確認(rèn)，發(fā)送端會(huì)重新發(fā)送該數(shù)據(jù)段。
TCP重新發(fā)送數(shù)據(jù)會(huì)帶來傳輸延遲和重復(fù)數(shù)據(jù)，降低了用戶的體驗(yàn)。對(duì)于延遲敏感的應(yīng)用，少量的數(shù)據(jù)丟失一般可以被忽略，這是使用UDP傳輸能夠提升用戶的體驗(yàn)。

總結(jié)：
1.TCP頭部中的確認(rèn)標(biāo)識(shí)位有什么作用呢？
TCP報(bào)文頭中的ACK標(biāo)識(shí)位用于目的端對(duì)已接受到數(shù)據(jù)的確認(rèn)。目的端成功收到序列號(hào)為x的字節(jié)后，會(huì)以序列號(hào)x+1進(jìn)行確認(rèn)。
2.TCP頭部中有哪些標(biāo)識(shí)位參與TCP三次握手？
在TCP三次握手過程中，要使用SYN和ACK標(biāo)識(shí)位來請(qǐng)求建立連接和確認(rèn)建立連接。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 傳輸層提供的服務(wù) 傳輸層的功能 從通信和信息處理的角度看 ，傳輸層向它上面的應(yīng)用層提供通信服務(wù)，它屬于面向通信部分...
    CodeKing2017閱讀 3,784評(píng)論 1贊 9
  • 運(yùn)輸層協(xié)議概述 從通信和信息處理的角度看，運(yùn)輸層向它上面的應(yīng)用層提供通信服務(wù)，它屬于面向通信部分的最高層，同時(shí)也是...
    srtianxia閱讀 2,767評(píng)論 0贊 2
  • 1.這篇文章不是本人原創(chuàng)的，只是個(gè)人為了對(duì)這部分知識(shí)做一個(gè)整理和系統(tǒng)的輸出而編輯成的，在此鄭重地向本文所引用文章的...
    SOMCENT閱讀 13,375評(píng)論 6贊 174
  • 傳輸層-TCP， TCP頭部結(jié)構(gòu) ，TCP序列號(hào)和確認(rèn)號(hào)詳解 TCP主要解決下面的三個(gè)問題 1.數(shù)據(jù)的可靠傳輸...
    抓兔子的貓閱讀 4,634評(píng)論 1贊 46
  • 目錄 TCP協(xié)議的基本概念面向鏈接的服務(wù)可靠的服務(wù)序列號(hào)字節(jié)流傳輸 TCP協(xié)議數(shù)據(jù)段的格式TCP偽頭部 TCP協(xié)議...
    kirito_song閱讀 3,159評(píng)論 2贊 33

友情鏈接更多精彩內(nèi)容