?作者簡介:大家好,我是小楊
📃個人主頁:「小楊」的csdn博客
🐳希望大家多多支持🥰一起進步呀!
UDP協議
1,UDP 簡介
UDP(User Datagram Protocol)是一種無連接的傳輸層協議,它提供了一種簡單的、不可靠的數據傳輸服務。
UDP 提供了不面向連接的通信,且不對傳送的數據報進行可靠的保證,適用于一次傳送少量的數據,不適用于傳輸大量的數據。
2,UDP 特點
UDP 的主要特點為無連接,不可靠傳輸,面向數據報,全雙工通信。下面對這些特點進行逐一解釋:
1,無連接:UDP是一種無連接的傳輸協議,這意味著在通信之前不需要進行連接建立的過程。發送方直接向目標主機發送數據報,接收方無需事先建立連接就能接收數據。
2,不可靠傳輸:UDP不保證數據傳輸的可靠性。它將數據劃分為獨立的數據報,并通過網絡發送,但不提供丟包重傳、數據校驗和錯序整理等機制。如果在傳輸過程中發生數據丟失、損壞或重復,UDP協議不會進行任何處理,這使得UDP的傳輸不可靠。
3,面向數據報:UDP以數據報(Datagram)為單位進行通信。每個UDP數據包是一個獨立的數據報,具有自己的報頭,其中包含源端口號、目標端口號和數據長度等信息。這使得UDP的通信單位獨立,不受其他數據報的影響,獨立地發送和接收數據。
4,全雙工通信:UDP支持全雙工通信,允許發送方和接收方同時發送和接收數據。發送方可以隨時發送數據報,而接收方可以在任何時間接收數據報,而不受發送方的限制。這使得UDP在實現實時雙向通信時具有優勢。
3,UDP 段格式
UDP協議的數據包(也稱為UDP報文)由兩部分組成:UDP頭部和UDP數據部分。
UDP 協議段格式示意圖:
UDP 數據包中的各字段代表含義如下:
1,源端口號(Source Port):16位字段,表示發送方的端口號,用于標識發起UDP通信的應用程序的發送端口。
2,目標端口號(Destination Port):16位字段,表示接收方的端口號,用于標識接收方應用程序的接收端口。
3,長度(Length):16位字段,表示UDP報文的長度,包括UDP頭部和數據部分的總長度。
4,校驗和(Checksum):16位字段,用于檢測UDP報文在傳輸過程中是否發生錯誤或被篡改。
5,數據區(Data):可選字段,用于攜帶實際的應用數據內容。
UDP 數據包中的注意事項:
1,UDP協議的首部固定為8個字節,即源端口、目的端口、長度和校驗和,其中校驗和字段為可選字段,可以不包含校驗和。
2,UDP報文長度包括UDP頭部和數據部分,最大長度為16位,UDP數據報的最大長度被限制為65535 B ,也就是最多只能傳輸64KB的數據。如果應用程序需要傳輸更大的數據,則需要將數據進行分片,并在應用層協議中進行重組,或者采用TCP協議。
3,UDP首部中的源端口和目的端口用于標識發送方和接收方的應用程序或服務。這兩個字段共同決定了數據包的傳輸路徑,以確保正確地將數據包傳送到相應的應用程序或服務。
4,UDP 擴展知識
拓展:端口號介紹
端口號是在傳輸層中使用的概念,用于標識不同應用程序或服務的網絡進程。
在傳輸層協議中,頭部中的源端口和目的端口用于標識發送方和接收方的應用程序或服務。
這兩個字段共同決定了數據包的傳輸路徑,以確保正確地將數據包傳送到相應的應用程序或服務。
端口號是一個16比特(2字節)的無符號整數,代表的取值范圍為0 ~ 65535,在該范圍內被劃分3部分,分別為:
- 知名端口:從0到1023的端口號被指定為知名端口,用于一些廣泛使用的標準服務。
- 注冊端口:從1024到49151的端口號被指定為注冊端口,用于一些用戶注冊的應用程序或服務。
- 動態或私有端口:從49152到65535的端口號是動態或私有端口,也稱為臨時端口。
下面是一些常見的知名端口號的定義和用途:
- 22:SSH端口,用于安全外殼協議,用于遠程登錄和安全文件傳輸。
- 53:DNS端口,用于域名系統解析域名到IP地址。
- 80:HTTP端口,用于超文本傳輸協議,用于Web瀏覽器和服務器之間的通信。
- 143:IMAP端口,用于Internet消息訪問協議,用于電子郵件客戶端與服務器之間的通信。
- 443:HTTPS端口,用于安全的超文本傳輸協議,通過SSL/TLS加密的HTTP通信。
- 3306:MySQL數據庫服務器的默認端口號。
進程與端口號之間的關系:
一個進程可以綁定多個端口號,但是一個端口號不能被多個進程綁定。
拓展:校驗和字段介紹
校驗和的作用是用于驗證UDP數據包的完整性,以確保數據在傳輸過程中沒有被篡改或損壞。
校驗和的作用過程:發送方在發送UDP數據包時,會計算數據包的校驗和(校驗和的計算涉及UDP頭部和數據部分),并將校驗和值存儲在校驗和字段中。接收方在接收到UDP數據包后,會重新計算數據包的校驗和,并將計算得到的校驗和值與接收到的校驗和字段進行比對。如果兩者一致,則說明數據包在傳輸過程中沒有損壞;如果兩者不一致,則說明數據包可能在傳輸過程中發生了錯誤。
校驗和字段為可選字段,在UDP協議中是可以不選,是否使用校驗和可以根據應用程序的需求和對數據完整性的要求來決定。
- 對于實時性要求高、數據可靠性要求較低的應用,可以選擇不使用校驗和以減少開銷和延遲。
- 對于對數據的可靠性要求較高的應用,可以自行添加校驗和機制來保證數據的完整性。
經典問題:基于傳輸層UDP協議,來實現一個可靠傳輸,應該如何設計?
問題引入:雖然校驗和可以提供一定程度的數據完整性檢查,但是因為UDP本身是一種不可靠傳輸協議,即使檢測到錯誤或數據篡改,UDP也不會進行任何恢復操作,具體就是不提供丟包重傳、數據校驗和錯序整理等機制。
若想基于傳輸層UDP協議,來實現一個可靠傳輸,那就是從下面這幾個方面來考慮:
- 數據包序列號:為每個發送的數據包分配一個唯一的序號。序號可以是一個遞增的數字或其他唯一標識符,接收方根據序列號對接收到的數據包進行排序和重組,以確保數據包按正確的順序傳遞給應用層。
- 確認應答機制:接收端需要向發送端發送確認消息以確認已收到的數據包。發送端在收到確認消息后才能發送下一個數據包。如果發送端沒有收到確認消息,則會啟動超時重傳機制。
- 超時重傳:當發送端發送一個數據包后,如果在一定時間內沒有收到確認消息,則認為數據包丟失或發生了錯誤。發送端需要啟動超時重傳機制,重新發送丟失的數據包。
結語
這就是本期博客的全部內容啦!如果有什么其他的問題無法自己解決,可以在評論區留言哦!
最后,如果你覺得這篇文章寫的還不錯的話或者有所收獲的話,麻煩小伙伴們動動你們的小手,給個三連唄(點贊👍,評論?,收藏📖),多多支持一下!各位的支持是我最大的動力,后期不斷更新優質的內容來幫助大家,一起進步。那我們下期見!