Tải tệp qua proxy: tiếp tục tải bằng HTTP Range khi mất kết nối

Khi tải tệp qua proxy, kết nối có thể bị ngắt trước khi dữ liệu được nhận đầy đủ. Nếu công cụ tải luôn bắt đầu lại, người dùng phải truyền lại cả phần đã có, làm kéo dài thời gian và phát sinh lưu lượng không cần thiết.

HTTP Range cho phép yêu cầu một phần tài nguyên thay vì toàn bộ nội dung. Tuy nhiên, để tiếp tục tải file an toàn, cần xác nhận máy chủ thực sự trả về đúng đoạn dữ liệu và tệp nguồn chưa thay đổi. Bài viết này trình bày cách kiểm tra, xử lý phản hồi và tổ chức quy trình tải tiếp khi proxy mất kết nối.

HTTP Range giúp tiếp tục tải file như thế nào?

Trong một lượt tải thông thường, trình khách yêu cầu toàn bộ tệp. Nếu kết nối gián đoạn, tệp cục bộ chỉ chứa phần dữ liệu đã nhận và ghi thành công. Thay vì bỏ phần đó, trình khách có thể gửi yêu cầu mới, chỉ lấy phần còn thiếu.

Với phạm vi theo byte, header Range xác định vị trí bắt đầu và có thể kèm vị trí kết thúc. Khi tải tiếp đến cuối tài nguyên, yêu cầu thường chỉ cần chỉ rõ byte bắt đầu.

Vị trí này được tính từ đầu tệp và đánh chỉ số từ không. Nếu tệp cục bộ đã chứa một đoạn dữ liệu liên tục, điểm bắt đầu của yêu cầu tiếp theo bằng chính kích thước đoạn đã lưu, tính theo byte.

Điều kiện quan trọng là tệp nguồn phải giữ nguyên giữa các lượt tải. Nếu nội dung đã thay đổi, ghép phần đầu của phiên bản cũ với phần sau của phiên bản mới sẽ tạo ra tệp không hợp lệ, dù dung lượng cuối cùng có vẻ đầy đủ.

Proxy ảnh hưởng thế nào đến khả năng tải tiếp?

Proxy là thành phần trung gian chuyển tiếp lưu lượng. Khi proxy mất kết nối, phiên truyền hiện tại có thể kết thúc, nhưng điều đó không tự động làm mất khả năng tải tiếp. Trình khách có thể mở kết nối mới và yêu cầu phần dữ liệu còn thiếu.

Khả năng này phụ thuộc vào toàn bộ đường truyền: máy chủ cung cấp tệp, proxy và phần mềm tải. Máy chủ phải xử lý yêu cầu Range phù hợp; proxy phải chuyển tiếp đúng; phần mềm tải phải kiểm tra phản hồi trước khi ghi nối.

Phân biệt proxy chuyển tiếp và proxy kết thúc TLS

Khả năng tải tiếp cần được kiểm tra trên chính tuyến proxy đang sử dụng.

Với HTTPS qua đường hầm CONNECT thông thường, proxy không đọc hoặc sửa trực tiếp header HTTP bên trong kết nối TLS. Khi đó, việc hỗ trợ Range chủ yếu thuộc về máy chủ đích và trình khách.

Nếu proxy kết thúc TLS hoặc xử lý nội dung HTTP, nó có thể tác động đến header, bộ nhớ đệm hoặc biểu diễn tài nguyên. Vì vậy, nên kiểm tra bằng chính tuyến proxy sẽ dùng để tải, thay vì chỉ thử kết nối trực tiếp.

Cách kiểm tra máy chủ có hỗ trợ tải tiếp

Kiểm tra header bằng yêu cầu HEAD

Yêu cầu HEAD cho phép xem header mà không chủ động tải phần thân phản hồi. Với curl, có thể sử dụng mẫu lệnh sau, thay địa chỉ mẫu bằng thông tin thực tế:

curl --head --location --proxy http://proxy.example:PORT https://download.example/archive.zip

Header Accept-Ranges: bytes là dấu hiệu máy chủ công bố hỗ trợ truy xuất theo byte. Nếu phản hồi có Accept-Ranges: none, máy chủ đang thông báo không hỗ trợ phạm vi cho tài nguyên đó.

Tuy nhiên, thiếu Accept-Ranges chưa đủ để kết luận không thể tải tiếp. Một số máy chủ vẫn xử lý Range nhưng không quảng bá khả năng này. HEAD cũng có thể được xử lý khác GET, nên đây chỉ là bước kiểm tra ban đầu.

Gửi yêu cầu GET với phạm vi nhỏ

Yêu cầu một phạm vi nhỏ giúp kiểm tra phản hồi thực tế trước khi tiếp tục tải tệp lớn.

Cách kiểm tra thực tế là yêu cầu một đoạn rất ngắn của tệp và quan sát phản hồi. Ví dụ dưới đây yêu cầu byte đầu tiên, đồng thời lưu header và phần thân vào hai tệp riêng:

curl --location --proxy http://proxy.example:PORT --range 0-0 --dump-header range-headers.txt --output range-probe.bin https://download.example/archive.zip

Máy chủ có thể bỏ qua Range và trả toàn bộ nội dung. Vì vậy, nên thực hiện trong môi trường kiểm thử có giới hạn thời gian hoặc lưu lượng phù hợp, đồng thời theo dõi phản hồi để dừng khi cần.

Nếu có chuyển hướng, cần đọc header của phản hồi cuối cùng chứa dữ liệu tệp. Không nên suy luận từ header của một phản hồi chuyển hướng trung gian.

Hiểu các phản hồi quan trọng của HTTP Range

206 Partial Content: đã trả nội dung từng phần

Mã trạng thái 206 Partial Content cho biết máy chủ trả về nội dung từng phần. Với yêu cầu một phạm vi, header Content-Range mô tả đoạn byte được trả và có thể cho biết tổng kích thước tài nguyên.

Trước khi ghi nối, phải kiểm tra vị trí bắt đầu trong Content-Range có trùng với điểm tải tiếp đã yêu cầu hay không. Chỉ nhìn thấy trạng thái 206 là chưa đủ để bảo đảm dữ liệu có thể ghép đúng.

200 OK: không được tự động ghi nối

Nếu đã gửi Range nhưng nhận 200 OK, phản hồi có thể chứa toàn bộ tài nguyên. Nguyên nhân thường là máy chủ bỏ qua Range hoặc điều kiện xác thực phiên bản không còn phù hợp.

Không ghi nối trực tiếp phần thân phản hồi này vào tệp dở dang. Hãy dừng để kiểm tra hoặc chuyển sang tải lại trong một tệp mới. Nếu không, tệp có thể chứa phần đầu bị lặp lại.

416 Range Not Satisfiable: cần đối chiếu lại trạng thái

Phản hồi 416 Range Not Satisfiable cho biết phạm vi yêu cầu không thể được đáp ứng. Điều này có thể xảy ra khi vị trí bắt đầu nằm ngoài tài nguyên hiện tại hoặc tệp cục bộ đã đủ dữ liệu.

Không nên mặc định coi đây là tải thành công. Cần kiểm tra kích thước máy chủ công bố trong Content-Range nếu có, đối chiếu phiên bản và xác minh tính toàn vẹn trước khi kết luận.

Quy trình tiếp tục tải file khi proxy mất kết nối

Trước khi ghi nối, cần xác định dữ liệu đã lưu và kiểm tra phạm vi cùng phiên bản tài nguyên.

Lưu tệp tạm và thông tin phiên bản

Trong lúc tải, nên sử dụng tên tệp tạm để ứng dụng khác không đọc nhầm tệp chưa hoàn chỉnh. Đồng thời, lưu URL, ETag, Last-Modified và tổng kích thước nếu máy chủ cung cấp.

ETag giúp nhận diện phiên bản tài nguyên. Để sử dụng với If-Range, cần ETag mạnh; không sử dụng ETag yếu có tiền tố W/. Thời điểm sửa đổi cũng có thể được dùng trong những điều kiện HTTP phù hợp, nhưng thường không phải lựa chọn ưu tiên khi có ETag mạnh.

Xác định phần dữ liệu đã ghi thành công

Sau khi kết nối bị ngắt, hãy đóng hoặc đồng bộ tệp trước khi đọc kích thước. Điểm tải tiếp phải dựa trên số byte thực sự lưu trên đĩa, không phải số byte chương trình đã nhận vào bộ nhớ.

Cách này phù hợp với tải tuần tự, khi tệp tạm chứa một đoạn liên tục từ đầu tài nguyên. Nếu tải nhiều luồng, kích thước tệp không chứng minh mọi vùng bên trong đã có dữ liệu; cần theo dõi riêng từng đoạn hoàn tất.

Gửi Range kèm điều kiện If-Range

Trong yêu cầu mới, Range chỉ rõ vị trí tiếp tục, còn If-Range mang giá trị xác thực của phiên bản đã tải. Nếu phiên bản còn phù hợp, máy chủ có thể trả đoạn dữ liệu được yêu cầu.

Nếu phiên bản đã thay đổi, máy chủ có thể trả toàn bộ tài nguyên thay vì phần còn thiếu. Trình khách phải nhận biết phản hồi này và không ghép với dữ liệu cũ.

Chỉ ghi nối sau khi xác thực phản hồi

• Kiểm tra mã trạng thái và Content-Range trước khi mở chế độ ghi nối.
• Đối chiếu vị trí bắt đầu với kích thước phần dữ liệu đã lưu.
• Kiểm tra thông tin phiên bản và biểu diễn nội dung.
• Xử lý phản hồi lỗi, trang đăng nhập hoặc nội dung không phải tệp một cách riêng biệt.
• Khi gián đoạn lần nữa, tính lại điểm tiếp tục từ dữ liệu thực tế.

Tiếp tục tải tệp qua proxy bằng curl

curl hỗ trợ tiếp tục tải dựa trên kích thước tệp đầu ra hiện có bằng tùy chọn --continue-at -. Một mẫu lệnh cơ bản là:

curl --location --proxy http://proxy.example:PORT --continue-at - --output archive.zip.part https://download.example/archive.zip

Nếu kết nối bị ngắt, có thể chạy lại lệnh với cùng tệp đầu ra. curl sẽ xác định điểm tiếp tục từ tệp cục bộ và yêu cầu phần dữ liệu tương ứng.

Tuy nhiên, lệnh này không tự bảo đảm tệp nguồn chưa thay đổi. Với dữ liệu quan trọng, cần quản lý thông tin phiên bản, điều kiện If-Range và bước xác minh sau tải. Không nên dùng chuyển hướng ghi nối của shell để ghép phản hồi HTTP một cách không kiểm tra.

Nếu proxy yêu cầu xác thực, hãy dùng cơ chế quản lý thông tin đăng nhập phù hợp. Tránh để mật khẩu xuất hiện trong lịch sử lệnh, nhật ký hoặc danh sách tiến trình có thể bị người khác đọc.

Những lỗi thường khiến tải tiếp không thành công

URL hoặc phiên đăng nhập hết hạn

Liên kết tải có chữ ký và phiên đăng nhập có thể hết hạn trong lúc tải. Khi nhận lỗi xác thực, cần làm mới quyền truy cập. Nếu phải lấy URL mới, hãy xác nhận URL đó vẫn trỏ đến cùng phiên bản tài nguyên trước khi tiếp tục.

Biểu diễn nội dung thay đổi

HTTP Range áp dụng lên biểu diễn mà máy chủ gửi. Nếu nội dung được nén hoặc chuyển đổi khác nhau giữa các lượt tải, vị trí byte có thể không còn tương thích.

Nên giữ nhất quán các header thương lượng nội dung. Với tệp nhị phân cần tải tiếp, có thể yêu cầu Accept-Encoding: identity và kiểm tra Content-Encoding thực tế. Không lấy kích thước dữ liệu đã giải nén làm điểm tiếp tục cho biểu diễn nén.

Đổi proxy làm thay đổi phản hồi

Đổi proxy không nhất thiết làm mất khả năng tải tiếp, nhưng có thể ảnh hưởng đến xác thực, lựa chọn máy chủ hoặc nội dung nhận được. Sau khi thay đổi tuyến kết nối, vẫn phải kiểm tra phiên bản và phạm vi trả về.

Xác minh hoàn tất trước khi sử dụng tệp

Tệp đủ kích thước chưa chắc có nội dung đúng. Sau khi tải xong, hãy so sánh hàm băm với giá trị do nguồn phát hành đáng tin cậy công bố, nếu có. Với gói phần mềm có chữ ký số, nên kiểm tra chữ ký theo hướng dẫn của nhà phát hành.

ETag không nhất thiết là hàm băm nội dung và không nên mặc định dùng như checksum. Chỉ đổi tên tệp tạm thành tên chính thức sau khi hoàn thành các bước kiểm tra phù hợp.

Tải tệp qua proxy bằng HTTP Range hiệu quả khi ba điều kiện cùng được bảo đảm: phần dữ liệu cục bộ được xác định chính xác, máy chủ trả đúng phạm vi và tài nguyên vẫn là cùng phiên bản. Áp dụng đầy đủ các bước này giúp tiếp tục tải file sau sự cố kết nối mà không đánh đổi tính toàn vẹn dữ liệu.