如果您不想在一段时间后等待,则首先不需要排队请求。做到这一点的唯一方法是将 TCP 积压设置为零并希望操作系统配合。
您可能想在这里重新考虑您的应用程序的一些事情。
首先,您可以调整 TCP 积压,但当然请求可能需要任意时间才能完成。因此,如果您只有 1 个请求处理线程并且它很忙,那么客户端将不得不不断地发出请求,直到它可以获得一个空闲线程(因为积压为零)。正在进行的请求完成的时间是不可知的,因此您将不得不重试。
其次,客户端不知道它的请求是在 TCP backlog 中等待还是正在被主动服务,所以它要么必须等到收到响应,要么超时。如果您无法判断请求是否已经开始,您将不会真正知道它是否值得等待。
第三,任何 TCP 连接都可能随时中断或失败。因此,如果服务器收到请求,即使客户端没有得到响应,它也可能会处理它。(如果客户放弃了,这基本上是相同的情况。)
有几种方法可以处理上述情况。
一种方法是使用称为 100-Continue 的 HTTP 功能,其中客户端通过发送请求行和标头(包括Expect: 100-continue
标头但没有请求正文)以及 POST 或 PUT 请求来发出请求。100 Continue
在准备好处理请求之前,服务器不会回复响应代码。如果您在例如 30 秒的窗口内没有收到 a 100 Continue
,则关闭连接,然后......不要继续请求。如果您确实收到了100 Continue
响应,那么您可以发送您的请求正文,其中大概包括实际服务请求所需的所有内容。如果服务器没有收到请求正文,它可能会(有点)优雅地失败,并且请求基本上会被忽略。
服务器检测客户端是否仍然存在的另一种方法是尝试将数据写回客户端。在服务器、操作系统和网络中进行缓冲有时会使这变得不切实际,并且可能会降低您的网络性能(因为必须对响应进行分块才能做到这一点)。如果客户端消失了并且您没有受到操作系统的阻碍,那么您将收到一个 IO 错误并且您的服务器端进程可能会中止。
您可能想要做的另一件事是确保所有(或大部分)进程都是幂等的。基本上,允许对同一事物的重复请求不会成为问题(当然,性能除外)。您可以使用诸如事务令牌或其他一些“可过期”资源之类的东西,这些资源允许客户端一遍又一遍地请求相同的东西,但它只会成功一次。而且,出于您的目的,您希望检查此类令牌的有效性非常快,因此不会导致性能问题。
有很多东西要吞下,但希望里面有一些对你有帮助的东西。