You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

XMLHttpRequest.send首次调用成功第二次报错ERR_EMPTY_RESPONSE

问题根因分析

你观察到的故障现象核心指向服务器响应写入的目标文件描述符不匹配,结合你调试得到的规律,最可能的原因如下:

  1. 你用汇编实现的Web服务器大概率存在逻辑漏洞:正常程序中SYS_ACCEPT每次返回相同fd,本质是内核复用了前一次请求处理完成后被关闭的连接fd号,即使你写响应时误用了固定/前一次的fd,也刚好命中了当前连接的fd,因此能正常返回响应;而故障程序存在fd泄漏(旧连接fd未被正确关闭),内核无法复用fd号,SYS_ACCEPT返回新fd后,你的响应写入逻辑依然往旧fd写数据,新连接对应的fd没有收到任何响应数据,浏览器就会抛出net::ERR_EMPTY_RESPONSE错误。
  2. 次要可能为故障版本的服务器未正确处理HTTP长连接:如果故障版本开启了长连接支持但未配套多连接fd管理逻辑,浏览器复用已有TCP连接发送新请求时,服务器未识别到该连接上的新请求,也不会返回响应。
排查解决思路
  • 优先校验响应写入逻辑:确保每次处理请求时,写入响应的目标fd严格使用当前次SYS_ACCEPT返回的最新fd,禁止硬编码固定fd值、或沿用上一次请求的fd变量。
  • 核查套接字生命周期管理:每次请求处理完成后,必须显式关闭当前SYS_ACCEPT返回的连接fd,避免fd泄漏;同时确认监听套接字全程没有被误关闭。
  • 核对孪生程序的配置差异:对比正常版本和故障版本的服务器初始化参数、请求处理分支逻辑,重点排查故障版本是否存在分支逻辑跳过了响应写入、连接关闭的步骤,或是误开启了长连接支持但无对应的多连接处理逻辑。
  • 抓包验证交互流程:使用tcpdump或Wireshark抓取本地环回端口1024的流量,对比正常请求和故障请求的TCP交互,确认故障时服务器是否确实未在对应TCP连接上返回响应报文,进一步定位问题分支。

内容的提问来源于stack exchange,提问作者roger tunnicliffe

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.09.24 07:36:04