Chunked Transfer Encoding là gì?

API Gật Đầu Giải Bản Không Tăng Trưởng thu thập nội dung web công khai qua một bề mặt yêu cầu được quản lý mà có thể trả lại các nội dung phản hồi mà không yêu cầu các khách hàng kiểm soát việc định dạng thông điệp của máy chủ nguồn gốc.

Định nghĩa và Câu trả lời ngắn gọn

Chunked transfer encoding là một phương pháp định dạng thông điệp HTTP/1.1 cho phép gửi một nội dung dưới dạng một chuỗi các khối có kích thước độc lập khi người gửi không cung cấp chiều dài nội dung hoàn chỉnh trước khi bắt đầu truyền tải. Mỗi khối bắt đầu với kích thước của nó ở dạng số thập lục phân, tiếp tục với số byte dữ liệu đó và kết thúc bằng một cặp quay xe và xuống dòng. Một khối kích thước không đánh dấu kết thúc nội dung. Cơ chế này định dạng một thông điệp trên một bước nhảy mạng; nó không định nghĩa loại phương tiện, không nén đại diện bởi chính nó, hoặc chia một tài nguyên thành các tệp có thể truy cập độc lập.

Lý do thực tiễn cho việc chia nhỏ là thời gian. Một ứng dụng có thể tạo ra một báo cáo theo hàng, phát trực tiếp đầu ra từ một dịch vụ khác, hoặc bắt đầu gửi một phản hồi được kết xuất động trước khi mỗi byte được biết. HTTP/1.1 còn cần một ranh giới đáng tin cậy, thường là một trường Content-Length hoặc đóng kết nối. Định dạng chunked cung cấp ranh giới đó trong khi cho phép kết nối duy trì liên tục. Người nhận có thể phân tích từng dòng kích thước, tiêu thụ chính xác số octet đã được khai báo và nhận ra hoàn tất mà không cần chờ máy chủ đóng socket.

Chunked transfer encoding diễn ra từng bước nhảy. Một proxy đảo ngược có thể nhận một phản hồi chunked, giải mã nó, đệm hoặc biến đổi nội dung, và chuyển tiếp nó với Content-Length hoặc một định dạng khối khác. Vì lý do đó, mã ứng dụng nên quan tâm đến nội dung đã giải mã và độ hoàn chỉnh của phản hồi thay vì giả định rằng các khối được quan sát ở một thời điểm nào đó tồn tại từ đầu đến cuối. Content-Encoding khác: gzip hoặc một mã hóa nội dung khác mô tả cách mà đại diện được mã hóa qua đường yêu cầu, trong khi Transfer-Encoding mô tả định dạng giữa các bên tham gia HTTP liền kề.

HTTP/2 và HTTP/3 không sử dụng tiêu đề Transfer-Encoding của HTTP/1.1 cho định dạng nội dung. Các giao thức đó truyền tải dữ liệu trong các khung nhị phân riêng của chúng. Một nhà phát triển vẫn có thể thấy dữ liệu được truyền phát, nhưng đại diện vận chuyển không phải là mã hóa chunked của HTTP/1.1. Sự phân biệt này quan trọng trong các nhật ký và công cụ gỡ lỗi vì một cổng có thể chấp nhận HTTP/2 từ một trình duyệt và nói tiếng HTTP/1.1 với một nguồn gốc, tạo ra lưu lượng chunked chỉ trên một đoạn của đường đi.

Cách một nội dung chunked của HTTP/1.1 được định dạng

1. Đọc mã hóa truyền tải. Người nhận kiểm tra Transfer-Encoding và coi mã hóa cuối cùng như là quy tắc định dạng. Khi có chunked, Content-Length không được định nghĩa cùng một nội dung thông điệp. Dữ liệu định dạng mâu thuẫn rất nguy hiểm vì các trung gian khác nhau có thể không đồng ý với nhau về nơi mà một yêu cầu hoặc phản hồi kết thúc.
2. Phân tích kích thước số thập lục phân. Mỗi khối bắt đầu với một hoặc nhiều chữ số thập lục phân. Giá trị đếm octet dữ liệu, không phải ký tự hiển thị. Văn bản đa byte do đó không thể được đo lường bởi độ dài chuỗi JavaScript hoặc số lượng ký tự; định dạng hoạt động trên các byte được truyền.
3. Tiêu thụ dữ liệu và các dấu phân cách một cách chính xác. Sau dòng kích thước, trình phân tích sẽ tiêu thụ số octet đã được khai báo và sau đó là dòng kết thúc cần thiết. Sự không khớp kích thước, thiếu dấu phân cách, hoặc đóng kết nối trước khi khối không có kích thước khiến thông điệp không hoàn chỉnh. Các thư viện HTTP đã được thử nghiệm kỹ lưỡng xử lý logic ranh giới này trước khi đưa nội dung đến mã ứng dụng.
4. Kết thúc với khối cuối cùng. Một khối kích thước không đánh dấu kết thúc chuỗi khối. Một phần trailer tùy chọn có thể theo sau trước dòng trống cuối cùng, nhưng các trailer chỉ thích hợp cho các trường có thể được tính toán sau khi phát trực tiếp. Chúng không sửa chữa các tiêu đề bị thiếu mà người nhận cần trước khi đọc nội dung.

Chunked Transfer Encoding trong các Hệ thống Thực tế

Mã hóa theo từng phần so với các khái niệm gần gũi

Một cái nhìn bên cạnh nhau ngăn chặn các khái niệm gần nhau bị coi là có thể hoán đổi cho nhau. Sử dụng sự so sánh để xác định hợp đồng nào đang hoạt động trước khi thay đổi hành vi của khách hàng hoặc máy chủ.

Chẩn đoán mã hóa chuyển giao từng phần và thiết kế hoạt động

Khi một phản hồi từng phần xuất hiện bị cắt xén, trước tiên hãy xác định nhảy nào tạo ra sự cố. Công cụ phát triển trình duyệt thường hiển thị cơ thể đã giải mã, trong khi việc chụp gói hoặc khách hàng dòng lệnh chi tiết có thể tiết lộ các dòng kích thước mức dây. So sánh nguồn gốc, cổng, mạng phân phối nội dung và nhật ký khách hàng theo định danh yêu cầu. Một tải trọng ứng dụng hoàn chỉnh vẫn có thể bị cắt đứt bởi thời gian chờ proxy và một khối không có kích thước đúng vẫn có thể bao gồm một tài liệu ứng dụng mà về mặt logic không hoàn chỉnh.

Đừng tự tay gỡ bỏ hợp phản hồi được trả về bởi một khách hàng HTTP bình thường. Các khách hàng trưởng thành loại bỏ khung vận chuyển và phơi bày một luồng byte hoặc cơ thể đã giải mã. Phân tích lại các dấu hiệu khối có thể làm hỏng nội dung hợp pháp mà có sự xuất hiện của các dòng thập lục phân. Việc phân tích thủ công thuộc về các bài kiểm tra giao thức, chẩn đoán mạng, máy chủ, proxy và khách hàng chuyên biệt mà tại đó các byte thô được cung cấp một cách có chủ đích.

Đánh giá bảo mật nên xem xét khung không rõ ràng như một vấn đề giao thức, không phải là một vấn đề tiêu đề thẩm mỹ. Một thông điệp mang các tín hiệu chiều dài mâu thuẫn có thể được diễn giải khác nhau bởi các hệ thống lân cận. Chuẩn hóa các yêu cầu đến tại các ranh giới đáng tin cậy, từ chối khung bị lỗi, giữ cho hành vi của proxy và nguồn gốc đồng bộ, và tránh việc chuyển tiếp các thông điệp không rõ ràng sâu hơn vào ngăn xếp ứng dụng.

Danh sách kiểm tra triển khai mã hóa chuyển giao từng phần

Danh sách kiểm tra dưới đây biến khái niệm thành công việc kỹ thuật có thể xác minh. Chỉ áp dụng các mục phù hợp với giao thức và hợp đồng sản phẩm đang hoạt động, nhưng giữ chứng cứ lại cùng nhau để kỹ sư khác có thể tái tạo quyết định.

• Xác nhận phiên bản HTTP đã thương lượng trên mỗi nhảy liên quan thay vì suy luận từ URL trình duyệt.
• Kiểm tra Transfer-Encoding và Content-Length cùng nhau; khung hợp lệ không được yêu cầu người nhận chọn giữa các ranh giới mâu thuẫn.
• Đo kích thước khối bằng octet và xác thực các kết thúc dòng yêu cầu khi phân tích thô là một phần của hệ thống đang được kiểm nghiệm.
• Ghi lại liệu các cổng có bộ đệm, giải nén hoặc tái cấu trúc cơ thể vì những bước đó thay đổi cái mà các công cụ downstream quan sát.
• Sử dụng định danh yêu cầu để kết nối chứng cứ của khách hàng, proxy và nguồn gốc cho các thông điệp không hoàn chỉnh.
• Kiểm tra việc đóng kết nối sớm và các khối cuối không hợp lệ trong một môi trường kiểm soát để các lỗi trở nên rõ ràng.
• Để các thư viện HTTP tiêu chuẩn phơi bày các cơ thể đã giải mã cho mã ứng dụng trừ khi việc triển khai giao thức là nhiệm vụ thực sự.

Sau khi triển khai, kiểm tra hành vi bình thường, các ranh giới, đầu vào không hợp lệ, trạng thái bị thiếu, hoạt động đồng thời và từ chối truy cập có chủ đích trong một môi trường được kiểm soát. Ghi lại trạng thái mong đợi, hình dạng cơ thể, điều kiện kết thúc và chuyển trạng thái cho mỗi trường hợp. Việc giám sát sản xuất nên báo cáo cùng các kích thước đã được sử dụng trong quá trình kiểm tra để một sự cố có thể được so sánh với một đường cơ sở đã biết.

Tài liệu nên chỉ ra trách nhiệm ở mỗi bên của giao diện. Khách hàng cần các trường bắt buộc, định danh ổn định, quy tắc sắp xếp, giới hạn, tín hiệu đầu cuối và ý nghĩa lỗi. Các nhà điều hành cần chính sách nội bộ, quyết định lưu trữ hoặc định tuyến, các lĩnh vực quan sát và phản hồi công cộng an toàn. Các hợp đồng mập mờ khiến các nhóm phải sửa chữa triệu chứng có thể nhìn thấy trong lớp sai.

Những sai lầm phổ biến với mã hóa chuyển giao từng phần

Đừng suy luận thành công, sự vắng mặt, sự cho phép, thứ tự hoặc hoàn thành từ một trường mà không có hợp đồng xung quanh. Mã trạng thái, mã thông báo, kích thước trang và tiêu đề vận chuyển mỗi cái trả lời một câu hỏi hẹp. Cơ thể phản hồi, phương thức, danh tính, bộ lọc, phiên bản giao thức và tài liệu máy chủ cung cấp phần còn lại của ý nghĩa.

Đừng loại bỏ ngữ cảnh chẩn đoán nhân danh sự đơn giản. Một dòng nhật ký ngắn bỏ qua định danh yêu cầu, mục tiêu, phiên bản, phạm vi hoặc ranh giới có thể biến một thiếu sót nhỏ thành hàng giờ đoán mò. Đồng thời, khả năng quan sát phải cắt đứt thông tin xác thực, bí mật phiên, URL đã ký và các trường tải trọng nhạy cảm.

Đừng biến một giải pháp tạm thời thành hợp đồng vĩnh viễn. Sửa chữa vấn đề về thứ tự, sự cho phép, định tuyến, nhịp độ, khung hoặc lập bản đồ lỗi cơ bản và thêm một kiểm tra hồi quy. Một hệ thống trở nên đáng tin cậy khi lỗi rõ ràng và có giới hạn, không phải khi một lần chạy thủ công nào đó tình cờ hoàn thành.

Kết luận

Mã hóa chuyển giao từng phần giải quyết một vấn đề chính xác của HTTP/1.1: cách xác định một cơ thể mà kích thước byte cuối cùng không được biết trước khi bắt đầu gửi. Các kích thước thập lục phân của nó, các đoạn dữ liệu, khối không và các phần bổ sung tùy chọn thuộc về khung vận chuyển trên một nhảy đơn. Các ứng dụng thường tiêu thụ cơ thể đã được giải mã, trong khi các nhà điều hành kiểm tra các khối thô chỉ khi theo dõi các phản hồi không hoàn chỉnh, biến đổi proxy hoặc xung đột khung.