Linux下面socket編程的非阻塞TCP研究

Linux下面socket編程的非阻塞TCP研究（轉）

引用連結：http://xufish.blogbus.com/logs/40537344.html

tcp協議本身是可靠的,並不等於應用程式用tcp發送資料就一定是可靠的.不管是否阻塞,send發送的大小,並不代表對端recv到多少的資料.

在阻塞模式下,
send函數的過程是將應用程式請求發送的資料拷貝到發送緩衝中發送並得到確認後再返回.但由於發送緩衝的存在,表現為:如果發送緩衝大小比請求發送的大
小要大,那麼send函數立即返回,同時向網路中發送資料;否則,send向網路發送緩衝中不能容納的那部分資料,並等待對端確認後再返回(接收端只要將
資料收到接收緩衝中,就會確認,並不一定要等待應用程式調用recv);

在非阻塞模式下,send函數的過程僅僅是將資料拷貝到協議棧的緩衝區而已,如果緩衝區可用空間不夠,則盡能力的拷貝,返回成功拷貝的大小;如緩衝區可用空間為0,則返回-1,同時設定errno為EAGAIN.


linux下可用sysctl -a | grep net.ipv4.tcp_wmem查看系統預設的發送緩衝大小:
net.ipv4.tcp_wmem = 4096 16384 81920
這
有三個值,第一個值是socket的發送緩衝區分配的最少位元組數,第二個值是預設值(該值會被net.core.wmem_default覆蓋),緩衝區
在系統負載不重的情況下可以增長到這個值,第三個值是發送緩衝區空間的最大位元組數(該值會被net.core.wmem_max覆蓋).
根據實際測試,如果手工更改了net.ipv4.tcp_wmem的值,則會按更改的值來運行,否則在預設情況下,協議棧通常是按net.core.wmem_default和net.core.wmem_max的值來分配記憶體的.

應用程式應該根據應用的特性在程式中更改發送緩衝大小:

socklen_t sendbuflen = 0; socklen_t len = sizeof(sendbuflen); getsockopt(clientSocket, SOL_SOCKET, SO_SNDBUF, (void*)&sendbuflen, &len); printf("default,sendbuf:%d\n", sendbuflen); sendbuflen = 10240; setsockopt(clientSocket, SOL_SOCKET, SO_SNDBUF, (void*)&sendbuflen, len); getsockopt(clientSocket, SOL_SOCKET, SO_SNDBUF, (void*)&sendbuflen, &len); printf("now,sendbuf:%d\n", sendbuflen);

需要注意的是,雖然將發送緩衝設定成了10k,但實際上,協議棧會將其擴大1倍,設為20k.


-------------------執行個體分析----------------------

在
實際應用中,如果發送端是非阻塞發送,由於網路的阻塞或者接收端處理過慢,通常出現的情況是,發送應用程式看起來發送了10k的資料,但是只發送了2k到
對端緩衝中,還有8k在本機緩衝中(未發送或者未得到接收端的確認).那麼此時,接收應用程式能夠收到的資料為2k.假如接收應用程式調用recv函數獲
取了1k的資料在處理,在這個瞬間,發生了以下情況之一,雙方表現為:

A. 發送應用程式認為send完了10k資料,關閉了socket:
發
送主機作為tcp的主動關閉者,串連將處於FIN_WAIT1的半關閉狀態(等待對方的ack),並且,發送緩衝中的8k資料並不清除,依然會發送給對
端.如果接收應用程式依然在recv,那麼它會收到餘下的8k資料(這個前題是,接收端會在發送端FIN_WAIT1狀態逾時前收到餘下的8k資料.),
然後得到一個對端socket被關閉的訊息(recv返回0).這時,應該進行關閉.

B. 發送應用程式再次調用send發送8k的資料:
假 如發送緩衝的空間為20k,那麼發送緩衝可用空間為20-8=12k,大於請求發送的8k,所以send函數將資料做拷貝後,並立即返回8192;

假
如發
送緩衝的空間為12k,那麼此時發送緩衝可用空間還有12-8=4k,send()會返回4096,應用程式發現返回的值小於請求發送的大小值後,可以認
為緩衝區已滿,這時必須阻塞(或通過select等待下一次socket可寫的訊號),如果應用程式不理會,立即再次調用send,那麼會得到-1的值,
在linux下表現為errno=EAGAIN.

C. 接收應用程式在處理完1k資料後,關閉了socket:
接
收主機作為主動關閉者,串連將處於FIN_WAIT1的半關閉狀態(等待對方的ack).然後,發送應用程式會收到socket可讀的訊號(通常是
select調用返回socket可讀),但在讀取時會發現recv函數返回0,這時應該調用close函數來關閉socket(發送給對方ack);

如 果發送應用程式沒有處理這個可讀的訊號,而是在send,那麼這要分兩種情況來考慮,假如是在發送端收到RST標誌之後調用send,send將返回-1,同時errno設為ECONNRESET表示對端網路已斷開,但是,也有說法是進程會收到SIGPIPE訊號,該訊號的預設響應動作是退出進程,如果忽略該訊號,那麼send是返回-1,errno為EPIPE(未證實);如果是在發送端收到RST標誌之前,則send像往常一樣工作;

以上說的是非阻塞的send情況,假如send是阻塞調用,並且正好處於阻塞時(例如一次性發送一個巨大的buf,超出了發送緩衝),對端socket關閉,那麼send將返回成功發送的位元組數,如果再次調用send,那麼會同上一樣.

D. 交換器或路由器的網路斷開:
接收應用程式在處理完已收到的1k資料後,會繼續從緩衝區讀取餘下的1k資料,然後就表現為無資料可讀的現象,這種情況需要應用程式來處理逾時.一般做法是設定一個select等待的最大時間,如果超出這個時間依然沒有資料可讀,則認為socket已不可用.

發送應用程式會不斷的將餘下的資料發送到網路上,但始終得不到確認,所以緩衝區的可用空間持續為0,這種情況也需要應用程式來處理.

如果不由應用程式來處理這種情況逾時的情況,也可以通過tcp協議本身來處理,具體可以查看sysctl項中的:
net.ipv4.tcp_keepalive_intvl
net.ipv4.tcp_keepalive_probes
net.ipv4.tcp_keepalive_time