本期分享的案例是有线网络的相关问题。
背景介绍
一朋友在是某单位的IT管理，出口路由用的是某P的设备静态公网IP，其一直耿耿于怀，我也不知道为什么。近期发现，远程PC通过互联网访问出口路由器的web管理页面失败，表现为能加载一部分信息，但是没有弹窗登录页面：
于是很高兴地疯狂投诉某P售后，结果人家检查了设备没问题而是线路问题。很不甘心，求助于我，如果是产品问题直接走法律程序赔偿。我不知道为何他执念为何那么深，给他做了简单的排查。
排查分析
第一步：对比测试
原拓扑：
测试结果：PC打开浏览器，通过路由器公网IP+端口号，无法打开路由Web管理页面和登录。
对比拓扑：
测试结果：PC打开浏览器，通过路由器公网IP+端口号，正常打开路由Web管理页面并正常登录
一般情况来讲，正常人到这一步大概差不多了，是否经过ISP运营链路导致的异常其实对比很明显。此人又较真：“路由器接入了宽带后自己功能异常了，兼容性太垃圾，直连PC这种做不得数。需要专业的排障，抓个包看看。”我：“有道理，那就在原拓扑下，抓个包看看”
第二步：报文分析
抓包自然是要抓取链路收尾两端的报文，第一个是远程PC接口报文，第二个是路由器GE1（WAN）口报文，同时比对丢包情况才能分析出问题，如下：
抓取访问Web页面异常时远程笔记本出接口的报文，如下：
可以看到加载部分资源的TCP会话一直SYN重传没有建立起来，并结合浏览器F12调试可分析应该是尝试去加载jpg图片、JS文件资源时握手失败。下面就看看路由器那边有没有收到握手的请求了。
抓取访问Web页面异常时某P路由器出口GE1接口的报文，如下：
发现会话都是正常的，没有异常的会话，说明客户端请求图片、JS资源的TCP SYN请求没有过来。
综合分析：
访问路由器Web页面的部分会话是成功了，但是部分资源会话的请求却没有过来，也就是路由器的GE1接口没有收到，基本确认是中间运营商链路丢包导致。
解决方案
找运营商确认或者更换链路对比试一下，但这老哥觉得我分析可能漏了些细节，欺负他看不懂报文。So，what can i say？朋友们，对于一个品牌你们会有这么大的恶意么？
