使用CONNECT的Squid HTTPS隧道非常缓慢

我在networking上使用鱿鱼来caching内容。 我用命令行开关启动chrome,告诉它使用代理。

在大多数情况下,这个工作很好,因为鱿鱼caching大量的内容和有限的用户数量performance良好。

当我访问使用chrome的HTTPS网站时,第一页加载非常缓慢。 Chrome上的状态栏显示“正在等待代理隧道…”。 Chrome使用CONNECT谓词通过代理进行隧道连接,并与服务器build立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 

整体鱿鱼performance非常好! 但是对于CONNECT来说非常慢。

我发现你可以使用echonc来从命令行请求一个通道。

我使用这种技术来连接两个连接

 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次。所以,鱿鱼似乎并不总是很慢。

后来,我又做了同样的事情,但使用tcpdump捕获从squid到服务器的stream量。

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

正如你可以看到报告的延迟是732毫秒。

这是前三个数据包的tcpdump捕获的输出,来自我的盒子的SYN ACK来自远程的SYN ACK以及来自我的盒子的ACK 。 我的理解是,这是build立连接所需的三方握手

 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毫秒。 所以在这个例子中,如果我的分析是正确的, squid有526毫秒的延迟。 额外的~500毫秒的延迟是巨大的。

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

我编辑我的logformat伪指令squid添加DNSparsing时间以毫秒为单位。

 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可能并不多。 该列显示为-因为squid有内部DNScaching。 这意味着鱿鱼使用其内部的DNScaching下一次连接。 这就解释了第一个页面视图变慢,而后续视图变得相对较快。 这也解释了额外的约500毫秒的延迟。 我正在使用bind9运行本地主机转发到ipv4谷歌DNS。 我如何得到一个简单的DNS查询500毫秒的延迟?

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

 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毫秒延迟。 Ping服务器的延迟大约为50毫秒,所以这是有道理的。

那么关于squidbind9东西不相互认同?

我知道这是一个问题,但我有同样的问题,并解决了在squid.conf中使用这个

dns_v4_first上

问候

我不得不设置“connect_timeout 2.0”,因为它先尝试ipv6 dnsparsing,然后在默认的60秒超时后切换到ipv4。