一、在Http的时代，大部分是走的RFC 7230中描述的普通代理。这种代理扮演的是“中间人”角色，对于连接到它的客户端来说，它是服务端；对于要连接的服务端来说，它是客户端。它就负责在两端之间来回传送 HTTP 报文。它的流程是：

1、客户端浏览器将请求原封不动的发送给代理服务器

2、代理服务器从HttpHeader中获取目标的主机地址，将请求发送给目标主机

3、目标主机将响应回传给代理服务器

4、代理服务器将响应回传给客户端浏览器。

对于客户端浏览器来说，代理服务器就是目标web服务器。

对于web服务器来说来说，它会把代理当做客户端，完全察觉不到真正客户端的存在。

这种代理服务器实现是比较简单的，基本上是原封不动的透传，主要是第2步，需要从header中识别目标主机地址。

二、到了Https时代，这种方式就有问题了，代理服务器是一个web服务器，它是影响了客户端和服务器的TLS加密连接的。此时主要使用RFC中定义的通过 Web 代理服务器用隧道方式传输基于 TCP 的协议的隧道代理方式，它的主要流程为：

1、浏览器首先发送Http Connect请求给代理服务器，发送目标主机信息。

2、代理服务器建立和目标主机的tcp链接，并向浏览器回应Connection Established应答。

3、浏览器将请求发送给代理服务器，代理服务器透传给目标主机。

4、目标主机将响应回给代理服务器，代理服务器将响应回给浏览器。

这种模式下，和Sock5等代理协议非常类似了，代理服务器完全就是一个透传的管道了。只不过是通过http协议协商建立起管道而已。建立连接后，代理服务器只起转发的作用，理论上也适用于转发其它TCP协议。