91 | 接收用户请求包体的方式

接下来我们看下nginx是怎样接受用户请求的包体的，虽然是由http的核心框架处理的，但是主要是由反向代理模块所使用的。下面看看在反向代理处理过程中，是通过哪些指令控制接收包体的行为。

局部图

在之前的HTTP反向代理流程图，我们看到生成发往上游的http头部及包体之后，这个时候开始读取用户请求的包体，不管是慢慢的读还是先读完再做，都是都去包体的步骤。

接收包体

image.png

on：打开on之后非常依赖nginx的处理能力，而nginx本身处理能力就非常的强。采用on的方式更适合高吞吐量的场景。

off：打开off。

上游可以更快的收到用户发来的请求，而不用去等nginx先收完请求。
上游会更及时的响应。降低nginx读写磁盘的消耗。因为nginx首先需要把用户请求的body写到磁盘中。如果超出内存大小。向上游发放的时候又需要再次读取磁盘。
proxy_next_stream功能失效。因为body还没有收完，一旦开始发送内容的话，再去转换就无能为力了。

image.png

分配client_body_buffer_size大小内存接收包体。根据proxy_buffering的开关决定
是立刻发给上游还是先写到磁盘中，释放内存，用于再次接收用户的响应。

client_body_in_single_buffer :请求的body全部放到内存中。默认是off。如果打开。request_buffer那个变量就可以用了。当然你使用那个变量还有很多的依赖要求。比如这个body不会很大等等。

image.png

默认1m，非常的小，有时候不够用。比如搭建一个WordPress站点时上传一些插件会出现413错误。

临时文件

image.png

client_body_temp_path：很多同学问，为什么搭建完nginx没有找到这个临时文件目录。那是因为nginx还未启动。启动好之后默认创建client_body_temp_path目录。向其中存放临时文件。每个临时文件都是一个很长的整数。通过整数从后向前数。每n位，最后两位可能作为level 1的目录、然后再作为level 2、 level 3。之所以这样做的原因是因为一个目录下不能存放太多的文件。文件太多的话会导致目录存取性能非常慢。linux比windows好很多。如果在windows早期的版本里面，往一个目录中放几千个文件，会发现这个目录几乎都无法操作了。linux好很多，但也不能支持非常大量的文件。所以通过多级子目录的方式能够处理这样的场景。

client_body_in_file_only：默认是关闭的。包体必须存放在文件中。为什么必须存放到文件中呢？因为我们可能要定位问题。这是为定位问题而生的。设置为on，用户所有上传的body都会一直保存到文件中，包括请求处理完毕之后，那个文件一直不会被删除的。默认是会被删除的。clean是用户上传的body必须写入文件。但请求处理完成以后就会被删除了。这跟off有什么不同呢？off表明如果body的长度非常小，以及内存的buffer size已经超过它了。这个时候我们不会记录到文件中的。clean不一样，只要有body一定要写到文件中，只要处理完成，就删除文件。