為了解決這題，可以具體看看下面這個討論。
盡管UDP協議遠沒TCP協議那么龐大、復雜，但是，要想將UDP描述清楚，用好UDP卻要比TCP難不少，於是文章從下筆寫，到最終寫成，斷斷續續拖了好幾個月。
說起網絡socket，大家自然會想到TCP，用的最多也是TCP，UDP在大家的印象中是作為TCP的補充而存在，是無連接、不可靠、無序、無流量控制的傳輸層協議。UDP的無連接性已經深入人心，協議上的無連接性指的是一個UDP的Endpoint1(IP,PORT)，可以向多個UDP的Endpointi(IP,PORT)發送數據包，也可以接收來自多個UDP的Endpointi(IP,PORT)的數據包。
實現上，需要考慮這樣一個特殊情況：UDP Client 在Endpoint_C1只往UDP Server的Endpoint_S1發送數據包，並且只接收來自Endpoint_S1的數據包，把UDP通信雙方都固定下來，這樣不就形成一條單向的虛”連接”了么？
1. UDP的”連接性”估計很多同學認為UDP的連接性只是將UDP通信雙方都固定下來了，一對一只是多對多的一個特例而已，這樣UDP連接不連接到無所謂了。果真如此嗎？其實不然，UDP的連接性可以帶來以下兩個好處：
1.1 高效率、低消耗我們知道Linux系統有用戶空間(用戶態)和內核空間(內核態)之分，對於x86處理器以及大多數其它處理器，用戶空間和內核空間之前的切換是比較耗時(涉及到上下文的保存和恢復，一般3種情況下會發生用戶態到內核態的切換：發生系統調用時、產生異常時、中斷時)。
那么對於一個高性能的服務應該減少頻繁不必要的上下文切換，如果切換無法避免，那么盡量減少用戶空間和內核空間的數據交換，減少數據拷貝。熟悉socket編程的同學對下面幾個系統調用應該比較熟悉了，由於UDP是基於用戶數據報的，只要數據包准備好就應該調用一次send或sendto進行發包，當然包的大小完全由應用層邏輯決定的。
細看兩個系統調用的參數便知道，sendto比send的參數多2個，這就意味着每次系統調用都要多拷貝一些數據到內核空間。同時，參數到內核空間后，內核還需要初始化一些臨時的數據結構來存儲這些參數值(主要是對端Endpoint_S的地址信息)，在數據包發出去后，內核還需要在合適的時候釋放這些臨時的數據結構。進行UDP通信的時候，如果首先調用connect綁定對端Endpoint_S的后，那么就可以直接調用send來給對端Endpoint_S發送UDP數據包了。
用戶在connect之后，內核會永久維護一個存儲對端Endpoint_S的地址信息的數據結構，內核不再需要分配/刪除這些數據結構，只需要查找就可以了，從而減少了數據的拷貝。這樣對於connect方而言，該UDP通信在內核已經維護這一個“連接”了，那么在通信的整個過程中，內核都能隨時追蹤到這個“連接”。
1.2 錯誤提示
相信大家寫UDP Socket程序的時候，有時候在第一次調用sendto給一個unconnected UDP socket發送UDP數據包時，接下來調用recvfrom()或繼續調sendto的時候會返回一個ECONNREFUSED錯誤。對於一個無連接的UDP是不會返回這個錯誤的，之所以會返回這個錯誤，是因為你明確調用了connect去連接遠端的Endpoint_S了。那么這個錯誤是怎么產生的呢？沒有調用connect的UDP Socket為什么無法返回這個錯誤呢？
點擊全文鏈接（體驗更佳哦~）：從UDP的”連接性”說起
騰訊優測(http://utest.qq.com)是專業的移動雲測試平台，提供【兼容性自動化測試】【雲手機】【漏洞檢測】等多維度測試服務。
