Giao thức truyền siêu văn bản. Giao thức truyền siêu văn bản - HTTP

Nếu biểu mẫu được gửi theo cách thông thường thì trình duyệt sẽ tự mã hóa (urlencode) tên và giá trị của từng trường dữ liệu (đầu vào, v.v.) và gửi biểu mẫu đến máy chủ ở dạng được mã hóa.

Phương pháp mã hóa thứ hai là không mã hóa. Ví dụ: không cần mã hóa để truyền tệp. Nó được chỉ định ở dạng (chỉ dành cho POST) như thế này:

Trong trường hợp này, không có gì được mã hóa khi gửi dữ liệu đến máy chủ. Và về phần mình, máy chủ nhìn vào “Content-Type: multipart/form-data” sẽ hiểu những gì đã đến.

Mã hóa dữ liệu.

Nếu bạn chỉ sử dụng UTF-8 thì không cần phần này.

Tất cả các tham số GET/POST gửi đến máy chủ, ngoại trừ trường hợp dữ liệu nhiều phần/biểu mẫu, đều được mã hóa bằng UTF-8. Không phải trong mã hóa trang mà ở UTF-8. Do đó, ví dụ, trong PHP, chúng cần được mã hóa lại bằng hàm iconv nếu cần.

$name = iconv("UTF8","CP1251",$_GET["name"]);

Trình duyệt nhận được phản hồi từ máy chủ chính xác theo mã hóa được chỉ định trong tiêu đề phản hồi Kiểu nội dung. Một lần nữa, trong PHP, để trình duyệt chấp nhận phản hồi trong windows-1251 và thường hiển thị dữ liệu trên trang trong windows-1251, bạn cần gửi tiêu đề được mã hóa bằng mã PHP, ví dụ như thế này:

Header("Content-Type: text/plain; charset=windows-1251");

Hoặc máy chủ phải thêm tiêu đề như vậy. Ví dụ: trong apache, mã hóa được tự động thêm vào với tùy chọn:

# trong cấu hình Apache AddDefaultCharset windows-1251
.

HTTP là một giao thức để truyền siêu văn bản giữa các hệ thống phân tán. Trên thực tế, http là thành phần cơ bản của Web hiện đại. Với tư cách là nhà phát triển web có lòng tự trọng, chúng ta nên biết càng nhiều càng tốt về nó.

Hãy nhìn vào giao thức này qua lăng kính nghề nghiệp của chúng tôi. Trong phần đầu tiên, chúng ta sẽ tìm hiểu những điều cơ bản và xem xét các yêu cầu/phản hồi. Trong bài viết tiếp theo, chúng ta sẽ xem xét các tính năng chi tiết hơn, chẳng hạn như bộ nhớ đệm, xử lý kết nối và xác thực.

Cũng trong bài viết này tôi sẽ chủ yếu đề cập đến tiêu chuẩn RFC 2616: Giao thức truyền siêu văn bản -- HTTP/1.1.

Thông tin cơ bản về HTTP

HTTP cho phép giao tiếp giữa nhiều máy chủ và máy khách và cũng hỗ trợ toàn bộ dòng thiết lạp mạng lưới.

Về cơ bản, TCP/IP được sử dụng để liên lạc, nhưng đây không phải là lựa chọn khả thi duy nhất. Theo mặc định, TCP/IP sử dụng cổng 80, nhưng có thể sử dụng các cổng khác.

Giao tiếp giữa máy chủ và máy khách xảy ra theo hai giai đoạn: yêu cầu và phản hồi. Máy khách tạo một yêu cầu HTTP, để đáp lại máy chủ sẽ cung cấp phản hồi (tin nhắn). Một lát sau, chúng ta sẽ xem xét kế hoạch làm việc này chi tiết hơn.

Phiên bản hiện tại của giao thức HTTP là 1.1, trong đó một số tính năng mới đã được giới thiệu. Theo tôi, điều quan trọng nhất trong số đó là: hỗ trợ liên tục kết nối mở, cơ chế mới truyền dữ liệu mã hóa truyền khối, các tiêu đề mới cho bộ nhớ đệm. Chúng ta sẽ xem xét một số điều này trong phần thứ hai của bài viết này.

URL

Cốt lõi của giao tiếp web là yêu cầu được gửi qua Bộ định vị tài nguyên thống nhất (URL). Tôi chắc rằng bạn đã biết URL là gì, nhưng để hoàn thiện hơn, tôi quyết định nói vài lời. Cấu trúc URL rất đơn giản và bao gồm các thành phần sau:

Giao thức có thể là http cho kết nối thông thường hoặc https để trao đổi dữ liệu an toàn hơn. Cổng mặc định là 80. Tiếp theo là đường dẫn đến tài nguyên trên máy chủ và một chuỗi tham số.

phương pháp

Bằng cách sử dụng URL, chúng tôi xác định tên chính xác của máy chủ mà chúng tôi muốn liên lạc, nhưng hành động chúng tôi cần thực hiện chỉ có thể được liên lạc với sử dụng HTTP phương pháp. Tất nhiên, có một số loại hành động mà chúng ta có thể thực hiện. HTTP triển khai những thứ cần thiết nhất, phù hợp với nhu cầu của hầu hết các ứng dụng.

Các phương pháp hiện có:

LẤY: Truy cập tài nguyên hiện có. URL liệt kê tất cả thông tin cần thiết, để máy chủ có thể tìm và trả lại tài nguyên được yêu cầu dưới dạng phản hồi.

BƯU KIỆN: Được sử dụng để tạo một tài nguyên mới. Yêu cầu POST thường chứa tất cả thông tin cần thiết để tạo tài nguyên mới.

ĐẶT: Cập nhật tài nguyên hiện tại. Yêu cầu PUT chứa dữ liệu sẽ được cập nhật.

XÓA BỎ: Được sử dụng để xóa một tài nguyên hiện có.

Những phương pháp này là phổ biến nhất và thường được sử dụng bởi nhiều công cụ và khung công tác khác nhau. Trong một số trường hợp, yêu cầu PUT và DELETE được gửi bằng cách gửi POST, nội dung của yêu cầu này cho biết hành động cần thực hiện trên tài nguyên: tạo, cập nhật hoặc xóa.

HTTP cũng hỗ trợ các phương thức khác:

CÁI ĐẦU: Tương tự như GET. Sự khác biệt là với loại yêu cầu này không có tin nhắn nào được truyền đi. Máy chủ chỉ nhận được các tiêu đề. Ví dụ: được sử dụng để xác định xem tài nguyên đã được sửa đổi hay chưa.

DẤU VẾT: trong quá trình truyền, yêu cầu đi qua nhiều điểm truy cập và máy chủ proxy, mỗi điểm truy cập sẽ nhập thông tin riêng: IP, DNS. Sử dụng phương pháp này, bạn có thể xem tất cả các thông tin trung gian.

TÙY CHỌN: Được sử dụng để xác định khả năng, cài đặt và cấu hình của máy chủ cho một tài nguyên cụ thể.

Mã trạng thái

Để đáp lại yêu cầu từ máy khách, máy chủ sẽ gửi phản hồi, trong đó cũng chứa mã trạng thái. Mã này mang một ý nghĩa đặc biệt để khách hàng có thể hiểu rõ hơn cách diễn giải câu trả lời:

1xx: Tin nhắn thông tin

Một bộ mã này đã được giới thiệu trong HTTP/1.1. Máy chủ có thể gửi yêu cầu có dạng: Expect: 100-continue, có nghĩa là máy khách vẫn gửi phần còn lại của yêu cầu. Khách hàng chạy HTTP/1.0 bỏ qua các tiêu đề này.

2xx: Thông báo thành công

Nếu khách hàng nhận được mã từ chuỗi 2xx thì yêu cầu đã được gửi thành công. Tùy chọn phổ biến nhất là 200 OK. Với yêu cầu GET, máy chủ sẽ gửi phản hồi trong nội dung thư. Ngoài ra còn có những câu trả lời khác có thể:

• 202 được chấp nhận: Yêu cầu được chấp nhận, nhưng có thể không chứa tài nguyên trong phản hồi. Điều này hữu ích cho các yêu cầu không đồng bộ ở phía máy chủ. Máy chủ xác định có gửi tài nguyên hay không.
• 204 Không có nội dung: Không có thông báo nào trong nội dung phản hồi.
• 205 Đặt lại nội dung: Hướng dẫn máy chủ đặt lại cách trình bày của tài liệu.
• 206 Nội dung một phần: Phản hồi chỉ chứa một phần nội dung. Các tiêu đề bổ sung xác định tổng độ dài của nội dung và thông tin khác.

3xx: Chuyển hướng

Một loại thông báo cho khách hàng về sự cần thiết phải thực hiện thêm một hành động. Trường hợp sử dụng phổ biến nhất là chuyển hướng máy khách đến một địa chỉ khác.

• 301 Đã di chuyển vĩnh viễn: Hiện tại, tài nguyên có thể được tìm thấy ở một URL khác.
• 303 Xem thêm: Tài nguyên có thể tạm thời được tìm thấy ở một URL khác. Tiêu đề Vị trí chứa URL tạm thời.
• 304 Không được sửa đổi: Máy chủ xác định rằng tài nguyên chưa được sửa đổi và máy khách cần sử dụng phiên bản được lưu trong bộ nhớ cache của phản hồi. Để kiểm tra danh tính của thông tin, ETag (băm Thẻ thực thể) được sử dụng;

4xx: Lỗi máy khách

Lớp thông báo này được máy chủ sử dụng nếu nó quyết định rằng yêu cầu đã được gửi do lỗi. Mã phổ biến nhất là 404 Not Found. Điều này có nghĩa là tài nguyên không được tìm thấy trên máy chủ. Các mã có thể khác:

• 400 yêu cầu xấu: Câu hỏi được hình thành không chính xác.
• 401 trái phép: Cần phải xác thực để thực hiện yêu cầu. Thông tin được truyền qua tiêu đề Ủy quyền.
• 403 bị cấm: Máy chủ không cho phép truy cập vào tài nguyên.
• Phương pháp 405 không được phép: Phương thức HTTP không hợp lệ đã được sử dụng để truy cập tài nguyên.
• 409 Xung đột: máy chủ không thể xử lý đầy đủ yêu cầu vì đang cố gắng thay đổi nhiều hơn phiên bản mới nguồn. Điều này thường xảy ra với các yêu cầu PUT.

5xx: Lỗi máy chủ

Một loạt mã được sử dụng để phát hiện lỗi máy chủ khi xử lý yêu cầu. Phổ biến nhất: 500 Máy chủ nội bộ Lỗi. Sự lựa chọn khác:

• 501 không được thực hiện: Máy chủ không hỗ trợ chức năng được yêu cầu.
• Lỗi 503: Dịch vụ không khả dụng: Điều này có thể xảy ra nếu máy chủ gặp lỗi hoặc quá tải. Thông thường trong trường hợp này, máy chủ không phản hồi và thời gian dành cho phản hồi sẽ hết.

Định dạng tin nhắn yêu cầu/phản hồi

TRÊN hình ảnh tiếp theo bạn có thể thấy sơ đồ quy trình gửi yêu cầu của máy khách, xử lý và gửi phản hồi của máy chủ.

Chúng ta hãy nhìn vào cấu trúc tin nhắn được truyền đi thông qua HTTP:

Tin nhắn = *() CRLF [ ] = Dòng yêu cầu | Dòng trạng thái = Tên trường => Giá trị trường

Phải có một dòng trống giữa tiêu đề và nội dung của tin nhắn. Có thể có một số tiêu đề:

Nội dung phản hồi có thể chứa tất cả hoặc một phần thông tin nếu tính năng tương ứng được bật (Mã hóa truyền: chunked). HTTP/1.1 cũng hỗ trợ tiêu đề Transfer-Encoding.

Tiêu đề chung

Dưới đây là một số loại tiêu đề được sử dụng trong cả yêu cầu và phản hồi:

Tiêu đề chung = Kiểm soát bộ đệm | Kết nối | Ngày | Thực dụng | Đoạn giới thiệu | Mã hóa chuyển giao | Nâng cấp | Qua | Cảnh báo

Chúng tôi đã đề cập đến một số điều trong bài viết này, một số điều chúng tôi sẽ thảo luận chi tiết hơn trong phần thứ hai.

Tiêu đề via được sử dụng trong yêu cầu TRACE và được cập nhật bởi tất cả các máy chủ proxy.

Tiêu đề Pragma được sử dụng để liệt kê các tiêu đề tùy chỉnh. Ví dụ: Pragma: no-cache giống như Cache-Control: no-cache. Chúng ta sẽ nói nhiều hơn về điều này trong phần hai.

Tiêu đề Ngày được sử dụng để lưu trữ ngày và giờ của yêu cầu/phản hồi.

Tiêu đề Nâng cấp được sử dụng để thay đổi giao thức.

Transfer-Encoding nhằm mục đích chia phản hồi thành nhiều phần bằng cách sử dụng Transfer-Encoding: chunked. Đây là một tính năng mới trong HTTP/1.1.

Tiêu đề thực thể

Tiêu đề thực thể truyền tải thông tin meta về nội dung:

Tiêu đề thực thể = Cho phép | Mã hóa nội dung | Ngôn ngữ nội dung | Độ dài nội dung | Nội dung-Vị trí | Nội dung-MD5 | Phạm vi nội dung | Loại nội dung | Hết hạn | Sửa đổi lần cuối

Tất cả các tiêu đề có tiền tố Nội dung- cung cấp thông tin về cấu trúc, mã hóa và kích thước của nội dung thư.

Tiêu đề Hết hạn chứa ngày và giờ hết hạn của thực thể. Giá trị “không bao giờ hết hạn” có nghĩa là thời gian + 1 mã kể từ thời điểm hiện tại. Sửa đổi lần cuối chứa thời gian và ngày thay đổi cuối cùng nước hoa.

Sử dụng các tiêu đề này, bạn có thể chỉ định thông tin cần thiết cho nhiệm vụ của mình.

Định dạng yêu cầu

Yêu cầu trông giống như thế này:

Dòng yêu cầu = Phương thức SP URI SP Phương thức CRLF phiên bản HTTP = "TÙY CHỌN" | "ĐẦU" | "NHẬN" | "ĐĂNG" | "ĐẶT" | "XÓA" | "DẤU VẾT"

SP là dấu phân cách giữa các mã thông báo. Phiên bản HTTP được chỉ định trong HTTP-Version. Yêu cầu thực tế trông như thế này:

GET /articles/http-basics HTTP/1.1 Máy chủ: www.articles.com Kết nối: keep-alive Kiểm soát bộ đệm: no-cache Pragma: no-cache Chấp nhận: text/html,application/xhtml+xml,application/xml; q=0,9,*/*;q=0,8

Danh sách các tiêu đề yêu cầu có thể có:

Tiêu đề yêu cầu = Chấp nhận | Bộ ký tự chấp nhận | Mã hóa chấp nhận | Ngôn ngữ chấp nhận | Ủy quyền | Mong đợi | Từ | Máy chủ | Nếu-Match | Nếu-Đã sửa đổi-Kể từ | Nếu-Không-Trận Đấu | Phạm vi nếu | Nếu-Chưa sửa đổi-Kể từ | Chuyển tiếp tối đa | Ủy quyền proxy | Phạm vi | Người giới thiệu | TE | Đại lý người dùng

Tiêu đề Chấp nhận chỉ định các loại mime, ngôn ngữ và mã hóa ký tự được hỗ trợ. Các tiêu đề Từ, Máy chủ, Người giới thiệu và Tác nhân người dùng chứa thông tin về máy khách. Tiền tố if- nhằm mục đích tạo điều kiện. Nếu điều kiện không vượt qua, lỗi 304 Not Modified sẽ xảy ra.

Định dạng phản hồi

Định dạng phản hồi chỉ khác nhau ở trạng thái và một số tiêu đề. Trạng thái trông như thế này:

Dòng trạng thái = HTTP-Phiên bản SP Mã trạng thái SP Lý do-Cụm từ CRLF

• Phiên bản HTTP
• Mã trạng thái
• Thông báo trạng thái con người có thể đọc được

Trạng thái bình thường trông giống như thế này:

HTTP/1.1 200 Được

Các tiêu đề phản hồi có thể như sau:

Tiêu đề phản hồi = Phạm vi chấp nhận | Tuổi | ETag | Vị trí | Xác thực proxy | Thử lại sau | Máy chủ | Thay đổi | WWW-Xác thực

• Tuổi là thời gian tính bằng giây khi tin nhắn được tạo trên máy chủ.
• Thực thể ETag MD5 để kiểm tra các thay đổi và sửa đổi đối với phản hồi.
• Vị trí được sử dụng để chuyển hướng và chứa URL mới.
• Máy chủ chỉ định máy chủ nơi phản hồi được tạo ra.

Tôi nghĩ lý thuyết hôm nay thế là đủ rồi. Bây giờ chúng ta hãy xem các công cụ chúng ta có thể sử dụng để giám sát các thông điệp HTTP.

Công cụ phát hiện lưu lượng HTTP

Có nhiều công cụ để theo dõi lưu lượng HTTP. Dưới đây là một vài trong số họ:

Công cụ được sử dụng phổ biến nhất là Công cụ dành cho nhà phát triển Chrome:

Nếu chúng ta nói về trình gỡ lỗi, bạn có thể sử dụng Fiddler:

Để giám sát lưu lượng HTTP, bạn sẽ cần Curl, tcpdump và tshark.

Thư viện làm việc với HTTP - jQuery AJAX

Vì jQuery rất phổ biến nên nó cũng có các công cụ để xử lý các phản hồi HTTP khi Yêu cầu AJAX. Thông tin về jQuery.ajax(settings) có thể được tìm thấy trên trang web chính thức.

Bằng cách truyền đối tượng cài đặt, cũng như sử dụng hàm gọi lại beforeSend, chúng ta có thể đặt tiêu đề yêu cầu bằng phương thức setRequestHeader().

$.ajax(( url: "http://www.articles.com/latest", gõ: "GET", beforeSend: function (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,en "); ) ));

Nếu bạn muốn xử lý trạng thái yêu cầu, bạn có thể làm như thế này:

$.ajax(( statusCode: ( 404: function() ( cảnh báo("không tìm thấy trang"); ) ) ));

Điểm mấu chốt

Đây là phần giới thiệu những kiến ​​thức cơ bản về giao thức HTTP. Phần thứ hai sẽ chứa nhiều sự kiện và ví dụ thú vị hơn nữa.

Giao thức chuẩn để truyền dữ liệu qua World Wide Web là HTTP ( Truyền siêu văn bản Giao thức - giao thức truyền siêu văn bản). Nó mô tả các thông điệp có thể được trao đổi giữa máy khách và máy chủ. Mỗi tương tác bao gồm một yêu cầu ASCII duy nhất, theo sau là một phản hồi duy nhất, tương tự như phản hồi tiêu chuẩn RFC 822 MIME. Tất cả máy khách và máy chủ đều phải tuân theo giao thức này. Nó được định nghĩa trong RFC 2616.

Kết nối

Cách thông thường để trình duyệt giao tiếp với máy chủ là thiết lập kết nối TCP tới cổng 80 của máy chủ, mặc dù quy trình này không bắt buộc về mặt hình thức. Giá trị của việc sử dụng TCP là cả trình duyệt và máy chủ đều không phải lo lắng về các thông báo và xác nhận bị mất, trùng lặp hoặc quá dài. Tất cả điều này được cung cấp bởi giao thức TCP.

Trong HTTP 1.0, sau khi kết nối được thiết lập, một yêu cầu sẽ được gửi và nhận được một phản hồi. Sau đó, kết nối TCP đã bị chấm dứt. Vào thời điểm đó, một trang web thông thường bao gồm toàn bộ văn bản HTML và cách tương tác này là đủ. Tuy nhiên, vài năm trôi qua, trang này chứa nhiều biểu tượng, hình ảnh và các đồ trang trí khác. Rõ ràng, việc thiết lập kết nối TCP để truyền một biểu tượng duy nhất là lãng phí và quá tốn kém.

Việc cân nhắc này đã dẫn đến việc tạo ra giao thức HTTP 1.1, hỗ trợ các kết nối ổn định. Điều này có nghĩa là có thể thiết lập kết nối TCP, gửi yêu cầu, nhận phản hồi, sau đó gửi và nhận các yêu cầu và phản hồi bổ sung. Vì vậy, các chi phí chung phát sinh trong quá trình cài đặt cố định và ngắt kết nối. Cũng có thể thực hiện các yêu cầu theo đường dẫn, nghĩa là gửi yêu cầu 2 ngay cả trước khi phản hồi cho yêu cầu 1 đến.

Mặc dù HTTP được thiết kế đặc biệt để sử dụng trong công nghệ web, nhưng nó được cố tình tạo ra tổng quát hơn mức cần thiết vì nó được dự định để sử dụng trong tương lai trong các ứng dụng hướng đối tượng. Vì lý do này, ngoài các truy vấn trang web thông thường, các hoạt động đặc biệt được gọi là phương thức đã được phát triển. Họ có được sự tồn tại của mình nhờ công nghệ SOAP. Mỗi yêu cầu bao gồm một hoặc nhiều chuỗi ASCII, với từ đầu tiên là tên của phương thức được gọi. Các phương thức tích hợp được liệt kê trong bảng ở Hình 6. bên cạnh những phương pháp phổ biến, y các đồ vật khác nhau Cũng có thể có những phương pháp cụ thể. Tên phương thức có phân biệt chữ hoa chữ thường, nghĩa là phương thức GET tồn tại nhưng phương thức get thì không.

Hình 6 - Các phương thức yêu cầu HTTP tích hợp

Phương thức GET yêu cầu một trang từ máy chủ (trong đó trường hợp chungđối tượng ngụ ý, nhưng trong thực tế nó thường chỉ là một tệp) được mã hóa theo tiêu chuẩn MIME. Phần lớn các yêu cầu tới máy chủ là các yêu cầu GET.

Phương thức HEAD chỉ yêu cầu tiêu đề của tin nhắn mà không cần đến trang đó. Sử dụng phương pháp này, bạn có thể tìm hiểu thời điểm một trang được sửa đổi lần cuối để thu thập thông tin chỉ mục hoặc đơn giản là kiểm tra chức năng của một URL nhất định.

Phương pháp PUT thì ngược lại phương thức NHẬN: Nó không đọc, nhưng viết trang. Phương pháp này cho phép bạn tạo một tập hợp các trang web trên máy chủ từ xa. Phần thân của yêu cầu chứa trang. Nó có thể được mã hóa MIME. Trong trường hợp này, các dòng theo sau lệnh PUT có thể bao gồm nhiều tiêu đề khác nhau, chẳng hạn như Tiêu đề loại nội dung hoặc tiêu đề xác thực, xác nhận quyền của người đăng ký đối với hoạt động được yêu cầu.

Phương thức POST có phần giống với phương thức PUT. Nó cũng chứa một URL, nhưng thay vì thay thế dữ liệu hiện có, dữ liệu mới được "nối thêm" (tại một số điểm theo nghĩa chung) sang những cái hiện có. Điều này có thể là đăng một tin nhắn lên một hội nghị hoặc thêm một tập tin vào bảng thông báo BBS. Trong thực tế, cả PUT và POST đều không được sử dụng rộng rãi.

Không có gì ngạc nhiên khi phương thức DELETE sẽ xóa trang. Giống như phương pháp PUT, việc xác thực và cho phép thực hiện thao tác này có thể đóng một vai trò đặc biệt ở đây. Ngay cả khi người dùng có quyền xóa trang, không có gì đảm bảo rằng phương thức DELETE sẽ xóa trang, bởi vì ngay cả khi máy chủ HTTP từ xa đồng ý, bản thân tệp có thể không bị sửa đổi hoặc di chuyển.

Phương pháp TRACE nhằm mục đích gỡ lỗi. Nó báo cho máy chủ gửi lại yêu cầu. Phương pháp này đặc biệt hữu ích khi các yêu cầu không được xử lý chính xác và máy khách muốn biết loại yêu cầu nào mà máy chủ thực sự nhận được.

Phương pháp CONNECT hiện không được sử dụng. Nó được dành riêng để sử dụng trong tương lai.

Phương thức OPTIONS cho phép máy khách hỏi máy chủ về các thuộc tính của nó hoặc các thuộc tính của một tệp cụ thể.

Để đáp lại mỗi yêu cầu từ máy chủ, một phản hồi sẽ được nhận có chứa một dòng trạng thái và cũng có thể, Thông tin thêm(ví dụ: một trang web hoặc một phần của trang web đó). Dòng trạng thái có thể chứa mã trạng thái gồm ba chữ số cho biết yêu cầu có thành công hay không hoặc tại sao yêu cầu đó không thành công. Loại đầu tiên nhằm chia tất cả các câu trả lời thành năm nhóm chính, như được hiển thị trong bảng ở Hình 7. Mã bắt đầu bằng 1 Aхх) hiếm khi được sử dụng trong thực tế. Mã bắt đầu bằng 2 có nghĩa là yêu cầu đã được xử lý thành công và dữ liệu (nếu được yêu cầu) đã được gửi. Mã 3xx yêu cầu khách hàng thử vận ​​may ở nơi khác - sử dụng URL khác hoặc bộ nhớ đệm của chính nó.

Hình 7 - Các nhóm mã trạng thái có trong phản hồi của máy chủ

Mã bắt đầu bằng 4 có nghĩa là yêu cầu không thành công vì lý do nào đó liên quan đến máy khách: ví dụ: trang không tồn tại hoặc bản thân yêu cầu đó không chính xác. Cuối cùng, mã 5xx cho biết lỗi máy chủ, do lỗi chương trình hoặc do quá tải tạm thời.

Ví dụ sử dụng HTTP

Vì HTTP là một giao thức văn bản nên việc tương tác với máy chủ thông qua thiết bị đầu cuối (trong trường hợp này hoạt động ngược lại với trình duyệt) có thể được tổ chức khá đơn giản. Bạn chỉ cần thiết lập kết nối TCP tới cổng 80 của máy chủ. Người đọc có thể tự mình xem tập lệnh này hoạt động như thế nào (tốt nhất là chạy nó trong hệ thống UNIX, vì một số hệ thống khác có thể không hiển thị trạng thái kết nối). Vì vậy, chuỗi lệnh là:

Hình 8 - chuỗi lệnh của giao thức HTTP

Chuỗi lệnh này thiết lập kết nối telnet (nghĩa là kết nối TCP) tới cổng 80 của máy chủ web IETF có tại www.ietf.org.

Kết quả của phiên giao tiếp được ghi lại trong tập tin nhật ký, sau đó bạn có thể xem. Tiếp theo là lệnh GET. Tên của tệp được yêu cầu và giao thức truyền được chỉ định. Tiếp theo là dòng bắt buộc có tiêu đề Host. Dòng trống theo sau nó cũng là bắt buộc. Nó báo hiệu cho máy chủ rằng tiêu đề yêu cầu đã hết. Lệnh đóng (đây là lệnh chương trình telnet) sẽ đóng kết nối.

Tệp nhật ký kết nối, nhật ký, có thể được xem bằng bất kỳ trình soạn thảo văn bản nào. Nó sẽ bắt đầu gần giống như trong danh sách ở Hình 8, trừ khi có một số thay đổi trên trang web IETF trong thời gian này.

Hình 9 - Bắt đầu xuất file “www.ietf.org/rfc.html”

Ba dòng đầu tiên trong danh sách này được tạo bởi chương trình telnet chứ không phải trang web từ xa. Tuy nhiên, dòng bắt đầu bằng HTTP/1.1 đã là phản hồi của IETF, cho biết rằng máy chủ muốn liên lạc với bạn bằng giao thức HTTP/1.1. Tiếp theo là một loạt tiêu đề và cuối cùng là nội dung của chính tệp được yêu cầu. Tiêu đề ETag, đó là định danh duy nhất các trang liên quan đến bộ nhớ đệm và X-Pad - một tiêu đề không chuẩn giúp xử lý các lỗi của trình duyệt.

Ngôn ngữ, v.v. Chính nhờ khả năng chỉ định cách mã hóa tin nhắn mà máy khách và máy chủ có thể trao đổi dữ liệu nhị phân, mặc dù giao thức này là văn bản.

Thuận lợi

Sự đơn giản

Giao thức thực hiện đơn giản đến mức giúp dễ dàng tạo các ứng dụng khách.

Khả năng mở rộng

Bạn có thể dễ dàng mở rộng khả năng của giao thức bằng cách triển khai các tiêu đề của riêng mình trong khi vẫn duy trì khả năng tương thích với các máy khách và máy chủ khác. Họ sẽ bỏ qua các tiêu đề mà họ không biết, nhưng đồng thời bạn có thể nhận được chức năng cần thiết khi giải quyết một vấn đề cụ thể.

Tỷ lệ hiện mắc

Khi chọn giao thức HTTP để giải quyết các vấn đề cụ thể, một yếu tố quan trọng là mức độ phổ biến của nó. Kết quả là, đây là một kho tài liệu phong phú về giao thức bằng nhiều ngôn ngữ trên thế giới, bao gồm các công cụ phát triển dễ sử dụng trong các IDE phổ biến, hỗ trợ giao thức với tư cách là máy khách trong nhiều chương trình, và có nhiều lựa chọn giữa các công ty cung cấp dịch vụ lưu trữ có máy chủ HTTP.

Nhược điểm và vấn đề

Kích thước tin nhắn lớn

Việc sử dụng định dạng văn bản trong giao thức tạo ra nhược điểm tương ứng: size lớn tin nhắn so với việc truyền dữ liệu nhị phân. Do đó, tải trọng của thiết bị khi tạo, xử lý và truyền tin nhắn sẽ tăng lên. Để giải quyết vấn đề này, giao thức bao gồm các phương tiện tích hợp để lưu vào bộ đệm ở phía máy khách, cũng như các phương tiện để nén nội dung được truyền. Các tài liệu quy định về giao thức cung cấp sự hiện diện của máy chủ proxy, cho phép khách hàng nhận tài liệu từ máy chủ gần mình nhất. Ngoài ra, mã hóa delta đã được đưa vào giao thức để không phải toàn bộ tài liệu được truyền đến máy khách mà chỉ một phần được sửa đổi của nó.

Thiếu "điều hướng"

Mặc dù giao thức được thiết kế như một phương tiện để làm việc với các tài nguyên máy chủ nhưng nó không cung cấp một cách rõ ràng phương tiện điều hướng giữa các tài nguyên này. Ví dụ: máy khách không thể yêu cầu rõ ràng danh sách các tệp có sẵn, như trong . Người ta cho rằng người dùng cuối đã biết các siêu liên kết. Điều này khá bình thường và thuận tiện với con người, tuy nhiên lại khó khăn khi nhiệm vụ phải tự động xử lý và phân tích toàn bộ tài nguyên máy chủ mà không có sự can thiệp của con người. Giải pháp cho vấn đề này hoàn toàn nằm ở vai của các nhà phát triển ứng dụng sử dụng giao thức này.

Không hỗ trợ phân phối

Giao thức HTTP được phát triển để giải quyết các vấn đề điển hình hàng ngày, trong đó thời gian xử lý yêu cầu sẽ mất rất ít thời gian hoặc hoàn toàn không được tính đến. Nhưng trong sử dụng công nghiệp với tính toán phân tán và tải trọng cao trên máy chủ, giao thức HTTP hóa ra lại bất lực. Năm 1998, W3C đề xuất một giao thức thay thế HTTP-NG(Tiếng Anh) HTTP thế hệ tiếp theo) để thay thế hoàn toàn cái lỗi thời và tập trung vào lĩnh vực này. Ý tưởng về sự cần thiết của nó đã được các chuyên gia lớn về điện toán phân tán ủng hộ, nhưng giao thức này vẫn đang ở giai đoạn phát triển.

Phần mềm

Tất cả phần mềm để làm việc với giao thức HTTP được chia thành ba loại lớn:

• May chủ là nhà cung cấp chính các dịch vụ lưu trữ và xử lý thông tin (xử lý yêu cầu).
• Khách hàng- người tiêu dùng cuối cùng của dịch vụ máy chủ (gửi yêu cầu).
• Ủy quyềnđể thực hiện dịch vụ vận tải.

Để phân biệt máy chủ cuối với proxy, tài liệu chính thức sử dụng thuật ngữ máy chủ gốc(Tiếng Anh) Máy chủ gốc). Tất nhiên là giống nhau phần mềm có thể đồng thời thực hiện các chức năng của client, server hoặc trung gian tùy theo nhiệm vụ được giao. Thông số kỹ thuật của giao thức HTTP nêu chi tiết hành vi của từng vai trò này.

Khách hàng

Giao thức HTTP ban đầu được phát triển để truy cập các tài liệu siêu văn bản trên World Wide Web. Do đó, việc triển khai khách hàng chính là trình duyệt(tác nhân người dùng). Các trình duyệt phổ biến (trong thứ tự ABC): Chrome, Internet Explorer, Mozilla Firefox, Safari.

Để xem nội dung đã lưu của các trang web trên máy tính không có kết nối Internet, chúng đã được phát minh trình duyệt ngoại tuyến. Trong số những người nổi tiếng. Chúng cho phép bạn tải xuống các tệp được chỉ định bất kỳ lúc nào sau khi mất kết nối với máy chủ web. Tải xuống các chương trình Master rất phổ biến trên hệ điều hành Windows. Tải xuống miễn phí Người quản lý, ReGet. Trong KGet và d4x (Trình tải xuống cho X). Nhiều người dùng Linux thích sử dụng NASA World Wind hơn, NASA World Wind cũng sử dụng HTTP.

Giao thức HTTP thường được các chương trình sử dụng để tải xuống các bản cập nhật.

Toàn bộ các chương trình robot được sử dụng trong các công cụ tìm kiếm trên Internet. Trong số đó nhện mạng(trình thu thập thông tin) đi theo các siêu liên kết, biên soạn cơ sở dữ liệu về tài nguyên máy chủ và lưu nội dung của chúng để phân tích thêm.

Máy chủ gốc

Triển khai chính: Dịch vụ thông tin Internet (IIS), nginx.

Máy chủ proxy

Triển khai chính: UserGate, Multiproxy, Naviscope, Danh sách máy chủ web

Lịch sử phát triển

HTTP/0.9

HTTP/1.0

HTTP/1.1

Phiên bản hiện tại của giao thức đã được thông qua vào tháng 6. Điểm mới trong phiên bản này là chế độ “kết nối vĩnh viễn”: Điểm khởi hành) - xác định loại tin nhắn;

Tiêu đề và nội dung thư có thể bị thiếu, nhưng dòng bắt đầu là thành phần bắt buộc vì nó cho biết loại yêu cầu/phản hồi. Một ngoại lệ là phiên bản 0.9 của giao thức, trong đó thông báo yêu cầu chỉ chứa dòng bắt đầu và thông báo phản hồi chỉ chứa nội dung của thông báo.

Dòng đầu

Các dòng bắt đầu là khác nhau cho yêu cầu và phản hồi. Chuỗi truy vấn trông như thế này:

LẤY URI- cho phiên bản giao thức 0.9. Phương pháp URI HTTP/ Phiên bản- đối với các phiên bản khác.

Để yêu cầu một trang cho một bài viết nhất định, khách hàng phải chuyển chuỗi:

NHẬN /wiki/Http HTTP/1.0

Dòng bắt đầu của phản hồi của máy chủ có định dạng sau:

HTTP/ Phiên bản Mã trạng thái Giải trình

• Phiên bản- một cặp chữ số Ả Rập cách nhau bằng dấu chấm, như trong yêu cầu.
• Mã trạng thái(Tiếng Anh) Mã trạng thái) - ba chữ số Ả Rập. Mã trạng thái xác định nội dung tiếp theo của tin nhắn và hành vi của khách hàng.
• Giải trình(Tiếng Anh) Cụm từ lý do) - một đoạn văn bản giải thích ngắn gọn về mã phản hồi cho người dùng. Không ảnh hưởng đến tin nhắn dưới bất kỳ hình thức nào và là tùy chọn.

Ví dụ: máy chủ đã phản hồi yêu cầu trước đó của khách hàng đối với trang này bằng dòng:

HTTP/1.0 200 Được

phương pháp

TÙY CHỌN

Được sử dụng để xác định khả năng của máy chủ web hoặc thông số kết nối cho một tài nguyên cụ thể. Máy chủ NÊN bao gồm tiêu đề Cho phép trong phản hồi của nó cùng với danh sách các phương thức được hỗ trợ. Tiêu đề phản hồi cũng có thể bao gồm thông tin về các tiện ích mở rộng được hỗ trợ.

Dự kiến ​​yêu cầu của khách hàng có thể chứa nội dung thông báo để cho biết thông tin mà khách hàng quan tâm. Định dạng nội dung và quy trình làm việc với nó Hiện nay không xác định. Máy chủ nên bỏ qua nó bây giờ. Tình huống tương tự với nội dung trong phản hồi của máy chủ.

Để tìm hiểu khả năng của toàn bộ máy chủ, máy khách phải chỉ định dấu hoa thị - “*” trong URI. TÙY CHỌN * Yêu cầu HTTP/1.1 cũng có thể được sử dụng để kiểm tra tình trạng của máy chủ (tương tự như ping) và để kiểm tra xem máy chủ có hỗ trợ HTTP phiên bản 1.1 hay không.

Kết quả của phương pháp này không được lưu trữ.

LẤY

Được sử dụng để truy vấn nội dung của một tài nguyên được chỉ định. Bạn cũng có thể bắt đầu một quá trình bằng phương thức GET. Trong trường hợp này, thông tin về tiến trình của quá trình phải được đưa vào nội dung của thông báo phản hồi.

Máy khách có thể chuyển các tham số thực thi yêu cầu trong URI tài nguyên đích sau dấu "? ":
NHẬN /path/resource?param1=value1¶m2=value2 HTTP/1.1

Theo tiêu chuẩn HTTP, các yêu cầu GET được coi là bình thường - việc lặp lại cùng một yêu cầu GET nhiều lần sẽ tạo ra cùng một kết quả (với điều kiện là bản thân tài nguyên không thay đổi theo thời gian giữa các yêu cầu). Điều này cho phép các phản hồi đối với yêu cầu GET được lưu vào bộ đệm.

Ngoại trừ phương pháp thông thường NHẬN, cũng có sự khác biệt giữa . Các yêu cầu GET có điều kiện chứa các tiêu đề If-Modified-Since, If-Match, If-Range và các tiêu đề tương tự. GET một phần chứa Phạm vi trong yêu cầu. Quy trình thực hiện các yêu cầu đó được xác định riêng theo tiêu chuẩn.

CÁI ĐẦU

Tương tự như phương thức GET, ngoại trừ việc không có phần nội dung trong phản hồi của máy chủ. Yêu cầu HEAD thường được sử dụng để truy xuất siêu dữ liệu, kiểm tra sự tồn tại của tài nguyên (xác thực URL) và xem liệu nó có thay đổi kể từ lần truy cập cuối cùng hay không.

Tiêu đề phản hồi có thể được lưu trữ. Nếu siêu dữ liệu của tài nguyên không khớp với thông tin tương ứng trong bộ nhớ đệm thì bản sao của tài nguyên đó sẽ được đánh dấu là lỗi thời.

BƯU KIỆN

Được sử dụng để chuyển dữ liệu người dùng đến một tài nguyên được chỉ định. Ví dụ: trên blog, khách truy cập thường có thể nhập nhận xét về bài đăng vào biểu mẫu HTML, sau đó chúng được ĐĂNG lên máy chủ và đặt trên trang. Trong trường hợp này, dữ liệu được truyền (trong ví dụ với blog, văn bản nhận xét) được bao gồm trong nội dung của yêu cầu. Tương tự, các tệp thường được tải lên bằng phương thức POST.

Không giống như phương thức GET, phương thức POST không được coi là bình thường, nghĩa là lặp lại cùng một ĐĂNG yêu cầu có thể trả về các kết quả khác nhau (ví dụ: sau khi mỗi bình luận được gửi đi, một bản sao của bình luận đó sẽ xuất hiện).

Nếu kết quả thực thi là 200 (Ok) và 204 (Không có nội dung), thông báo về kết quả của yêu cầu sẽ được đưa vào nội dung phản hồi. Nếu tài nguyên đã được tạo, máy chủ NÊN trả về phản hồi 201 (Đã tạo) với URI của tài nguyên mới trong tiêu đề Vị trí.

Thông báo phản hồi của máy chủ đối với phương thức POST không được lưu vào bộ đệm.

ĐẶT

Được sử dụng để tải nội dung yêu cầu vào URI được chỉ định trong yêu cầu. Nếu tài nguyên không tồn tại tại URI nhất định, máy chủ sẽ tạo tài nguyên đó và trả về trạng thái 201 (Đã tạo). Nếu tài nguyên đã bị thay đổi, máy chủ trả về 200 (Ok) hoặc 204 (Không có nội dung). Máy chủ KHÔNG PHẢI bỏ qua các tiêu đề Content-* không hợp lệ do máy khách gửi cùng với tin nhắn. Nếu bất kỳ tiêu đề nào trong số này không thể được nhận dạng hoặc không hợp lệ trong các điều kiện hiện tại thì phải trả về mã lỗi 501 (Chưa triển khai).

Sự khác biệt cơ bản giữa phương thức POST và PUT là sự hiểu biết về mục đích của URI tài nguyên. Phương thức POST giả định rằng URI được chỉ định sẽ xử lý nội dung do máy khách gửi. Bằng cách sử dụng PUT, máy khách giả định rằng nội dung được tải xuống khớp với tài nguyên nằm tại URI đã cho.

Thông báo phản hồi của máy chủ đối với phương thức PUT không được lưu vào bộ đệm.

VÁ

Tương tự như PUT nhưng chỉ áp dụng cho một phần tài nguyên.

XÓA BỎ

Xóa tài nguyên được chỉ định.

DẤU VẾT

Trả về yêu cầu đã nhận để khách hàng có thể xem máy chủ trung gian nào đang thêm hoặc thay đổi yêu cầu.

KẾT NỐI

Để sử dụng với các máy chủ proxy có thể tự động chuyển sang chế độ đường hầm

LIÊN KẾT

Thiết lập kết nối giữa tài nguyên được chỉ định và các tài nguyên khác.

HỦY LIÊN KẾT

Loại bỏ kết nối của tài nguyên được chỉ định với tài nguyên khác.

Mã trạng thái

Mã trạng thái là một phần của dòng đầu tiên trong phản hồi của máy chủ. Nó đại diện cho một số nguyên gồm 3 chữ số Ả Rập. Chữ số đầu tiên cho biết lớp điều kiện. Mã phản hồi thường được theo sau bởi một cụm từ giải thích bằng tiếng Anh, cách nhau bằng dấu cách, cho biết lý do cho phản hồi cụ thể này.

Máy khách tìm hiểu từ mã phản hồi về kết quả yêu cầu của mình và xác định hành động cần thực hiện tiếp theo. Bộ mã trạng thái là một tiêu chuẩn và tất cả chúng đều được mô tả trong các tài liệu IETF liên quan. Máy khách có thể không biết tất cả các mã trạng thái nhưng nó phải phản hồi theo loại mã.

Hiện tại có năm loại mã trạng thái.

1xx Thông tin (tiếng Nga) Thông tin) Lớp này chứa các mã thông báo về quá trình chuyển giao. Trong HTTP/1.0, các tin nhắn có mã như vậy sẽ bị bỏ qua. Trong HTTP/1.1, máy khách phải sẵn sàng chấp nhận loại tin nhắn này như một phản hồi bình thường nhưng không cần gửi bất cứ thứ gì đến máy chủ. Bản thân các tin nhắn từ máy chủ chỉ chứa dòng bắt đầu của phản hồi và, nếu được yêu cầu, một vài trường tiêu đề dành riêng cho phản hồi. Máy chủ proxy phải gửi những tin nhắn như vậy từ máy chủ đến máy khách. Thành công 2xx (tiếng Nga) thành công) Các thông báo thuộc lớp này thông báo về các trường hợp chấp nhận và xử lý thành công yêu cầu của khách hàng. Tùy thuộc vào trạng thái, máy chủ cũng có thể truyền tiêu đề và nội dung của tin nhắn. Chuyển hướng 3xx (tiếng Nga) Chuyển hướng ) Mã trạng thái lớp 3xx cho khách hàng biết rằng yêu cầu tiếp theo phải được thực hiện tới một URI khác để hoạt động thành công. Trong hầu hết các trường hợp, địa chỉ mới được chỉ định trong trường Vị trí của tiêu đề. Trong trường hợp này, theo quy định, khách hàng phải thực hiện chuyển đổi tự động (jarl. chuyển hướng). Lưu ý rằng khi bạn truy cập tài nguyên tiếp theo, bạn có thể nhận được phản hồi từ cùng một lớp mã. Thậm chí có thể có một chuỗi chuyển hướng dài mà nếu được thực hiện tự động sẽ tạo ra tải quá mức cho thiết bị. Do đó, các nhà phát triển giao thức HTTP đặc biệt khuyến nghị rằng sau phản hồi thứ hai liên tiếp như vậy, bạn phải yêu cầu người dùng xác nhận chuyển hướng (trước đây điều này được khuyến nghị sau phản hồi thứ 5). Máy khách chịu trách nhiệm giám sát việc này vì máy chủ hiện tại có thể chuyển hướng máy khách đến tài nguyên trên máy chủ khác. Khách hàng cũng phải ngăn chặn việc chuyển hướng vòng tròn. Lỗi máy khách 4xx (tiếng Nga) Lỗi máy khách) Lớp mã 4xx nhằm mục đích chỉ ra lỗi ở phía máy khách. Khi sử dụng tất cả các phương thức ngoại trừ HEAD, máy chủ phải trả về lời giải thích siêu văn bản cho người dùng trong nội dung thư. Để ghi nhớ các giá trị của mã từ 400 đến 417, có các phương pháp minh họa ghi nhớ Lỗi máy chủ 5xx (tiếng Nga. Lỗi máy chủ) Mã 5xx được cấp cho các trường hợp hoạt động không thành công do lỗi của máy chủ. Đối với tất cả các tình huống khác ngoài việc sử dụng phương thức HEAD, máy chủ phải đưa vào nội dung thông báo lời giải thích mà máy khách sẽ hiển thị cho người dùng.

Tiêu đề

Nội dung thư

Ví dụ về hộp thoại HTTP

Yêu cầu GET thường xuyên

Yêu cầu khách hàng:

NHẬN /wiki/ trang HTTP/1.1 Máy chủ: ru.wikipedia.org Tác nhân người dùng: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Chấp nhận: text/html Kết nối: đóng

Phản hồi của máy chủ:

HTTP/1.0 200 OK Ngày: Thứ Tư, ngày 11 tháng 2 năm 2009 11:20:59 GMT Máy chủ: Apache X-Powered-By: PHP/5.2.4-2ubuntu5wm1 Sửa đổi lần cuối: Thứ Tư, ngày 11 tháng 2 năm 2009 11:20:59 Nội dung GMT -Ngôn ngữ: ru Loại nội dung: text/html; charset=utf-8 Độ dài nội dung: 1234 Kết nối: đóng (sau đây là trang được yêu cầu trong

Chuyển hướng

Giả sử công ty hư cấu Ví dụ Corp. có một trang web chính tại http://example.com và một tên miền bí danh example-corp.com. Máy khách gửi yêu cầu về trang Giới thiệu đến miền phụ (một số tiêu đề bị bỏ qua):

Trong tiêu đề Vị trí, bạn có thể chỉ định các đoạn như trong ví dụ này. Trình duyệt không đưa đoạn này vào yêu cầu vì nó quan tâm đến toàn bộ tài liệu. Nhưng nó sẽ tự động cuộn trang đến đoạn “danh bạ” ngay khi tải nó. Một tài liệu HTML ngắn có liên kết cũng được đặt trong phần nội dung phản hồi, tài liệu này sẽ đưa khách truy cập đến trang đích nếu trình duyệt không tự động truy cập trang đó. Tiêu đề Kiểu nội dung chứa các đặc điểm của phần giải thích HTML cụ thể này, không phải tài liệu nằm ở URL mục tiêu.

Giả sử cùng một công ty Ví dụ Corp. có một số văn phòng khu vực trên khắp thế giới. Và đối với mỗi văn phòng đại diện họ có một website với ccTLD tương ứng. Lời yêu cầu trang chủ Trang web chính example.com có ​​thể trông như thế này:

Máy chủ đã tính đến tiêu đề Ngôn ngữ chấp nhận và tạo phản hồi với chuyển hướng tạm thời đến máy chủ Nga example.ru, cho biết địa chỉ của nó trong tiêu đề Vị trí:

HTTP/1.x 302 Đã tìm thấy Vị trí: http://www.example.ru/ Kiểm soát bộ đệm: riêng tư Ngày: Thứ năm, ngày 19 tháng 2 năm 2009 11:08:01 GMT Máy chủ: Apache/2.2.6 Loại nội dung: văn bản/html; charset=windows-1251 Độ dài nội dung: 82 (dòng trống) Tập đoàn ví dụ Nga

Lưu ý tiêu đề Kiểm soát bộ đệm. Giá trị "riêng tư" cho các máy chủ khác (chủ yếu là proxy) biết rằng phản hồi có thể được lưu vào bộ đệm ở phía máy khách. Nếu không, có thể những du khách tiếp theo từ các quốc gia khác sẽ luôn đến một văn phòng đại diện khác.

Mã phản hồi (Xem phần khác) và (Chuyển hướng tạm thời) cũng được sử dụng để chuyển hướng.

Tiếp tục và tải xuống từng mảnh

Giả sử một tổ chức hư cấu đề nghị tải xuống video về một hội nghị trước đây từ trang web http://example.org/conf-2009.avi với dung lượng khoảng 160 MB. Hãy xem cách tải xuống tệp này trong trường hợp không thành công và cách trình quản lý tải xuống sẽ tổ chức tải xuống nhiều đoạn theo nhiều luồng.

Trong cả hai trường hợp, khách hàng sẽ đưa ra yêu cầu đầu tiên như sau:

GET /conf-2009.avi HTTP/1.0 Máy chủ: example.org Chấp nhận: */* Tác nhân người dùng: Mozilla/4.0 (tương thích; MSIE 5.0; Windows 98) Người giới thiệu: http://example.org/

Tiêu đề Người giới thiệu cho biết rằng tệp được yêu cầu từ trang chủ của trang web. Trình quản lý tải xuống cũng thường chỉ ra điều đó để mô phỏng quá trình chuyển đổi từ trang web. Không có nó, máy chủ có thể phản hồi (Truy cập bị cấm) nếu không cho phép yêu cầu từ các trang web khác. Trong trường hợp của chúng tôi, máy chủ trả về phản hồi thành công:

HTTP/1.1 200 OK Ngày: Thứ 5, ngày 19 tháng 2 năm 2009 12:27:04 GMT Máy chủ: Apache/2.2.3 Sửa đổi lần cuối: Thứ Tư, ngày 18 tháng 6 năm 2003 16:05:58 GMT ETag: "56d-9989200-1132c580" Nội dung -Loại: video/x-msvideo Độ dài nội dung: 160993792 Phạm vi chấp nhận: byte Kết nối: đóng (dòng trống) (nội dung nhị phân của toàn bộ tập tin)

Tiêu đề Accept-Ranges thông báo cho máy khách rằng nó có thể yêu cầu các đoạn từ máy chủ, cho biết độ lệch của chúng so với đầu tệp tính bằng byte. Nếu tiêu đề này bị thiếu, máy khách có thể cảnh báo người dùng rằng rất có thể sẽ không tải được tệp xuống. Dựa trên giá trị của tiêu đề Độ dài nội dung, trình quản lý tải xuống sẽ chia toàn bộ tập thành các phần bằng nhau và yêu cầu chúng riêng biệt, sắp xếp một số luồng. Nếu máy chủ không chỉ định kích thước thì máy khách sẽ không thể thực hiện tải xuống song song nhưng đồng thời có thể tiếp tục tải xuống tệp cho đến khi máy chủ phản hồi (Phạm vi yêu cầu không thỏa mãn).

Giả sử ở mức 84 megabyte, kết nối Internet bị gián đoạn và quá trình tải xuống bị tạm dừng. Khi kết nối Internet được khôi phục, trình duyệt sẽ tự động gửi yêu cầu mới tới máy chủ nhưng có hướng dẫn xuất nội dung từ megabyte thứ 84:

GET /conf-2009.avi HTTP/1.0 Máy chủ: example.org Chấp nhận: */* Tác nhân người dùng: Mozilla/4.0 (tương thích; MSIE 5.0; Windows 98) Phạm vi: byte=88080384- Người giới thiệu: http://example.org/

Máy chủ không bắt buộc phải nhớ các yêu cầu trước đó là gì và từ ai, do đó, máy khách đã chèn lại tiêu đề Người giới thiệu như thể đó là yêu cầu đầu tiên của nó. Giá trị tiêu đề Phạm vi được chỉ định sẽ yêu cầu máy chủ “cung cấp nội dung từ byte thứ 88080384 đến cuối cùng”. Về vấn đề này, máy chủ sẽ trả về phản hồi sau:

HTTP/1.1 206 Nội dung một phần Ngày: Thứ 5, ngày 19 tháng 2 năm 2009 12:27:08 GMT Máy chủ: Apache/2.2.3 Sửa đổi lần cuối: Thứ Tư, ngày 18 tháng 6 năm 2003 16:05:58 GMT ETag: "56d-9989200-1132c580" Phạm vi chấp nhận: byte Phạm vi nội dung: byte 88080384-160993791/160993792 Độ dài nội dung: 72913408 Kết nối: đóng Loại nội dung: video/x-msvideo (dòng trống) (nội dung nhị phân từ 84 megabyte)

Tiêu đề Accept-Ranges không còn cần thiết ở đây nữa vì máy khách đã biết về khả năng của máy chủ này. Khách hàng biết rằng một đoạn đang được truyền đi bằng mã (Nội dung một phần). Tiêu đề Phạm vi nội dung chứa thông tin về đoạn này: số byte bắt đầu và kết thúc và sau dấu gạch chéo - tổng kích thước của toàn bộ tệp tính bằng byte. Hãy chú ý đến tiêu đề Độ dài nội dung - nó cho biết kích thước của nội dung thư, tức là đoạn được truyền. Nếu máy chủ trả về một số đoạn thì Độ dài nội dung sẽ chứa tổng khối lượng của chúng.

Bây giờ hãy quay lại trình quản lý tải xuống. Biết được tổng kích thước của file “conf-2009.avi”, chương trình chia nó thành 10 phần bằng nhau. Người quản lý sẽ tải cái đầu tiên ở yêu cầu đầu tiên, làm gián đoạn kết nối ngay khi nó bắt đầu yêu cầu thứ hai. Anh ấy sẽ yêu cầu phần còn lại một cách riêng biệt. Ví dụ: phần thứ 4 sẽ được yêu cầu với các tiêu đề sau (một số tiêu đề bị bỏ qua - xem ví dụ đầy đủ cao hơn):

NHẬN /conf-2009.avi HTTP/1.0 Phạm vi: byte=64397516-80496894

Phản hồi của máy chủ trong trường hợp này sẽ như sau (một số tiêu đề bị bỏ qua - xem ví dụ đầy đủ ở trên):

HTTP/1.1 206 Nội dung một phần Phạm vi chấp nhận: byte Phạm vi nội dung: byte 64397516-80496894/160993792 Độ dài nội dung: 16099379 (dòng trống) (nội dung nhị phân của phần 4)

Nếu một yêu cầu như vậy được gửi đến một máy chủ không hỗ trợ các đoạn, nó sẽ trả về phản hồi tiêu chuẩn (OK) như được hiển thị ngay từ đầu, nhưng không có tiêu đề Phạm vi chấp nhận.

Cơ chế giao thức cơ bản

NHẬN một phần

HTTP cho phép bạn yêu cầu không phải toàn bộ nội dung của tài nguyên cùng một lúc mà chỉ một đoạn được chỉ định. Những yêu cầu như vậy được gọi là NHẬN một phần, khả năng thực thi chúng là tùy chọn (nhưng mong muốn) đối với máy chủ. GET một phần chủ yếu được sử dụng để tiếp tục các tệp và tải xuống song song nhanh chóng trong nhiều luồng. Một số chương trình tải xuống tiêu đề lưu trữ, hiển thị cấu trúc bên trong cho người dùng và sau đó yêu cầu các đoạn có thành phần lưu trữ được chỉ định.

Để nhận một đoạn, máy khách sẽ gửi yêu cầu đến máy chủ với tiêu đề Phạm vi, cho biết trong đó yêu cầu cần thiết phạm vi byte. Nếu máy chủ không hiểu các yêu cầu một phần (bỏ qua tiêu đề Phạm vi), thì nó sẽ trả về toàn bộ nội dung có trạng thái, như với GET thông thường. Nếu thành công, máy chủ trả về phản hồi có trạng thái 206 (Nội dung một phần) thay vì mã 200, bao gồm tiêu đề Phạm vi nội dung trong phản hồi. Bản thân các mảnh vỡ có thể được truyền đi theo hai cách:

NHẬN có điều kiện

Đàm phán nội dung

Đàm phán nội dung(Tiếng Anh) Đàm phán nội dung) - cơ chế Tự động phát hiện tài nguyên cần thiết khi có nhiều loại phiên bản tài liệu khác nhau. Đối tượng điều phối không chỉ có thể là tài nguyên máy chủ mà còn có thể trả về các trang có thông báo lỗi (, v.v.).

Có hai loại phê duyệt chính:

• Máy chủ được quản lý(Tiếng Anh) Điều khiển máy chủ).
• Khách hàng định hướng(Tiếng Anh) Điều khiển bởi đại lý).

Cả hai loại hoặc từng loại riêng biệt có thể được sử dụng đồng thời.

Đặc tả giao thức chính (RFC 2616) cũng nêu bật cái gọi là phê duyệt minh bạch(Tiếng Anh) Đàm phán minh bạch) làm tùy chọn ưu tiên để kết hợp cả hai loại. Không nên nhầm lẫn cơ chế sau với công nghệ độc lập Đàm phán nội dung minh bạch (TCN, Tiếng Nga Đàm phán nội dung minh bạch , xem RFC 2295), đây không phải là một phần của giao thức HTTP nhưng có thể được sử dụng cùng với nó. Cả hai đều có sự khác biệt đáng kể về nguyên lý hoạt động và ý nghĩa của từ “minh bạch” ( trong suốt). Trong đặc tả HTTP, tính minh bạch có nghĩa là quy trình này không hiển thị đối với máy khách và máy chủ và trong công nghệ TCN, tính minh bạch có nghĩa là khả năng truy cập danh sách đầy đủ các tùy chọn tài nguyên cho tất cả những người tham gia vào quá trình phân phối dữ liệu.

Máy chủ được quản lý

Nếu có nhiều phiên bản của một tài nguyên, máy chủ có thể phân tích các tiêu đề yêu cầu của máy khách để tạo ra phiên bản mà nó tin là phù hợp nhất. Các tiêu đề chính được phân tích là Accept, Accept-Charset, Accept-Encoding, Accept-Languages ​​​​và User-Agent. Máy chủ nên bao gồm tiêu đề Vary trong phản hồi cho biết các tham số mà nội dung của URI được yêu cầu khác nhau.

Vị trí địa lý của khách hàng có thể được xác định bằng địa chỉ IP từ xa.

Đàm phán theo hướng máy chủ có một số nhược điểm:

• Máy chủ chỉ đoán tùy chọn nào thích hợp nhất cho người dùng cuối, nhưng không thể biết chính xác những gì cần thiết vào lúc này (ví dụ: phiên bản bằng tiếng Nga hoặc tiếng Anh).
• Có rất nhiều tiêu đề nhóm Chấp nhận được gửi nhưng ít tài nguyên có nhiều tùy chọn. Bởi vì điều này, thiết bị phải chịu tải quá mức.
• Bộ đệm chia sẻ bị hạn chế ở khả năng tạo ra cùng một phản hồi cho các yêu cầu giống hệt nhau từ những người dùng khác nhau.
• Việc chuyển các tiêu đề Chấp nhận cũng làm tổn hại đến quyền riêng tư của người dùng bằng cách tiết lộ một số thông tin về sở thích của người dùng.

Khách hàng định hướng

Trong trường hợp này, loại nội dung chỉ được xác định ở phía máy khách. Để thực hiện việc này, máy chủ trả về với mã trạng thái 300 (Nhiều lựa chọn) hoặc 406 (Không được chấp nhận), danh sách các tùy chọn mà người dùng chọn tùy chọn thích hợp. Việc điều chỉnh theo hướng khách hàng sẽ hiệu quả khi nội dung thay đổi theo những cách phổ biến (chẳng hạn như ngôn ngữ và mã hóa) và sử dụng bộ nhớ đệm công khai. Nhược điểm chính: tải thêm, vì bạn phải đưa ra yêu cầu bổ sung để có được nội dung mong muốn.

Phê duyệt minh bạch

Việc đàm phán này hoàn toàn minh bạch đối với máy khách và máy chủ. Trong trường hợp này, bộ nhớ đệm dùng chung được sử dụng, chứa danh sách các tùy chọn, cho cả khách hàng quản lý phê duyệt Nếu bộ đệm hiểu được tất cả các tùy chọn này thì nó sẽ tự đưa ra lựa chọn, như trong đàm phán do máy chủ điều khiển. Điều này làm giảm tải trên máy chủ gốc và loại bỏ yêu cầu bổ sung từ máy khách.

Đặc tả HTTP cốt lõi không mô tả chi tiết cơ chế đàm phán minh bạch.

Nhiều nội dung

Bài chi tiết: hệ thống phân cấp với việc lồng các phần tử vào nhau. Các loại phương tiện multipart/* được sử dụng để biểu thị nhiều nội dung. Làm việc với các loại như vậy được thực hiện theo các quy tắc chung được mô tả trong RFC 2046 (trừ khi được xác định khác bởi loại phương tiện cụ thể). Nếu người nhận không biết cách xử lý loại này thì nó sẽ xử lý loại đó theo cách tương tự như multipart/mixed .

Về phía máy chủ, các tin nhắn có nhiều nội dung có thể được gửi để đáp lại khi yêu cầu nhiều đoạn tài nguyên. Trong trường hợp này, loại phương tiện multipart/byteranges được sử dụng.