反向代理

目录 下载好nginx Nginx的配置 配置网关 启动/重新加载nginx 不带端口的访问项目 Nginx反向代理的原理 下载好nginx 这里我以windows版本的nginx为例 链接： https://pan.baidu.com/s/1UNsoG7a12Irq--WxC-T3-Q 提取码：vego 下载好之后我们解压出来 Nginx的配置 进入nginx.conf文件中 把server_name的名字改成你自己买的或者你自己配置的本地域名 配置网关 启动/重新加载nginx 在目录中输入cmd，弹出终端 如果我们是第一次启动nginx的话输入 如果我们已经启动了nginx，又像上一步更改了配置文件，这时我们输入命令重新加载nginx nginx -s reload 不带端口的访问项目 首先我们先参照这篇博客，达到可以通过网址+端口号访问本地项目的效果 https://blog.csdn.net/Delicious_Life/article/details/104187969 启动项目，访问效果如下 通过上面的配置，我们已经可以把端口去掉访问了，试试看 Nginx反向代理的原理 来源： CSDN 作者： 刘桐ssss 链接： https://blog.csdn.net/Delicious_Life/article/details/104191750

Nginx是有俄罗斯人伊戈尔·赛索耶夫(Igor Sysoev)为俄罗斯访问量第二的rambler.ru站点开发的轻量级Web服务器，同时也是一个非常高效的反向代理、负载平衡服务器。在性能上，Nginx占用很少的系统资源，能支持更多的并发连接，达到更高的访问效率；在功能上，Nginx是优秀的代理服务器和负载均衡服务器；在安装配置上，Nginx安装简单、配置灵活。 本文主要从正向代理，反向代理和负载均衡三个方面简单介绍Nginx的工作原理。 正向代理 正向代理也可以理解为客户端代理，Nginx代替客户端向明确的服务器发送请求，对于服务器来说客户端完全透明。如上图所示，客户机数量的多少不重要，重要的是客户机一定是知道将要访问的是哪台服务器。而且代理服务器是可以不知道客户机要访问哪里的，代理服务器可以从客户机的请求中解析出目标服务器的地址。 在生活中很多场景都可以形象的展现正向代理的例子。比如客户去某 品牌专卖店购物 ，在客户购买产品这个过程中，专卖店就是个代理的角色。对于客户而言，客户明确指明了购买哪个厂家的具体哪个产品，专卖店需要明确的去这个厂家取货就可以了。上述这样的代理模式称为正向代理。 在软件应用的场景来说FQ最能体现这个正向代理模式。正向代理最大的特点是客户端非常明确要访问的服务器地址；服务器只清楚请求来自哪个代理服务器，而不清楚来自哪个具体的客户端

tinyproxy简单方便，可以用来正向代理，也可以反向代理。 如何使用tinyproxy: 下载安装 yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm yum install tinyproxy -y 修改配置 vi /etc/tinyproxy/tinyproxy.conf 修改端口 Port 8888 允许所有 # Allow 127.0.0.1 反向代理 ReversePath "/" "http://www.apple.com" ReverseOnly Yes 重启服务 systemctl restart tintproxy 来源： https://www.cnblogs.com/kiancyc/p/12263979.html

Python的Web开发中，如果使用Django框架，那么较为成熟稳定的服务器架构一般是Nginx+uWSGI+Django。而为什么一定要三个结合在一起呢？直接使用Django的runserver来启动服务器进程，或者uWSGI+Django可不可以呢？为什么？ 概念说明： APP（应用程序），就是开发者写的应用程序，例如django，bottle这些。记录怎么处理客户端发来的请求的逻辑部分。 WSGI，是一个协议，Python用于Web开发的协议 uWSGI，是一个程序，充当Web服务器或中间件。 如果架构是Nginx+uWSGI+APP，uWSGI是一个中间件 如果架构是uWSGI+APP，uWSGI是一个服务器 uwsgi，是uWSGI程序实现的一个自有的协议。 Web协议出现顺序： CGI -> FCGI -> WSGI -> uwsgi CGI，最早的协议 FCGI，比CGI快 WSGI，Python专用的协议 uwsgi，比FCGI和WSGI都快，是uWSGI项目自有的协议，主要特征是采用二进制来存储数据，之前的协议都是使用字符串，所以在存储空间和解析速度上，都优于字符串型协议. 官方介绍 一、WSGI协议 浏览器请求一个页面的流程： 浏览器发送请求给服务器，包含请求头和请求体 服务器解析请求头和请求体 服务器根据请求信息来处理请求，生成返回内容

Python的Web开发中，如果使用Django框架，那么较为成熟稳定的服务器架构一般是Nginx+uWSGI+Django。而为什么一定要三个结合在一起呢？直接使用Django的runserver来启动服务器进程，或者uWSGI+Django可不可以呢？为什么？ 概念说明： APP（应用程序），就是开发者写的应用程序，例如django，bottle这些。记录怎么处理客户端发来的请求的逻辑部分。 WSGI，是一个协议，Python用于Web开发的协议 uWSGI，是一个程序，充当Web服务器或中间件。 如果架构是Nginx+uWSGI+APP，uWSGI是一个中间件 如果架构是uWSGI+APP，uWSGI是一个服务器 uwsgi，是uWSGI程序实现的一个自有的协议。 Web协议出现顺序： CGI -> FCGI -> WSGI -> uwsgi CGI，最早的协议 FCGI，比CGI快 WSGI，Python专用的协议 uwsgi，比FCGI和WSGI都快，是uWSGI项目自有的协议，主要特征是采用二进制来存储数据，之前的协议都是使用字符串，所以在存储空间和解析速度上，都优于字符串型协议. 官方介绍 一、WSGI协议 浏览器请求一个页面的流程： 浏览器发送请求给服务器，包含请求头和请求体 服务器解析请求头和请求体 服务器根据请求信息来处理请求，生成返回内容

想必大家一定听说过 Nginx，若没听说过它，那么一定听过它的"同行"Apache 吧！ Nginx 的产生 Nginx 同 Apache 一样都是一种 Web 服务器。基于 REST 架构风格，以统一资源描述符（Uniform Resources Identifier）URI 或者统一资源定位符（Uniform Resources Locator）URL 作为沟通依据，通过 HTTP 协议提供各种网络服务。 然而，这些服务器在设计之初受到当时环境的局限，例如当时的用户规模，网络带宽，产品特点等局限并且各自的定位和发展都不尽相同。这也使得各个 Web 服务器有着各自鲜明的特点。 Apache 的发展时期很长，而且是毫无争议的世界第一大服务器。它有着很多优点：稳定、开源、跨平台等等。 它出现的时间太长了，它兴起的年代，互联网产业远远比不上现在。所以它被设计为一个重量级的。 它不支持高并发的服务器。在 Apache 上运行数以万计的并发访问，会导致服务器消耗大量内存。 操作系统对其进行进程或线程间的切换也消耗了大量的 CPU 资源，导致 HTTP 请求的平均响应速度降低。 这些都决定了 Apache 不可能成为高性能 Web 服务器，轻量级高并发服务器 Nginx 就应运而生了。 俄罗斯的工程师 Igor Sysoev，他在为 Rambler Media 工作期间，使用 C 语言开发了

Nginx 反向代理配置示例(conf文件配置) www.aaa.com代理到http://127.0.0.1:3001 server { listen 80; server_name www.aaa.com; #charset koi8-r; #access_log /var/log/nginx/host.access.log main; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_buffering off; proxy_pass http://127.0.0.1:3001; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } } www.bbb.com代理到http://127.0.0.1:3002 server {

1.高并发和大流量 大型互联网需要面对高并发的访问用户，比如在天猫“双11”的时候，一分钟之内，有超过一千万的独立用户访问整个天猫系统，大规模的并发用户访问会对系统的处理能力造成巨大的冲击，系统必须要有足够强的处理能力才能够满足。同时有这么多用户来访问，产生了巨大的访问流量，对系统的抗压能力形成了考验。 高可用 大型互联网系统必须要 7×24 小时不间断地提供服务，和传统软件系统不同，银行或者是电信甚至零售业，它们都有下班时间，下了班以后可以对系统进行停机维护和升级发布，但是互联网没有下班时间，所以一直要保持高可用，7×24 小时永不间断。为了保证系统的高可用，必须要进行特别的系统架构设计。 海量的数据存储 因为互联网需要满足大量的用户使用，所以这些用户会产生很多的数据，需要对这些数据进行重组和管理。除了用户提交的数据，互联网还会采集很多其它的数据，包括一些用户行为的数据、第三方的数据以及网络爬虫获取的数据，通过大数据技术对这些数据做进一步分析，对用户进行更精准的营销和服务，以发现新的业务增长点。 用户分布广泛，网络情况复杂 互联网是为全球用户提供服务的，用户分布范围广，各地的网络情况千差万别，为了使所有用户能够得到统一的良好的体验，需要对系统架构进行相关的设计。 安全环境恶劣 因为互联网是开放的，所以互联网站很容易就会受到攻击。 需求变化快，发布频繁 和传统的软件版本发布频率比

正向代理 （1）正向代理是一个位于客户端和原始服务器(origin server)之间的服务器。 （2）为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。 （3）正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径。 （4）正向代理还可以使用缓冲特性(由mod_cache提供)减少网络使用率。 （5）使用ProxyRequests指令即可激活正向代理。因为正向代理允许客户端通过它访问任意网站并且隐藏客户端自身，因此你必须采取安全措施以确保仅为经过授权的客户端提供服务。 反向代理 （1）反向代理正好相反，对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。 （2）客户端向反向代理的名字空间(name-space)中的内容发送普通请求，接着反向代理将判断向何处(原始服务器)转交请求，并将获得的内容返回给客户端，就像这些内容原本就是它自己的一样。 （3）反向代理的典型用途是将防火墙后面的服务器提供给Internet用户访问。 （4）反向代理还可以为后端的多台服务器提供负载平衡，或为后端较慢的服务器提供缓冲服务。另外，还可以启用高级URL策略和管理技术

David Wheeler有一句名言：“计算机科学中的任何问题，都可以通过加上另一层间接的中间层解决。”为了提高Python网络服务的可移植性，Python社区在PEP 333中提出了Web服务器网关接口(WSGI，Web Server Gateway Interface)。 为了提高Python网络服务的可移植性，Python社区在PEP 333中提出了Web服务器网关接口(WSGI，Web Server Gateway Interface)。 WSGL标准就是添加了一层中间层。通过这一个中间层，用Python编写的HTTP服务就能够与任何Web服务器进行交互了。现在，WSGI已经成为了使用Python进行HTTP操作的标准方法。 按照标准的定义，WSGI应用程序是可以被调用的，并且有两个输入参数。 1、WSGI 下面是第一段代码，第一个参数是environ，用于接收一个字典，字典中提供的键值对是旧式的CGI环境集合的拓展。第二个参数本身也是可以被调用的，习惯上会将其命名为start_response()，WSGI应用程序通过这个参数来声明响应头信息。 # 用WSGI应用形式编写的简单HTTP服务。 #!/usr/bin/env python3 # A simple HTTP service built directly against the low-level WSGI