Tôi sử dụng mực trên mạng của tôi để lưu trữ nội dung. Tôi khởi chạy chrome với một công tắc dòng lệnh bảo nó sử dụng proxy.
Đối với hầu hết các phần này hoạt động tuyệt vời như mực lưu trữ một lượng lớn nội dung và với một số lượng người dùng hạn chế, nó hoạt động tốt.
Khi tôi truy cập trang web HTTPS bằng chrome, trang đầu tiên tải rất chậm. Thanh trạng thái trên chrome cho biết "Đang chờ đường hầm proxy ...". Chrome sử dụng động từ CONNECT để tạo đường hầm thông qua proxy và thiết lập HTTPS với máy chủ. Các trang tiếp theo rất nhanh vì Chrome giữ kết nối mở.
Tôi đã kiểm tra nhật ký squid3 của tôi. Dưới đây là một số mục CONNECT. Cột thứ hai là thời gian phản hồi tính bằng mili giây
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 -
Một số kết nối mất hơn 60000 mili giây!
Dưới đây là một vài GET để so sánh
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
Hiệu suất mực nói chung là tuyệt vời! Nhưng đối với KẾT NỐI thì rất chậm.
Tôi phát hiện ra bạn có thể sử dụng echo
và nc
yêu cầu một đường hầm từ dòng lệnh.
Tôi đã thực hiện hai kết nối trở lại bằng cách sử dụng kỹ thuật này
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
Trong nhật ký,
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 -
Kết nối đầu tiên mất 3079 mili giây, nhưng kết nối thứ hai chỉ có 208. Vì vậy, có vẻ như Squid không phải lúc nào cũng chậm.
Sau đó, tôi đã làm điều tương tự một lần nữa nhưng được sử dụng tcpdump
để nắm bắt lưu lượng truy cập từ squid
máy chủ.
1416070989.180 732 192.168.12.10 TCP_MISS/200 0 CONNECT russiatoday.com:443 - DIRECT/62.213.85.4 -
Như bạn có thể thấy độ trễ báo cáo là 732ms.
Đây là đầu ra từ việc chụp tcpdump của 3 gói đầu tiên, SYN
từ hộp của tôi, SYN ACK
từ xa và ACK
từ hộp của tôi. Tôi hiểu rằng đây là cái bắt tay 3 chiều cần thiết để thiết lập kết nối
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
Thời gian đã qua là 206,8 ms trong trao đổi đó. Vì vậy, trong ví dụ squid
này có độ trễ 526 ms nếu phân tích của tôi là chính xác. Độ trễ thêm ~ 500 ms là rất lớn.
Nhưng phân tích của tôi có thể là thiếu sót, tôi nghĩ bởi vì "thời gian phản hồi" cho một CONNECT
con mực chỉ đo tổng thời gian đường hầm được giữ mở.
Tôi đã chỉnh sửa logformat
chỉ thị của mình squid
để thêm thời gian phân giải DNS tính bằng mili giây.
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 -
Cột thứ hai là thời gian tra cứu DNS, cột thứ 3 là "thời gian phản hồi" có thể không có ý nghĩa nhiều CONNECT
. Cột hiển thị -
vì squid
có bộ đệm ẩn DNS bên trong. Điều này có nghĩa là con mực đã sử dụng bộ đệm DNS bên trong của nó cho lần kết nối tiếp theo. Điều này giải thích lượt xem trang đầu tiên chậm và những trang tiếp theo tương đối nhanh. Điều này cũng giải thích thêm ~ 500 ms độ trễ. Tôi đang sử dụng bind9 chạy trên chuyển tiếp máy chủ cục bộ để googles DNS trên ipv4. Làm thế nào tôi có được độ trễ ~ 500ms cho một tra cứu DNS đơn giản?
Chạy nslookup
trực tiếp bằng cách sử dụng 8.8.8.8 và bỏ qua máy chủ cục bộ của tôi:
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
Điều này cho thấy độ trễ 56 ms cho toàn bộ tra cứu. Ping máy chủ đó cho độ trễ khoảng 50 ms, vì vậy điều này có ý nghĩa.
Vì vậy, một cái gì đó về squid
và bind9
không đồng ý với nhau?
iptables
để hoạt động như tường lửa NAT + cho kết nối internet của mình.
iptables -A chain_name -j ACCEPT
. Ý tôi là chắc chắn, tôi có thể thêm nó, nhưng tôi không hiểu tại sao nó lại quan trọng.