共计 1736 个字符，预计需要花费 5 分钟才能阅读完成。
代理（Proxy）也称网络代理，是一种非凡的网络服务，容许一个（个别为客户端）通过这个服务与另一个网络终端（个别为服务器）进行非间接的连贯。一些网关、路由器等网络设备具备网络代理性能。个别认为代理服务有利于保障网络终端的隐衷或平安，避免攻打。
HTTP 协定中，容许通过中间人（Intermediaries）来实现申请，“中间人”的交互流程，如下图所示：
客户端本来发送给指标服务的报文，当初会发送给中间人，由中间人转发到指标服务器；当指标服务器返回后，中间人会将报文发送给客户端
HTTP 代理常见的利用场景有：伪造申请起源，绕过某些网络限度（你懂），抓包等等。
HTTP 代理
这种“转发”模式的代理，工作原理很简略：当开启代理后，HTTP 首部报文会批改为残缺 URL，代理服务器就会从 HTTP Request 报文中解析第一行的指标服务信息，比方：
# 未开启代理时的首行报文
GET /v-5fc4b0fa/global/img/logo-b.svg HTTP/1.1
# 开启代理后，发送的首行报文
GET http://cdn.segmentfault.com/v-5fc4b0fa/global/img/logo-b.svg HTTP/1.1那么该申请的指标服务就是cdn.segmentfault.com 8080，此时收到音讯的 Proxy Server 会连贯到指标服务器cdn.segmentfault.com 8080，而后将收到的客户端报文发送到指标服务器，同时将收到的指标服务器报文转发给客户端
至于是收到残缺的 HTTP 报文才转发，还是每收到一个分组就转发，HTTP 协定中并没有看到相干的标准
HTTP 隧道代理（Tunnel）
隧道代理次要是为了 SSL(TLS)提供的，因为下面介绍的一般代理无奈作为 HTTPS 的代理，HTTPS 协定下会加密数据，所以解析报文头这一步就无奈工作了
在隧道代理下，和指标服务进行 SSL 握手的过程会交由代理服务器实现，代理服务还是会转发客户端发送和指标服务返回的每一个分组报文。
隧道代理（HTTPS）下，客户端首先会发送一个 CONNECT 类型的首行报文，如下所示：
CONNECT home.netscape.com:443 HTTP/1.1
User-agent: Mozilla/4.0
...隧道代理服务收到首部报文后，会解析 CONNECT 信息，从中获取指标服务的地址（主机 + 端口），用来和指标主机建设连贯（SSL 握手），当连贯建设实现后像客户端发送一段连贯建设胜利的报文：
HTTP/1.1 200 Connection Established当客户端收到代理服务返回的连贯建设胜利报文时，就会进行 SSL(TLS)握手 /HTTP 报文加密传输等工作，对于隧道代理服务来说，实现了 CONNECT 首部解析和返回连贯建设胜利报文之后就没有非凡工作了，只须要将客户端发送的报文间接转发给指标服务器，同时将收到的指标服务器报文转发给客户端。
在这个过程里，SSL(TLS)握手过程还是由客户端实现的，隧道代理服务并不关怀握手的细节，它只是自觉的转发报文
Socks 代理
Socks 代理尽管也能够作为 HTTP 的代理，然而它自身并不是面向 HTTP 协定的，可参考
https://zh.wikipedia.org/zh-hans/SOCKS
基于 Netty 的 HTTP Proxy Server 实现
https://github.com/kongwu-/netty-proxy-server
根本实现，只实现了外围的 proxy 性能，keepAlive 之类的并没有解决
参考
- HTTP tunnel – Wikipedia
- https://github.com/luizluca/bridge
- Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing – ietf
- Tunneling TCP based protocols through Web proxy servers – ietf
- https://www.ietf.org/rfc/rfc2068.txt
- https://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html