客户端在HTTP持久连接中发送下一个请求的信号

Question

在HTTP / 1.1（持久连接）中，提示客户端发送下一个HTTP请求的“信号”是什么？ Content-Length之外还有什么吗？

我正在尝试构建一个简单的网关，它可以跨文件桥接TCP流量。我有两个应用程序：

• “server”打开一个套接字并等待连接。建立连接后，它会转发输出文件中的所有内容，同时将所有内容从输入文件转发回套接字
• “client”等待上述输出文件中的内容并建立与服务器的连接，向其发送数据并将接收到的数据写回上述输入文件。

换句话说：我通过套接字获得的所有内容都会通过文件重定向到另一个套接字，反之亦然。

AFAIK这应该是完全透明的，但持久连接不能按预期工作。

我正在使用Firefox进行测试 - 会发生的情况是FF发送两个GET并收到两个响应。但它只是坐在那里，等待它好像还没有收到所有数据... 5秒后（服务器响应“保持活动：超时= 5”，所以这适合）其中一方关闭连接和当它再次卡住时，重新建立它并继续发送一些文件。

我听过WireShark，但无法发现任何异常。知道发生了什么事吗？

更新：下面是WireShark日志的屏幕截图。它表明在TCP连接关闭（注意时间）后发送HTTP连接太晚了。从我的日志来看，它是立即发送的。知道为什么会出现这种差异吗？我应该以某种方式“冲洗”插座吗？我正在使用Python。

Answer 1

它是Content-Length或Chunked-Encoding（或者如果连接已关闭），它会“向客户端发送”数据的长度/结尾。

收到HTTP数据后，浏览器会保持tcp / ip连接打开一段时间，以允许通过相同的tcp / ip连接向同一服务器发出进一步请求。

Answer 2

没有'信号'。客户端准备好时会发送下一个请求。

  

然后它只是坐在那里等待它好像没有收到所有   数据

所以它可能尚未收到所有数据。你是在准确写出来的吗？并刷新任何缓冲区？