代理服务器是HTTP协议中一个重要的组件，发挥着重要的作用。 关于HTTP代理的文章有很多，本文不再赘述，如果不清楚的可以看一下
本文主要介绍代理的事例，分析一个真实的案例来帮助理解HTTP代理的原理。
HTTP代理的原理
下面分析一个
http://iflow.uczzd.cn/iflow/api/v1/client_event?app=uc-iflow...经过代理服务器的HTTP请求。
iflow.uczzd.cn的公网IP是140.205.136.82（各地测试到的IP有可能不同），我的局域网IP是192.168.100.115，代理服务器的IP是192.168.16.35。
再简单说一下HTTP请求的流程：
192.168.100.115向140.205.136.82发送HTTP请求,其中192.168.16.35是代理服务器。
一、 监控请求
通过网络监控获取到的HTTP请求如下：
可以看到在网络监控中，有两个HTTP请求，一个是向代理服务器发送的HTTP，另一个是代理服务器想目标服务器发送的HTTP请求。这两个请求的请求体是一样的，如下图：
客户端向代理服务器发送的HTTP报文：
代理服务器想目标服务器发送的HTTP报文：
二、 推测处理流程
可以看到，两张图片的HTTP报文是相同的（也有可能Header不同），我们可以推测出客户端和代理服务器的处理流程，如下：
客户端的处理流程：
代理服务器的处理流程：
三、 验证推测的处理流程
在推测出客户端和代理服务器的处理逻辑后，我们需要验证我们的推测是否正确。
我们可以构造一个TCP请求，客户端连接到代理服务器，发送HTTP报文，报文的内容是客户端直接发送到服务器的内容。
例如：直接访问
http://www.cnblogs.com/tgwang/的HTTP报文是：
GET http://www.cnblogs.com/tgwang/ HTTP/1.1
Host: www.cnblogs.com
Connection: close
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36
Referer: http://www.cnblogs.com/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
Cookie: ***
If-Modified-Since: Sat, 30 Jan 2016 02:48:23 GMT
我们构造一个TCP请求，连接代理服务器，报文的内容也是发送上面的报文，看代理服务器能否正常请求博客园的数据，如果可以正常请求，说明我们对于客户端和代理服务器推测是正确的，如果没有请求博客园数据，而是返回代理服务器的相关信息，表示推测错误。
下面我使用python向代理服务器127.0.0.1:8888发送一个TCP请求，为了在代理服务器中能找到此请求，我在Header中增加了一个Token，使用UUID标识（见红框）。
运行程序，发送TCP请求，报文如下：
查看代理服务器的信息，可知，HTTP请求正常发送到博客园，并且正常响应，如下图：
到此推测验证完成，符合预期结果。
