白天是个程序员,晚上就是个有抱负的演员,这是就是我,我住在天朝的陪都。

iXCache&Panabit缓存牵引原理分析

注:

  1. 部署不是重点略过
  2. 本文以网桥模式分析
  3. 本文仅作简单分析,不到之处还请见谅

<h1>牵引策略</h1>
1
<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

Referer: http://v.youku.com/v_show/id_XMTI3OTgwMzI0NA==.html?from=y1.3-idx-uhome-1519-20887.212790-212949.3-1.1-8-1-3-0

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

2

实际测试,如果用户和iXCache在同一网段,用户取资源可以不经过panabit NAT直接访问iXCache。如下图,测试用户(192.168.2.119/24)与ixcache(192.168.2.134/24)同网段,且接在同交换机上(可以直接访问)。

3

iXCache待改进之处:

  • 当iXCache没有命中请求资源时,可以直接采用包复制技术,而不是同时去服务器去资源,这会造成出口压力增大。
  • 界面统计可以考虑增加测试IP的统计,更加直观。
  • 很多视频都是走的UDP或者TCP协议的P2P,如PPWeb协议,导致视频缓存命中率不是太高。可以控制视频的UDP类型的P2P来增加缓存的命中率
  • ...

转载请注明来自Candoit www.dpifw.cn

添加新评论

咻~