nghiên cứu về TCP
Đối số để tăng khoảng thời gian tắc nghẽn ban đầu của TCP
Các luồng TCP bắt đầu với cửa sổ tắc nghẽn ban đầu với tối đa 4 phân đoạn hoặc khoảng 4 KB dữ liệu. Vì hầu hết các giao dịch trên web đều diễn ra trong thời gian ngắn, nên khoảng thời gian tắc nghẽn ban đầu là một thông số TCP quan trọng trong việc xác định tốc độ kết thúc của luồng dữ liệu. Mặc dù tốc độ truy cập mạng trên toàn cầu tăng trung bình đáng kể trong thập kỷ qua, giá trị tiêu chuẩn của giai đoạn chặn nghẽn ban đầu của TCP vẫn không thay đổi. Trong bài viết này, chúng tôi đề xuất tăng cửa sổ tắc nghẽn ban đầu của TCP lên ít nhất 10 phân đoạn (khoảng 15 KB). Thông qua các thử nghiệm Internet trên quy mô lớn, chúng tôi định lượng được lợi ích và chi phí của độ trễ khi sử dụng cửa sổ lớn hơn, dưới dạng các hàm của băng thông mạng, thời gian trọn vòng (RTT), sản phẩm có độ trễ băng thông (BDP) và bản chất của các ứng dụng. Chúng tôi cho thấy độ trễ trung bình của phản hồi HTTP đã cải thiện khoảng 10%, trong đó các mạng có RTT và BDP cao mang lại nhiều lợi ích nhất. Độ trễ của mạng băng thông thấp cũng được cải thiện đáng kể trong các thử nghiệm của chúng tôi. Tốc độ truyền lại trung bình tăng 0,5% khiêm tốn, với phần lớn mức tăng đến từ các ứng dụng tránh né thuật toán khởi động chậm của TCP bằng cách sử dụng nhiều kết nối đồng thời. Dựa trên kết quả từ các thí nghiệm, chúng tôi cho rằng khoảng thời gian tắc nghẽn ban đầu nên ít nhất là 10 đoạn và cùng được điều tra để chuẩn hoá theo tiêu chuẩn của IETF.
Mở nhanhTCP
Các dịch vụ web hiện nay bị chi phối bởi các luồng TCP quá ngắn nên chúng kết thúc một vài lượt vòng sau khi bắt tay. Sự bắt tay này là một nguồn gây ra độ trễ đáng kể cho các luồng đó. Trong bài viết này, chúng tôi mô tả việc thiết kế, triển khai và triển khai giao thức TCP Fast Open, một cơ chế mới cho phép trao đổi dữ liệu trong quá trình bắt tay ban đầu của TCP. Bằng cách làm như vậy, TCP Fast Open giảm độ trễ mạng của ứng dụng xuống toàn bộ thời gian trọn vòng, giảm độ trễ do những lần chuyển TCP ngắn như vậy gây ra. Chúng tôi giải quyết các vấn đề bảo mật vốn có trong việc cho phép trao đổi dữ liệu trong quá trình bắt tay ba chiều. Chúng tôi sẽ giảm thiểu các vấn đề này bằng cách sử dụng một mã thông báo bảo mật xác minh quyền sở hữu địa chỉ IP. Chúng tôi trình bày chi tiết các cơ chế bảo vệ dự phòng khác cũng như giải quyết các vấn đề mà chúng tôi gặp phải với hộp trung gian, khả năng tương thích ngược cho các ngăn xếp mạng hiện có cũng như việc triển khai gia tăng. Dựa trên dữ liệu phân tích lưu lượng truy cập và mô phỏng mạng, chúng tôi cho thấy rằng TCP Fast Open sẽ giảm độ trễ mạng giao dịch HTTP xuống 15%, thời gian tải toàn bộ trang trung bình hơn 10% và trong một số trường hợp lên tới 40%.
Giảm tỷ lệ cho TCP
Tình trạng mất gói dữ liệu làm tăng độ trễ đối với người dùng web. Khôi phục nhanh là cơ chế chính để TCP phục hồi khi gói dữ liệu bị mất. Trong bài viết này, chúng tôi khám phá một số điểm yếu của thuật toán chuẩn được mô tả trong RFC 3517 và các thuật toán không chuẩn được triển khai trong Linux. Chúng tôi nhận thấy rằng những thuật toán này sai lệch so với hành vi dự định của chúng trong thế giới thực do tác động kết hợp của các luồng ngắn, các gian hàng ứng dụng, tổn thất liên tục, mất xác nhận (ACK) và sắp xếp lại thứ tự cũng như kéo dài ACK. Linux bị giảm cửa sổ tắc nghẽn quá mức trong khi RFC 3517 truyền các loạt lớn với tổn thất cao, cả hai đều gây hại cho phần còn lại của luồng và làm tăng độ trễ của web. Nội dung đóng góp chính của chúng tôi là một thiết kế mới giúp kiểm soát quá trình truyền dữ liệu trong quá trình phục hồi nhanh, được gọi là giảm tốc độ theo tỷ lệ (PRR). PRR phục hồi sau khi mất dữ liệu một cách nhanh chóng, suôn sẻ và chính xác bằng cách tăng tốc độ truyền lại trên các ACK đã nhận. Ngoài PRR, chúng tôi còn đánh giá thuật toán truyền lại sớm (ER) của TCP để giảm ngưỡng xác nhận trùng lặp đối với các lượt chuyển ngắn và cho thấy rằng việc trì hoãn các lần truyền lại sớm trong một khoảng thời gian ngắn sẽ có hiệu quả trong việc tránh các hoạt động truyền lại giả khi có một chút thay đổi sắp xếp lại. PRR và ER giúp giảm độ trễ TCP của các kết nối bị mất từ 3 đến 10% tuỳ thuộc vào kích thước phản hồi. Dựa trên công cụ đo lường của chúng tôi trên các máy chủ của Google Web và YouTube tại Hoa Kỳ và Ấn Độ, chúng tôi cũng trình bày số liệu thống kê quan trọng về bản chất của việc truyền lại TCP.
C TCP
Laminar là một khung mới để kiểm soát tình trạng tắc nghẽn của TCP, tách biệt việc lập lịch truyền tải, giúp xác định chính xác thời điểm gửi dữ liệu và kiểm soát tình trạng tắc nghẽn thuần tuý (xác định tổng lượng dữ liệu được gửi trong mỗi RTT). Laminar dự kiến sẽ mang lại các thuật toán nâng cao mới để điều chỉnh chính xác hơn lưu lượng truy cập TCP.
Bản nháp SSL và TLS
Khởi động giả liên quan đến Bảo mật tầng truyền tải (TLS)
False Start là một hành vi không bắt buộc của quá trình triển khai TLS. Chế độ cài đặt này chỉ ảnh hưởng đến thời gian của giao thức, chứ không ảnh hưởng đến dữ liệu giao thức trực tuyến, và có thể được triển khai đơn phương. Tính năng TLS False Start giúp giảm độ trễ một vòng khứ hồi đối với một số quá trình bắt tay.
Tiện ích mở rộng thương lượng về giao thức bảo mật tầng truyền tải (TLS) tiếp theo
Tiện ích Bảo mật tầng truyền tải (TLS) dùng để thương lượng giao thức lớp ứng dụng. Điều này cho phép lớp ứng dụng thương lượng xem giao thức nào cần được thực hiện qua kết nối an toàn theo cách tránh được các lượt trọn vòng bổ sung và giao thức nào độc lập với các giao thức lớp ứng dụng.
Bản nháp DNS
Mạng con của ứng dụng trong các yêu cầu DNS
Bản nháp này xác định một tiện ích EDNS0 để truyền thông tin về mạng bắt nguồn từ truy vấn DNS và mạng mà thư trả lời có thể được lưu vào bộ nhớ đệm.