作者 | JunSIr_deCp
責(zé)編 | 王曉曼
來源 | CSDN博客
TCP/IP協(xié)議概述
在TCP/IP協(xié)議棧，傳輸層有兩個協(xié)議TCP和UDP：
-
TCP（Transmission Control Protocol，傳輸控制協(xié)議）協(xié)議：負(fù)責(zé)將要傳輸?shù)奈募侄?進(jìn)行傳輸，一般用于建立會話 ，其基本特性是可靠傳輸 、流量控制，所謂三握手、四揮手也是基于TCP協(xié)議的；
-
UDP（User Data Protocol，用戶數(shù)據(jù)報(bào)協(xié)議）協(xié)議：一個數(shù)據(jù)包就能夠完成數(shù)據(jù)通信，數(shù)據(jù)包不分段 ，不需要建立會話 ，不需要流量控制 ，屬于不可靠傳輸 ， 屏幕廣播 、多播 、廣播都是基于UDP協(xié)議。
以上定義，下面來詳講：
傳輸層協(xié)議的作用體現(xiàn)在應(yīng)用層協(xié)議
TCP和UDP協(xié)議內(nèi)指定不同的端口即可對應(yīng)一個應(yīng)用層的協(xié)議。
端口代表主機(jī)服務(wù)的偵聽"門牌號"，不管是TCP還是UDP，帶上門牌號，它就能幫你找到主機(jī)上的對應(yīng)服務(wù)。
例如我們在瀏覽器訪問某個網(wǎng)站地址，這個動作會被我們本機(jī)上的80端口偵聽到，并處理你的網(wǎng)絡(luò)請求。
我們主機(jī)上常見的應(yīng)用層協(xié)議端口：
- HTTP默認(rèn)使用TCP的80端口標(biāo)識；
-
FTP默認(rèn)使用TCP的21端口標(biāo)識；
-
SMTP默認(rèn)使用TCP的25端口標(biāo)識；
-
POP3默認(rèn)使用TCP的110端口；
-
HTTPS默認(rèn)使用TCP的443端口；
-
DNS使用UDP的53端口；
-
遠(yuǎn)程桌面協(xié)議（RDP）默認(rèn)使用TCP的3389端口；
-
Telnet 使用 TCP 的23端口 windows 訪問共享資源使用TCP的445端口；
但是我們通過TCP/UDP封裝的數(shù)據(jù)包，通過本機(jī)偵聽服務(wù)發(fā)送到目標(biāo)主機(jī)，目標(biāo)主機(jī)是如何識別并處理的呢？
如上圖，我們會在數(shù)據(jù)包中添加目標(biāo)端口號，這樣目標(biāo)主機(jī)相關(guān)服務(wù)偵聽到，就能處理我們的請求了。
TCP/UDP傳輸層協(xié)議與網(wǎng)絡(luò)層協(xié)議的區(qū)別
-
網(wǎng)絡(luò)層實(shí)現(xiàn)如何把數(shù)據(jù)包從這個地址(服務(wù)器)發(fā)送到另一個地址(服務(wù)器)；
-
傳輸層實(shí)現(xiàn)如何讓這個應(yīng)用程序找到對應(yīng)計(jì)算機(jī)的應(yīng)用程序，即服務(wù)。
說白了，IP協(xié)議主要讓數(shù)據(jù)能知道傳到哪去，不管對應(yīng)目標(biāo)誰來負(fù)責(zé)接待，而TCP/UDP管。
越靠近頂層應(yīng)用層、功能越強(qiáng)大。
UDP協(xié)議
主要特點(diǎn)：
-
UDP 是面向無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接，如向DNS服務(wù)器申請域名解析服務(wù)；
-
UDP 使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制；
-
UDP 是面向報(bào)文的。UDP 沒有擁塞控制，很適合多媒體通信的要求；
-
UDP 支持一對一、一對多、多對一和多對多的交互通信，這也是，應(yīng)用場景如廣播、組播；
-
UDP 的首部開銷小，只有 8 個字節(jié)。
基本描述：
UDP首部：
首先得知道數(shù)據(jù)包在OSI模型中層層傳輸，自頂向下。
來看看UDP首部：
- 用戶數(shù)據(jù)報(bào) UDP 有兩個字段：數(shù)據(jù)字段和首部字段。首部字段有 8 個字節(jié)，由 4 個字段組成，每個字段都是兩個字節(jié)；
-
在計(jì)算檢驗(yàn)和時，臨時把“偽首部”和 UDP 用戶數(shù)據(jù)報(bào)連接在一起。偽首部僅僅是為了計(jì)算檢驗(yàn)和，偽首部12個字節(jié)取自IP數(shù)據(jù)報(bào)的字段；
-
檢驗(yàn)和實(shí)現(xiàn)UDP數(shù)據(jù)檢驗(yàn)，通過驗(yàn)證檢驗(yàn)和可以知道UDP數(shù)據(jù)包是否出現(xiàn)異常。
TCP協(xié)議
基本特點(diǎn)：
- TCP 是面向連接的傳輸層協(xié)議，UDP面向無連接；
- 每一條 TCP 連接只能有兩個端點(diǎn)(endpoint)，每一條 TCP 連接只能是點(diǎn)對點(diǎn)的（一對一）；
- TCP 提供可靠交付的服務(wù)（持續(xù)交付）；
- TCP 提供全雙工通信（信道雙向傳輸）；
-
面向字節(jié)流(傳送最小單位為字節(jié)，即八位)。
上圖可以看出TCP傳輸是如何面向字節(jié)流的，具體細(xì)節(jié)后面繼續(xù)解析：
TCP連接基于Socket：
- TCP 把連接作為最基本的抽象，每一條 TCP 連接有兩個端點(diǎn)；
- TCP 連接的端點(diǎn)不是主機(jī)，不是主機(jī)的IP 地址，不是應(yīng)用進(jìn)程，也不是傳輸層的協(xié)議端口。TCP 連接的端點(diǎn)叫做套接字(socket)；
- IP地址+服務(wù)端口構(gòu)成了套接字。
TCP協(xié)議確保可靠傳輸
TCP使用自動重傳請求ARQ (Automatic Repeat reQuest)確保可靠傳輸；
停止等待機(jī)制:
報(bào)文過不了檢驗(yàn)的，被B丟棄，A發(fā)送發(fā)出去的報(bào)文無回應(yīng)、重新發(fā)送。
請注意：
- 在發(fā)送完一個分組后，必須暫時保留已發(fā)送的分組的副本，方便重傳；
-
分組和確認(rèn)分組都必須進(jìn)行編號；
-
超時計(jì)時器的重傳時間應(yīng)當(dāng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些。
確認(rèn)丟失和確認(rèn)遲到機(jī)制：
-
確認(rèn)丟失機(jī)制將超時的包覆蓋為超時重傳的包。
使用上述的確認(rèn)和重傳機(jī)制，我們就可以在不可靠的傳輸網(wǎng)絡(luò)上實(shí)現(xiàn)可靠的通信。
ARQ 表明重傳的請求是自動進(jìn)行的。
TCP流水線傳輸：停止等待協(xié)議的優(yōu)點(diǎn)是簡單，但缺點(diǎn)是信道利用率太低。
改進(jìn):
發(fā)送方可連續(xù)發(fā)送多個分組，不必每發(fā)完一個分組就停頓下來等待對方的確認(rèn)，由于信道上一直有數(shù)據(jù)不間斷地傳送，這種傳輸方式可獲得很高的信道利用率。
連續(xù) ARQ 協(xié)議(自動重傳協(xié)議):連續(xù)ARQ（AutomaticRepeat reQuest）協(xié)議指發(fā)送方維持著一個一定大小的發(fā)送窗口，位于發(fā)送窗口內(nèi)的所有分組都可連續(xù)發(fā)送出去，而中途不需要等待對方的確認(rèn)。這樣信道的利用率就提高了。而發(fā)送方每收到一個確認(rèn)就把發(fā)送窗口向前滑動一個分組的位置；
接收方一般都是采用積累確認(rèn)的方式。這就是說，接收方不必對收到的分組逐個發(fā)送確認(rèn)，而是在收到幾個分組后，對按序到達(dá)的最后一個分組發(fā)送確認(rèn)，這就表示：到這個分組為止的所有分組都已正確收到了；
積累確認(rèn)有優(yōu)點(diǎn)也有缺點(diǎn)。優(yōu)點(diǎn)是：容易實(shí)現(xiàn)，即使確認(rèn)丟失也不必重傳。但缺點(diǎn)是不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息；
例如，如果發(fā)送方發(fā)送了前5個分組，而中間的第3個分組丟失了。這時接收方只是對前兩個分組發(fā)出確認(rèn)。發(fā)送方無法知道后面三個分組的下落，而只好把后面的三個分組都再重傳一次。這就叫做Go-back-N（回退N），表示需要再退回來重傳已發(fā)送過的N個分組。可見當(dāng)通信線路質(zhì)量不好時，連續(xù)ARQ協(xié)議會帶來負(fù)面的影響。
TCP 報(bào)文段的首部格式:
- 源端口和目的端口字段各占 2 字節(jié)(16位)，源端口指發(fā)送端相關(guān)服務(wù)端口，目的端口是目標(biāo)主機(jī)相關(guān)服務(wù)，端口是傳輸層與應(yīng)用層的服務(wù)接口，傳輸層的復(fù)用和分用功能都要通過端口才能實(shí)現(xiàn)。
-
序號：當(dāng)前數(shù)據(jù)組的第一個字節(jié)在整個文件中的序號。
-
確認(rèn)號ack：接收端發(fā)送，提示發(fā)送端下一次該發(fā)的數(shù)據(jù)在整個文件中的序號（收發(fā)連續(xù)的話就是序號+1），接收端收到后，會把這個序號之前的數(shù)據(jù)從緩存中刪掉。
-
數(shù)據(jù)偏移：指明當(dāng)前TCP報(bào)文段第多少個字節(jié)后是TCP的數(shù)據(jù)部分了，數(shù)據(jù)偏移最多表示1111，即15，他最多可以表示15乘以4，即60個字節(jié)的偏移量，所以選項(xiàng)+填充最多只能是40個字節(jié)。
-
保留：就是保留，沒有用的。
-
URG：urgent，意思是優(yōu)先級高，發(fā)送端優(yōu)先發(fā)送，而不是在緩存中排隊(duì)。
-
ACK：acknowledge，1意味著確認(rèn)正式建立了會話。
-
PSH：1意味著接收端優(yōu)先讀取，而不是在緩存中排隊(duì)。
-
RST：reset，1意味著TCP會話出現(xiàn)嚴(yán)重錯誤，必須釋放和重新連接，比如你打開網(wǎng)頁又立馬將之關(guān)掉了，那么接收方也不用再給你傳輸網(wǎng)頁信息了。
-
SYN：同步，1意味著要發(fā)起會話。
-
FIN：finish，1意味著釋放連接。
-
窗口：同步接收端和發(fā)送端窗口大小的，接收端先發(fā)，發(fā)送端根據(jù)接收端的窗口尺寸確定發(fā)送端窗口尺寸。
-
檢驗(yàn)和：略，上已講。
-
緊急指針：只有URG為1才有用。
滑動窗口
1、TCP 可靠通信的具體實(shí)現(xiàn)：
- TCP 連接的每一端都必須設(shè)有兩個窗口——一個發(fā)送窗口和一個接收窗口；
-
TCP 的可靠傳輸機(jī)制用字節(jié)的序號進(jìn)行控制；
-
TCP 兩端的四個窗口經(jīng)常處于動態(tài)變化之中；
-
TCP連接的往返時間 RTT 也不是固定不變的，需要使用特定的算法估算較為合理的重傳時間；
2、窗口動態(tài)變化-以字節(jié)為單位的滑動窗口：
- A的發(fā)送窗口是由B的接受窗口長度決定的；
-
在沒有收到B確認(rèn)收到之前，A不能刪掉滑動窗口內(nèi)的內(nèi)容；
-
A可以持續(xù)給B發(fā)送，直到A的滑動窗口內(nèi)數(shù)據(jù)都發(fā)送成功；
-
B收到后給A發(fā)確認(rèn)收到的反饋ack（下一個應(yīng)該發(fā)送的字節(jié)的序號），A收到后，就可以滑動窗口到對應(yīng)的位置。例如B反饋ack是7，那么A的滑窗可以移動到7位置，1-6刪除，21-26可以繼續(xù)發(fā)送。
相關(guān)名詞：
-
P3 – P1 = A 的發(fā)送窗口（又稱為通知窗口）；
-
P2 – P1 = 已發(fā)送但尚未收到確認(rèn)的字節(jié)數(shù)；
-
P3 – P2 = 允許發(fā)送但尚未發(fā)送的字節(jié)數(shù)（又稱為可用窗口）。
TCP流量控制
流量控制(flowcontrol)就是讓發(fā)送方的發(fā)送速率不要太快，既要讓接收方來得及接收，也不要使網(wǎng)絡(luò)發(fā)生擁塞。
利用滑動窗口機(jī)制可以很方便地在 TCP 連接上實(shí)現(xiàn)流量控制，收方返回的 rwnd中會包含自己的接收窗口的大小，并且利用大小來控制發(fā)送方的數(shù)據(jù)發(fā)送，發(fā)送方在rwnd窗口之后的數(shù)據(jù)不允許發(fā)送。
流量控制根本目的是防止分組丟失，它是構(gòu)成TCP可靠性的一方面。
死鎖解決：
接收方返回窗口大小為0，可能是緩沖區(qū)已滿，需要處理緩存中的字節(jié)，發(fā)送端收到滑動窗口為0，不再發(fā)送，但是數(shù)據(jù)還沒發(fā)送完，這就造成了死鎖；
如果在某個時候，接收方緩沖區(qū)有空間了，于是發(fā)送了一個非 0 窗口的通告給接收方，不幸的是這個通告丟失了，而發(fā)送方卻還在死等接收方的非 0 窗口通告，接下來就成了死鎖；
TCP 為每一個連接設(shè)有一個持續(xù)計(jì)時器：
- 若持續(xù)計(jì)時器設(shè)置的時間到期，就周期性的向接收方發(fā)送 1 字節(jié)的 0 窗口探測報(bào)文；
- 若窗口仍然是零，則收到這個報(bào)文段的一方就重新設(shè)置持續(xù)計(jì)時器，等待重傳；
- 若窗口不是零，則死鎖的僵局就可以打破了。
三次握手齊白首
傳輸連接有三個階段，即：連接建立（三次握手）、數(shù)據(jù)傳送和連接釋放（四次揮手）。
頭兩次握手除了確定雙方都能聯(lián)通外，還通知了雙方的一些端口信息：
A：我們談戀愛吧；
B：好的（如果“好的“丟了，A就不知道B的態(tài)度，感情就無法建立起來）；
C：走你~
第三次握手原因：假如把三次握手改成僅需要兩次握手，死鎖是可能發(fā)生的。作為例子，考慮計(jì)算機(jī)A和B之間的通信，假定A給B發(fā)送一個連接請求分組，B收到了這個分組，并發(fā)送了確認(rèn)應(yīng)答分組。
按照兩次握手的協(xié)定，B認(rèn)為連接已經(jīng)成功地建立了，可以開始發(fā)送數(shù)據(jù)分組。可是，B的應(yīng)答分組在傳輸中被丟失的情況下，A將不知道B是否已準(zhǔn)備好，A認(rèn)為連接還未建立成功，將忽略B發(fā)來的任何數(shù)據(jù)分組，這樣就形成了死鎖。
四次揮手說分手
A 的應(yīng)用進(jìn)程先向其 TCP 發(fā)出連接釋放報(bào)文段，并停止再發(fā)送數(shù)據(jù)，主動關(guān)閉 TCP
連接：
- A 把連接釋放報(bào)文段首部的 FIN = 1，其序號seq = u，等待 B 的確認(rèn)（A：分手吧？）
- B 發(fā)出確認(rèn)，確認(rèn)號 ack = u + 1，而這個報(bào)文段自己的序號 seq = v（B：確定嗎？）
- TCP 服務(wù)器進(jìn)程通知高層應(yīng)用要進(jìn)行關(guān)閉了
- 從 A 到 B 這個方向的連接就釋放了，TCP 連接處于半關(guān)閉狀態(tài)。B 若發(fā)送數(shù)據(jù)，A 仍要接收（因?yàn)锳要知道B是否收到斷開請求）
- 若 B 已經(jīng)沒有要向 A 發(fā)送的數(shù)據(jù)，其應(yīng)用進(jìn)程就通知 TCP 釋放連接，并通知A連接已關(guān)閉（B:那就分了吧，我走了）
-
A 收到連接釋放報(bào)文段后，必須發(fā)出確認(rèn)(好的)
版權(quán)聲明：本文為CSDN博主「JunSIr_deCp」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。
原文鏈接：
https://blog.csdn.net/junsirhl/article/details/106155015
