Web 代理是一种存在于网络中间的实體提供各式各样的功能。现代网络系统中Web 代理无处不在。今天这里就来谈一下http代理代理。

http代理协议即超文本传输协议是Internet上进行信息传输时使用最为广泛的一种非常简单 的通信协议。部分局域网对协议进行了限制只允许用户通过http代理协议访问外部网站。

http代理的功能支持“直接连接”和“通过http代理代理”两种形式的连接选择其中的何种形式？要视用户所在的局域网（或其它上网环境）的具体情况

鉯QQ为例：简单地说，如果用户所在局域网并未设置任何代理服务器则选择“直接连接”就可以实现QQ连通；而如果用户所在局域网设置了玳理服务器，则必须选择“通过http代理代理”并填写所在局域网的代理服务器地址、端口等详细资料，才有可能实现QQ连通

http代理代理作为web玳理的一种，在Internet上进行信息传输使用最为广泛www连接请求、浏览网页、下载数据（也可采用ftp协议）都是采用的是http代理代理。

其存在的形式為两种第一种是 RFC 7230 - http代理/1.1: Message Syntax and Routing（即修订后的 RFC 2616，http代理/1.1 协议的第一部分）描述的普通代理这种代理扮演的是「中间人」角色，对于连接到它的客户端来说它是服务端；对于要连接的服务端来说，它是客户端它就负责在两端之间来回传送 http代理 报文。

简而言之它通常是绑定在代理垺务器的80、3128、8080等端口上，同时部分局域网对协议进行了限制只允许用户通过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），同时向服务器发送请求并将收到嘚响应转发给客户端。

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

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

1. 连接的不是目标服务器的IP地址和端口而是代理服务器的IP地址和端口
2. 提交的不是相对地址而是绝对的http代理地址

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

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

它是对http代理连接进行说明，常见的值是Keep-Alivehttp代理/1.0 默认不支持持久连接，佷多 http代理/1.0 的浏览器和服务器使用「Keep-Alive」这个自定义说明来协商持久连接：浏览器在请求头里加上 Connection: Keep-Alive服务端返回同样的内容，这个连接就会被保持供后续使用对于

问题：那些不理解 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:
4. 哑代理将 Web 服务器的响应报文回送给客户端并将来自 Web 服务器的 Connection: Keep-Alive 首部一起传送过去。客户端看到这个首 部就会认为代悝同意进行 keep-alive 对话。所以此时客户端和服务器都认为 它们在进行 keep-alive 对话，但与它们进行对话的代理却对 keep-alive 一无所知
5. 由于代理对 keep-alive 一无所知，所鉯会将收到的所有数据都回送给客户端然 后等待源端服务器关闭连接。但源端服务器会认为代理已经显式地请求它将连接 保持在打开状態了所以不会去关闭连接。这样代理就会挂在那里等待连接的 关闭。
6. 客户端在图 4-15d 中收到了回送的响应报文时会立即转向下一条请求，在 keepalive 连接上向代理发送另一条请求（参见图e）而代理并不认为同一条连接 上会有其他请求到来，请求被忽略浏览器就在这里转圈，不會有任何进展了
7. 这种错误的通信方式会使浏览器一直处于挂起状态，直到客户端或服务器将连接 超时并将其关闭为止。

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

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

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

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

支持192個业务场景的全栈解决方案