内行透底：3秒加载？实测TCP握手就耗了1.2秒

　　去年四月的一个周三下午，我在机房盯着监控屏，旁边坐的是新来的运维小周，手里攥着刚打印的性能报表，嘴里还碎碎念着“终于把页面加载压到三秒以内”。那天我们本来是测新业务的上线基线，他说之前加载慢到五秒，调了几次就砍到三秒，跑出来的监控曲线都带着点往上飘的劲儿，跟他脸上藏不住的笑似的。

　　我当时没接他的话，伸手拉了抓包工具的日志窗口——那玩意儿是我攥了快十年的老伙计，键盘快捷键都磨掉漆了。我原以为是请求的链路问题，比如绕了多活节点或者CDN调度错了，结果往下翻TCP握手的时序，第一个SYN包发出去，隔了差不多一秒多收到SYN+ACK，第二次握手的ACK包发出去，又隔了二十毫秒才拿到后续的HTTP响应——单握手就耗了快一秒二，占了三秒加载时间的四成不到，这锅性能优化的小周要背大半？

　　我蹲在小周旁边，把抓包日志甩给他看，他眼睛瞪得快贴到屏幕上，手里的笔滚到了机房地板上。后来我们扯了快一小时，从服务器的TCP参数调到运营商的链路配置，他说之前只调了业务层的缓存，没碰网络层的细节，还说之前问过老员工，老员工说“TCP参数别瞎调，容易出连接问题”，他就没敢碰。

　　哪年我刚入行的时候？好像是第十年还是第十一年来着，有个项目的登录页面加载慢到七秒，抓出来的TCP握手就占了快三秒，那时候运营商的链路还没现在这么稳定，那时候我就觉得TCP握手这个环节，是个没人愿意捅的窗户纸——大家都盯着页面加载总时间，没人拆成链路的各个部分看，反正总时间达标就行。

文章配图，仅供参考

　　我后来才发现，很多同行都跟这几个前端哥们一样，只看总加载时间，不拆TCP握手的时间。去年四月那次测的业务，TCP握手就耗了快一秒二，我原以为是链路问题，后来查出来是服务器的TCP参数调得不对——比如syn队列的长度设得太小，超过队列的连接都被丢了，导致客户端重传SYN包，每次重传就多耗一秒多，我后来把syn队列改成了合适的长度，又调整了tcp_syn_retries的次数，TCP握手的时间直接砍到了一百二十毫秒不到，页面加载总时间也落到了两秒以内，小周后来给我买了两杯冰美式，说是欠我的“救命之恩”。

　　还有个细节，那天测的时候，我注意到客户端的TCP初始窗口设得不对，明明可以设成更大的，却用了默认值，导致第一次发送的数据量太小，后续的HTTP响应又被拆成了好几个包，反而增加了延迟，这也是TCP握手之后的小问题，但不解决的话，总加载时间还是会飘。

　　后来我跟之前那个给小周提建议的老员工聊，他说那时候项目紧，大家都盯着上线，TCP参数调起来麻烦，还容易出问题，就这么凑合了，没想到现在新员工还是这么凑合，这事儿让我觉得，内行的责任不光是自己把活干好，还要把这些细节说透，不然大家都在“差不多就行”的坑里打转，没人愿意去碰那些耗时间的小环节。

　　还有一次，我跟一个做安全的朋友聊，他说现在很多网络攻击都是盯着TCP握手的漏洞，比如syn洪水攻击，就是利用syn队列的漏洞，把服务的连接打崩，那时候我就想，如果我们平时就把TCP参数调对，不仅能优化加载时间，还能增强服务的抗攻击能力，这是一举两得的事儿，之前怎么就没人提呢？

　　对了，去年四月那次测，我还发现一个有意思的事儿，就是不同的浏览器，TCP握手的时间不一样，比如Chrome的TCP握手时间比Firefox短，Firefox又比Edge短，这是因为不同的浏览器对TCP参数的默认设置不一样，比如初始窗口、重传次数这些，这也是前端优化的时候可以注意的细节，我后来把这个发现告诉了小周，他说下次测不同浏览器的性能，一定要把这个环节也拆进去。

　　还有个事儿，我之前跟一个做CDN的朋友聊，他说很多CDN厂商都能优化TCP握手的时间，比如用TCP fast open，或者提前建立连接，这样能把TCP握手的时间砍到几乎为零，我后来把这个想法跟小周说，他说下次上线新业务，一定要把CDN的TCP优化参数用上，这样不仅能优化加载时间，还能节省服务器的资源，这又是一个之前没人注意的细节。

　　我原以为TCP握手的时间是个没法优化的死环节，结果去年四月那次实测，给我上了一课——原来只要把参数调对，把链路理顺，这个环节的时间能砍得这么多，后来我就跟周围的同行说，别只盯着总加载时间，要把每个环节的时间都拆出来看，这样才能找到真正的性能瓶颈，不然就会像小周之前那样，以为三秒的加载时间已经达标了，其实里面藏着快一秒二的浪费。

　　对了，刚才说的那个做安全的朋友，他后来还跟我说，TCP握手的时间其实也能反映服务的健康状况，如果TCP握手的时间突然变长，可能是服务器的syn队列满了，或者链路出现了丢包，这也是一个监控服务健康状况的指标，这事儿我之前从来没考虑过，原来性能优化和安全监控是相通的，只是我们之前把它们分开了，没人愿意把这两个领域的细节串起来。

　　还有一次，我跟一个刚入行的运维聊，他说他觉得TCP参数是个很深的东西，不敢随便碰，我就把去年四月那次测的抓包日志给他看，跟他讲了syn队列、重传次数、初始窗口这些参数的作用，他听了之后说，原来这么简单，之前以为要学好多复杂的东西，现在才发现，只要把几个核心参数调对，就能解决好多问题，这让我觉得，把内行的细节说透，不光是优化性能，还能帮新人少走弯路。

　　对了，我后来还发现，有些业务系统的TCP连接是复用的，不用每次都走完整的TCP握手，比如用HTTP/2或者HTTP/3，就能复用之前的连接，这样也能节省时间，我之前做过一个项目，用HTTP/2之后，TCP握手的时间几乎没了，页面加载时间直接砍了一半，这也是一个之前没重视的点，大家都在炒HTTP/2的多路复用，却没人提连接复用能省多少时间。

　　还有个事儿，我跟一个做网络设备的朋友聊，他说现在的交换机和路由器，也能优化TCP握手的时间，比如用流量工程，把TCP连接的路径选得更短，这样也能减少延迟，我之前从来没注意过这个，原来性能优化不光是服务器和应用层的事儿，网络设备也能出大力，只是大家之前都盯着应用层，没人愿意去碰网络设备的配置，觉得那是运营商或者设备商的事儿，其实不是，我们自己也能调，只要懂点基础的网络知识。

　　我原以为这个事儿就这么过去了，结果上个月又碰到一个类似的项目，测的时候TCP握手的时间又占了总加载时间的三分之一，这次我直接把之前的抓包日志和优化参数拿出来，跟那个运维一起调，不到半小时就把时间砍到了一百五十毫秒，那个运维跟小周之前一样，眼睛瞪得大大的，说原来还能这么弄，这让我觉得，内行的价值就是把这些没人说透的细节，变成能解决实际问题的办法，不然大家都在“优化了但没完全优化”的坑里打转，还沾沾自喜。

　　对了，刚才跟我吵架的那两个前端，上次我碰到他们，他们说已经把TCP握手的时间加到性能监控里了，每次测页面加载都会拆成各个环节看，还说之前的项目，TCP握手就占了快一秒，他们之前都没注意，这让我觉得，把内行的细节说透，不光是自己的事儿，还能影响周围的人，哪怕只是一点点，也能让整个行业的水平往上走一点，这比什么高大上的技术分享都有用，因为都是实打实的踩坑经验，是同行能听得进去的东西。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!