HTTP là gì? Phương thức, Tin nhắn, Mã trạng thái và Lưu trữ

Giới thiệu

HTTP là giao thức lớp ứng dụng cung cấp cho Web một từ vựng chung để xác định tài nguyên và trao đổi đại diện. Một trình duyệt có thể yêu cầu một tài liệu, một khách hàng API có thể gửi JSON, và một trình thu thập có thể lấy HTML vì mỗi bên hiểu các phương thức, trường, mã trạng thái và ý nghĩa tin nhắn giống nhau.

HTTP không định nghĩa một mô hình dữ liệu ứng dụng cố định nào. Nó định nghĩa cách một yêu cầu nêu một ý định và cách một phản hồi mô tả kết quả. Những ý nghĩa giống nhau tồn tại qua HTTP/1.1, HTTP/2 và HTTP/3 mặc dù các phiên bản đó mã hóa và truyền tải tin nhắn khác nhau.

Tài nguyên, Đại diện và URIs

HTTP hoạt động trên các tài nguyên được xác định bởi một URI. Một bản ghi sản phẩm, một hình ảnh, một kết quả tìm kiếm, và một trạng thái công việc đều có thể là một tài nguyên. Các byte trả về là một đại diện được chọn cho yêu cầu đó, có thể là HTML, JSON, một hình ảnh, hoặc nội dung nén trong một ngôn ngữ được yêu cầu.

Sự phân biệt này có ý nghĩa vì một URI có thể có nhiều đại diện. Các trường yêu cầu như Accept và Accept-Language mô tả sở thích của khách hàng, trong khi các trường phản hồi như Content-Type và Content-Encoding giải thích những gì đã được gửi. RFC 9110 định nghĩa ý nghĩa HTTP được chia sẻ bởi các phiên bản hiện tại.

Cấu trúc của một Yêu cầu

Một yêu cầu chứa một phương thức, mục tiêu, các trường, và đôi khi nội dung. GET yêu cầu một đại diện. HEAD yêu cầu cùng một siêu dữ liệu mà không có nội dung phản hồi. POST cung cấp thông tin để xử lý. PUT yêu cầu thay thế một tài nguyên mục tiêu, trong khi DELETE yêu cầu máy chủ xóa một liên kết.

Tên phương thức không chỉ là nhãn định tuyến. An toàn và tính vô tư ảnh hưởng đến lưu trữ, công cụ tự động, và cách khách hàng phục hồi sau các kết quả mạng không chắc chắn. Một máy chủ có thể tiết lộ hành vi cụ thể cho ứng dụng, nhưng nó nên giữ nguyên ý nghĩa tiêu chuẩn của phương thức mà nó chấp nhận.

Cấu trúc của một Phản hồi

Một phản hồi chứa một mã trạng thái, các trường, và nội dung tùy chọn. Một mã 2xx báo cáo việc xử lý thành công, 3xx chỉ định khách hàng đến nơi khác hoặc đến trạng thái lưu trữ, 4xx báo cáo một vấn đề với yêu cầu, và 5xx báo cáo rằng máy chủ không thể hoàn thành một yêu cầu hợp lệ.

Các tiêu đề mang siêu dữ liệu về đại diện đã chọn, thách thức xác thực, chính sách lưu trữ, bộ xác thực, các khoảng, cookie, và trung gian. Nội dung của phản hồi không được đảm bảo: phản hồi HEAD, 204 và 304 có các quy tắc nội dung đặc biệt, và các phản hồi lỗi có thể mang lại chẩn đoán hữu ích trong một định dạng do ứng dụng định nghĩa.

Không trạng thái Không có nghĩa là Ứng dụng Không nhớ

HTTP là không trạng thái vì mỗi yêu cầu có thể được hiểu mà không cần trạng thái cuộc trò chuyện ở mức giao thức từ một yêu cầu trước đó. Các ứng dụng vẫn duy trì trạng thái thông qua cookie, thông tin đăng nhập xác thực, phiên máy chủ, bản ghi cơ sở dữ liệu, và mã thông báo.

Sự tách biệt này giữ cho giao thức chung. Một giỏ hàng có thể tồn tại trong khi mỗi yêu cầu HTTP vẫn tự mô tả đủ để định tuyến và xử lý. Các nhà thiết kế nên phân biệt trạng thái ứng dụng và trạng thái kết nối và tránh giả định rằng cùng một kết nối mạng ngụ ý cùng một người dùng đã xác thực.

Lưu trữ và Yêu cầu Điều kiện

Các bộ nhớ cache có thể sử dụng lại một phản hồi đã lưu khi phương thức, trạng thái, độ tươi và các quy tắc lưu trữ cho phép. Độ tươi tránh làm liên lạc với nguồn gốc. Xác thực cho phép một bộ nhớ cache hỏi xem một đại diện đã lưu có vẫn còn hiện tại không bằng cách gửi một thẻ thực thể hoặc ngày sửa đổi trong một yêu cầu điều kiện.

Một xác thực thành công có thể trả về 304 mà không chuyển tiếp lại đại diện. Các khóa bộ nhớ cache chính xác phải tính đến URI mục tiêu và các trường yêu cầu được chọn được đặt tên bởi Vary. Cái này Quy định lưu trữ HTTP định nghĩa những điều khiển này và ngăn chặn một phản hồi riêng tư bị rò rỉ giữa các người dùng khi các chỉ thị được thiết lập đúng cách.

Kết nối, Proxy và Phiên bản

Các tin nhắn HTTP có thể đi qua các proxy, cổng, bộ nhớ cache, và mạng phân phối nội dung trước khi đến nguồn gốc. Mỗi trung gian có thể định tuyến, xác thực, chuyển đổi, hoặc lưu trữ các tin nhắn trong các quy tắc của giao thức. Các trường từ cuối đến cuối mô tả trao đổi tài nguyên; xử lý riêng về kết nối phụ thuộc vào phiên bản giao thức.

HTTP/1.1 sử dụng cú pháp tin nhắn văn bản qua một luồng byte. HTTP/2 ánh xạ cùng một ý nghĩa vào các khung nhị phân và các luồng đa dạng. HTTP/3 ánh xạ chúng qua QUIC. Tổng quan HTTP của MDN cung cấp một cái nhìn theo định hướng trình duyệt về cùng một mô hình khách hàng, máy chủ và trung gian.

HTTP là gì? Phương thức, Tin nhắn, Mã trạng thái và Kế hoạch Xác thực Bộ đệm

HTTP là một giao thức yêu cầu-phản hồi. Một khách hàng gửi một yêu cầu và một máy chủ trả về một phản hồi. Xác minh rằng yêu cầu đó đúng trên toàn bộ đường dẫn sản xuất. Bắt đầu với một giao dịch đại diện nhỏ, ghi lại hành vi đã đàm phán tại khách hàng và biên, và xác nhận rằng ứng dụng nhận được các trường, khung hoặc sự kiện mà nó mong đợi qua cùng một cổng, máy chủ proxy, điểm kết thúc chứng chỉ và chính sách mạng mà lưu lượng thực tế sử dụng.

Biến giả định thiết kế đầu tiên thành một bài tập thất bại: Đặt tên các tài nguyên có URI ổn định. Sau đó, xem xét áp lực tài nguyên xung quanh giả định thứ hai: Chọn phương thức cho ngữ nghĩa đã xác định của chúng. Một triển khai chính xác nên thất bại trong các giới hạn được tài liệu hóa, giải phóng kết nối và trạng thái bộ đệm, và để lại dấu vết giải thích kết quả mà không tiết lộ thông tin xác thực hoặc dữ liệu riêng tư.

Điều hướng web và API máy tính luyện tập các phần khác nhau của thiết kế, vì vậy việc kiểm tra khả năng tương thích nên bao gồm cả hình thái lưu lượng mà chúng có liên quan. Thêm một trình duyệt hiện tại, một khách hàng không phải trình duyệt, một đường mạng chậm hơn và trung gian hỗ trợ cũ nhất. Ghi lại lựa chọn phiên bản, thời gian kết nối, tuổi tin nhắn hoặc phản hồi, chiều sâu hàng đợi và lý do kết thúc cho con đường ưu tiên và con đường dự phòng của nó.

Xem xét ngữ nghĩa và vận chuyển như các lớp riêng biệt trong quá trình thử nghiệm. Một kết nối thành công không chứng minh rằng ứng dụng xử lý đúng thứ tự, ủy quyền, hủy bỏ, bộ đệm, phát lại hoặc khôi phục trạng thái. Tương tự, một lỗi ứng dụng không chứng minh rằng giao thức đàm phán đã thất bại. Gán nhãn các quan sát với tài nguyên, phạm vi người dùng, hoạt động logic và định danh kết nối, sau đó so sánh những gì mà mỗi điểm cuối cho rằng đã xảy ra. Sự tách biệt này làm cho công việc về khả năng tăng cường hữu ích hơn: các nhóm có thể xem liệu độ trễ có đến từ việc thiết lập kết nối, phân phối mạng, xếp hàng, xử lý ứng dụng, tuần tự hóa, hoặc một máy thu chậm. Giữ nội dung riêng tư ra khỏi thông tin giám sát thông thường trong khi vẫn giữ đủ dữ liệu thời gian và kết quả để tái tạo quyết định.

Nơi nào HTTP là gì? Các Phương thức, Tin nhắn, Mã trạng thái và Bộ đệm Xuất hiện trong Thực tiễn

HTTP là gì? Phương thức, Tin nhắn, Mã trạng thái và Danh sách Kiểm tra Quy trình Bộ đệm

• Đặt tên các tài nguyên với URI ổn định. Chuyển điểm này thành một bài kiểm tra chấp nhận bằng văn bản để các người đánh giá có thể phân biệt hành vi dự kiến ​​với chi tiết thực hiện vô tình.
• Chọn phương thức cho ngữ nghĩa đã xác định của chúng. Đặt tên thành phần sở hữu cấu hình và người hoặc nhóm phản hồi khi hành vi quan sát của nó thay đổi.
• Trả về mã trạng thái mô tả kết quả thực tế. Ghi lại tín hiệu liên quan trong nhật ký hoặc dấu vết, sau đó xác minh rằng tín hiệu sống sót qua từng máy chủ proxy, cổng, và ranh giới dịch vụ trong con đường thực tế.
• Đặt Content-Type cho mọi đại diện. Kiểm tra quyết định với một trường hợp bình thường, một đồng minh chậm, một kết nối bị đóng, một đầu vào quá kích thước, và một sự không khớp phiên bản hoặc khả năng.
• Tách trạng thái xác thực khỏi danh tính kết nối. Tài liệu mặc định an toàn và điều kiện chính xác cho phép một ngoại lệ; các ngoại lệ ẩn trở thành vấn đề về khả năng tương tác trong các thay đổi sau này.
• Định nghĩa hành vi bộ nhớ đệm một cách rõ ràng cho các phản hồi nhạy cảm. Kiểm tra hành vi này từ một trình duyệt hoặc khách hàng đại diện thay vì chỉ dựa vào một kiểm tra đơn vị cục bộ hoặc một màn hình cấu hình phía máy chủ.
• Sử dụng trình kiểm tra cho các tài nguyên lớn hoặc thường xuyên được kiểm tra. Đặt giới hạn tài nguyên cố định và làm cho sự từ chối kết quả trở nên rõ ràng đối với cả các nhà điều hành và ứng dụng gọi.
• Ghi lại định danh yêu cầu qua các trung gian. Bảo tồn đủ định danh để tương quan một giao dịch logic giữa khách hàng, biên, ứng dụng, và bất kỳ công nhân bất đồng bộ nào.
• Bảo tồn các lỗi mà khách hàng nhìn thấy dưới dạng định dạng nhất quán. Xem xét lựa chọn sau khi thay đổi hình thái lưu lượng vì số lượng kết nối, kích thước tải trọng và tần suất tin nhắn có thể thay đổi thiết kế chính xác.
• Kiểm tra hành vi qua các phiên bản giao thức mà edge của bạn hỗ trợ. Giữ cho đường dẫn dự phòng có thể quan sát và được thử nghiệm để tính khả năng tương thích không phụ thuộc vào một đường dẫn cũ đã âm thầm ngừng hoạt động.

Kết luận

HTTP là một giao thức yêu cầu-phản hồi. Một khách hàng gửi một yêu cầu và một máy chủ trả lại một phản hồi. Ngữ nghĩa HTTP tồn tại lâu dài hơn mỗi phiên bản đường dây. Cấu trúc thay đổi qua các phiên bản trong khi các phương thức và ý nghĩa phản hồi vẫn quen thuộc. Áp dụng hai thực tế này với giới hạn rõ ràng, trạng thái có thể quan sát được và một đường dẫn dự phòng được kiểm tra bởi các khách hàng đại diện thay vì được giả định từ cấu hình.

Tài liệu tham khảo

• Tài liệu API Scraping Universal Scrapeless
• Tổng quan sản phẩm API Scraping Universal Scrapeless
• Hướng dẫn scraping HTTP C++ của Scrapeless