Linux内核技术实战课
邵亚方
前蘑菇街技术专家,Linux Kernel活跃贡献者
新⼈⾸单¥9.9
2805 人已学习
课程目录
已更新 17 讲 / 共 23 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 如何让Linux内核更好地服务应用程序?
免费
Page Cache管理问题 (5讲)
01 基础篇 | 如何用数据观测Page Cache?
02 基础篇 | Page Cache是怎样产生和释放的?
03 案例篇 | 如何处理Page Cache难以回收产生的load飙高问题?
04 案例篇 | 如何处理Page Cache容易回收引起的业务性能问题?
免费
05 分析篇 | 如何判断问题是否由Page Cache产生的?
内存泄漏问题 (5讲)
06 基础篇 | 进程的哪些内存类型容易引起内存泄漏?
07 案例篇 | 如何预防内存泄漏导致的系统假死?
08 案例篇 | Shmem:进程没有消耗内存,内存哪去了?
09 分析篇 | 如何对内核内存泄漏做些基础的分析?
10 分析篇 | 内存泄漏时,我们该如何一步步找到根因?
TCP重传问题 (6讲)
11 基础篇 | TCP连接的建立和断开受哪些系统配置影响?
12 基础篇 | TCP收发包过程会受哪些配置项影响?
13 案例篇 | TCP拥塞控制是如何导致业务性能抖动的?
14 案例篇 | TCP端到端时延变大,怎样判断是哪里出现了问题?
15 分析篇 | 如何高效地分析TCP重传问题?
16 套路篇 | 如何分析常见的TCP问题?
Linux内核技术实战课
15
15
1.0x
00:00/00:00
登录|注册

12 基础篇 | TCP收发包过程会受哪些配置项影响?

邵亚方 2020-09-15
你好,我是邵亚方。我们这节课来讲一下,TCP 数据在传输过程中会受到哪些因素干扰。
TCP 收包和发包的过程也是容易引起问题的地方。收包是指数据到达网卡再到被应用程序开始处理的过程。发包则是应用程序调用发包函数到数据包从网卡发出的过程。你应该对 TCP 收包和发包过程中容易引发的一些问题不会陌生,比如说:
网卡中断太多,占用太多 CPU,导致业务频繁被打断;
应用程序调用 write() 或者 send() 发包,怎么会发不出去呢;
数据包明明已经被网卡收到了,可是应用程序为什么没收到呢;
我想要调整缓冲区的大小,可是为什么不生效呢;
是不是内核缓冲区满了从而引起丢包,我该怎么观察呢;
想要解决这些问题呢,你就需要去了解 TCP 的收发包过程容易受到哪些因素的影响。这个过程中涉及到很多的配置项,很多问题都是这些配置项跟业务场景不匹配导致的。
我们先来看下数据包的发送过程,这个过程会受到哪些配置项的影响呢?

TCP 数据包的发送过程会受什么影响?

TCP数据包发送过程
上图就是一个简略的 TCP 数据包的发送过程。应用程序调用 write(2) 或者 send(2) 系列系统调用开始往外发包时,这些系统调用会把数据包从用户缓冲区拷贝到 TCP 发送缓冲区(TCP Send Buffer),这个 TCP 发送缓冲区的大小是受限制的,这里也是容易引起问题的地方。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux内核技术实战课》,如需阅读全部文章,
请订阅文章所属专栏新⼈⾸单¥9.9
立即订阅
登录 后留言

精选留言(3)

  • 我来也
    终于到TCP篇了.

    看了文中的`TCP数据包发送过程`图,有几个疑问:
    1. 如果用tcpdump抓包,它是在哪一层抓的包呢?(IP Layer / Link Layer)
       最近遇到的问题,就是调用write函数有返回值.但是tcpdump抓包来看,并没有迹象.
       只知道在此期间有地方把包给丢了,并不知道具体是哪一层丢的.后来发现是内核把包丢了.
    2. `TCP Send Buffer`默认是动态调整的.
       这个是按需分配的意思么?如果我调整了内核参数,对之前建立的连接产生影响么?
    3. 如果`TCP Send Buffer`满了,调用`write`时是阻塞还是返回错误码呢?(是不是跟TCP的阻塞/非阻塞模式有关?)

    -------------------
    最近在CentOS 7.6上遇到了一个TCP内核方面的问题.
    它的内核版本太低了,还是linux-3.10.0-957.21.3.el7.

    具体的分析和解决过程参考了这篇博文:
    [TCP SACK 补丁导致的发送队列报文积压](https://runsisi.com/2019-12-19/tcp-sack-hang)

    作者回复: 1. 这个tcpdump的原理,我们在后面的课程里会讲到,是在link layer来抓包的。
    2. 对的,会按需调整,调整后会影响之前的连接,因为在检查缓冲区大小时会用到这些全局变量。
    3. 对的 跟是否设置了阻塞模式有关。


    这个blog分享得不错,赞!

    2020-09-15
    1
    2
  • 王崧霁
    流控应该在上游发送端控制,接收端有个开关net.core.devbudget也是控制发端行为
    2020-09-19
    1
  • feihui
    根据老师文中对 qdisc 长度的设置,这个队列应该是网卡独享的设备,此外使用 bbr 需要更改改队列行为,猜测一部分是跟发送优先级有关,而这在接收端没必要
    2020-09-20
收起评论
3
返回
顶部