【計算機網絡原理】淺談應用層協議的自定義和傳輸層UDP協議的總結

?????? write in front????????
?????????大家好，我是xiaoxie.希望你看完之后,有不足之處請多多諒解，讓我們一起共同進步????? . ?? ?xiaoxie?????????—CSDN博客
本文由xiaoxie??????????原創 CSDN?如需轉載還請通知?????
個人主頁：xiaoxie?????????—CSDN博客

系列專欄:xiaoxie的計算機網絡學習系列專欄——CSDN博客●'?'σσ??
我的目標:"團團等我💪( ??_?? ?)"?

(?????????? )歡迎各位→點贊👍 + 收藏?? + 留言📝?+關注（互三必回）!

?編輯?一.淺談應用層協議

1.自定義應用層協議

1.場景假設

2.信息規定

3.數據格式

1.基于行文本的方式來傳輸

2.基于xml方式來傳輸

3.基于json的方式來傳輸

4.yaml的方式來傳輸數據

5.protobuffer(pb)的方式來傳輸數據

二.傳輸層協議總結1

1.傳輸層的作用

2.端口號.

1.端口號的特性

1端口號的范圍

2. 使用命令行查看某個端口號是否被綁定

3.端口號在客服端和服務端的分配

4.多個進程是否能夠綁定同一個端口號?

5.一個進程是否可以綁定多個端口號?

3.UDP協議

1.UDP的特點

2.UDP協議的格式

?3.源端口 vs 目的端口

4.UDP長度

5.校驗和

6.應用場景

?一.淺談應用層協議

我們可以從上圖看到在TCP/ IP模型中,除了應用層是由我們來處理之外,其他層都是由操作系統來處理,雖然這樣說并不代表其他層的工作原理和它們所使用協議不重要

原因包括：

故障排查：了解網絡層次結構有助于在遇到網絡問題時進行有效的故障排查。
性能優化：理解不同層次的協議如何工作可以幫助開發者優化應用程序的性能。
安全考慮：了解網絡層次可以更好地設計安全措施，保護數據傳輸的安全。
協議設計：對于需要設計自定義協議的開發者，理解現有層次結構和協議是基礎。
互操作性：了解不同層次的協議有助于確保應用程序能夠與不同的系統和網絡設備進行互操作

這里所以博主就先為大家先簡單介紹一下應用層協議的幾種格式類型,重點介紹一下其他層的協議之后,再重新重點詳細的介紹應用層的原理和協議.

1.自定義應用層協議

1.場景假設

我們需要開發一個外賣軟件,這個時候就需要?我們來自定義應用層協議,來傳輸信息了.其中自定義應用層協議就是我們要對傳輸的數據做出約定:?

1.傳輸的數據都有那些信息.

2.傳輸的信息都有遵守什么樣的格式.

2.信息規定

這里的信息規定具體就是看你的業務需要,不同的業務需要傳輸的信息自然不同,這里并沒有什么別的技巧,根據具體的業務來具體規定即可.我們根據這個外賣軟件的場景,簡單的規定一下需要傳輸什么信息.

1.請求: 用戶id, 所在位置(這里只是舉個例子)

2.響應:商家列表其中包含的元素:1.商家名稱2.商家圖片3,商家簡介4.商家評價等等.

3.數據格式

上述的數據,都屬于"結構化數據”(通過結構體來表示的數據)網絡上傳輸的是字符串(二進制字符串),就需要對數據進行序列化.序列化的方式是有很多種的.

1.基于行文本的方式來傳輸

請求:用戶ID,所在位置經緯度\n

例子: 123,123°18′\n

響應: 商家1名稱,商家1圖片,商家1簡介,商家1評價;商家2名稱,商家2圖片,商家2簡介,商家2評價\n

例子: 北京烤鴨,圖片地址,北京烤鴨簡介,北京烤鴨評價;海底撈,圖片地址,海底撈評價,海底撈評價\n

上述格式就屬于是一種自定義的格式.要包含哪些信息,分割符都使用哪個.…. 都是可以靈活的進行控制的只要確保, 客戶端和服務器,使用同一套規則進行通信即可(非常重要)
上面這套規則,就屬于是比較一般的的?可維護性比較差,特別是屬性多了的時候,比較混亂.這種格式通常用于簡化的通信場景，其中客戶端和服務器之間的數據交換不需要復雜的結構

2.基于xml方式來傳輸

xml是通過成對的標簽來組織數據的,是一種經典的數據組織格式,在十幾二十年前是非常流行的,現在就比較少了,它和HTML的那個格式類似.

<result>

? ? ? ? ? ?<userID> 123</userID>

? ? ? ? ? ?<position>123°18′</position>

</result>

其中,標簽的名稱是啥,如何嵌套,都是可以自定義的,只要確保客戶端和服務器都遵循相同的數據格式和標簽定義，以保證數據的正確傳輸和解析.

雖然這套規則還是不夠簡潔高效,但它的結構性和自描述性使其在某些場景下仍然是一個不錯的選擇，特別是在需要高度結構化數據和元數據的情況下。

3.基于json的方式來傳輸

json是目前最流行,最廣泛的輕量級數據交換格式。它易于人閱讀和編寫，同時也易于機器解析和生成

{

? ?userID:123,

? ?position:123°18′

}

使用{ }作為邊界,{ }里面為鍵值對,鍵值對之間使用 , 來分割,鍵和值之間使用:來分割.

JSON的優點：

輕量性：JSON格式簡潔，沒有XML那么冗長，通常比XML文件更小。
易于閱讀和編寫：JSON的結構類似于編程語言中的結構，使得它易于人類閱讀和編寫。
靈活的格式：JSON支持各種數據類型，包括字符串、數字、數組、對象（也稱為字典或哈希表）、布爾值和null。
與JavaScript的兼容性：JSON與JavaScript天然集成，可以直接被JavaScript解析為對象或序列化為字符串。
跨語言支持：許多編程語言提供了原生的庫來處理JSON，包括但不限于Python、Java、C#、Ruby等。
自描述：JSON對象是鍵值對的集合，使得數據結構清晰且易于理解。
不需要啟動和結束標簽：與XML不同，JSON不需要額外的開始和結束標簽來標識文檔。
高效的數據交換：JSON通常用于APIs，因其高效性而成為RESTful Web服務中數據交換的首選格式。

JSON的應用場景：

Web API通信：作為客戶端和服務器之間數據交換的標準格式。
配置文件：存儲應用程序的配置信息。
數據存儲：作為輕量級的數據存儲格式，用于數據庫或文件系統。
消息隊列：在消息傳遞系統中作為消息的格式。
緩存：作為緩存數據的格式，因為它易于序列化和反序列化。
前端開發：在網頁開發中，JSON常用于與后端進行數據交換。
微服務架構：在微服務架構中，服務之間通過JSON交換數據。
移動應用開發：在移動應用中，JSON常用于客戶端和服務器之間的通信。
游戲開發：在游戲開發中，JSON用于存儲游戲數據和配置。
數據分析：在數據分析和機器學習中，JSON用于傳輸數據集或模型參數。

JSON的這些優點使其成為現代網絡應用中數據交換的首選格式，尤其是在需要快速、高效和跨語言兼容的場景中。同時注意確保客服端和服務端規則的統一.

4.yaml的方式來傳輸數據

基于縮進的格式來組織數據的

result

? ?userID:123

? ?position:123°18′

它是通過縮進來表示包含/嵌套關系的,而xml是通過標簽來表示同時注意這個縮進是有講究的

縮進：YAML嚴格使用空格進行縮進，通常是兩個空格作為一級縮進，且不允許混用空格和制表符（Tab）。
一致性：整個文檔的縮進必須保持一致，否則會導致解析錯誤。
空格敏感：除了縮進，YAML還對空格敏感，因此在鍵值對中使用空格需要特別注意。

YML的這些特性使其在需要高度可讀性和結構化的配置文件或數據表示時非常適用。?

5.protobuffer(pb)的方式來傳輸數據

前面幾種都是文本格式，肉眼能看懂而 pb 是二進制格式了,肉眼看不懂,博主這里也不好手搓出一個例子
pb 針對要傳輸的數據進一步的整理和壓縮了雖然可讀性不好,能夠把空間最充分的利用,最節省網絡帶寬,效率也最高 .

Pb雖然在人機交互方面不如文本格式直觀，但在機器之間傳輸數據時，其效率和性能優勢非常明顯。使用Pb時，首先需要定義數據結構的.proto文件，然后使用Pb工具生成相應語言的代碼，之后就可以使用這些代碼來序列化和反序列化數據。

由于Protobuf是二進制格式，確實無法直接提供一個手寫的示例，但定義數據結構的.proto文件示例如下：

syntax = "proto3";
package example;message Result {int32 userID = 1;string position = 2;
}

在這個例子中，Result是一個消息類型，包含一個整型的userID字段和一個字符串類型的position字段。字段后面的數字（如1和2）是字段的標簽，用于序列化時標識字段。

使用Protobuf時，需要通過編譯.proto文件生成對應的序列化和反序列化代碼，然后才能在程序中使用。

以上就是關于應用層協議的一點介紹,具體的內容,在博主總結完其余幾層協議和原理之后,會對應用層協議重點介紹.

二.傳輸層協議總結1

這里解釋一下由于TCP的內容比較復雜,所以這里就主要是對UDP協議的總結,博主將會在下一篇博客重點介紹TCP協議(這個非常非常重要,屬于是面試必考,大學考試的話也必考).

1.傳輸層的作用

傳輸層是OSI（開放系統互聯）七層模型和TCP/IP四層模型中的一個關鍵層次，它位于網絡層之上，應用層之下。傳輸層的主要作用是提供進程間的通信服務，負責在網絡中不同主機的應用程序之間建立、維護和終止通信連接

2.端口號.

傳輸層中有個非常重要的名詞就是端口號,端口號是網絡套接字（通常稱為套接字地址）的一個組成部分，用于區分同一IP地址上運行的不同網絡服務或進程。端口號(傳輸層)與IP地址(網絡層)一起構成了一個唯一的網絡端點，允許數據被正確地路由到正確的應用程序。

1.端口號的特性

1端口號的范圍

端口號是一個16位數字,所以它的范圍為 0 - 65535?其中，0到1023是眾所周知的端口（也叫系統端口或特權端口），通常被系統或者常見服務和應用程序使用.所以當我們寫自己的服務器系統的時候最好要避開這些端口號.

2. 使用命令行查看某個端口號是否被綁定

同一臺機器上,同一時刻,端口號不能被重復綁定,例如如果在一臺機器上進程A綁定了端口號8023,進程B也嘗試綁定端口號8023,就會綁定失敗.那我們該如何確定某個端口號被進程綁定了呢.

Windows?

netstat -ano | findstr [端口號]

Linux

netstat -tuln | grep [端口號]

這里以Windows舉例?

?就可以看到某個端口號是否被綁定

3.端口號在客服端和服務端的分配

客戶端通常在動態分配的端口號（臨時端口，通常在1024到65535之間）上發起通信，而服務器監聽在固定的端口號上。

4.多個進程是否能夠綁定同一個端口號?

前文提到雖然同一臺機器上,同一時刻,端口號不能被重復綁定,但是操作系統允許TCP和UDP套接字綁定到同一個端口，因為它們在協議層面上是獨立的，并且可以共存而不相互干擾。當然可以使用是可以使用,但是盡量避免使用,畢竟端口號多著呢.你就算是服務器系統也不可能同時啟動六萬多個進程.這有助于提高系統的清晰性、安全性和性能，并減少潛在的沖突和混淆.

5.一個進程是否可以綁定多個端口號?

在實際應用中，一個進程綁定多個端口是常見的，尤其是在提供多種服務或需要處理大量并發連接的服務器上,每個服務綁定到不同的端口號。并且也非常推薦使用.

舉個栗子

比如寫一個服務器程序,首先服務器需要有一個端口號,給客戶端提供業務功能,這樣的端口,稱為“業務端口” 給普通用戶用的
程序猿還需要能夠對這個服務器進行更精細的控制.
比如控制讓這個服務器重新加載配置/開啟某個功能/重新啟動/重新加載數據/修改某個選項設定...
這樣的操作,經常會通過網絡來進行操作,服務器就會另外綁定一個端口號,稱為"管理端口"

程序員想對這個服務器進行管理操作,就通過管理端口給服務器發送一些對應的請求,服務器執行對應的邏輯
給程序猿+運營人員例如搞個后門,給指定用戶的賬戶余額增加 1000.這樣的操作勢必要通過管理端口不能通過業務端口(萬一被玩家發現了!
日常開發會遇到一些 bug,需要去査看服務器的一些運行狀態 (比如服務器中的一些關鍵的變量是啥樣的值...服務器不能直接用就需要調試器去調試(調試器一調試就會把服務器阻塞住,無法給別的客戶端提供服務了)也會通過網絡的方式,給服務器發調試請求,服務器返回對應的關鍵信息,稱為"調試端口"

還有一些其他的方面這里就不多舉例,總之這種一個進程綁定多個端口是一種常見的做法，它提供了靈活性和安全性，有助于構建可維護和可擴展的服務器應用程序。

3.UDP協議

UDP協議比較簡單,這里就簡單介紹

1.UDP的特點

1.無連接

UDP是一種無連接的協議，這意味著在數據傳輸之前，發送方和接收方之間不需要建立和維護一個連續的連接。發送端可以直接向接收端發送數據報，而無需事先通知或握手。這簡化了通信流程，減少了延遲，但也意味著發送方不知道數據是否成功到達目的地。

2.不可靠傳輸

UDP不提供像TCP那樣的數據包確認、重傳機制或錯誤恢復服務。數據報可能會在網絡中丟失、重復或亂序到達，UDP本身不負責解決這些問題。因此，數據的可靠傳輸需要由上層應用來保證，或者接受數據丟失的可能性。

3.面向數據報

UDP是面向數據報的協議，它將應用程序的數據封裝成數據報（datagrams）進行傳輸。每個數據報都是獨立傳輸的單元，包含完整的源地址和目的地址信息。這使得UDP適合傳輸少量數據或對實時性要求高的應用。

4.全雙工

指的是數據可以同時在兩個方向上傳輸。在UDP中，既然沒有連接的概念，自然也沒有限制數據只能單向流動，所以UDP支持全雙工通信。發送方和接收方可以同時獨立地發送數據，而不需要等待對方的響應，這增強了協議的靈活性和效率。

2.UDP協議的格式

源端口（Source Port）：占用16位，標識發送方的應用程序端口。這個字段是可選的，但當使用時，它標明了發送方進程的端口號，有助于接收方回復消息到正確的應用程序。如果未使用，該字段通常被置為0。
目的端口（Destination Port）：同樣占用16位，表示接收方的應用程序端口。這個字段是必要的，確保數據能夠被正確地路由到接收端的指定應用程序。
長度（Length）：占用16位，指示整個UDP數據報的長度，包括UDP頭部和數據部分。這個字段的單位是字節，因此最小的有效UDP數據報長度為8字節（僅頭部）。
校驗和（Checksum）：占用16位，提供了一個基本的錯誤檢測機制。校驗和覆蓋UDP頭部和數據部分，以及一個偽頭部（包含IP頭部的部分信息），以確保數據的完整性。如果接收方計算的校驗和與數據包中的校驗和不匹配，該數據包將被丟棄。

?3.源端口 vs 目的端口

UDP源端口（Source Port）

標識性：源端口號通常用于標識發送數據報的本地應用程序或服務。
可選性：在UDP中，源端口號是可選的，應用程序可以選擇不指定源端口號，讓操作系統自動選擇一個臨時的源端口。
客戶端通信：當客戶端應用程序向服務器發送數據報時，通常需要指定一個源端口號，以便服務器能夠識別并可能需要向客戶端發送響應。
多任務處理：源端口號允許一臺主機上的多個應用程序同時進行通信。

UDP目的端口（Destination Port）

服務識別：目的端口號用于指定接收數據報的遠程服務或應用程序。例如，如果一個客戶端想要訪問服務器上的DNS服務，它會將目的端口號設置為53（DNS服務的標準端口）。
服務器監聽：服務器應用程序通常會監聽特定的端口，當它們接收到發往該端口的數據報時，會知道如何處理這些數據。
無連接：由于UDP是無連接的，目的端口號不用于建立或維護連接，而僅僅是為了將數據報路由到正確的服務或應用程序。

4.UDP長度

由于UDP數據報 = UDP報頭 + 載荷.而UDP長度表示的是整個UDP數據報的長度,而UDP長度最多為16位也就是65535即為64kb,所以傳輸數據時UDP最多傳輸的數據就為64kb不可以再多了,也正是因為這UDP數據報長度的制約導致了UDP無法傳輸數據量大的數據.

5.校驗和

數據在網絡的傳輸過程中,出錯是不可以避免的,例如發生比特翻轉等等,那么我們就需要對傳輸過來的數據進行校驗知道數據在傳輸過程中是否出錯,而UDP的校驗和就是通過CRC(循環冗余校驗)來完成的.

CRC是一種廣泛使用的錯誤檢測碼，通過對數據執行多項式除法生成校驗碼，以確保數據的完整性。

UDP校驗和的計算過程如下：

偽首部的添加：在計算校驗和時，UDP數據報前面會臨時添加一個偽首部，這個偽首部包含了源IP地址、目的IP地址和UDP長度等信息，但這個偽首部僅用于計算校驗和，并不隨數據報一起發送。
填充：如果UDP數據報的長度（包括偽首部、UDP首部和數據）不是16位的整數倍，則在數據報的末尾添加一個全零的字節進行填充。
計算校驗和：將整個UDP數據報（包括偽首部、UDP首部和數據）按照16位的單元進行累加，如果中間結果的高16位不為0，則繼續與低16位相加，重復此過程直到高16位為0。然后將得到的16位數值進行按位取反，得到的結果就是校驗和。
發送：發送方將計算得到的校驗和放入UDP數據報的校驗和字段中，然后發送整個UDP數據報。
接收：接收方在收到UDP數據報后，使用相同的過程重新計算校驗和，如果計算得到的校驗和與UDP數據報中的校驗和字段相同，則認為數據報未損壞；如果不同，則認為數據報在傳輸過程中可能出現了錯誤。

UDP校驗和雖然可以檢測許多常見的錯誤，但它不是百分百可靠，有些錯誤可能無法被檢測到。盡管如此，UDP校驗和提供了一種簡單、高效的錯誤檢測方法，適用于那些可以容忍一定錯誤率的實時或流式數據傳輸應用。

除了使用CRC,還有一種方法-- MD5,MD5是一種廣泛使用的哈希函數，它產生一個128位（16字節）的哈希值，通常用于驗證數據的完整性。不光是在UDP中使用于校驗和,在我們以后開發工作中,也算是會用到的一種方法.我們可以簡單了解一下,當然現在的MD5已經變得容易破解了,我們需要這種在對數據安全領域比較高的場景中,推薦使用更加安全的哈希函數

當使用MD5作為UDP數據報的校驗方法時，通常的做法是：

計算MD5哈希：發送方首先對UDP數據負載計算MD5哈希值。
附加MD5哈希：將計算得到的MD5哈希值作為UDP數據負載的一部分附加到原始數據之后。
傳輸：發送方將整個UDP數據報（包括附加的MD5哈希值）發送給接收方。
接收與驗證：接收方在收到UDP數據報后，會提取出數據負載，并對接收到的數據負載重新計算MD5哈希值。
比較哈希值：接收方比較重新計算的MD5哈希值與數據報中附帶的MD5哈希值。如果兩個哈希值相同，那么認為數據在傳輸過程中沒有被篡改；如果不同，那么數據可能已經被篡改，接收方應該丟棄該數據報。