我正在尝试使用 WebSockets 作为应用程序协议（这里没有浏览器），并且遇到了流量控制问题...... 我目前正在使用带有WebSocketServlet和@WebSocket的Jetty 9.1.0.RC0。
第一种情况是消息的传入速度超过了我的处理速度。 在这种情况下，我想暂停从该套接字读取，让 TCP 背压发挥作用。 这在以前的应用程序（当然是非 websocket）中效果很好。 我认为 Session.suspend（） 可能会做我想做的事，但它似乎没有影响，并且返回的令牌为 null。
有没有办法怀疑阅读？ 由于它是一个基于 nio 的连接器，Jetty 将继续读取帧并缓冲它们，直到我可以处理它们，我宁愿暂停阅读也不必引入一些流控制消息。
我的第二种情况是我将 websocket 消息发送到连接的客户端 - 这可能是一个浏览器，但并非总是如此...... 看起来我可以通过使用 sendStringByFuture 方法获得一些流量控制，但是有没有办法在未来完成后获得回调，而不必等待或轮询它？
由于我已经嵌入了 jetty 并将其用于 SpringMVC，如果我能在上面获得我需要的流量控制，以避免在另一个端口上运行像 Netty 这样的东西，那就太好了。
谢谢。
Jetty 和 JSR API 确实具有 aysnchronous 回调的写入风格。 在码头是： sendBytes（ByteBuffer data， WriteCallback callback）JSR API 是： sendBinary（ByteBuffer data， SendHandler handler）
两者都具有文本消息等效项。 但是这两者都存在一些问题。 首先，如果回调用于流量控制，则回调将"在消息传输时收到通知"。 这对于高吞吐量来说不是最佳的，因为这意味着下一条消息的发送将始终等到前一条消息被传输，从而没有机会将多条消息聚合为单个写入。
如果后续对 sentBytes 或 sendBinary 的调用不等待回调，那么它们可以将多个帧排队，这些帧将被有效传输，但问题是发送时没有背压，因此内部队列可能会永远增长。
一种"解决方案"是队列大小有限，但随后您会遇到所谓的异步调用 sendBytes 突然阻塞的问题！
我认为解决方案是使用另一种形式的回调，用于在消息排队等待传输但未实际传输后调用的发送。 一旦调用了这个回调，那么任何传递的缓冲区都可以被重用/回收，并且可以进行另一个调用和另一个调用sendBytes/sendBinary。
也许像这样：
公共接口 QueuedWriteCallback 扩展 WriteCallback { 写队列（）; }
对于 JSR：
公共接口 QueuedSendHandler 扩展 SendHandler { onQueued（）; }