Squid HTTPS туннелирование с использованием CONNECT очень медленно

12

Я использую в сети squid для кеширования контента. Я запускаю Chrome с параметром командной строки, который говорит ему использовать прокси.

По большей части это прекрасно работает, так как Squid кеширует большое количество контента, а с ограниченным числом пользователей работает нормально.

Когда я захожу на веб-сайт, использующий HTTPS с использованием Chrome, первая страница загружается очень медленно. Строка состояния на 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 -

Как видите, задержка составляет 732 мс.

Вот выходные данные из захвата 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 мс. Так что в этом примере squidзадержка составляет 526 мс, если мой анализ правильный. Задержка ~ 500 мс огромна.

Но мой анализ может быть ошибочным, я думаю, потому что «время отклика» для 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 -

Второй столбец - время поиска DNS, третий - «время отклика», которое может мало что значить CONNECT. В столбце вверх , как -потому , что squidимеет внутреннее кэширование DNS. Это означает, что squid использовал свой внутренний DNS-кеш для следующего соединения. Это объясняет, что просмотр первой страницы идет медленно, а последующие - относительно быстро. Это также объясняет дополнительные ~ 500 мс задержки. Я использую bind9, работающий на локальной переадресации хоста, чтобы гуглить DNS на ipv4. Как я получаю ~ 500 мс задержки для простого поиска DNS?

Запуск 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 мс задержки для всего поиска. Пинг этого сервера дает задержку около 50 мс, так что это имеет смысл.

Так что-то о squidи bind9не согласны друг с другом?

https squid Эрик Урбан
источник
Вы используете какой-нибудь брандмауэр где-то между прокси-сервером и сетью общего пользования или между настольным компьютером и прокси-сервером?
Ксавье Лукас
Да, я использую другую машину, которая используется iptablesв качестве межсетевого экрана NAT + для моего интернет-соединения.
Эрик Урбан
Убедитесь, что ваши правила используют состояния сетевого фильтра (NEW, ESTABLISHED), чтобы разрешить трафик, а не только пары ip: port. Немного tcpdump, чтобы увидеть, что занимает время, определенно поможет (например, проверить запросы DNS).
Ксавье Лукас
как это могло бы быть по-другому, что просто иметь правило iptables -A chain_name -j ACCEPT. Я имею в виду, конечно, я мог бы добавить это, но я не понимаю, почему это будет иметь значение.
Эрик Урбан
1
Определенно быстрее проверить состояние существующего соединения, чем тестировать набор правил для каждого пакета. По своему опыту, я видел резкое снижение производительности без такой настройки. Лучший способ проанализировать вашу проблему: tcpdump.
Ксавье Лукас

Ответы:

12

Я знаю, что это старый вопрос, но у меня была та же проблема, и я решил ее с помощью squid.conf

dns_v4_first on

С уважением

Джулиано Пиасса
источник
Круто, спасибо большое! Я обвинял Chrome все время, когда у меня была эта досадная проблема. Надо было подумать об этом, так как у меня проблема с сетью IPv6 на моем виртуальном компьютере.
piit79
К точке! Спасибо.
Маринос Ан
1

Публикация этого, как я думаю, будет полезна всем, кто запускает squid с pfSense. Спасибо Джулиано за ответ! Тот же параметр можно найти в разделе (в вашем поле pfSense) Сервисы> Squid Proxy Server> Общие как Resolve DNS IPv4 First. Ниже скриншот.

Настройки прокси pfSense squid

darshanags
источник
-1

Мне пришлось установить «connect_timeout 2.0», потому что он сначала пытался разрешить ipv6 dns, а затем перешел на ipv4 после 60-секундного таймаута по умолчанию.

HawtDogFlvrWtr
источник