應用層協(xié)議是請求與響應服務，客戶端的請求與服務器的響應是通過應用層傳輸?shù)骄W(wǎng)絡中的，但再實際上，應用層并不能直接通信，需要將數(shù)據(jù)進行報頭的封裝，向下層交付，貫穿整個協(xié)議棧。我們已經談到應用層協(xié)議負責應用。往下層交付，我們又要考慮交給誰？瀏覽器接收到請求后，同樣要經過協(xié)議棧，并且需要知道將數(shù)據(jù)交到哪一個應用。

在協(xié)議中，我們始終要考慮，數(shù)據(jù)如何向上交付，報文和有效載荷如何分離的問題，還要考慮粘包等問題。

本文介紹距離應用層最近的傳輸層，負責數(shù)據(jù)從發(fā)送端送到接收端。

傳輸層協(xié)議有UDP和TCP，UDP是不可靠連接，不考慮數(shù)據(jù)丟失，正因如此，UDP協(xié)議很簡單，并且資源浪費小。而TCP協(xié)議必須考慮大量數(shù)據(jù)丟失的問題，十分的負責，必然的代價是資源的消耗（空間和時間上）。

從了解UDP協(xié)議。

端口號

之前說過，端口號是用來標記主機上唯一的一個進程。數(shù)據(jù)在網(wǎng)絡傳輸中，必須要解決上層交付的問題，因此傳輸中必定會獲取到上層標志進程的唯一標志，就是端口號。所以端口是傳輸層的概念，主要負責向上交付的問題。

? ? ? ?? ?

傳輸層獲取到應用層的數(shù)據(jù)后，必定會添加端口相關的報頭

同樣傳輸層向上交付數(shù)據(jù)時，也必須解析出目標端口和源端口，向上交付有效載荷。

五元組標志通信?

在TCP/ip協(xié)議中，通過源端口，目的端口，源ip,目的ip，及協(xié)議號。這個五元組就能雙方通信。

?

查看五元組

常用的方式是netstat - nltp a u?

介紹選項:

• n:把字符顯示成數(shù)字
• l:查看監(jiān)聽狀態(tài)的服務，去掉" l "，就能查看所有狀態(tài)
• u:查看udp協(xié)議
• t:查看tcp協(xié)議
• a:顯示所有的選項，默認不顯示LISTEN相關
• p:查看進程?

---

端口號的劃分

0-1023號是知名端口，普通用戶是不能綁定的。

1024-65535是可以被OS分配的動態(tài)端口號。

---

?UDP協(xié)議

UDP協(xié)議是一中無連接的協(xié)議，它不像TCP協(xié)議在通信前需要建立連接。這種特性使得UDP在對時實性能要求比較高，對數(shù)據(jù)丟失容忍度高的場合有極高的運用。如視頻流，電話通信等。

UDP報文傳輸都是獨立的，每一個UDP都被封裝成獨立的數(shù)據(jù)報，數(shù)據(jù)報中必然包含著源端口，目標端口。

UDP協(xié)議格式

udp協(xié)議的基本格式如下：

源端口：數(shù)據(jù)從哪里來

目的端口：數(shù)據(jù)交付到哪里

udp長度：包括報頭和有效載荷

校驗和：如果UDP報文出錯，就直接丟棄

---

報頭和有效載荷分離的問題？

UDP的報頭是四個字段，每一個字段是16位。因此讀到8字節(jié)后，就代表讀完報頭。繼續(xù)讀取到結尾，就讀完有效載荷，就能做到報頭和有效載荷的分離。

數(shù)據(jù)如何向上交付的問題？?

獲取到有效載荷后，就要將數(shù)據(jù)往上層交付，在上層中有大量的協(xié)議進程，具體交到哪一個進程呢，主要是目的端口決定的！獲取到目的端口后，就能交付。

---

如何理解報頭

?報頭的本質就是一個結構化字段，必然也是數(shù)據(jù)。其實就是一個結構體。

數(shù)據(jù)的封裝

傳輸層收到應用層發(fā)來的數(shù)據(jù)后，會在傳輸層創(chuàng)建udp_header報頭類型的變量，并且填充相應的字段。接著在OS開辟一塊空間，將報頭和有效載荷封裝到一起，并直接發(fā)到下一級。

因此udp的傳輸層是沒有緩沖區(qū)的，報文是直接向下交付的。

報文的管理

udp沒有發(fā)送緩沖區(qū)，必然的結果是數(shù)據(jù)一旦被封裝就直接發(fā)送到對方的主機上，對方主機就會一下子收到大量的報文，必然會來不及處理。所以必須對報文進行管理。OS怎么管理呢？先描述，再組織。

實際上就是一個隊列，如果有報文發(fā)來，就先維護起來，列入隊列中sk_buff 。要處理數(shù)據(jù)時，就往隊列中取出對頭的數(shù)據(jù)去處理。

---

UDP協(xié)議的特點

?udp協(xié)議就像寄信：

• 無連接：知道對端的主機和端口就能直接通信，無需要建立連接。TCP有三次握手，是面向連接。
• 不可靠：沒有確認機制，沒有重傳。如果數(shù)據(jù)校驗不一致，就直接丟棄這個報文。
• 面向數(shù)據(jù)報：不能控制讀取的大小和次數(shù)。

面向數(shù)據(jù)報

應用層交付給UDP一個報文，報文封裝后就直接發(fā)送到對端。

不會囤積報文，或者分割報文。

對端必須一次收完一個完整的報文。

比如一份udp報文有10個字節(jié)：
發(fā)送端會立刻調用sento發(fā)送報文。接收方會調用recvfrom,一次性接收10個字節(jié)。這樣就解決了粘包的問題。

接收方的報文天然就存放著數(shù)據(jù)報的長度，所以依靠數(shù)據(jù)報就能實現(xiàn)有效載荷和報文的分離，能夠知道有效負載的長度。

基于UDP的應用層協(xié)議

• NFS：網(wǎng)絡文件系統(tǒng)。
• TFTP：簡單文件傳輸協(xié)議。
• DHCP：動態(tài)主機配置協(xié)議。
• BOOTP：啟動協(xié)議（用于無盤設備啟動）。
• DNS：域名解析協(xié)議。

UDP的使用場景

• 實時視頻流和音頻流傳輸，如在線直播、視頻會議等；
• 實時游戲，如在線游戲中的游戲數(shù)據(jù)傳輸；
• 簡單的請求/響應交互，如 DNS、SNMP 等；
• 廣播通信，如廣播、多播等；