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

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

1.1 端口號(hào)的理解

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

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

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

1.2 端口號(hào)范圍的劃分

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

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

1.3 認(rèn)識(shí)知名端口號(hào)

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

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

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

cat /etc/services

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

1.4 一個(gè)進(jìn)程可以bind多個(gè)端口號(hào)

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

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

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

1.5 相關(guān)命令

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

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

常用選項(xiàng)：

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

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

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

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

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

二、UDP報(bào)頭

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

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

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

3、認(rèn)識(shí)報(bào)頭的組成

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

2.2 UDP協(xié)議端格式

問題1：報(bào)頭和有效載荷是如何分離的呢？？

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

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

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

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

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

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

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

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

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

2.3 UDP的特點(diǎn)

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

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

應(yīng)用層交給UDP多長(zhǎng)的報(bào)文, UDP原樣發(fā)送, 既不會(huì)拆分, 也不會(huì)合并，要么就收一個(gè)，要么就不收，沒有半個(gè)或者一個(gè)半的情況??！

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

2.4 UDP的緩沖區(qū)

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

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

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

2.5 基于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é)議;

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

因?yàn)長(zhǎng)inux系統(tǒng)是用C語言寫的，所以UDP報(bào)頭的結(jié)構(gòu)其實(shí)涉及到結(jié)構(gòu)體的位段。

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

UDP并不需要有發(fā)送緩沖區(qū)，是因?yàn)榘l(fā)送方準(zhǔn)備好了就可以直接發(fā)了，但是他需要有接收緩沖區(qū)，因?yàn)樗褦?shù)據(jù)發(fā)給對(duì)方之后可能對(duì)方并不能立即去處理這個(gè)數(shù)據(jù)，所以在對(duì)方的接收緩沖區(qū)里可能會(huì)存在多個(gè)UDP報(bào)文，那么也就必然要求OS必須將多個(gè)UDP報(bào)文給管理起來?。∷孕枰让枋鲈俳M織！！

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

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

三、TCP報(bào)頭

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

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

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

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