正向代理与反向代理
正向代理
概念
正向代理是一个位于客户端和目标服务器之间的代理服务器(中间服务器)。为了从原始服务器取得内容，客户端向代理服务器发送一个请求，并且指定目标服务器，之后代理向目标服务器转交并且将获得的内容返回给客户端。正向代理的情况下客户端必须要进行一些特别的设置才能使用。
使用场景
正向代理一般用于为在防火墙内的局域网客户端提供访问 Internet 的途径，如果不采用代理、用户的IP、端口号直接暴露在 Internet（尽管地址转换 NAT ），外部主机依然可以根据IP、端口号来开采主机安全漏洞，所以在企业网，一般都是采用代理服务器访问互联网（相比于千千万万的用户主机，代理服务器数量有限，修补安全漏洞更方便快捷）。
正向代理还可以使用缓冲特性减少网络使用率。
正向代理还有个大家比较了解的用途，那就是俗称的“翻墙”。
反向代理
概念
对于客户端来说，反向代理就好像目标服务器。并且客户端不需要进行任何设置。客户端向反向代理发送请求，接着反向代理判断请求走向何处，并将请求转交给客户端，使得这些内容就好似他自己一样，一次客户端并不会感知到反向代理后面的服务，也因此不需要客户端做任何设置，只需要把反向代理服务器当成真正的服务器就好了。
使用场景
反向代理的作用有很多，除了平常听得比较多的 CDN（缓存静态内容）和负载均衡，还有：保护和隐藏原始资源服务器、加密和SSL加速、压缩、减速上传、安全、外网发布。
总结
- 正向代理代理的对象是客户端，反向代理代理的对象是服务端
- 正向代理隐藏了真实的请求客户端，反向代理隐藏了真实的响应服务器
负载均衡
当系统面临大量用户访问，负载过高的时候，通常会使用增加服务器数量来进行横向扩展，使用集群和负载均衡提高整个系统的处理能力
以下内容摘自《大型网站技术架构：核心原理与案例分析》 6.2 应用服务器集群的伸缩性设计
HTTP 重定向负载均衡
HTTP 重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的 HTTP 请求计算一台真实的 web 服务器地址，并将该地址写入 HTTP 重定向响应中（响应状态码302）返回给用户浏览器。
这种负载均衡的优点是比较简单。缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差；重定向服务器自身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用 HTTP302 响应码重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。因此实践中使用这种方案进行负载均衡的案例并不多见。
DNS 域名解析负载均衡
在 DNS 服务器中配置多个 A 记录，每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样 A 记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。
优点是将负载均衡的工作交给DNS，省掉网站管理维护负载均衡服务器的麻烦，同时许多 DNS 还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样可加快用户访问速度，改善性能。但是也有缺点，就是目前的 DNS 是多级解析，每一级 DNS 都可能缓存 A 记录，当下线某台服务器后，即使修改了 DNS 的 A 记录，要使其生效也需要较长时间。而且 DNS 负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。
事实上，大型网站总是部分使用 DNS 域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供 Web 服务的物理服务器，而是同样提供负载均衡的内部服务器，这组负载均衡服务器再进行负载均衡，将请求分发到真实的 Web 服务器上。
反向代理负载均衡
大多数反向代理服务器同时提供负载均衡的功能，管理一组 Web 服务器，将请求根据负载均衡算法转发到不同 Web 服务器上。Web 服务器处理完成的响应也需要通过反向代理服务器返回给用户。由于 Web 服务器不直接对外提供访问，因此 Web 服务器不需要使用外部IP地址，而反向代理服务器则需要配置双网卡和内部外部两套 IP 地址。
由于反向代理服务器转发请求在 HTTP 协议层面，因此也叫应用层负载均衡。其优点是和反向代理服务器功能集成在一起，部署简单。缺点是反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。
IP 负载均衡
在网络层通过修改请求目标地址进行负载均衡。
用户请求数据包到达负载均衡服务器 114.100.80.10 后，负载均衡服务器在操作系统的内核进程获取网络数据包，根据负载均衡算法计算得到一台真实 Web 服务器 10.0.0.1，然后将数据目的 IP 地址修改为 10.0.0.1，不需要用过用户进程处理。真实 Web 应用服务器处理完成后，响应数据包回到负载均衡服务器， 负载均衡服务器再将数据源地址修改为自身的IP地址（114.100.80.10）发送给用户浏览器。
这里的关键在于真实物理 Web 服务器响应数据包如何返回给负载均衡服务器。一种方案是负载均衡服务器在修改目的 IP 地址的同时修改源地址，将数据包源地址设为自身 IP，即源地址转换（SNAT），这样 Web 服务器的响应会再回到负载均衡服务器；另一种方案是负载均衡服务器同时作为真实物理服务器集群的网关服务器，这样所有响应数据都会到达负载均衡服务器。
IP 负载均衡在内核进程完成数据分发，较反向代理负载均衡（在应用程序中分发数据）有更好的处理性能。但是由于所有请求响应都需要经过负载均衡服务器，集群的最大响应数据吞吐量不得不受制于负载均衡服务器网卡带宽。对于提供下载服务器或者视频服务等需要传输大量数据的网站而言，难以满足需求。能不能让负载均衡服务器只分发请求，而使响应数据从真实物理服务器直接返回给用户呢？
数据链路层负载均衡
指在通信协议的数据链路层修改 mac 地址进行负载均衡。
这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改 IP 地址，只修改目的 mac 地址，通过配置真实服务器集群所有机器虚拟 IP 和负载均衡服务器 IP 地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实物理服务器 IP 和数据请求目的 IP 一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称作直接路由方式（DR）。
使用三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在 Linux 平台上最好的链路层负载均衡开源产品是 LVS （Linux Virtual Server）。
负载均衡算法
轮询（Round Robin,RR）
所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同，适合于所有服务器硬件都相同的场景。
加权轮询（Weighted Round Robin,WRR）
根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重将请求分发到每个服务器，高性能的服务器分配更多请求。
随机（Random）
请求被随机分配到各个应用服务器，在许多场合下，这种方案都很简单实用，因为好的随机数本身就很均衡。即使应用服务器硬件配置不同，也可以实用加权随机算法。
最少连接（Least Connections）
记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上，应该说，这是最符合负载均衡定义的算法。同样，最少连接算法也可以实现加权最好连接。
源地址散列（Source Hashing）
根据请求来源的 IP 地址进行 Hash 计算，得到应用服务器，这样来自同一个 IP 地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，从而实现会话粘滞。
URL 重写
以下内容转自 什么是url重写
URL 重写是拦截客户端传入 Web 请求URL并自动将其定向到到规则指定的 URL 的过程。比如浏览器发来请求 http://blog.mocoder.com/hello.html ，服务器自动将这个请求中定向为http://blog.mocoder.com/test.do?method=hello。
好处：
- 搜索引擎比较喜欢.html,.htm的（与.jsp,.PHP,.aspx,.cff相比），因为.html, .htm是静态的，更容易让引擎了解你网页的内容。而动态网页的内容是根据用户，来输出不同的内容，不容易让引擎吸收具体HTML内容。
- 如果不用URL Rewriting将拓展名隐藏或改成.html，那么假如这个网站要换个技术或把动态页面换成静态，则需要寻找所有含有拓展名的连接，把连接所含URL进行拓展名修改（如从JSP换到php技术，则要寻找所有含有.jsp的页面，并把所有含.jsp的URL改成.php，费时费力）。URL Rewriting正好避免了这点，因为好的URL是能做到“不变应完变”的。
- 防止某些黑客恶意攻击。有些大网站采用不同的技术开发不同功能的页面。而把拓展名改掉，让黑客无法确认此页面用的技术是什么，从而就无从下手。
- 方便访问者使用。访问者不是程序员，他们不明白什么是.jsp,.php.aspx，他们只知道URL。所以统一把拓展名拿掉，或者同意把拓展名换为html,htm，有利于用户的使用。用户可以知道现在在你网站的位置，如何通过输入URL到某一页面。