CONNECTを使用したSquid HTTPSトンネリングが非常に遅い

11

ネットワークでイカを使用してコンテンツをキャッシュしています。プロキシを使用するように指示するコマンドラインスイッチを使用してChromeを起動します。

squidは大量のコンテンツをキャッシュし、限られた数のユーザーで正常に動作するため、ほとんどの場合これはうまく機能します。

Chromeを使用したHTTPSのWebサイトにアクセスすると、最初のページの読み込みが非常に遅くなります。Chromeのステータスバーに「プロキシトンネルを待機しています...」と表示されます。ChromeはCONNECT動詞を使用してプロキシをトンネルし、サーバーとのHTTPSを確立します。Chromeは接続を開いたままにしているため、後続のページは高速です。

squid3のログを確認しました。CONNECTエントリの一部を次に示します。2番目の列はミリ秒単位の応答時間です

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、コマンドラインからのトンネルを要求します。

私はこのテクニックを使用して背中合わせに2つの接続を行いました

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ミリ秒かかりましたが、2番目の接続には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と報告されています。

これは、SYN私のボックス、SYN ACKリモート、および私のボックスからの最初の3つのパケットのtcpdumpキャプチャからの出力ACK です。私の理解では、これは接続を確立するために必要な3ウェイハンドシェイクです。

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 msのレイテンシは巨大です。

しかし、私の分析には不備があるかもしれません。なぜなら、CONNECTsquid の「応答時間」は、トンネルが開いたままにされた合計時間を測定するだけだからです。

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 -

2番目の列はDNSルックアップ時間、3番目の列は「応答時間」ですCONNECT。この列は、内部DNSキャッシングがある-ために表示されsquidます。これは、squidが次の接続に内部DNSキャッシュを使用したことを意味します。これは、最初のページの表示が遅く、その後の表示が比較的速いことを説明しています。これは、余分な〜500ミリ秒の遅延も説明します。ローカルホストで実行されているbind9を使用して、ipv4のgoogle DNSに転送しています。単純なDNSルックアップで最大500ミリ秒のレイテンシを取得するにはどうすればよいですか？

nslookup8.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 
— エリックアーバン
ソース
プロキシとパブリックネット範囲の間、またはデスクトップリグとプロキシの間のどこかにファイアウォールを実行していますか？
— ザビエルルーカス
はい、iptablesインターネット接続のNAT +ファイアウォールとして機能するを使用する別のマシンを使用しています。
— Eric Urban
ルールがnetfilter状態（NEW、ESTABLISHED）を使用して、ip：portカップルだけでなくトラフィックを許可していることを確認してください。何が時間がかかっているかを確認するためのtcpdumpの少しは間違いなく役立ちます（たとえば、DNS要求を確認します）。
— ザビエルルーカス
ルールがあるだけの場合とどう違うのでしょうかiptables -A chain_name -j ACCEPT。確かに、私はそれを追加することができましたが、なぜそれが重要であるのかわかりません。
— Eric Urban
1
各パケットの一連のルールをテストするよりも、既存の接続の状態を確認する方が間違いなく高速です。私の経験では、このような設定を行わないとパフォーマンスが大幅に低下することがわかりました。問題を分析する最良の方法：tcpdump。
— ザビエルルーカス

回答:

11

私はそれが古い質問であることを知っていますが、同じ問題があり、squid.confでこれを使用して解決しました

dns_v4_firstオン

よろしく

— ジュリアーノ・ピアッサ
ソース
すばらしい、本当にありがとう！この迷惑な問題が発生している間ずっと、Chromeを非難していました。私のvmのIPv6ネットワークに問題があるので、これを考えるべきでした。
— piit79 2017年
1

これをpfSenseボックスでsquidを実行しているすべての人に役立つと思うので、これを投稿します。答えてくれたジュリアーノに感謝！同じ設定が（pfSenseボックス内の）Services> Squid Proxy Server> General asにありResolve DNS IPv4 Firstます。以下はスクリーンショットです。

pfSense squidプロキシ設定

— Darshanags
ソース
-1

「connect_timeout 2.0」を設定する必要があったのは、最初にipv6 dns解決を試み、次にデフォルトの60秒のタイムアウト後にipv4にシフトしたためです。

— HawtDogFlvrWtr
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.