终端com域名

知Portal李晨光2013-12-23发表某局点无线Portal认证重定向过程耗时长问题处理经验案例某局点无线某局点无线PortalPortal认证重定向过程耗时长问题处理经验案认证重定向过程耗时长问题处理经验案例例一、组网拓扑:某校园网局点采用了我司WX6000系列高性能无线控制器,管理800多个AP,为校区学生宿舍、读书馆、教室提供无线接入服务,并使用我司IMC做无线Portal认证,AC作为接入BAS:二、问题描述:有学校老师和学生反馈,部分终端概率性出现关联SSID后,打开WEB认证页面过程非常慢的问题,有的甚至需要耗时10秒以上,影响了WLAN网络的使用体验.
但同时,一旦用户Portal认证通过,后续的上网过程就非常流畅了,也即是问题仅仅发生在Portal页面弹出过程.
三、问题定位过程:首先,我们第一直觉是怀疑无线网络质量不佳.
但这一点又和用户反馈的认证通过后网络使用流畅的说法相悖,所以排除这种可能.
其次,由于是学校局点,WLAN业务量大,也可能和Portal服务器性能瓶颈相关.
于是,我们对Portal服务器WEB页面弹出做了测试,即让问题终端绕过AC重定向过程,直接输入Portal认证url,发现页面能非常快的打开,并无卡顿现象,重复多次都未复现问题.
于是排除了imc故障的可能性.
再次,我们协调客户检查了网络中是否有防火墙对WLAN用户做了特殊策略,得到的答复是否定的.
到这里,基本明确该问题与有线网络侧没有关系.
最后,问题点回归到AC上,我们仔细检查了AC状态,包括CPU、内存、日志信息,未见明显异常.
于是,我们开始在终端侧wireshark抓包,并同步在AC上抓取debugportal信息.
问题终于露出端倪.
(1)AC上debugportal信息有报错,显示故障终端有旧TCP连接存在.
*Nov216:53:08:1322013AC-CTCPCHEAT/7/TCPCHEAT_DEBUG:Error:Connectionexist,Srcport:49325,DstIP:50.
19.
209.
45,newSrcport:49326,DstIP:50.
19.
209.
45*Nov216:53:08:1352013AC-CTCPCHEAT/7/TCPCHEAT_DEBUG:SourceMAC=b0aa-36fc-9efdVLAN=112,PortIndex=045000028b31b40004006d3990a0c109c7b7d1df6a6cb00508febf65eb9ad3a6650107210682f0000(2)终端抓包上,看到终端访问nnnn.
com域名的TCP连接请求未收到AC的响应.
同时该终端后台软件(非用户web认证所使用的IE浏览器)访问seapp.
stat.
360safe.
com的连接却被成功重定向.
注意,后台软件的HTTP重定向对用户来说是不察觉的,即用户无法在后台软件中完成Portal认证.
四、定位结论及过程总结:问题根因已明确,原来终端装了360安全管理软件,这款软件会在PC系统的后台运行,并每隔一段时间就向360服务器发送http请求.
设备侧并不能识别这个链接是用户正常的IE浏览器行为的还是终端后台程序行为,所以AC对这个后台访问链接进行了重定向,而一旦这个重定向链接建立,设备IE浏览器正常的web访问就无法同时被AC重定向.

必须等原TCP链接自动老化或者终端主动RST断开链接后才能发起下一次重定向过程.

问题原因总结为,终端后台程序的干扰导致用户的IE浏览器概率性出现需要等待几秒甚至十几秒才能成功重定向.
回顾整个处理过程,我们逐一排除了WLAN网络质量差丢包、Portal服务器性能瓶颈、防火墙故障的可能性,最终通过在终端抓包和AC侧debug找到了问题根因.
并且前期的故障问题点排除过程并未花费过多人力和时间,比较高效率的完成了这个故障定位.