理解 Curl 命令和时间差异

理解 Curl 命令和时间差异

我有一个这样的系统设置 -

互联网 <--------------> (eno1) 公司 A (192.168.151.19)(eth1) <----------> (eth1) 公司 B (192.168.151.15)

eno1 和 eth1 桥接。计算机 B 通过计算机 A 访问互联网

考虑场景 1:

Comp A 上没有防火墙规则。这就像常规的端到端 TLS 连接

对 facebook.com 的 curl 请求需要以下流程 -

sudo SSLKEYLOGFILE=/home/test/FINALDEMO/keylog.txt ./sslkeylog.sh curl -S -k -v -w "@curl-format.txt" --tlsv1.2 https://facebook.com


    time_namelookup:  0.022945
       time_connect:  0.043648
    time_appconnect:  0.117821
   time_pretransfer:  0.117884
      time_redirect:  0.000000
 **time_starttransfer:  0.137791**  (Imp)
       size_download:  0
      size_header:    312
                    ----------
         **time_total:  0.137868**

场景 2:

Comp A 上有一些防火墙规则

  1. 丢弃所有 TLS 应用程序数据包(允许 TLS 握手和更改密码规范)
  2. 当计算机 A 通过 rsync 从计算机 B 接收文件时,允许一对 IP 地址的应用数据包。处理该文件并通过 ipset 添加防火墙规则(从计算机 A 发送的文件包含要添加到防火墙的 ipaddress)

为了实现这两个步骤,我使用 Bash 脚本自动执行。通过rsync 为 0.29 秒平均而言,处理文件和添加防火墙规则所需的时间为0.03 秒

对 facebook.com 的 curl 请求需要以下流程 -

    time_namelookup:  0.010086
       time_connect:  0.024921
    time_appconnect:  0.096774
   time_pretransfer:  0.096860
      time_redirect:  0.000000
 **time_starttransfer:  1.851846**  (Imp)
       size_download:  0
      size_header:    312
                    ----------
         **time_total:  1.851923**

我无法理解这两种场景之间的时间信息差异。在场景 2 中运行脚本和允许数据包连接所花的时间不相符。

有人可以建议更好的调试技术或了解为什么会发生这种情况吗?

编辑 1:在场景 2 中,TLS 应用程序数据包通过 u32 模块丢弃。我使用 u32 模块检查数据包的 TLS 标头,并据此丢弃数据包。

编辑 2:捕获 curl 请求的数据包https://yts.ag在这儿

https://drive.google.com/open?id=0Bz5corUPBatBdXhCZldxUWp6S2c

相关内容