絮叨两句，现在 AI 的知识储备太强大了，一个好模型喂了海量的文档之后，就可以用做一个知识库来用。对于很多技术问题，即使是比较罕见的问题，也会由于网上的材料足够多，而让 AI 抓到答案。不论是资深技术工程师还是做为技术博客而言，都难做了不少。或者说，如果之前只需要提升技术水平，现在还需要培养对AI工具潮流的敏锐度。
场景
点击一个按钮的时候，会发一组 3 个请求。由于没有做节流，请求会在发送若干次后，一组请求成为pending状态。在相同浏览器中打开一个新 tab 请求相同域名，页面资源文件无法返回。
分析
首先排除 HTTP 连接数达到上限。
因为这种场景只会影响到当前tab，而不会影响到新开tab。
转而去想是否是网关层对流量做了限制。当然这个想法比较愚蠢，如果请求的 QPS 这么低，那么环境早就该报出问题了。但是排查问题的话，肯定都是要一步一步来，如果一个问题查了很久，最后查出一个很简单的问题，往往就是排查路径盲目自信导致遗漏重要问题点。所以在另一台电脑上面访问相同域名，不出意料可以正常访问。但是还是有可能网关侧的安全措施，按照用户做限流。在另外电脑登陆相同用户之后，发现还是可以正常访问。这个时候要排查问题，首先得找到问题出在哪里，所以转到问题定位流程。
首先请求是pending状态，还是需要判断请求是否真的发出去了，而不是在等请求返回。要判断还是比较简单，通过Charles或者Fiddler抓包看返回就好。结果请求没有发出去。
原因
TCP连接池占满。在大家所熟知的，大部分浏览器对同域名的 HTTP 并发请求为6个，但是在TCP层也会有类似的限制。以下节选自大模型：\
在传输层，操作系统会对单个源（协议+域名+端口）的TCP连接和TLS（SSL）会话有严格的管理。每当一个TCP连接被关闭时，它不会立即消失，而是会进入一个叫做
TIME_WAIT的状态。这个状态会持续一段时间（通常是60秒或2*MSL），目的是确保网络中所有的旧数据包都已消散，防止它们与新的连接混淆。。处于TIME_WAIT状态的Socket（源IP、源端口、目标IP、目标端口四元组）不能被立即重用。 (HTTP/1.0旧模式) 每个HTTP请求都需要：建立TCP连接 -> 发送请求 -> 接收响应 -> 关闭TCP连接, 在这种模式下，每秒一个请求，60秒后就会产生60个处于TIME_WAIT状态的连接，很快就会耗尽端口。这就是为什么HTTP/1.0性能极其低下的原因。 解决方案：启用HTTP/2 - 多路复用让所有请求共享一个TCP连接，彻底规避端口耗尽和握手问题。
结语
问题就是这样，模型的力量还是很强大的，无论什么级别的同学，都应该好好利用，但是不要过度依赖，尤其是成长中的同学。自身实力硬才是硬道理。
