Giao thức HTTP. Các loại yêu cầu HTTP và triết lý REST

Nếu bạn muốn biết dữ liệu được truyền trên Internet như thế nào thì bài viết này là dành cho bạn. Tôi sẽ kể cho bạn mọi thứ tôi biết về giao thức HTTP và HTTPS, chỉ ra sự khác biệt và khác biệt giữa chúng. Thích đọc sách!

HTTP 1.1 - giao thức này là gì?

HTTP (tiếng Anh: Giao thức truyền siêu văn bản) - giao thức mạng cấp cao nhất để truyền siêu văn bản và dữ liệu tùy ý trên Internet.

Tại Trợ giúp HTTP trình duyệt nhận dữ liệu từ máy chủ web và có thể hiển thị dữ liệu đó ở dạng mà người dùng Internet có thể chấp nhận và dễ hiểu. Quá trình ngược lại diễn ra theo cách tương tự - gửi dữ liệu người dùng trở lại máy chủ (ví dụ: trong khi đăng ký).

Nội dung được gửi từ và đến máy chủ có thể được trình bày dưới mọi hình thức: hình ảnh, tệp, tài liệu, liên kết và mã - trong mọi trường hợp, nhờ HTTP mà mọi người có thể sử dụng Internet và tải hàng trăm trang web trong trình duyệt.

Phiên bản hiện tại giao thức - 1.1. Mô tả của nó nằm trong đặc tả RFC.

HTTP được sử dụng trong cơ sở hạ tầng truyền dữ liệu máy khách-máy chủ. Làm thế nào nó hoạt động? Ứng dụng ở phía “máy khách” tạo ra yêu cầu xử lý ở phía “máy chủ”, sau đó phản hồi sẽ được gửi lại cho “máy khách”. Sau đó, “khách hàng” có thể bắt đầu các yêu cầu bổ sung và nhận phản hồi mới. Và như thế.

Ứng dụng “máy khách” phổ biến nhất là một trình duyệt web thông qua đó các tài nguyên web được truy cập. Với sự phát triển công nghệ di động nhiều trình duyệt hơn đã được thêm vào ứng dụng di động trên nhiều loại điện thoại thông minh và máy tính bảng. Hơn nữa, phía máy chủ của các ứng dụng đa ngành hiện đại có thể xử lý đồng thời dữ liệu từ cả trình duyệt và điện thoại thông minh. Tất cả điều này được thực hiện thông qua giao thức HTTP.

Hơn nữa, HTTP thường hoạt động như một giao thức truyền tải để truyền các thông tin khác giao thức ứng dụng và các API của chúng: WebDAV, XML-RPC, REST, SOAP. Chà, dữ liệu được truyền qua API có thể có nhiều lợi ích nhất định dạng khác nhau: XML, JSON và các thứ khác.

Dữ liệu này được truyền đi như thế nào? Thông thường nhất là qua kết nối TCP/IP: ứng dụng khách sử dụng cổng TCP 80 theo mặc định và máy chủ có thể sử dụng bất kỳ cổng nào khác, nhưng thông thường đây cũng là cổng 80.

Đối tượng thao tác HTTP là tài nguyên được chỉ định trong URI yêu cầu ứng dụng khách, để xác định chính xác “những gì thường cần thiết”. Thông thường đây là các tệp, dữ liệu hoặc đối tượng logic được lưu trữ trên máy chủ. Trong trường hợp này, yêu cầu có thể chỉ ra chính xác cách trình bày cùng một dữ liệu: nên chọn định dạng, mã hóa, ngôn ngữ nào. “Tính năng” này cho phép bạn trao đổi không chỉ siêu văn bản mà còn cả dữ liệu nhị phân.

Tính năng thứ hai của HTTP là nó không lưu trạng thái giữa các cặp yêu cầu-phản hồi liên tiếp. Nhưng đây không phải là vấn đề vì các thành phần ứng dụng ở phía máy khách hoặc phía máy chủ có thể tự lưu trữ thông tin về trạng thái của các yêu cầu và phản hồi mới nhất. Về phía khách hàng, thông tin đó được gọi là cookie, về phía máy chủ - phiên.

Đồng thời, việc trình duyệt máy khách theo dõi độ trễ phản hồi của máy chủ không phải là vấn đề và đối với máy chủ, việc lưu trữ tiêu đề của các yêu cầu mới nhất và địa chỉ IP của máy khách không phải là vấn đề đối với máy chủ. Tuy nhiên, tôi nhấn mạnh một lần nữa, bản thân giao thức không biết gì về điều này - nó chỉ truyền dữ liệu.

Các trung gian (máy chủ proxy) cũng có thể tham gia truyền dữ liệu nhằm phân biệt proxy với máy chủ cuối (gọi là “ máy chủ gốc»).

Điều kỳ diệu bắt đầu khi cùng một chương trình (máy khách hoặc máy chủ) có thể thực hiện các chức năng của trung gian, máy khách hoặc máy chủ - tùy thuộc vào nhiệm vụ.

HTTP/2 - đây là loại giao thức gì?

Phiên bản đầu tiên Giao thức HTTP xuất hiện tại CERN vào năm 1991. Vào năm 1992, phiên bản công khai của HTTP 0.9 và thông số kỹ thuật của nó đã được xuất bản, nhờ đó các quy tắc tương tác giữa ứng dụng khách và ứng dụng máy chủ được sắp xếp hợp lý, cũng như phân định rõ ràng về chức năng.

HTTP/1.0 xuất hiện vào năm 1996 và phiên bản hiện đại của giao thức - HTTP/1.1 - vào năm 1999. Vào đầu thiên niên kỷ, giao thức HTTP đã học cách hỗ trợ chế độ kết nối liên tục, tức là. để kết nối mở sau khi nhận được phản hồi cho yêu cầu. Điều này giúp có thể gửi nhiều yêu cầu cùng lúc trong một kết nối, thay vì phải mở và đóng phiên mỗi lần.

Thời gian trôi qua và khi Internet phát triển, kích thước của các trang tăng lên, số lượng yêu cầu ngày càng tăng - ngày càng cần nhiều tài nguyên hơn. Đây là lý do nảy sinh nhu cầu về một giao thức mới.

Và mười sáu năm sau, vào năm 2015, nó đã được xuất bản Phiên bản cuối cùng dự thảo đặc điểm kỹ thuật phiên bản tiếp theo giao thức - HTTP/2. Giao thức nhị phân HTTP/2 được chuẩn bị tốt hơn cho thực tế hiện đại so với giao thức tiền nhiệm HTTP 1.1 vì giao thức mới giải quyết được vấn đề quan trọng nhất về truyền dữ liệu trên Internet - nhiều kết nối mở.

Và tất cả là do các trang web hiện tại tải rất nhiều thành phần, cả từ máy chủ của họ và từ CDN: tập lệnh JS, kiểu CSS, phông chữ và hình ảnh. Khi truyền một bộ tệp hoàn chỉnh bằng giao thức HTTP 1.1, nhiều kết nối sẽ được tạo. Nếu trong tương lai chúng ta chuyển sang giao thức HTTP/2, quá trình truyền sẽ diễn ra trong một kết nối duy nhất giữa máy khách và máy chủ, điều này sẽ tăng tốc đáng kể và tối ưu hóa việc tải nội dung trang web.

Các tính năng chính của HTTP/2 sẽ hữu ích cho các trang web:

Sắp xếp và quản lý mức độ ưu tiên của yêu cầu/luồng - máy khách đặt mức độ ưu tiên của tài nguyên và dữ liệu cho máy chủ một cách độc lập
nén tiêu đề HTTP;
Yêu cầu ghép kênh hoặc tải song song một số thành phần trang web qua kết nối TCP - một số yêu cầu được gửi qua một kết nối và máy khách có thể nhận được phản hồi theo bất kỳ thứ tự nào, tức là. bây giờ bạn không cần nhiều mở kết nối TCP;
Tính khả dụng và hỗ trợ từ máy chủ của thông báo đẩy chủ động - máy chủ có thể gửi dữ liệu độc lập đến máy khách mà khách hàng chưa yêu cầu (ví dụ: dựa trên thông tin về trang nào người dùng sẽ mở sau trang này).

Tất nhiên, điều chính ở đây là ghép kênh luồng. Nguyên lý hoạt động rất dễ giải thích: Các gói kết nối TCP/IP được trộn lẫn trong một kết nối. Do đó, ở chế độ hỗn hợp, một số “toa dữ liệu” được kết nối thành một “đoàn tàu”, được tách ra “khi đến nơi”. Trước đây, các “ô tô” buộc phải di chuyển xa hơn và riêng lẻ nhưng giờ đây chúng sẽ di chuyển cùng nhau và nhanh hơn.

Những ưu điểm trên của giao thức HTTP/2 sẽ cho phép các nhà phát triển web thở sâu và từ bỏ những “nạng” như:

Sử dụng số lượng lớn hơn các miền liên quan để đảm bảo thiết lập số lượng lớn kết nối TCP/IP (để tải xuống tệp);
Hình ảnh sprite - khi hình ảnh được kết hợp thành một tệp để giảm số lượng yêu cầu đến máy chủ web (và bản thân tệp đó "phình to" vì có nhiều hình ảnh được ghi vào nó);
Kết hợp các tệp CSS và JS, cũng được thực hiện để giảm yêu cầu.

Ưu điểm rõ ràng cuối cùng là bạn không cần phải làm gì thêm với chính trang web (để bật HTTP/2) - tất cả công việc được thực hiện trên máy chủ chỉ với “1 cú nhấp chuột” và đối với khách hàng chia sẻ và lưu trữ VPS nó thường sẽ không được chú ý.

Tóm lại, chúng ta sẽ sống!

HTTP/2 được tạo và phát triển dựa trên giao thức SPDY/3 dự thảo (Google) và đã vượt qua nó - Google nhận thấy những ưu điểm của HTTP/2 là hứa hẹn hơn và sẽ từ bỏ hỗ trợ cho SPDY/2 trong tương lai.

Khả năng tăng tốc phản hồi của máy chủ thông qua giao thức HTTP/2 được dự đoán sẽ vào khoảng 30%, - bài kiểm tra thực tếđã cho thấy tốc độ cao hơn 19-23% và đây không phải là giới hạn.

Theo kết quả thử nghiệm của Airi.rf, tốc độ tăng lên khi chỉ kích hoạt giao thức HTTP/2 là 13-18% (không tối ưu hóa). Tại sao nó lại quan trọng?

Mặc dù thực tế là việc hỗ trợ giao thức HTTP/2 của một trang web hiện không ảnh hưởng trực tiếp đến thứ hạng của các trang web trong Google và Yandex, nhưng vị trí trong kết quả tìm kiếm vẫn bị ảnh hưởng bởi tốc độ tải. Và vì giao thức hiển thị nhiều hơn tốc độ cao lượt tải xuống (là một yếu tố khá quan trọng), nó gián tiếp ảnh hưởng đến thứ hạng.

Chủ yếu là do yếu tố hành vi. Tải nhanh hơn cho phép người dùng bớt mệt mỏi và tập trung hơn vào việc khám phá trang web: xem nhiều trang hơn và không rời khỏi trang web vì thời gian tải lâu(thất bại giảm).

Hầu hết các trình duyệt hiện đại đều đã hỗ trợ HTTP/2 - ~70% lưu lượng truy cập Internet đi qua chúng:

Chrome 41-52 và Chrome 46+ trên Android;
Firefox 36-48 và Firefox 41+ trên Android;
Opera 28-34 và Opera 30+ trên Android;
Safari 9 và Safari trong iOS 9.1;
IE 11 trên Windows 10 và Trình duyệt cạnh 12, 13.

Vẫn chưa rõ khi nào quá trình chuyển đổi hoàn toàn sang HTTP/2 sẽ diễn ra - rất có thể là trong tương lai rất gần. Điều quan trọng là không ai vội vàng từ bỏ HTTP/1.x. Như người ta nói: “Nếu nó hoạt động thì đừng chạm vào nó”.

Giao thức HTTPS có ý nghĩa gì và nó được sử dụng ở đâu?

Chà, bạn đã biết mọi thứ về trao đổi dữ liệu bằng giao thức HTTP: mọi hoạt động truyền dữ liệu đều được thực hiện thông qua các yêu cầu sử dụng giao thức truyền tải này. Tại sao chúng ta cần HTTPS và nó là gì? Rốt cuộc chúng ta vẫn sống bình thường khi không có anh ấy?

Vấn đề là dữ liệu qua HTTP không được bảo vệ và được truyền tới biểu mẫu mở. Internet là một mạng lưới phân phối toàn cầu của các nút. Và nếu bạn truyền dữ liệu mở qua giao thức không bảo mật (Wi-Fi trong trung tâm mua sắm cũng được áp dụng ở đây), thì một trong các nút này có thể chặn dữ liệu đó.

Tất nhiên là không cố ý, nó có thể chỉ bị bọn tội phạm hack. HTTPS được tạo để đảm bảo kết nối được an toàn và dữ liệu được truyền ở dạng mã hóa bằng giao thức mã hóa SSL/TLS. Đây là một “trình bao bọc” đặc biệt trên HTTP; nó mã hóa dữ liệu, khiến những kẻ xâm nhập và những người không được phép không thể truy cập được.

HTTPS - tiếng Anh "Giao thức truyền siêu văn bản an toàn".

Vì vậy, không giống như cổng 80 mặc định trong HTTP, HTTPS sử dụng cổng TCP 443 và có khóa mã hóa. Khóa có thể dài 40, 56, 128 hoặc 256 bit; mức bảo mật đủ hiện bắt đầu bằng khóa 128 bit.

Bây giờ tất cả các trình duyệt đều hỗ trợ HTTPS - nó được bật tự động khi có thể và máy chủ yêu cầu nó.

Điều quan trọng là sử dụng HTTPS trong các dịch vụ sau:

Hệ thống thanh toán điện tử (ngân hàng, tiền điện tử, v.v.);
Các dịch vụ nhận và gửi thông tin cá nhân và dữ liệu cá nhân, chẳng hạn như Yandex có: Passport, Taxi, Direct, Metrica, Mail, Money, Webmaster và các dịch vụ khác;
Mạng xã hội và tài khoản cá nhân trong dịch vụ Internet;
Công cụ tìm kiếm.

HTTPS hoạt động đơn giản. Tôi sẽ giải thích bằng một ví dụ.

Bạn nhập thông tin quan trọng (thông tin đăng nhập, mật khẩu, chi tiết thẻ, dữ liệu cá nhân) vào một ô, “khóa bằng chìa khóa”: ô đó sẽ mã hóa dữ liệu của bạn bằng khóa này.

Bây giờ gửi nó qua thư cho người nhận. Người nhận nhận được ô bưu kiện nhưng không mở được - không có chìa khóa. Sau đó, anh ta khóa (mã hóa) ô bằng khóa thứ hai và trả lại bưu kiện cho bạn. Bạn nhận được một gói hàng có hai ổ khóa, nhưng bạn có chìa khóa của một ổ khóa. Bây giờ bạn có thể mở khóa (giải mã dữ liệu) và gửi lại gói hàng cho người nhận ban đầu.

Đồng thời, dữ liệu vẫn được bảo vệ - xét cho cùng, nó chưa được bất kỳ ai xem hoặc thay đổi và cho đến khi người nhận nhận được, nó sẽ được bảo vệ bằng khóa mã hóa. Người nhận nhận được bưu kiện đã có một khóa, giải mã nó và xử lý dữ liệu của bạn. Ví dụ, nó thực hiện giao dịch của bạn.

Vậy đó - đó là cách HTTPS hoạt động.

Thủ thuật ở đây là trong lần trao đổi đầu tiên như vậy, khóa mã hóa được trao đổi sao cho cả người nhận cuối cùng đều biết, nhưng bất kỳ nút nào dọc theo tuyến dữ liệu đều không biết. Sau khi trao đổi mật mã, bạn có thể thoải mái trao đổi tin nhắn (đã mã hóa) mà không sợ bị chặn dữ liệu này, vì nếu không có khóa mật mã thì sẽ không thể mở và đọc được.

Lưu ý duy nhất ở đây là bạn cần biết rằng bạn đang gửi dữ liệu chính xác đến nơi cần thiết. Và điểm cuối cùng chính là đích đến. Nhưng bạn cần xác nhận và biết chắc chắn rằng đích cuối cùng tồn tại và được kiểm soát bởi chính máy chủ nơi dữ liệu được gửi.

Để thực hiện việc này, các máy chủ sẽ nhận được chứng chỉ bảo mật HTTPS đặc biệt từ các trung tâm chứng nhận, chứng chỉ này xác nhận “tính cuối cùng” của đích đến (rằng trang web không phải là nút truyền dữ liệu thêm) và chức năng của công nghệ mã hóa SSL/TLS, tức là. bảo mật kết nối.

Và đây là hình ảnh của chứng chỉ:

Hiện tại, HTTPS được tích hợp trong tất cả các trình duyệt hiện đại và tất cả những gì người dùng yêu cầu để duy trì tính bảo mật khi gửi dữ liệu qua HTTPS là cập nhật thường xuyên. phần mềmđể lướt, nhận và gửi dữ liệu quan trọng trên Internet.

Thực hiện tương tác client-server thông qua Giao thức HTTPS Bạn không phải lo lắng về sự an toàn của dữ liệu - bạn được bảo vệ một cách đáng tin cậy khỏi việc nghe lén kết nối mạng của mình: các cuộc tấn công của kẻ đánh hơi và các cuộc tấn công trung gian.

Biểu tượng HTTPS bị gạch chéo và biểu tượng HTTPS màu xanh lá cây có ý nghĩa gì, có gì khác biệt? An toàn. Màu xanh lá cây là an toàn, màu đỏ và gạch chéo là không an toàn.

Và rất tiện lợi khi biểu tượng HTTPS bị gạch chéo có nghĩa là dù sử dụng giao thức này nhưng kết nối không an toàn. Điều này xảy ra khi các thành phần trang web không được tải qua HTTPS hoặc chứng chỉ đã hết hạn. Người dùng có thể thấy ngay - vâng, nó không an toàn. Và anh ta có thể rời khỏi trang web hoặc mạo hiểm dữ liệu của mình.

HTTP 1.1, HTTP/2 hay HTTPS cái nào tốt hơn?

Tóm lại, tôi sẽ đề cập đến chủ đề sử dụng các giao thức tốt hơn.

Rõ ràng là hiện tại HTTP 1.1 là giao thức phổ biến nhất và được sử dụng theo mặc định. Thời của HTTP/2 vẫn chưa đến nhưng chẳng bao lâu nữa hầu hết lưu lượng truy cập Internet sẽ đi qua phiên bản thứ hai của giao thức HTTP. Điều này sẽ giúp cuộc sống của người dùng dễ dàng hơn vì các trang web sẽ tải nhanh hơn. Quản trị viên máy chủ và trang web cũng sẽ rất vui vì giao thức mới cho phép bạn tối ưu hóa trang web theo cách mới, tăng tốc độ tải và tải lên dữ liệu.

Nói như vậy, khó có khả năng tất cả các trang web sẽ chuyển sang HTTPS, vì vì mục đích tiêu dùng nội dung giải trí mã hóa là vô ích. Có, hiện 10% trang web sử dụng HTTPS trong bảng xếp hạng Alexa về các tài nguyên web được truy cập nhiều nhất. Nhưng đây chỉ là mười phần trăm, bao gồm cả những gã khổng lồ như Google, PayPal, Amazon, Aliexpress và những hãng khác. Nghĩa là, có nhiều trang web không sử dụng HTTPS có nghĩa là vi phạm quyền của người dùng Internet về bảo mật và tính toàn vẹn của dữ liệu.

Nhưng các trang web thông thường như blog của bảy blogger không cần HTTPS - không nhận dữ liệu cá nhân hoặc thanh toán, không đăng ký và gửi tin nhắn quan trọng.

Vì vậy trong thời gian tới chúng ta sẽ dần dần chuyển từ HTTP 1.1 sang HTTP/2 và HTTPS.

Giao thức truyền siêu văn bản (HTTP) là giao thức cấp cao (cụ thể là cấp ứng dụng) cung cấp tốc độ truyền dữ liệu cần thiết cho các hệ thống thông tin siêu phương tiện phân tán. HTTP đã được dự án World Wide Web sử dụng từ năm 1990.

Các hệ thống thông tin thực tế đòi hỏi nhiều hơn việc truy xuất, sửa đổi và chú thích dữ liệu nguyên thủy. HTTP/1.0 cung cấp một tập hợp các phương thức mở có thể được sử dụng để chỉ định mục đích của một yêu cầu. Chúng được xây dựng dựa trên nguyên tắc tham chiếu, trong đó Mã định danh tài nguyên chung (URI), ở dạng vị trí (URL) hoặc tên (URN), được sử dụng để chỉ ra tài nguyên mà một phương thức nhất định sẽ được áp dụng. Định dạng thư tương tự như Internet Mail hoặc Phần mở rộng thư Internet đa năng (MIME).

HTTP/1.0 cũng được sử dụng để liên lạc giữa nhiều trình duyệt người dùng và cổng khác nhau cho phép truy cập siêu phương tiện vào các giao thức Internet hiện có như SMTP, NNTP, FTP, Gopher và WAIS. HTTP/1.0 được thiết kế để cho phép các cổng như vậy truy cập máy chủ proxy, không bị mất mát, truyền dữ liệu bằng các giao thức đã đề cập của các phiên bản trước đó.

Cấu trúc chung

HTTP dựa trên mô hình yêu cầu/phản hồi. Chương trình yêu cầu (thường được gọi là máy khách) thiết lập kết nối với chương trình dịch vụ nhận (thường được gọi là máy chủ) và gửi yêu cầu đến máy chủ theo dạng sau: phương thức yêu cầu, URI, phiên bản giao thức, theo sau là một thông báo giống MIME chứa thông tin kiểm soát yêu cầu, thông tin về khách hàng và có thể là nội dung của tin nhắn. Máy chủ phản hồi bằng thông báo chứa chuỗi trạng thái (bao gồm phiên bản giao thức và mã trạng thái thành công hoặc lỗi), theo sau là thông báo giống MIME bao gồm thông tin về máy chủ, siêu thông tin về nội dung phản hồi và có thể cả phản hồi bản thân cơ thể. Cần lưu ý rằng một chương trình có thể đồng thời là máy khách và máy chủ. Việc sử dụng các thuật ngữ này trong văn bản này chỉ đề cập đến vai trò được chương trình thực hiện trong phiên giao tiếp cụ thể đó chứ không đề cập đến các chức năng chung của chương trình.

Trên Internet, thông tin liên lạc thường dựa trên giao thức TCP/IP. Đối với WWW, số cổng mặc định là TCP 80, nhưng cũng có thể sử dụng các số cổng khác - điều này không loại trừ khả năng sử dụng HTTP làm giao thức cấp cao nhất.

Đối với hầu hết các ứng dụng, một phiên được máy khách mở cho mỗi yêu cầu và được máy chủ đóng sau khi phản hồi yêu cầu được hoàn thành. Tuy nhiên, đây không phải là một tính năng của giao thức. Ví dụ: cả máy khách và máy chủ đều phải có khả năng đóng phiên giao tiếp do một số hành động của người dùng. Trong mọi trường hợp, việc ngắt kết nối do một trong hai bên thực hiện sẽ chấm dứt yêu cầu hiện tại, bất kể trạng thái của nó.

Khái niệm chung

Yêu cầu là một tin nhắn được gửi bởi máy khách đến máy chủ.
Dòng đầu tiên của thông báo này bao gồm phương thức được áp dụng cho tài nguyên được yêu cầu, mã định danh tài nguyên và phiên bản giao thức sẽ sử dụng. Để tương thích với giao thức HTTP/0.9, có hai định dạng yêu cầu HTTP:

Truy vấn = Truy vấn đơn giản | Yêu cầu đầy đủ Yêu cầu đơn giản = "GET" SP Yêu cầu-URI CRLF Yêu cầu đầy đủ = Trạng thái dòng *(Tiêu đề chung | Tiêu đề yêu cầu | Tiêu đề nội dung) CRLF [ Nội dung yêu cầu ]

Nếu máy chủ HTTP/1.0 nhận được Yêu cầu đơn giản, nó phải phản hồi bằng Phản hồi đơn giản HTTP/0.9. Máy khách HTTP/1.0 có khả năng xử lý Phản hồi đầy đủ sẽ không bao giờ gửi Yêu cầu đơn giản.

Trạng thái dòng

Dòng Trạng thái bắt đầu bằng một dòng có tên của phương thức, theo sau là URI yêu cầu và phiên bản giao thức đang được sử dụng. Dòng trạng thái kết thúc bằng ký tự CRLF. Các phần tử dòng được phân tách bằng dấu cách (SP). Các ký tự LF và CR không được phép xuất hiện trong Dòng trạng thái, ngoại trừ chuỗi kết thúc CRLF.

Trạng thái chuỗi = Phương thức SP Yêu cầu URI Phiên bản SP-HTTP CRLF

Cần lưu ý rằng sự khác biệt giữa Dòng trạng thái yêu cầu đầy đủ và Dòng trạng thái Yêu cầu đơn giản bao gồm sự hiện diện của trường Phiên bản HTTP.

Phương pháp

Trường Phương thức chỉ định phương thức sẽ được áp dụng cho tài nguyên được xác định bởi URI yêu cầu. Tên phương thức có phân biệt chữ hoa chữ thường. Danh sách các phương pháp hiện có có thể được mở rộng.

Danh sách các phương thức được một tài nguyên cụ thể cho phép có thể được chỉ định trong trường Tiêu đề-Nội dung của “Điểm”. Tuy nhiên, máy khách luôn được máy chủ thông báo thông qua mã trạng thái phản hồi xem phương thức này có được phép sử dụng cho tài nguyên đã chỉ định hay không, vì việc sử dụng phương thức này được cho phép Các phương pháp khác nhau có thể thay đổi một cách năng động. Nếu máy chủ đã biết một phương thức nhất định nhưng không được phép đối với tài nguyên đã chỉ định thì máy chủ PHẢI trả về mã trạng thái là "Phương thức 405 không được phép" và mã trạng thái là "501 Không được triển khai" nếu phương thức đó không được biết hoặc không được hỗ trợ bởi máy chủ nhất định. Các phương thức HTTP/1.0 phổ biến được mô tả bên dưới.

LẤY

Phương thức GET được sử dụng để truy xuất bất kỳ thông tin nào được xác định bởi URI yêu cầu. Nếu URI yêu cầu đề cập đến một quy trình tạo ra dữ liệu thì phản hồi sẽ là dữ liệu do quy trình đó tạo ra chứ không phải chính mã quy trình (trừ khi đó là đầu ra của quy trình).

Phương thức GET được thay đổi thành "GET có điều kiện" nếu thông báo yêu cầu bao gồm trường tiêu đề "If-Modified-Since". Để đáp lại GET có điều kiện, nội dung của tài nguyên được yêu cầu chỉ được truyền đi nếu nó đã được sửa đổi kể từ ngày được chỉ định trong tiêu đề "If-Modified-Since". Thuật toán xác định điều này bao gồm các trường hợp sau:

Nếu mã trạng thái phản hồi yêu cầu khác với "200 OK" hoặc ngày được chỉ định trong trường tiêu đề "If-Modified-Since" không chính xác thì phản hồi sẽ giống hệt với phản hồi đối với yêu cầu GET thông thường.
Nếu sau ngày quy định tài nguyên đã thay đổi, phản hồi cũng sẽ giống hệt với phản hồi cho yêu cầu GET thông thường.
Nếu tài nguyên chưa được sửa đổi kể từ ngày được chỉ định, máy chủ sẽ trả về mã trạng thái "304 Không được sửa đổi".

Việc sử dụng phương thức GET có điều kiện nhằm mục đích dỡ bỏ mạng vì nó cho phép bạn tránh truyền thông tin dư thừa qua mạng.

CÁI ĐẦU

Phương thức HEAD tương tự như phương thức GET, ngoại trừ việc máy chủ không trả về Nội dung phản hồi trong phản hồi. Thông tin meta có trong tiêu đề HTTP của phản hồi cho yêu cầu HEAD phải giống với thông tin có trong tiêu đề HTTP của phản hồi cho yêu cầu GET. Phương pháp này có thể được sử dụng để lấy siêu thông tin về tài nguyên mà không cần truyền tải tài nguyên đó qua mạng. Phương thức "HEAD có điều kiện", tương tự như GET có điều kiện, không được xác định.

BƯU KIỆN

Phương thức POST được sử dụng để yêu cầu máy chủ chấp nhận thông tin có trong yêu cầu dưới dạng phụ thuộc vào tài nguyên được chỉ định trong Dòng trạng thái trong trường URI yêu cầu. Phương thức POST được thiết kế để cho phép một phương pháp chung cho các chức năng sau:

Tóm tắt các tài nguyên hiện có
Thêm tin nhắn vào nhóm tin, danh sách gửi thư hoặc nhóm bài viết tương tự
Cung cấp các khối dữ liệu cho các quy trình xử lý dữ liệu
Mở rộng cơ sở dữ liệu thông qua thao tác chắp thêm

Chức năng thực tế được thực hiện bằng phương thức POST được xác định bởi máy chủ và thường phụ thuộc vào URI yêu cầu. Thông tin được thêm vào được xử lý như một cấp dưới của URI được chỉ định theo nghĩa tương tự như một tệp phụ thuộc vào thư mục chứa nó, một bài viết mới phụ thuộc vào nhóm tin mà nó được thêm vào, một mục nhập phụ thuộc vào kho dữ liệu.

Máy khách có thể đề xuất URI để xác định tài nguyên mới bằng cách đưa tiêu đề "URI" vào yêu cầu. Tuy nhiên, máy chủ chỉ nên coi URI này là gợi ý và có thể lưu trữ nội dung yêu cầu dưới một URI khác hoặc hoàn toàn không có URI nào cả.

Nếu do quá trình xử lý ĐĂNG yêu cầuđã được tạo ra tài nguyên mới, phản hồi phải có mã trạng thái là "201 Created" và chứa URI của tài nguyên mới.

ĐẶT

Phương thức PUT yêu cầu máy chủ lưu trữ Nội dung yêu cầu trong một URI bằng với URI yêu cầu. Nếu URI yêu cầu đề cập đến một tài nguyên đã tồn tại thì Nội dung yêu cầu sẽ được coi là phiên bản được sửa đổi của tài nguyên này. Nếu tài nguyên được tham chiếu bởi URI yêu cầu không tồn tại và URI đã cho có thể được coi là mô tả cho tài nguyên mới thì máy chủ có thể tạo tài nguyên với URI đã cho. Nếu một tài nguyên mới đã được tạo, máy chủ phải thông báo cho khách hàng yêu cầu thông qua phản hồi với mã trạng thái “201 Đã tạo”. Nếu tài nguyên hiện có đã được sửa đổi, phản hồi "200 OK" phải được gửi để thông báo cho khách hàng rằng thao tác đã thành công. Nếu không thể tạo hoặc sửa đổi tài nguyên có URI được chỉ định thì phải gửi thông báo lỗi thích hợp.

Sự khác biệt cơ bản giữa phương thức POST và PUT là ý nghĩa khác nhau của trường URI yêu cầu. Đối với phương thức POST, URI này chỉ định một tài nguyên sẽ quản lý thông tin có trong phần thân yêu cầu dưới dạng phần phụ. Tài nguyên có thể là một quy trình xử lý dữ liệu, một cổng vào một số giao thức khác hoặc một tài nguyên riêng biệt cho phép chú thích. Ngược lại, URI cho yêu cầu PUT xác định thông tin có trong Nội dung yêu cầu. Người dùng yêu cầu PUT biết chính xác URI nào nó dự định sử dụng và người nhận yêu cầu không nên cố gắng áp dụng yêu cầu đó cho một số tài nguyên khác.

XÓA BỎ

Phương thức DELETE được sử dụng để xóa các tài nguyên được xác định bởi URI yêu cầu. Kết quả của phương pháp này trên máy chủ có thể được thay đổi thông qua sự can thiệp của con người (hoặc một số phương tiện khác). Về nguyên tắc, máy khách không bao giờ có thể chắc chắn rằng thao tác xóa đã hoàn thành, ngay cả khi mã trạng thái được máy chủ gửi cho biết thao tác xóa đã thành công. Tuy nhiên, máy chủ sẽ không báo cáo thành công cho đến khi nó sắp bị xóa tại thời điểm phản hồi. tài nguyên này hoặc di chuyển nó đến một số khu vực không thể truy cập được.

LIÊN KẾT

Phương thức LINK thiết lập mối quan hệ giữa tài nguyên hiện có được chỉ định trong URI yêu cầu và các tài nguyên hiện có khác. Sự khác biệt giữa phương thức LINK và các phương pháp khác cho phép thiết lập liên kết giữa các tài liệu là phương thức LINK không cho phép chuyển Nội dung yêu cầu trong một yêu cầu và do phương pháp này, các tài nguyên mới không được tạo.

HỦY LIÊN KẾT

Phương thức UNLINK loại bỏ một hoặc nhiều mối quan hệ liên kết cho tài nguyên được chỉ định trong URI yêu cầu. Những mối quan hệ này có thể được thiết lập bằng phương pháp LINK hoặc một số phương pháp khác hỗ trợ tiêu đề "Liên kết". Việc xóa liên kết đến một tài nguyên không có nghĩa là tài nguyên đó không còn tồn tại hoặc không còn khả dụng để tham khảo trong tương lai.

Trường tiêu đề yêu cầu

Các trường Tiêu đề yêu cầu cho phép máy khách gửi đến máy chủ Thông tin thêm về yêu cầu và về chính khách hàng.

Ngoài ra, các tiêu đề bổ sung có thể được xác định thông qua cơ chế mở rộng; các ứng dụng không nhận ra chúng phải coi các tiêu đề này là Nội dung tiêu đề.

Một số trường tiêu đề yêu cầu sẽ được thảo luận dưới đây.

Từ

Nếu có trường Từ thì trường này phải chứa địa chỉ E-mail đầy đủ của người dùng kiểm soát chương trình tổng đài viên thực hiện các yêu cầu. Địa chỉ này phải được chỉ định theo định dạng được xác định trong RFC 822. Định dạng của trường này là: From = "From" ://đặc tả địa chỉ. Ví dụ:

Từ: [email được bảo vệ]

Trường này có thể được sử dụng cho các chức năng đăng nhập cũng như để xác định nguồn của các yêu cầu không chính xác hoặc không mong muốn. Nó không nên được sử dụng như một hình thức kiểm soát truy cập chưa được phân loại. Giải thích của trường này là yêu cầu đang được xử lý được thực hiện thay mặt cho người dùng nhất định, người chịu trách nhiệm về phương thức được sử dụng. Đặc biệt, các đặc vụ robot nên sử dụng tiêu đề này để có thể liên hệ với người chịu trách nhiệm về robot nếu có vấn đề phát sinh. Địa chỉ thư Internet được chỉ định trong trường này không nhất thiết phải khớp với địa chỉ của máy chủ lưu trữ mà nó được gửi đi. yêu cầu này. Nếu có thể, địa chỉ đó phải là địa chỉ Internet có thể truy cập được, bất kể đó có thực sự là địa chỉ Internet hay không Địa chỉ email hoặc Internet E-mail đại diện cho địa chỉ của các hệ thống thư khác.

Lưu ý: Máy khách không nên sử dụng trường tiêu đề Từ mà không có sự cho phép của người dùng vì điều này có thể xung đột với lợi ích riêng tư của nó hoặc với hệ thống bảo mật cục bộ của nó. Chúng tôi đặc biệt khuyên người dùng nên được cung cấp tùy chọn tắt, bật hoặc sửa đổi trường này bất kỳ lúc nào trước khi đưa ra yêu cầu.

Nếu-Sửa đổi-Kể từ

Trường tiêu đề If-Modified-Since được sử dụng với phương thức GET để đặt điều kiện: nếu tài nguyên được yêu cầu không thay đổi trong thời gian được chỉ định trong trường này, thì máy chủ sẽ không trả về bản sao của tài nguyên đó; thay vào đó, phản hồi "304 Không được sửa đổi" không có Nội dung phản hồi sẽ được trả về.

If-Modified-Since = "If-Modified-Since" ://Ngày HTTP

Ví dụ về việc sử dụng tiêu đề:

Mục đích của tính năng này là cho phép cập nhật hiệu quả thông tin bộ đệm cục bộ với lượng thông tin được truyền tối thiểu. Kết quả tương tự có thể đạt được bằng cách sử dụng phương thức HEAD theo sau là sử dụng GET nếu máy chủ chỉ ra rằng nội dung của tài liệu đã thay đổi.

Đại lý người dùng

Trường tiêu đề Tác nhân người dùng chứa thông tin về tác nhân người dùng đã gửi yêu cầu. Trường này được sử dụng để thống kê, theo dõi lỗi giao thức và nhận dạng tác nhân người dùng tự động. Mặc dù không bắt buộc nhưng tác nhân người dùng phải luôn đưa trường này vào yêu cầu của họ. Trường này có thể chứa nhiều dòng biểu thị tên của sản phẩm phần mềm, dấu gạch chéo lên phía trước tùy chọn cho biết phiên bản sản phẩm và các dòng khác. sản phẩm phần mềm, các thành phần phần quan trọngđại lý người dùng. Theo quy ước, các sản phẩm được liệt kê theo thứ tự giảm dần về tầm quan trọng của chúng đối với việc xác định ứng dụng.

Tác nhân người dùng = "Tác nhân người dùng" => 1*(sản phẩm) sản phẩm = chuỗi ["/" phiên bản sản phẩm] phiên bản sản phẩm = chuỗi

Tác nhân người dùng: CERN-LineMode/2.15 libwww/2.17b3

Dòng mô tả tên sản phẩm phải ngắn gọn và đi vào trọng tâm - việc sử dụng tiêu đề này để quảng cáo bất kỳ thông tin không liên quan nào khác đều không được phép và sẽ bị coi là không phù hợp với quy định. Mặc dù bất kỳ chuỗi nào cũng có thể xuất hiện trong trường phiên bản sản phẩm, dòng đã cho chỉ nên được sử dụng để chỉ ra phiên bản sản phẩm. Trường Tác nhân người dùng có thể bao gồm thông tin bổ sung trong nhận xét không phải là một phần giá trị của nó.

Cấu trúc phản hồi

Sau khi nhận và giải thích yêu cầu, máy chủ sẽ gửi phản hồi theo mẫu sau:

Trả lời = Trả lời đơn giản | Phản hồi đầy đủ Phản hồi đơn giản = [ Nội dung phản hồi ] Phản hồi đầy đủ = Trạng thái dòng * (Tiêu đề chung | Tiêu đề phản hồi | Tiêu đề nội dung) CRLF [ Nội dung phản hồi ]

Phản hồi đơn giản chỉ nên được gửi để đáp lại Yêu cầu đơn giản HTTP/0.9 hoặc nếu máy chủ chỉ hỗ trợ giao thức HTTP/0.9 bị giới hạn. Nếu máy khách gửi Yêu cầu đầy đủ HTTP/1.0 và nhận được phản hồi không bắt đầu bằng Dòng trạng thái, thì nó phải giả định rằng phản hồi của máy chủ là Phản hồi đơn giản và xử lý phản hồi đó cho phù hợp. Cần lưu ý rằng Phản hồi đơn giản chỉ bao gồm thông tin được yêu cầu (không có tiêu đề) và luồng dữ liệu sẽ dừng tại thời điểm máy chủ đóng phiên giao tiếp.

Trạng thái dòng

Dòng đầu tiên của Full-Request là Dòng trạng thái bao gồm phiên bản giao thức, theo sau là mã kỹ thuật số trạng thái và câu văn bản liên quan. Tất cả các phần tử Trạng thái dòng được phân tách bằng dấu cách. Các ký tự CR và LF không được phép, ngoại trừ chuỗi CRLF ở cuối.

Line-Status=Phiên bản-HTTP SP Mã trạng thái SP Giải thích cụm từ.

Vì Dòng trạng thái luôn bắt đầu bằng phiên bản giao thức "HTTP/" 1*DIGIT "." 1*DIGIT (ví dụ: HTTP/1.0), sự tồn tại của biểu thức này được coi là cơ bản để xác định xem phản hồi là Phản hồi đơn giản hay Phản hồi đầy đủ. Mặc dù định dạng Phản hồi đơn giản không ngăn dòng như vậy xuất hiện (điều này có thể dẫn đến thông báo phản hồi bị hiểu sai thành Phản hồi đầy đủ), khả năng xảy ra trường hợp như vậy là gần bằng không.

Mã trạng thái và giải thích cho nó

Phần tử Mã trạng thái là toàn bộ mã gồm 3 chữ số xác định kết quả của nỗ lực diễn giải và đáp ứng yêu cầu. Cụm từ giải thích theo sau được dùng để mô tả văn bản ngắn gọn về Mã trạng thái. Mã trạng thái được thiết kế để sử dụng cho máy, trong khi Cụm từ giải thích dành cho con người. Khách hàng không bắt buộc phải kiểm tra và hiển thị Cụm từ giải thích.

Chữ số đầu tiên của Mã trạng thái nhằm xác định loại phản hồi. Hai chữ số cuối không đóng vai trò phân loại nào. Có 5 ý nghĩa cho chữ số đầu tiên:

1xx: Thông tin - Không được sử dụng, nhưng được dành để sử dụng trong tương lai
2xx: Thành công - Yêu cầu đã được nhận, hiểu đầy đủ và được chấp nhận để xử lý.
3xx: Chuyển hướng - Khách hàng nên thực hiện hành động hơn nữađể hoàn thành yêu cầu thành công. Hành động bổ sung bắt buộc đôi khi có thể được khách hàng thực hiện mà không cần sự tương tác của người dùng, nhưng chúng tôi đặc biệt khuyến nghị rằng điều này chỉ xảy ra trong trường hợp phương thức được sử dụng trong yêu cầu không quan trọng (GET hoặc HEAD).
4xx: Lỗi máy khách - Yêu cầu chứa cú pháp không hợp lệ không thể hoàn thành thành công. Lớp 4xx nhằm mô tả các trường hợp xảy ra lỗi ở phía máy khách. Nếu client chưa hoàn thành yêu cầu khi nhận được phản hồi với Status Code - 4xx thì phải dừng ngay việc truyền dữ liệu về server. Loại này Mã trạng thái có thể áp dụng cho mọi phương thức được sử dụng trong yêu cầu.
5xx: Lỗi máy chủ - Máy chủ không thể cung cấp phản hồi cho yêu cầu được gửi chính xác. Trong những trường hợp này
máy chủ biết nó đã xảy ra lỗi hoặc không thể xử lý yêu cầu. Ngoại trừ phản hồi cho các yêu cầu HEAD, máy chủ sẽ gửi mô tả về tình huống lỗi và liệu tình trạng đó là tạm thời hay vĩnh viễn trong Nội dung phản hồi. Loại Mã trạng thái này có thể áp dụng cho mọi phương thức được sử dụng trong yêu cầu.

Ý nghĩa riêng của Mã trạng thái và Cụm từ giải thích tương ứng được đưa ra dưới đây. Các cụm từ giải thích này chỉ được khuyến nghị - chúng có thể được thay thế bằng bất kỳ cụm từ nào khác vẫn giữ nguyên ý nghĩa và được giao thức cho phép.

Các ứng dụng HTTP không bắt buộc phải hiểu tất cả các Mã trạng thái, mặc dù sự hiểu biết như vậy rõ ràng là mong muốn. Tuy nhiên, các ứng dụng bắt buộc phải có khả năng nhận dạng các loại Mã trạng thái (được xác định bằng chữ số đầu tiên) và xử lý tất cả các Mã trạng thái phản hồi như thể chúng tương đương với Mã trạng thái x00.

Trường phản hồi tiêu đề

Các trường tiêu đề phản hồi cho phép máy chủ chuyển thông tin bổ sung về phản hồi không thể đưa vào Dòng trạng thái. Các trường tiêu đề này không nhằm mục đích truyền tải thông tin về nội dung phản hồi được gửi để đáp lại yêu cầu, nhưng chúng có thể chứa thông tin về chính máy chủ.

Phản hồi-Tiêu đề= Công khai | Thử lại sau | Máy chủ | WWW-Xác thực | tiêu đề mở rộng

Mặc dù các trường tiêu đề phản hồi bổ sung có thể được triển khai thông qua cơ chế mở rộng, nhưng các ứng dụng không nhận ra các trường này phải coi chúng là các trường Nội dung tiêu đề. Bạn có thể tìm thấy mô tả đầy đủ về các trường này trong đặc tả giao thức HTTP CERN.

Khái niệm chung

Full-Request và Full-Response có thể được sử dụng để chuyển một số thông tin tới yêu cầu cá nhân Và câu trả lời. Thông tin này lần lượt là Nội dung yêu cầu hoặc Nội dung phản hồi và Tiêu đề nội dung.

Trường Tiêu đề-Nội dung

Các trường Nội dung tiêu đề chứa thông tin meta tùy chọn tương ứng về Nội dung yêu cầu hoặc Nội dung phản hồi. Nếu không có nội dung của thông báo tương ứng (yêu cầu hoặc phản hồi) thì Tiêu đề nội dung sẽ chứa thông tin về tài nguyên được yêu cầu.

Một số trường tiêu đề nội dung được mô tả bên dưới.

Cho phép

Trường tiêu đề Cho phép là danh sách các phương thức mà tài nguyên được xác định bởi URI yêu cầu hỗ trợ. Mục đích của trường này là thông báo chính xác cho người nhận về các phương thức hợp lệ được liên kết với tài nguyên; trường này phải xuất hiện trong phản hồi có mã trạng thái “Phương thức 405 không được phép”.

Cho phép = "Cho phép" => 1#method

Ví dụ sử dụng:

Cho phép: GET, HEAD, PUT

Tất nhiên, khách hàng có thể thử các phương pháp khác. Tuy nhiên, nên làm theo các phương pháp được chỉ ra trong trường này. Trường này không có giá trị mặc định; nếu không được xác định, tập hợp các phương thức được phép sẽ được máy chủ xác định tại thời điểm mỗi yêu cầu.

Thời lượng nội dung

Trường Độ dài nội dung chỉ định kích thước của nội dung thư được máy chủ gửi để đáp ứng yêu cầu hoặc, trong trường hợp yêu cầu HEAD, kích thước của nội dung thư sẽ được gửi để đáp ứng yêu cầu GET.

Độ dài nội dung = "Độ dài nội dung" ://: 1*DIGIT

Ví dụ:

Độ dài nội dung: 3495

Mặc dù không bắt buộc nhưng các ứng dụng được khuyến khích sử dụng trường này để phân tích kích thước tin nhắn được truyền đi, bất kể loại thông tin nó chứa. Đối với trường Độ dài nội dung, mọi giá trị số nguyên lớn hơn 0 đều hợp lệ.

Loại nội dung

Trường tiêu đề Kiểu nội dung xác định loại thông tin trong nội dung thư được gửi đến bên nhận hoặc, trong trường hợp phương thức HEAD, loại thông tin (phương tiện) sẽ được gửi nếu sử dụng phương thức GET.

Content-Type = "Content-Type" ://loại môi trường

Các loại phương tiện được xác định riêng.
Ví dụ:

Loại nội dung: văn bản/html; bộ ký tự=ISO-8859-4

Trường Loại nội dung không có giá trị mặc định.

Sửa đổi lần cuối

Trường tiêu đề chứa ngày và giờ mà bên gửi tin rằng tài nguyên đã được sửa đổi lần cuối. Ngữ nghĩa của trường này được xác định bằng các thuật ngữ mô tả cách người nhận diễn giải nó: nếu người nhận có bản sao của tài nguyên cũ hơn ngày được chuyển vào trường Sửa đổi lần cuối thì bản sao đó sẽ được coi là đã lỗi thời .

Sửa đổi lần cuối = "Sửa đổi lần cuối" ://Ngày HTTP

Ví dụ sử dụng:

Ý nghĩa chính xác của trường tiêu đề này phụ thuộc vào việc triển khai của bên gửi và bản chất của chính tài nguyên đó. Đối với các tập tin, đây có thể chỉ là thời gian của anh ấy sửa đổi mới nhất. Đối với cổng cơ sở dữ liệu, đây có thể là thời điểm dữ liệu trong cơ sở dữ liệu được cập nhật lần cuối. Trong mọi trường hợp, người nhận chỉ cần lo lắng về kết quả—có gì trong trường nhất định—và không cần lo lắng về kết quả thu được như thế nào.

Nội dung thư

Nội dung thông báo lần lượt đề cập đến Nội dung yêu cầu hoặc Nội dung phản hồi. Nội dung thư, nếu có, sẽ được gửi trong yêu cầu hoặc phản hồi HTTP/1.0 ở định dạng và mã hóa được chỉ định bởi các trường Nội dung tiêu đề.

Nội dung thư = *OCTET (trong đó OCTET là ký tự 8 bit bất kỳ)

Nội dung thư chỉ được đưa vào yêu cầu nếu phương thức yêu cầu ngụ ý sự hiện diện của nó. Đối với đặc tả HTTP/1.0, các phương thức này là POST và PUT. Nói chung, sự hiện diện của nội dung thư được biểu thị bằng sự hiện diện của các trường tiêu đề nội dung như Độ dài nội dung và/hoặc Mã hóa chuyển nội dung trong yêu cầu được truyền.

Sau khi đọc bài viết này, bạn sẽ tìm hiểu lý do tại sao việc sử dụng tính năng nén lại quan trọng và tác động của nó đến trang web của bạn. Bài viết này dựa trên hai điểm chính...

HTTP. Nó dựa trên sự tương tác" máy khách-máy chủ", nghĩa là, người ta giả định rằng:

Người tiêu dùng- khách hàng sau khi bắt đầu kết nối với máy chủ-nhà cung cấp, hãy gửi yêu cầu cho nó;
Các nhà cung cấp- máy chủ, sau khi nhận được yêu cầu, thực hiện các hành động cần thiết và trả về phản hồi cùng kết quả cho khách hàng.
Trong trường hợp này, có hai cách có thể để tổ chức công việc của máy khách:
- Khách hàng mỏng là một máy khách chuyển tất cả các tác vụ xử lý thông tin đến máy chủ. Một ví dụ về máy khách tối thiểu là máy tính có trình duyệt được sử dụng để làm việc với các ứng dụng web.
- Khách hàng béo ngược lại, xử lý thông tin độc lập với máy chủ, chỉ sử dụng máy chủ sau để lưu trữ dữ liệu.

Trước khi chuyển sang các công nghệ web máy khách-máy chủ cụ thể, chúng ta hãy xem xét các nguyên tắc và cấu trúc cơ bản của giao thức HTTP cơ bản.

Giao thức HTTP

HTTP (Giao thức truyền siêu văn bản - RFC 1945, RFC 2616) là giao thức lớp ứng dụng để truyền siêu văn bản.

Thực thể trung tâm trong HTTP là nguồn URL được trỏ đến trong yêu cầu của khách hàng. Thông thường, các tài nguyên này là các tệp được lưu trữ trên máy chủ. Một tính năng của giao thức HTTP là khả năng chỉ định trong yêu cầu và phản hồi phương thức biểu diễn cùng một tài nguyên theo các tham số khác nhau: định dạng, mã hóa, ngôn ngữ, v.v. Đó là nhờ khả năng chỉ định phương thức mã hóa tin nhắn rằng máy khách và máy chủ có thể trao đổi dữ liệu nhị phân, mặc dù ban đầu giao thức nàyđược thiết kế để truyền tải thông tin mang tính biểu tượng. Thoạt nhìn, điều này có vẻ như là một sự lãng phí tài nguyên. Thật vậy, dữ liệu ở dạng tượng trưng chiếm thêm bộ nhớ, tin nhắn tạo thêm tải cho các kênh liên lạc, nhưng định dạng này có nhiều ưu điểm. Tin nhắn được truyền qua mạng có thể đọc được và sau khi phân tích dữ liệu nhận được, Quản trị hệ thống có thể dễ dàng tìm ra lỗi và sửa nó. Nếu cần, một người có thể đóng vai trò là một trong những ứng dụng tương tác bằng cách nhập thủ công các tin nhắn theo định dạng được yêu cầu.

Không giống như nhiều giao thức khác, HTTP là giao thức không có bộ nhớ. Điều này có nghĩa là giao thức không lưu trữ thông tin về các yêu cầu trước đó của máy khách và phản hồi của máy chủ. Các thành phần sử dụng HTTP có thể duy trì độc lập thông tin trạng thái liên quan đến yêu cầu mới nhất Và câu trả lời. Ví dụ: ứng dụng khách web gửi yêu cầu có thể theo dõi độ trễ phản hồi và máy chủ web có thể lưu trữ địa chỉ IP và tiêu đề yêu cầu của khách hàng gần đây.

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

May chủ- Nhà cung cấp 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).
Máy chủ proxyđể hỗ trợ công việc của dịch vụ vận tải.

Khách hàng chính là trình duyệt ví dụ: Internet Explorer, Opera, Mozilla Firefox, Netscape Điều hướng và những người khác. Việc triển khai máy chủ web phổ biến nhất là: Internet Thông tin Dịch vụ (IIS), Apache, lighttpd, nginx. Triển khai máy chủ proxy nổi tiếng nhất: Squid, UserGate, Multiproxy, Naviscope.

Sơ đồ phiên HTTP “cổ điển” trông như thế này.

Thiết lập kết nối TCP.
Yêu cầu khách hàng.
Phản hồi của máy chủ.
Chấm dứt kết nối TCP.

Do đó, máy khách gửi yêu cầu đến máy chủ, nhận được phản hồi từ máy chủ, sau đó quá trình tương tác sẽ dừng lại. Thông thường, yêu cầu của máy khách là yêu cầu chuyển tài liệu HTML hoặc một số tài nguyên khác và phản hồi của máy chủ chứa mã cho tài nguyên này.

Yêu cầu HTTP được máy khách gửi đến máy chủ bao gồm các thành phần sau.

Dòng trạng thái (đôi khi các thuật ngữ dòng trạng thái hoặc dòng truy vấn cũng được dùng để chỉ nó).
Các trường tiêu đề.
Dòng trống.
Thân yêu cầu.

Thanh trạng thái cùng với trường tiêu đềđôi khi còn được gọi là tiêu đề yêu cầu.

Cơm. 2.1.

Thanh trạng thái có định dạng sau:

request_method URL_pecypca giao thức_version HTTP

Chúng ta hãy xem các thành phần của thanh trạng thái, với Đặc biệt chú ý Hãy tập trung vào các phương pháp truy vấn.

Phương phápđược chỉ định trong dòng trạng thái xác định tài nguyên có URL được chỉ định trong cùng một dòng bị ảnh hưởng như thế nào. Phương thức có thể lấy các giá trị GET, POST, HEAD, PUT, DELETE, v.v. Mặc dù có rất nhiều phương thức nhưng chỉ có hai trong số chúng thực sự quan trọng đối với một lập trình viên web: GET và POST.

LẤY. Theo định nghĩa chính thức, phương thức GET nhằm mục đích lấy tài nguyên có URL được chỉ định. Khi nhận được yêu cầu GET, máy chủ phải đọc tài nguyên được chỉ định và bao gồm mã tài nguyên như một phần của phản hồi cho máy khách. Tài nguyên có URL được chuyển như một phần của yêu cầu không nhất thiết phải là trang HTML, tệp hình ảnh hoặc dữ liệu khác. URL tài nguyên có thể trỏ đến mã chương trình thực thi mà nếu đáp ứng một số điều kiện nhất định thì phải được thực thi trên máy chủ. Trong trường hợp này, máy khách được trả về không phải mã chương trình mà là dữ liệu được tạo trong quá trình thực thi. Mặc dù, theo định nghĩa, phương thức GET nhằm mục đích lấy thông tin nhưng nó có thể được sử dụng cho các mục đích khác. Phương thức GET khá phù hợp để truyền những mẩu dữ liệu nhỏ đến máy chủ.
BƯU KIỆN. Theo định nghĩa chính thức tương tự, mục đích chính của phương thức POST là truyền dữ liệu đến máy chủ. Tuy nhiên, giống như phương thức GET, phương thức POST có thể được sử dụng theo nhiều cách khác nhau và thường được sử dụng để lấy thông tin từ máy chủ. Giống như phương thức GET, URL được chỉ định trong thanh trạng thái sẽ trỏ đến một tài nguyên cụ thể. Phương thức POST cũng có thể được sử dụng để bắt đầu một tiến trình.
Các phương thức HEAD và PUT là các sửa đổi Phương thức NHẬN và BÀI ĐĂNG.

Phiên bản giao thức HTTP thường được chỉ định theo định dạng sau:

HTTP/version.modification

Trường tiêu đề, theo dòng trạng thái, cho phép bạn tinh chỉnh yêu cầu, tức là. truyền tải thông tin bổ sung đến máy chủ. Trường tiêu đề có định dạng sau:

Tên trường: Giá trị

Mục đích của một trường được xác định bởi tên của nó, được phân tách khỏi giá trị bằng dấu hai chấm.

Tên của một số trường tiêu đề phổ biến nhất trong yêu cầu của khách hàng và mục đích của chúng được hiển thị trong Bảng 2.1.

Bảng 2.1. Các trường tiêu đề yêu cầu HTTP.

Trường tiêu đề HTTP -lời yêu cầu	Nghĩa
Chủ nhà	Tên miền hoặc địa chỉ IP của máy chủ mà khách hàng đang truy cập
Người giới thiệu	URL của tài liệu tham chiếu tài nguyên được liệt kê trên thanh trạng thái
Từ	Địa chỉ E-mail người dùng làm việc với khách hàng
Chấp nhận	Các loại dữ liệu MIME được khách hàng xử lý. Trường này có thể có nhiều giá trị, cách nhau bằng dấu phẩy. Thông thường, trường tiêu đề Chấp nhận được sử dụng để cho máy chủ biết loại tệp đồ họa nào được máy khách hỗ trợ.
Ngôn ngữ chấp nhận	Một tập hợp các mã định danh gồm hai ký tự, được phân tách bằng dấu phẩy, cho biết các ngôn ngữ được khách hàng hỗ trợ
Bộ ký tự chấp nhận	Danh sách các bộ ký tự được hỗ trợ
Loại nội dung	Loại dữ liệu MIME có trong phần thân yêu cầu (nếu yêu cầu không bao gồm một tiêu đề duy nhất)
Thời lượng nội dung	Số ký tự có trong nội dung yêu cầu (nếu yêu cầu không bao gồm một tiêu đề)
Phạm vi	Trình bày nếu khách hàng không yêu cầu toàn bộ tài liệu mà chỉ một phần của tài liệu đó
Sự liên quan	Được sử dụng để quản lý kết nối TCP. Nếu trường chứa Đóng, điều này có nghĩa là máy chủ sẽ đóng kết nối sau khi xử lý yêu cầu. Giá trị Keep-Alive đề xuất duy trì kết nối TCP mở để có thể sử dụng kết nối này cho các yêu cầu tiếp theo
Đại lý người dùng	Thông tin khách hàng

Trong nhiều trường hợp, khi làm việc trên Web không có nội dung yêu cầu. Khi các tập lệnh CGI được chạy, dữ liệu được chuyển đến chúng trong yêu cầu có thể được đặt trong phần nội dung của yêu cầu.

Tiêu đề HTTP được sử dụng để trao đổi thông tin dịch vụ giữa máy khách và máy chủ. Thông tin này vẫn ẩn đối với người dùng, nhưng không có nó thì không thể làm việc đúng browser. Vì người dùng thông thường Thông tin về điều này và mục đích của các tiêu đề http có vẻ khá phức tạp, nhưng trên thực tế nó không chứa những công thức khó. Đây là điều mà người dùng web gặp phải hàng ngày.

tiêu đề?

“Giao thức truyền siêu văn bản” chính xác là cách nó được dịch. Nhờ sự tồn tại của nó, giao tiếp giữa máy khách và máy chủ là có thể. Nói một cách đơn giản, người dùng trình duyệt sẽ gửi yêu cầu, bắt đầu kết nối đến máy chủ. Theo mặc định, cái sau sẽ chờ yêu cầu từ máy khách, xử lý nó và gửi lại thông tin hoặc phản hồi cuối cùng. Trong thanh tìm kiếm, người dùng “lái xe vào” địa chỉ trang web bắt đầu bằng http:// và nhận kết quả dưới dạng một trang mở ra.

Khi địa chỉ trang web được nhập vào dòng thích hợp, trình duyệt sẽ tìm thấy máy chủ được yêu cầu bằng DNS. Máy chủ nhận ra tiêu đề http (một hoặc nhiều) mà khách hàng gửi tới nó và sau đó đưa ra tiêu đề được yêu cầu. Tập hợp các tiêu đề bắt buộc bao gồm các tiêu đề đã có sẵn và những tiêu đề không được tìm thấy.

Nói chung, tiêu đề http khá hiệu quả. Chúng không hiển thị trong mã hóa HTML; chúng được gửi trước thông tin được yêu cầu. Nhiều tiêu đề được máy chủ gửi tự động. Để gửi nó tới Ngôn ngữ PHP, bạn nên sử dụng chức năng tiêu đề.

Tương tác giữa trình duyệt và trang web

Sự tương tác giữa trình duyệt và trang web khá đơn giản. Vì vậy, tiêu đề http bắt đầu dòng yêu cầu, sau đó được gửi đến máy chủ. Câu trả lời chính là thông tin khách hàng cần. Nhân tiện, giao thức http đã được sử dụng nhiều nhất trên Internet trong mười bảy năm. Nó đơn giản, đáng tin cậy, nhanh chóng và linh hoạt. nhiệm vụ chinh http - yêu cầu thông tin từ máy chủ web. Máy khách là trình duyệt và máy chủ là litthttp, apache, nginx. Nếu kết nối giữa chúng thành công, máy chủ sẽ nhận được thông tin cần thiết để đáp ứng yêu cầu. thông tin http chứa văn bản, tập tin âm thanh, băng hình.

Giao thức có thể là phương tiện vận chuyển cho người khác. Yêu cầu của khách hàng bao gồm ba phần:

dòng bắt đầu (loại tin nhắn);
tiêu đề (tham số tin nhắn);
nội dung thông tin (một tin nhắn được phân tách bằng một dòng trống).

Dòng bắt đầu là thành phần bắt buộc của yêu cầu trường tiêu đề http. Cấu trúc của một yêu cầu của người dùng bao gồm ba phần chính:

Phương pháp. Nó được sử dụng để chỉ ra loại yêu cầu.
Con đường. Đây là chuỗi URL theo tên miền.
Giao thức được sử dụng. Nó bao gồm một giao thức và một phiên bản http.

Các trình duyệt hiện đại sử dụng phiên bản 1.1. Sau đây là các tiêu đề có định dạng "Tên: giá trị".

Bộ nhớ đệm HTTP

Điểm mấu chốt là bộ nhớ đệm đảm bảo rằng các trang HTML và các tệp khác được lưu trữ trong bộ nhớ đệm (một vị trí trong bộ nhớ hoạt động, trên ổ cứng của máy tính). Điều này là cần thiết để tăng tốc độ truy cập nhiều lần vào chúng và tiết kiệm lưu lượng.

Bộ đệm có trình duyệt máy khách, cổng trung gian và máy chủ proxy. Trước khi gửi tin nhắn tới một URL, trình duyệt sẽ kiểm tra xem đối tượng có nằm trong bộ đệm hay không. Nếu không có đối tượng, yêu cầu sẽ được chuyển đến máy chủ tiếp theo, nơi kiểm tra bộ nhớ đệm của các tiêu đề http trên máy chủ nginx. Cổng và proxy được sử dụng bởi những người dùng khác nhau, do đó bộ đệm được chia sẻ.

Bộ nhớ đệm HTTP không chỉ có thể tăng tốc đáng kể trang web mà còn cung cấp phiên bản cũ của trang. Điều này được sử dụng để gửi tiêu đề đến phản hồi. Tuy nhiên, thông tin được yêu cầu qua giao thức HTTPS không thể được lưu vào bộ đệm.

Mô tả tiêu đề http

Một trong những cơ chế bộ đệm quan trọng nhất là tiêu đề http hết hạn. Các tiêu đề này cho biết ngày hết hạn của thông tin được cung cấp trong phản hồi. Chúng cho biết ngày và giờ khi bộ đệm sẽ được coi là lỗi thời. Ví dụ: tiêu đề như sau: Hết hạn: Wen, ngày 30 tháng 11 năm 2016 13:45:00 GMT. Cấu trúc này được sử dụng ở hầu hết mọi nơi, bao gồm cả các trang và hình ảnh trong bộ nhớ đệm. Nếu người dùng chọn ngày cũ thì thông tin sẽ không được lưu vào bộ nhớ đệm.

Tiêu đề proxy HTTP thuộc danh mục liên kết tiêu đề. Chúng không được lưu trữ theo mặc định. Để bộ đệm hoạt động bình thường, mỗi URL phải khớp với một biến thể của nội dung. Nếu một trang song ngữ thì mỗi phiên bản phải có URL riêng. Tiêu đề khác nhau cho bộ đệm biết tên của các tiêu đề yêu cầu. Ví dụ: nếu việc hiển thị yêu cầu phụ thuộc vào trình duyệt thì máy chủ cũng phải gửi tiêu đề. Vì vậy, bộ nhớ đệm lưu trữ các biến thể khác nhau truy vấn và các loại tài liệu. Tiêu đề chấp nhận TTP là cần thiết để biên soạn danh sách các định dạng được chấp nhận của tài nguyên được sử dụng; khá dễ dàng để làm việc với nó, vì nó lọc ra những định dạng không cần thiết.

Tổng cộng có bốn nhóm tiêu đề truyền tải thông tin dịch vụ. Đây là các tiêu đề chính - chúng được chứa trong bất kỳ thông báo, yêu cầu và phản hồi cũng như thực thể nào của máy chủ và máy khách. Cái sau mô tả nội dung của bất kỳ tin nhắn nào từ máy khách và máy chủ.

Tiêu đề ủy quyền HTTP được coi là tùy chọn. Khi một trang web yêu cầu khách hàng ủy quyền, trình duyệt sẽ hiển thị một cửa sổ đặc biệt với các trường để nhập thông tin đăng nhập và mật khẩu. Sau khi người dùng nhập thông tin của họ, trình duyệt sẽ gửi yêu cầu http. Nó chứa tiêu đề "ủy quyền".

Làm cách nào tôi có thể nhìn thấy các tiêu đề?

Để xem tiêu đề http, bạn cần cài đặt plugin trình duyệt, ví dụ: firefox:

Bọ lửa. Bạn có thể xem các tiêu đề trong tab mạng, nơi bạn chọn tất cả. Plugin này có các tính năng hữu ích cho nhà phát triển web.
Sống tiêu đề http. Một plugin đơn giản được thiết kế để xem tiêu đề http. Với sự trợ giúp của nó, bạn có thể tạo yêu cầu theo cách thủ công.
Người dùng Ghrome sẽ dễ dàng nhìn thấy các tiêu đề nếu họ nhấp vào nút cài đặt và chọn công cụ dành cho nhà phát triển (net works).

Sau khi cài đặt xong các plugin, hãy khởi chạy chúng trong trình duyệt của bạn.

Phương thức truy vấn

Các phương thức được sử dụng trong HTTP tương tự như các hướng dẫn được gửi dưới dạng tin nhắn đến máy chủ. Đây là một từ đặc biệt trong tiếng Anh.

Phương thức NHẬN. Nó được sử dụng để yêu cầu thông tin từ một tài nguyên. Đây là nơi mọi hành động bắt đầu.
BƯU KIỆN. Nó được sử dụng để gửi dữ liệu. Ví dụ: một tin nhắn trên mạng xã hội hoặc một bình luận được trình duyệt đặt trong phần nội dung của yêu cầu POST và gửi đến máy chủ.
CÁI ĐẦU. Phương pháp này tương tự như phương pháp đầu tiên nhưng thực hiện một chức năng dễ dàng. Nó chỉ yêu cầu siêu dữ liệu, loại trừ tin nhắn khỏi phản hồi. Phương pháp này được sử dụng nếu bạn muốn lấy thông tin về tập tin mà không cần tải xuống. Nó được sử dụng nếu họ muốn kiểm tra chức năng của các liên kết trên máy chủ.
ĐẶT. Tải dữ liệu vào một URL. Truyền lượng lớn dữ liệu.
TÙY CHỌN. Hoạt động với cấu hình máy chủ.
URI. Xác định tài nguyên và chứa URL.

Cấu trúc phản hồi HTTP

Máy chủ đáp ứng yêu cầu của khách hàng bằng những tin nhắn dài. Phản hồi bao gồm một số dòng cho biết phiên bản giao thức và mã trạng thái máy chủ (200). Nó cho bạn biết điều gì đã thay đổi trên máy chủ trong khi xử lý yêu cầu đến:

Trạng thái "hai trăm" biểu thị xử lý thành công thông tin. Sau đó, máy chủ sẽ gửi tài liệu đến máy khách. Các dòng còn lại của yêu cầu cho biết thông tin khác về thông tin được truyền đi.
Nếu không tìm thấy hoặc không tồn tại tệp, máy chủ sẽ gửi mã 404 đến máy khách, còn gọi là lỗi.
Mã 206 cho biết quá trình tải xuống một phần tệp có thể được tiếp tục sau một thời gian.
Mã 401 biểu thị việc từ chối ủy quyền. Điều này có nghĩa là trang được yêu cầu được bảo vệ bằng mật khẩu, mật khẩu này phải được nhập để xác nhận việc nhập.
Mã 403 biểu thị quyền truy cập bị cấm. Cấm xem, tải xuống tệp hoặc video là phản hồi phổ biến trên Internet.
Ngoài ra còn có các phiên bản mã khác: di chuyển tạm thời tệp được yêu cầu, lỗi máy chủ nội bộ, di chuyển vĩnh viễn. Trong trường hợp này, người dùng sẽ được chuyển hướng. Nếu mã 500 xuất hiện, điều này có nghĩa là có vấn đề với máy chủ.

URL - nó là gì?

URL là trung tâm của giao tiếp web giữa máy khách và máy chủ. Yêu cầu thường được gửi qua URL - Bộ định vị tài nguyên thống nhất. Cấu trúc yêu cầu url rất đơn giản. Nó bao gồm một số thành phần: giao thức http (tiêu đề), hoot (địa chỉ trang web), cổng, đường dẫn tài nguyên và truy vấn.

Giao thức này cũng có sẵn cho kết nối an toàn https và trao đổi thông tin. Một URL chứa thông tin về vị trí của một trang web cụ thể trên Internet. Địa chỉ bao gồm tên miền, đường dẫn đến trang và tiêu đề của nó.

Nhược điểm chính khi làm việc với URL là sự tương tác bất tiện với bảng chữ cái Latinh, cũng như các con số và ký hiệu. TRONG Tối ưu hóa SEOđóng một vai trò quan trọng.

Người dùng và nhà phát triển máy tính đang hoạt động được khuyến khích làm quen với một số khuyến nghị chuyên môn do các chuyên gia trong lĩnh vực này đưa ra:

Cho biết ngày hết hạn của các tệp và tài liệu, có tính đến các bản cập nhật. Thông tin thống kê chỉ ra trong giá trị lớn tuổi tối đa
Một tài liệu duy nhất chỉ có thể được truy cập thông qua một URL.
Nếu bạn đang cập nhật một tệp mà người dùng sẽ tải xuống, hãy đổi tên và liên kết tới tệp đó. Điều này đảm bảo rằng tài liệu mới được tải xuống chứ không phải tài liệu lỗi thời.
Các tiêu đề được sửa đổi lần cuối phải tương ứng với ngày thực tế mà nội dung được sửa đổi lần cuối. Bạn không nên lưu lại các trang và tài liệu trừ khi bạn thay đổi chúng.
Chỉ sử dụng các yêu cầu POST khi cần thiết. Giữ SSL hoạt động ở mức tối thiểu.
Các tiêu đề phải được kiểm tra bằng plugin REDbot trước khi được máy chủ gửi.

HTTP (Giao thức truyền siêu văn bản) được phát triển làm nền tảng của World Wide Web.

Giao thức HTTP hoạt động như sau: chương trình máy khách thiết lập kết nối TCP với máy chủ ( Phòng tiêu chuẩn port-80) và đưa ra yêu cầu HTTP tới nó. Máy chủ xử lý yêu cầu này và đưa ra phản hồi HTTP cho máy khách.

Cấu trúc yêu cầu HTTP

Yêu cầu HTTP bao gồm tiêu đề yêu cầu và nội dung yêu cầu, được phân tách bằng một dòng trống. Nội dung yêu cầu có thể bị thiếu.

Tiêu đề yêu cầu bao gồm dòng chính (đầu tiên) của yêu cầu và các dòng tiếp theo làm rõ yêu cầu trong dòng chính. Các dòng tiếp theo cũng có thể bị thiếu.

Truy vấn dòng chính bao gồm ba phần, cách nhau bằng dấu cách:

Phương pháp(nói cách khác là lệnh HTTP):

LẤY- yêu cầu tài liệu. Phương pháp được sử dụng phổ biến nhất; trong HTTP/0.9, họ nói, anh ấy là người duy nhất.

CÁI ĐẦU- yêu cầu tiêu đề tài liệu. Nó khác với GET ở chỗ chỉ trả về tiêu đề yêu cầu có thông tin về tài liệu. Bản thân tài liệu không được ban hành.

BƯU KIỆN- phương pháp này được sử dụng để truyền dữ liệu sang tập lệnh CGI. Bản thân dữ liệu xuất hiện trong các dòng tiếp theo của yêu cầu dưới dạng tham số.

ĐẶT- đặt tài liệu trên máy chủ. Theo tôi biết thì nó hiếm khi được sử dụng. Một yêu cầu với phương pháp này có phần thân trong đó tài liệu được truyền đi.

Nguồn- đây là đường dẫn đến một tệp cụ thể trên máy chủ mà máy khách muốn nhận (hoặc đặt - cho phương thức PUT). Nếu tài nguyên chỉ đơn giản là một số tệp cần đọc thì máy chủ phải trả lại nó trong phần nội dung phản hồi cho yêu cầu này. Nếu đây là đường dẫn đến tập lệnh CGI thì máy chủ sẽ chạy tập lệnh và trả về kết quả thực thi tập lệnh đó. Nhân tiện, nhờ sự thống nhất các tài nguyên này, khách hàng thực tế không quan tâm đến những gì anh ta đại diện trên máy chủ.

Phiên bản giao thức-version của giao thức HTTP mà chương trình máy khách hoạt động.

Vì vậy, một yêu cầu HTTP đơn giản có thể trông như thế này:

Điều này yêu cầu tệp gốc từ thư mục gốc của máy chủ web.

Các dòng sau dòng truy vấn chính có định dạng sau:

Giá trị tham số.

Đây là cách các tham số yêu cầu được thiết lập. Đây là tùy chọn; tất cả các dòng sau dòng truy vấn chính có thể bị thiếu; trong trường hợp này, máy chủ chấp nhận giá trị của chúng theo mặc định hoặc dựa trên kết quả của yêu cầu trước đó (khi làm việc ở chế độ Keep-Alive).

Tôi sẽ liệt kê một số tham số yêu cầu HTTP được sử dụng phổ biến nhất:

Sự liên quan(kết nối) - có thể lấy các giá trị Keep-Alive và đóng. Keep-Alive có nghĩa là sau khi phát hành tài liệu này, kết nối đến máy chủ không bị ngắt và có thể đưa ra nhiều yêu cầu hơn. Hầu hết các trình duyệt hoạt động ở chế độ Keep-Alive, vì nó cho phép bạn "tải xuống" trang html và hình ảnh cho trang đó trong một kết nối với máy chủ. Sau khi được đặt, chế độ Keep-Alive sẽ được duy trì cho đến khi xảy ra lỗi đầu tiên hoặc cho đến khi yêu cầu Kết nối: đóng tiếp theo được chỉ định rõ ràng.
close ("đóng") - kết nối bị đóng sau khi đáp ứng yêu cầu này.

Đại lý người dùng- giá trị là "mã" của trình duyệt, ví dụ:

Mozilla/4.0 (tương thích; MSIE 5.0; Windows 95; DigExt)

Chấp nhận- danh sách các loại nội dung được trình duyệt hỗ trợ theo thứ tự ưu tiên của chúng đối với một trình duyệt nhất định, ví dụ như đối với IE5 của tôi:

Chấp nhận: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Điều này rõ ràng là cần thiết trong trường hợp máy chủ có thể xuất cùng một tài liệu ở các định dạng khác nhau.

Giá trị của tham số này chủ yếu được sử dụng bởi các tập lệnh CGI để tạo phản hồi phù hợp với trình duyệt nhất định.

Người giới thiệu- URL mà bạn đã truy cập vào tài nguyên này.

Chủ nhà- tên của máy chủ mà tài nguyên được yêu cầu. Hữu ích nếu máy chủ có nhiều máy chủ ảo có cùng địa chỉ IP. Trong trường hợp này tên máy chủ ảođược xác định bởi trường này.

Ngôn ngữ chấp nhận- ngôn ngữ được hỗ trợ. Điều quan trọng đối với một máy chủ có thể phục vụ cùng một tài liệu ở các phiên bản ngôn ngữ khác nhau.

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

Định dạng phản hồi rất giống với định dạng yêu cầu: nó cũng có phần đầu và phần thân được phân tách bằng một dòng trống.

Tiêu đề cũng bao gồm một dòng chính và các dòng tham số, nhưng định dạng của dòng chính khác với định dạng của tiêu đề yêu cầu.

Chuỗi truy vấn chính bao gồm 3 trường cách nhau bằng dấu cách:

Phiên bản giao thức- tương tự với tham số yêu cầu tương ứng.

Mã lỗi- mã chỉ định “thành công” của yêu cầu. Mã 200 có nghĩa là "mọi thứ đều bình thường" (OK).

Mô tả bằng lời về lỗi- “giải mã” mã trước đó. Ví dụ: với 200 thì không sao, với 500 thì đó là Lỗi Máy chủ Nội bộ.

Các tham số phản hồi http phổ biến nhất:

Sự liên quan- tương tự với tham số yêu cầu tương ứng.
Nếu máy chủ không hỗ trợ Keep-Alive (có một số), thì giá trị Kết nối trong phản hồi luôn đóng.

Vì vậy, theo tôi, chiến thuật trình duyệt đúng đắn là như sau:
1. phát hành Connection: Keep-Alive trong yêu cầu;
2. Trạng thái kết nối có thể được đánh giá bằng trường Kết nối trong phản hồi.

Loại nội dung(“loại nội dung”) - chứa chỉ định loại nội dung của phản hồi.

Tùy thuộc vào giá trị Content-Type, trình duyệt diễn giải phản hồi dưới dạng trang HTML, hình ảnh gif hoặc jpeg, dưới dạng tệp sẽ được lưu vào đĩa hoặc bất kỳ thứ gì và thực hiện hành động thích hợp. Giá trị Content-Type cho trình duyệt giống với giá trị phần mở rộng tệp cho Windows.

Một số loại nội dung:

text/html - văn bản ở định dạng HTML (trang web);
text/plain - văn bản thuần túy (tương tự Notepad);
image/jpeg - ảnh ở định dạng JPEG;
hình ảnh/gif - giống nhau, ở định dạng GIF;
ứng dụng/octet-stream - một luồng "octet" (tức là chỉ byte) để ghi vào đĩa.

Thực tế có nhiều loại nội dung hơn.

Thời lượng nội dung("độ dài nội dung") - độ dài của nội dung phản hồi tính bằng byte.

Sửa đổi lần cuối("Đã sửa đổi lần trước") - ngày thay đổi cuối cùng tài liệu.