tcp服务端一直sleep，客户端发送数据问题总结

怼烎@ 2022-04-03 07:20 283阅读 0赞

在之前参加腾讯面试的时候，被面试官问到了一个问题：“一个tcp服务端和一个tcp客户端，客户端和服务端建立连接后，服务端一直sleep，然后客户端一直发送数据会是什么现象”。

回答这个问题前我们先想一想tcp的特征和tcp发送数据的大体过程：首先，tcp是有链接的可靠传输协议，所谓可靠也就是说保证客户端发送的数据服务端都能够收到，并且是按序收到。那么对于上面的问题就不可能存在数据的丢弃。那么客户端一直发送数据越来越多怎么办？下面我们分析一下tcp的传输过程。

![20181220225613541][]

**图1**

如图1所示当发送数据时：

**(1) **数据首先由应用程序缓冲区复制到发送端的套接字发送缓冲区（位于内核），注意这个过程是用类似write功能的函数完成的。有的人通常看到write成功就以为数据发送到了对端主机，其实这是错误的，**write成功仅仅表示**数据成功的由应用进程缓冲区复制到了套接字发送缓冲区。

**(2)** 然后内核协议栈将套接字发送缓冲区中的数据发送到对端主机，注意这个过程不受应用程序控制，而是发送端内核协议栈完成，其中包括使用滑动窗口、用赛控制等功能。

**(3)** 数据到达接收端主机的套接字接收缓冲区，注意这个接收过程也不受应用程序控制，而是由接收端内核协议栈完成，其中包括发送ack确认等。

**(4) **数据由套接字接收缓冲区复制到接收端应用程序缓冲区，注意这个过程是由类似read等函数来完成。

**1.1 阻塞方式的情况**

知道了这个过程，我们在看一下在默认情况下（套接字为阻塞方式）write等函数的工作方式：输出操作，包括write、writev、send、sendto和sendmsg共5个函数。对于一个TCP套接字，内核从应用进程的缓冲区到套接字的发送缓冲区复制数据。对于阻塞的套接字，如果其发送缓冲区中没有空间，进程将被投入睡眠，直到有空间为止。——UNPv1

这样我们就可以推测出了结果：阻塞方式下，如果服务端一直sleep不接收数据，而客户端一直write，也就是只能执行上述过程中的前三步，这样最终结果肯定是接收端的套接字接收缓冲区和发送端套接字发送缓冲区都被填满，这样write就无法继续将数据从应用程序复制到发送端的套接字发送缓冲区了，从而使进程进入睡眠。

验证例子如下，客户端代码：

![20181220225613559][]

客户端每次write成功一次，将计数器count加1，同时输出本次write成功的字节数。count保存客户端write成功的次数。

服务端代码：

![20181220225613634][]

首先编译运行服务端，然后启动客户端，运行结果如图2所示。

![20181220225613653][]

**图2**

可以看到客户端write成功377次后就陷入了阻塞，注意这个时候不能说明发送端的套接字发送缓冲区一点是满的，只能说明套接字发送缓冲区的可用空间小于write请求写的自己数——1024。

**补充**：当服务端sleep到1000后，会关闭当前连接，此时客户端处于阻塞中的write会返回错误，效果如图3。

![20181220225613670][]

图3

**1.2 非阻塞方式的情况**

下面看一下非阻塞套接字情况下，write的工作方式：对于一个非阻塞的TCP套接字，如果发送缓冲区中根本没有空间，输出函数将立即返回一个EWOULDBLOCK错误。如果发送缓冲区中有一些空间，返回值将是内核能够复制到该缓冲区的字节数。这个字节数也成为“不足计数”。——UNPv1

这样就可以知道非阻塞情况下服务端一直sleep，客户端一直write数据的效果了：开始客户端write成功，随着客户端write，接收端的套接字接收缓冲区和发送端的套接字发送缓冲区会被填满。当发送端的套接字发送缓冲区的可用空间小于write请求写的字节数时，write立即返回-1，并将errno置为EWOULDBLOCK。

验证例子代码如下。

l 服务端同阻塞情况（略）。

**客户端（非阻塞模式）：**

![20181220225613691][]

首先编译运行服务端，然后启动客户端，运行结果如下图4所示。

![20181220225613708][]

**图4**

可以看到客户端成功write 185次后就发生套接字发送缓冲区空间不足，从而返回EWOULDBLOCK错误。我们注意到每次write同样的字节数(1024)阻塞模式下能write成功377次，为什么非阻塞情况下要少呢？

这是因为阻塞模式下一直write到接收端的套接字接收缓冲区和发送端的套接字发送缓冲区都满的情况才会阻塞。而非阻塞模式情况下有可能是发送端发送过程的第二步较慢，造成发送端的套接字发送缓冲区很快写满。而接收端的套接字接收缓冲区还没有满，这样write就会仅仅因为发送端的套接字发送缓冲区满而返回错误(准确的说的套接字发送缓冲区的可用空间小于write请求写的字节数)。

对比一下377正好是185的二倍左右，所以可以推测由于发送过程第二步的延迟，很可能发送端的套接字发送缓冲区已经满了，而接收端的套接字接收缓冲区还是空的。

**1.3 UDP情况补充**

对于UDP套接字不存在真正的发送缓冲区。内核只是复制应用进程数据并把它沿协议栈向下传送，渐次冠以UDP首部和IP首部。因此对于一个阻塞的UDP套接字（默认设置），输出函数调用将不会因为与TCP套接字一样的原因而阻塞，不过有可能会因为其他原因而阻塞。——UNPv1

***扩展阅读***

[Java网络编程之TCP协议][Java_TCP]

[关于Http协议，你必须要知道的][Http]

[Java网络编程之UDP协议][Java_UDP]

来源：http://blog.chinaunix.net/uid-28541347-id-4730278.html

> ### 微信公众号：javafirst ###
> 
> ### 扫码关注免费获取更多资源  ###
> 
> ![70][]

[20181220225613541]: /images/20220403/1d29b36f393d4674b5b05263e0912954.png
[20181220225613559]: /images/20220403/fce788e764b3429abbc7c5d098a17b0c.png
[20181220225613634]: /images/20220403/23a147521c614b7397fd30880d778aae.png
[20181220225613653]: /images/20220403/3ccafdd7e5da4eee8e90212d60e89027.png
[20181220225613670]: /images/20220403/e49f4f0c5925464693a2d8a87ff0e9a5.png
[20181220225613691]: /images/20220403/aad5674294b24ba2a64c79ffe9621a44.png
[20181220225613708]: /images/20220403/add8518439f0461cb8a3d333e8b938ec.png
[Java_TCP]: http://mp.weixin.qq.com/s?__biz=MzU5NTAzNjM0Mw==&mid=2247485394&idx=4&sn=1007805293d77932f8275f49dba4fcda&chksm=fe79560ac90edf1c2db837360bcef241567ff7d3bd7be3aa2736fc54d07efd205d77e6321aa4&scene=21#wechat_redirect
[Http]: http://mp.weixin.qq.com/s?__biz=MzU5NTAzNjM0Mw==&mid=2247485934&idx=1&sn=e0c1406e79b2aefede8131a225d19124&chksm=fe795836c90ed120027519259944222fef6f1f9791c3b702c7406c6cd282aeb59f10bb166673&scene=21#wechat_redirect
[Java_UDP]: http://mp.weixin.qq.com/s?__biz=MzU5NTAzNjM0Mw==&mid=2247485379&idx=4&sn=cc04114bf6382f643cfda1d347001378&chksm=fe79561bc90edf0df5e264801e19a417584f1fa315db55e04e2189ce4d5ba68230c869021555&scene=21#wechat_redirect
[70]: /images/20220403/b7820cf4dd1b4e3f8a1ddca413ca30ee.png