我发现 Linux 文档写错了

Posted 小林coding

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了我发现 Linux 文档写错了相关的知识,希望对你有一定的参考价值。

作者:小林coding
图解计算机基础网站:https://xiaolincoding.com

大家好,我是小林。

周末的时候,有位读者疑惑为什么 Linux man 手册中关于 netstat 命令中的 tcp listen 状态下的 Recv-Q 和 Send-Q 这两个信息的描述跟我的图解网络写的不一样?

我看了源码后,确认了这个 man 手册写的不对。没想到 Linux 的 man 手册也会出错。

首先,先给大家介绍下 netstat 命令。netstat 命令是查看网络状态很常见的 Linux 命令。

比如,如果我们想查看系统中的进程监听了哪些 TCP 端口,则可以使用下面这个命令:

接下来,小林带大家分析,为什么我说 man 手册写错了 netstat 命令中 Recv-Q 和 Send-Q 的描述?

疑惑提出

读者提出的疑惑:


我先给大家翻译一下,man 手册是怎么说的:

  • Recv-Q:如果 TCP 连接状态处于 Established,Recv-Q 的数值表示接收缓冲区中还没拷贝到应用层的数据大小;如果 TCP 连接状态处于 Listen 状态,Recv-Q 的数值表示当前 syn 半连接队列的大小(自内核版本 2.6.18 起)
  • Send-Q:如果 TCP 连接状态处于 Established,Send-Q的数值表示发送缓冲区中已发送但未被确认的数据大小;如果 TCP 连接状态处于 Listen 状态,Send-Q 的数值表示 syn 半连接队列的容量(自内核版本 2.6.18 起)。

而我通过查阅内核 2.6.18 版本的源码,得到的结论如下:

  • Recv-Q:如果 TCP 连接状态处于 Established,Recv-Q 的数值表示接收缓冲区中还没拷贝到应用层的数据大小;如果 TCP 连接状态处于 Listen 状态,Recv-Q 的数值表示当前 syn 半连接队列的大小 当前全连接队列的大小;
  • Send-Q:如果 TCP 连接状态处于 Established,Send-Q的数值表示发送缓冲区中已发送但未被确认的数据大小;如果 TCP 连接状态处于 Listen 状态,Send-Q 的数值表示 syn 半连接队列的容量

上面被我划掉的部分,就是我与 man 手册差异的地方。

什么是 TCP 半连接队列和全链接队列?

在 TCP 三次握手的时候,Linux 内核会维护两个队列,分别是:

  • 半连接队列,也称 SYN 队列;
  • 全连接队列,也称 accept 队列;

服务端收到客户端发起的 SYN 请求后,内核会把该连接存储到半连接队列,并向客户端响应 SYN+ACK,接着客户端会返回 ACK,服务端收到第三次握手的 ACK 后,内核会把连接从半连接队列移除,然后创建新的完全的连接,并将其添加到全连接队列,等待进程调用 accept 函数时把连接取出来。


如果你想知道 TCP 半连接和全连接溢出会发生什么?可以看看这篇文章:TCP 半连接队列和全连接队列满了会发生什么?又该如何应对?

源码分析

netstat 工具在获取 TCP 连接的信息的时候,实际上是读取了 /proc/net/tcp 文件里的数据,而这个文件的数据是由内核由 net/ipv4/tcp_ipv4.c 文件中的 tcp4_seq_show() 函数打印的。

所以,我们直接看 tcp4_seq_show() 函数是根据什么信息打印出 Recv-Q 和 Send-Q 的数据。

有一个网站可以在线看 Linux 内核代码:https://elixir.bootlin.com/,每个内核版本的代码都有,平常我都是在这里看。

这次,我们选择内核版本为 2.6.18 查看 tcp4_seq_show() 函数的实现,如下:

static int tcp4_seq_show(struct seq_file *seq, void *v)

	.....

	switch (st->state) 
	case TCP_SEQ_STATE_LISTENING:
	case TCP_SEQ_STATE_ESTABLISHED:
		get_tcp4_sock(v, tmpbuf, st->num);
		break;
	.......
	
	...
	return 0;

我们只分析 tcp 连接状态为 ESTABLISHED 和 LISTENING 时打印的信息,所以接下来看 get_tcp4_sock 函数。

get_tcp4_sock 函数中,打印信息的代码如下:

我在图中标红了两行代码,这两行代码分别是 Recv-Q 和 Send-Q 的数据。

我单独把这两行代码抽了出来:

// Send-Q 打印的数据
tp->write_seq - tp->snd_una,

//Recv-Q 打印的数据
(sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog : (tp->rcv_nxt - tp->copied_seq),

可以看到, 不管 TCP 连接状态是什么, Send-Q 都是发送缓冲区中已发送但未被确认的数据大小。

然后针对 Recv-Q ,在 TCP 连接状态为 LISTEN 时,打印的是 sk_ack_backlog 的值。

那 sk_ack_backlog 的值代表什么意思呢?

下面这个是判断全连接队列是否溢出的函数:
可以得知,sk_ack_backlog 其实是当前全连接队列的大小,也就是经历三次握手后等待被应用层 accpet() 的连接的数量。

所以,从上面的源码分析过,得到的结论如下:

  • netstat 命令中的 Recv-Q:如果 TCP 连接状态处于 Established,Recv-Q 的数值表示接收缓冲区中还没拷贝到应用层的数据大小;如果 TCP 连接状态处于 Listen 状态,Recv-Q 的数值表示当前全连接队列的大小
  • netstat 命令中的 Send-Q:表示发送缓冲区中已发送但未被确认的数据大小(不管 TCP 是 Listen 状态还是 Established 状态都表示这个意思);

好了,至此就分析完了。

最后

看到这,大家肯定会说:小林你太强了吧,为什么对 Linux 内核源码那么熟,这都能分析出来

其实,我并没有熟读过 Linux 内核源码啦,其实只要大家有好奇心,其实你也能分析出来。

我也是通过网上的资料,一点一点分析出来的,并不是直接就在内核源码里查,不然那真是大海捞针。

我是这样一步一步查资料分析的:

  • 先网上查下 netstat 源码,看是根据什么信息打印 Send-Q 和 Recv-Q,然后看到网上有人说是读 /proc/net/tcp 这个文件;
  • 接着,就网上查 /proc/net/tcp 这个文件是怎么打印的,然后看到网上有人说是由 net/ipv4/tcp_ipv4.c 文件中的 tcp4_seq_show() 函数打印的;
  • 最后,再自己去看 tcp4_seq_show 函数的实现,这个函数的代码也不多,就几十行,所以很容易就分析出来了。

你看,其实我也是通过「搜索」一步一步分析出来的,其实并没有什么难度。

只是我比较细节一点。

创作打卡挑战赛 赢取流量/现金/CSDN周边激励大奖

以上是关于我发现 Linux 文档写错了的主要内容,如果未能解决你的问题,请参考以下文章

~/.bashrc文件写错, 导致Linux全部命令丢失

LINUX安装文件的postrm写错了怎么办?

mybatis使用xml实现发生的异常之一return null from a method with a primitive return type (int)

anylogic软件在运行的时候老是说模型启动时发生错误

没想到吧!关于Dubbo的『消费端线程池模型』官网也写错了

容器类型