运维人员经常碰到服务无法正常访问的情况:
示例
类似这种报错很让人头疼。这种应用层的信息不足以定位故障的准确位置 —— 它说连接被重置了,但究竟是谁重置的呢?浏览器也只能建议你尝试检查代理和防火墙。
有没有更精准的定位方法呢?
这里提供一个思路,可以考虑抓取底层报文,从 TTL 上查找端倪。
重置信号的发送者可能性很多,但不同发送者的 TTL 一般是不同的,如果我们能找到这个突破点,就能更精准的定位问题。
运维人员经常碰到服务无法正常访问的情况:
类似这种报错很让人头疼。这种应用层的信息不足以定位故障的准确位置 —— 它说连接被重置了,但究竟是谁重置的呢?浏览器也只能建议你尝试检查代理和防火墙。
有没有更精准的定位方法呢?
这里提供一个思路,可以考虑抓取底层报文,从 TTL 上查找端倪。
重置信号的发送者可能性很多,但不同发送者的 TTL 一般是不同的,如果我们能找到这个突破点,就能更精准的定位问题。