对于后端是动态服务来说，比如Java和PHP。这类服务器（如JBoss和PHP-FPM）的IO处理能力往往不高。Nginx有个好处是它会把Request在读取完整之前buffer住，这样交给后端的就是一个完整的HTTP请求，从而提高后端的效率，而不是断断续续的传递（互联网上连接速度一般比较慢）。同样，Nginx也可以把response给buffer住，同样也是减轻后端的压力。

最高赞回答的点是buffer，这个其实意义不大，应用层的服务器自己也可以开buffer。反向代理的主要作用是分发请求。

首先我们要了解系统的性能瓶颈在哪里，一般来说网络io速度和内存io接近，都远高于磁盘io。假定一个接口请求返回数据100k（一般没有这么大，只是假定一个方便计算的值），10个并发请求就是1M，那么全双工千兆网卡（现在还有万兆网卡，但成本太高，应用还不广），可以支撑并发10000个请求，开双网卡，理论的上限就是20000个并发请求。

假设我们收到请求马上就返回，那么最高并发数就是我们上面计算的结果，但是，问题在于，应用服务器做不到马上返回，因为它有很多业务逻辑需要执行处理，比如给用户发推送发短信发邮件，本地磁盘写日志，请求数据库增删改查，调用的登录接口等等等等，都附加了各个层面的io。

所以第一层的优化，我们会尽量优化应用服务自身，把发推送发短信发邮件的活推到队列，让别的服务器去干。这个一般用内存队列，io很高。

开多线程或者协程的方式异步写日志，但再怎么优化，磁盘io的上限突破不了，这个io很低。还有更激进的方案，干脆日志也写内存，或者通过内网网络同步到别的服务器上，可以更优化。

数据库复用连接池，减少连接和断开的时间开销。查询语句尽量优化，减少等待数据库操作的时间。当然，再怎么优化，一样有个上限。

调用的登录接口等外部接口，这个就更难办了，受制于人，除了tcp连接池复用能稍微优化一点点，完全是取决于外部条件。

木桶理论取最短板，所有这些条件里，总有最慢最落后的那个。假如拖后腿的这个，最佳状态也只能优化到支持2000个并发，那就尴尬了，本来能支持20000个请求的系统，只能用到1/10性能。

（ 当然也可以在dns对应不同ip方式分布请求，但是dns层面的分布更复杂更麻烦，因为dns缓存的原因，请求也不能均匀分布，而且ip地址也是越来越稀缺的资源，没有背景没有后台的，搞这么多ip也不容易啊 ）

单个公网ip算一个节点的话，这个节点本来的潜力是响应20000个并发请求，实际在应用层面只能到2000并发，潜力还未发掘啊。这个时候，就是反向代理起到用武之地的时候了。

首先一个反向代理的服务器抛开所有业务层的东西，只单纯的接下请求再返回，那么可以支持到20000并发了。接下来应用层面谁来处理？找来10个小弟，转发给他们，每人2000正好。这样这个节点系统虽然性价比只有10/11，但是性能潜力好歹挖尽了。

这就是反向代理的作用了。

打个比方来说：

把服务器想象成饭店，没有Nginx的情况，就如同每一个厨师服务一桌顾客，从点菜开始到炒菜到上菜到收银，有n个厨师就只能服务n桌顾客。有了Nginx的话，Nginx就成了强大的服务员，把招呼，点菜、上菜和收银的活都做了，厨师只需要专心炒菜就行。这样饭店的效率就大大提高了。

技术一点的话：

请求如果直接发到同步处理的后端，那么从收到请求到把响应发出去这段时间，一个进程的资源就被占用了（比如Apache的prefork模式）。在慢连接的情况下，这个进程除了处理之外的大多数时间基本上都耗费在了无意义的等待上。Nginx在这方面的优势就在于它的异步非阻塞模型。这意味着Nginx可以通过基于事件的方式同时处理和维护多个请求，而后端就只需要去做逻辑计算，节约了等待时间去处理更多的请求。

单纯的反向代理模式显然并不能提高性能，后端收到的请求数没变，协议也没变，带宽也没有减小，而且如果是默认配置，还会把HTTP/1.1变成HTTP/1.0，反而会降低性能，那些说性能提高的通常也没测过，只是个心理作用而已。

回答这个问题之前，必须先祭出这篇文章：彻底搞懂 Nginx 五大应用场景！出去吹牛逼再也不担心了 ，反向代理是Nginx 5大场景之一。

反向代理：客户端无法感知代理，因为客户端访问网络不需要配置，只要把请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据，然后再返回到客户端。

此时反向代理服务器和目标服务器对外就是一个服务器，暴露的是代理服务器地址，隐藏了真实服务器 IP 地址。

反向代理应该是Nginx使用最多的功能了，反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

简单来说就是真实的服务器不能直接被外部网络访问，所以需要一台代理服务器，而代理服务器能被外部网络访问的同时又跟真实服务器在同一个网络环境，当然也可能是同一台服务器，端口不同而已。

反向代理通过proxy_pass指令来实现。关于Nginx的一些配置的话，不太清楚的可以参阅：

Nginx 常用配置汇总！从入门到干活足矣​mp...com/s?__biz=MzI0MDQ4MTM5NQ==&mid=&idx=1&sn=10e9933f4fc78d48fbe32197d552d0ec&chksm=e918d962de6f50741ecbde462f22bcb3ef38b0231d3437b9a2668a16fe0ccabf&scene=21#wechat_redirect

代理（proxy）设计，可以说是 Nginx 深入骨髓的设计，无论是对于HTTP，还是对于Memcache 、Redis、FastCGI 等的网络请求或响应，本质上都采用了代理机制 。所以，Nginx 天生就是高性能的代理服务器 。

上面讲了反向代理的作用与功能介绍，以及实现配置等。

再返回你说的：如果作为纯粹的反向代理服务器，不做任何缓存，也没有静态文件服务，每一个请求都转发到后端，这样还能提高性能吗？

这个就要看看Nginx处理请求的流程与模式了。

Nginx 是一个高性能的 Web 服务器，能够同时处理大量的并发请求。它结合多进程机制和异步机制 ，异步机制使用的是异步非阻塞方式 ，接下来就给大家介绍一下 Nginx 的多线程机制和异步非阻塞机制 。

1、多进程机制

服务器每当收到一个客户端时，就有 服务器主进程 （ master process ）生成一个 子进程（ worker process ）出来和客户端建立连接进行交互，直到连接断开，该子进程就结束了。

使用进程的好处是各个进程之间相互独立，不需要加锁，减少了使用锁对性能造成影响，同时降低编程的复杂度，降低开发成本。其次，采用独立的进程，可以让进程互相之间不会影响 ，如果一个进程发生异常退出时，其它进程正常工作， master 进程则很快启动新的 worker 进程，确保服务不会中断，从而将风险降到最低。

缺点是操作系统生成一个子进程需要进行 内存复制等操作，在资源和时间上会产生一定的开销。当有大量请求时，会导致系统性能下降 。

2、异步非阻塞机制

每个工作进程 使用 异步非阻塞方式 ，可以处理 多个客户端请求 。

当某个 工作进程 接收到客户端的请求以后，调用 IO 进行处理，如果不能立即得到结果，就去 处理其他请求 （即为 非阻塞 ）；而 客户端 在此期间也 无需等待响应 ，可以去处理其他事情（即为 异步 ）。

当 IO 返回时，就会通知此 工作进程 ；该进程得到通知，暂时 挂起 当前处理的事务去 响应客户端请求 。

更深层次的核心架构剖析可以参阅：浅谈Nginx服务器的内部核心架构设计！

提高的是吞吐量，而不是性能。

原因我就不多说了，我们来看一个使用keepalive实现nginx反向代理高可用的实验。

在网站架构中，为了分散客户端对服务器的访问压力，可以使用nginx作为反向代理。但是使用一个nginx作为代理服务器必定会面对单点故障的情况，所以一般使用多台nginx反代服务器，而使用多台nginx服务器还要面对如何协调调度的问题。在此，我给大家介绍使用keepalive协调调度nginx反代服务器的方法。

keepalive简介

说到keepalive就要说到他的实现核心——VRRP协议。VRRP即虚拟路由器冗余协议，最初是为了解决多个路由器热备份而制定的。它是通过主路由器定时在网络中发送主路由器信息，通知各个备路由器，当备路由器接收不到信息就会通过优先级竞选成为主路由器。

VRRP的优先级范围是0-255，可配置范围1-254，其中0给路由器放弃MASTER位置时候使用，255保留给IP地址的拥有者使用。如果路由器的IP地址为虚拟IP地址时，只要其工作正常，则为MASTER路由器。

VRRP提供了三种认证方式：

1 无认证；

2 简单字符认证：不能超过8个字符；

3 MD5认证。

实验器材

lvs1 Centos7.3 172.18.55.74

lvs2 Centos7.3 172.18.55.75

web1 Centos6.8172.18.55.61

web2 Centos7.3172.18.55.71

实验步骤：

1 安装nginx反向代理服务

2 安装keepalive服务

实验过程：

1 安装nginx反向代理服务

为了简便，这里分别在web1和web2上使用yum源安装的方式

#yum install –y nginx

修改nginx的配置文件

# vim /etc/nginx/nginx.conf

增加服务器组

upstream websvrs { server 172.18.55.61:80; server 172.18.55.71:80; server 127.0.0.1:8080 backup; #sorry Server }

增加sorry server配置

server { listen 8080; root /etc/nginx/html; index sorry.html; location / { } }

增加sorry server页面文件

vim /etc/nginx/html/sorry.html <h1> Sorry !!! <h1>

2 安装keepalive服务

使用yum安装

# yum install –y keepalived

修改配置文件

# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs { notification_email { [email protected] [email protected] [email protected] } notification_email_from [email protected] smtp_server 192.168.200.1 smtp_connect_timeout 30 router_id LVS_MASTER #备服务器LVS_BACKUP vrrp_mcast_group4 224.0.109.55 #组播地址，一个虚拟路由器组设置相同 } vrrp_instance VI_1 { state MASTER #备服务器BACKUP interface ens33 #网卡名 virtual_router_id 155 #虚拟路由器ID，主备设置相同 priority 100 #优先级1-254，备服务器98 advert_int 1 #网络通知时间间隔 authentication { auth_type PASS #认证方式为密码 auth_pass GOOD #密码为GOOD，最多8位 } virtual_ipaddress { 172.18.55.100/16 dev ens33 #指定虚拟IP地址和接口网卡 } track_script { ngxstatus #调用nginx状态监测脚本 } notify_backup "/etc/keepalived/notify.sh backup" #如果nginx的状态改为了BACKUP，则执行此脚本 } vrrp_script ngxstatus { #nginx状态监测脚本 script "killall -0 nginx && exit 0 || exit 1" interval 1 weight -5 }

增加配置nginx重启脚本，省略了非必要步骤

vim /etc/ keepalived/notify.sh #!/bin/bash myservice=nginx.service case $1 in backup) systemctl restart $myservice;; esac

如果nginx 作为纯粹的代理服务器，我不认为对整个网站的性能有所提高，除非nginx 和你的后端是两台不同的服务器。

我们不要相信感觉，让数字来说话。实测了得出数据来比较，才能下定论，性能提高了。

从理论上分析并猜测一下：

假设你的后端是指 apache+php handler ，前面搭一个nginx 作为代理。

nginx 只是将请求转发，后端仍然要面对那么多的请求，没有任何性能上面的帮助，怎么会性能高呢？

而且还nginx 和 apache 还建立了多一次的tcp 连接，在低并发下不会有什么感觉，但在高并发下，性能肯定会下降。

我猜测一下，你的apache 开启了keepalive ，apache 与用户保持连接，apache 也是需要去维护这些连接的，当连接数逐渐高起来的时候，apache 也就吃不消了。而把nginx 假设在前面，nginx 与后端的连接是短连接，也就是，一个请求过去了，apache 返回了就断开了。apache 不再需要维护这些连接，身上的重担少了一块，可以花多一点精力去处理请求了，从而让你感觉到好像快了。

由此我可以得出，你感觉上的性能提升，是可以通过apache 的调优来完成的，与nginx 的代理无关。

反向代理可以提高网站性能？？？这个单机环境下是没啥作用的。在集群环境下，Nginx可以支持负载均衡，使网站获得更好的性能和稳定性。

Nginx的快速， 其实在于Linux上优秀网络模型epoll 的支持

而传统Select模型很低效

反向代理提高网站性能主要通过三个方面：

1，反向代理可以理解为7层应用层的负载均衡，使用负载均衡之后可以非常便捷的横向扩展服务器集群，实现集群整体并发能力、抗压能力的提高。

2，通常反向代理服务器会带有本地Cache功能，通过静态资源的Cache，有效的减少后端服务器所承载的压力，从而提高性能

3，http压缩，开启压缩后，网络流量传输减小，相同带宽下可以服务更多用户

最后还有一个TCP链接复用，不过说实话，如果不是商用的负载均衡器，一般没这个功能。

其实，反向代理还可以有效的隐藏隔离内部服务器，提高了安全性，这也算是提高性能的一个方面吧

可以，因为比如后端单台1000qps，nginx负载均衡10个后端，自然获得接近10000qps的能力，也就提高了性能。这是吞吐量。就时延来看，如果后端在1000qps时时延为1S，2000qps时时延为2S，那么因为用了nginx降低了后端的压力，其时延也会下降，毕竟nginx上消耗的内网时延很小。

nginx源码分析之内存池与线程池更多知识视频：C/C++Linux服务器开发/后台架构师】-学习视频教程

Nginx提高网站性能有几个方面，一个是可以直接操作memcache，redis等缓存，并且可以直接处理静态文件，而且速度还很快

。

二是可以直接跑lua，或许以后会提供直接跑js，php。就是不需要php-fpm，nodejs了，直接在nginx里面跑。我现在后台都用lua，性能比php快很多，不在一个数量级。前端反向代理也好，后端处理也好，全是Nginx。数据库，memcache，redis，静态文件，外部http请求，全部用nginx的子请求实现，利用Nginx的异步模式，性能很好。

三是负载均衡，一个应用请求或许处理很慢，就像银行排队一样，有的人业务很快，有的人要很久，如果你按窗口排队，遇到一个很久才能处理完的，这个窗口排队的人都要等很久，给客户感觉就是性能差。nginx反向代理就像银行叫号器，哪个窗口空去哪里，不会因为个别人办很长的业务影响客户等待时间。而叫号器性能非常好，增加的额外等待时间可以忽略不记。一台普通pc做nginx反向代理，也能同时处理几万请求。而一般的业务服务器只能处理几千。一台nginx反向代理，后端带10台业务服务器，是没啥问题的。业务处理总有些请求是耗时比较久的。如果不用Nginx反向代理，用基于ip的智能dns解析来负载均衡，就会遇到银行窗口排队的问题。

推荐一本书《构建高性能Web站点》

学东西要系统

其实，题主想问的应该是 “Nginx是怎么实现高负载的” ？

首先，题主对此问题的解释，是不对的。“ 1Ngxin＋1后端 ”，是不会对改后端服务有任何改善的；本质原因还是瓶颈就是“1后端”，所以处理能力就是“1后端”；同时，多了一次Nginx一层代理，多了一次TCP链接，所以处理能力甚至小于“1后端”；

所以，题主实际上想要的方案是：“1nginx ＋ n 后端”的方式；

这个问题你首先要明白，不是反向代理提高了性能，反向代理到后端服务器（N台），通过轮询多台后端服务器来提高逻辑处理能力，达到提高系统性能的效果

Nginx很火，因为它就像一个万能药，在任何存在性能需求的场合总能找见它的身影，它可以轻松在百万并发连接下实现高吞吐量的 Web 服务。

从 HTTP 应用层的视角、分布式集群的视角、硬件及操作系统内核优化的视角为大家体系化地解读Nginx 的核心知识，帮助大家从 Nginx 的初级使用者成长为高阶使用者。

找分享：Nginx核心知识100讲,百万并发下的性能优化之道6 赞同 · 0 评论文章

推荐一个非常好用的APP：

轻返APP - 全网生活消费导购平台，网购省钱神器 → 温馨提示：请到各大应用商店搜索「 轻返 」下载安装，官方邀请码：

在没有碰到性能问题前,不建议做这样的架构调整.保持简单,不断优化.

对于配置或架构不合理的后端应用程序，如默认只有100并发的http://asp.net程序，nginx可以在不增加进程数量级的情况下增加并发处理网络的数量，相当于给阻塞式服务套了个非阻塞的壳。

例：一台低配置阿里云，默认配置tomcat和nginx

1、没有nginx2000并发失败。

zhblue@XXXXXX:~$ ab -n 10000 -c 2000

http://127.0.0.1:8080/pm/

This is ApacheBench, Version 2.3 <$Revision:$>

Copyright 1996 Adam Twiss, Zeus Technology Ltd,

http://www.zeustech.net/

Licensed to The Apache Software Foundation,

Welcome to The Apache Software Foundation!

Benchmarking 127.0.0.1 (be patient)

Completed 1000 requests

Completed 2000 requests

Completed 3000 requests

Completed 4000 requests

Completed 5000 requests

Completed 6000 requests

Completed 7000 requests

Completed 8000 requests

Completed 9000 requests

apr_socket_recv: Connection reset by peer (104)

Total of 9701 requests completed

2、加上nginx

zhblue@XXXXXX:~$ ab -n 10000 -c 2000

http://127.0.0.1/pm/

This is ApacheBench, Version 2.3 <$Revision:$>

Copyright 1996 Adam Twiss, Zeus Technology Ltd,

http://www.zeustech.net/

Licensed to The Apache Software Foundation,

Welcome to The Apache Software Foundation!

Benchmarking 127.0.0.1 (be patient)

Completed 1000 requests

Completed 2000 requests

Completed 3000 requests

Completed 4000 requests

Completed 5000 requests

Completed 6000 requests

Completed 7000 requests

Completed 8000 requests

Completed 9000 requests

Completed 10000 requests

Finished 10000 requests

Server Software:nginx/1.4.6

Server Hostname:127.0.0.1

Server Port:80

Document Path:/pm/

Document Length:945 bytes

Concurrency Level:2000

Time taken for tests: 17.208 seconds

Complete requests:10000

Failed requests:21

(Connect: 0, Receive: 0, Length: 21, Exceptions: 0)

Non-2xx responses:21

Total transferred: bytes

HTML transferred:bytes

Requests per second:581.12 [#/sec] (mean)

Time per request: 3441.625 [ms] (mean)

Time per request: 1.721 [ms] (mean, across all concurrent requests)

Transfer rate:673.18 [Kbytes/sec] received

Connection Times (ms)

minmean[+/-sd] median max

Connect:0 3061.30 200

Processing:13 1605 2533.8154 16915

Waiting: 13 1605 2533.8154 16915

Total: 13 1635 2561.2154 17026

Percentage of the requests served within a certain time (ms)

50%154

66% 1103

75% 2185

80% 3020

90% 7012

95% 7409

98% 9738

99%10115

100%17026 (longest request)

非常认同

1、分流请求

2、负载均衡

Nginx的确是大型网站构架的考虑。

我的理解：

1、分流请求

2、负载均衡

在做大型网站构架的时候，才能用得上，你一般的网站也没必要用个好几台服务器吧

我给

@叔度的答案补充一个例子，题目说的是不加缓存，我加缓冲应该还算切题

叔度的答案是2012年写的，2015年我在实习的时候曾经搞过这么一个系统，只说和这个题目相关的部分（其他部分做的太懒不好意思说）

当时后端是一个Tornado + LevelDB 运行在类似树莓派的单板机上，CPU性能比较差，请求大部分都是通过网络来取LevelDB中的一块数据，这个对于单板机并不是一个CPU消耗可以忽略的任务。

对于特定的取数据任务（一次请求总计取出100M的数据，Tornado 做Streaming，每个Chunk 大小4M左右)

当时我设计系统的时候，考虑到Linux的网络协议栈本身有缓冲，而且我用的都是Tornado的异步模式，我就觉得Tornado 把一个Chunk发送给Linux内核，Tornado 的 Handler 的 write 就应该能返回了（考虑到Linux内核缓冲），然后做下一个chunk的读取（CPU性能不足会有一定时间消耗）或者取处理其他请求（考虑到Tornado 异步模型），而且我听很多人说 Tornado 部署一般不再在前面放 nginx 了，我就没放Nginx

然后测试的时候，发现CPU没有占满，读取带宽上不去。这时候我就想到了很久之前看的这个问题下

@叔度的回答

Nginx 反向代理为什么可以提高网站性能？

尝试在Tornado 前面加上 nginx 用 unix socekt 通信，然后nginx 配置了 16M 的响应缓冲，终于把CPU跑满了，读取带宽达到最大。

这个项目当时做的比较仓促，后来也没成功上线，

@武翔宇 和 @gashero 可能对我加nginx这个事情都有印象

后来我才知道，linux 内核给 TCP 的缓冲好像是 Kb 级别，对于我这种一下响应几M的，可能真的还是要等网卡把数据发出去才能callback（随便分析了一下，不一定对）

这个问题根本就不存在。

nginx做反向代理的目标不是提高性能。

馒头不能分开。

一个人吃1个馒头要1分钟。问：两个人吃2个馒头要几分钟？

100个馒头限最短时间吃完，一个人吃更快（撑死）还是100个人吃更快？当你从50个人扩到100人，当然你觉得提高了性能，但是从100个人扩到200个人却没有什么卵用。

看怎么解释“性能”这个词了。

1、分离IO与业务，提高业务效率；

2、实现分流与负载均衡。

你觉得提高了性能，那是因为你用的后端语言处理IO的能力太差，阻塞式io几个慢连接就可能堆死线程池。用golang，前面基本不用nginx，用也不是因为性能。

利用Nginx的缓冲、缓存优化提升性能

使用缓冲释放后端服务器

反向代理的一个问题是代理大量用户时会增加服务器进程的性能冲击影响。在大多数情况下，可以很大程度上能通过利用Nginx的缓冲和缓存功能减轻。

当代理到另一台服务器，两个不同的连接速度会影响客户的体验：

从客户机到Nginx代理的连接。

从Nginx代理到后端服务器的连接。

Nginx具有优化这些连接调整其行为的能力。

如果没有缓冲，数据从代理的服务器发送并立即开始被发送到客户。如果假定客户端很快，缓冲可以关闭而尽快使数据到客户端，有了缓冲，Nginx 代理将暂时存储后端的响应，然后按需供给数据给客户端。如果客户端是缓慢的，允许Nginx服务器关闭到后端的连接。然后，它可以处理数据分配到客户端， 以任何可能的速度。

Nginx默认有缓冲设计，因为客户端往往有很大的不同的连接速度。我们可以用以下指令调节缓冲行为。可以在HTTP，server或 location位置来设置。重要的是要记住，大小size指令是针对每个请求配置的，所以增加超出你需求会影响你的性能，如果这时有许多客户端请求：

proxy_buffering：该指令控制缓冲是否启用。默认情况下，它的值是“on”。

proxy_buffers：该指令控制代理响应缓冲区的数量（第一个参数）和大小（第二个参数）。默认配置是8个缓冲区大小等于一个内存页（4K或者8K）。增加缓冲区的数目可以让你缓冲更多信息。

proxy_buffer_size：从后端服务器的响应头缓冲区大小，它包含headers，和其他部分响应是分开的。该指令设置响应部分的缓冲区大小。默认情况下，它和proxy_buffers是相同的尺寸，但因为这是用于头信息，这通常可以设置为一个较低的值。

proxy_busy_buffers_size：此指令设置标注“client-ready”缓冲区的最大尺寸。而客户端可以一次读取来自一个缓冲区的数据，缓冲被放置在队列中，批量发送到客户端。此指令控制允许是在这种状态下的缓冲空间的大小。

proxy_max_temp_file_size：这是每个请求能用磁盘上临时文件最大大小。这些当上游响应太大不能装配到缓冲区时被创建。

proxy_temp_file_write_size：这是当被代理服务器的响应过大时Nginx一次性写入临时文件的数据量。

proxy_temp_path：当上游服务器的响应过大不能存储到配置的缓冲区域时，Nginx存储临时文件硬盘路径。

正如你所看到的，Nginx提供了相当多的不同的指令来调整缓冲行为。大多数时候，你不必担心太多，但它对于调整一些值可能是有用的。可能最有用的调整是proxy_buffers和proxy_buffer_size指令。

配置代理服务缓存来减少响应时间

尽管缓冲可以帮助释放后端服务器以处理更多的请求，Nginx还提供了一种方法来缓存从后端服务器的内容，对于许多请求无需连接到上游。

配置代理缓存

要设置缓存用于代理内容，我们可以使用proxy_cache_path指令。这将创建区域保存来自被代理服务器返回的数据。该proxy_cache_path指令必须在HTTP上下文部分进行设置。

仅仅「转发」请求到后端服务，nginx 也可以通过 LB 策略影响整站性能分布。

拿异步并发来说事就太扯了，nginx 在并发上的优化只是努力降低 LB 层的损耗而已。

这是横向伸缩

客户,外卖员(饿了吗),饭店 的关系户,外卖员(饿了吗),饭店 的关系

客户点餐(请求),

饿了吗接请求(管你多慢,并发多少,统一报备饭店,因为我能记住,换成人(服务器扛不住)就记不住),

饭店安心做饭，不需要再一会儿接一个订单电话了。

1) 通过后端服务横向扩展,基本可以线性提高吞吐.

2) 若不做静态缓存, 瓶颈还在后端服务.

大并发量的时候（并发数超过一个应用能处理的极限时），能够挺高处理的能力，只能算提高整体性能。

这和它的实现机制有关，nginx和nodejs一样都是基于事件驱动，这就和java很不一样，因为它没有线程池切换所带来的高资源消费，完全靠事件循环来处理，通常一个主进程三个子进程。PHP由于靠apache维持多线程环境，实际上性能也不会太好，不过和nginx集成倒是可以大幅度提高性能。

说那么多，根本就没有直面回答题主问题。

一句话，nginx不能提升网站性能，只会降低，因为增加了网络开销。提升网站性能还是得靠后面默默工作的业务集群

个人感觉主要是负载均衡 以及io速率

好像没有人提到ssl卸载

按照我目前的理解来看，反向代理=负载均衡设备分流Client到Nginx集群

Client感觉不到自己访问的是集群，并不知道自己访问的其实是负载均衡设备……

负载均衡又将流量导流至运行着相同服务的不同服务器~

所以，这个名词- -让我一直非常困惑……

话说- -

我这么绕的回答转的过来嘛~

先说结论：单纯的反向代理不能够提高性能，相反，在一定程度上反向代理会造成整体的性能的损耗。

反向代理的定义：反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。

反向代理的基本功能就是 隐藏原始服务器地址。其解决的是安全的问题。

但目前的主流反向代理服务器还同时兼职做负载均衡，静态文件缓存和动态请求分发，压缩文件，预防DDoS攻击等功能。这些功能都在一定程度上可以提升服务器负载。

还想不通为什么会造成性能损耗可以考虑一个极端的例子，前端一台Nginx做反向代理，链接后端一台Nginx处理静态网页。

nginx反向代理更多是负载均衡用，不会提高性能，因为他只是转发请求到tomcat等。想要提高性能需要优化自己程序或者换更好的硬件。

不会提高，这样做相当于“绕路”了，后端服务器的压力并没有减小。

它可以将请求分发到不同的集群上，然后静态资源自己处理。减轻业务服务器的压力

【网站性能】是什么意思？

反向代理并不能提升性能，但是如果有集群的话反向代理是一种很好的提升扩展性和容错性的方案。

单纯的反代没有均衡复杂的话，只有靠内置的缓存模块提升性能了吧。

nginx比较稳定，可以承担的负载也比较高

如果你后端的服务可以做到和nginx类似当然没有必要用Nginx代理，比如你不会用nginx代理nginx

ng代理一个是做负载均衡后面挂多台机器，或者是一台机器但是后端服务高压力下不能把系统资源用满（CPU，内存）就承担不住压力了，这个时候可以本机启动多个服务用nginx代理，比如tomat,比如单进程的node.js(node估计有其他方案不是很了解哈)

如果你的后端服务是同步IO写的，nginx对客户端提供长连接，到你的服务短链接的话，是有一些效果的。

你去饭店吃饭，一个写菜的服务员后面有一大堆厨师。

nginx就是这个写菜的人，把单子丢给厨房，交给后面的厨师（应用实例）。

因为Nginx 反向代理能够实现IO和业务分离，其次是实现负载均衡，在java和php作为后台服务端，这类服务器的io处理能力有限，这时候可以通过Nginx获取完完整的request后再给服务器后端，同时也可以把response完整的通过Nginx中转，减少在io方面的不必要开支，提高并发量。

反向代理（Reverse Proxy）方式是指以代理服务器来接受客户端的连接请求，然后将请求转发给网络上的web服务器（可能是apache、nginx、tomcat、iis等），并将从web服务器上得到的结果返回给请求连接的客户端，此时代理服务器对外就表现为一个服务器。

在高负载的情况下的PHP-FPM调优

通常性能会降低10-15%。

反向代理这个概念本身不会有任何提高网站性能的效果。

是Nginx本身支持的高并发性能可以让我们轻松接收更多的并发请求。

而反向代理作为服务器端的入口，可以在上面做一些提高性能的事情，比如说负载均衡。

当然我们也可以在后端的统一入口处，做一些其他事情，如配置二级域名、安全措施、压缩结果、缓存等事情，这些事情其中有的也可以提高系统整体的性能。

我的理解只是把压力转移到后端服务器，在单机无法处理所有请求必须通过增加后端服务器来增加处理业务请求的能力，以提高系统的扩展能力

动态内容的网站或者说应用，追到最后瓶颈是在db那，如果qps不高，不用反向代理也没问题。

一般appserver都是用多线程写的，线程开多了系统需要花很多时间在非业务处理上，请求量在增加的时候就容易弄崩溃，或者响应慢，甚至雪崩效应整个系统全崩了，然后用户不断刷新页面，导致继续崩溃

为了防止db崩溃，能用的法子其实并不多，就是加cache，排队。appserver里把db读写请求排队或者从redis读写，nginx之类的也相当于做了一次排队。

nginx，在网络io方面比较好，能一定程度保护后端。

但要是请求超过nginx服务器硬件资源的制约，没辙，只能随机选择用户直接返回静态页面防止后端挂了。

使用nginx做了反向代理后，后端由原来的一台服务器，可以使用N台同时提供服务，速度自然就提升上去了。

不聊场景、不聊配置方式，哪来的正确讨论？

反向代理的用法太多了，只有特定某些用法才能在某些场景下提高并发。

主要原因是使用epoll和kqueue。。。。。。