我发现 Linux 文档写错了,你发现了吗?

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

大家好,我是小林。

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

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

首先,先给大家介绍下 netstat 命令。netstat 命令是查看网络状态很常见的 Linux 命令。比如,如果我们想查看系统中的进程监听了哪些 TCP 端口,则可以使用下面这个命令 netstat -napt:

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

疑惑提出读者提出的疑惑:

我先给大家翻译一下,man 手册(https://man7.org/linux/man-pages/man8/netstat.8.html)是怎么说的:

  • 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 函数的实现,这个函数的代码也不多,就几十行,所以很容易就分析出来了。

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

责任编辑:武晓燕 来源: 小林coding
相关推荐

2024-05-20 08:25:55

2022-03-01 21:05:39

TCP网络协议

2022-04-18 07:42:31

配置机制Spring

2020-09-01 10:32:52

iOS微信新功能

2020-04-14 15:30:00

微信群管理朋友圈

2014-08-21 14:49:32

MIUI 6

2018-07-12 14:03:33

区块链新零售电子商务

2023-06-24 23:11:07

2024-11-05 09:47:08

VGG网络模型

2022-03-18 11:50:06

AI模型GPT-3

2021-08-19 15:05:08

微信功能技巧

2020-04-01 08:40:44

Vue.jsweb开发

2024-06-03 11:43:55

2021-08-10 22:52:49

微信功能工具

2021-02-23 09:06:00

MVCC版本并发

2023-06-20 08:01:09

RoseDB存储数据

2020-05-18 08:42:23

CSS背景图像前端开发

2021-07-10 07:40:27

Excel数据分析大数据

2022-11-30 09:18:51

JavaMyBatisMQ
点赞
收藏

51CTO技术栈公众号