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