HTTPS ấm so với VPN ấm: so sánh cùng một đường yêu cầu

Có lẽ bạn đã đọc rằng HTTPS mở một kết nối TCP mới và một lần bắt tay TLS mới cho mỗi yêu cầu API, nên một đường hầm duy trì trong một giờ có vẻ rẻ hơn. Nửa đầu của điều đó thường sai. Một ứng dụng khách được hỗ trợ dùng lại kết nối đã thiết lập cho nhiều lần trao đổi, và một phép đo tạo ứng dụng khách mới cho mỗi lệnh gọi đang đo vòng đời chứ không phải sự bảo vệ. Phần còn lại của trang này nói về điều nên đo thay vào đó.

Điều mà việc dùng lại thực sự đòi hỏi

Tính bền vững là một phần của mô hình HTTP chứ không phải mẹo: một kết nối mang nhiều lần trao đổi yêu cầu và phản hồi. Kết nối kết thúc khi một trong hai bên đóng nó, khi máy chủ loại bỏ một kết nối nhàn rỗi hoặc quá tải, hoặc khi một tiêu đề hay quy tắc giao thức nói rằng kết nối không thể dùng lại. HTTPS đặt cuộc trò chuyện đó bên trong TLS mà không đòi hỏi bắt tay mới cho mỗi lần trao đổi. Vì vậy yêu cầu thứ hai không lặp lại bắt tay của yêu cầu thứ nhất trừ khi có gì đó đã kết thúc kết nối ở giữa.

Dùng lại cũng có một điều kiện mà ứng dụng dễ phá vỡ. Một ứng dụng khách định dùng lại kết nối phải đọc toàn bộ nội dung phản hồi, và một phản hồi bị bỏ dở giữa chừng là cách thường gặp khiến một nhóm kết nối biến mất mà không ai nhận ra.

Hãy kiểm tra ứng dụng khách được thư viện hỗ trợ và vòng đời của nhóm kết nối thay vì giả định rằng việc gộp kết nối đang bật hay tắt. Ghi lại cả phiên bản HTTP đã thương lượng, vì HTTP/2 và HTTP/3 xử lý việc dùng lại kết nối khác với HTTP/1.1. Hãy coi phiên bản đã thương lượng là một phần của phép đo, không phải chú thích.

Vì sao phép so sánh đo vòng đời

Tạo một ứng dụng khách mới cho mỗi thao tác và so sánh nó với một đường hầm đã kết nối một giờ là so sánh việc thiết lập kết nối với trạng thái ổn định. Đó là một phép đo hợp lệ, và đó không phải là HTTPS so với VPN. Hai lần chạy với cùng cấu hình ứng dụng khách mô tả hành vi tốt hơn một lần, nhất là khi lần chạy đầu làm nóng bộ phân giải hoặc bộ đệm kết nối.

Giữ thao tác API, máy chủ, tài khoản và dữ liệu cố định, nếu không phép so sánh mang nhiều hơn một biến. Quyết định trước nơi đặt đồng hồ đo, vì việc thiết lập, thương lượng TLS, thực thi ứng dụng và giao phản hồi đóng góp khác nhau vào tổng. Một đồng hồ đo cho yêu cầu đầu tiên mô tả việc thiết lập và không nói gì về lưu lượng ổn định mà bạn thực sự vận hành. Ghi các ranh giới của đồng hồ đo bên cạnh các con số.

Tách việc thiết lập nguội khỏi các yêu cầu ấm

Đo yêu cầu đầu tiên tách biệt với những yêu cầu tiếp theo. Sau đó thêm những gì dịch vụ thực sự thấy: các giai đoạn nhàn rỗi, đợt tăng vọt, tính đồng thời, kích thước phản hồi và các lần kết nối lại.

Giữ bật xác thực chứng chỉ và HTTPS trên cả hai đường, vì loại bỏ chúng là đo một thiết kế bảo mật khác chứ không phải nhanh hơn. Nếu đường hầm thay đổi tuyến hoặc vị trí cổng, hãy báo cáo khác biệt đó riêng thay vì quy mọi thay đổi thời gian cho mã hóa, vì đường đi, mất gói và hàng đợi có thể chi phối một yêu cầu nhỏ. Chạy mỗi đường hai lần trên cùng tuyến trước khi kết luận. Ghi lại giao thức đã thương lượng và ranh giới đồng hồ đo với cả hai lần chạy.

Tính trước cho kết nối bị đóng

Bền không có nghĩa là vĩnh viễn. Máy chủ, proxy hoặc một thay đổi mạng có thể đóng kết nối trong giai đoạn nhàn rỗi, và ứng dụng khách phải phục hồi theo hành vi mà thư viện hỗ trợ. Việc phục hồi đó có một máy trạng thái: yêu cầu có thể đã hoàn tất trên máy chủ, hoặc có thể đã thất bại trước khi máy chủ đọc nó, và một socket đã đóng không cho bên gọi biết điều nào đã xảy ra. Một thao tác không idempotent ở vị trí đó không thể chỉ phát lại, vì phát lại biến một kết quả không rõ thành một lần ghi trùng. Đây là chỗ một đường hầm ấm và một kết nối ấm xử sự giống nhau, vì cả hai đều có thể thất bại đúng lúc công việc đang diễn ra.

Dùng cơ chế thử lại hoặc idempotency được dịch vụ ghi trong tài liệu thay vì một vòng lặp mở lại socket. Hãy kiểm tra phục hồi một cách rõ ràng: đóng một kết nối nhàn rỗi và quan sát ứng dụng khách làm gì tiếp theo. Mở lại socket không làm cho việc lặp lại một lệnh gọi thay đổi trạng thái trở nên an toàn.

Chọn ranh giới trước, rồi tinh chỉnh

Chọn ranh giới mạng từ các yêu cầu về truy cập và tin cậy trước khi tối ưu bất cứ điều gì. VPN bảo vệ đoạn giữa các điểm ngang hàng của nó, trong khi các điểm cuối ứng dụng và bất kỳ đoạn văn bản rõ nào ngoài đường hầm vẫn quan trọng. Sau đó điều chỉnh vòng đời kết nối trong ranh giới đó. Kết luận về đường hầm rẻ hơn chỉ xuất phát từ niềm tin rằng mỗi yêu cầu lặp lại bắt tay, và chính niềm tin đó là thứ được kiểm tra ở đây.

Phần nói về tính bền vững trong RFC 9112 là tài liệu tham chiếu cho những gì việc dùng lại thực sự hứa hẹn, bao gồm các điều kiện kết thúc một kết nối. Hãy đọc một lần trước khi tin vào một phép đo bỏ qua chúng.