TCP 是一个每个人都懂的协议，但真没必要每个人都懂。
协议栈工人的大部分时间都抛洒在和业务工程师拧巴 TCP 的细节上。
- 为什么我抓到了这么多重传包。
- 为什么没有重传。
- 为什么会被 RST。
- 为什么人家的 TCP 能打到 100 Mbps，我这里只能 50 Mbps。
- …
这是你该知道的吗？拜托，大家时间都贵。
每当我遇到这种咨询，我都会反问一句 “影响到业务指标了吗？”，如果影响到了，我会帮忙查一下配置问题，基本就解决了，我会很乐意顺便精讲一下 TCP 细节，但这明显是个人行为，与工作无关，因为我本来就喜欢分享。但如果根本没有影响到业务指标，我心里会觉得 “你只是好奇罢了，但不要利用工作时间满足你的好奇心。”
TCP 是一个挣扎协议，你会发现搞 Web 开发的甚至搞前端的，多多少少都懂 TCP，但很多人真的没必要懂 TCP。协议栈工人不懂物理层细节，业务工人懂 TCP 只会浪费很多时间掰扯。
要有边界意识。边界意识可以节省很多时间。
我经常陷入诸如下面的问题。“配置一样，为什么 A 和 B 差那么一丁点？”，“配置一样，为什么 A 和 B 差那么多？” 并且一陷就是好几天。最后大概率就是环境问题。
业务工人有必要知道这些吗？每到此时，“影响到业务指标了吗？”是应该问一句的。当然，如果是配置问题，我会在解决问题后戛然而止，然后走人，表明工作结束，走两步后回头给业务工人解释 TCP 细节，就纯属个人行为了。
我不觉得业务工人有懂 TCP 的必要，就好像开奥迪的不必懂夸戳(quattro)一样，只需要知道个名字就好了。为什么 BBR 好，不用跟业务解释 BBR 的状态机，只告诉他们 BBR 对丢包不敏感就够了，为什么夸戳好，只需要告诉车主夸戳是四驱就够了。
客户追问 TCP 的细节会浪费大量的时间和精力，在他们用业务语言描述问题的时候，已经存在偏差了，比如当他们说 “都一样” 的时候，在协议栈工人看来并非如此，如果他们不理解环境的细节差异，他们就不必知道 TCP 的细节。不然就是没完没了的扯皮。
TCP 范围太宽了，你会发现几乎所有做开发的，都懂 TCP，但也只是稍微懂，包括客户在内，这些懂 TCP 的人很容易将很多更多的人卷入一些无谓的挣扎，所以，对客户，你只告诉他 “我们保证文件 F 可以最快的速度从 A 传到 B，如果没有做到，那是我们的错” 就够了。
如果某天真的没有做到，当我排查到根因后，我没有义务告诉客户细节，我只需要告诉客户 “问题解决了，是我们的错。“ 就够了。我甚至拒绝客户参与过程，因为很多细节不是客户需要知道的，即便我想让他们知道，前置信息太多，以至于无论是谁事后看，都在浪费时间。
我经常怼客户，我认为他们在问一些他们不该问的东西，10 多年了都这样，我从来没有问题夸戳的细节，就算感兴趣我也不会去问修车行的工人，我只是默默查查资料，有个修车行的朋友在他下班后给我讲讲就行了。写个文章，未完待续。
浙江温州皮鞋湿，下雨进水不会胖。
