什么信号表明客户端在 HTTP 持久连接中发送下一个请求
在HTTP/1.1（持久连接）中，提示客户端发送下一个HTTP请求的“信号”是什么？除了 Content-Length 之外还有其他什么吗？
我正在尝试构建一个简单的网关，它将跨文件桥接 TCP 流量。我有两个应用程序：
- “服务器”打开一个套接字并等待连接。建立连接后，它将转发从输出文件获得的所有内容，同时将输入文件中的所有内容转发回套接字
- “客户端”等待上述输出文件中的内容，并与服务器建立连接，将数据发送到并将接收到的数据写回上述输入文件。
换句话说：我通过套接字获得的所有内容都通过文件重定向到另一个套接字，反之亦然。
据我所知，这应该是完全透明的，但持久连接不能按预期工作。
我正在使用 Firefox 进行测试 - 发生的情况是 FF 发送两个 GET 并收到两个响应。但然后它只是坐在那里等待，好像还没有收到所有数据一样...... 5 秒后（服务器响应“Keep-Alive：timeout = 5”，所以这适合）其中一侧关闭连接并当它再次卡住时，重新建立它并继续发送一些文件。
我用 WireShark 听过，但没有发现任何异常。知道发生了什么事吗？
更新：下面是WireShark日志的截图。它表明在 TCP 连接关闭之后（注意时间），HTTP 连接发送得太晚了。从我的日志来看，它是立即发送的。知道为什么会出现这种差异吗？我应该以某种方式“冲洗”插座吗？我正在使用Python。
In HTTP/1.1 (persistent connections), what is the "signal" which prompts the client to send the next HTTP request? Is there anything else besides Content-Length?
I'm trying to build a simple gateway, which would bridge the TCP traffic across files. I have two apps:
- "server" opens a socket and waits for connections. When the connection is established it forwards everything it gets ot the output file, at the same time forwarding everything from input file back to the socket
- "client" waits for content in the above output file and makes the connection to the server, sends data to it and writes the received data back to the above input file.
In other words: everything I get through socket is redirected through files to another socket, and vice versa.
AFAIK this should be completely transparent, but persistent connections do not work as expected.
I am testing with Firefox - what happens is that FF sends two GETs and receives two responses. But then it just sits there and waits as if it hasn't received all data yet... After 5 seconds (server responds with "Keep-Alive: timeout=5", so this fits) one of the sides closes the connection and reestablishes it and sending continues for a few files, when it gets stuck again.
I have listened with WireShark, but could not spot anything out of ordinary. Any idea what is going on?
UPDATE: below is a screenshot of WireShark log. It shows that the HTTP connection is sent much too late, after TCP connections closes (notice the times). Judging from my logs it was sent right away. Any idea why this discrepancy? Should I "flush" the socket somehow? I'm using Python.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它是内容长度或分块编码（或者如果连接关闭），向客户端“发出信号”数据的长度/结束。
收到 HTTP 数据后，浏览器将 tcp/ip 连接保持打开状态一段时间，以允许通过同一 tcp/ip 连接向同一服务器发出进一步的请求。
It is either Content-Length or Chunked-Encoding (or if the connection is closed) which "signals" the client the length/end of data.
After the HTTP data has been received the browser keeps the tcp/ip connection open for some time to allow further requests to the same server over the same tcp/ip connection.
没有“信号”。客户端准备好后发送下一个请求。
所以它可能还没有收到所有数据。你是在它进来的时候准确地写出来吗？并刷新任何缓冲区？
There is no 'signal'. The client sends the next request when it is ready to do so.
So it probably hasn't received all the data yet. Are you writing it out exactly when it comes in? and flushing any buffers?