一、應(yīng)用層

我們 Java 程序員在日常開發(fā)中，最經(jīng)常與應(yīng)用層打交道，在應(yīng)用層一般是使用 HTTP 協(xié)議與自定義協(xié)議。

如何自定義協(xié)議?
答：

1. 確定傳輸信息。
2. 確定數(shù)據(jù)格式（xml、json、yml、protobuffer）。

二、傳輸層

負(fù)責(zé)數(shù)據(jù)能夠從發(fā)送端傳輸接收端。

2.1 端口號(hào)：

端口號(hào)(Port)標(biāo)識(shí)了一個(gè)主機(jī)上進(jìn)行通信的不同的應(yīng)用程序。

• 端口號(hào)范圍劃分：

端口號(hào)是兩個(gè)字節(jié)無符號(hào)整數(shù)（0 ~ 65535）。

1. 0 ~ 1023 知名端口號(hào)： HTTP、FTP、SSH 等這些廣為使用的應(yīng)用層協(xié)議，他們的端口號(hào)都是固定的。
2. 1024 ~ 65535 操作系統(tǒng)動(dòng)態(tài)分配的端口號(hào)： 客戶端程序的端口號(hào)，就是由操作系統(tǒng)從這個(gè)范圍分配的。

• 常見知名端口號(hào)（well-know port Number）了解即可:

1. ssh 服務(wù)器，使用 22 端口。

2. ftp 服務(wù)器，使用 21 端口。

3. telnet 服務(wù)器，使用 23 端口。

4. http 服務(wù)器，使用 80 端口。

5. https 服務(wù)器，使用 443 端口。

我們自己寫一個(gè)程序使用端口號(hào)時(shí)，要避開這些知名端口號(hào)。

• 端口號(hào)的兩個(gè)常見問題：

1. 問題1：一個(gè)進(jìn)程是否可以同時(shí)綁定多個(gè)端口號(hào)？
   答：可以。這個(gè)是非?？尚械?#xff0c;而且在日常開發(fā)中經(jīng)常使用到。舉個(gè)栗子：一個(gè)服務(wù)器綁定兩個(gè)端口，一個(gè)端口給普通用戶使用，另一個(gè)端口給程序員 + 運(yùn)營人員使用，以便進(jìn)行日常維護(hù)，兩個(gè)端口的功能可以是不一樣的。

2. 問題2：一個(gè)端口號(hào)是否可以同時(shí)被多個(gè)進(jìn)程綁定？
   答：不能。好比“一山不容二虎，除非一公一母?！比绻粋€(gè)服務(wù)器是 TCP，一個(gè)是 UDP 此時(shí)，端口號(hào)即使在同一時(shí)刻重復(fù)了，是不影響的（一公一母），但是如果兩個(gè) TCP 或者兩個(gè) UDP，在同一時(shí)刻，使用同一個(gè)端口號(hào)，就會(huì)出現(xiàn)綁定失敗的情況。

2.2 UDP 協(xié)議：

2.2.1 UDP 協(xié)議端格式：

下面 16 位指的是 16個(gè)bit 位。

• 16 位 UDP 長度，表示整個(gè)數(shù)據(jù)報(bào)（UDP 首部 + UDP 數(shù)據(jù)）的最大長度。
• 如果校驗(yàn)和出錯(cuò)，就會(huì)直接丟棄。
• 各個(gè)術(shù)語在下面會(huì)做出詳細(xì)介紹。

上面那張圖由于排版問題，畫的不是很好，下面我給出一張更加清晰的圖：

一個(gè) UDP 數(shù)據(jù)報(bào)由報(bào)頭和載荷構(gòu)成。

• 源端口號(hào)：發(fā)送端的端口號(hào)。
• 目的端口號(hào)：接收方的端口號(hào)。
• UDP 長度：整個(gè) UDP 數(shù)據(jù)報(bào)占多少個(gè)字節(jié)。
• UDP 校驗(yàn)和（UDP Checksum）：UDP 校驗(yàn)和是用于檢測(cè) UDP 數(shù)據(jù)報(bào)在傳輸過程中是否發(fā)生錯(cuò)誤的一種機(jī)制。 舉個(gè)栗子：如果發(fā)送方計(jì)算得到的校驗(yàn)和為 0x1234，接收方接收到數(shù)據(jù)后按照相同的算法計(jì)算校驗(yàn)和，在傳輸?shù)倪^程中可能會(huì)出現(xiàn) bit 翻轉(zhuǎn)的情況，如果結(jié)果也為 0x1234，則說明數(shù)據(jù)在傳輸過程中沒有發(fā)生錯(cuò)誤。

UDP 中使用 CRC 算法來作為計(jì)算校驗(yàn)和的算法。 CRC 是一個(gè)簡(jiǎn)單粗暴的計(jì)算校驗(yàn)和的方式，循環(huán)冗余校驗(yàn)（校驗(yàn)和不是為了得到確切的值，只是為了判斷算出來得值是否一樣）。例如：設(shè)定 2 個(gè)字節(jié)得變量，把數(shù)據(jù)得每個(gè)字節(jié)取出來往這個(gè)變量上進(jìn)行累加。如果結(jié)果溢出超過 2 個(gè)字節(jié)，溢出部分舍棄。

2.2.2 UDP 存在的問題：

UDP 長度描述了整個(gè) UDP 數(shù)據(jù)報(bào)占的字節(jié)數(shù)，通過 UDP 長度，就能知道載荷一共是多少字節(jié)（全部的字節(jié)數(shù) - 報(bào)頭字節(jié)數(shù)）。

無符號(hào) 2 字節(jié)數(shù)的范圍為：0 ~ 65535（1024 * 64）。也就是說一個(gè) UDP 數(shù)據(jù)報(bào)最長就是 64 KB，不能再長了。對(duì)于現(xiàn)在來說有點(diǎn)短，隨便拿手機(jī)拍個(gè)照片，10 MB左右，所以使用 UDP 開發(fā)程序會(huì)有很大的制約。最好的解決方法是將 UDP 改寫成 TCP，TCP 對(duì)于應(yīng)用層數(shù)據(jù)包的大小是無限制的。

既然 UDP 有上面的長度限制，那么為什么不對(duì) UDP 進(jìn)行升級(jí)呢？

答：這里的升級(jí)難點(diǎn)不在于技術(shù)，而是 zz 問題，升級(jí)到更高的字節(jié)數(shù)，成本很高。單個(gè)主機(jī)升級(jí)是沒有意義的，需要對(duì)端一起升級(jí)（不然會(huì)出現(xiàn)解析錯(cuò)誤的情況），由于 UDP 是系統(tǒng)內(nèi)核實(shí)現(xiàn)的，如果全世界都是使用同一個(gè)操作系統(tǒng)，升級(jí)的成本還會(huì)小一點(diǎn)，但是市面上存在各種各樣的操作系統(tǒng)，很難統(tǒng)一升級(jí)。

2.3 UDP 特點(diǎn)：

UDP 傳輸?shù)倪^程類似于寄信。

其特點(diǎn)有：

• 無連接： 知道對(duì)端的 IP 和端口號(hào)就直接進(jìn)行傳輸，不需要建立連接（存儲(chǔ)對(duì)方信息）。
• 不可靠傳輸： 沒有確認(rèn)機(jī)制，沒有重傳機(jī)制。如果因?yàn)榫W(wǎng)絡(luò)故障該段無法發(fā)到對(duì)方，UDP 協(xié)議層也不會(huì)給應(yīng)用層返回任何錯(cuò)誤信息。
• 面向數(shù)據(jù)報(bào)： 不能夠靈活的控制讀寫數(shù)據(jù)的次數(shù)和數(shù)量。

2.4 基于 UDP 的應(yīng)用層協(xié)議：

• NFS：網(wǎng)絡(luò)文件系統(tǒng)。

• TFTP：簡(jiǎn)單文件傳輸協(xié)議。

• DHCP：動(dòng)態(tài)主機(jī)配置協(xié)議。

• BOOTP：啟動(dòng)協(xié)議（用于無盤設(shè)備啟動(dòng)）。

• DNS：域名解析協(xié)議。

當(dāng)然，也包括我們自己寫 UDP 程序時(shí)自定義的應(yīng)用層協(xié)議。

結(jié)語：
其實(shí)寫博客不僅僅是為了教大家，同時(shí)這也有利于我鞏固知識(shí)點(diǎn)，和做一個(gè)學(xué)習(xí)的總結(jié)，由于作者水平有限，對(duì)文章有任何問題還請(qǐng)指出，非常感謝。如果大家有所收獲的話還請(qǐng)不要吝嗇你們的點(diǎn)贊收藏和關(guān)注，這可以激勵(lì)我寫出更加優(yōu)秀的文章。