multipart/x-mixed-replace 是否等待客户端请求？
我试图弄清楚当服务器发送 multipart/xmixed-replace 响应时是否可以减慢服务器速度。 我希望我的客户尝试限制运动 jpeg 流的速率。 我找到了很多关于服务器在 HTTP 响应中发送什么内容的文档，但没有找到关于客户端发送内容的文档。
客户端在 multipart/x-mixed-replace 响应中的每个部分之后发送什么（如果有的话）？ 如果它不发送任何内容，服务器是否会继续堆积零件？
I'm trying to figure out if it's possible to slow down the server when it's sending multipart/xmixed-replace responses. I want my client to try to rate limit a motion jpeg stream. I've found a lot of documentation about what the server sends in an HTTP response but nothing about what the client sends.
What does the client send, if anything, after each part in a multipart/x-mixed-replace response? If it doesn't send anything, does the server just keep piling on the parts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
实际上，我认为多部分的事情是一个转移注意力的事情，因为多部分的概念只是在同一消息正文中描述内容类型。 因此，从服务器的角度来看（就发送内容的速率而言），它与发送单个大数据块并没有真正的区别。
因此，我想知道是否可以使用 Range 标头仅请求特定范围 - 一次一个“部分”。
从响应标头末尾开始计算字节数。 当您到达第一部分的末尾时，记下读取的字节数并关闭连接。 发送请求
相同的文档，但将起始范围指定为块末尾的字节。 再次阅读响应，当您到达该部分的末尾时，将当前响应字节添加到前一个响应字节，关闭连接并重复令人恶心的操作...
还没有尝试过，但听起来只要服务器支持，它就可以工作范围标头，并提供您能够在客户端进行一些修补的情况。
编写一个通过丢弃数据包来限制速率的客户端代理可能会更容易......
Actually I think the multipart thing is a red herring because the concept of multipart is just to delineate content types within the same message body. So from a server perspective (in terms of the rate at which content is sent) it is not really different from sending a single big chunk of data.
So, I am wondering if you can the Range header to only request a specific range - one "part" at a time.
Start counting bytes from the end of the response headers. When you reach the end of the first part, note the number of bytes read and close the connection. Send a request for
the same document but specify the starting Range as the bytes at the end of chunk. Again, read the response, when you reach the end of the part, add the current response bytes to the previous, close the connection and repeat ad nauseam...
Haven't tried it, but sounds like it would work provided the server supported range headers and provided you were able to do some patching on the client side.
Might be easier to write a client-side proxy that rate limits by dropping packets ...
尝试使用 Mozilla 的 LiveHTTPHeaders 插件。 我访问 Gmail（使用 AJAX）并跟踪客户端和服务器之间的对话几分钟。 看来这可以帮助你。
Try using LiveHTTPHeaders plugin for Mozilla. I went to Gmail (which uses AJAX) and followed the conversation between the client and server for a few minutes. It seems this could help you.
在 HTTP 级别，我认为客户端不会发送任何内容。 服务器假设只要连接打开，它就可以继续发送响应。
我认为没有一个简单的 HTTP 级别的解决方案可以解决这个问题，因为客户端-服务器交换中没有“ack”概念。
显然，这个问题有 TCP-/IP 级别的解决方案。
我想知道当客户端实际收到服务器的响应标头并认识到响应是多部分时是否可以做一些不同的事情 - 然后它是否可以中止连接并打开一个新的非保持活动连接并一一获取各个部分...
At the HTTP level I dont think the client sends anything. The server assumes that as long as the connection is open it can keep sending the response.
I dont think there is an easy HTTP-level solution to the problem because there is no "ack" concept in the client-server exchange.
There are obviously TCP-/IP level solutions to this problem.
I am wondering if the client can do something differently when it actually receives the server's response headers and recognizes that the response is multipart - whether it can then abort the connect and open a new non-keep alive one and just get the parts one by one...