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

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

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

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

一个 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 层的事情了。

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

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