Тунелювання кальмарів HTTPS за допомогою CONNECT дуже повільне

Я використовую кальмари в своїй мережі для кешування вмісту. Я запускаю chrome за допомогою перемикача командного рядка, який повідомляє йому використовувати проксі.

Здебільшого це чудово працює, оскільки кальмари кешують велику кількість контенту і з обмеженою кількістю користувачів вони чудово працюють.

коли я відвідую веб-сайт із HTTPS за допомогою хрому, перша сторінка завантажується дуже повільно. У рядку статусу на хромі написано "Очікування тунелю проксі ...". 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. Отже, схоже, що кальмар не завжди повільний.

Пізніше я знову зробив те ж саме, але використовував 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 мс затримки величезні.

Але мій аналіз може бути помилковим, я думаю, тому що "час реакції" для 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, 3-й - "час відповіді", що може не означати багато CONNECT. Стовпець відображається так, -тому що squidмає внутрішнє кешування DNS. Це означає, що кальмар використовував свій внутрішній кеш DNS для наступного підключення. Це пояснює те, що перегляд першої сторінки є повільним, а наступний - відносно швидким. Це також пояснює зайві ~ 500 мс затримки. Я використовую bind9, що працює на локальній переадресації хоста до googles 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 + для мого підключення до Інтернету.

— Ерік Урбан

Переконайтеся, що ваші правила використовують стан netfilter (НОВИЙ, Встановлений), щоб дозволити трафік, а не лише пара ip: порт. Трохи tcpdump, щоб побачити, на що потрібен час, безумовно, допоможе (наприклад, перевірити запити DNS).

— Ксав'є Лукас

як би це було інакше, ніж просто правило iptables -A chain_name -j ACCEPT. Я маю на увазі впевнений, я міг би його додати, але не бачу, чому це мало б значення.

— Ерік Урбан

Напевно швидше перевірити стан існуючого з'єднання, ніж тестувати купу правил для кожного пакету. На моєму досвіді я бачив різкі втрати продуктивності без таких налаштувань. Найкращий спосіб проаналізувати свою проблему: tcpdump.

— Ксав'є Лукас

Я знаю, що це старе питання, але у мене була така ж проблема і вирішено за допомогою цього в squid.conf

dns_v4_first on

З повагою

— Джуліано Піасса
джерело

Дивовижне, велике спасибі! Я звинувачував Chrome упродовж усього часу, коли у мене виникала ця дратівлива проблема. Якщо б у мене виникли проблеми з мережею IPv6 на моєму vm.

— piit79

До суті! Дякую.

— Марінос

Опублікувавши це, як я думаю, це буде корисно всім, хто працює з кальмарами з полем pfSense. Дякую Джуліано за їх відповідь! Такі самі налаштування можна знайти в розділі (у вашому полі pfSense) Послуги> Проксі-сервер кальмара> Загальне як Resolve DNS IPv4 First. Нижче - скріншот.

— darshanags
джерело

-1

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

— HawtDogFlvrWtr
джерело