注:
- 部署不是重点略过
- 本文以网桥模式分析
- 本文仅作简单分析,不到之处还请见谅
<h1>牵引策略</h1>
<h1>数据报文</h1>
PA..n#.........wx%.j...PGET /youku/6568FDE6953478B17ED62775/0300010301559C93F358CD2AA5CFC6C43A51C5-36D9-99EE-1C96-1F326285CD87.flv?nk=410882563736_23941640220&ns=15578400_23115680&special=true HTTP/1.1
Host: 120.37.140.106
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36
X-Requested-With: ShockwaveFlash/18.0.0.194
Accept: /
DNT: 1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6,ja;q=0.4,zh-TW;q=0.2
PA..n#.........wx%.j...PHTTP/1.1 302 Found
Server: httpserver
Location: http://172.16.100.134/youku/6568FDE6953478B17ED62775/0300010301559C93F358CD2AA5CFC6C43A51C5-36D9-99EE-1C96-1F326285CD87.flv?nk=410882563736_23941640220&ns=15578400_23115680&special=true
Content-Length: 0
Connection: close
<h1>分析报文</h1>
- Panabit –> iXCache, UDP端口58888 --> 58888
消息头长度24字节,格式如下
0~1字节固定, 50 41
2字节,(应该是源接口标识,待验证)
3~4 字节变动,如00 6e。分析判断该字段位报顺序号,以自加的方式增长。00 00 70
5~11 字节固定,23 00 01 c1 00 00(包含文件类型等其他特征字段,待验证)
12~15字节为来源地址(主机序),如测试机ip:192.168.2.119 –> c0 a8 02 77
16~19 字节为目的地址(主机序)
20~21字节变动,(可能是来源端口,待验证)
22~23字节固定, 00 50(可能是目的端口,待验证)
注:其中某些未知字段因该包含了VLAN标记,文件类型等牵引策略信息。
- iXCache-> Panabit
消息头长度24字节,格式如下(和1一样的)
总结:PA根据牵引策略封装一些特定GET 请求报文到iXCache, 如果iXCache命中,则返回PA一个302重定向报文,PA向服务器发送关闭连接RST报文,反之不会返回应答报文,同时iXCache也会去服务器取资源。
<h1>附录</h1>
需要如下策略路由才能保证客户机访问到ixcache
实际测试,如果用户和iXCache在同一网段,用户取资源可以不经过panabit NAT直接访问iXCache。如下图,测试用户(192.168.2.119/24)与ixcache(192.168.2.134/24)同网段,且接在同交换机上(可以直接访问)。
iXCache待改进之处:
- 当iXCache没有命中请求资源时,可以直接采用包复制技术,而不是同时去服务器去资源,这会造成出口压力增大。
- 界面统计可以考虑增加测试IP的统计,更加直观。
- 很多视频都是走的UDP或者TCP协议的P2P,如PPWeb协议,导致视频缓存命中率不是太高。可以控制视频的UDP类型的P2P来增加缓存的命中率
- ...
转载请注明来自Candoit www.dpifw.cn