请教个问题，背压(backpressure)是如何体现在 Webflux 的呢？

[jooks]

我对背压的理解是下游可以控制上游的下发速率。

那么当 Webflux 的收到一个 HTTP 请求后，是怎么控制上游的流速的呢？

或者说 webflux 的背压只是在内部的？

[ymmud]

参考 akka 的，是从 tcp 开始。不知道 webflux 是咋整的

[qwerthhusn]

TCP 协议里面有个滑动窗口机制，如果下面的请求处理不了，WebFlux 就不会再读取数据，这时候 OS 通过调整窗口阻止客户端继续发送数据。我瞎猜的

[frank1256]

这个问题我也想知道，落实到代码的话，调用的是
public interface Subscription {
public void request(long n);
public void cancel();
}
的 request 方法。我理解的应该是在内部代码层面。你是控制不了其他服务给你发 http 的速度的。

[mgcnrx11]

一个 HTTP 一般包含 HTTP Header 头和 HTTP Body 内容体，WebFlux 要处理一个请求，需要先解析（完整读取） Header 头的内容，最起码第一行 URL 地址要读完，这样 WebFlux 才知道要构建一条怎样的 Pipeline 来处理这个请求。

说个简单的情况假设请求的 Body 是一个 JSON 格式的数据，可能 pipeline 流水线就这么简单：

request -> json parser -> response

在构建完 Pipeline 之后，触发 subscribe 的是最下游 response 的 write ，response 响应要知道要写什么内容返回，那就会 request 上游获取完整的请求的 JSON 的数据（这时候可能只是 request(1)，它只需要一个 JSON ），那上游获取 JSON 数据的假设是一个 JSON Parser ，它自己内部应该就可以控制每次请求多少字节的数据来做 parse 了，这里就可以控制 request 每次的量。通过每次的量和次数，就能控制上游 读取 request 的速率了。但是这个读取速率都是从缓冲区读，不能控制对方给你发的速率的，那是 TCP 层的事情了。

[bxb100]

如果你用的是 netty 的话，是通过 tcp 流控制来减速，如果是用 rssocket 的话，是请求端控制

[jooks]

@mgcnrx11 原来如此，这个跟 grpc 有点像，grpc 是控制 http2 的流控窗口