wireshark分析技巧及案例
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
TTL、IP ID 定位防火墙;NAT 和 TCP Keep-alive 之间的关系 =========================================================================================================================== TTL、IP ID 定位防火墙 通过 TTL 定位防火墙的原理: 本质原因就是这个 IP 报文是防火墙自己构造的,而在构造时 TTL 被设置为了初始值。(接收端收到服务端和防火墙发出的报文,TTL值不同!) 同理,在 IP 层,还有一个IP ID字段。 IP ID 字段占用了 2 个字节,所以它的最大值是 2^16-1,也就是 65535。IP ID 一般是 IP 报文的发起端设置的,每次发包递增 1,然后在 0 到 65535 之间循环使用。 它最主要的用途,是接收端会根据这个 ID 来组装(assemble)同一组 IP 分片(fragments),而中间设备(交换机、路由器)不会改动 IP ID。 并且在防火墙构造 RST 报文的时候,IP 包的 TTL 和 ID 值也是防火墙自己设置的,也就有可能被我们用来发现防火墙。 所以,如果 SYN+ACK 和 RST 的 IP ID 不连续,我们就可以判断出防火墙 注意:Linux 系统发送 SYN+ACK 的时候,IP ID 一定是 0,但是我既在 Wireshark 里看到了这个现象,也在内核代码里证实了这一点。 这就给我们利用 IP ID 带来了障碍:因为即使 RST 真的是对端发出的,两个报文的 IP ID 也会不同。 其实就是在描述这样一种情况:server端回复syn+ack后,马上发送RST,这2个报文的IP ID是不同的 所以,利用 IP ID 的方法,对于 TCP 握手后就发生 RST 的情况并不适用,但对于交互过程中发生 RST 的情况应该是适用的。 ------------------------------------------------------------------------------------------------------------------------------ NAT 和 TCP Keep-alive 之间的关系。 NAT 是维护连接跟踪表的,里面的表项有一定的有效期,过了有效期的表项就会被清空。 而 TCP Keep-alive 正好可以定期去刷新这个计时器,让它“永葆青春”,表项不被删除,这个连接就可以一直愉快地工作下去了。 Chrome 每隔 45 秒的 TCP Keep-alive,主要是起到下面这两个作用: 避免连接被中间环节给撤销掉。一般客户端是在内网里的,出公网的时候 NAT 会转换为公网 IP 跟对端通信。而跟上面的例子类似,为了保持 NAT 表项不被回收,所以 Chrome 要发送保活报文。 避免被服务端认为是无效连接给撤销掉。服务端一般也有 idle timeout 时间,也就是如果一个客户端连接超过一定时间没有报文传送,服务端就会取消这个连接,而且这时很可能不发送 FIN 或者 RST,导致客户端对连接失效这个事情并不知情。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
传输速度慢分析技巧 ======================================================================= 个人理解:(理想状态下的最终速度上限) TCP的传输速度受接口窗口和拥塞窗口大小的限制;也收到RTT的限制;还受到接收端处理速度的限制 传输速度 = 接收端的处理速度/RTT 速度上限是由接收端的处理速度和接收窗口共同决定的 所以可以查看wireshark中的在途字节数, 若在途数据等于最大的通告窗口,那么速度上限就取决于接收窗口大小or接收端的处理速度 反之则可能是带宽、发送端发送效率等因素影响发送速度 很多 TCP 实现里(比如 Windows 系统),确认报文是这样工作的:如果收到连续多个报文,确认报文是一个隔一个回复。 即每接收2个报文,回复一个ACK Wireshark 自动找到了被它确认的 16 号报文,也在它的左边打上了一个小小的勾。(wireshark细节)