Delivery Hero tăng tốc ứng dụng giao đồ ăn nhờ HTTP/3 và Cloudflare

Khi khách hàng đặt món qua điện thoại, mỗi giây chờ đợi để ứng dụng tải xong cũng là một trải nghiệm bị lãng phí. Tại hội nghị trực tuyến P99 2026, kỹ sư cấp cao Elvis Chidera của Delivery Hero đã chia sẻ cách công ty giao hàng toàn cầu có trụ sở tại Đức chuyển phần lớn người dùng sang HTTP/3, qua đó giảm 17% tổng thời gian phản hồi từ đầu đến cuối của màn hình chính.

Theo Chidera, người trực tiếp quản lý dự án, HTTP/3 đúng như lời đồn: nhanh hơn HTTP/2, nhưng vẫn có những điểm chậm cần được xử lý khéo léo mới phát huy hết hiệu quả.

Bối cảnh của một nền tảng đa thị trường

Delivery Hero gần như không được biết đến ở Mỹ, nơi thị trường do Uber Eats và DoorDash thống trị. Tuy nhiên, công ty này có tầm phủ toàn cầu bên ngoài nước Mỹ với ước tính khoảng 60 triệu người dùng trải khắp châu Âu, Mỹ Latinh, châu Phi, Trung Đông và châu Á.

Hiện Uber đang trong quá trình thâu tóm Delivery Hero với giá 14,8 tỷ USD, dự kiến sáp nhập với Uber Eats. Thương vụ này sẽ mở rộng số thị trường mà Uber cung cấp cả dịch vụ gọi xe lẫn giao hàng.

Delivery Hero vận hành tập trung nhiều ứng dụng riêng biệt cho từng khu vực, tất cả đều do công ty tự xây dựng hoặc mua lại:

• Foodpanda phục vụ người dùng châu Á
• Yemeksepeti phục vụ người dùng Thổ Nhĩ Kỳ
• Glovo hoạt động tại Tây Ban Nha, Ý, Ba Lan, Romania, Ukraine và phần lớn châu Phi
• PedidosYa phục vụ thị trường Mỹ Latinh

Các khu vực này có chất lượng kết nối mạng rất khác nhau — bài toán mà Delivery Hero muốn giảm thiểu. Nút thắt lớn nhất thường nằm ở mạng chặng cuối (last mile). Chẳng hạn, tại Pakistan, ứng dụng có thể mất gần một giây (ở mức p90) chỉ để thiết lập bắt tay bảo mật với máy chủ. Đội ngũ kỹ thuật đã xem HTTP/3 là giải pháp để kéo giảm, thậm chí xóa bỏ hoàn toàn độ trễ này.

HTTP/3 nhanh hơn nhờ QUIC

Nhóm đặc trách kỹ thuật Internet (IETF) chính thức giới thiệu phiên bản thứ ba của giao thức truyền tải siêu văn bản vào năm 2022. HTTP là giao thức tầng ứng dụng kết nối trình duyệt và các tài nguyên với máy chủ trên Internet.

Các phiên bản HTTP trước đây được xây dựng trên giao thức TCP, vốn đảm bảo việc truyền tải và kiểm soát luồng dữ liệu. HTTP/3 thay TCP bằng QUIC (Quick UDP Internet Connection) do Google phát triển, nhằm khắc phục một số điểm chậm của TCP.

Về cơ bản, bạn có thể loại bỏ hoàn toàn một giây độ trễ đó. Bạn không muốn phải trả giá bằng hai vòng khứ hồi chỉ để trao đổi dữ liệu nếu có thể làm nhanh hơn.

Điểm mấu chốt là HTTP/3 dựa trên UDP giúp giảm và đôi khi loại bỏ các vòng khứ hồi cần thiết để thiết lập kết nối bảo mật. Ứng dụng có thể lưu bộ nhớ đệm phiên (session ticket) và ở lần kết nối sau, tận dụng khả năng 0-RTT của QUIC để bắt đầu gửi dữ liệu ứng dụng trong khi quá trình bắt tay vẫn đang diễn ra.

Khác với HTTP/2, HTTP/3 không bị tắc nghẽn khi gói tin bị mất hoặc trễ. Không còn hiện tượng chặn đầu hàng (head-of-line blocking) vì dữ liệu được truyền trong nhiều luồng song song thay vì một chuỗi đơn như trước.

Cài đặt dễ, nhưng cần tinh chỉnh

Theo Chidera, việc thiết lập HTTP/3 hóa ra lại dễ một cách đáng ngạc nhiên. Delivery Hero vốn đã dùng mạng phân phối nội dung (CDN) của Cloudflare để phục vụ người dùng toàn cầu, nên chuyển sang HTTP/3 chỉ là một thao tác cấu hình lại đơn giản.

Việc bổ sung hỗ trợ HTTP/3 cho phía máy khách, chủ yếu là thiết bị di động, cũng khá suôn sẻ. Apple đã hỗ trợ HTTP/3 từ iOS 15 và hầu hết trình duyệt gốc đều dùng được ngay.

Android lại rắc rối hơn một chút. Đội ngũ dùng thư viện Cronet của Google cho tầng mạng, ban đầu tích hợp vào ứng dụng Android thông qua lớp bọc Cronet Transport for OkHttp nhằm hạn chế việc phải viết lại mã nguồn cũ. Cronet giúp triển khai HTTP/3 và giảm số lần yêu cầu thất bại ở tầng mạng. Tuy nhiên, nó đi kèm một vấn đề đáng kể: công cụ mất khoảng 800 mili giây để khởi tạo ở mức p90, làm xói mòn lợi ích tốc độ 0-RTT của HTTP/3.

Để giải quyết, nhóm kỹ thuật đã fork mã nguồn thành một cầu nối riêng có tên OKCronet, đồng thời chồng chéo quá trình khởi tạo Cronet với các tác vụ nền khác.

Kết quả tổng thể rất ấn tượng:

• Độ trễ p95 giảm từ 1,2 giây xuống còn 120 mili giây, tức cải thiện gấp 10 lần
• 95% người dùng được chuyển sang HTTP/3
• Độ trễ bắt tay giảm 51%
• Thời gian phản hồi tại Pakistan giảm một nửa

Những thiết bị không dùng được giao thức mới (chủ yếu do mạng chặn lưu lượng UDP) sẽ tự động quay về HTTP/2.

Bài toán thuật toán kiểm soát tắc nghẽn

Vẫn còn một trở ngại. Các màn hình phụ trong một số ứng dụng (không phải trang chủ) gặp vấn đề độ trễ, và chỉ xảy ra ở những thị trường dễ mất gói tin như Pakistan.

Đội ngũ Delivery Hero cho rằng nguyên nhân nằm ở thuật toán kiểm soát tắc nghẽn mà Cloudflare chọn cho HTTP/3 là Cubic, vốn xử lý mất gói tin không tốt. Khi thử nghiệm một phần lưu lượng với máy chủ Google hỗ trợ HTTP/3 — nơi dùng thuật toán BBR (Bottleneck Bandwidth and Round-trip propagation time) — họ không gặp vấn đề tương tự.

Delivery Hero hiện đang phối hợp với Cloudflare để giải quyết vấn đề thuật toán kiểm soát tắc nghẽn này. Bài học rút ra cho các đội ngũ kỹ thuật tại Việt Nam cũng khá rõ ràng: khi tối ưu hạ tầng mạng cho ứng dụng di động phục vụ người dùng có điều kiện kết nối không đồng đều, việc lựa chọn giao thức mới chỉ là bước đầu — tinh chỉnh thư viện, xử lý khởi tạo và chọn đúng thuật toán kiểm soát tắc nghẽn mới là yếu tố quyết định thành bại.