這是根據自己的筆記整理的,如有錯誤,歡迎指出來. 　　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的數據:…