CONNECT kullanarak Squid HTTPS Tüneli çok yavaş

İçeriğimi önbelleğe almak için ağımda kalamar kullanıyorum. Chrome'u, proxy'yi kullanmasını söyleyen bir komut satırı anahtarıyla başlatırım.

Çoğunlukla bu, kalamar çok miktarda içeriği önbelleğe aldığı için harika çalışır ve sınırlı sayıda kullanıcıyla iyi performans gösterir.

krom kullanan HTTPS olan bir web sitesini ziyaret ettiğimde, ilk sayfa çok yavaş yükleniyor. Chrome'daki durum çubuğunda "Proxy tüneli bekleniyor ..." yazıyor. Chrome, proxy üzerinden tünel oluşturmak ve sunucu ile HTTPS oluşturmak için CONNECT fiilini kullanır. Sonraki sayfalar hızlıdır çünkü Chrome bağlantıyı açık tutar.

Squid3 günlüklerimi kontrol ettim. CONNECT girişlerinden bazıları. İkinci sütun milisaniye cinsinden yanıt süresidir

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 -

Bazı bağlantılar 60000 milisaniyeden fazla sürüyor!

Karşılaştırma için birkaç 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

Genel kalamar performansı mükemmel! Ancak CONNECT için çok yavaş.

Kullanabileceğin öğrendim echove nckomut satırından bir tünel istemek için.

Bu tekniği kullanarak arka arkaya iki bağlantı yaptım

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

Günlüklerde,

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 -

İlk bağlantı 3079 milisaniye sürdü, ancak ikincisi sadece 208. Öyleyse Squid her zaman yavaş değil.

Daha sonra aynı şeyi tekrar yaptım ama sunucudan tcpdumptrafiği yakalamak için kullandım squid.

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

Gördüğünüz gibi gecikme süresi 732 ms'dir.

İşte ilk 3 paket tcpdump yakalama çıktı, olan SYNbenim kutusundan, SYN ACKuzaktan kumandadan ve ACK benim kutusundan. Anladığım kadarıyla, bu bağlantıyı kurmak için gereken 3 yönlü el sıkışma

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

Bu değişimde geçen süre 206.8 ms'dir. Dolayısıyla bu örnekte squid, analizim doğruysa 526 ms gecikme süresi vardır. Fazladan 500 ms'lik bir gecikme süresi çok büyük.

Ama analizim kusurlu olabilir diye düşünüyorum çünkü bir CONNECTkalamar için "tepki süresi" sadece tünelin açık tutulduğu toplam süreyi ölçer.

DNS çözümleme süresini milisaniye olarak eklemek için logformatdirektifimi düzenledim squid.

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 -

İkinci sütun DNS arama süresidir, üçüncüsü ise çok fazla anlama gelmeyebilecek "yanıt süresidir" CONNECT. Sütun , dahili DNS önbelleğe sahip olduğu -için squidgörünür. Bu, kalamarın bir sonraki bağlantı için dahili DNS önbelleğini kullandığı anlamına gelir. Bu, ilk sayfa görünümünün yavaş ve sonraki sayfaların nispeten hızlı olduğunu açıklar. Bu ayrıca ~ 500 ms gecikme süresini de açıklar. Ben ipv4 üzerinde googles DNS yerel ana bilgisayar yönlendirme üzerinde çalışan bind9 kullanıyorum. Basit bir DNS araması için ~ 500ms gecikme nasıl alabilirim?

Koşu nslookupdoğrudan 8.8.8.8 kullanıyorum ve benim yerel sunucusu atlayarak:

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

Bu, tüm arama için 56 ms gecikme süresi gösterir. Bu sunucuya ping atmak yaklaşık 50 ms gecikme süresi verir, bu da mantıklıdır.

Öyleyse birbirinizle ilgili bir şey var squidve bind9birbirinize katılmıyor musunuz?

https squid

— Eric Urban
kaynak

Proxy ve genel net aralık arasında veya masaüstü donanım ve proxy arasında bir yerlerde güvenlik duvarı mı kullanıyorsunuz?

— Xavier Lucas

Evet, iptablesinternet bağlantım için NAT + güvenlik duvarı görevi gören başka bir makine kullanıyorum .

— Eric Urban

Kurallarınızın yalnızca ip: bağlantı noktası çiftlerine değil, trafiğe izin vermek için netfilter durumlarını (YENİ, KURULDU) kullandığından emin olun. Neyin zaman alacağını görmek için biraz tcpdump yardımcı olacaktır (örneğin, DNS isteklerini kontrol edin).

— Xavier Lucas

nasıl bir kurala sahip olmaktan daha farklı olurdu iptables -A chain_name -j ACCEPT. Demek istediğim, ekleyebilirim, ama neden önemli olduğunu anlamıyorum.

— Eric Urban

Mevcut bir bağlantının durumunu kontrol etmek, her paket için bir grup kuralı test etmekten kesinlikle daha hızlıdır. Deneyimlerime göre, böyle bir kurulum olmadan dramatik performans kaybı gördüm. Sorununuzu analiz etmenin en iyi yolu: tcpdump.

— Xavier Lucas

Eski bir soru olduğunu biliyorum ama aynı sorunu vardı ve bunu squid.conf kullanarak çözüldü

dns_v4_first on

Saygılarımızla

— Juliano Piassa
kaynak

Harika, çok teşekkürler! Bu can sıkıcı sorunu yaşadığım süre boyunca Chrome'u suçluyordum. Benim vm IPv6 ağ ile ilgili bir sorun var gibi bunu düşünmeliydim.

— piit79

Diyeceğim şey şu ki! Teşekkür ederim.

— Marinos An

Bunu bir pfSense kutusu ile kalamar çalıştıran herkes için yararlı olacağını düşünüyorum olarak gönderme. Yanıtları için Juliano'ya teşekkürler! Aynı ayarı (pfSense kutunuzda) Hizmetler> Squid Proxy Sunucusu> Genel olarak bulabilirsiniz Resolve DNS IPv4 First. Aşağıda bir ekran görüntüsü var.

— darshanags
kaynak

-1

İlk önce ipv6 dns çözünürlüğü deniyordu ve sonra varsayılan bir 60 saniye zaman aşımı sonra ipv4'e kaymaya çünkü "connect_timeout 2.0" ayarlamak zorunda kaldı.

— HawtDogFlvrWtr
kaynak