Cloudflare Origin Range Requests: tối ưu cache tệp lớn ra sao?

Một người xem tua đến giữa video chỉ cần vài MB, nhưng cache cấu hình kém có thể kéo hàng trăm MB từ máy chủ gốc. Tình huống tương tự xảy ra khi tải tiếp file ISO, lấy metadata trong archive hoặc đọc một phần model AI. Quản trị hệ thống cần tối ưu phần dữ liệu thực sự được yêu cầu, không chỉ tăng băng thông.

Ngày 23/10/2026, Cloudflare mở Origin Range Requests dưới dạng tính năng tự phục vụ cho mọi gói. Tính năng dùng kiến trúc cache dựa trên Pingora để xử lý yêu cầu byte-range mà không bắt khách hàng chọn kích thước range cố định.

HTTP Range giải quyết việc gì?

Client gửi header Range để xin một đoạn byte của tài nguyên. Nếu máy chủ hỗ trợ, phản hồi thường là 206 Partial Content kèm Content-Range. Video player dùng cơ chế này khi tua; trình tải dùng nó để tiếp tục sau gián đoạn; kho gói hoặc workload AI có thể lấy một vùng nhỏ của tệp lớn.

GET /model.bin HTTP/1.1
Host: example.com
Range: bytes=1048576-2097151

Cách cũ ánh xạ yêu cầu vào range có kích thước được cấu hình. Range quá nhỏ tạo nhiều lượt gọi origin; range quá lớn tải thừa. Cloudflare nêu ví dụ cấu hình 64 MiB của R2: một yêu cầu nhỏ cắt qua ranh giới có thể kéo 128 MiB giữa các trung tâm dữ liệu.

Kiến trúc mới giới hạn phần tải thừa

Pingora đã lưu tệp cache thành các chunk cố định để có thể tiếp tục tải. Origin Range Requests tận dụng chính chunk này: kiểm tra byte nào đã có, lấy phần thiếu theo ranh giới chunk, lưu lại rồi chỉ trả đúng đoạn client yêu cầu. Nếu một lượt tải đang diễn ra đã bao phủ đoạn cần thiết, yêu cầu sau có thể gắn vào thay vì mở lượt tải origin mới.

Hệ thống còn kiểm tra kích thước tài nguyên và entity tag để không ghép byte từ hai phiên bản khác nhau. Nếu không thể xử lý range an toàn, nó trả tài nguyên đầy đủ thay vì quảng bá một range sai. Tính năng cũng không biến nội dung vốn không cache được thành nội dung cache được; origin vẫn phải hỗ trợ byte-range.

Đọc đúng số liệu Cloudflare

Sau khi chuyển R2 sang kiến trúc mới, Cloudflare cho biết p99 time to first byte giảm khoảng một nửa trên cả cache hit và miss. Một cải tiến tiếp theo giảm khoảng 6% lưu lượng tiered cache theo tuần cho R2 và workload tương tự. Đây là số liệu nội bộ của Cloudflare, không phải cam kết rằng website bất kỳ sẽ đạt cùng tỷ lệ.

Checklist triển khai không làm origin quá tải

1. Ghi lại tỷ lệ phản hồi 200, 206 và 416 trước khi thay đổi.
2. Kiểm tra origin hỗ trợ Range, ETag và Content-Length nhất quán.
3. Tách rule cho đuôi file hoặc đường dẫn lớn; không bật toàn site ngay.
4. Đo cache hit, byte lấy từ origin, request count, p95/p99 và lỗi hủy giữa chừng.
5. Thử đồng thời nhiều request vào cùng một file và các đoạn chồng lấn.
6. Kiểm tra hành vi khi file thay đổi trong lúc đang tải và khi cache bị xóa.
7. So sánh chi phí CDN với lưu lượng origin thay vì chỉ nhìn tốc độ phía người dùng.

Với máy chủ tại Việt Nam, CDN giúp giảm lượt truyền quốc tế cho nội dung được cache, nhưng không chữa được origin thiếu IOPS, ứng dụng sinh file động chậm hoặc cache-control sai. Đọc thêm băng thông trong nước và quốc tế và monitoring máy chủ để tách nghẽn mạng khỏi nghẽn lưu trữ.

Đội vận hành có thể gửi mẫu URL, kích thước file, header cache, log 200/206, lưu lượng giờ cao điểm và vị trí người dùng tới hotro@thuemaychu.vn. Nếu origin cần tài nguyên riêng, tham khảo bảng giá máy chủ; việc chọn cấu hình chỉ nên thực hiện sau khi xác định điểm nghẽn.

Nguồn tham khảo

• Cloudflare Blog: Origin Range Requests, đăng và ra mắt 23/10/2026