Wikipedia

Hypertext Transfer Protocol

giao thức chuẩn của mạng Internet

HTTP (tiếng Anh: HyperText Transfer Protocol - Giao thức truyền tải siêu văn bản) là một giao thức lớp ứng dụng nằm trong bộ giao thức dành cho hệ thống thông tin siêu phương tiện phân tán, cộng tác.[1] Nó chính là nền tảng dùng để trao đổi và liên lạc dữ liệu với World Wide Web, nơi mà các tập tin tài liệu siêu văn bản có thể chứa các siêu liên kết dẫn đến các tài nguyên số khác mà người dùng có thể dễ dàng truy cập được bằng cách dùng chuột nhấp vào hoặc dùng ngón tay chạm vào màn hình cảm hứng lúc duyệt web. Nhờ đó, HTTP cho phép người sử dụng truy cập và tải về các tài nguyên như văn bản HTML, text, video, ảnh... của các trang web và hiển thị chúng trên trình duyệt.

Hypertext Transfer Protocol
International standard
Nhà phát triểnBan đầu là CERN; IETF, W3C
Giới thiệu lần đầu1991; 32 năm trước (1991)
Hypertext Transfer Protocol

Tim Berners-Lee là người khởi xướng cho sự hình thành và phát triển của HTTP vào năm 1989 tại CERN. Nội dung ý tưởng của HTTP được tóm gọn lại trong một tài liệu cơ bản, bên trong mô tả hoạt động tương tác giữa máy khách và máy chủ ở phiên bản HTTP thử nghiệm đầu tiên, có số 0.9.[2] Phiên bản đó một thời gian sau được phát triển, trở thành phiên bản chính thức 1.0.[3]

Quá trình phát triển các RFC HTTP ban đầu là nhờ vào sự hợp tác từ phía Lực lượng Đặc nhiệm Kỹ thuật Internet (IETF) và World Wide Web Consortium (W3C), về sau thì chuyển sang do IETF phụ trách.

HTTP/1 được hoàn thiện và xuất bản tài liệu sử dụng (phiên bản 1.0) vào năm 1996. HTTP tiếp tục được phát triển vào năm 1997 (khi này là phiên bản 1.1), và đặc tính kỹ thuật của nó được cải tiến lần lượt vào các năm 1999, 2014 và 2022.

Sau này, phiên bản bảo mật hơn của HTTP là HTTPS được sử dụng rộng rãi trên hơn 80% trang web.[4] HTTP/2 là một giao thức hiệu quả hơn về ngữ nghĩa của HTTP "trên dây" và được đưa vào sử dụng vào năm 2015. Tính đến năm tháng 4 năm 2023, nó được sử dụng trên 39% trang web[5] và được gần như toàn bộ trình duyệt web hỗ trợ (chiếm 97% người sử dụng).[6] Ngoài ra, nó cũng được hỗ trợ bởi các máy chủ web lớn qua Bảo mật tầng truyền tải (TLS) bằng cách sử dụng tiện ích mở rộng Application-Layer Protocol Negotiation (ALPN) [7] nhưng bắt buộc phải sử dụng TLS 1.2 hoặc mới hơn.[8][9]

HTTP/3 là phiên bản kế nhiệm của HTTP/2 được triển khai vào năm 2022,[10][11]. Nó đã được sử dụng trên 26% trang web và được nhiều trình duyệt hỗ trợ. Phiên bản này sử dụng QUIC thay vì TCP cho giao thức truyền tải cơ bản. Giống như HTTP/2, nó không gây lỗi thời các phiên bản chính trước đó của giao thức. Hỗ trợ dành cho cho HTTP/3 đã được bổ sung vào Cloudflare và Google Chrome vào tháng 9 năm 2019,[12][13] và có thể được kích hoạt trong các phiên bản ổn định của Chrome và Firefox.[14] HTTP/3 có độ trễ thấp hơn khi duyệt các trang web, tải trang nhanh hơn HTTP/2, và thậm chí còn nhanh hơn nhiều so với HTTP/1.1, trong một số trường hợp thì HTTP/3 cho tốc độ nhanh gấp ba lần so với HTTP/1.1.[15]

Tổng quan về mặt kỹ thuật sửa

 
Một URL sẽ bắt đầu bằng HTTP, rồi kế đó là hai chấm và hai dấu gạch xiên liên tiếp, rồi đến mác tên miền WWW

HTTP hoạt động dựa trên giao thức yêu cầu-phản hồi nằm trong mô hình khách - chủ. Khách có thể là một trình duyệt được một người truy cập thực hiện yêu cầu, còn chủ có thể là một máy chủ web trên đám mây hoặc lưu trữ cục bộ chạy trên một chiếc máy tính quản lý một hay nhiều trang web. Khách sẽ gửi một yêu cầu HTTP lên cho máy chủ. Còn máy chủ (nơi cung cấp các tài nguyên chẳng hạn như tập tin HTML và những nội dung, hoặc thực hiện những chức năng khác thay mặt cho khách) sẽ phản hồi lại thông điệp cho khách. Thông điệp được phản hồi sẽ chứa thông tin hoàn thành yêu cầu như thế nào, và đôi khi cũng sẽ chứa thông tin được yêu cầu trong phần nội dung của nó.

Trình duyệt web là ví dụ điển hình của user agent (UA). Các loại user agent khác có thể kể đến gồm có các công cụ tự động lập chỉ mục được sử dụng bởi các bộ máy tìm kiếm (web crawler), duyệt tìm bằng giọng nói, ứng dụng di động hoặc những phần mềm khác có thể truy cập, tải xuống và hiển thị nội dung web.

HTTP được thiết kế nhằm cải thiện các thành phần mạng trung gian cùng với cho phép liên lạc giữa máy khách và máy chủ. Các trang web có lưu lượng truy cập cao thường tận dụng những ưu điểm từ các máy chủ bộ đệm web (web caching) nhằm cung cấp nội dung thay mặt cho các máy chủ ngược dòng để cải thiện thời gian phản hồi. Trình duyệt web thường sẽ lưu giữ các tài nguyên web đã từng được truy cập trước đó vào bộ nhớ và tái sử dụng chúng bất cứ khi nào có thể để giảm lưu lượng mạng. Máy chủ proxy HTTP ở không gian mạng riêng tư có thể tạo điều kiện liên lạc cho khách mà không cần địa chỉ có thể định tuyến toàn cầu bằng cách chuyển tiếp thông điệp với máy chủ bên ngoài.

Để cho phép các nút HTTP trung gian chẳng hạn như proxy, web cache,... có thể thực hiện được chức năng thì một số tiêu đề HTTP (có trong phần yêu cầu/phản hồi HTTP) sẽ được quản lý theo từng bước (hop-by-hop), trong khi những tiêu đề khác thì được quản lý đầu cuối (tức là chỉ duy nhất một khách đầu nguồn và một máy chủ được chỉ định).

HTTP là một giao thức lớp ứng dụng được thiết kế hoạt động trong khuôn khổ bộ giao thức Internet. Ngoài ra, nó cũng còn được giả định cho là giao thức lớp vận chuyển cơ bản và đáng tin cậy. Trong phiên bản HTTP/3 mới nhất, Transmission Control Protocol (TCP) không còn được sử dụng nữa nhưng các phiên cũ thì vẫn còn sử dụng rất nhiều. HTTP cũng được thiết kế và điều chỉnh để sử dụng các giao thức không đáng tin cậy như User Datagram Protocol (UDP), và công nghệ mà HTTP/3 gián tiếp xây dựng dựa trên nó, ví dụ như HTTPU và Simple Service Discovery Protocol (SSDP).

Tài nguyên HTTP cùng vị trí của nó được xác định dựa trên đường dẫn URL (Uniform Resource Locator), sử dụng bộ URI http và https. Theo như định nghĩa RFC 3986, các URI sẽ được mã hoá ở dạng siêu liên kết trong các tập tin tư liệu HTML để hình thành tập tin tư liệu siêu văn bản liên kết với nhau.

Ở phiên bản HTTP/1.0, một kết nối TCP đến cùng máy chủ sẽ được thực hiện cho mỗi yêu cầu tài nguyên.[16]

Ở phiên bản HTTP/1.1, một kết nối TCP có thể được sử dụng nhiều lần để tạo ra nhiều yêu cầu tài nguyên khác (trang HTML, khung, hình ảnh, mã nguồn,...).[17] Nhờ vậy, liên lạc qua HTTP/1.1 sẽ ít gặp độ trễ hơn, vốn dĩ việc thiết lập các kết nối TCP gây ra chi phí đáng kể, đặc biệt trong điều kiện lưu lượng truy cập cao.[18]

HTTP/2 là phần cải tiến của HTTP/1.1 trước đó nhằm giữ lại mô hình khách-chủ và phương pháp giao thức giống nhau nhưng khác nhau ở chỗ:

  • để sử dụng siêu dữ liệu nhị phân nén (tiêu đề HTTP) thay vì dạng văn bản, để tiêu đề yêu cầu ít không gian hơn;
  • để sử dụng một kết nối TCP/IP duy nhất (thường đã được mã hoá) cho mỗi tên miền máy chủ được truy cập thay vì từ 2 cho tới 8 kết nối TCP/IP;
  • để sử dụng một hoặc nhiều luồng stream hai chiều cho mỗi kết nối TCP/IP trong đó các yêu cầu/phản hồi HTTP được chia nhỏ và truyền thành từng gói (packet) nhỏ để gần như giải quyết được vấn đề HOLB (head-of-line blocking).[note 1]
  • để thêm khả năng "đẩy", cho phép ứng dụng máy chủ gửi dữ liệu đến máy khách bất cứ khi nào có dữ liệu mới (không bắt buộc máy khách phải yêu cầu dữ liệu mới định kỳ đến máy chủ bằng cách sử dụng phương pháp polling).[19]

Nhờ đó, liên lạc qua HTTP/2 sẽ giảm độ trễ đi nhiều, và nhiều lúc còn chạy nhanh hơn cả liên lạc qua HTTP/1.1.

HTTP/3 là bản tinh chỉnh của HTTP/2 nhằm sử dụng giao thức truyền tải QUIC + UDP thay cho TCP. Trước đó, phiên bản kết nối TCP/IP được sử dụng, thì giờ đây chỉ có lớp IP (được xây dựng trên UDP, như TCP) cũng cải thiện một chút tốc độ liên lạc trung bình và để tránh sự cố tắc nghẽn kết nối TCP không thường xuyên (rất hiếm) có thể tạm thời chặn đứng hoặc làm chậm luồng dữ liệu của tất cả các stream của nó (dạng khác của "head of line blocking").

Lịch sử sửa

 
Tim Berners-Lee

Khái niệm siêu văn bản được Ted Nelson đặt ra vào năm 1965 trong dự án Xanadu lấy cảm hứng từ tầm nhìn những năm 1930 về hệ thống quản lý và truy xuất thông tin dựa trên vi phim "memex" nằm trong luận án "As We May Think" của ông vào năm 1945. Tim Berners-Lee và nhóm nghiêm cứu của ông tại CERN được ghi công phát minh HTTP nguyên thuỷ, cùng với HTML và công nghệ đi liền cho máy chủ web và giao diện người dùng máy khách được gọi là trình duyệt web. Berners-Lee thiết kế HTTP nhằm mục đích bổ trợ cho ý tưởng sáng tạo khác của ông: dự án "WorldWideWeb" lần đầu tiên công bố vào 1989 và nổi tiếng ngày nay với World Wide Web.

Máy chủ web đầu tiên được đưa vào hoạt động vào năm 1990.[20][21] Giao thức được sử dụng chỉ có một phương thức duy nhất, mang tên GET, có nghĩa là yêu cầu trích xuất dữ liệu một trang từ một máy chủ.[22] Phản hồi từ phía máy chủ luôn luôn là một trang định dạng HTML.[2]

Tóm lược các cột mốc phiên bản HTTP sửa

Phiên bản Năm ra mắt Trạng thái hiện tại
HTTP/0.9 1991 Đã lỗi thời
HTTP/1.0 1996 Đã lỗi thời
HTTP/1.1 1997 Còn thông dụng
HTTP/2 2015 Còn thông dụng
HTTP/3 2022 Còn thông dụng
HTTP/0.9
Vào năm 1991, phiên bản chính thức đầu tiên của HTTP được viết dưới dạng tài liệu đơn giản, dài dưới 700 từ và phiên bản này được đặt tên là HTTP/0.9, chỉ hỗ trợ phương thức GET, cho phép khách hàng chỉ truy xuất tài liệu HTML từ máy chủ, nhưng không hỗ trợ bất kỳ định dạng tệp hoặc tải lên thông tin nào khác.[2]
HTTP/1.0-nháp
Từ năm 1992, một tài liệu mới đã được viết để chỉ rõ sự phát triển của giao thức cơ bản hướng tới phiên bản đầy đủ tiếp theo. Nó hỗ trợ cả phương thức yêu cầu đơn giản của phiên bản 0.9 và yêu cầu GET đầy đủ bao gồm phiên bản HTTP máy khách. Đây là bản nháp đầu tiên trong số nhiều bản nháp HTTP/1.0 không chính thức, trước khi hoàn chỉnh sang phiên bản cuối HTTP/1.0.[3]
Nhóm làm việc HTTP W3C
Sau khi nhất trí các tính năng mới của giao thức HTTP là yêu cầu bắt buộc và cần phải được ghi lại đầy đủ dưới dạng RFC chính thức, vào đầu năm 1995, nhóm làm việc HTTP (HTTP WG, do Dave Raggett lãnh đạo) được thành lập với mục đích chuẩn hoá và mở rộng giao thức với các tác vụ mở rộng, trao đổi mở rộng, thông tin meta phong phú hơn, kèm theo giao thức bảo mật hiệu quả hơn nhờ vào việc bổ sung thêm các phương thức và trường Header.[23][24]
HTTP WG đã lên kế hoạch sửa đổi và xuất bản các phiên bản mới của giao thức dưới dạng HTTP/1.0 và HTTP/1.1 trong năm 1995, nhưng do có quá nhiều thứ cần tinh chỉnh nên mốc thời gian đó đã phải kéo dài tới hơn một năm.[25]
HTTP WG cũng đã lên kế hoạch chỉ định một phiên bản HTTP trong tương lai xa có tên là HTTP-NG (HTTP Next Generation) sẽ giải quyết tất cả các vấn đề còn lại của các phiên bản trước, liên quan đến hiệu suất, phản hồi độ trễ thấp, v.v. nhưng công việc này chỉ bắt đầu một vài năm sau và không bao giờ được hoàn thành.
HTTP/1.0
Vào tháng 5 năm 1996, RFC 1945 đã được xuất bản dưới dạng bản sửa đổi HTTP/1.0 cuối cùng của tất cả những đặc tính đã được sử dụng trong 4 năm trước dưới dạng bản nháp HTTP/1.0 tiền tiêu chuẩn đã được nhiều trình duyệt web và máy chủ web sử dụng.
Vào đầu năm 1996, các nhà phát triển thậm chí còn bắt đầu đưa các phần mở rộng không chính thức của giao thức HTTP/1.0 (tức là các kết nối duy trì, v.v.) vào sản phẩm của họ bằng cách sử dụng các bản nháp của đặc tính kỹ thuật HTTP/1.1 sắp tới.
HTTP/1.1
Kể từ đầu năm 1996, các trình duyệt web và nhà phát triển máy chủ web lớn cũng bắt đầu triển khai các tính năng mới được chỉ định bởi các đặc tính kỹ thuật dự thảo HTTP/1.1 tiền tiêu chuẩn. Người dùng cuối đã nhanh chóng tiếp nhận các phiên bản mới của trình duyệt và máy chủ. Vào tháng 3 năm 1996, một công ty lưu trữ web đã báo cáo có hơn 40% trình duyệt sử dụng trên Internet đã sử dụng tiêu đề "Máy chủ" HTTP/1.1 mới để kích hoạt lưu trữ ảo. Cũng chính công ty lưu trữ web đó đã báo cáo rằng vào tháng 6 năm 1996, 65% các trình duyệt truy cập vào máy chủ của họ đều tuân thủ chuẩn HTTP/1.1.[26]
Vào tháng 1 năm 1997, RFC 2068 được chính thức phát hành dưới dạng đặc tính kỹ thuật HTTP/1.1.
Vào tháng 6 năm 1999, RFC 2616 được phát hành để cải tiến và cập nhật dựa trên đặc tính kỹ thuật HTTP/1.1 (lỗi thời) trước đó.
Nhóm làm việc HTTP-NG W3C
Tiếp tục kế hoạch cũ năm 1995 của Nhóm làm việc HTTP trước đó, năm 1997, nhóm làm việc HTTP-NG được thành lập để phát triển giao thức HTTP mới có tên HTTP-NG (HTTP New Generation). Một số đề xuất/bản nháp đã được đưa ra cho giao thức mới để sử dụng tính năng ghép kênh trao đổi HTTP trong một kết nối TCP/IP duy nhất, nhưng vào năm 1999, nhóm đã ngừng hoạt động và chuyển các vấn đề kỹ thuật sang IETF.[27]
Nhóm làm việc IETF HTTP đã tái hoạt động.
Vào năm 2007, nhóm làm việc HTTP IETF (HTTP WG bis hoặc HTTPbis) đầu tiên được khởi động lại để sửa đổi và làm rõ các đặc tính kỹ thuật HTTP/1.1 trước đó và kế đến là để viết và tinh chỉnh các đặc tính kỹ thuật HTTP/2 trong tương lai (được đặt tên là httpbis).[28][29]
SPDY: một giao thức HTTP không chính thức được phát triển bởi Google
Vào năm 2009, một công ty tư nhân mang tên Google thông báo rằng họ đã phát triển và thử nghiệm một giao thức nhị phân HTTP mới có tên SPDY. Mục đích ngầm là tăng tốc đáng kể lưu lượng truy cập web (đặc biệt là giữa các trình duyệt web trong tương lai và máy chủ của nó).
SPDY thực sự nhanh hơn nhiều so với HTTP/1.1 trong nhiều thử nghiệm và do đó nó nhanh chóng được Chromium áp dụng và nhiều trình duyệt lớn khác sau đó tương tự.[30]
Một số ý tưởng về việc ghép kênh các luồng HTTP qua một kết nối TCP/IP được lấy từ nhiều nguồn khác nhau, gồm cả dự án của nhóm làm việc W3C HTTP-NG.
HTTP/2
Từ tháng 1 đến tháng 3 năm 2012, nhóm công tác HTTP (HTTPbis) đã công bố sẽ bắt đầu tập trung vào việc phát triển giao thức HTTP/2 mới (đồng thời hoàn tất việc sửa đổi các đặc tính kỹ thuật HTTP/1.1), và họ có thể xem xét mượn các ý tưởng và công việc đã hoàn thành trước đó với SPDY.[31][32]
Sau một vài tháng cân nhắc những việc cần làm để phát triển một phiên bản HTTP mới, họ đã quyết định phát triển HTTP/2 từ SPDY.[33]
Vào tháng 5 năm 2015, HTTP/2 được công bố ở số RFC 7540 và nhanh chóng được đưa vào áp dụng với tất cả các trình duyệt web đã hỗ trợ SPDY và chậm hơn nữa là với các máy chủ web.
Các bản cập nhật 2014 dành cho HTTP/1.1
Vào tháng 6 năm 2014, nhóm làm việc HTTP đã phát hành đặc tính kỹ thuật HTTP/1.1 gồm sáu phần được cập nhật RFC 2616 đã lỗi thời:
  • RFC 7230, HTTP/1.1: Cú pháp và định tuyến thông điệp
  • RFC 7231, HTTP/1.1: Ngữ nghĩa và Nội dung
  • RFC 7232, HTTP/1.1: Yêu cầu có điều kiện
  • RFC 7233, HTTP/1.1: Yêu cầu phạm vi
  • RFC 7234, HTTP/1.1: Bộ nhớ đệm
  • RFC 7235, HTTP/1.1: Xác thực
Ngừng sử dụng và hỗ trợ HTTP/0.9
Ở mục phụ lục A số RFC 7230, HTTP/0.9 đã hoàn toàn bị khai tử đối với các máy chủ hỗ trợ phiên bản HTTP/1.1 (và cao hơn):[34]

Vì HTTP/0.9 không hỗ trợ các trường Header trong một yêu cầu nên không có cơ chế nào để hỗ trợ các máy chủ ảo dựa trên tên (lựa chọn tài nguyên bằng cách kiểm tra trường Header Máy chủ). Bất kỳ máy chủ nào triển khai máy chủ ảo dựa trên tên phải tắt hỗ trợ cho HTTP/0.9. Trên thực tế, hầu hết các yêu cầu có vẻ là HTTP/0.9 đều là các yêu cầu HTTP/1.x được xây dựng kém do máy khách không mã hoá chính xác mục tiêu yêu cầu.

Kể từ năm 2016, nhiều nhà quản lý sản phẩm, nhà phát triển user agent (trình duyệt, v.v.) và máy chủ web đã bắt đầu lên kế hoạch ngừng sử dụng và loại bỏ dần hỗ trợ cho giao thức HTTP/0.9, chủ yếu vì những lý do sau:[35]
  • nó đơn giản đến mức khỏi cần viết ra tài liệu RFC cũng được (chỉ cần tài liệu gốc là đủ);[2]
  • nó không có tiêu đề HTTP và thiếu nhiều tính năng khác mà ngày nay được yêu cầu vì lý do bảo mật tối thiểu;
  • nó đã không được phổ biến rộng rãi kể từ năm 1999 hay 2000 trở về sau (vì HTTP/1.0 và HTTP/1.1) và thường chỉ được sử dụng bởi một số phần cứng mạng rất cũ như mấy cái router cổ lỗ sĩ v.v.
[note 2]
HTTP/3
Vào năm 2020, bản thảo đầu tiên HTTP/3 đã được xuất bản và các trình duyệt web cũng như máy chủ web lớn bắt đầu đưa vào áp dụng.
Vào ngày 6 tháng 6 năm 2022, IETF đã chuẩn hoá HTTP/3 thành RFC 9114.
Cập nhật và tái cấu trúc vào năm 2022
Vào tháng 6 năm 2022, một loạt RFC đã được xuất bản, loại bỏ nhiều tài liệu trước đó và đưa ra một số thay đổi nhỏ cũng như tái cấu trúc mô tả ngữ nghĩa HTTP thành một tài liệu riêng.

HTTP Session sửa

Session (phiên làm việc) là một khái niệm phổ biến được dùng trong lập trình web có kết nối với database. Đặc biệt các chức năng như đăng nhập, đăng xuất người dùng sẽ khó có thể thực hiện được nếu không sử dụng session. Ví dụ email, giao dịch ngân hàng,...

HTTPS:\\ Authentication sửa

HTTP Request methods sửa

HTTP Request Method chỉ phương thức để được thực hiện trên nguồn được nhận diện bởi Request-URI đã cung cấp

GET

GET được sử dụng để lấy lại thông tin từ máy chủ đã cung cấp bởi sử dụng một URI đã cung cấp. Các yêu cầu sử dụng GET chỉ nhận dữ liệu và không có ảnh hưởng gì tới dữ liệu.

HEAD

Tương tự như GET, nhưng nó truyền tải dòng trạng thái và khu vực header.

POST

Một yêu cầu POST sử dụng các mẫu HTML để gửi dữ liệu tới máy chủ, như thông tin khách hàng, file tải lên,...

PUT

Thay đổi tất cả các đại diện hiện tại của nguồn mục tiêu với nội dung được tải lên.

DELETE

Gỡ bỏ tất cả các đại diện hiện tại của nguồn mục tiêu bởi URI.

CONNECT

Thiết lập một tunnel tới máy chủ được xác định bởi URI đã cung cấp.

OPTIONS

Miêu tả các chức năng giao tiếp cho nguồn mục tiêu.

TRACE

Trình bày một vòng lặp kiểm tra thông báo song song với path tới nguồn mục tiêu.

HTTP Response sửa

Khi nhận và phiên dịch một HTTP Request, máy chủ sẽ gửi tín hiệu phản hồi là một HTTP Response bao gồm các thành phần sau:

  • Một dòng trạng thái (Status-Line)
  • Không hoặc nhiều hơn các trường Header (General | Response | Entity) được theo sau CRLF
  • Một dòng trống chỉ dòng kết thúc của các trường header
  • Một phần thân thông báo tùy ý

Server response sửa

Một ví dụ về một HTTP Response: 

HTTP/1.1 200 OK
Date: Mon, ngày 23 tháng 5 năm 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Encoding: UTF-8
Content-Length: 138
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
<head>
  <title>An Example Page</title>
</head>
<body>
  Hello World, this is a very simple HTML document.
</body>
</html>

Dòng Status-Line: Một dòng Status Line bao gồm phiên bản giao thức (HTTP-Version) sau đó là mã hóa trạng thái số (Status-Code) và cụm từ thuần văn bản được liên kết của nó. Các thành phần được phân biệt bởi dấu cách.

HTTP Status Code sửa

Mã trạng thái HTTP được máy chủ phản hồi lại mỗi khi nhận được HTTP Resquest.

Yếu tố Status-Code là một số nguyên 3 ký tự, trong đó ký tự đầu tiên của mã hóa trạng thái định nghĩa hạng (loại) phản hồi và hai ký tự cuối không có bất cứ vai trò phân loại nào. Có 5 giá trị của ký tự đầu tiên như sau:

1xx: Thông tin sửa

Nó nghĩa là yêu cầu đã được nhận và tiến trình đang tiếp tục.

   100 (Continue) sửa

Máy chủ trả về mã này để chỉ ra rằng nó đã nhận được một phần đầu tiên của một yêu cầu và được chờ đợi cho phần còn lại.

101 (Switching protocols) sửa

Bên yêu cầu đã yêu cầu các máy chủ để chuyển đổi và máy chủ được thừa nhận rằng nó sẽ làm như vậy

2xx: Thành công sửa

Nó nghĩa là hoạt động đã được nhận, được hiểu, và được chấp nhận một cách thành công.

200 (Successful) sửa

Các máy chủ xử lý yêu cầu thành công

201 (Created) sửa

Yêu cầu đã thành công và các máy chủ tạo ra một nguồn tài nguyên mới.

202 (Accepted) sửa

Máy chủ đã chấp nhận yêu cầu, nhưng vẫn chưa xử lý nó

203 (Non-authoritative information) sửa

Máy chủ xử lý yêu cầu thành công, nhưng đang quay trở lại các thông tin mà có thể là từ một nguồn khác.

204 (No content) sửa

Các máy chủ xử lý yêu cầu thành công, nhưng không trả lại bất kỳ nội dung nào

205 (Reset content) sửa

Các máy chủ proccessed yêu cầu thành công, nhưng không trả lại bất kỳ nội dung. Không giống như một phản ứng 204, phản ứng này đòi hỏi người yêu cầu thiết lập lại xem tài liệu

206 (Partial content) sửa

Các máy chủ xử lý thành công một phần của một yêu cầu

3xx: Sự điều hướng lại sửa

Nó nghĩa là hoạt động phải được thực hiện để hoàn thành yêu cầu.

301 (Moved permanently) sửa

Các trang web yêu cầu đã bị di chuyển vĩnh viễn tới URL mới

302 (Moved temporarily) sửa

Trang được yêu cầu đã di chuyển tạm thời tới một URL mới

304 (Not modified) sửa

Các trang yêu cầu đã không được sửa đổi kể từ khi yêu cầu cuối cùng. Khi máy chủ trả về phản hồi này, nó không trả lại các nội dung của trang.

4xx: Lỗi Client sửa

Nó nghĩa là yêu cầu chứa cú pháp không chính xác hoặc không được thực hiện

400 (Bad request) sửa

Các máy chủ không hiểu được yêu cầu.

401 (Not authorized) sửa

Đề nghị yêu cầu xác thực. Máy chủ có thể trả về phản hồi này yêu cầu xác thực đăng nhập tài khoản và mật khẩu (thông thường máy chủ trả về phản hồi này nếu client gửi request một trang đăng nhập)

403 (Forbidden) sửa

Máy chủ từ chối yêu cầu.(thông thường nếu đăng nhập không thành công máy chủ sẽ trả về mã lỗi này)

404 (Not found) sửa

Máy chủ không thể tìm thấy trang yêu cầu. Ví dụ, máy chủ thường trả về mã này nếu có 1 yêu cầu tới một trang không tồn tại trên máy chủ.

405 (Method not allowed) sửa

Phương thức được xác định trong yêu cầu là không được cho phép.

406 (Not acceptable) sửa

Máy chủ chỉ có thể tạo một phản hồi mà không được chấp nhận bởi Client.

407 (Proxy authentication required) sửa

Yêu cầu client phải xác thực sử dụng một proxy. Khi máy chủ trả về phản hồi này, nó cũng chỉ ra proxy mà người yêu cầu phải sử dụng.

408 (Request timeout) sửa

Request tốn thời gian dài hơn thời gian máy chủ phản hồi

409 (Conflict) sửa

Các máy chủ gặp phải một cuộc xung đột thực hiện yêu cầu. Các máy chủ phải bao gồm thông tin về các cuộc xung đột trong các phản ứng. Máy chủ có thể trả về mã này để đáp ứng với yêu cầu PUT xung đột với yêu cầu trước đó, cùng với một danh sách các sự khác biệt giữa các yêu cầu.

410 (Gone) sửa

Các máy chủ trả về phản hồi này khi các nguồn tài nguyên yêu cầu đã bị loại bỏ vĩnh viễn. Nó tương tự như một 404 (Không tìm thấy) mã, nhưng đôi khi được sử dụng ở vị trí của một 404 cho nguồn lực được sử dụng để tồn tại nhưng không còn làm. Nếu tài nguyên đã di chuyển vĩnh viễn, bạn nên sử dụng một 301 để xác định vị trí mới của tài nguyên.

411 (Length required) sửa

Content-Length không được xác định rõ. Máy chủ sẽ không chấp nhận yêu cầu mà không có nó

412 (Precondition failed) sửa

Các máy chủ không đáp ứng một trong các điều kiện tiên quyết mà người yêu cầu đưa vào yêu cầu.

413 (Request entity too large) sửa

Máy chủ không thể xử lý yêu cầu bởi vì nó là quá lớn đối với các máy chủ để xử lý.

414 (Requested URI is too long) sửa

URI yêu cầu (thường là một URL) là quá dài đối với máy chủ để xử lý.

416 (Requested range not satisfiable) sửa

Máy chủ trả về mã trạng thái này nếu yêu cầu cho một phạm vi không có sẵn cho trang.

417 (Expectation failed) sửa

Máy chủ không thể đáp ứng yêu cầu của các trường yêu cầu, tiêu đề mong đợi.

5xx: Lỗi Server sửa

Nó nghĩa là máy chủ thất bại với việc thực hiện một yêu cầu nhìn như có vẻ khả thi.

500 (Internal server error) sửa

Các máy chủ gặp lỗi và không thể thực hiện yêu cầu.

501 (Not implemented) sửa

Các máy chủ không có các chức năng để thực hiện yêu cầu. Ví dụ, máy chủ có thể trả về mã này khi nó không nhận ra phương thức yêu cầu.

502 (Bad gateway) sửa

Các máy chủ đã hoạt động như một gateway hoặc proxy và nhận được một phản ứng không hợp lệ từ máy chủ ngược.

503 (Service unavailable) sửa

Máy chủ hiện không có sẵn (vì nó bị quá tải hoặc xuống để bảo trì). Nói chung, đây là một trạng thái tạm thời.

504 (Gateway timeout) sửa

Các máy chủ đã hoạt động như một gateway hoặc proxy và đã không nhận được yêu cầu kịp thời từ máy chủ ngược.

505 (HTTP version not supported) sửa

Các máy chủ không hỗ trợ phiên bản giao thức HTTP được sử dụng trong yêu cầu.

Sau đây là danh sách tất cả các mã trạng thái HTTP được liệt kê theo tài liệu giao thức HTTP của trang w3c

HTTP Response Header Fields sửa

Các trường Header phản hồi cho phép Server truyền thông tin thêm về phản hồi mà không thể được đặt trong dòng Status-Line. Những trường Header này cung cấp thông tin về Server và về truy cập từ xa tới nguồn được xác định bởi Request-URI:

response-header = Accept-Ranges; 
                       | Age     ; 
                       | ETag    ; 
                       | Location; 
                       | Proxy-Authenticate; 
                       | Retry-After; 
                       | Server;
                       | Vary    ; 
                       | WWW-Authenticate;

HTTP CACHING sửa

Encrypted connections sửa

Có 2 cách phổ biến mã hóa kết nối HTTP là HTTP secure (viết tắt HTTPS = HTTP + SSL) hoặc kết hợp HTTP và Transport Layer Securerity (TLS)

Liên quan sửa

Chú giải sửa

  1. ^ Trong thực tế, các luồng này được sử dụng dưới dạng nhiều kết nối phụ TCP/IP để ghép các yêu cầu/phản hồi đồng thời, do đó giảm đáng kể số lượng kết nối TCP/IP thực ở phía máy chủ, từ 2-8 cho mỗi máy khách xuống còn 1 và cho phép nhiều khách hơn được xử lý cùng một lúc.
  2. ^ Vào năm 2022, hỗ trợ HTTP/0.9 vẫn chưa chính thức bị ngừng sử dụng hoàn toàn và vẫn hiện diện trên nhiều máy chủ web và trình duyệt (chỉ dành cho phản hồi của máy chủ), ngay cả khi thường bị tắt. Hiện chưa rõ sẽ mất bao lâu để ngừng hoạt động HTTP/0.9 hoàn toàn.

Tham khảo sửa

  1. ^ Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul J.; Berners-Lee, Tim (June 1999). Hypertext Transfer Protocol – HTTP/1.1. IETF. RFC 2616. https://tools.ietf.org/html/rfc2616. 
  2. ^ a b c d Tim Berner-Lee (1 tháng 1 năm 1991). “The Original HTTP as defined in 1991”. www.w3.org (bằng tiếng Anh). World Wide Web Consortium. Truy cập ngày 24 tháng 7 năm 2010.
  3. ^ a b Tim Berner-Lee (1992). “Basic HTTP as defined in 1992”. www.w3.org (bằng tiếng Anh). World Wide Web Consortium. Truy cập ngày 19 tháng 10 năm 2021.
  4. ^ “Usage Statistics of Default protocol https for websites”. w3techs.com. Truy cập ngày 16 tháng 10 năm 2022.
  5. ^ “Usage Statistics of HTTP/2 for websites”. w3techs.com. Truy cập ngày 20 tháng 4 năm 2023.
  6. ^ “Can I use... Support tables for HTML5, CSS3, etc”. caniuse.com. Truy cập ngày 16 tháng 10 năm 2022.
  7. ^ “Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension”. IETF. tháng 7 năm 2014. RFC 7301.
  8. ^ Belshe, M.; Peon, R.; Thomson, M. “Hypertext Transfer Protocol Version 2, Use of TLS Features”. Bản gốc lưu trữ ngày 15 tháng 7 năm 2013. Truy cập ngày 10 tháng 2 năm 2015.
  9. ^ Benjamin, David. “Using TLS 1.3 with HTTP/2”. tools.ietf.org (bằng tiếng Anh). Truy cập ngày 2 tháng 6 năm 2020. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.
  10. ^ Bishop, Mike (ngày 9 tháng 7 năm 2019). “Hypertext Transfer Protocol Version 3 (HTTP/3)”. tools.ietf.org (bằng tiếng Anh). draft-ietf-quic-http-22. Truy cập ngày 16 tháng 8 năm 2019.
  11. ^ Cimpanu, Catalin. “HTTP-over-QUIC to be renamed HTTP/3 | ZDNet”. ZDNet (bằng tiếng Anh). Truy cập ngày 19 tháng 11 năm 2018.
  12. ^ Cimpanu, Catalin (ngày 26 tháng 9 năm 2019). “Cloudflare, Google Chrome, and Firefox add HTTP/3 support”. ZDNet. Truy cập ngày 27 tháng 9 năm 2019.
  13. ^ “HTTP/3: the past, the present, and the future”. The Cloudflare Blog (bằng tiếng Anh). 26 tháng 9 năm 2019. Truy cập ngày 30 tháng 10 năm 2019.
  14. ^ “Firefox Nightly supports HTTP 3 - General - Cloudflare Community”. 19 tháng 11 năm 2019. Bản gốc lưu trữ ngày 6 tháng 6 năm 2020. Truy cập ngày 23 tháng 1 năm 2020.
  15. ^ “HTTP/3 is Fast”. Request Metrics (bằng tiếng Anh). Truy cập ngày 1 tháng 7 năm 2022.
  16. ^ "Overall Operation". RFC 1945. pp. 6–8. sec. 1.3. RFC 1945. https://tools.ietf.org/html/rfc1945#section-1.3. 
  17. ^ "Connection Management: Persistence". RFC 9112, HTTP/1.1. sec. 9.3. RFC 9112. https://tools.ietf.org/html/rfc9112#section-9.3. 
  18. ^ “Classic HTTP Documents”. W3.org. 14 tháng 5 năm 1998. Truy cập ngày 1 tháng 8 năm 2010.
  19. ^ "HTTP/2 Protocol Overview". RFC 9113, HTTP/2). sec. 2. RFC 7540. https://tools.ietf.org/html/rfc7540#section-2. 
  20. ^ “Invention Of The Web, Web History, Who Invented the Web, Tim Berners-Lee, Robert Cailliau, CERN, First Web Server”. LivingInternet (bằng tiếng Anh). Truy cập ngày 11 tháng 8 năm 2021.
  21. ^ Berners-Lee, Tim (2 tháng 10 năm 1990). “daemon.c - TCP/IP based server for HyperText”. www.w3.org. Truy cập ngày 11 tháng 8 năm 2021.
  22. ^ Berners-Lee, Tim. “HyperText Transfer Protocol”. World Wide Web Consortium. Truy cập ngày 31 tháng 8 năm 2010.
  23. ^ Raggett, Dave. “Dave Raggett's Bio”. World Wide Web Consortium. Truy cập ngày 11 tháng 6 năm 2010.
  24. ^ Raggett, Dave; Berners-Lee, Tim. “Hypertext Transfer Protocol Working Group”. World Wide Web Consortium. Truy cập ngày 29 tháng 9 năm 2010.
  25. ^ Raggett, Dave. “HTTP WG Plans”. World Wide Web Consortium. Truy cập ngày 29 tháng 9 năm 2010.
  26. ^ “HTTP/1.1”. Webcom.com Glossary entry. Bản gốc lưu trữ ngày 21 tháng 11 năm 2001. Truy cập ngày 29 tháng 5 năm 2009.
  27. ^ “HTTP-NG Working Group”. www.w3.org (bằng tiếng Anh). World Wide Web Consortium. 1997. Truy cập ngày 19 tháng 10 năm 2021.
  28. ^ Web Administrator (2007). “HTTP Working Group”. httpwg.org (bằng tiếng Anh). IETF. Truy cập ngày 19 tháng 10 năm 2021.
  29. ^ Web Administrator (2007). “HTTP Working Group: charter httpbis”. datatracker.ietf.org (bằng tiếng Anh). IETF. Truy cập ngày 19 tháng 10 năm 2021.
  30. ^ “SPDY: An experimental protocol for a faster web”. dev.chromium.org (bằng tiếng Anh). Google. 1 tháng 11 năm 2009. Truy cập ngày 19 tháng 10 năm 2021.
  31. ^ “Rechartering httpbis” (bằng tiếng Anh). IETF; HTTP WG. 24 tháng 1 năm 2012. Truy cập ngày 19 tháng 10 năm 2021.
  32. ^ IESG Secretary (19 tháng 3 năm 2012). “WG Action: RECHARTER: Hypertext Transfer Protocol Bis (httpbis)” (bằng tiếng Anh). IETF; HTTP WG. Truy cập ngày 19 tháng 10 năm 2021.
  33. ^ Ilya Grigorik; Surma (3 tháng 9 năm 2019). “High Performance Browser Networking: Introduction to HTTP/2”. developers.google.com (bằng tiếng Anh). Google Inc. Truy cập ngày 19 tháng 10 năm 2021.
  34. ^ "Phụ lục-A: Lịch sử phiên bản HTTP". RFC 7230, HTTP/1.1: Cú pháp và định tuyến thông điệp. p. 78. sec. A. RFC 7230. https://tools.ietf.org/html/rfc7230#appendix-A. 
  35. ^ Matt Menke (30 tháng 6 năm 2016). “Intent to Deprecate and Remove: HTTP/0.9 Support”. groups.google.com (bằng tiếng Anh). Truy cập ngày 15 tháng 10 năm 2021.

Liên kết ngoài sửa

  1. HTTP Protocol w3c.org. Liên kết: https://www.w3.org/Protocols/
  2. Hypertext Transfer Protocol wikipedia https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
  3. Bản RFC 2616 https://tools.ietf.org/html/rfc2616
Lấy từ “https://vi.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&oldid=70902650”