TCP中send函數(shù)研究是怎樣的，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
tcp協(xié)議本身是可靠的,并不等于應用程序用tcp發(fā)送數(shù)據(jù)就一定是可靠的.不管是否阻塞,send發(fā)送的大小,并不代表對端recv到多少的數(shù)據(jù).
在阻塞模式下, send函數(shù)的過程是將應用程序請求發(fā)送的數(shù)據(jù)拷貝到發(fā)送緩存中發(fā)送并得到確認后再返回.但由于發(fā)送緩存的存在,表現(xiàn)為:如果發(fā)送緩存大小比請求發(fā)送的大小要大,那么send函數(shù)立即返回,同時向網(wǎng)絡中發(fā)送數(shù)據(jù);否則,send向網(wǎng)絡發(fā)送緩存中不能容納的那部分數(shù)據(jù),并等待對端確認后再返回(接收端只要將數(shù)據(jù)收到接收緩存中,就會確認,并不一定要等待應用程序調(diào)用recv);
在非阻塞模式下,send函數(shù)的過程僅僅是將數(shù)據(jù)拷貝到協(xié)議棧的緩存區(qū)而已,如果緩存區(qū)可用空間不夠,則盡能力的拷貝,返回成功拷貝的大小;如緩存區(qū)可用空間為0,則返回-1,同時設置errno為EAGAIN.
linux下可用sysctl -a | grep net.ipv4.tcp_wmem查看系統(tǒng)默認的發(fā)送緩存大小:
net.ipv4.tcp_wmem = 4096 16384 81920
這有三個值,第一個值是socket的發(fā)送緩存區(qū)分配的最少字節(jié)數(shù),第二個值是默認值(該值會被net.core.wmem_default覆蓋),緩存區(qū)在系統(tǒng)負載不重的情況下可以增長到這個值,第三個值是發(fā)送緩存區(qū)空間的較大字節(jié)數(shù)(該值會被net.core.wmem_max覆蓋).
根據(jù)實際測試,如果手工更改了net.ipv4.tcp_wmem的值,則會按更改的值來運行,否則在默認情況下,協(xié)議棧通常是按net.core.wmem_default和net.core.wmem_max的值來分配內(nèi)存的.
應用程序應該根據(jù)應用的特性在程序中更改發(fā)送緩存大小:
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);
需要注意的是,雖然將發(fā)送緩存設置成了10k,但實際上,協(xié)議棧會將其擴大1倍,設為20k.
-------------------實例分析---------------
在實際應用中,如果發(fā)送端是非阻塞發(fā)送,由于網(wǎng)絡的阻塞或者接收端處理過慢,通常出現(xiàn)的情況是,發(fā)送應用程序看起來發(fā)送了10k的數(shù)據(jù),但是只發(fā)送了2k到對端緩存中,還有8k在本機緩存中(未發(fā)送或者未得到接收端的確認).那么此時,接收應用程序能夠收到的數(shù)據(jù)為2k.假如接收應用程序調(diào)用recv函數(shù)獲取了1k的數(shù)據(jù)在處理,在這個瞬間,發(fā)生了以下情況之一,雙方表現(xiàn)為:
A. 發(fā)送應用程序認為send完了10k數(shù)據(jù),關閉了socket:
發(fā)送主機作為tcp的主動關閉者,連接將處于FIN_WAIT1的半關閉狀態(tài)(等待對方的ack),并且,發(fā)送緩存中的8k數(shù)據(jù)并不清除,依然會發(fā)送給對端.如果接收應用程序依然在recv,那么它會收到余下的8k數(shù)據(jù)(這個前題是,接收端會在發(fā)送端FIN_WAIT1狀態(tài)超時前收到余下的8k數(shù)據(jù).), 然后得到一個對端socket被關閉的消息(recv返回0).這時,應該進行關閉.
B. 發(fā)送應用程序再次調(diào)用send發(fā)送8k的數(shù)據(jù):
假如發(fā)送緩存的空間為20k,那么發(fā)送緩存可用空間為20-8=12k,大于請求發(fā)送的8k,所以send函數(shù)將數(shù)據(jù)做拷貝后,并立即返回8192;
假如發(fā)送緩存的空間為12k,那么此時發(fā)送緩存可用空間還有12-8=4k,send()會返回4096,應用程序發(fā)現(xiàn)返回的值小于請求發(fā)送的大小值后,可以認為緩存區(qū)已滿,這時必須阻塞(或通過select等待下一次socket可寫的信號),如果應用程序不理會,立即再次調(diào)用send,那么會得到-1的值, 在linux下表現(xiàn)為errno=EAGAIN.
C. 接收應用程序在處理完1k數(shù)據(jù)后,關閉了socket:
接收主機作為主動關閉者,連接將處于FIN_WAIT1的半關閉狀態(tài)(等待對方的ack).然后,發(fā)送應用程序會收到socket可讀的信號(通常是 select調(diào)用返回socket可讀),但在讀取時會發(fā)現(xiàn)recv函數(shù)返回0,這時應該調(diào)用close函數(shù)來關閉socket(發(fā)送給對方ack);
如果發(fā)送應用程序沒有處理這個可讀的信號,而是在send,那么這要分兩種情況來考慮,假如是在發(fā)送端收到RST標志之后調(diào)用send,send將返回-1,同時errno設為ECONNRESET表示對端網(wǎng)絡已斷開,但是,也有說法是進程會收到SIGPIPE信號,該信號的默認響應動作是退出進程,如果忽略該信號,那么send是返回-1,errno為EPIPE(未證實);如果是在發(fā)送端收到RST標志之前,則send像往常一樣工作;
以上說的是非阻塞的send情況,假如send是阻塞調(diào)用,并且正好處于阻塞時(例如一次性發(fā)送一個巨大的buf,超出了發(fā)送緩存),對端socket關閉,那么send將返回成功發(fā)送的字節(jié)數(shù),如果再次調(diào)用send,那么會同上一樣.
D. 交換機或路由器的網(wǎng)絡斷開:
接收應用程序在處理完已收到的1k數(shù)據(jù)后,會繼續(xù)從緩存區(qū)讀取余下的1k數(shù)據(jù),然后就表現(xiàn)為無數(shù)據(jù)可讀的現(xiàn)象,這種情況需要應用程序來處理超時.一般做法是設定一個select等待的較大時間,如果超出這個時間依然沒有數(shù)據(jù)可讀,則認為socket已不可用.
發(fā)送應用程序會不斷的將余下的數(shù)據(jù)發(fā)送到網(wǎng)絡上,但始終得不到確認,所以緩存區(qū)的可用空間持續(xù)為0,這種情況也需要應用程序來處理.
如果不由應用程序來處理這種情況超時的情況,也可以通過tcp協(xié)議本身來處理,具體可以查看sysctl項中的:
net.ipv4.tcp_keepalive_intvl
net.ipv4.tcp_keepalive_probes
net.ipv4.tcp_keepalive_time
關于TCP中send函數(shù)研究是怎樣的問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關知識。
重慶分公司
重慶分公司
