理解了实现再谈网络性能-202202更新

理 解 了 实 现 再 谈

⽹ 络 性 能

开 发 内 功 修 炼 之 ⽹ 络 篇

张 彦 ⻜

最后更新时间：2022-02-01

添加⽹络包发送过程分析

⼤家好，我是张彦⻜，⼤家都喜欢称呼我⻜哥。我于 2010 年 7 ⽉从⻄北⼤学计算机学院硕⼠

毕业，之后⼀直混迹于帝都。刚毕业时因为户⼝的问题去了⼀家⼴播电视软件⻰头公司，但

按捺不住对互联⽹的向往，在 2011 年就跳槽去了腾讯。后来随着腾讯和搜狗的战略联姻，被

⽼板连⼈带业务⼀并注⼊到搜狗。现在在搜狗任专家开发⼯程师，负责 PC 浏览器、搜狗⼿

机助⼿等产品的后端技术。

我在这⼗多年的⼯作中有不少的技术思考，因此创办了「开发内功修炼」技术号，分别在微

信公众号和知乎两个平台发布。这本电⼦书是我之前所发布的⽹络相关⽂章的⼀个总结，在

⽹络⽂章的基础上理顺了整本电⼦书的架构，也添加了⼀些⽹络开发优化建议、实际问题分

析等章节。

深⼊问⼀点性能相关的问题都没有好的思路，技术能⼒并没有随着⼯作年限的增⻓⽽增⻓。

也确实为这种类型的同学的前途感到担忧。另外⼀类同学都是除了业务的开发以外，还会额

外抽时间注重⾃⼰的技术积累，成⻓的就⽐较好，对于他们我觉得别说 35 岁了，45 岁也仍

然会是团队的中流砥柱。

对于第⼀类同学来讲，技术成⻓过慢也不完全是他们⾃⼰的原因。现在国内的开发环境中都

存在着⼀个普遍的⽭盾，那就是排期过满的需求开发和需要⼤把时间去磨练技术的⽭盾。 排

期过满导致开发同学平时绝⼤部分的时间都是在处理各种各样的业务逻辑和 bug 。很多同学

的时间全部被这种需求吃掉了，导致没有想法或精⼒去提升⾃⼰的底层技术能⼒，导致技术

level 并没有随着⼯作年限⽽同⽐增⻓。

︎︎︎︎ udp_rcv ︎平时⼤家都是⽤各种语⾔进⾏业务逻辑的代码编写，⽆论你⽤的是 PHP、Go、还

思考总结分享给⼤家，帮助这些同学提升⾃⼰的技术⽊桶短板。

在本书中，我会从应⽤层的问题出发，深⼊到 Linux 中进⾏分析。帮助⼤家提升对底层的理

解，加强你的技术深度，也为你的中年焦虑症送上⼀剂良药。

相信很多同学也都保持着在互联⽹上进⾏学习的习惯，我但我觉得⽬前⼤多数的技术类⽂章

还是太偏向于各种花拳绣腿了。

⾼性能的 PHP 异步⽹络通信引擎 swoole 的作者韩天峰说过，很多程序员职业规划的⽂章，

上来就是 Linux、PHP、MySQL、Nginx、Redis、Memcache、jQuery 这些，然后就直接

上⼿搭环境、做项⽬，中级就是学习各种 PHP 框架和类库，⾼级阶段就是 MySQL 优化、

进⾏的，⼀个 Cache Line 是 64 字节。56 字节可以⼀次请求搞定，⽽原来的 72 字节则需要

两次。另外就是 L1/L2/L3 的命中率也会提升很多，这个对性能的帮助更⼤。

内功它不帮助你掌握最新的开发语⾔，也不教会你时髦的框架，也不会带你⾛进⽕热的⼈⼯

智能。但是我相信它是你成为⼤⽜的必经之路。我简单列⼀下锻炼内功的好处：

1）内功⽅⾯的技术⽣命周期⻓。Linux 操作系统 1991 年就发布了，现在还是发展的如⽇中

天。对于作者 Linus，我觉得他也有年龄焦虑。但他可能焦虑的找不到接班⼈。反观应⽤层的

⼀些技术尤其是很多的框架，⽣命周期能超过⼗年我就已经觉得他很⽜叉了。如果你的精⼒

全部押宝在这些⽣命周期很短的技术上，你说能不焦虑吗！所以我觉得戒掉浮躁，踏踏实实

练好内功打好是你对抗中年焦虑的解药之⼀。

2）内功深厚的⼈理解新技术⾮常快。拿我⾃⼰来举两个⼩例⼦吧。我其实没怎么去翻过

界顶级的设计和实现⽅案。平时我们在⾃⼰的业务开发中，在编码之前也需要先进⾏设计。

⽐如我在刚⼯作的时候负责的⼀个数据采集任务调度，其中的实现就是部分参考了操作系统

进程调度⽅案。再⽐如如何在管理海量的连接的情况下仍然能⾼效发现某⼀条连接上的 IO 事

件，epoll 内部的红⿊树 + 队列的组合可以提供给你⼀个很好的参考。这种例⼦还有很多很

多，总之如果能将 Linux 的某些优秀实现，搬到你的系统中会极⼤提升你的项⽬的实现⽔平。

时髦的东⻄终究会过时，但扎实的内功能⼒将会伴随你的⼀⽣。只有具备了深厚的内功底

蕴，你才能在你的发展道路上⾛的更稳、⾛的更远。

其实我在刚⼯作前⼏年对计算机⽹络的理解也是不深的。

紧处理哈。后来他帮我们打开了 tcp_tw_reuse 和 tcp_tw_recycle，先把问题处理掉了。

但是我的思考却并没有停⽌，⼀条 TIME_WAIT 到底会有哪些开销。端⼝占⽤导致新连接⽆法

建⽴？还是会过多消耗机器上的内存？ 3 万条 TIME_WAIT 究竟该算是 warning 还是 error？

2）另外⼀次是当时公司还没有建⽴ redis 平台之前，我们业务⾃⼰维护了⼀组 redis server

。为了节约握⼿开销，我们的业务进程对 redis 开启了⻓连接。这样⼀个 redis 实例上最终就

出现了 6000 条的连接。虽然每条连接上⼤部分时间都是空闲的，但是我却在思考⼀条空闲的

连接究竟会有哪些开销？这 6000 条连接会不会把服务器搞坏？ 当然最终观测的结果是没啥

问题，但是对于细节原理我仍然吃的不是很准。

3）另外⼀次也是我们业务要把短连接优化成⻓连接。但是这次涉及到了要访问公司的 Mysql

平台。当时我们公司的 Mysql 需要为每⼀个 ip 申请⼀个并发数。因为我们当时使⽤的是