实际中空闲 HTTP 连接的理想超时长度
在嵌入式设备中，允许空闲 HTTP 连接保持打开状态的实际时间是多少？
我知道在 1999 年左右的网络时代，互联网聊天室有时会保持连接打开并在收到回复时发送回复。在那些日子里，HTTP 连接的空闲超时和会话长度需要更长……
怎么样？今天有ajax之类的吗？
推理：我正在为内存较低的嵌入式系统编写透明代理。我正在寻找防止 DoS 攻击的方法。
我的猜测是3 分钟，或1 分钟。该系统的内存极其有限，即使破坏了罕见和不受欢迎的网站也没关系。
In an embedded device, What is a practical amount time to allow idle HTTP connections to stay open?
I know back in the olden days of the net circa 1999 internet chat rooms would sometimes just hold the connection open and send replies as they came in. Idle timeouts and session length of HTTP connections needed to be longer in those days...
How about today with ajax and such?
REASONING: I am writing a transparent proxy for an embedded system with low memory. I am looking for ways to prevent DoS attacks.
My guess would be 3 minutes, or 1 minute. The system has extremely limited RAM and it's okay if it breaks rare and unpopular sites.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在过去（大约 2000 年），空闲超时标准最多为 5 分钟。如今，它往往是 5秒到 50 秒。 Apache 的默认值为 5 秒。一些特殊应用程序默认为 120 秒。
所以我的假设是，使用 AJAX，不再需要长时间保持打开的 HTTP 连接。
In the old days (about 2000), an idle timeout was up to 5 minutes standard. These days it tends to be 5 seconds to 50 seconds. Apache's default is 5 seconds. With some special apps defaulting to 120 seconds.
So my assumption is, that with AJAX, long held-open HTTP connections are no longer needed.
除非有另一个通信请求到来，否则允许空闲 HTTP 连接保持打开状态怎么样？如果连接打开并且没有其他人尝试通信，则打开的连接不会造成任何损害。如果其他人确实尝试通信，请向第一个连接发送 FIN+ACK 并打开第二个连接。如果可能的话，许多 http 客户端将尝试使用同一连接接收多个文件，但如果需要，可以在文件之间重新连接。
How about allowing idle HTTP connections to remain open unless another communication request comes in? If a connection is open and no one else is trying to communicate, the open connection won't hurt anything. If someone else does try to communicate, send a FIN+ACK to the first connection and open the second. Many http clients will attempt to receive multiple files using the same connection if possible, but can reconnect between files if necessary.