CONNECT를 사용한 오징어 HTTPS 터널링 속도가 매우 느림

네트워크에서 오징어를 사용하여 콘텐츠를 캐시합니다. 프록시를 사용하라는 명령 줄 스위치로 크롬을 시작합니다.

대부분의 경우 오징어가 많은 양의 콘텐츠를 캐시하고 제한된 수의 사용자로 정상적으로 작동하므로 훌륭하게 작동합니다.

크롬을 사용하는 HTTPS 웹 사이트를 방문하면 첫 페이지가 매우 느리게로드됩니다. 크롬의 상태 표시 줄에 "프록시 터널 대기 중 ..."이 표시됩니다. Chrome은 CONNECT 동사를 사용하여 프록시를 통해 터널링하고 서버와 HTTPS를 설정합니다. Chrome에서 연결을 계속 열어두기 때문에 후속 페이지가 빠릅니다.

내 오징어 3 로그를 확인했습니다. 다음은 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 -

보시다시피보고 된 대기 시간은 732ms입니다.

다음은 처음 3 개 패킷의 tcpdump 캡처, SYN내 상자, SYN ACK원격 및 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.8ms입니다. 따라서이 예제에서 squid분석이 정확하면 대기 시간이 526ms입니다. 추가 ~ 500ms의 대기 시간이 엄청납니다.

그러나 CONNECT오징어에 대한 "응답 시간" 은 터널이 열린 총 시간을 측정 하기 때문에 분석에 결함이있을 수 있습니다 .

DNS 확인 시간을 밀리 초 단위로 추가 logformat하기 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 -

두 번째 열은 DNS 조회 시간이며, 세 번째 열은 "응답 시간"이므로 별 의미가 없습니다 CONNECT. 내부 DNS 캐싱이 -있기 때문에 열이 표시됩니다 squid. 이것은 squid가 다음 연결을 위해 내부 DNS 캐시를 사용했음을 의미합니다. 이것은 첫 페이지보기가 느리고 후속 페이지보기가 상대적으로 빠르다는 것을 설명합니다. 또한 추가 ~ 500ms의 대기 시간을 설명합니다. ipv4의 Google DNS에 로컬 호스트 전달을 실행하는 bind9을 사용하고 있습니다. 간단한 DNS 조회를 위해 최대 500ms의 대기 시간을 얻으려면 어떻게해야합니까?

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

전체 조회에 대해 56ms의 대기 시간이 표시됩니다. 서버를 핑 (Ping)하면 약 50ms의 대기 시간이 발생하므로 이치에 맞습니다.

에 대해 뭔가 그래서 squid하고 bind9서로 동의하지 않는?

https squid

— 에릭 어반
소스

프록시와 퍼블릭 넷 범위 사이 또는 데스크탑 장비와 프록시 사이에 방화벽을 실행하고 있습니까?

— Xavier Lucas

예, iptables인터넷 연결을 위해 NAT + 방화벽 역할을하는 다른 컴퓨터를 사용 하고 있습니다.

— Eric Urban

규칙에서 netfilter 상태 (NEW, ESTABLISHED)를 사용하여 ip : port 커플뿐만 아니라 트래픽도 허용해야합니다. 시간이 오래 걸리는 것을 확인하는 tcpdump 비트는 DNS 요청 확인과 같이 확실히 도움이 될 것입니다.

— Xavier Lucas

그냥 규칙을 갖는 것과는 어떻게 다를까요 iptables -A chain_name -j ACCEPT? 나는 그것을 추가 할 수는 있지만 확실하게 왜 그런지 알지 못한다.

— Eric Urban

각 패킷에 대해 많은 규칙을 테스트하는 것보다 기존 연결 상태를 확인하는 것이 훨씬 빠릅니다. 내 경험상 그러한 설정없이 성능이 크게 저하되었습니다. 문제를 분석하는 가장 좋은 방법 : tcpdump.

— Xavier Lucas

나는 그것이 오래된 질문 이라는 것을 알고 있지만 같은 문제가 있었고 이것을 squid.conf에서 사용하여 해결했습니다.

dns_v4_first 켜기

문안 인사

— 줄리아노 피아 사
소스

정말 고마워요! 나는이 성가신 문제가있을 때마다 Chrome을 비난했습니다. 내 VM의 IPv6 네트워킹에 문제가 있기 때문에 이것을 생각해야합니다.

— piit79

요점까지! 감사합니다.

— 마리노스

pfSense 상자로 오징어를 타는 사람에게는 도움이 될 것이라고 생각합니다. 그들의 답변에 대해 Juliano에게 감사드립니다! pfSense 상자에서 서비스> 오징어 프록시 서버> 일반 과 동일한 설정을 찾을 수 있습니다 Resolve DNS IPv4 First. 아래는 스크린 샷입니다.

— 다르 샤나 그
소스

-1

"connect_timeout 2.0"은 ipv6 dns 해상도를 먼저 시도한 다음 기본 60 초 시간 초과 후 ipv4로 이동했기 때문에 설정해야했습니다.

— HawtDogFlvrWtr
소스