Dijkstra June 2018 | Page 21

Tư tưởng thiết kế giao thức QUIC là sự kết hợp giữa TCP và tinh thần của HTTP/2 • Đảm bảo không mất mát, đúng thứ tự gói tin: Tương tự TCP • Cải thiện thuật toán chống nghẽn: Sử dụng thuật toán CUBIC • Tự sửa lỗi gói tin • Hỗ trợ lớp bảo mật TLS việc sử dụng rộng rãi giao thức này còn rất hạn chế. Hiện chỉ có hai trình duyệt hỗ trợ giao thức này là Chromium và Opera. Việc cố gắng xây dựng lại một giao thức lõi của internet của Google là một diễn biến lạ lẫm, họ thử nghiệm QUIC trên những sản phẩm nội bộ của mình (các dịch vụ web và trình duyệt), nhưng Google đủ lớn để biến những cuộc thử nghiệm về công nghệ khiến cả thế giới công nghệ phải ồn ào và học hỏi, thậm chí trở thành chuẩn. Trường hợp đó đã đúng với Ajax, BigTable, SPDY ... và biết đâu đó là QUIC trong tương lai. Hình: QUIC = TLS + TCP + SPDY Mặc dù trong UDP, khái niệm kết nối không tồn tại, nhưng dựa trên tinh thần của TCP, QUIC xây dựng lại kết nối cho mình, tuy nhiên tầng truyền tải dữ liệu sẽ độc lập giữa các stream. Điều này giúp loại bỏ head-of-line block- ing gây ra khi các stream truyền tải dùng chung kết nối. Một điều thú vị là kết nối của QUIC sẽ tốt hơn TCP trong một số trường hợp. Ví dụ khi kết nối mạng của bạn đang sử dụng đột ngột bị ngắt và kết nối lại, trong khi kết nối của TCP sẽ bị mất và buộc phải khởi tạo kết nối mới, thì QUIC do xây dựng trên nền tảng UDP - một giao thức phi kết nối (connectionless) nên về lý thuyết thì kết nối sẽ vẫn tiếp tục truyền nhận dữ liệu bình thường dù sẽ chậm đi một chút. QUIC cũng sử dụng thuật toán chống nghẽn cho từng stream riêng biệt, loại bỏ vấn đề thuật toán chống nghẽn gây ra cho HTTP/2. Đọc và thảo luận bài viết online: https://engineering.grokking.org/ Hình: Giao thức QUIC 2. LỜI KẾT QUIC hiện tại là một phần của dự án Chromium, chưa có một đóng gói độc lập nào để sử dụng giao thức này. Điều này khiến việc sử dụng QUIC rất khó khăn. Mặc dù rất nhiều các dịch vụ của Google hiện tại đã dùng QUIC nhưng DIJSKTRA 21