自己几年前写的http proxy代理程序一直工作良好,经常不时用一下满足某些上网需求。昨晚偶尔翻了一下程序日志,突然发现了里面大量的程序线程连接错误。
提高日志级别,重新跑一会程序后仔细研究了一下,发现原来ipv6 url已经不知不觉悄然兴起了。以微信程序为例进行分析,在接收聊天、朋友圈的图片、表情包的时候,微信会连接到其mmsns/emoji服务器请求资源。微信首先会通过ipv6 url来发送请求,完整http请求如下:
GET http://[::ffff:183.56.150.156]/wx_emoji/DIkVxibabfH8eHDibw0xNdcExNPYfGekiapG1qq8lrYWuod6JqiaxPpwPlgWhVfSF5Pia/ HTTP/1.1 Host: emoji.qpic.cn Proxy-Connection: keep-alive Accept: */* User-Agent: WeChat/6.3.16.17 CFNetwork/758.5.3 Darwin/15.6.0 Accept-Language: zh-cn Accept-Encoding: gzip, deflate Connection: keep-alive
如上,ipv6文本形式的url格式为http://[ipv6]:port/xxxx。实际上上图中的ipv6地址从后四个字节看仍然是个v4地址。说明微信首先会试探用户环境是否支持ipv6,如果不支持没有响应,微信的兼容性也很好,会立即切换到传统url方式,将ipv6文本形式的url替换为域名,重发http请求:
GET http://emoji.qpic.cn/wx_emoji/DIkVxibabfH8eHDibw0xNdcExNPYfGekiapG1qq8lrYWuod6JqiaxPpwPlgWhVfSF5Pia/ HTTP/1.1 Host: emoji.qpic.cn Proxy-Connection: keep-alive Accept: */* User-Agent: WeChat/6.3.16.17 CFNetwork/758.5.3 Darwin/15.6.0 Accept-Language: zh-cn Accept-Encoding: gzip, deflate Connection: keep-alive
互联网上网络环境迥异,存在大量不计其数的老旧的ipv4 http代理,这些代理服务器遇到ipv6 url就懵了,不能解析和支持。
查明bug后,捋起袖子重新写了一下对ipv6 url的解析支持。
相关标准文档请参考RFC2396、RFC2373。