1. 程式人生 > >Socket的Send,Recv的長度問題

Socket的Send,Recv的長度問題

一個包沒有固定長度,乙太網限制在46-1500位元組,1500就是乙太網的MTU,超過這個量,TCP會為IP資料報設定偏移量進行分片傳輸,現在一般可允許應用層設定8k(NTFS系統)的緩衝區,8k的資料由底層分片,而應用層看來只是一次傳送。
        windows的緩衝區經驗值是4k。
        Socket本身分為兩種,流(TCP)和資料報(UDP),你的問題針對這兩種不同使用而結論不一樣。甚至還和你是用阻塞、還是非阻塞Socket來程式設計有關。
        1、通訊長度,這個是你自己決定的,沒有系統強迫你要發多大的包,實際應該根據需求和網路狀況來決定。對於TCP,這個長度可以大點,但要知道,Socket內部預設的收發緩衝區大小大概是8K,你可以用SetSockOpt來改變。但對於UDP,就不要太大,一般在1024至10K。注意一點,你無論發多大的包,IP層和鏈路層都會把你的包進行分片傳送,一般區域網就是1500左右,廣域網就只有幾十位元組。分片後的包將經過不同的路由到達接收方,對於UDP而言,要是其中一個分片丟失,那麼接收方的IP層將把整個傳送包丟棄,這就形成丟包。顯然,要是一個UDP發包佷大,它被分片後,鏈路層丟失分片的機率就佷大,你這個UDP包,就佷容易丟失,但是太小又影響效率。最好可以配置這個值,以根據不同的環境來調整到最佳狀態。

send()函式返回了實際傳送的長度,在網路不斷的情況下,它絕不會返回(傳送失敗的)錯誤,最多就是返回0。對於TCP你可以寫一個迴圈傳送。當send函式返回SOCKET_ERROR時,才標誌著有錯誤。但對於UDP,你不要寫迴圈傳送,否則將給你的接收帶來極大的麻煩。所以UDP需要用SetSockOpt來改變Socket內部Buffer的大小,以能容納你的發包。明確一點,TCP作為流,發包是不會整包到達的,而是源源不斷的到,那接收方就必須組包。而UDP作為訊息或資料報,它一定是整包到達接收方。
        2、關於接收,一般的發包都有包邊界,首要的就是你這個包的長度要讓接收方知道,於是就有個包頭資訊,對於TCP,接收方先收這個包頭資訊,然後再收包資料。一次收齊整個包也可以,可要對結果是否收齊進行驗證。這也就完成了組包過程。UDP,那你只能整包接收了。要是你提供的接收Buffer過小,TCP將返回實際接收的長度,餘下的還可以收,而UDP不同的是,餘下的資料被丟棄並返回WSAEMSGSIZE錯誤。注意TCP,要是你提供的Buffer佷大,那麼可能收到的就是多個發包,你必須分離它們,還有就是當Buffer太小,而一次收不完Socket內部的資料,那麼Socket接收事件(OnReceive),可能不會再觸發,使用事件方式進行接收時,密切注意這點。這些特性就是體現了流和資料包的區別。

        補充一點,接收BuffSize >= 傳送BuffSize >= 實際傳送Size,對於內外部的Buffer都適用,上面講的主要是Socket內部的Buffer大小關係。
        3、TCP是有多少就收多少,如果沒有當然阻塞Socket的recv就會等,直到有資料,非阻塞Socket不好等,而是返回WSAEWOULDBLOCK。UDP,如果沒有資料,阻塞Socket就會等,非阻塞Socket也返回WSAEWOULDBLOCK。如果有資料,它是會等整個發包到齊,並接收到整個發包,才返回。