struct timeval二次循环返回0的原因排查与解决方法

核心问题可能的根源 #

• 时间变量未重置：如果循环内没有在每次测试前重新调用gettimeofday记录起始时间，第二次循环会用上一轮的结束时间作为起点，直接导致时间差为0。
• TCP连接/缓存复用：若测试后未彻底关闭socket，后续循环可能复用已有连接或读取缓存中的数据，实际传输耗时趋近于0。
• 时间差计算逻辑漏洞：计算秒和微秒差值时，未处理微秒为负的情况（比如结束时间的微秒数小于起始时间），导致计算结果异常。

分步排查方案 #

1. 强制重置计时起点
   每次切换拥塞控制算法、开始接收文件前，必须重新初始化时间变量：

   struct timeval start, end;
   // 每次测试前重新获取起始时间
   gettimeofday(&start, NULL);
   // 执行接收逻辑
   receive_segment();
   gettimeofday(&end, NULL);
   

2. 确保socket完全销毁
   每次测试循环结束后，调用close()关闭客户端和服务端的socket，下一轮循环重新建立全新连接，避免缓存或连接复用干扰测试结果。

3. 修复时间差计算逻辑
   处理微秒借位问题，保证时间差计算准确：

   long sec_diff = end.tv_sec - start.tv_sec;
   long usec_diff = end.tv_usec - start.tv_usec;
   if (usec_diff < 0) {
       sec_diff--;
       usec_diff += 1000000;
   }
   double elapsed = sec_diff + (double)usec_diff / 1000000;
   

4. 验证拥塞控制算法切换生效
   切换算法后，通过setsockopt返回值或系统命令sysctl net.ipv4.tcp_congestion_control确认当前生效的算法，避免因切换失败导致两次测试无差异。

5. 添加调试输出
   打印每次测试的start和end的tv_sec、tv_usec具体值，直接判断是计时逻辑问题还是实际传输耗时为0。

额外优化建议 #

• 使用更大的测试文件，避免因传输过快导致时间差被截断为0。
• 循环之间增加1-2秒延迟，让网络状态恢复稳定，消除前一次测试的残留影响。

内容的提问来源于stack exchange，提问作者Dolev Dublon