• TCP重组问题


    今天问题: vqmon 测试一pcap抓包文件18.pcap。发现实际输出的视频分片信息和抓包不符合。

    ===>pts : 00:00:33 
    Too much data in TCP receive queue
    Too much data in TCP receive queue
    Too much data in TCP receive queue
    Too much data in TCP receive queue
    Too much data in TCP receive queue
    Too much data in TCP receive queue
    Too much data in TCP receive queue
    Too much data in TCP receive queue
    Find segment : url = /youku/6573830471A33761B97894B64/030002070054579E45054304CB019F22D8CB1A-D056-E9D6-D4C7-6BA4A0C62FC1.flv 
    ===>pts : 00:01:35 
    ===> reset 
    Segment Info : program id = 11325996754328884573 segment id = 1 url = /youku/6573830471A33761B97894B64/030002070054579E45054304CB019F22D8CB1A-D056-E9D6-D4C7-6BA4A0C62FC1.flv ip = 112.25.58.53 port = 80 insert time = 1426161953753    size = 14704 duration = 402 download size = 1298 bit rate = 292 begin time = 1426068829170 download time = 3768 rtt = 0    tcp retrans rate = 0.000000 
    mt_vqmon_callback 

    实际wireshark显示:

    vqmon检测输出1298KB, 与 6413KB 不符合!

    vqmon监测的输出Segment Info 是每一个分片的信息,

     download size = 1298 KB 分片下载大小

       download time = 3768 ms 下载时间,从第一个数据包到 最后一个数据包结束(采集完成) 或者到会话关闭。 有时候数据收集很快完成,但会话会超时很久才关闭。

       vqmon监测的输出Segment Info 是每一个分片的信息,


    Too much data in TCP receive queue
    显示 tcp重组出现错误, 一直无法重组完成,包堆积,导致队列溢出,出现 Too much data in TCP receive queue告警。导致33秒后续的报文无法进去分析逻辑,所以显示download size 偏小,应该是统计到

    出错的报文位置。


    出错的包
    读包测试tcp重组输出包,
    static void
    add_from_skb(struct tcp_stream * a_tcp, struct half_stream * rcv,
             struct half_stream * snd,
             u_char *data, int datalen,
             u_int this_seq, char fin, char urg, u_int urg_ptr)
    {
      u_int lost = EXP_SEQ - this_seq;
      int to_copy, to_copy2;
    
      if (urg && after(urg_ptr, EXP_SEQ - 1) &&
          (!rcv->urg_seen || after(urg_ptr, rcv->urg_ptr)))
      {
        rcv->urg_ptr = urg_ptr;
        rcv->urg_seen = 1;
      }
    
     if(a_tcp->addr.source == 49455)
        printf("===>%u 
    ",this_seq - snd->first_data_seq);
    输出相对的seq序号,然后查看pcap报文。


    包1203显示当前seq:1328601, seq_next:1330001

    包1204显示当前seq:1337001, seq_next:1338401,  故 seq 1330001 - 1337001之间报文丢失!应该是丢失 7000字节,4个包。

    当前包1205的 seq:1339801, seq_next:1341201, 故 seq 1338401 - 1339801 之前数据丢失,应该是丢了一个包(1400b)。

    后续报文没有出现重传!

    注意ack=1331401表明这个包已经收到,但是与上面 seq 1330001 - 1337001之间报文丢失!应该是丢失 7000字节,4个包 矛盾。故wireshark已经提示 [TCP ACKed unseen segment].  


    seq 1330001 后面的重组出现问题!  1330001 / 1024 = 1298KB 与vqmon输出值符合。

    此包出现原因: 抓包部分丢失!

    ps:  请求的FLV数据,Follow TCP Stream ,然后另存为是18.flv,用文本编辑器,去掉http头信息,直接到FLV....后,文件是可以播放的。播放了33s直接停掉了。


    此处可以判定另存的文件(即报文重组)有问题。

    一共是6:24s 播放到 33s出问题, 

    两个分片总大小 看content-length

    Content-Range: bytes 3578164-15057252/15057253
    Content-Length: 11479089

    33 / 144 * 15057253  = 3450620 b = 3370Kb   

    大概3M 与 6M 不符合。故有问题。

    2.通过工具flvparse可以查看。

    工具地址:http://blog.csdn.net/leixiaohua1020/article/details/17934487

     0x0083c5 = 33733 ms。

    0x144148  = 1296 kb.

  • 相关阅读:
    rabbitmq系统学习(三)集群架构
    rabbitmq系统学习(二)
    rabbitmq系统学习(一)
    itext实现pdf自动定位合同签订
    itext7知识点研究(PDF编辑)
    itext实现合同尾部签章部分自动添加,定位签名
    ELK实战(Springboot日志输出查找)
    [Wireshark]_002_玩转数据包
    [Wireshark]_001_入门
    [Objective-C] 014_Objective-C 代码规范指南
  • 原文地址:https://www.cnblogs.com/iclk/p/4333082.html
Copyright © 2020-2023  润新知