前言:
今天姐妹们对“socket缓冲区满了阻塞怎么办”大概比较讲究,同学们都需要分析一些“socket缓冲区满了阻塞怎么办”的相关文章。那么小编同时在网络上汇集了一些关于“socket缓冲区满了阻塞怎么办””的相关知识,希望大家能喜欢,兄弟们快快来学习一下吧!其实最开始我们已经总结了两者的不同 socket在阻塞和非阻塞下send / receive的区别 - socket在阻塞和非阻塞下send / receive的区别,但还不够底层,下面让我们深入底层来聊聊两者的区别:
首先需要强调的是send()本质上并不是把数据丢到网络上进行发送。而是把应用层的发送缓冲区的数据拷贝到内核缓冲区(网卡缓冲区),至于什么时候数据会从网卡缓冲区真正的发送到网络中要根据TCP/IP协议栈的行为来确定。同时这里会设计到一个NAGEL算法和TCP_NODELAY的socket选项,他会控制发送包的大小,在必要时候进行组包进行发送。
recv函数本质上也不是从网络上来收取数据,而只是把内核缓冲区的数据拷贝到应用程序的缓冲区中,当然拷贝完成以后还会多做一步 - 把内核缓冲区中的数据进行移除。可以用下面的图来描述这个过程:
通过上图我们可以知道,不同的程序进行网络通信试,发送方会把内核缓冲区的数据通过网络传输给接收方的内核缓冲区。在应用程序A和B建立了TCP连接之后,假设应用程序A不断调用send()函数,这样数据会不断拷贝到对应的内核缓冲区中,如果B那一端不调用recv()函数,那么B的内核缓冲区被填满之后,A的内核缓冲区也会被填满。此时如果A继续调用send()函数,会产生什么样的结果?具体的结果取决于此时socket是否是阻塞模式,以下是结论:
当socket是阻塞模式的时候,继续调用send/recv函数会导致程序阻塞在send/recv调用处当socket是非阻塞模式的时候,继续调用send/recv函数,send/recv函数不会阻塞程序执行流,而是会立即返回错误,我们会得到一个错误码,在Linux上是EWOULDBLOCK或者EAGAIN(错误码值相同),Windows上会显示WSAEWOULDBLOCK
即这里有一个概念,如果接收端的内核缓冲区不去接收,或者速度比发送端来的慢的话,此时两端的内核缓冲区都会被填满,导致发送端的send()被阻塞。这里的内核缓冲区就是TCP窗口,也就是说在socket阻塞模式下,send()函数会在TCP窗口太小的情况下阻塞当前程序的执行. 从实验结果看到最终卡在了
同时我们发送的helloworld其实是10个字节,那计算内核缓冲区的方式也就出来了
10 * 265092 / 2(发送端和接收端的内核缓冲区最个数) = 1.3MB
紧接着,为了更进一步的了解这个问题,我们利用tcpdump来抓包来查看这个win的窗口的变化,主要关注的就是从port 3000发送给我们的包的里面的win大小的变化
可以看到最终,接收端的窗口为0,表示不再能接收。但是当我们继续实验,发现即使为0的情况下,我们client的send()仍然还是继续发送了一下,这就表示,即使对端不能接收,实际我们本端还有自己的内核缓冲区没有塞满,最终程序真正block的时候,就是两端内核缓冲区都被塞满的时候,这也证实了send()实际是拷贝到了内核缓冲区,而不是发送到网络上。
同时,可以重点关注前面3个包,他表示初始窗口大小,其实也是在做三次握手
由于TCP流量控制和拥塞控制,server的TCP窗口大小短期内会增加,然后随着接收缓冲区数据积压越来越多,TCP窗口慢慢变小,最终变为0。同时需要注意的是当tcpdump显示窗口为0的时候,client仍然可以继续发送一段时间,实际上此时的数据已经不会发送出去,而是逐渐填满本端的内核缓冲区,这也验证了send()实际上就是往内核缓冲区进行数据拷贝。
同样,如果我们此时让Client在连接完服务器之后,立马调用recv()函数,此时根据是否为阻塞模式,表现的差异如下:
阻塞 - 会一直卡在那里,如果我们上gdb然后ctrl-c进行查看堆栈,发现一直阻塞在recv()里非阻塞 - 会立即返回-1即EWOULDBLOCK
标签: #socket缓冲区满了阻塞怎么办