การขุดอุโมงค์ HTTPS โดยใช้ CONNECT ช้ามาก


12

ฉันใช้ปลาหมึกในเครือข่ายเพื่อแคชเนื้อหา ฉันเปิด 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

ประสิทธิภาพของปลาหมึกโดยรวมนั้นยอดเยี่ยมมาก! แต่สำหรับการเชื่อมต่อมันช้ามาก

ฉันพบคุณสามารถใช้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 -

ในขณะที่คุณสามารถดูรายงานความล่าช้าเป็น 732ms

นี่คือผลลัพธ์จากการจับ tcpdump ของ 3 แพ็กเก็ตแรก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.8 ms ในการแลกเปลี่ยนนั้น ดังนั้นในตัวอย่างนี้squidมีความล่าช้า 526 มิลลิวินาทีหากการวิเคราะห์ของฉันถูกต้อง เวลาในการตอบสนองเพิ่มขึ้นประมาณ 500 ms นั้นใหญ่มาก

แต่การวิเคราะห์ของฉันอาจมีข้อบกพร่องฉันคิดว่าเพราะ "เวลาตอบสนอง" สำหรับ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 ms ฉันใช้ 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 มิลลิวินาทีสำหรับการค้นหาทั้งหมด ส่ง Ping เซิร์ฟเวอร์นั้นให้เวลาแฝงประมาณ 50 ms ดังนั้นจึงสมเหตุสมผล

ดังนั้นสิ่งที่เกี่ยวกับsquidและbind9ไม่เห็นด้วยกับแต่ละอื่น ๆ ?


คุณใช้ไฟร์วอลล์อยู่ระหว่างพร็อกซีและช่วงเน็ตสาธารณะหรือระหว่างอุปกรณ์เดสก์ท็อปกับพร็อกซีหรือไม่
ซาเวียร์ลูคัส

ใช่ฉันใช้เครื่องอื่นที่ใช้iptablesทำหน้าที่เป็น NAT + ไฟร์วอลล์สำหรับการเชื่อมต่ออินเทอร์เน็ตของฉัน
Eric Urban

ตรวจสอบให้แน่ใจว่ากฎของคุณใช้สถานะ netfilter (ใหม่, สร้างแล้ว) เพื่ออนุญาตการรับส่งข้อมูลและไม่เพียง แต่ ip: พอร์ตคู่รัก tcpdump เล็กน้อยเพื่อดูว่าจะใช้เวลานานจะช่วยอะไรแน่นอน (เช่นตรวจสอบคำขอ DNS)
ซาเวียร์ลูคัส

วิธีการที่จะแตกต่างกันที่ใด ๆ iptables -A chain_name -j ACCEPTเพียงแค่มีกฎ ฉันหมายความว่าแน่นอนฉันสามารถเพิ่มได้ แต่ฉันไม่เห็นว่าทำไมจึงมีความสำคัญ
Eric Urban

1
การตรวจสอบสถานะการเชื่อมต่อที่มีอยู่นั้นเร็วกว่าแน่นอนกว่าการทดสอบกฎต่างๆสำหรับแต่ละแพ็คเก็ต จากประสบการณ์ของฉันฉันเห็นการสูญเสียประสิทธิภาพอย่างมากโดยไม่ต้องตั้งค่าดังกล่าว วิธีที่ดีที่สุดในการวิเคราะห์ปัญหาของคุณ: tcpdump
ซาเวียร์ลูคัส

คำตอบ:


12

ฉันรู้ว่ามันเป็นคำถามเก่าแต่ฉันมีปัญหาเดียวกันและแก้ไขได้โดยใช้ใน squid.conf

dns_v4_ เริ่มแรก

ความนับถือ


เยี่ยมมากขอบคุณมาก! ฉันโทษ Chrome ตลอดเวลาที่ฉันมีปัญหาที่น่ารำคาญนี้ ควรมีความคิดเช่นนี้เนื่องจากฉันมีปัญหากับเครือข่าย IPv6 บน vm ของฉัน
piit79

ถึงจุด! ขอบคุณ.
Marinos

1

โพสต์สิ่งนี้เพราะฉันคิดว่ามันจะเป็นประโยชน์กับทุกคนที่ใช้ปลาหมึกด้วยกล่อง pfSense ขอบคุณ Juliano สำหรับคำตอบ! การตั้งค่าเดียวกันสามารถพบได้ตาม (ในกล่อง pfSense ของคุณ) บริการ> Squid Proxy Server> ทั่วไปResolve DNS IPv4 Firstเป็น ด้านล่างเป็นภาพหน้าจอ

pfSense squid proxy settings


-1

ฉันต้องตั้งค่า "connect_timeout 2.0" เพราะมันพยายาม ipv6 ความละเอียด dns ก่อนแล้วจึงเปลี่ยนเป็น ipv4 หลังจากค่าเริ่มต้นหมดเวลา 60 วินาที

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.