我发现大多数人将 HTTP 归类为一种短寿命协议。即“发射后不管”。然而，对于 HTTP 1.1 和保持连接，我并不认为情况确实如此。
有人可以确认是否确实如此吗？
答案1
首先，我们需要一个定义。
长寿命协议是指那些旨在无限期保持连接打开的协议。（这种协议的一个例子是 ssh。虽然 ssh 连接可能很短，但它旨在能够永远处于空闲状态，因此该协议是长寿命的。）
短期协议本质上更具事务性；发生特定操作或一系列操作，然后关闭连接。
根据这些定义HTTP 是一种短暂的协议，即使保持活动状态。
事实上，在传输数据时，HTTP 连接可能会保持打开状态几分钟或几小时，但这并不重要。
Keep-Alive 是一种性能优化，旨在允许客户端在短时间内向服务器发出多个请求。服务器必须在一段时间后断开空闲的 Keep-Alive 连接，因为它们只有有限的资源来保持开放端口，而且客户端也不需要它保持开放。
由于 HTTP 无法永远保持打开和空闲状态，并且其设计初衷也不是这样做的，因此它是一种短暂的协议。
答案2
这取决于TM - 一些 HTTP 会话的持续时间为几亿秒，而其他会话（例如下载大型资源或执行缓慢的 REST 调用）的持续时间为几秒或几分钟。由于使用了 keepalive，其他会话的持续时间可能会更长。
所以，我不会说 HTTP 是完全短暂的。
答案3
首先，“发射后不管”的意思并不是你想象的那样。我强烈建议你多读一些这方面的资料，因为这似乎与问题无关。
主题：是的，保持活动确实允许在同一个 TCP 连接中发送多条消息，但通常您不应假设会话只要您想要或需要就会保持打开状态，原因如下：
大多数 Web 服务器都会限制通过一个连接发送的 Keep Alive 请求的最大数量，以及发送后续请求所需的时间。
提高上一点提到的限制将使服务器更容易受到某些类型的拒绝服务和分布式拒绝服务攻击，例如懒猴。
您需要考虑服务器背后的网络设计。例如，许多 REST 服务都位于负载均衡器后面，该负载均衡器将工作负载分配到多个服务器。来自保持活动的 TCP 连接的所有请求不一定都发送到同一个后端，在这种情况下，您不再谈论与后端服务器的真实连接。