使用CONNECT的Squid HTTPS隧道非常慢

我在网络上使用鱿鱼来缓存内容。我使用命令行开关启动chrome，告诉它使用代理。

在大多数情况下，这非常有效，因为鱿鱼会缓存大量内容，并且在用户数量有限的情况下，它的性能很好。

当我访问使用chrome的HTTPS网站时，首页加载非常缓慢。chrome上的状态栏显示“正在等待代理隧道...”。Chrome使用CONNECT动词通过代理建立隧道并与服务器建立HTTPS。随后的页面很快，因为Chrome使连接保持打开状态。

我检查了squid3日志。这是一些CONNECT条目。第二列是以毫秒为单位的响应时间

1416064285.231   2926 192.168.12.10 TCP_MISS/200 0 CONNECT www.google.com:443 - DIRECT/74.125.136.105 -
1416064327.076  49702 192.168.12.10 TCP_MISS/200 1373585 CONNECT r2---sn-q4f7sn7l.googlevideo.com:443 - DIRECT/173.194.141.152 -
1416064345.018  63250 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064372.020  63038 192.168.12.10 TCP_MISS/200 1809 CONNECT www.facebook.com:443 - DIRECT/31.13.91.2 -
1416064393.040  64218 192.168.12.10 TCP_MISS/200 25346 CONNECT clients4.google.com:443 - DIRECT/173.194.32.196 -
1416064408.040  63021 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064408.040  62515 192.168.12.10 TCP_MISS/200 619 CONNECT ssl.gstatic.com:443 - DIRECT/173.194.32.207 -
1416064427.019  90301 192.168.12.10 TCP_MISS/200 2663948 CONNECT r2---sn-q4f7sn7l.googlevideo.com:443 - DIRECT/173.194.141.152 -
1416064429.019  63395 192.168.12.10 TCP_MISS/200 1339 CONNECT clients6.google.com:443 - DIRECT/173.194.32.195 -
1416064439.015  63382 192.168.12.10 TCP_MISS/200 764 CONNECT talkgadget.google.com:443 - DIRECT/173.194.32.199 -
1416064446.896 170270 192.168.12.10 TCP_MISS/200 2352814 CONNECT r20---sn-q4f7dm7z.googlevideo.com:443 - DIRECT/208.117.252.121 -
1416064471.010  62969 192.168.12.10 TCP_MISS/200 516 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064524.010  63389 192.168.12.10 TCP_MISS/200 764 CONNECT talkgadget.google.com:443 - DIRECT/173.194.32.195 -
1416064534.014  63003 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064542.010  63387 192.168.12.10 TCP_MISS/200 2114 CONNECT www.facebook.com:443 - DIRECT/31.13.91.2 -
1416064553.010  63376 192.168.12.10 TCP_MISS/200 470 CONNECT clients4.google.com:443 - DIRECT/173.194.32.194 -
1416064561.010  63379 192.168.12.10 TCP_MISS/200 1807 CONNECT mail.google.com:443 - DIRECT/173.194.32.213 -
1416064597.019  63003 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064600.126      0 192.168.12.10 TCP_DENIED/403 3630 CONNECT www.google-analytics.com:443 - NONE/- text/html
1416064610.122  10959 192.168.12.10 TCP_MISS/200 626 CONNECT avatars0.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.129  10968 192.168.12.10 TCP_MISS/200 576 CONNECT avatars1.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.130  10968 192.168.12.10 TCP_MISS/200 628 CONNECT avatars1.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.130  10967 192.168.12.10 TCP_MISS/200 576 CONNECT avatars1.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.133  10972 192.168.12.10 TCP_MISS/200 576 CONNECT avatars1.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.133  10970 192.168.12.10 TCP_MISS/200 627 CONNECT avatars0.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.135  10972 192.168.12.10 TCP_MISS/200 576 CONNECT avatars3.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.135  10972 192.168.12.10 TCP_MISS/200 628 CONNECT avatars2.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.260  11098 192.168.12.10 TCP_MISS/200 574 CONNECT avatars3.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064610.316  11155 192.168.12.10 TCP_MISS/200 1063 CONNECT avatars3.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064611.722  13327 192.168.12.10 TCP_MISS/200 17113 CONNECT github.com:443 - DIRECT/192.30.252.128 -
1416064619.130  19005 192.168.12.10 TCP_MISS/200 141 CONNECT avatars3.githubusercontent.com:443 - DIRECT/185.31.17.133 -
1416064639.016  95397 192.168.12.10 TCP_MISS/200 1037 CONNECT talkgadget.google.com:443 - DIRECT/173.194.32.194 -
1416064643.210   4739 192.168.12.10 TCP_MISS/200 4085 CONNECT dgafology.com:443 - DIRECT/198.74.52.100 -
1416064662.010  64990 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -
1416064665.219  65086 192.168.12.10 TCP_MISS/200 3851 CONNECT collector.githubapp.com:443 - DIRECT/54.236.179.219 -
1416064685.276   4003 192.168.12.10 TCP_MISS/200 3956 CONNECT qa.sockets.stackexchange.com:443 - DIRECT/198.252.206.25 -
1416064689.142   3750 192.168.12.10 TCP_MISS/200 357 CONNECT qa.sockets.stackexchange.com:443 - DIRECT/198.252.206.25 -
1416064709.014  78381 192.168.12.10 TCP_MISS/200 779 CONNECT clients6.google.com:443 - DIRECT/173.194.32.193 -
1416064721.010  63396 192.168.12.10 TCP_MISS/200 764 CONNECT talkgadget.google.com:443 - DIRECT/173.194.32.193 -
1416064725.013  63001 192.168.12.10 TCP_MISS/200 545 CONNECT mtalk.google.com:5228 - DIRECT/74.125.136.188 -

有些连接需要60000毫秒！

以下是一些GET供比较

1416064691.281     68 192.168.12.10 TCP_MISS/200 412 GET http://serverfault.com/questions/ticks? - DIRECT/198.252.206.16 text/plain
1416064693.492     70 192.168.12.10 TCP_MISS/200 309 GET http://serverfault.com/search/titles? - DIRECT/198.252.206.16 application/json
1416064693.548    126 192.168.12.10 TCP_MISS/200 739 GET http://serverfault.com/content/img/progress-dots.gif - DIRECT/198.252.206.16 image/gif

总体鱿鱼表现出色！但是对于CONNECT来说非常慢。

我发现您可以在命令行中使用echo和nc请求隧道。

我使用这种技术背对背建立了两个连接

ericu@ericu-desktop:~$ echo -e -n 'CONNECT russiatoday.com:443\r\n\r\n' | nc 192.168.12.95 3127
HTTP/1.0 200 Connection established

ericu@ericu-desktop:~$ echo -e -n 'CONNECT russiatoday.com:443\r\n\r\n' | nc 192.168.12.95 3127
HTTP/1.0 200 Connection established

在日志中

1416065033.065   3079 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -
1416065034.090    208 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -

第一个连接耗时3079毫秒，而第二个连接仅耗时208。因此，似乎Squid并不总是很慢。

后来，我再次做同样的事情，但是用来tcpdump捕获来自squid服务器的流量。

1416070989.180    732 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -

如您所见，报告的延迟为732ms。

这是从tcpdump捕获的前3个数据包的输出，这些数据SYN来自我的机器，SYN ACK遥控器和ACK 我的机器。我的理解是，这是建立连接所需的三向握手

11:03:08.973995 IP 192.168.12.95.34778 > 62.213.85.4.443: Flags [S], seq 1280719736, win 14600, options [mss 1460,sackOK,TS val 605181173 ecr 0,nop,wscale 7], length 0
11:03:09.180753 IP 62.213.85.4.443 > 192.168.12.95.34778: Flags [S.], seq 614920595, ack 1280719737, win 14480, options [mss 1460,sackOK,TS val 1284340103 ecr 605181173,nop,wscale 7], length 0
11:03:09.180781 IP 192.168.12.95.34778 > 62.213.85.4.443: Flags [.], ack 1, win 115, options [nop,nop,TS val 605181225 ecr 1284340103], length 0

在该交换中经过的时间为206.8 ms。因此，squid如果我的分析正确，则在此示例中有526毫秒的延迟。额外的〜500 ms的延迟是巨大的。

但是我认为我的分析可能有缺陷，因为CONNECT鱿鱼的“响应时间” 只是衡量隧道保持开放的总时间。

我修改了logformat指令，squid以添加DNS解析时间（以毫秒为单位）。

1416072432.918 580 776 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -
1416072446.823 - 185 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -

第二列是DNS查找时间，第三列是“响应时间”，对于而言可能并不重要CONNECT。该列显示为具有内部DNS缓存，-因为squid。这意味着鱿鱼将其内部DNS缓存用于下一次连接。这解释了第一个页面视图变慢，随后的页面视图变快。这也解释了额外的〜500 ms的延迟。我正在使用在本地主机上运行的bind9转发到ipv4上的Google DNS。如何通过简单的DNS查找获得约500ms的延迟？

nslookup直接使用8.8.8.8 运行并绕过我的本地服务器：

ericu@katz:~$ time nslookup russiatoday.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   russiatoday.com
Address: 62.213.85.4


real    0m0.056s
user    0m0.004s
sys 0m0.008s

这显示整个查询的等待时间为56 ms。对服务器执行Ping操作会导致大约50毫秒的延迟，因此这很有意义。

因此，一些关于squid和bind9不相互同意吗？

https squid

— 埃里克·厄本（Eric Urban）
source

您是在代理服务器与公用网络范围之间还是在桌面设备与代理服务器之间的某个地方运行防火墙？

— Xavier Lucas 2014年

是的，我正在使用另一台计算机iptables作为Internet连接的NAT +防火墙。

— Eric Urban

确保您的规则使用netfilter状态（NEW，ESTABLISHED）来允许流量，而不仅限于ip：port对。一点点tcpdump来查看花费时间肯定会有所帮助（例如，检查DNS请求）。

— Xavier Lucas

仅仅有规则会有什么不同iptables -A chain_name -j ACCEPT。我的意思是肯定的，我可以添加它，但是我不明白为什么这很重要。

— Eric Urban

与测试每个数据包的规则相比，检查现有连接的状态肯定要快得多。以我的经验，如果没有这样的设置，我会看到严重的性能损失。分析问题的最佳方法：tcpdump。

— Xavier Lucas

我知道这是一个老问题，但我遇到了同样的问题，并在squid.conf中使用此问题解决了

dns_v4_first

问候

— 朱利安·皮亚萨（Juliano Piassa）
source

太好了，非常感谢！我一直把这个烦人的问题归咎于Chrome。应该考虑到这一点，因为我的vm上确实存在IPv6网络问题。

— piit79 '17

要点！谢谢。

— Marinos

我认为发布此内容对使用pfSense框运行squid的任何人都将有所帮助。感谢Juliano的回答！同样的设置下可以找到（在pfSense盒）服务> Squid代理服务器>常规的Resolve DNS IPv4 First。以下是屏幕截图。

— 达沙纳格斯
source

-1

我必须设置“ connect_timeout 2.0”，因为它首先尝试ipv6 dns解析，然后在默认的60秒超时后转换为ipv4。

— HawtDogFlvrWtr
source