Używam kałamarnicy w mojej sieci do buforowania zawartości. Uruchamiam chrome z przełącznikiem wiersza poleceń, który każe mu używać proxy.
W większości przypadków działa to świetnie, ponieważ kałamarnica buforuje dużą ilość treści, a przy ograniczonej liczbie użytkowników działa dobrze.
gdy odwiedzam stronę internetową, która używa HTTPS przy użyciu chrome, pierwsza strona ładuje się bardzo wolno. Pasek stanu na chrome mówi „Oczekiwanie na tunel proxy…”. Chrome używa czasownika CONNECT do tunelowania przez serwer proxy i ustanowienia HTTPS z serwerem. Kolejne strony są szybkie, ponieważ Chrome utrzymuje połączenie otwarte.
Sprawdziłem moje dzienniki squid3. Oto niektóre wpisy CONNECT. Druga kolumna to czas odpowiedzi w milisekundach
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 -
Niektóre połączenia trwają ponad 60000 milisekund!
Oto kilka GETÓW do porównania
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
Ogólna wydajność kałamarnicy jest doskonała! Ale dla CONNECT jest to bardzo powolne.
Dowiedziałem się, że możesz użyć echo
i nc
poprosić o tunel z wiersza poleceń.
Za pomocą tej techniki wykonałem dwa połączenia jeden po drugim
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
W logach
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 -
Pierwsze połączenie zajęło 3079 milisekund, ale drugie tylko 208. Wygląda więc na to, że Squid nie zawsze jest wolny.
Później powtórzyłem to samo, ale tcpdump
przechwyciłem ruch z squid
serwera.
1416070989.180 732 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -
Jak widać zgłoszone opóźnienie wynosi 732 ms.
Oto wynik przechwytywania przez tcpdump pierwszych 3 pakietów, SYN
z mojego urządzenia, SYN ACK
z pilota i ACK
mojego urządzenia. Rozumiem, że jest to 3-drożny uścisk dłoni potrzebny do nawiązania połączenia
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
Upływający czas to 206,8 ms w tej wymianie. Więc w tym przykładzie squid
ma 526 ms opóźnienia, jeśli moja analiza jest poprawna. Dodatkowe ~ 500 ms opóźnienia jest ogromne.
Ale myślę, że moja analiza może być błędna, ponieważ „czas odpowiedzi” dla CONNECT
kałamarnicy po prostu mierzy całkowity czas pozostawania tunelu otwartego.
Zredagowałem moją logformat
dyrektywę, squid
aby dodać czas rozpoznawania DNS w milisekundach.
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 -
Druga kolumna to czas wyszukiwania DNS, trzecia to „czas odpowiedzi”, co może nie mieć większego znaczenia CONNECT
. Kolumna jest wyświetlana jako, -
ponieważ squid
ma wewnętrzne buforowanie DNS. Oznacza to, że squid użył wewnętrznej pamięci podręcznej DNS do następnego połączenia. To tłumaczy, że pierwsze wyświetlenie strony jest powolne, a kolejne względnie szybkie. To wyjaśnia również dodatkowe ~ 500 ms opóźnienia. Korzystam z bind9 działającego na lokalnym hostie przekierowującym do googles DNS na ipv4. Jak uzyskać ~ 500ms opóźnienia na proste wyszukiwanie DNS?
Uruchamianie nslookup
przy użyciu 8.8.8.8 bezpośrednio i omijanie mojego lokalnego serwera:
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
To pokazuje 56 ms opóźnienia dla całego wyszukiwania. Pingowanie tego serwera daje opóźnienie około 50 ms, więc ma to sens.
Więc coś o sobie squid
i bind9
nie zgadzasz się ze sobą?
iptables
działa jako zapora NAT + dla mojego połączenia internetowego.iptables -A chain_name -j ACCEPT
. Mogę to dodać, ale nie wiem, dlaczego miałoby to mieć znaczenie.Odpowiedzi:
Wiem, że to stare pytanie, ale miałem ten sam problem i rozwiązałem go za pomocą squid.conf
pozdrowienia
źródło
Publikowanie tego, jak myślę, będzie pomocne dla każdego, kto używa kałamarnicy z polem pfSense. Dziękuję Juliano za odpowiedź! To samo ustawienie można znaleźć w (w polu pfSense) Usługi> Serwer proxy Squid> Ogólne jako
Resolve DNS IPv4 First
. Poniżej znajduje się zrzut ekranu.źródło
Musiałem ustawić „connect_timeout 2.0”, ponieważ najpierw próbował on rozwiązać rozdzielczość dns ipv6, a następnie przestawił się na ipv4 po domyślnym 60 sekundowym przekroczeniu limitu czasu.
źródło