Giao thức QUIC cực kỳ thú vị để xem, đó là lý do tại sao chúng tôi thích viết về nó. Nhưng nếu các ấn phẩm trước đây về QUIC thiên về tính chất lịch sử (lịch sử địa phương, nếu bạn muốn) và phần cứng, thì hôm nay chúng tôi rất vui được xuất bản một bản dịch thuộc loại khác - chúng tôi sẽ nói về ứng dụng thực sự của giao thức vào năm 2019. Hơn nữa, chúng ta không nói về cơ sở hạ tầng nhỏ dựa trên cái gọi là gara, mà là về Uber, công ty hoạt động gần như trên toàn thế giới. Làm thế nào các kỹ sư của công ty đi đến quyết định sử dụng QUIC trong sản xuất, cách họ thực hiện các thử nghiệm và những gì họ thấy sau khi đưa nó vào sản xuất - dưới mức cắt giảm.
Những hình ảnh có thể nhấp vào được. Thích đọc sách!
Uber có quy mô toàn cầu, cụ thể là có mặt tại 600 thành phố, trong đó ứng dụng hoàn toàn dựa vào Internet không dây từ hơn 4500 nhà khai thác di động. Người dùng mong đợi ứng dụng không chỉ nhanh mà còn phải chạy theo thời gian thực - để đạt được điều này, ứng dụng Uber cần có độ trễ thấp và kết nối rất đáng tin cậy. Than ôi, nhưng ngăn xếp không hoạt động tốt trong các mạng không dây động và dễ bị mất dữ liệu. Chúng tôi nhận thấy rằng trong trường hợp này, hiệu suất thấp có liên quan trực tiếp đến việc triển khai TCP trong nhân hệ điều hành.
Để giải quyết vấn đề người ta đã áp dụng , một giao thức ghép kênh hiện đại cho phép chúng ta kiểm soát nhiều hơn hiệu suất của giao thức truyền tải. Hiện nay nhóm công tác tiêu chuẩn hóa QUIC như .
Sau khi thử nghiệm rộng rãi, chúng tôi kết luận rằng việc triển khai QUIC trong ứng dụng của mình sẽ mang lại độ trễ thấp hơn so với TCP. Chúng tôi nhận thấy lưu lượng truy cập HTTPS trong ứng dụng dành cho người lái xe và hành khách đã giảm trong khoảng 10-30%. QUIC cũng trao cho chúng tôi quyền kiểm soát từ đầu đến cuối đối với các gói người dùng.
Trong bài viết này, chúng tôi chia sẻ kinh nghiệm của mình trong việc tối ưu hóa TCP cho các ứng dụng Uber bằng cách sử dụng ngăn xếp hỗ trợ QUIC.
Công nghệ mới nhất: TCP
Ngày nay, TCP là giao thức truyền tải được sử dụng nhiều nhất để phân phối lưu lượng HTTPS trên Internet. TCP cung cấp luồng byte đáng tin cậy, do đó giải quyết được tình trạng tắc nghẽn mạng và mất mát lớp liên kết. Việc sử dụng rộng rãi TCP cho lưu lượng HTTPS là do tính phổ biến của TCP (hầu hết mọi hệ điều hành đều chứa TCP), tính khả dụng trên hầu hết cơ sở hạ tầng (chẳng hạn như bộ cân bằng tải, proxy HTTPS và CDN) và chức năng sẵn có có sẵn trên hầu hết các nền tảng và mạng.
Hầu hết người dùng sử dụng ứng dụng của chúng tôi khi đang di chuyển và độ trễ ở đuôi TCP không bằng nhu cầu về lưu lượng HTTPS theo thời gian thực của chúng tôi. Nói một cách đơn giản, người dùng trên toàn thế giới đã trải qua điều này - Hình 1 cho thấy sự chậm trễ ở các thành phố lớn:
Hình 1: Độ trễ đuôi khác nhau giữa các thành phố chính của Uber.
Mặc dù độ trễ trong mạng Ấn Độ và Brazil cao hơn ở Hoa Kỳ và Vương quốc Anh, nhưng độ trễ ở đuôi cao hơn đáng kể so với độ trễ trung bình. Và điều này đúng ngay cả với Hoa Kỳ và Vương quốc Anh.
Hiệu suất TCP qua mạng
TCP được tạo ra cho có dây mạng, nghĩa là tập trung vào các liên kết có khả năng dự đoán cao. Tuy nhiên, không dây mạng có những đặc điểm và khó khăn riêng. Đầu tiên, mạng không dây dễ bị tổn thất do nhiễu và suy giảm tín hiệu. Ví dụ: mạng Wi-Fi rất nhạy cảm với sóng vi ba, bluetooth và các sóng vô tuyến khác. Mạng di động bị mất tín hiệu () do sự phản xạ/hấp thụ tín hiệu của các vật thể và tòa nhà, cũng như từ từ nước láng giềng . Điều này dẫn đến ý nghĩa hơn (4-10 lần) và đa dạng hơn và mất gói so với kết nối có dây.
Để chống lại sự dao động và tổn thất băng thông, mạng di động thường sử dụng bộ đệm lớn cho các đợt bùng phát lưu lượng. Điều này có thể dẫn đến việc xếp hàng quá nhiều, đồng nghĩa với việc độ trễ sẽ kéo dài hơn. TCP thường coi việc xếp hàng này là lãng phí do thời gian chờ kéo dài, do đó TCP có xu hướng chuyển tiếp và do đó lấp đầy bộ đệm. Vấn đề này được gọi là () và điều này rất Internet hiện đại.
Cuối cùng, hiệu suất mạng di động thay đổi tùy theo nhà cung cấp dịch vụ, khu vực và thời gian. Trong Hình 2, chúng tôi đã thu thập độ trễ trung bình của lưu lượng HTTPS trên các ô trong phạm vi 2 km. Dữ liệu được thu thập từ hai nhà khai thác di động lớn ở Delhi, Ấn Độ. Như bạn có thể thấy, hiệu suất thay đổi tùy theo từng ô. Ngoài ra, năng suất của người vận hành này khác với năng suất của người vận hành thứ hai. Điều này bị ảnh hưởng bởi các yếu tố như mô hình truy cập mạng có tính đến thời gian và vị trí, tính di động của người dùng cũng như cơ sở hạ tầng mạng có tính đến mật độ tháp và tỷ lệ các loại mạng (LTE, 3G, v.v.).
Hình 2. Độ trễ sử dụng bán kính 2 km làm ví dụ. Delhi, Ấn Độ.
Ngoài ra, hiệu suất của mạng di động thay đổi theo thời gian. Hình 3 cho thấy độ trễ trung bình theo ngày trong tuần. Chúng tôi cũng quan sát thấy sự khác biệt ở quy mô nhỏ hơn, trong vòng một ngày và một giờ.
Hình 3. Độ trễ ở đuôi có thể khác nhau đáng kể giữa các ngày, nhưng đối với cùng một nhà điều hành.
Tất cả những điều trên khiến hiệu suất TCP không hiệu quả trong mạng không dây. Tuy nhiên, trước khi tìm kiếm các giải pháp thay thế cho TCP, chúng tôi muốn hiểu rõ hơn về các điểm sau:
- TCP có phải là thủ phạm chính đằng sau độ trễ đuôi trong ứng dụng của chúng tôi không?
- Các mạng hiện đại có độ trễ khứ hồi (RTT) đáng kể và đa dạng không?
- Tác động của RTT và mất mát đối với hiệu suất TCP là gì?
Phân tích hiệu suất TCP
Để hiểu cách chúng tôi phân tích hiệu suất TCP, hãy xem nhanh cách TCP truyền dữ liệu từ người gửi đến người nhận. Đầu tiên, người gửi thiết lập kết nối TCP, thực hiện giao dịch ba chiều : Người gửi gửi gói SYN, đợi gói SYN-ACK từ người nhận, sau đó gửi gói ACK. Lượt thứ hai và thứ ba bổ sung được dành để thiết lập kết nối TCP. Người nhận xác nhận đã nhận từng gói (ACK) để đảm bảo việc gửi tin cậy.
Nếu gói hoặc ACK bị mất, người gửi sẽ truyền lại sau một khoảng thời gian chờ (RTO, ). RTO được tính toán linh hoạt dựa trên nhiều yếu tố khác nhau, chẳng hạn như độ trễ RTT dự kiến giữa người gửi và người nhận.
Hình 4. Trao đổi gói qua TCP/TLS bao gồm cơ chế truyền lại.
Để xác định cách thức hoạt động của TCP trong các ứng dụng của chúng tôi, chúng tôi đã theo dõi các gói TCP bằng cách sử dụng trong một tuần do lưu lượng truy cập chiến đấu đến từ các máy chủ biên của Ấn Độ. Sau đó chúng tôi đã phân tích các kết nối TCP bằng cách sử dụng . Ngoài ra, chúng tôi đã tạo một ứng dụng Android gửi lưu lượng truy cập mô phỏng đến máy chủ thử nghiệm, bắt chước lưu lượng truy cập thực nhiều nhất có thể. Điện thoại thông minh có ứng dụng này đã được phân phát cho một số nhân viên, những người này đã thu thập nhật ký trong vài ngày.
Kết quả của cả hai thí nghiệm đều phù hợp với nhau. Chúng tôi thấy độ trễ RTT cao; giá trị đuôi cao hơn gần 6 lần so với giá trị trung bình; trung bình số học của độ trễ là hơn 1 giây. Nhiều kết nối bị mất, khiến TCP phải truyền lại 3,5% tổng số gói. Ở những khu vực tắc nghẽn như sân bay và nhà ga, chúng tôi thấy tổn thất 7%. Những kết quả này đặt ra nghi ngờ về quan điểm thông thường mà những kết quả được sử dụng trong mạng di động giảm đáng kể tổn thất ở cấp độ vận chuyển. Dưới đây là kết quả thử nghiệm từ ứng dụng “giả lập”:
Số liệu mạng
Giá trị
RTT, mili giây [50%,75%, 95%,99%]
[350, 425, 725, 2300]
Phân kỳ RTT, giây
Trung bình ~1,2 giây
Mất gói trên các kết nối không ổn định
Trung bình ~3.5% (7% ở khu vực quá tải)
Gần một nửa số kết nối này bị mất ít nhất một gói, hầu hết là các gói SYN và SYN-ACK. Hầu hết việc triển khai TCP sử dụng giá trị RTO là 1 giây cho các gói SYN, giá trị này sẽ tăng theo cấp số nhân đối với các tổn thất tiếp theo. Thời gian tải ứng dụng có thể tăng do TCP mất nhiều thời gian hơn để thiết lập kết nối.
Trong trường hợp gói dữ liệu, giá trị RTO cao làm giảm đáng kể việc sử dụng mạng hữu ích khi có hiện tượng mất mát tạm thời trong mạng không dây. Chúng tôi thấy rằng thời gian truyền lại trung bình là khoảng 1 giây với độ trễ ở đuôi gần 30 giây. Những độ trễ cao này ở cấp độ TCP đã gây ra tình trạng hết thời gian chờ và yêu cầu lại HTTPS, làm tăng thêm độ trễ và tính kém hiệu quả của mạng.
Trong khi phân vị thứ 75 của RTT đo được là khoảng 425 ms thì phân vị thứ 75 của TCP là gần 3 giây. Điều này gợi ý rằng sự mất mát đã khiến TCP phải mất 7-10 lần để truyền dữ liệu thành công. Đây có thể là hệ quả của việc tính toán RTO không hiệu quả, TCP không có khả năng phản ứng nhanh khi bị mất trong cửa sổ và sự kém hiệu quả của thuật toán kiểm soát tắc nghẽn, không phân biệt giữa tổn thất không dây và tổn thất do tắc nghẽn mạng. Dưới đây là kết quả kiểm tra mất TCP:
Thống kê mất gói TCP
Giá trị
Tỷ lệ kết nối bị mất ít nhất 1 gói
45%
Tỷ lệ kết nối bị mất trong quá trình thiết lập kết nối
30%
Tỷ lệ kết nối bị mất trong quá trình trao đổi dữ liệu
76%
Phân bổ độ trễ khi truyền lại, giây [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Phân phối số lần truyền lại cho một gói hoặc phân đoạn TCP
[1,3,6,7]
Ứng dụng QUIC
Được phát triển ban đầu bởi Google, QUIC là một giao thức truyền tải hiện đại đa luồng chạy trên UDP. Hiện nay QUIC đang ở (chúng tôi đã viết rằng hiện tại có hai phiên bản QUIC, gây tò mò – khoảng. người dịch). Như được hiển thị trong Hình 5, QUIC được đặt dưới HTTP/3 (trên thực tế, HTTP/2 trên QUIC là HTTP/3, hiện đang được tiêu chuẩn hóa chuyên sâu). Nó thay thế một phần các lớp HTTPS và TCP bằng cách sử dụng UDP để tạo thành các gói. QUIC chỉ hỗ trợ truyền dữ liệu an toàn vì TLS được tích hợp hoàn toàn vào QUIC.
Hình 5: QUIC chạy dưới HTTP/3, thay thế TLS, trước đây chạy dưới HTTP/2.
Dưới đây là những lý do thuyết phục chúng tôi sử dụng QUIC để khuếch đại TCP:
- Thiết lập kết nối 0-RTT. QUIC cho phép sử dụng lại các ủy quyền từ các kết nối trước đó, giảm số lần bắt tay bảo mật. Trong tương lai sẽ hỗ trợ 0-RTT, nhưng vẫn cần phải bắt tay TCP ba chiều.
- khắc phục tình trạng chặn HoL. HTTP/2 sử dụng một kết nối TCP cho mỗi máy khách để cải thiện hiệu suất, nhưng điều này có thể dẫn đến chặn HoL (head-of-line). QUIC đơn giản hóa việc ghép kênh và gửi yêu cầu đến ứng dụng một cách độc lập.
- điều khiển tắc nghẽn. QUIC nằm ở lớp ứng dụng, giúp cập nhật thuật toán truyền tải chính kiểm soát việc gửi dựa trên các tham số mạng (số lượng tổn thất hoặc RTT) dễ dàng hơn. Hầu hết việc triển khai TCP đều sử dụng thuật toán , điều này không tối ưu cho lưu lượng truy cập nhạy cảm với độ trễ. Các thuật toán được phát triển gần đây như , mô hình hóa mạng chính xác hơn và tối ưu hóa độ trễ. QUIC cho phép bạn sử dụng BBR và cập nhật thuật toán này khi nó được sử dụng. .
- bù đắp tổn thất. QUIC gọi hai TLP () trước khi RTO được kích hoạt - ngay cả khi tổn thất rất đáng chú ý. Điều này khác với việc triển khai TCP. TLP chủ yếu truyền lại gói cuối cùng (hoặc gói mới, nếu có) để kích hoạt việc bổ sung nhanh chóng. Xử lý độ trễ đuôi đặc biệt hữu ích đối với cách Uber vận hành mạng của mình, cụ thể là đối với việc truyền dữ liệu ngắn, rời rạc và nhạy cảm với độ trễ.
- ACK được tối ưu hóa Vì mỗi gói có một số thứ tự duy nhất nên không có vấn đề gì các gói tin khi chúng được truyền lại. Các gói ACK cũng chứa thời gian để xử lý gói và tạo ACK ở phía máy khách. Những tính năng này đảm bảo QUIC tính toán RTT chính xác hơn. ACK trong QUIC hỗ trợ tới 256 băng tần , giúp người gửi linh hoạt hơn trong việc xáo trộn gói và sử dụng ít byte hơn trong quy trình. ACK chọn lọc () trong TCP không giải quyết được vấn đề này trong mọi trường hợp.
- di chuyển kết nối. Các kết nối QUIC được xác định bằng ID 64 bit, vì vậy nếu máy khách thay đổi địa chỉ IP, ID kết nối cũ có thể tiếp tục được sử dụng trên địa chỉ IP mới mà không bị gián đoạn. Đây là một thực tế rất phổ biến đối với các ứng dụng di động nơi người dùng chuyển đổi giữa kết nối Wi-Fi và kết nối di động.
Các lựa chọn thay thế cho QUIC
Chúng tôi đã xem xét các phương pháp thay thế để giải quyết vấn đề trước khi chọn QUIC.
Điều đầu tiên chúng tôi thử là triển khai TPC PoP (Điểm hiện diện) để chấm dứt các kết nối TCP gần hơn với người dùng. Về cơ bản, PoP chấm dứt kết nối TCP với thiết bị di động gần mạng di động hơn và ủy quyền lưu lượng truy cập trở lại cơ sở hạ tầng ban đầu. Bằng cách chấm dứt TCP gần hơn, chúng tôi có thể giảm RTT và đảm bảo rằng TCP phản ứng nhanh hơn với môi trường không dây động. Tuy nhiên, các thử nghiệm của chúng tôi đã chỉ ra rằng hầu hết RTT và tổn thất đều đến từ mạng di động và việc sử dụng PoP không mang lại cải thiện hiệu suất đáng kể.
Chúng tôi cũng đã xem xét việc điều chỉnh các tham số TCP. Việc thiết lập ngăn xếp TCP trên các máy chủ biên không đồng nhất của chúng tôi rất khó khăn vì TCP có cách triển khai khác nhau trên các phiên bản hệ điều hành khác nhau. Rất khó để thực hiện điều này và kiểm tra các cấu hình mạng khác nhau. Không thể định cấu hình TCP trực tiếp trên thiết bị di động do thiếu quyền. Quan trọng hơn, các tính năng như kết nối 0-RTT và dự đoán RTT được cải thiện rất quan trọng đối với kiến trúc của giao thức và do đó không thể đạt được những lợi ích đáng kể chỉ bằng cách điều chỉnh TCP.
Cuối cùng, chúng tôi đã đánh giá một số giao thức dựa trên UDP để khắc phục sự cố truyền phát video—chúng tôi muốn xem liệu các giao thức này có hữu ích trong trường hợp của chúng tôi hay không. Thật không may, họ thiếu nghiêm trọng nhiều cài đặt bảo mật và cũng yêu cầu kết nối TCP bổ sung cho siêu dữ liệu và thông tin kiểm soát.
Nghiên cứu của chúng tôi đã chỉ ra rằng QUIC có lẽ là giao thức duy nhất có thể giúp giải quyết vấn đề lưu lượng truy cập Internet, đồng thời tính đến cả bảo mật và hiệu suất.
Tích hợp QUIC vào nền tảng
Để nhúng QUIC thành công và cải thiện hiệu suất ứng dụng trong môi trường kết nối kém, chúng tôi đã thay thế ngăn xếp cũ (HTTP/2 thay vì TLS/TCP) bằng giao thức QUIC. Chúng tôi đã sử dụng thư viện mạng của , chứa phiên bản gốc của giao thức Google - gQUIC. Việc triển khai này cũng liên tục được cải tiến để tuân theo đặc tả IETF mới nhất.
Lần đầu tiên chúng tôi tích hợp Cronet vào các ứng dụng Android của mình để hỗ trợ thêm cho QUIC. Việc tích hợp được thực hiện theo cách giảm chi phí di chuyển nhiều nhất có thể. Thay vì thay thế hoàn toàn ngăn xếp mạng cũ đã sử dụng thư viện , chúng tôi đã tích hợp Cronet THEO khung API OkHttp. Bằng cách thực hiện tích hợp theo cách này, chúng tôi đã tránh được những thay đổi đối với cuộc gọi mạng của mình (được sử dụng bởi ) ở cấp độ API.
Tương tự như phương pháp dành cho thiết bị Android, chúng tôi đã triển khai Cronet vào ứng dụng Uber trên iOS, chặn lưu lượng HTTP từ mạng sử dụng . Bản tóm tắt này do iOS Foundation cung cấp, xử lý dữ liệu URL theo giao thức cụ thể và đảm bảo rằng chúng tôi có thể tích hợp Cronet vào các ứng dụng iOS của mình mà không phải trả chi phí di chuyển đáng kể.
Hoàn thành QUIC trên Google Cloud Balancers
Về phía phụ trợ, quá trình hoàn thành QUIC được cung cấp bởi cơ sở hạ tầng cân bằng tải Google Cloud, sử dụng tiêu đề trong phản hồi để hỗ trợ QUIC. Nói chung, bộ cân bằng thêm tiêu đề alt-svc vào mỗi yêu cầu HTTP và điều này đã xác thực hỗ trợ QUIC cho miền. Khi ứng dụng khách Cronet nhận được phản hồi HTTP với tiêu đề này, nó sẽ sử dụng QUIC cho các yêu cầu HTTP tiếp theo tới miền đó. Sau khi bộ cân bằng hoàn thành QUIC, cơ sở hạ tầng của chúng tôi sẽ gửi hành động này một cách rõ ràng qua HTTP2/TCP đến trung tâm dữ liệu của chúng tôi.
Hiệu suất: Kết quả
Hiệu suất đầu ra là lý do chính để chúng tôi tìm kiếm một giao thức tốt hơn. Để bắt đầu, chúng tôi đã tạo ra một lập trường với để tìm hiểu QUIC sẽ hoạt động như thế nào trong các cấu hình mạng khác nhau. Để kiểm tra hiệu suất của QUIC trên các mạng trong thế giới thực, chúng tôi đã chạy thử nghiệm khi lái xe quanh New Delhi bằng cách sử dụng lưu lượng truy cập mạng được mô phỏng rất giống với các cuộc gọi HTTP trong ứng dụng hành khách.
Thí nghiệm 1
Thiết bị thí nghiệm:
- kiểm tra các thiết bị Android có ngăn xếp OkHttp và Cronet để đảm bảo rằng chúng tôi cho phép lưu lượng HTTPS qua TCP và QUIC tương ứng;
- một máy chủ mô phỏng dựa trên Java gửi cùng loại tiêu đề HTTPS trong phản hồi và tải các thiết bị khách để nhận yêu cầu từ chúng;
- proxy đám mây có vị trí thực tế gần Ấn Độ để chấm dứt kết nối TCP và QUIC. Trong khi để chấm dứt TCP, chúng tôi đã sử dụng proxy ngược trên , thật khó để tìm được proxy ngược nguồn mở cho QUIC. Chúng tôi đã tự xây dựng proxy ngược cho QUIC bằng cách sử dụng ngăn xếp QUIC cơ bản từ Chrome và nó thành crom dưới dạng nguồn mở.
Hình 6. Bộ thử nghiệm đường TCP và QUIC bao gồm các thiết bị Android có OkHttp và Cronet, proxy đám mây để chấm dứt kết nối và máy chủ mô phỏng.
Thí nghiệm 2
Khi Google cung cấp QUIC với , chúng tôi đã sử dụng cùng một khoảng không quảng cáo nhưng có một sửa đổi: thay vì NGINX, chúng tôi sử dụng bộ cân bằng tải của Google để chấm dứt kết nối TCP và QUIC khỏi thiết bị cũng như định tuyến lưu lượng HTTPS đến máy chủ mô phỏng. Bộ cân bằng được phân phối trên toàn thế giới nhưng sử dụng máy chủ PoP gần thiết bị nhất (nhờ định vị địa lý).
Hình 7. Trong thử nghiệm thứ hai, chúng tôi muốn so sánh độ trễ hoàn thành của TCP và QUIC: sử dụng Google Cloud và sử dụng proxy đám mây của chúng tôi.
Kết quả là, một số điều mặc khải đang chờ đợi chúng ta:
- chấm dứt thông qua PoP đã cải thiện hiệu suất TCP. Vì bộ cân bằng chấm dứt các kết nối TCP gần hơn với người dùng và được tối ưu hóa cao, điều này dẫn đến RTT thấp hơn, giúp cải thiện hiệu suất TCP. Và mặc dù QUIC ít bị ảnh hưởng hơn nhưng nó vẫn hoạt động tốt hơn TCP về việc giảm độ trễ đuôi (10-30%).
- đuôi bị ảnh hưởng . Mặc dù proxy QUIC của chúng tôi cách xa các thiết bị hơn (độ trễ cao hơn khoảng 50 ms) so với bộ cân bằng tải của Google, nhưng nó mang lại hiệu suất tương tự - độ trễ giảm 15% so với mức giảm 20% ở phân vị thứ 99 đối với TCP. Điều này cho thấy quá trình chuyển đổi dặm cuối là một nút cổ chai trong mạng.
Hình 8: Kết quả từ hai thử nghiệm cho thấy QUIC vượt trội hơn đáng kể so với TCP.
Chống giao thông
Lấy cảm hứng từ thử nghiệm, chúng tôi đã triển khai hỗ trợ QUIC trong các ứng dụng Android và iOS của mình. Chúng tôi đã tiến hành thử nghiệm A/B để xác định tác động của QUIC tại các thành phố nơi Uber hoạt động. Nhìn chung, chúng tôi nhận thấy độ trễ ở đuôi đã giảm đáng kể ở cả khu vực, nhà khai thác viễn thông và loại mạng.
Các biểu đồ bên dưới cho thấy mức độ cải thiện phần trăm ở phần cuối (phần trăm 95 và 99) theo vùng vĩ mô và các loại mạng khác nhau - LTE, 3G, 2G.
Hình 9. Trong các thử nghiệm chiến đấu, QUIC vượt trội hơn TCP về độ trễ.
Chỉ tiến về trước
Có lẽ đây mới chỉ là khởi đầu - việc đưa QUIC vào sản xuất đã mang đến những cơ hội tuyệt vời để cải thiện hiệu suất ứng dụng trong cả mạng ổn định và mạng không ổn định, cụ thể là:
Tăng độ phủ sóng
Sau khi phân tích hiệu suất của giao thức trên lưu lượng truy cập thực, chúng tôi thấy rằng khoảng 80% phiên đã sử dụng thành công QUIC cho của tất cả yêu cầu, trong khi 15% số phiên sử dụng kết hợp QUIC và TCP. Chúng tôi giả định rằng sự kết hợp này là do thư viện Cronet hết thời gian chờ trở lại TCP, vì nó không thể phân biệt giữa lỗi UDP thực và điều kiện mạng kém. Chúng tôi hiện đang xem xét giải pháp cho vấn đề này khi chúng tôi nỗ lực triển khai QUIC tiếp theo.
Tối ưu hóa QUIC
Lưu lượng truy cập từ ứng dụng dành cho thiết bị di động nhạy cảm với độ trễ nhưng không nhạy cảm với băng thông. Ngoài ra, các ứng dụng của chúng tôi chủ yếu được sử dụng trên mạng di động. Dựa trên thử nghiệm, độ trễ đuôi vẫn cao mặc dù sử dụng proxy để chấm dứt TCP và QUIC gần với người dùng. Chúng tôi đang tích cực tìm cách cải thiện việc quản lý tắc nghẽn và nâng cao hiệu quả của thuật toán khôi phục tổn thất QUIC.
Với những cải tiến này và một số cải tiến khác, chúng tôi có kế hoạch cải thiện trải nghiệm người dùng bất kể mạng và khu vực, giúp việc vận chuyển gói thuận tiện và liền mạch trở nên dễ tiếp cận hơn trên toàn thế giới.
Nguồn: www.habr.com