亚洲视频二区_亚洲欧洲日本天天堂在线观看_日韩一区二区在线观看_中文字幕不卡一区

作者 | JunSIr_deCp

責編 | 王曉曼

來源 | CSDN博客

TCP/IP協議概述

在TCP/IP協議棧，傳輸層有兩個協議TCP和UDP：

• TCP（Transmission Control Protocol，傳輸控制協議）協議：負責將要傳輸的文件分段 進行傳輸，一般用于建立會話 ，其基本特性是可靠傳輸 、流量控制，所謂三握手、四揮手也是基于TCP協議的；

• UDP（User Data Protocol，用戶數據報協議）協議：一個數據包就能夠完成數據通信，數據包不分段 ，不需要建立會話 ，不需要流量控制 ，屬于不可靠傳輸 ， 屏幕廣播 、多播 、廣播都是基于UDP協議。

以上定義，下面來詳講：

傳輸層協議的作用體現在應用層協議

TCP和UDP協議內指定不同的端口即可對應一個應用層的協議。

端口代表主機服務的偵聽"門牌號"，不管是TCP還是UDP，帶上門牌號，它就能幫你找到主機上的對應服務。

例如我們在瀏覽器訪問某個網站地址，這個動作會被我們本機上的80端口偵聽到，并處理你的網絡請求。

我們主機上常見的應用層協議端口：

• HTTP默認使用TCP的80端口標識；

• FTP默認使用TCP的21端口標識；

• SMTP默認使用TCP的25端口標識；

• POP3默認使用TCP的110端口；

• HTTPS默認使用TCP的443端口；

• DNS使用UDP的53端口；

• 遠程桌面協議（RDP）默認使用TCP的3389端口；

• Telnet 使用 TCP 的23端口 windows 訪問共享資源使用TCP的445端口；

但是我們通過TCP/UDP封裝的數據包，通過本機偵聽服務發送到目標主機，目標主機是如何識別并處理的呢？

如上圖，我們會在數據包中添加目標端口號，這樣目標主機相關服務偵聽到，就能處理我們的請求了。

TCP/UDP傳輸層協議與網絡層協議的區別

• 網絡層實現如何把數據包從這個地址(服務器)發送到另一個地址(服務器)；

• 傳輸層實現如何讓這個應用程序找到對應計算機的應用程序，即服務。

說白了，IP協議主要讓數據能知道傳到哪去，不管對應目標誰來負責接待，而TCP/UDP管。

越靠近頂層應用層、功能越強大。

UDP協議

主要特點：

• UDP 是面向無連接的，即發送數據之前不需要建立連接，如向DNS服務器申請域名解析服務；

• UDP 使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制；

• UDP 是面向報文的。UDP 沒有擁塞控制，很適合多媒體通信的要求；

• UDP 支持一對一、一對多、多對一和多對多的交互通信，這也是，應用場景如廣播、組播；

• UDP 的首部開銷小，只有 8 個字節。

基本描述：

UDP首部：

首先得知道數據包在OSI模型中層層傳輸，自頂向下。

來看看UDP首部：

• 用戶數據報 UDP 有兩個字段：數據字段和首部字段。首部字段有 8 個字節，由 4 個字段組成，每個字段都是兩個字節；

• 在計算檢驗和時，臨時把“偽首部”和 UDP 用戶數據報連接在一起。偽首部僅僅是為了計算檢驗和，偽首部12個字節取自IP數據報的字段；

• 檢驗和實現UDP數據檢驗，通過驗證檢驗和可以知道UDP數據包是否出現異常。

TCP協議

基本特點：

• TCP 是面向連接的傳輸層協議，UDP面向無連接；
• 每一條 TCP 連接只能有兩個端點(endpoint)，每一條 TCP 連接只能是點對點的（一對一）；
• TCP 提供可靠交付的服務（持續交付）；
• TCP 提供全雙工通信（信道雙向傳輸）；

• 面向字節流(傳送最小單位為字節，即八位)。

上圖可以看出TCP傳輸是如何面向字節流的，具體細節后面繼續解析：

TCP連接基于Socket：

• TCP 把連接作為最基本的抽象，每一條 TCP 連接有兩個端點；
• TCP 連接的端點不是主機，不是主機的IP 地址，不是應用進程，也不是傳輸層的協議端口。TCP 連接的端點叫做套接字(socket)；
• IP地址+服務端口構成了套接字。

TCP協議確保可靠傳輸

TCP使用自動重傳請求ARQ (Automatic Repeat reQuest)確保可靠傳輸；

停止等待機制:

報文過不了檢驗的，被B丟棄，A發送發出去的報文無回應、重新發送。

請注意：

• 在發送完一個分組后，必須暫時保留已發送的分組的副本，方便重傳；

• 分組和確認分組都必須進行編號；

• 超時計時器的重傳時間應當比數據在分組傳輸的平均往返時間更長一些。

確認丟失和確認遲到機制：

• 確認丟失機制將超時的包覆蓋為超時重傳的包。

使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網絡上實現可靠的通信。

ARQ 表明重傳的請求是自動進行的。

TCP流水線傳輸：停止等待協議的優點是簡單，但缺點是信道利用率太低。

改進:

發送方可連續發送多個分組，不必每發完一個分組就停頓下來等待對方的確認，由于信道上一直有數據不間斷地傳送，這種傳輸方式可獲得很高的信道利用率。

連續 ARQ 協議(自動重傳協議):連續ARQ（AutomaticRepeat reQuest）協議指發送方維持著一個一定大小的發送窗口，位于發送窗口內的所有分組都可連續發送出去，而中途不需要等待對方的確認。這樣信道的利用率就提高了。而發送方每收到一個確認就把發送窗口向前滑動一個分組的位置；

接收方一般都是采用積累確認的方式。這就是說，接收方不必對收到的分組逐個發送確認，而是在收到幾個分組后，對按序到達的最后一個分組發送確認，這就表示：到這個分組為止的所有分組都已正確收到了；

積累確認有優點也有缺點。優點是：容易實現，即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方已經正確收到的所有分組的信息；

例如，如果發送方發送了前5個分組，而中間的第3個分組丟失了。這時接收方只是對前兩個分組發出確認。發送方無法知道后面三個分組的下落，而只好把后面的三個分組都再重傳一次。這就叫做Go-back-N（回退N），表示需要再退回來重傳已發送過的N個分組。可見當通信線路質量不好時，連續ARQ協議會帶來負面的影響。

TCP 報文段的首部格式:

• 源端口和目的端口字段各占 2 字節(16位)，源端口指發送端相關服務端口，目的端口是目標主機相關服務，端口是傳輸層與應用層的服務接口，傳輸層的復用和分用功能都要通過端口才能實現。

• 序號：當前數據組的第一個字節在整個文件中的序號。

• 確認號ack：接收端發送，提示發送端下一次該發的數據在整個文件中的序號（收發連續的話就是序號+1），接收端收到后，會把這個序號之前的數據從緩存中刪掉。

• 數據偏移：指明當前TCP報文段第多少個字節后是TCP的數據部分了，數據偏移最多表示1111，即15，他最多可以表示15乘以4，即60個字節的偏移量，所以選項+填充最多只能是40個字節。

• 保留：就是保留，沒有用的。

• URG：urgent，意思是優先級高，發送端優先發送，而不是在緩存中排隊。

• ACK：acknowledge，1意味著確認正式建立了會話。

• PSH：1意味著接收端優先讀取，而不是在緩存中排隊。

• RST：reset，1意味著TCP會話出現嚴重錯誤，必須釋放和重新連接，比如你打開網頁又立馬將之關掉了，那么接收方也不用再給你傳輸網頁信息了。

• SYN：同步，1意味著要發起會話。

• FIN：finish，1意味著釋放連接。

• 窗口：同步接收端和發送端窗口大小的，接收端先發，發送端根據接收端的窗口尺寸確定發送端窗口尺寸。

• 檢驗和：略，上已講。

• 緊急指針：只有URG為1才有用。

滑動窗口

1、TCP 可靠通信的具體實現：

• TCP 連接的每一端都必須設有兩個窗口——一個發送窗口和一個接收窗口；

• TCP 的可靠傳輸機制用字節的序號進行控制；

• TCP 兩端的四個窗口經常處于動態變化之中；

• TCP連接的往返時間 RTT 也不是固定不變的，需要使用特定的算法估算較為合理的重傳時間；

2、窗口動態變化-以字節為單位的滑動窗口：

• A的發送窗口是由B的接受窗口長度決定的；

• 在沒有收到B確認收到之前，A不能刪掉滑動窗口內的內容；

• A可以持續給B發送，直到A的滑動窗口內數據都發送成功；

• B收到后給A發確認收到的反饋ack（下一個應該發送的字節的序號），A收到后，就可以滑動窗口到對應的位置。例如B反饋ack是7，那么A的滑窗可以移動到7位置，1-6刪除，21-26可以繼續發送。

相關名詞：

• P3 – P1 = A 的發送窗口（又稱為通知窗口）；

• P2 – P1 = 已發送但尚未收到確認的字節數；

• P3 – P2 = 允許發送但尚未發送的字節數（又稱為可用窗口）。

TCP流量控制

流量控制(flowcontrol)就是讓發送方的發送速率不要太快，既要讓接收方來得及接收，也不要使網絡發生擁塞。

利用滑動窗口機制可以很方便地在 TCP 連接上實現流量控制，收方返回的 rwnd中會包含自己的接收窗口的大小，并且利用大小來控制發送方的數據發送，發送方在rwnd窗口之后的數據不允許發送。

流量控制根本目的是防止分組丟失，它是構成TCP可靠性的一方面。

死鎖解決：

接收方返回窗口大小為0，可能是緩沖區已滿，需要處理緩存中的字節，發送端收到滑動窗口為0，不再發送，但是數據還沒發送完，這就造成了死鎖；

如果在某個時候，接收方緩沖區有空間了，于是發送了一個非 0 窗口的通告給接收方，不幸的是這個通告丟失了，而發送方卻還在死等接收方的非 0 窗口通告，接下來就成了死鎖；

TCP 為每一個連接設有一個持續計時器：

• 若持續計時器設置的時間到期，就周期性的向接收方發送 1 字節的 0 窗口探測報文；
• 若窗口仍然是零，則收到這個報文段的一方就重新設置持續計時器，等待重傳；
• 若窗口不是零，則死鎖的僵局就可以打破了。

三次握手齊白首

傳輸連接有三個階段，即：連接建立（三次握手）、數據傳送和連接釋放（四次揮手）。

頭兩次握手除了確定雙方都能聯通外，還通知了雙方的一些端口信息：

A：我們談戀愛吧；

B：好的（如果“好的“丟了，A就不知道B的態度，感情就無法建立起來）；

C：走你~

第三次握手原因：假如把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機A和B之間的通信，假定A給B發送一個連接請求分組，B收到了這個分組，并發送了確認應答分組。

按照兩次握手的協定，B認為連接已經成功地建立了，可以開始發送數據分組。可是，B的應答分組在傳輸中被丟失的情況下，A將不知道B是否已準備好，A認為連接還未建立成功，將忽略B發來的任何數據分組，這樣就形成了死鎖。

四次揮手說分手

A 的應用進程先向其 TCP 發出連接釋放報文段，并停止再發送數據，主動關閉 TCP

連接：

• A 把連接釋放報文段首部的 FIN = 1，其序號seq = u，等待 B 的確認（A：分手吧？）
• B 發出確認，確認號 ack = u + 1，而這個報文段自己的序號 seq = v（B：確定嗎？）
• TCP 服務器進程通知高層應用要進行關閉了
• 從 A 到 B 這個方向的連接就釋放了，TCP 連接處于半關閉狀態。B 若發送數據，A 仍要接收（因為A要知道B是否收到斷開請求）
• 若 B 已經沒有要向 A 發送的數據，其應用進程就通知 TCP 釋放連接，并通知A連接已關閉（B:那就分了吧，我走了）

• A 收到連接釋放報文段后，必須發出確認(好的)

版權聲明：本文為CSDN博主「JunSIr_deCp」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。

原文鏈接：
https://blog.csdn.net/junsirhl/article/details/106155015