關(guān)于UDP和TCP 我們就要重點聊一聊傳輸層（負(fù)責(zé)數(shù)據(jù)能夠從發(fā)送端傳輸接收端.）

一、關(guān)于端口號

1.1 端口號的理解

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

每一個應(yīng)用層服務(wù)（進(jìn)程）都綁定著自己的協(xié)議，而具體這個數(shù)據(jù)要傳輸給哪一個應(yīng)用程序，是要根據(jù)具體的端口號來決定的，而交給哪個服務(wù)的本質(zhì)也是交給哪個進(jìn)程又因為進(jìn)程bind了自己的端口號所以O(shè)S究竟會把數(shù)據(jù)交給誰，其實是根據(jù)端口號來確認(rèn)的！

在TCP/IP協(xié)議中, 用 "源IP", "源端口號", "目的IP", "目的端口號", "協(xié)議號" 這樣一個五元組來標(biāo)識一個通信(可以通過netstat -n查看);

1.2 端口號范圍的劃分

0 - 1023: 知名端口號, HTTP, FTP, SSH等這些廣為使用的應(yīng)用層協(xié)議, 他們的端口號都是固定的.

1024 - 65535: 操作系統(tǒng)動態(tài)分配的端口號. 客戶端程序的端口號, 就是由操作系統(tǒng)從這個范圍分配的.

1.3 認(rèn)識知名端口號

有些服務(wù)器是非常常用的, 為了使用方便, 人們約定一些常用的服務(wù)器, 都是用以下這些固定的端口號:

• 1、ssh服務(wù)器, 使用22端口
• 2、ftp服務(wù)器, 使用21端口
• 3、telnet服務(wù)器, 使用23端口
• 4、http服務(wù)器, 使用80端口
• 5、https服務(wù)器, 使用443

執(zhí)行下面的命令, 可以看到知名端口號

cat /etc/services

我們自己寫一個程序使用端口號時, 要避開這些知名端口號.

1.4 一個進(jìn)程可以bind多個端口號

一個端口號不能被多個進(jìn)程bind，但是一個進(jìn)程可以被多個端口號bind的（一個進(jìn)程可以有多個文件描述符，而每一個文件描述符都可以對應(yīng)一個端口號，）！！

問題：什么情況下需要一個進(jìn)程綁定多個端口號呢？？

---->比如HTTP和HTTPS，同一個Web服務(wù)器可能需要監(jiān)聽80和443端口，分別處理HTTP和HTTPS的請求（每次調(diào)用bind都會為該進(jìn)程創(chuàng)建一個獨立的socket，這些socket是由內(nèi)核管理的，他們之間是相互獨立互不影響的，所以bind多個套接字就對應(yīng)監(jiān)聽多個套接字?。。?/span>

1.5 相關(guān)命令

1、netstat是一個用來查看網(wǎng)絡(luò)狀態(tài)的重要工具.

• 語法：netstat [選項]
• 功能：查看網(wǎng)絡(luò)狀態(tài)

常用選項：

• n 拒絕顯示別名，能顯示數(shù)字的全部轉(zhuǎn)化成數(shù)字
• l 僅列出有在 Listen (監(jiān)聽) 的服務(wù)狀態(tài)
• p 顯示建立相關(guān)鏈接的程序名
• t (tcp)僅顯示tcp相關(guān)選項
• u (udp)僅顯示udp相關(guān)選項
• a (all)顯示所有選項，默認(rèn)不顯示LISTEN相關(guān)

其中unix是域間套接字，用來進(jìn)行本地通信（懂了網(wǎng)絡(luò)套接字之后學(xué)習(xí)成本就不大了?。?/span>

2、pidof在查看服務(wù)器的進(jìn)程id時非常方便.

語法：pidof [進(jìn)程名]

功能：通過進(jìn)程名, 查看進(jìn)程id

二、UDP報頭

2.1 研究協(xié)議的一些具體問題

1、報頭和有效載荷是如何進(jìn)行分離的？？

2、有效載荷應(yīng)該交付給上層的那一個協(xié)議呢？（協(xié)議字段、方案）

3、認(rèn)識報頭的組成

4、學(xué)習(xí)協(xié)議的周邊知識

2.2 UDP協(xié)議端格式

問題1：報頭和有效載荷是如何分離的呢？？

------>UDP采用的是定長分離（8字節(jié)），通過讀取前8個字節(jié)，可以讀到UDP的長度（16位UDP長度, 表示整個數(shù)據(jù)報(UDP首部+UDP數(shù)據(jù))的最大長度;），然后數(shù)據(jù)的大小就是UDP長度-8，就實現(xiàn)了報頭和有效載荷的分離——>固定長度+自描述字段

問題2：有效載荷又是如何交付給上層的？？

——>分離之后通過報頭信息的源端口號和目的端口號，確認(rèn)應(yīng)該交付給那個進(jìn)程（一般來說已經(jīng)bind相關(guān)端口號了）

問題3：UDP可以保證可靠性么？？

——> 雖然不保證可靠性，但是至少要是對的，其中UDP校驗和就是一種檢驗UDP數(shù)據(jù)包是否有誤的校驗機(jī)制，他通過了某種算法將UDP數(shù)據(jù)包中的所有數(shù)據(jù)進(jìn)行計算然后存儲在報頭字段中，以便確保接收方在收到數(shù)據(jù)包后進(jìn)行校驗。如果校驗失敗的話，就直接把這個數(shù)據(jù)包丟棄！！

問題4：UDP有什么應(yīng)用場景？

——>比如我們的視頻傳輸就是UDP協(xié)議，其實就是無數(shù)張相片的組成傳輸過來，而你切換清晰度無非就跟圖片的一些像素信息有關(guān)，像素越高越清晰一般就會越大，可能就會導(dǎo)致udp的傳送速度變慢，有時候你電視劇看著看著出現(xiàn)緩沖了，你可能就會把畫質(zhì)調(diào)低一點這樣傳輸就會快一點，甚至有些時候?qū)嵲诰W(wǎng)絡(luò)太擁塞了可能會出現(xiàn)丟包的情況，那么視頻就會出現(xiàn)異常，但是UDP對這種現(xiàn)象是不負(fù)責(zé)任的??！因為他半身就不保證可靠性。。而如果你想保證可靠性那你就應(yīng)該用TCP協(xié)議，所以研究UDP的應(yīng)用場景，其實就是基于上層不同協(xié)議對應(yīng)的應(yīng)用場景是否需要選擇UDP！

問題5：如果UDP數(shù)據(jù)包太大怎么辦？？

——>我們注意到, UDP協(xié)議首部中有一個16位的最大長度. 也就是說一個UDP能傳輸?shù)臄?shù)據(jù)最大長度是64K(包含UDP首部).然而64K在當(dāng)今的互聯(lián)網(wǎng)環(huán)境下, 是一個非常小的數(shù)字.如果我們需要傳輸?shù)臄?shù)據(jù)超過64k，就需要在應(yīng)用層手動的分包, 多次發(fā)送并在接收端手動拼裝（面向數(shù)據(jù)報）

2.3 UDP的特點

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

• 1、無連接: 知道對端的IP和端口號就直接進(jìn)行傳輸, 不需要建立連接;
• 2、不可靠: 沒有確認(rèn)機(jī)制, 沒有重傳機(jī)制; 如果因為網(wǎng)絡(luò)故障該段無法發(fā)到對方, UDP協(xié)議層也不會給應(yīng)用層 返回任何錯誤信息;
• 3、面向數(shù)據(jù)報: 不能夠靈活的控制讀寫數(shù)據(jù)的次數(shù)和數(shù)量;

應(yīng)用層交給UDP多長的報文, UDP原樣發(fā)送, 既不會拆分, 也不會合并，要么就收一個，要么就不收，沒有半個或者一個半的情況?。?/p>

舉例：用UDP傳輸100字節(jié)的數(shù)據(jù)，如果如果發(fā)送端調(diào)用一次sendto, 發(fā)送100個字節(jié), 那么接收端也必須調(diào)用對應(yīng)的一次recvfrom, 接收100個 字節(jié); 而不能循環(huán)調(diào)用10次recvfrom, 每次接收10個字節(jié);

2.4 UDP的緩沖區(qū)

1、UDP沒有真正意義上的發(fā)送緩沖區(qū)（因為他不需要！?。? 調(diào)用sendto會直接交給內(nèi)核, 由內(nèi)核將數(shù)據(jù)傳給網(wǎng)絡(luò)層協(xié)議進(jìn)行后 續(xù)的傳輸動作;

2、UDP具有接收緩沖區(qū). 但是這個接收緩沖區(qū)不能保證收到的UDP報的順序和發(fā)送UDP報的順序一致; 如果緩沖區(qū)滿了, 再到達(dá)的UDP數(shù)據(jù)就會被丟棄;

3、UDP的socket既能讀也能寫，也是全雙工

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

• NFS: 網(wǎng)絡(luò)文件系統(tǒng)
• TFTP: 簡單文件傳輸協(xié)議
• DHCP: 動態(tài)主機(jī)配置協(xié)議
• BOOTP: 啟動協(xié)議(用于無盤設(shè)備啟動)
• DNS: 域名解析協(xié)議
• 當(dāng)然, 也包括你自己寫UDP程序時自定義的應(yīng)用層協(xié)議;

2.6 UDP的結(jié)構(gòu)

因為Linux系統(tǒng)是用C語言寫的，所以UDP報頭的結(jié)構(gòu)其實涉及到結(jié)構(gòu)體的位段。

填上報頭數(shù)據(jù)，然后帶上有效載荷形成UDP報文，我們就可以發(fā)送了?。?/p>

UDP并不需要有發(fā)送緩沖區(qū)，是因為發(fā)送方準(zhǔn)備好了就可以直接發(fā)了，但是他需要有接收緩沖區(qū)，因為他把數(shù)據(jù)發(fā)給對方之后可能對方并不能立即去處理這個數(shù)據(jù)，所以在對方的接收緩沖區(qū)里可能會存在多個UDP報文，那么也就必然要求OS必須將多個UDP報文給管理起來??！所以需要先描述再組織！！

sk_buff就是服務(wù)端管理UDP報文的緩沖區(qū) 其中start指向緩沖區(qū)的頭部（報文的頭部）、end指向緩沖區(qū)的尾部、pos指向有效數(shù)據(jù)的尾部。然后再用鏈表形式去鏈接管理起來。此時我們OS將對UDP報文的管理轉(zhuǎn)化成了對sk_buff結(jié)構(gòu)體的管理

所以新的UDP數(shù)據(jù)就會連接在這個鏈表上，而UDP數(shù)據(jù)的丟棄就是把他對應(yīng)的結(jié)構(gòu)體給釋放了

三、TCP報頭

3.1 傳輸控制協(xié)議的理解

TCP全稱為 "傳輸控制協(xié)議(Transmission Control Protocol"). 人如其名, 要對數(shù)據(jù)的傳輸進(jìn)行一個詳細(xì)的控制;

我們平時調(diào)用的write、read、recv、send其實本質(zhì)上都是拷貝函數(shù)，要么將用戶緩沖區(qū)的內(nèi)容拷貝到發(fā)送緩沖區(qū)，要么將接受緩沖區(qū)的內(nèi)容拷貝到用戶緩沖區(qū)進(jìn)行處理，本質(zhì)來說就是不斷把數(shù)據(jù)放到網(wǎng)絡(luò)中，而具體數(shù)據(jù)要什么時候發(fā)送，發(fā)送多少，出錯了怎么辦，是由TCP協(xié)議自主決定的?。?！！

其實通過TCP協(xié)議控制網(wǎng)絡(luò)傳輸可靠性將數(shù)據(jù)從一臺主機(jī)的發(fā)送緩沖區(qū)安全地交付到另一臺主機(jī)的接收緩沖區(qū) ，要求數(shù)據(jù)原封不動的發(fā)送過去，所謂發(fā)送，本質(zhì)上是一種也是一種跨網(wǎng)絡(luò)的拷貝?。?/strong>