注：
- 部署不是重点略过
- 本文以网桥模式分析
- 本文仅作简单分析，不到之处还请见谅
<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