HTTP代理模式学习

强烈推荐下这篇文章，把代理模式说的很清楚了。这里我自己整理了一下并添加了一些其他的内容。

常用的代理技术分为正向代理，反向代理和透明代理。

一、正向代理

正向代理是一个位于客户端【用户A】和原始服务器【服务器B】之间的服务器【代理服务器Z】，为了从原始服务器取得内容，用户A向代理服务器Z发送一个请求并指定目标（服务器B），然后代理服务器Z向服务器B转交请求并将获得的内容返回给客户端。其中原始服务器是不知道有代理服务器的存在的。

主要作用

• 访问本无法访问的服务器B，比如google

• 加速访问服务器B，如下图：

• Cache作用，客户端不必每次都访问服务器B，可以将内容缓存到代理服务器中

• 客户端访问授权，如下图：

• 隐藏访问者的行踪，服务器并不知道访问自己的实际上是客户端还是代理服务器，

二、反向代理

反向代理和正向代理相反，对于客户端而言代理服务器就像是原始服务器，客户端无需做任何处理。

主要作用

• 保护和隐藏原始资源服务器，因为客户端根本不知道自己访问的是代理服务器还是原始服务器

• 负载均衡，当存在多个代理服务器时，更多的用户访问原始服务器，让不同的代理服务器去应答不同的用户。同时这些代理服务器也可以进行缓存，用户无需去源站获取数据，这个也是CDN技术的核心。

三、透明代理

透明代理的意思是客户端根本不需要知道有代理服务器的存在，它改编你的request fields（报文），并会传送真实IP。

用户A和用户B并不知道行为管理设备充当透明代理行为，当用户A或用户B向服务器A或服务器B提交请求的时候，透明代理设备根据自身策略拦截并修改用户A或B的报文，并作为实际的请求方，向服务器A或B发送请求，当接收信息回传，透明代理再根据自身的设置把允许的报文发回至用户A或B，如上图，如果透明代理设置不允许访问服务器B，那么用户A或者用户B就不会得到服务器B的数据。

四、代理模式总结

正向代理中，proxy和client同属一个lan，对server透明。正向代理需要配置在client端；

反向代理中，proxy和server同属一个lan，对client透明，反向代理需要配置在proxy端。

实际上proxy在两种代理中做的事都是代为请求和响应，不过从结构上看正好左右相反，故称为正反向代理。

五、代理的实现方式

普通代理（适用于HTTP）

这种代理扮演的是中间人角色，对于连接他的客户端来说，它是服务端；对于要连接的服务端来说，它是客户端。它就负责在两端之间来回传送HTTP报文。

HTTP客户端向代理发送请求报文，代理服务器需要正确的处理请求和连接（例如正确处理Connection:keep-alive），同时向服务器发送请求，并将收到的响应转发给客户端。

不过使用这种方式是无法访问HTTPS的，因为这种代理的本质是中间人，而 HTTPS 网站的证书认证机制是中间人劫持的克星。普通的 HTTPS 服务中，服务端不验证客户端的证书，中间人可以作为客户端与服务端成功完成 TLS 握手；但是中间人没有证书私钥，无论如何也无法伪造成服务端跟客户端建立 TLS 连接。当然如果你拥有证书私钥，代理证书对应的 HTTPS 网站当然就没问题了。

它和普通的http请求的区别在于

1. 连接的不是目标服务器的IP地址和端口而是代理服务器的IP地址和端口
2. 提交的不是相对地址而是绝对的HTTP地址
3. 请求头部Connection:Keep-Alive和Proxy-Connection:Keey-Alive的区别

为什么需要完整路径

早期的 HTTP 设计中，浏览器直接与单个服务器进行对话，不存在虚拟主机。单个服务器总是知道自己的主机名和对应端口，为了避免冗余，浏览器只需要发送主机名之外的那部分 URI 就行了。代理出现之后，部分 URI 彻底杯具，代理服务器无法得知用户想要访问的URI在什么主机上。为此，HTTP/1.0 要求浏览器为代理请求发送完整的 URI，也就是说规范告诉浏览器的实现者必须这么做。

Connection请求头变成了Proxy-Connection请求头

有一点需要知道的是当客户端和服务端存在一个或多个中间实体（如代理）时，每个请求报文都会从客户端（通常是浏览器）开始，逐跳发给服务器；服务器的响应报文，也会逐跳返回给客户端。通常，即使通过了重重代理，请求头都会原封不动的发给服务器，响应头也会原样被客户端收到。但 Connection，以及 Connection 定义的其它 Header，只是对上个节点和当前节点之间的连接进行说明，必须在报文转给下个节点之前删除。

Connection请求头：

它是对HTTP连接进行说明，常见的值是Keep-Alive，HTTP/1.0 默认不支持持久连接，很多 HTTP/1.0 的浏览器和服务器使用「Keep-Alive」这个自定义说明来协商持久连接：浏览器在请求头里加上 Connection: Keep-Alive，服务端返回同样的内容，这个连接就会被保持供后续使用。对于 HTTP/1.1，Connection: Keep-Alive 已经失去意义了，因为 HTTP/1.1 除了显式地将 Connection 指定为 close，默认都是持久连接。

问题：那些不理解 Connection 首部，而且不知道在沿着转发链路将其发送出去之前，应该将该首部删除的代理。很多老的或简单的代理都是盲中继（blind relay），它们只是将字节从一个连接转发到另一个连接中去，不对 Connection 首部进行特殊的处理。

假设有一个Web 客户端正通过一个作为盲中继使用的哑代理与 Web 服务器进行对话。下图显示的就是这种情形。

1. 上图中 Web 客户端向代理发送了一条报文，其中包含了 Connection: Keep-Alive 首部，如果可能的话请求建立一条 keep-alive 连接。客户端等待响 应，以确定对方是否认可它对 keep-alive 信道的请求
2. 哑代理收到了这条 HTTP 请求，但它并不理解 Connection 首部（只是将其作 为一个扩展首部对待）。代理不知道 keep-alive 是什么意思，因此只是沿着转发 链路将报文一字不漏地发送给服务器。但 Connection 首部是个逐 跳首部，只适用于单条传输链路，不应该沿着传输链路向下传输。
3. 经过中继的 HTTP 请求抵达了 Web 服务器。当 Web 服务器收到 经过代理转发的 Connection: Keep-Alive 首部时，会误以为代理（对服务器 来说，这个代理看起来就和所有其他客户端一样）希望进行 keep-alive 对话！对 Web 服务器来说这没什么问题——它同意进行 keep-alive 对话，并在图c 中 回送了一个 Connection: Keep-Alive 响应首部。所以，此时 Web 服务器认为 它在与代理进行 keep-alive 对话，会遵循 keep-alive 的规则。但代理却对 keepalive 一无所知。
4. 哑代理将 Web 服务器的响应报文回送给客户端，并将来自 Web 服务器的 Connection: Keep-Alive 首部一起传送过去。客户端看到这个首 部，就会认为代理同意进行 keep-alive 对话。所以，此时客户端和服务器都认为 它们在进行 keep-alive 对话，但与它们进行对话的代理却对 keep-alive 一无所知。
5. 由于代理对 keep-alive 一无所知，所以会将收到的所有数据都回送给客户端，然 后等待源端服务器关闭连接。但源端服务器会认为代理已经显式地请求它将连接 保持在打开状态了，所以不会去关闭连接。这样，代理就会挂在那里等待连接的 关闭。
6. 客户端在图 4-15d 中收到了回送的响应报文时，会立即转向下一条请求，在 keepalive 连接上向代理发送另一条请求（参见图e）。而代理并不认为同一条连接 上会有其他请求到来，请求被忽略，浏览器就在这里转圈，不会有任何进展了。
7. 这种错误的通信方式会使浏览器一直处于挂起状态，直到客户端或服务器将连接 超时，并将其关闭为止。

我们看下Proxy-Connection是如何解决上述问题的：

浏览器会向代理发送非标准的 Proxy-Connection 扩展首部，而不是官方支持的著名的 Connection 首部。如果代理是盲中继，它会将无意 义的 Proxy-Connection 首部转发给 Web 服务器，服务器会忽略此首部，不会带 来任何问题。但如果代理是个聪明的代理（能够理解持久连接的握手动作），就用一 个 Connection 首部取代无意义的 Proxy-Connection 首部，然后将其发送给服 务器，以收到预期的效果。

隧道代理（HTTP和HTTPS）

HTTP 客户端通过 CONNECT 方法请求隧道代理创建一条到达任意目的服务器和端口的 TCP 连接，并对客户端和服务器之间的后继数据进行盲转发。

假如我通过代理访问 A 网站，浏览器首先通过 CONNECT 请求，让代理创建一条到 A 网站的 TCP 连接；一旦 TCP 连接建好，代理无脑转发后续流量即可。所以这种代理，理论上适用于任意基于 TCP 的应用层协议，HTTPS 网站使用的 TLS 协议当然也可以。这也是这种代理为什么被称为隧道的原因。对于 HTTPS 来说，客户端透过代理直接跟服务端进行 TLS 握手协商密钥，所以依然是安全的。

CONNECT这个方法的作用就是把服务器作为跳板，让服务器代替用户去访问其他网页，之后把数据原原本本的返回给用户。这也是用来区分正常的HTTPS请求和增加代理的HTTPS请求的不同点之一。

参考：

Http 请求头中的 Proxy-Connection

HTTP 代理原理及实现（一）

《HTTP权威指南》