1. http协议请求头
[method] [uri] [version]\r\n
Host: www.example.com\r\n
Connection: keep-alive\r\n
...
\r\n
1.1 第一行的字段为请求的：方法，资源地址，协议版本
http协议常用的请求方法[method]为
- GET：用于向服务器请求数据；
- POST: 用于向服务器提交数据；
- CONNECT: 用于隧道代理;
- HEAD: 用于向服务器请求报头;
资源地址[uri]：一般为URL中去掉域名后剩下的那部分，即浏览器地址栏网址中域名之后的内容。
http协议版本[version]: 目前主流版本有HTTP/1.0和HTTP/1.1。
http请求头中的的换行用的是\r\n, 而非Linux中的换行符\n。以下为一个真实请求头的示例
GET /index.html HTTP/1.1
Host: www.example.com
Connection: keep-alive
1.2 Host字段为请求的主机域名
早期没有虚拟主机的概念，一台服务器有一个主机名。因此规定在请求头的第一行，资源地址只需给出相对地址，不必给出主机名（域名）。但现在一台服务器可能提供多个主机服务，比如一条服务器同时运行了example.com和example.cn两个web站点。只给出相对地址，服务器在收到连接请求后，无法得知该请求是希望与自己哪个web服务建立连接。因此增加了Host字段[1]。
1.3 Connection字段为连接选项
用于对连接进行说明：说明是保持连接还是关闭连接等。
早期的http协议不支持此字段，因此为http提供代理的http代理服务器自然也不支持此字段。如今互联网上比较古老的代理服务器依然存在。为了兼容早期的http代理服务器，在客户端和代理之间又增加了Proxy-Connection字段。关于此字段此处简要介绍。
http代理的实现原理是，代理服务器作为通信中介；客户端把代理当作他想访问的服务器，向代理发送连接轻求。之后代理收到连接请求，向客户端真正想访问的服务器转发此连接请求。
使用http代理的客户端，会主动修改其http请求头，比如浏览器在设置http代理后，会将请求头做出如下修改：
GET http://www.example.com/index.html HTTP/1.1
Host: www.example.com
Proxy-Connection: keep-alive
修改内容主要是请求头第一行的URI, 由相对地址变为绝对地址。原因同Host字段的产生类似，为了让代理能够区分此连接是希望与哪个主机建立连接。但是这里存在一个疑问：既然有了host字段，为什么还要完整地址？我个人给出两个可能的理由：
Host字段出现的更晚，起初是通过完整URI解决虚拟主机的问题，后来提出的Host字段更方便，但为了兼容早期的代理服务器，现在二者同时使用。
Host字段是为了让服务器知道，收到的请求是连接自己的哪个主机。而完整URI是让代理知道客户端向服务器的哪个主机发起连接，二者作用不同。
修改的第二部分是Connection字段，该字段修改为Proxy-Connection。
Proxy-Connection: 用于兼容不支持Connection字段的旧版代理服务器，因为代理服务器默认会将所有未知字段原样转发，而老旧的代理工具不支持Connection选项。当客户端发送Connection: Keep-Alive希望保持连接请求，但是代理无法识别此字段，转发一次数据依然会立即断开连接。虽然服务端收到请求且接受保持连接，但代理却关闭了连接，会导致连接中断。因此代理协议要求将Connection修改为Proxy-Connection，只有识别Proxy-Connection的代理服务器才能将Proxy-Connection转为Connection发给服务端，让服务端保持连接。
2. 隧道代理请求头
2.1 CONNECT方法
隧道代理不同于http代理：http代理是代理服务器作为中介，获取到客户端的数据转发给服务器端，获取到服务端的数据转发给客户端。其通信过程是客户端与代理建立http连接，代理和服务端建立http连接。显然无法用于https通信：因为https是加密协议，代理即使使用https协议代替客户端与服务端通信获取到连接应答数据，也无法使用https加密发送给客户端，因为代理没有服务器的证书。此时退而求其次的方式是，代理到客户端这段转为http通信，可能会降低安全性。当然可以在应用层进行加密，依然能保证安全性。但这样并不是完美的https代理。为了解决此问题，http或者说https增加了CONNECT方法，该方法是请求代理向服务器建立一条隧道通信。该隧道是在TCP层建立，客户端与代理建立一条TCP连接，代理再与服务器建立一条TCP连接。之后客户端和服务端在这条TCP连接之上建立一条https连接。
CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com
建立连接的请求头方法为CONNECT， 地址只需要主机地址，不能再添加具体的资源路径，因为该请求只是用来建立一条连接，连接建立完成才真正请求数据用来通信。
这里说明一下隧道和http直观上的区别：隧道所使用的TCP属于ISO七层网络模型的第4层，而http和https协议处于第7层，所以TCP作为https的底层协议，https并不会察觉代理的存在。举个例子：隧道相当于A向C输送石油，建立了一条A到B的公路，然后建立了一条B到C的公路，之后在这段公路上建立一条A经由B到C的油管。而http代理是建立了一条A到B的公路，然后建立了一条A到B的油管；之后建立了一条B到C的公路，再建立了一条B到C的油管。隧道方式AC是油管直连，http方式在B处要有个储油罐。
3. 移动通信数据代理
3. 1 简述
移动通信提供了wap和net两种网络接入方式，net即直连，和电脑通过网线连接网络没有什么区别。而wap则是通过代理连接，类比电脑通过路由器联网，多台电脑可以共用一个路由器，多部手机也可共用一个代理，这样只需要一个ip地址即可让多个用户实现通信。对运营商而言wap是节省资源的一种方式。所以早期的手机默认都是wap方式，但是这样当一个代理提供接入的用户过多时，可能导致网速下降。这即是网上盛传修改接入点能提高网速的原因。但我个人感觉其实影响不大，因为运营商的代理吞吐能力肯定够高，不会和直连有太大差距。
移动联通的wap接入点代理为10.0.0.127
电信的wap接入点代理为10.0.0.200
接入点代理地址相当于路由器ip：192.168.0.1
3.2 移动接入点cmwap分析[2]
cmwap代理, 在http协议之上增加了扩展字段X-Online-Host；
移动的网关代理和http协议相似，而又同于http代理或隧道代理。
http协议在不使用代理时才使用相对url，与Host字段拼接为绝对地址。
标准的http代理协议是在GET 后添加绝对URL，而非相对URL(http协议在不使用代理时才使用相对url，与Host字段拼接为绝对地址)；
而移动的wap代理GET字段仍是相对URL，但是增加了X-Online-Host字段，通过与X-Online-Host字段拼接为绝对地址。
但是如果GET字段获取到绝对地址，则不再和X-Online-Host字段拼接。
这就产生了下面这个问题：
假设我连接的URL为：http://wap.baidu.com/logo.gif?img=http://wap.uc.cn/uc.png
使用移动网关代理X-Online-Host字段联网：
Conection to 10.0.0.172:80
GET /logo.gif?img=http://wap.uc.cn/uc.png HTTP/1.1
Host: wap.baidu.com
X-Online-Host: wap.baidu.com
早期的移动网络，这样的请求到达移动网关之后，可能会被误发至http://wap.baidu.com/uc.png。但是实际上我们想要请求的是http://wap.baidu.com/logo.gif （?之后表示提交内容）。
因为，移动网关实际上就是一个HTTP的代理服务器，它对于X-Online-Host协议处理如下：
截取请求头中的URL字段：
- 如果URL字段没有域名的话，则将该字段作为相对URI，同X-Online-Host字段进行补全，作为目的地址；
- 如果URL字段有域名的话，则将该字段作为绝对URI，将host替换为X-Online-Host的值。
现在处理方法应该已经完善，不会再出现此问题。
这里可以看到存在3个位置可以出现域名：
请求头第一行方法字段；
Host字段；
X-Online-Host字段；
符和移动网关代理协议的标准请求，应该是方法字段使用无域名的相对地址，Host和X-Online-Host字段使用相同的域名。但是事情往往没有想象的那么美好：如果我修改请求方法用绝对地址，同时Host和X-Online-Host字段使用两个不同的域名，将三个域名设为都不相同。网关收到此数据包会发生什么，直接丢掉异或是三个地址具有某种优先级，选择优先级高的作为目的地址转发？这个就看各自地区的运营商如果制定规则了。
但更有趣的事情不在这里而是下面这个问题，流量费用是由网关统计的，当网关转发目的地址都难以确定时，费用又是如何计算呢？之所以发出这个疑问，是因为有些访问特定主机的流量运营商是不收费的，比如访问运营商官网，又或者现在互联网套餐兴起，各种定向免流数据。也就是说计费也需要知道用户请求的Host地址。那么计费又是根据哪个字段，所用的规则和转发规则是相同的么？我想此处是可以给个否定回答的。转发规则和计费规则是不同的!!!
由此我们就可以顺理成章的提出一个坊间流传多年词汇：免流。相传2012年就有人运用此漏洞修改UC浏览器达到免流的目的。时隔多年，三大运营商或注意到或没注意到，此问题也在一点点修复。但是以此作为基础，免流的手段可以说层出不穷，虽然也在一个个失效。但似乎如同道高一尺魔高一丈般，免流的技术却从未中断。尤其各大互联网套餐的出现，让这淡出视野的东西又浮现出来。当然在这个家家有宽带处处有wifi的今天，还玩免流的是真不多了。玩也不是图省那点流量，就是想装装13。
附：联通大王卡动态免流脚本，需要手机获取root权限，使用RE文件管理器，复制到系统/system/xbin目录执行即可
https://lanzous.com/iat0glg
