以下都是我瞎猜的

Http报文三层头部有IP，且Http协议头里面有Host字段，Get字段是资源URI的相对路径，Host和Get字段组合起来可以形成了一个完整的URI。Host字段在Http1.1协议中是必须的，即使为空也必须要有这个字段。但字段里面的值却可以是自己定义的，甚至可以不是正常的主机的名称，后面还可以跟着端口号。另外，在回复报文中是不带HOST字段的。

 

当设置了Http代理的话，发送http请求的时候，三层头部将会填写上http服务器的IP，而在http头里面的Host字段将会填写上真实服务器的DNS或者IP地址。当代理服务器收到请求的时候，将Http报文重组，将Host字段处的URI里面带的Host的信息作DNS解析填写到三层头，再发送到真实的请求服务器上。网络上对于服务器如何反向发送报文没有提到。但可以推测如下：代理服务器记录了这些会话，而真实服务器无法感知原本发给它的请求报文是经过了http服务器的，所以，它只能按照平常的请求一样回复到代理服务器上，并且回复报文里面无法填写HOST字段。当代理服务器收到此报文的时候，可以根据报文中的某个SessionId(可能是三层头里面的，也可能是四层头或者更高层里面的一个字段）来查询自己曾经记录过的转发内容，再把它转发给原来的发送源），这个整个过程类似于NAT的形式。

 

由此种应用方式，引出了一种新的应用：运营商免流。

运营商如何检测出哪些请求是免流的：

运营商只检查Http头部里面的Host字段，如果里面带有的域名在它的白名单里面（或者是对照当前的数字通道开通的情况，加上白名单进行联合判断），就视为免流，不会进行流量统计。根据此原理，可以推断出以下情况：

1. 只对http请求生效，甚至无法对于Https生效

2. 反向报文的免流的原理（暂是不明，但对于免流应用来说，反向的流量反而应该是占用最多的，反向报文中不会带有Host信息，而且运营商应该不会对三层的IP地址进行判断免流（否则在出方向也应该作此判断），另外一个可能是对流进行了判断，当发现出方向符合免流的要求的时候，就直接把这条流ID标记为免流，所以反向就直接判断流ID即可）

 

如果是自己搭建免流的话，需要做到以下几点

1. 本地重组Http报文，将原本要发出去的报文的三层头进行更改，更改为一台自己搭建的代理服务器的IP地址。本地并非所有的应用都支持设置Http代理服务器，那样的话，就需要在本地启动一个代理，拦截所有的Http请求，把报文进行修改。

2. 搭建代理服务器，对于所有入方向的报文，解析出Http报文头，取出Host之后进行DNS解析，再填写到三层头里面，转发出去。

 

从上面来看，这个整个流程就无限类似于一个Http代理服务器。但其实还有可以挖掘的地方。可以把Http协议作为一种承载协议，进行不透明的代理。对于所有的报文都封装成Http请求的内容中的一部分，然后伪装成免流的Http协议头，发送到代理服务器。这台代理服务器是特殊定制的，收到报文之后，解出请求头之后，再修改被承载的协议，修改三层头，再进行转发。这样的话，这种不透明代理就不会再受到协议类型的约束。也许现在的某种免流原理就已经是这种方式了。