超詳細(xì)的Linux編程之UDP SOCKET全攻略（一文讓你徹底了解）
一、基本的udp socket編程
1. UDP編程框架
要使用UDP協(xié)議進(jìn)行程序開(kāi)發(fā)，我們必須首先得理解什么是什么是UDP？這里簡(jiǎn)單概括一下。
UDP（user datagram protocol）的中文叫用戶數(shù)據(jù)報(bào)協(xié)議，屬于傳輸層。UDP是面向非連接的協(xié)議，它不與對(duì)方建立連接，而是直接把我要發(fā)的數(shù)據(jù)報(bào)發(fā)給對(duì)方。所以UDP適用于一次傳輸數(shù)據(jù)量很少、對(duì)可靠性要求不高的或?qū)?shí)時(shí)性要求高的應(yīng)用場(chǎng)景。正因?yàn)閁DP無(wú)需建立類如三次握手的連接，而使得通信效率很高。
UDP的應(yīng)用非常廣泛，比如一些知名的應(yīng)用層協(xié)議（SNMP、DNS）都是基于UDP的，想一想，如果SNMP使用的是TCP的話，每次查詢請(qǐng)求都得進(jìn)行三次握手，這個(gè)花費(fèi)的時(shí)間估計(jì)是使用者不能忍受的，因?yàn)檫@會(huì)產(chǎn)生明顯的卡頓。所以UDP就是SNMP的一個(gè)很好的選擇了，要是查詢過(guò)程發(fā)生丟包錯(cuò)包也沒(méi)關(guān)系的，我們?cè)侔l(fā)起一個(gè)查詢就好了，因?yàn)閬G包的情況不多，這樣總比每次查詢都卡頓一下更容易讓人接受吧。
UDP通信的流程比較簡(jiǎn)單，因此要搭建這么一個(gè)常用的UDP通信框架也是比較簡(jiǎn)單的。以下是UDP的框架圖。
由以上框圖可以看出，客戶端要發(fā)起一次請(qǐng)求，僅僅需要兩個(gè)步驟（socket和sendto），而服務(wù)器端也僅僅需要三個(gè)步驟即可接收到來(lái)自客戶端的消息（socket、bind、recvfrom）。
2. UDP程序設(shè)計(jì)常用函數(shù)
對(duì)于該參數(shù)我們僅需熟記AF_INET和AF_INET6即可
小插曲：PF_XXX和AF_XXX
我們?cè)诳碙inux網(wǎng)絡(luò)編程相關(guān)代碼時(shí)會(huì)發(fā)現(xiàn)PF_XXX和AF_XXX會(huì)混著用，他們倆有什么區(qū)別呢？以下內(nèi)容摘自《UNP》。
AF_前綴表示地址族（Address Family），而PF_前綴表示協(xié)議族（Protocol Family）。歷史上曾有這樣的想法：?jiǎn)蝹€(gè)協(xié)議族可以支持多個(gè)地址族，PF_的值可以用來(lái)創(chuàng)建套接字，而AF_值用于套接字的地址結(jié)構(gòu)。但實(shí)際上，支持多個(gè)地址族的協(xié)議族從來(lái)就沒(méi)實(shí)現(xiàn)過(guò)，而頭文件<sys/socket.h>中為一給定的協(xié)議定義的PF_值總是與此協(xié)議的AF_值相同。
所以我在實(shí)際編程時(shí)還是偏向于使用AF_XXX。
參數(shù)type（只列出最重要的三個(gè)）:
SOCK_STREAM ? ? ? ? Provides sequenced, reliable, two-way, connection-based byte streams. ? //用于TCP
SOCK_DGRAM ? ? ? ? ?Supports datagrams (connectionless, unreliable messages ). //用于UDP
SOCK_RAW ? ? ? ? ? ? ?Provides raw network protocol access. ?//RAW類型，用于提供原始網(wǎng)絡(luò)訪問(wèn)
參數(shù)protocol：置0即可
返回值：成功：非負(fù)的文件描述符
失?。?1
第一個(gè)參數(shù)sockfd:正在監(jiān)聽(tīng)端口的套接口文件描述符，通過(guò)socket獲得
第二個(gè)參數(shù)buf：發(fā)送緩沖區(qū)，往往是使用者定義的數(shù)組，該數(shù)組裝有要發(fā)送的數(shù)據(jù)
第三個(gè)參數(shù)len:發(fā)送緩沖區(qū)的大小，單位是字節(jié)
第四個(gè)參數(shù)flags:填0即可
第五個(gè)參數(shù)dest_addr:指向接收數(shù)據(jù)的主機(jī)地址信息的結(jié)構(gòu)體，也就是該參數(shù)指定數(shù)據(jù)要發(fā)送到哪個(gè)主機(jī)哪個(gè)進(jìn)程
第六個(gè)參數(shù)addrlen:表示第五個(gè)參數(shù)所指向內(nèi)容的長(zhǎng)度
返回值：成功：返回發(fā)送成功的數(shù)據(jù)長(zhǎng)度
失?。?-1
第一個(gè)參數(shù)sockfd:正在監(jiān)聽(tīng)端口的套接口文件描述符，通過(guò)socket獲得
第二個(gè)參數(shù)buf：接收緩沖區(qū)，往往是使用者定義的數(shù)組，該數(shù)組裝有接收到的數(shù)據(jù)
第三個(gè)參數(shù)len:接收緩沖區(qū)的大小，單位是字節(jié)
第四個(gè)參數(shù)flags:填0即可
第五個(gè)參數(shù)src_addr:指向發(fā)送數(shù)據(jù)的主機(jī)地址信息的結(jié)構(gòu)體，也就是我們可以從該參數(shù)獲取到數(shù)據(jù)是誰(shuí)發(fā)出的
第六個(gè)參數(shù)addrlen:表示第五個(gè)參數(shù)所指向內(nèi)容的長(zhǎng)度
返回值：成功：返回接收成功的數(shù)據(jù)長(zhǎng)度
失?。?-1
第一個(gè)參數(shù)sockfd:正在監(jiān)聽(tīng)端口的套接口文件描述符，通過(guò)socket獲得
第二個(gè)參數(shù)my_addr:需要綁定的IP和端口
第三個(gè)參數(shù)addrlen：my_addr的結(jié)構(gòu)體的大小
返回值：成功：0
失?。?1
close函數(shù)比較簡(jiǎn)單，只要填入socket產(chǎn)生的fd即可。
3. 搭建UDP通信框架
server：
client：
以上的框架用于一臺(tái)主機(jī)不同端口的UDP通信，現(xiàn)象如下：
我們先建立server端，等待服務(wù)；然后我們建立client端請(qǐng)求服務(wù)。
server端：
client端：
自己主機(jī)跟自己通信不是很爽，我們想跟其他主機(jī)通信怎么搞？很簡(jiǎn)單，上面client的代碼的第49行的注釋打開(kāi)，并注釋掉下面那行，在宏定義里填入自己想通信的serverip就可以了?，F(xiàn)象如下：
server端：
client端：
這樣我們就實(shí)現(xiàn)了主機(jī)172.0.5.183和172.0.5.182之間的網(wǎng)絡(luò)通信。
UDP通用框架搭建完成，我們可以利用該框架跟指定主機(jī)進(jìn)行通信了。
如果想學(xué)習(xí)UDP的基礎(chǔ)知識(shí)，以上的知識(shí)就足夠了；如果想繼續(xù)深入學(xué)習(xí)一下UDP SOCKET一些高級(jí)知識(shí)（奇技淫巧），可以花點(diǎn)時(shí)間往下看。
二、高級(jí)udp socket編程
1. udp的connect函數(shù)
什么？UDP也有conenct？connect不是用于TCP編程的嗎？
是的，UDP網(wǎng)絡(luò)編程中的確有connect函數(shù)，但它僅僅用于表示確定了另一方的地址，并沒(méi)有其他含義。
有了以上認(rèn)識(shí)后，我們可以知道UDP套接字有以下區(qū)分：
未連接的UDP套接字
已連接的UDP套接字
對(duì)于未連接的套接字，也就是我們常用的的UDP套接字，我們使用的是sendto/recvfrom進(jìn)行信息的收發(fā)，目標(biāo)主機(jī)的IP和端口是在調(diào)用sendto/recvfrom時(shí)確定的；
在一個(gè)未連接的UDP套接字上給兩個(gè)數(shù)據(jù)報(bào)調(diào)用sendto函數(shù)內(nèi)核將執(zhí)行以下六個(gè)步驟：
連接套接字
輸出第一個(gè)數(shù)據(jù)報(bào)
斷開(kāi)套接字連接
連接套接字
輸出第二個(gè)數(shù)據(jù)報(bào)
斷開(kāi)套接字連接
對(duì)于已連接的UDP套接字，必須先經(jīng)過(guò)connect來(lái)向目標(biāo)服務(wù)器進(jìn)行指定，然后調(diào)用read/write進(jìn)行信息的收發(fā)，目標(biāo)主機(jī)的IP和端口是在connect時(shí)確定的，也就是說(shuō)，一旦conenct成功，我們就只能對(duì)該主機(jī)進(jìn)行收發(fā)信息了。
已連接的UDP套接字給兩個(gè)數(shù)據(jù)報(bào)調(diào)用write函數(shù)內(nèi)核將執(zhí)行以下三個(gè)步驟：
連接套接字
輸出第一個(gè)數(shù)據(jù)報(bào)
輸出第二個(gè)數(shù)據(jù)報(bào)
由此可以知道，當(dāng)應(yīng)用進(jìn)程知道給同一個(gè)目的地址的端口號(hào)發(fā)送多個(gè)數(shù)據(jù)報(bào)時(shí)，顯示套接字效率更高。
下面給出帶connect函數(shù)的UDP通信框架
具體框架代碼不再給出了，因?yàn)楦厦娌粠onnect的代碼大同小異，僅僅多出一個(gè)connect函數(shù)處理而已，下面給出處理conenct()的基本步驟。
2. udp報(bào)文丟失問(wèn)題
因?yàn)閁DP自身的特點(diǎn)，決定了UDP會(huì)相對(duì)于TCP存在一些難以解決的問(wèn)題。第一個(gè)就是UDP報(bào)文缺失問(wèn)題。 在UDP服務(wù)器客戶端的例子中，如果客戶端發(fā)送的數(shù)據(jù)丟失，服務(wù)器會(huì)一直等待，直到客戶端的合法數(shù)據(jù)過(guò)來(lái)。如果服務(wù)器的響應(yīng)在中間被路由丟棄，則客戶端會(huì)一直阻塞，直到服務(wù)器數(shù)據(jù)過(guò)來(lái)。
防止這樣的永久阻塞的一般方法是給客戶的recvfrom調(diào)用設(shè)置一個(gè)超時(shí)，大概有這么兩種方法：
使用信號(hào)SIGALRM為recvfrom設(shè)置超時(shí)。首先我們?yōu)镾IGALARM建立一個(gè)信號(hào)處理函數(shù)，并在每次調(diào)用前通過(guò)alarm設(shè)置一個(gè)5秒的超時(shí)。如果recvfrom被我們的信號(hào)處理函數(shù)中斷了，那就超時(shí)重發(fā)信息；若正常讀到數(shù)據(jù)了，就關(guān)閉報(bào)警時(shí)鐘并繼續(xù)進(jìn)行下去。
使用select為recvfrom設(shè)置超時(shí) 設(shè)置select函數(shù)的第五個(gè)參數(shù)即可。
3. udp報(bào)文亂序問(wèn)題
所謂亂序就是發(fā)送數(shù)據(jù)的順序和接收數(shù)據(jù)的順序不一致，例如發(fā)送數(shù)據(jù)的順序?yàn)锳、B、C，但是接收到的數(shù)據(jù)順序卻為：A、C、B。產(chǎn)生這個(gè)問(wèn)題的原因在于，每個(gè)數(shù)據(jù)報(bào)走的路由并不一樣，有的路由順暢，有的卻擁塞，這導(dǎo)致每個(gè)數(shù)據(jù)報(bào)到達(dá)目的地的順序就不一樣了。UDP協(xié)議并不保證數(shù)據(jù)報(bào)的按序接收。
解決這個(gè)問(wèn)題的方法就是發(fā)送端在發(fā)送數(shù)據(jù)時(shí)加入數(shù)據(jù)報(bào)序號(hào)，這樣接收端接收到報(bào)文后可以先檢查數(shù)據(jù)報(bào)的序號(hào)，并將它們按序排隊(duì)，形成有序的數(shù)據(jù)報(bào)。
4. udp流量控制問(wèn)題
總所周知，TCP有滑動(dòng)窗口進(jìn)行流量控制和擁塞控制，反觀UDP因?yàn)槠涮攸c(diǎn)無(wú)法做到。UDP接收數(shù)據(jù)時(shí)直接將數(shù)據(jù)放進(jìn)緩沖區(qū)內(nèi)，如果用戶沒(méi)有及時(shí)將緩沖區(qū)的內(nèi)容復(fù)制出來(lái)放好的話，后面的到來(lái)的數(shù)據(jù)會(huì)接著往緩沖區(qū)放，當(dāng)緩沖區(qū)滿時(shí)，后來(lái)的到的數(shù)據(jù)就會(huì)覆蓋先來(lái)的數(shù)據(jù)而造成數(shù)據(jù)丟失（因?yàn)閮?nèi)核使用的UDP緩沖區(qū)是環(huán)形緩沖區(qū)）。因此，一旦發(fā)送方在某個(gè)時(shí)間點(diǎn)爆發(fā)性發(fā)送消息，接收方將因?yàn)閬?lái)不及接收而發(fā)生信息丟失。
解決方法一般采用增大UDP緩沖區(qū)，使得接收方的接收能力大于發(fā)送方的發(fā)送能力。
int n = 220 * 1024; //220kB
setsocketopt(sockfd, SOL_SOCKET, SO_RCVBUF, &n, sizeof(n));
這樣我們就把接收方的接收隊(duì)列擴(kuò)大了，從而盡量避免丟失數(shù)據(jù)的發(fā)生。
