Vì sao Tor chậm hơn VPN: nhấp chuột so với tải xuống

Những trang có cảm giác bị kẹt trong khi các lượt tải xuống chạy với tốc độ bình thường đang mô tả các vòng khứ hồi, không phải băng thông. VPN thêm một bước nhảy mã hóa và một mạch Tor thêm vài bước, và mỗi bước nhảy thêm tốn một lần bắt tay trước khi một byte hữu ích di chuyển. Chi phí đó hiện ra trên một trang mở nhiều kết nối ngắn và gần như biến mất trong một lần truyền lớn. Khi mô hình đã rõ, cuộc tranh luận không còn là công cụ nào nhanh hơn.

Triệu chứng chỉ vào chi phí thiết lập, không phải dung lượng

Tải một trang là một chuỗi các trao đổi phụ thuộc: tìm tên, bắt tay vận chuyển, bắt tay TLS, rồi yêu cầu đầu tiên. Mỗi bước nhảy trên đường chèn vòng khứ hồi của riêng nó vào chuỗi đó trước khi có gì được vẽ. Một lượt tải lớn trả cùng chi phí thiết lập một lần rồi chảy, và đó chính là lý do hai khối lượng công việc không đồng ý với nhau.

Đọc trong bảng mạng thời gian chờ trước byte đầu tiên, không phải tổng. Chờ lâu với lượt tải nội dung ngắn chỉ vào các vòng khứ hồi, trong khi lượt tải nội dung dài với chờ ngắn chỉ vào thông lượng. Lặp lại với một đích thứ hai, vì một máy chủ sau một rơ-le bận rộn không chứng minh được gì. Khi truyền tốt mà nhấp chuột chậm, hãy nghi chi phí thiết lập lâu trước khi nghi băng thông.

Độ trễ và dung lượng thất bại theo cách khác nhau

Lấy hai lần đọc và phần lớn sự bối rối tự giải quyết. Độ trễ là chi phí cố định mỗi trao đổi và dung lượng là tốc độ theo thời gian, nên một đường có thể tốt ở cái đầu và tệ ở cái sau. Một điểm cuối xa với bộ xử lý nhàn rỗi trả lời nhanh một yêu cầu nhỏ và vẫn giới hạn một lượt truyền liên tục trong mức mà đường lên của nó cho phép. Người dùng trải nghiệm sự tách đó như một cú nhấp nhanh theo sau là thanh tiến trình gần như không nhúc nhích.

Thử dung lượng bằng một lượt truyền liên tục và xem tốc độ có giữ ổn định hay răng cưa. Thử độ trễ bằng một yêu cầu nhỏ lặp lại nhiều lần và đọc độ phân tán thay vì mẫu tốt nhất, vì độ phân tán rộng cảm thấy tệ hơn mức trung bình của nó gợi ý. Ghi cả hai con số trước và sau mỗi thay đổi, nếu không sau này bạn sẽ ghi công cho biến sai.

Coi hai thứ như một con số tạo ra các chỉnh sửa không bao giờ dịch chuyển phép đo mà bạn quan tâm. Đây là cách phổ biến nhất để một phàn nàn về độ trễ được trả lời bằng một bản nâng cấp băng thông.

Định tuyến hành tây thêm những bước nhảy bạn không chọn

Một mạch Tor thường dùng ba rơ-le — một lính gác, một nút giữa và một lối ra — và ứng dụng khách chọn chúng từ một đồng thuận, không phải từ bản đồ. Vì thế đường đi có thể dài hơn nhiều so với đường thẳng tới đích. Mỗi rơ-le cũng chở lưu lượng của người khác, nên luồng của bạn chia sẻ dung lượng còn lại trên rơ-le đó.

Dùng lại mạch làm dịu chi phí, vì một luồng mới có thể cưỡi trên mạch sẵn có thay vì trả cho một lần dựng nữa. Ứng dụng khách dựng mạch mới cho mỗi yêu cầu trả chi phí thiết lập lặp đi lặp lại và cảm thấy tệ hơn nhiều so với bên dùng lại. Chọn lối ra cũng quan trọng, vì một số lối ra chở tải nặng hơn và không gì trong giao diện cho bạn biết mình đã hạ cánh ở đâu. Sự chia sẻ đó chính là mục đích thiết kế và lý do không thể chỉnh độ trễ về một giá trị cố định, nên một lối ra chậm là lý do yếu để từ bỏ cách bố trí này.

Đổi thứ tự chuỗi là đổi thí nghiệm

VPN trước rồi Tor sau là một thí nghiệm khác với Tor trước rồi VPN sau. Trong cách bố trí đầu, điểm cuối VPN chở toàn bộ mạch, nên mạng truy cập của bạn chỉ biết địa chỉ VPN. Trong cách thứ hai, chính kết nối VPN được chở bên trong đường hành tây, và lối ra thấy lưu lượng VPN. Cả hai đều là thiết kế hợp lý, và so sánh bất kỳ cái nào với một VPN trần trụi là đo một thứ khác, đó là lý do trang của dự án Tor về việc kết hợp hai thứ đặt nó như câu hỏi về điều bạn đang cố giấu trước khi là câu hỏi về thời gian.

Giữ thiết bị, mạng truy cập và đích cố định, và đổi đúng một yếu tố giữa các lần chạy. Di chuyển máy chủ, mạch và máy thử cùng lúc tạo ra một khác biệt không ai có thể quy cho yếu tố nào. Ghi lại mỗi cách bố trí giấu điều gì với ai trước khi tối ưu nó, vì một chuỗi nhanh mà phơi bày điều bạn muốn giấu không phải là cải thiện.

Một so sánh sống sót qua lần chạy thứ hai

Chọn hai hoặc ba đích bạn thật sự dùng và bấm giờ cùng một tương tác trên mỗi đích, gồm một trang kéo nhiều tài nguyên nhỏ và một lượt truyền lớn. Lặp lại toàn bộ bộ đo vào một giờ khác trong ngày.

Báo cáo trung vị và trường hợp xấu nhất thay vì mẫu nhanh nhất, vì công việc tương tác được đánh giá bằng những khoảnh khắc tệ của nó. Ghi lại ứng dụng khách, điểm cuối hoặc lối ra, và liệu mạch hay đường hầm có được dùng lại trong lần chạy đó. Nếu một thay đổi cải thiện trung vị nhưng làm tệ đuôi, đó là đánh đổi chứ không phải thắng lợi, và việc quyết định liệu người dùng có nhận ra là quyết định thật sự.