在待機狀態下有多個UDP數據報套接字是否有意義？內核丟棄或排隊「同步」數據包嗎？

Question

我正在編寫Android上的網絡應用程序。

我在考慮擁有一個UDP端口和數據報套接字，它接收發送給它的所有數據報，然後爲這些消息設置不同的處理隊列。

我懷疑我是否應該有第二個或第三個UDP套接字待機。一些消息會非常短（100bytes左右），但其他消息將不得不傳輸文件。

我擔心的是，如果Android內核忙於處理較大的消息，Android內核會丟棄這些小消息嗎？

更新 「後者函數調用sock_queue_rcv_skb（）（在sock.h），哪個隊列的插座的接收緩衝區的UDP數據包。如果沒有更多的空間留在緩衝區，數據包將被丟棄。過濾也是通過這個函數來完成的，它調用sk_filter（）就像TCP一樣，最後調用data_ready（），UDP包接收完成。

Answer 1

讓我們得到一些基本的先降：

每個插座具有接收和發送緩衝區。當網絡硬件發信號通知新數據包和到達接收緩衝區已滿時，數據包將被丟棄。緩衝區大小通過SO_RCVBUF和SO_SNDBUF插座選項進行控制，請參見setsockopt(3)。操作系統設置了一些默認設置（並且有/etc/sysctl.conf文件）。這是一個BSD系統上：

~$ sysctl -a|grep space 
net.inet.tcp.recvspace=16384 
net.inet.tcp.sendspace=16384 
net.inet.udp.recvspace=41600 
net.inet.udp.sendspace=9216 

TCP和UDP之間的區別在於，前者以數據排序和丟棄的數據包的重傳，再加上流量控制的護理（慢讀者減慢快作家），而後者則沒有。

所以是的，使用UDP傳輸文件不是最好的，，但可行，選項。人們必須重新創建TCP的一部分，並權衡重新發明對TCP的開銷。再一次，普遍的看法是，UDP最適合於可以容忍某些分組重排序/丟失的應用程序（例如音頻/視頻流）。

然後有一個錯誤的觀點，即每個套接字都需要一個單獨的線程來發送/接收數據，這遠非事實。許多優秀的高性能網絡應用程序都是在沒有線程的情況下編寫的，但使用了非阻塞套接字和一些輪詢機制（請參閱select(2)，poll(2),epoll(7)）。

爲了這個問題本身：

是，如果應用程序是太忙，無法保持足夠的可用空間，插座內核可能會丟棄數據包接收緩衝區。但是由於每個套接字都有自己的特性，控制和數據流的分離將會有所幫助。就個人而言，我會去做一個簡單的TCP服務器設置 - 偵聽端口，接受每個客戶端的連接，在TCP流上實現一個有意義的協議。我同意玩UDP和低級別協議狀態機非常有趣，但已經完成了，幾十年的研究進入了調整TCP性能。最重要的是你的應用程序的可靠性（第一）和性能（第二）。

希望這會有所幫助。

Answer 2

UDP是傳輸文件的壞主意，因爲您無法保證數據包的接收順序，或者它們是否會被接收。如果您打算在此基礎上構建一個容錯傳輸層，那麼您應該只使用TCP/IP，因爲這正是它的功能。

UDP不緩衝或排隊收到的數據包。如果收到數據包並且您正在等待數據，您將收到數據包。如果在程序忙於其他處理時接收到數據包，則根本無法獲取數據包。因此，如果您收到兩個「同步數據包」（呃，兩個非常靠近），如果您正在對每個數據包進行任何重要處理，您很有可能會錯過其中的一個。

我不明白如何打開額外的端口將有助於你。如果您正忙於處理來自端口1的數據包，那麼除非每個端口都在專用線程上運行，否則您將錯過任何其他正在監視的端口上的數據包。將數據包快速複製到您自己的緩衝區並將其傳遞到另一個線程來處理它，您的情況會好得多，因此您的偵聽器線程可以儘快恢復監聽。

Answer 3

TCP的流量控制將幫助您減少丟棄的數據包。其容錯能力並確保數據包將按順序到達。