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 多年了都这样,我从来没有问题夸戳的细节,就算感兴趣我也不会去问修车行的工人,我只是默默查查资料,有个修车行的朋友在他下班后给我讲讲就行了。写个文章,未完待续。
浙江温州皮鞋湿,下雨进水不会胖。