send函数阻塞
以下內容轉載時請注明出處。（原文鏈接：http://blog.chinaunix.net/uid-8489474-id-2031025.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的值來分配內存的.
應用程序應該根據應用的特性在程序中更改發送緩存大小:
需要注意的是,雖然將發送緩存設置成了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);
如果應用程序通過select()函數僅檢測該socket句柄是否可寫,它會返回應用層可寫.
假設發送應用程序收到可讀或可寫的信號后,繼續send,send將返回-1,同時errno設為ECONNRESET表示對端網絡已斷開. 但是,當發送應用程序沒有使用select機制,則可能會收到SIGPIPE信號,這取決于send時是發生成RST標志收到之前還是之后.如果是之后,則會產生SIGPIPE信號,該信號的默認響應動作是退出進程,如果忽略該信號,那么send是返回-1,errno為EPIPE; 如果是在發送端收到RST標志之前,則send像往常一樣工作;
以上說的是非阻塞的send情況,假如send是阻塞調用,并且正好處于阻塞時(例如一次性發送一個巨大的buf,超出了發送緩存),對端socket關閉,那么send將返回成功發送的字節數,如果再次調用send,會收到ECONNRESET的錯誤.
D. 交換機或路由器的網絡斷開:
接收應用程序在處理完已收到的1k數據后,會繼續從緩存區讀取余下的1k數據,然后就表現為無數據可讀的現象,這種情況需要應用程序來處理超時.一般做法是設定一個select等待的最大時間,如果超出這個時間依然沒有數據可讀,則認為socket已不可用.
發送應用程序會不斷的將余下的數據發送到網絡上,但始終得不到確認,所以緩存區的可用空間持續為0,這種情況也需要應用程序來處理.
如果不由應用程序來處理這種情況超時的情況,也可以通過tcp協議本身來處理,具體可以查看sysctl項中的:
net.ipv4.tcp_keepalive_intvl
net.ipv4.tcp_keepalive_probes
net.ipv4.tcp_keepalive_time
所以,要想編寫優秀的socket程序也是很不容易的.特別是在為應用做優化時,很多工作都非常的煩瑣.
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; |
需要注意的是,雖然將發送緩存設置成了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);
如果應用程序通過select()函數僅檢測該socket句柄是否可寫,它會返回應用層可寫.
假設發送應用程序收到可讀或可寫的信號后,繼續send,send將返回-1,同時errno設為ECONNRESET表示對端網絡已斷開. 但是,當發送應用程序沒有使用select機制,則可能會收到SIGPIPE信號,這取決于send時是發生成RST標志收到之前還是之后.如果是之后,則會產生SIGPIPE信號,該信號的默認響應動作是退出進程,如果忽略該信號,那么send是返回-1,errno為EPIPE; 如果是在發送端收到RST標志之前,則send像往常一樣工作;
以上說的是非阻塞的send情況,假如send是阻塞調用,并且正好處于阻塞時(例如一次性發送一個巨大的buf,超出了發送緩存),對端socket關閉,那么send將返回成功發送的字節數,如果再次調用send,會收到ECONNRESET的錯誤.
D. 交換機或路由器的網絡斷開:
接收應用程序在處理完已收到的1k數據后,會繼續從緩存區讀取余下的1k數據,然后就表現為無數據可讀的現象,這種情況需要應用程序來處理超時.一般做法是設定一個select等待的最大時間,如果超出這個時間依然沒有數據可讀,則認為socket已不可用.
發送應用程序會不斷的將余下的數據發送到網絡上,但始終得不到確認,所以緩存區的可用空間持續為0,這種情況也需要應用程序來處理.
如果不由應用程序來處理這種情況超時的情況,也可以通過tcp協議本身來處理,具體可以查看sysctl項中的:
net.ipv4.tcp_keepalive_intvl
net.ipv4.tcp_keepalive_probes
net.ipv4.tcp_keepalive_time
所以,要想編寫優秀的socket程序也是很不容易的.特別是在為應用做優化時,很多工作都非常的煩瑣.
總結
- 上一篇： protobuf流的反解析Message
- 下一篇： 关于WSAEWOULDBLOCK和WSA