聊网络性能这件事，我踩过的坑大多不是出在"带宽不够"上，而是出在对延迟和丢包的理解有偏差。前阵子帮一个做实时协作工具的朋友看问题，他坚信自己租的带宽太小，非要从 10M 升到 100M，我让他先测一组数据：单向时延 68ms、抖动 12ms、丢包 0.3%。带宽翻十倍之后，时延一点没变，丢包还在。最后定位到的是出口链路的排队问题，跟带宽数字毫无关系。
这次经历让我把当年在计算机网络课上学的分组延时、丢包和吞吐量重新翻出来认真过了一遍。这四个词听起来像概念题，实际上是排查一切网络问题的坐标系。这篇笔记就是围绕Internet 与 ISP 的结构，以及分组延时、丢失和吞吐量这条主线展开的：先把网络长什么样画清楚，再把一个分组从发出到抵达要经历的四段延时拆开算清楚，最后落到实际测量和排查上。刚学计网的同学可以当复习提纲，天天调接口、看监控的开发者可以当排查手册，准备面试的也能当速查表。
下面这些东西，我尽量按"先讲清为什么，再讲怎么算，最后讲怎么用"的顺序来，中间穿插我自己踩过的坑。
1. Internet 与 ISP：先把"网络的形状"画出来
1.1 从一个具体问题出发：一个数据包到底走过哪些路
很多人学完这一章，脑子里还是只有"网络"两个字，具体连成什么样完全没概念。我建议你先问自己一个特别具体的问题：在自己家里点开一个网页，那个请求报文从网卡出去之后，到它被服务器处理之前，中间经过了哪些"实体"？
顺着这条线捋，你会依次遇到：家里的无线路由器、运营商放在小区或楼道里的接入设备、区域性的汇聚机房、城市之间的骨干链路、对端服务器所在数据中心的边界路由器。每一跳都不是抽象概念，都是你能说出型号、能查到位置的真实设备。理解 Internet 的结构，本质上就是理解"这些设备是谁的、按什么规则连在一起、谁给谁付钱"。
教材里给 Internet 的定义通常有两个角度，我觉得这两个角度必须都记住，否则后面看拓扑图会懵。一个是"组成角度"：Internet 是数以亿计的计算设备（主机、端系统）通过通信链路和分组交换机连起来的网络。另一个是"服务角度"：Internet 是为分布式应用提供基础设施的平台。前者回答"它由什么组成"，后者回答"它为什么存在"。你做性能优化的时候用的是前一个视角，做业务架构设计的时候用的是后一个视角。
提示：端系统（end system）这个词别被名字骗了，它指的是跑应用的设备——手机、笔记本、服务器、摄像头都算。路由器、交换机这类只负责转发的设备，才叫中间系统。这个区分在后面算延时的时候很重要，因为延时是按"链路 + 交换机"逐段累加的。
1.2 ISP 的四层结构与"网络的网络"是怎么长出来的
Internet 不是一次性设计出来的，它是长出来的，这一点决定了它的结构特征。教材里讲"网络的网络"的演进过程，从最初所有主机直接连一个骨干网，到后来把接入网和骨干网拆开，再到现在形成多层 ISP 的层级结构。我把它压缩成一句话：端系统通过接入 ISP 接入，接入 ISP 向上购买区域 ISP 的连通性，区域 ISP 再向上购买骨干 ISP 的连通性，同级 ISP 之间通过 IXP（互联网交换点）或对等链路直接互联。
这个层级结构有几个必须理解的点，它们直接决定了实际网络问题的形态。
第一层是接入 ISP。家里办宽带、公司拉专线，对接的就是这一层。它们的特征是离用户近、链路带宽相对小、覆盖范围以城市或片区为单位。你家宽带跑不满，问题很可能就出在这一层，而不是骨干网。
第二层是区域 ISP。一个省或大区范围内的汇聚网络，接入 ISP 把流量交给它，它再往上送。这一层平时你感知不到，但跨市访问变慢时，往往就是这里的链路拥塞。
第三层是骨干 ISP。全国甚至跨国的大管道，特点是带宽极高、跳数少、覆盖广，但价格也高。很多看起来"绕远路"的路由，背后其实是商业结算关系，不是技术选不出来更短的路径。
最上面还有内容提供商网络。现在大型的内容方会自建全球网络，直接和各级 ISP 互联，把自己的内容推到离用户很近的位置。这就是为什么有时候访问某些服务快得离谱——不是链路神奇，是内容就放在你城市的机房里。
| 层级 | 典型覆盖范围 | 设备特征 | 出问题时的表现 |
|---|---|---|---|
| 接入 ISP | 小区、园区、城市片区 | 接入服务器、汇聚交换机 | 高峰时段整体变慢、上行明显低于下行 |
| 区域 ISP | 省、大区 | 大型路由器、城域光纤环 | 跨市访问时延跳变，同城正常 |
| 骨干 ISP | 全国、跨国 | 高速路由集群、长距光缆 | 跳数少但单跳时延大，抖动明显 |
| 内容方网络 | 全球分布式节点 | 缓存集群、专线互联 | 命中缓存时极快，未命中时回源变慢 |
我在实际工作中发现，这张表最大的价值不是记忆，而是定位。当一个问题出现时，先判断它发生在哪一层，排查范围立刻缩小一个数量级。用户说"你们网站慢"，你至少要区分：是所有用户都慢，还是某个地区慢；是首次访问慢，还是刷新也慢；是下载慢，还是点按钮响应慢。这三个问题分别指向不同的层。
1.3 边缘、接入、核心：三块拼图各自的优化目标不一样
把 Internet 按位置切成三块——网络边缘、接入网、网络核心——这个划分比 ISP 分层更贴近工程视角。
网络边缘是端系统所在的地方，也就是你能直接接触的那一层。这一层的性能问题多半和终端有关：网卡协商速率、无线信号质量、CPU 抢占、应用层缓冲策略。我见过不少"网络慢"最后查出来是客户端自己处理不过来，报文堆在接收缓冲区里。
接入网是把边缘连到第一个路由器的链路，典型形态有光纤入户、同轴电缆、移动蜂窝、企业专线。这一层的关键指标是上下行带宽比和链路稳定性。家庭宽带通常下行远大于上行，做上传密集的业务时特别容易在这里撞墙，而很多人只看下行数字就以为带宽够用。
网络核心是路由器组成的网状结构，它的核心机制是分组交换。这一层不关心你传的是什么内容，只关心把分组从入口送到出口。它的性能瓶颈通常是队列容量和链路带宽，表现出来就是排队延时和丢包。
搞清楚这三块的分工，你会发现一个规律：边缘看终端、接入看带宽、核心看排队。这句话我写在排查笔记的第一页，遇到问题先按这个分类，比盲目抓包高效得多。
2. 分组交换为什么能把链路"用满"
2.1 存储转发：一个分组要经历的完整生命周期
分组交换的核心动作叫存储转发。这四个字看着平淡，其实信息量很大：路由器必须先把这个分组完整接收下来、存进缓冲区、查转发表、再决定从哪个口发出去。也就是说，一个分组在每一跳都要经历"收完才能发"。
这个机制带来一个直接后果：端到端延时是逐跳累加的。假设源主机到目的主机中间经过 N 条链路，每条链路的传输速率是 R，分组长度是 L，忽略其他延时，那么总延时大约是 N × L/R。这个公式在教材里是用来讲"为什么分组交换会引入额外延时"的，但它的工程含义更实用：跳数越多，累计的传输延时就越多。
这也解释了一个现象：为什么很多服务要把内容放到离用户近的节点。不是玄学，是把 N 从 15 降到 3。我做过一个粗略的对比，同一个静态资源从跨区域节点取和从同城节点取，首字节时间差了将近 40ms，其中大部分就是多出来的那几跳加上传播距离。
注意：存储转发意味着路由器在接收一个分组的過程中，这条输出链路可能是空闲的。这就是"存储转发"和"直通转发"的分歧点。很多高性能交换设备支持边收边转，代价是丢掉了完整性校验。理解了这一点，你就明白为什么有些设备标称的时延低得不正常——它们不是更快，是规则不一样。
2.2 统计复用的红利与代价
分组交换相对于电路交换最大的优势是统计复用。电路交换在你建立连接的时候就把带宽独占下来了，不管你说话不说话；分组交换是按需使用，链路上没有你的分组时，别人可以用。
用生活化的类比：电路交换像包下一整条马路，哪怕你只开一辆车；分组交换像大家共用一条马路，车多的时候排队，车少的时候畅通。显然共用更经济，代价是排队不可避免。
教材里有个经典算例：一条 1 Mbps 的链路，用户活跃时以 100 kbps 的速率产生数据，活跃时间占比 10%。用电路交换，最多支持 10 个用户。用分组交换，如果按"同时活跃用户超过 10 个才会明显拥塞"来算，能支持的用户数远大于 10，因为同时活跃超过 10 个的概率很小。
这个算例的关键不是记住数字，而是理解背后的假设：用户行为是独立的、随机的。一旦这个假设被打破——比如所有人都在晚上八点看同一个直播——统计复用的红利就消失了，排队会突然变得极其严重。这也是为什么突发流量是网络设计里最头疼的东西。
我在实际系统里见过类似问题：某个内部服务白天很稳，每天下午三点准时卡顿。查下来是定时任务集中触发，几百台机器在同一分钟内拉取同一份大文件。带宽没变，链路没坏，只是"独立随机"这个前提不成立了。
2.3 一个算例：把队列长度的直觉建立起来
光说排队没感觉，算一下就有概念了。设链路速率 R = 100 Mbps，平均分组长度 L = 1500 字节 = 12000 bit，分组到达速率 a = 8000 包/秒。
链路每秒能发出的分组数是 R/L = 100000000 / 12000 ≈ 8333 包/秒。流量强度 ρ = aL/R = 8000 × 12000 / 100000000 = 0.96。也就是说，链路有 96% 的时间在忙。
流量强度 0.96 听起来"还有余量"，但排队理论告诉我们，这个状态下队列长度会急剧波动。粗略地，平均排队分组数约等于 ρ/(1-ρ) = 0.96/0.04 = 24 个分组；如果 ρ 升到 0.98，平均值变成 49 个。流量强度从 96% 涨到 98%，排队长度翻倍。这就是为什么生产环境的链路利用率监控阈值一般设在 70% 到 80%，而不是 95%。
平均排队延时 = 平均排队分组数 × L/R = 24 × 12000/100000000 ≈ 2.9ms。如果 ρ = 0.98，就是 5.9ms。看着不大，但这是平均值，尾部的 P99 可能是平均值的十倍以上，对实时性敏感的业务就是灾难。
这组数字我建议你亲手算一遍，算完再看监控面板上的利用率曲线，感受会完全不同。
3. 四种延时：公式背后的物理含义
3.1 处理延时：路由器里那几微秒到底在干什么
处理延时是节点处理分组所花的时间，包括检查首部、提取目的地址、查转发表、检查差错。这段时间通常在微秒级，高性能设备甚至能做到纳秒级。
它容易被忽略，但在两种情况下会变成主角。一是设备本身负载过重，控制平面被大量路由更新或管理请求打满，查表动作被拖慢；二是遇到了需要特殊处理的分组，比如分片重组、深度包检测、NAT 转换，这些都会让处理延时明显上升。
我遇到过一台老设备，正常转发时延 30 微秒，一旦开启某种流量识别功能，单跳处理延时涨到 200 微秒以上，链路总时延直接从 3ms 涨到 6ms。这类问题从带宽、丢包上完全看不出来，只能靠逐跳对比时延才能发现。
提示：处理延时在总延时里占比很小，但它是最容易因为配置变更而突变的成分。做网络变更时，如果时延出现无规律的普遍抬升，优先怀疑设备功能和配置，而不是链路。
3.2 排队延时：流量强度决定一切
排队延时是分组在输出缓冲区等待发送的时间。它是四种延时里唯一随负载动态变化的成分，也是实际排查中最重要的一个。
教材用流量强度 ρ = La/R 来描述排队程度，其中 L 是分组长度，a 是到达速率，R 是链路速率。这个量的取值有三种区间：
- ρ 接近 0：几乎没有排队，链路大部分时间空闲；
- ρ 接近 1：排队迅速增长，且波动极大；
- ρ 大于 1：到达速率超过发送能力，缓冲区持续占用，最终溢出丢包。
这里是第一个"反直觉点"。很多人觉得 ρ 小于 1 就安全，实际上 ρ = 0.9 时尾部延时已经可能达到几十毫秒。系统的稳定性不是由平均值决定的，是由峰值决定的。
缓冲区大小的选择也是同一逻辑。缓冲区太小，突发流量直接丢包；缓冲区太大，排队延时可能高得离谱，而且丢包被推后了，反而让上层协议误判。这个"缓冲区到底多大合适"的问题在业界争论了很多年，结论是不能一刀切，要结合业务类型。交互型业务宁可丢包也不要长延时，大文件传输则相反。
我自己的经验是：看 P99 排队延时，不要看平均。平均值会把大量零排队的样本混进来，把问题稀释掉。监控面板上如果有"平均响应时间"这一项，它几乎从来不会告诉你真相。
3.3 传输延时：L/R 到底由谁决定
传输延时是把分组的全部比特推上链路所需的时间，等于分组长度除以链路速率：L/R。
这个公式很简单，但两个变量的来源必须清楚。L 取决于你的报文大小和应用层协议，R 取决于链路本身。这意味着优化传输延时只有两条路：减小 L，或者提高 R。
减小 L 在实践里有具体做法：控制接口返回体大小、压缩传输内容、分页拉取、避免一次性返回巨量 JSON。我见过一个接口返回 3MB 的配置数据，改成增量下发后降到 40KB，在低速链路上传输时间从 200ms 以上降到个位数毫秒。
提高 R 就是升级带宽，但要注意 R 是每一条链路各自的。端到端路径上所有链路的 R 都提升了才有意义，只提升其中一段，那段就成了浪费。这也是为什么单纯扩容某一侧带宽经常没有效果。
还有一个容易忽略的点：传输延时是串行的。一个 1500 字节的包在 1 Gbps 链路上传输需要 12 微秒，这 12 微秒内这条链路就被这个包占着。链路速率越高，单个包的占用时间越短，但包的数量不会因此减少。
3.4 传播延时：d/s，由物理距离和介质决定
传播延时是比特在物理介质中传播所需的时间，等于距离除以传播速度：d/s。
这个量最让人无奈，因为它几乎无法通过技术手段优化。光在真空中的速度约 3×10^8 m/s，在光纤中约为 2×10^8 m/s。也就是说，每 1000 公里的光纤，单程至少要 5ms。这是物理定律，不是工程问题。
这个数字能解释很多现象。跨洲访问时延通常在 150ms 以上，其中大部分是传播延时，你把带宽升到多高都没用。同城访问能做到 1ms 以内，也是因为物理距离短。
介质的选择也会影响 s。光纤中约 2×10^8 m/s，铜缆中略低，无线信号在空气中接近光速但受环境影响更大。教材里会给几个典型值，实际工程中一般直接按光纤 2×10^8 m/s 估算。
注意：传播延时和链路带宽完全无关。一条 10 Gbps 的跨洲链路，传播延时和一条 100 Mbps 的同路线链路一模一样。带宽只影响"推上去要多久"，不影响"在路上飞多久"。
3.5 传输延时与传播延时：这条区分值一千块钱
这是整章最容易混淆、也最值得反复强调的一对概念。我用一个类比说清楚：
想象一条高速公路上有一队卡车运送货物。传输延时是"把这一队卡车全部开上高速匝道"所需的时间，取决于卡车的数量和匝道的通行能力。传播延时是"第一辆卡车从匝道口开到目的地"所需的时间，取决于路程和车速。
这两个时间可以差异极大。一条 1000 公里长、带宽 1 Gbps 的链路，传输一个 1000 字节的包只需要 8 微秒，但传播延时是 5 毫秒。也就是说，真正花时间的是在路上飞，不是推上链路。反过来，一条 10 米长的千兆网线，传播延时只有 50 纳秒，传输延时反而可能占主导。
| 维度 | 传输延时 | 传播延时 |
|---|---|---|
| 公式 | L/R | d/s |
| 决定因素 | 分组长度、链路速率 | 物理距离、介质传播速度 |
| 量级 | 微秒到毫秒（低速链路时） | 纳秒到百毫秒 |
| 能否优化 | 能，减小包或升级带宽 | 基本不能，只能缩短物理距离 |
| 类比 | 把车队开上匝道 | 车队在路上跑 |
理解了这个区分，你就能解释很多"看起来矛盾"的现象：为什么升级带宽有时候对响应时间毫无帮助（因为瓶颈是传播延时）；为什么把大包拆小能改善交互体验（减少了单个包的传输延时，让后续的包不用等）；为什么同城机房和异地机房在实时业务上体验差距那么大（传播延时差了几十毫秒）。
还有个组合概念值得记住：带宽时延积，等于带宽乘以传播延时，表示"管道里最多能装多少比特"。一条 1 Gbps、传播延时 5ms 的链路，带宽时延积是 5×10^6 bit，约 625 KB。这个数告诉你，要填满这条链路需要一次性发出去这么多数据，否则链路就是空转的。这也是为什么长肥管道（高带宽、高时延）上的传输协议需要更大的窗口。
4. 丢包与吞吐量：端到端性能的两张底牌
4.1 丢包发生在哪里，以及为什么 TCP 会"背锅"
丢包的直接原因通常是缓冲区溢出：分组到达时队列已经满了，只能丢弃。另一种情况是链路误码导致分组校验失败被丢弃，但现代有线链路的误码率极低，这不是主因。
丢包有两个非常关键的认知点。
第一，丢包和延时是同一个问题的两面。缓冲区满导致丢包，缓冲区接近满导致长延时。你不可能只要其中之一。想降低延时就得减小缓冲区，但那样会更早丢包；想减少丢包就得加大缓冲区，但延时会变长。这个权衡没有免费答案。
第二，丢包对上层协议的影响是放大的。TCP 把丢包解释为拥塞信号，会主动降低发送速率。一个丢包可能触发窗口减半，进而导致整体吞吐量断崖式下降。所以 1% 的丢包率，在吞吐量上的表现可能是 20% 以上的性能损失，而不是 1%。
我遇到过最典型的误判：某个服务成功率 99.9%，看着不错，但用户投诉明显。查下来是那 0.1% 集中在某个环节，且每次失败都要等超时重试，一次超时 3 秒，用户体验上是"偶尔卡死"。丢包率是统计量，体验是个体量。监控看平均数永远看不出这类问题。
4.2 吞吐量：端到端速度由最窄的那一段决定
吞吐量是单位时间内成功传输的比特数。对于一条经过多个链路的路径，端到端吞吐量约等于min(R1, R2, ..., Rn)，也就是所有链路速率中的最小值。这个最小值所在的链路叫瓶颈链路。
这个结论看着平淡，实际价值极大。它意味着：优化非瓶颈链路是完全无效的。你把中间某一段从 100 Mbps 升到 1 Gbps，如果瓶颈在别处只有 50 Mbps，端到端吞吐量还是 50 Mbps。
实际场景里的瓶颈常常不在你以为的地方。一个典型例子：客户端带宽 100 Mbps，服务器出口 100 Mbps，中间链路 10 Gbps，但服务器所在机房有一个共享的带宽池，被其他业务占用了大半。这时候瓶颈是那个共享池，不是任何一条"链路"。
还有一个更隐蔽的因素：存储和 CPU 也会成为瓶颈。服务器磁盘读取慢、应用序列化耗时、TLS 握手开销大，都会让"网络吞吐量"上不去。真正的端到端吞吐量是由整条处理链路上最慢的一环决定的，网络只是其中一环。
| 观测指标 | 说明什么 | 常见误判 |
|---|---|---|
| 带宽利用率 | 链路负载水平 | 利用率不高就认为没问题，忽略了尾部拥塞 |
| 平均 RTT | 整体时延水平 | 平均值被大量快请求稀释，掩盖长尾 |
| 丢包率 | 拥塞或链路质量 | 认为 0.1% 无所谓，忽略重传放大效应 |
| 吞吐量 | 有效传输速率 | 只看单链路，忽略应用层和存储瓶颈 |
4.3 用 ping、traceroute、iperf 把公式对回现实
概念讲完，必须落到能动手的工具上。我平时用的三件套：
ping测往返时延和丢包。注意 ping 测的是 RTT（往返），不是单向延时，估算时除以 2。
# 发 20 个包，每个 1400 字节，间隔 0.2 秒 ping -c 20 -s 1400 -i 0.2 目标地址输出里的time=是 RTT，mdev或标准差反映抖动。如果最小值和最大值差很多，说明路径上存在排队波动。
traceroute看逐跳时延，能定位问题出在哪一段。
# 最多 20 跳，每跳探测 3 次 traceroute -n -m 20 目标地址用法要点：某一跳突然时延暴涨，而后续跳恢复正常，通常说明那一跳的设备对探测报文响应慢，不代表转发有问题。要结合多跳趋势看。连续多跳时延线性上升是正常的传播延时；某跳之后所有跳都抬高，那一段才是真问题。
iperf3测真实吞吐量。
# 服务端 iperf3 -s # 客户端，测 10 秒，单流 iperf3 -c 服务端地址 -t 10 # 客户端，测 10 秒，4 条并发流 iperf3 -c 服务端地址 -t 10 -P 4单流和并发流的差异很关键。单流吞吐受限于单个连接的窗口和 RTT，并发流能更好地填满链路。如果单流只有 20 Mbps 而 4 并发能到 80 Mbps，说明瓶颈在协议窗口或单连接处理能力，不在链路带宽。
再补一个自己算传播延时的例子。假设两个机房直线距离 1200 公里，走光纤，s 取 2×10^8 m/s：
传播延时 = 1.2×10^6 / 2×10^8 = 6ms（单程），往返 12ms。
如果实测 RTT 是 25ms，那么除了 12ms 的传播延时，还有 13ms 消耗在处理、传输和排队上。这个差值就是你可以在设备和配置上优化的空间上限。先算出物理下限，再看还有多少可优化余量，这个习惯能帮你避免做无用功。
5. 排查实录：把概念变成一张对照表
5.1 典型症状与对应的排查方向
下面这张表是我从自己的排查记录里整理的，症状和成因的对应关系不唯一，但覆盖了大部分常见情况。
| 症状 | 优先怀疑 | 验证方式 |
|---|---|---|
| 时延高但稳定，不抖 | 传播延时，物理距离 | 查两端地理位置，算理论下限 |
| 时延周期性波动 | 排队延时，链路拥塞 | 对比不同时段的 RTT 分布 |
| 时延随机尖刺 | 缓冲区排队或设备处理 | 逐跳对比，看哪一跳抖动 |
| 吞吐上不去但时延正常 | 瓶颈链路或应用层 | iperf 单流 vs 多流对比 |
| 小文件快、大文件慢 | 带宽时延积不足或窗口限制 | 调整并发数看是否改善 |
| 少量请求超时 | 丢包触发的重传超时 | 抓包看重传次数和间隔 |
用法很直接：先按症状圈定两三个可能原因，再用验证方式逐个排除。不要一上来就抓包，抓包成本高、信息噪音大，先用 ping 和 traceroute 建立基本判断，能省掉大量时间。
5.2 几个我踩过的坑
第一个坑：把 RTT 当成单向延时。早期算优化空间的时候，我用 RTT 直接减传播延时，结论总是"还有很大优化余地"，实际改造后毫无效果。RTT 是往返，单向延时是它的一半左右，物理下限也要按单程算。
第二个坑：忽略缓冲区的影响。有一次跨区域调用时延从 40ms 涨到 90ms，我以为是链路出了问题，查了半天才发现是中间某台设备的缓冲区被调大了，排队时间变长。缓冲区调大不等于优化，很多时候是把延时换成了不丢包。
第三个坑：只测平均值。一个接口平均响应 50ms，看着很好，但 P99 是 800ms。用户感受到的是那 1% 的慢请求，不是平均值。现在我看任何网络指标，第一眼找的都是分位数。
第四个坑：用带宽解释一切。带宽只影响传输延时，对传播延时、处理延时、排队延时都没有直接作用。升级带宽能解决"传大文件慢"，解决不了"点按钮反应慢"。
第五个坑：忘记跳数的影响。存储转发意味着每跳都要完整接收再转发，跳数多的时候，累计的传输延时会明显起来。一个路径从 8 跳变成 16 跳，即使每跳只增加 1ms，端到端也会多出 8ms。
提示：做任何网络优化之前，先做三件事——测 RTT 分布（不只看平均）、算传播延时理论下限、确认瓶颈链路在哪。这三件事做完，能排除掉大半的错误方向。
从 Internet 的分层结构，到分组交换的存储转发，再到四种延时的拆解、丢包与吞吐量的关系，这条线其实是一个完整的因果链：结构决定了路径，路径决定了跳数，跳数决定了延时累加，链路速率决定了瓶颈，缓冲区决定了排队和丢包。任何一个网络问题，都能在这条链上找到位置。我自己最大的体会是，不要急着调参数，先算清楚理论上限在哪里。算完你会发现，很多所谓的性能问题，其实是物理规律，能优化的只有剩下那一小块，而那一小块往往就在缓冲区策略和路径选择上。
