正向代理与反向代理

正向代理与反向代理

1、正向代理(forward)是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。客户端必须要进行一些特别的设置才能使用正向代理。

2、反向代理(reverse proxy)正好相反，对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间(name-space)中的内容发送普通请求，接着反向代理将判断向何处(原始服务器)转交请求，并将获得的内容返回给客户端，就像这些内容原本就是它自己的一样。正向代理与反向代理

3、两者区别
从用途上来讲：
正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径，正向代理还可以使用缓冲特性减少网络使用率。
反向代理的典型用途是将防火墙后面的服务器提供给Internet用户访问，反向代理还可以为后端的多台服务器提供负载平衡，或为后端较慢的服务器提供缓冲服务。另外，反向代理还可以启用高级URL策略和管理技术，从而使处于不同web服务器系统的web页面同时存在于同一个URL空间下。
从安全性来讲：
正向代理允许客户端通过它访问任意网站并且隐藏客户端自身，因此你必须采取安全措施以确保仅为经过授权的客户端提供服务。
反向代理对外都是透明的，访问者并不知道自己访问的是一个代理。

而squid是一个forword/reverse proxy，两个功能兼备，一般可以作为局域网的上网缓存，此时作为正向代理。一般服务器会让squid作为前端，那就是充当反向代理，反向代理有很多软件都可以，比如nginx、lighttpd，但他们两个一般做不了正向代理。

4、透明代理（简单代理）：透明代理的意思是客户端根本不需要知道有代理服务器的存在，它改编你的request fields（报文），并会传送真实IP。注意，加密的透明代理则是属于匿名代理，意思是不用设置使用代理了，例如Garden 2程序。

如何使用透明代理

透明代理技术中的透明是指客户端感觉不到代理的存在，不需要在浏览器中设置任何代理，客户只需要设置缺省网关，客户的访问外部网络的数据包被发送到缺省网关，而这时缺省网关运行有一个代理服务器，数据实际上被被重定向到代理服务器的代理端口（如8080），即由本地代理服务器向外请求所需数据然后拷贝给客户端。理论上透明代理可以对任何协议通用。

但是在这种情况下客户端必须正确设置DNS服务器。因为现在浏览器不设置任何代理。则DNS查询必须由browser来解析，也就是要由客户端必须在TCP/IP中设置的正确的DNS服务器，其完成dns解析。

私有网地址为192.168.1.*, 其中客户机是192.168.1.100，防火墙机器网卡是192.168.1.1。透明web代理被安装在防火墙机器上并配置端口为8080。内核使用iptables把与防火墙端口80的连接重定向到代理服务。

5、透明模式的防火墙就好象是一台网桥(非透明的防火墙好象一台路由器)，网络设备(包括主机、路由器、工作站等)和所有计算机的设置(包括IP地址和网关)无须改变，同时解析所有通过它的数据包，既增加了网络的安全性，又降低了用户管理的复杂程度。

防火墙使用透明代理技术，这些代理服务对用户也是透明的，用户意识不到防火墙的存在，便可完成内外网络的通讯。当内部用户需要使用透明代理访问外部资源时，用户不需要进行设置，代理服务器会建立透明的通道，让用户直接与外界通信，这样极大地方便了用户的使用。 一般使用代理服务器时，每个用户需要在客户端程序中指明要使用代理，自行设置Proxy参数(如在浏览器中有专门的设置来指明HTTP或FTP等的代理)。而透明代理服务，用户不需要任何设置就可以使用代理服务器，简化了网络的设置过程。

透明代理的原理如下：假设A为内部网络客户机，B为外部网络服务器，C为防火墙。当A对B有连接请求时，TCP连接请求被防火墙截取并加以监控。截取后当发现连接需要使用代理服务器时，A和C之间首先建立连接，然后防火墙建立相应的代理服务通道与目标B建立连接，由此通过代理服务器建立A 和目标地址B的数据传输途径。从用户的角度看，A和B的连接是直接的，而实际上A 是通过代理服务器C和B建立连接的。反之，当B对A有连接请求时原理相同。由于这些连接过程是自动的，不需要客户端手工配置代理服务器，甚至用户根本不知道代理服务器的存在，因而对用户来说是透明的。

透明代理与透明模式都可以简化防火墙的设置，提高系统安全性。但两者之间也有本质的区别：工作于透明模式的防火墙使用了透明代理的技术，但透明代理并不是透明模式的全部，防火墙在非透明模式中也可以使用透明代理。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/iinel/archive/2009/10/17/4687760.aspx