wireshark分析技巧及案例

 

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，导致客户端对连接失效这个事情并不知情。
 

传输速度慢分析技巧
=======================================================================
个人理解：（理想状态下的最终速度上限）
    TCP的传输速度受接口窗口和拥塞窗口大小的限制；也收到RTT的限制；还受到接收端处理速度的限制
        传输速度 = 接收端的处理速度/RTT
        速度上限是由接收端的处理速度和接收窗口共同决定的
    
    所以可以查看wireshark中的在途字节数，
        若在途数据等于最大的通告窗口，那么速度上限就取决于接收窗口大小or接收端的处理速度
        反之则可能是带宽、发送端发送效率等因素影响发送速度
    
    


很多 TCP 实现里（比如 Windows 系统），确认报文是这样工作的：如果收到连续多个报文，确认报文是一个隔一个回复。
    即每接收2个报文，回复一个ACK

Wireshark 自动找到了被它确认的 16 号报文，也在它的左边打上了一个小小的勾。（wireshark细节）