这是一个创建于 816 天前的主题，其中的信息可能已经有所发展或是发生改变。
问题描述
假设：
- 这里有一个接口，在浏览器控制台中看到他的请求时间是 50ms
- 复制到同网络环境下的 postman 中调用，请求时间是将近 200ms ，请求头完全复制
- 把调用写到 js 脚本中，在同网络环境下 node 运行 ，console.time 显示也是 200ms
怀疑过程
- 一开始以为是 nodejs 瓶颈，在中文互联网下搜索原因寥寥无几，改去 stackoverflow 用 [nodejs is slower than chrome] 查找，有几篇类似的像这一篇，看回答基本都是是归咎于网络；
- 通过 fiddler 查看，有如下区别
- 在 js 脚本中把原本一次运行只调用一次的请求重复调用了几次，发现后几次速度逐渐接近浏览器原生访问
我的问题
- 我怀疑是不是有什么缓存机制在生效，与 fiddler 中的 TCP/IP Connect 和 ServerConnected 的差异相耦合，可惜到这里中文互联网上的资料就明显出现了欠缺，感觉我已经快找到正确的原因了，所以来找大家确认下
- 如果 1 是正确的，那对于每次运行都从头开始的 js 脚本，有什么解决方法吗？ nginx 的缓存配置可以起到作用吗
 | 1 BeautifulSoap 2023-09-03 13:50:46 +08:00 via Android  3 keep alive 吧，chrome 多次请求就自动帮你处理了。nodejs 运行完脚本就停掉了所以打开的端口直接关了需要重开 |
 | 2 hronro 2023-09-03 13:59:17 +08:00 听说 node.js 内置的 http 模块很拉, 在 node.js 里用 shell 去调用 CURL 发请求都比用内置的 http 模块快(听别人说的, 没实际验证过) |
 | 3 isbase PRO 用 urllib 试试 |
 | 4 div class="sep3"> L1shen 2023-09-03 14:08:32 +08:00 觉得内置的 http 慢可以试试 uWebSockets.js |
 | 5 sub166 2023-09-03 16:12:21 +08:00 换成 deno 或者 bun 试试 |
 | 6 zsj1029 2023-09-03 19:38:55 +08:00 via iPhone 进程开销，如果是 koa 常驻内存再试，应该可以稳定 |
 | 7 MrKrabs 2023-09-03 19:58:35 +08:00 盲猜 tcp 连接延迟 |
 | 8 githmb 2023-09-04 10:19:12 +08:00 有没有一种可能，浏览器的请求复用了一个 TCP 连接，你没发现你在 js 脚本里重复调用了几次只有第一次延迟有点高吗？ |
 | 9 mark2025 2023-09-04 13:11:44 +08:00 1. nodejs 环境启动开销 2. http 握手开销 |
 | 10 KiraMaple 2023-09-11 22:14:15 +08:00 @hronro 你看过 nodejs 的架构图就知道了，nodejs 本身调用 http 请求最后也是用 nodejs 内置的 curl 库，c++和 js 的交互应该不算频繁，而且 V8 在跨语言交互这块不算差 |
 | 11 thynson 2023-09-15 09:54:05 +08:00 1. 浏览器的 keep-alive 机制优化掉了连接建立的开销 2. 浏览器默认会开启压缩，而 postman/node.js 默认没有压缩，如果 response body 较大，而且网速不够快的话，会有显著的区别 3. 如果你要测量一个接口的响应时间，最好在服务端测量，浏览器端的测量不可避免的会收到网络的影响 |
Select Language