031.3 Bài 1
Chứng chỉ: |
Web Development Essentials |
---|---|
Phiên bản: |
1.0 |
Chủ đề: |
031 Phát triển Phần mềm và Công nghệ Web |
Mục tiêu: |
031.3 Khái niệm cơ bản về HTTP |
Bài: |
1 trên 1 |
Giới thiệu
Giao thức truyền Siêu Văn bản (HTTP - HyperText Transfer Protocol) sẽ xác định cách mà máy khách yêu cầu máy chủ cung cấp một tài nguyên cụ thể. Nguyên tắc hoạt động của nó khá đơn giản: máy khách sẽ tạo một thông báo yêu cầu xác định tài nguyên mà nó cần và chuyển tiếp thông báo đó đến máy chủ thông qua mạng. Đổi lại, máy chủ HTTP sẽ xem xét vị trí để trích xuất tài nguyên được yêu cầu và gửi thông báo phản hồi lại cho máy khách. Thông báo trả lời sẽ chứa thông tin chi tiết về tài nguyên được yêu cầu, theo sau chính là tài nguyên đó.
Cụ thể hơn, HTTP là tập hợp các quy tắc xác định cách máy khách định dạng các thông báo yêu cầu sẽ được gửi đến máy chủ. Sau đó, máy chủ sẽ tuân theo các quy tắc HTTP để diễn giải yêu cầu và định dạng thông báo phản hồi. Ngoài việc yêu cầu hoặc chuyển nội dung được yêu cầu, các thông báo HTTP sẽ chứa các thông tin bổ sung về máy khách và máy chủ có liên quan, về bản thân nội dung và thậm chí là về tính không khả dụng của nội dung đó. Nếu không thể gửi tài nguyên, một mã trong phản hồi sẽ giải thích lý do không khả dụng và sẽ cho biết nơi tài nguyên đã được chuyển tới nếu có thể.
Phần thông báo xác định chi tiết tài nguyên và thông tin ngữ cảnh khác được gọi là tiêu đề của thông báo. Phần theo sau tiêu đề sẽ chứa nội dung của tài nguyên tương ứng và được gọi là tải trọng của thông báo. Cả thông báo yêu cầu và thông báo phản hồi đều có thể có tải trọng, nhưng trong hầu hết các trường hợp thì chỉ có thông báo phản hồi là có tải trọng.
Yêu cầu của Máy Khách
Giai đoạn đầu tiên của một phiên trao đổi dữ liệu HTTP giữa máy khách và máy chủ sẽ được bắt đầu bởi máy khách khi nó viết một thông báo yêu cầu tới máy chủ. Lấy ví dụ một tác vụ phổ biến của trình duyệt: tải trang HTML từ máy chủ lưu trữ trang web (chẳng hạn như https://learning.lpi.org/en/
). Địa chỉ (hay còn gọi là URL) sẽ cung cấp một số thông tin liên quan. Có ba mẩu thông tin xuất hiện trong ví dụ cụ thể này:
-
Giao thức: Giao thức Truyền Siêu Văn bản an toàn (
https
) - một phiên bản được mã hóa của HTTP. -
Tên mạng của máy chủ web (
learning.lpi.org
) -
Vị trí của tài nguyên được yêu cầu trên máy chủ (thư mục
/en/
--trong trường hợp này là phiên bản tiếng Anh của trang chủ).
Note
|
Bộ Định vị Tài nguyên Thống nhất (URL - Uniform Resource Locator) là một địa chỉ trỏ đến một tài nguyên trên Internet. Tài nguyên này thường là một tệp có thể được sao chép từ một máy chủ từ xa, nhưng các URL cũng có thể biểu thị các luồng dữ liệu và nội dung được tạo ở trạng thái động. |
Cách Máy Khách xử lý URL
Trước khi liên hệ với máy chủ, máy khách sẽ cần chuyển đổi learning.lpi.org
thành địa chỉ IP tương ứng của nó. Máy khách sẽ sử dụng một dịch vụ Internet khác là Hệ thống Tên Miền (DNS) để yêu cầu địa chỉ IP của tên máy chủ từ một hoặc nhiều máy chủ DNS được xác định trước (máy chủ DNS thường được Nhà cung cấp dịch vụ Internet hay ISP tự động xác định).
Với địa chỉ IP của máy chủ, máy khách sẽ cố gắng kết nối với cổng HTTP hoặc HTTPS. Các cổng mạng là các số nhận dạng được Giao thức Điều khiển Truyền dẫn (TCP) xác định để đan xen và xác định các kênh liên lạc riêng biệt trong một kết nối máy khách/máy chủ. Theo mặc định, máy chủ HTTP sẽ nhận yêu cầu trên cổng TCP 80 (HTTP) và 443 (HTTPS).
Note
|
Có các giao thức khác được các ứng dụng web sử dụng để thực hiện giao tiếp máy khách/máy chủ. Ví dụ: đối với các cuộc gọi thoại và video, sẽ phù hợp hơn khi sử dụng WebSockets - một giao thức cấp thấp hơn và hiệu quả hơn HTTP trong việc truyền luồng dữ liệu theo cả hai hướng. |
Định dạng của thông báo yêu cầu mà máy khách gửi đến máy chủ trong HTTP và HTTPS là giống nhau. HTTPS hiện nay đã được sử dụng rộng rãi hơn HTTP bởi tất cả các trao đổi dữ liệu giữa máy khách và máy chủ đều được mã hóa; đây là một tính năng không thể thiếu để thúc đẩy quyền riêng tư và bảo mật trên các mạng công cộng. Kết nối được mã hóa sẽ được thiết lập giữa máy khách và máy chủ ngay cả trước khi bất kỳ thông báo HTTP nào được trao đổi sử dụng giao thức mã hóa Bảo mật Tầng Vận tải (TLS). Bằng cách này, tất cả các giao tiếp HTTPS sẽ được gói gọn bởi TLS. Sau khi được giải mã, yêu cầu hoặc phản hồi được truyền qua HTTPS sẽ không khác gì yêu cầu hoặc phản hồi được thực hiện riêng qua HTTP.
Phần tử thứ ba của URL trong ví dụ (/en/
) sẽ được máy chủ hiểu là vị trí hoặc đường dẫn cho tài nguyên được yêu cầu. Nếu đường dẫn không được cung cấp trong URL, vị trí mặc định /
sẽ được sử dụng. Việc triển khai máy chủ HTTP đơn giản nhất sẽ liên kết các đường dẫn trong URL với các tệp trên hệ thống tệp nơi máy chủ đang chạy, nhưng đây chỉ là một trong nhiều tùy chọn có sẵn trên các máy chủ HTTP phức tạp.
Thông báo Yêu cầu
HTTP hoạt động thông qua một kết nối đã được thiết lập giữa máy khách và máy chủ thường được triển khai trong TCP và được mã hóa bằng TLS. Trên thực tế, một khi kết nối đáp ứng được các yêu cầu do máy chủ đặt ra đã sẵn sàng, một yêu cầu HTTP được nhập bằng tay ở dạng văn bản thuần túy sẽ có thể tạo ra phản hồi từ máy chủ. Tuy nhiên, trên thực tế, các lập trình viên hiếm khi cần triển khai các quy trình để soạn thông báo HTTP vì hầu hết các ngôn ngữ lập trình đều cung cấp các cơ chế tự động hóa việc tạo thông báo HTTP. Trong trường hợp của URL trong ví dụ (https://learning.lpi.org/en/
), thông báo yêu cầu đơn giản nhất có thể sẽ có nội dung như sau:
GET /en/ HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: text/html
Từ đầu tiên của dòng đầu tiên sẽ xác định phương thức HTTP. Nó sẽ xác định hoạt động nào mà máy khách muốn thực hiện trên máy chủ. Phương thức GET sẽ thông báo cho máy chủ rằng máy khách đang yêu cầu tài nguyên theo sau nó, tức /en/
. Cả máy khách và máy chủ đều có thể hỗ trợ nhiều hơn một phiên bản của giao thức HTTP; vì vậy, phiên bản được sử dụng trong quá trình trao đổi dữ liệu cũng sẽ được cung cấp trong dòng đầu tiên là HTTP/1.1
.
Note
|
Phiên bản mới nhất của giao thức HTTP là HTTP/2. Ngoài một số khác biệt chung, các tin nhắn được viết bằng HTTP/2 sẽ được mã hóa theo cấu trúc nhị phân, trong khi các tin nhắn được viết bằng HTTP/1.1 sẽ được gửi ở dạng văn bản thuần túy. Sự thay đổi này giúp tối ưu hóa tốc độ truyền tải dữ liệu, nhưng về cơ bản thì nội dung các tin nhắn vẫn không thay đổi. |
Tiêu đề có thể chứa nhiều dòng hơn sau dòng đầu tiên để bối cảnh hóa và giúp xác định yêu cầu tới máy chủ. Ví dụ như trường tiêu đề Host
(máy chủ) trông có vẻ hơi dư thừa vì máy chủ của máy chủ rõ ràng đã được máy khách xác định để thiết lập kết nối, và việc cho rằng máy chủ phải biết được danh tính của chính nó cũng là điều hợp lý. Tuy nhiên, điều quan trọng là phải thông báo cho máy chủ về tên máy chủ dự kiến trong tiêu đề của yêu cầu vì việc sử dụng cùng một máy chủ HTTP để lưu trữ nhiều trang web là khá thông dụng (trong trường hợp này, mỗi máy chủ cụ thể sẽ được gọi là máy chủ ảo). Do đó, trường Host
sẽ được máy chủ HTTP sử dụng để xác định máy chủ mà yêu cầu đề cập đến.
Trường tiêu đề User-Agent
sẽ chứa thông tin chi tiết về chương trình máy khách gửi yêu cầu. Trường này có thể được máy chủ sử dụng để điều chỉnh phản hồi theo nhu cầu của một máy khách cụ thể, nhưng nó lại thường được sử dụng để tạo số liệu thống kê về các máy khách sử dụng máy chủ.
Trường Accept
(Chấp nhận) sẽ có giá trị ngay tức thì vì nó sẽ thông báo cho máy chủ về định dạng của tài nguyên được yêu cầu. Nếu máy khách không quan tâm đến định dạng tài nguyên, trường Accept
có thể chỉ định */*
làm định dạng.
Có nhiều trường tiêu đề khác có thể được sử dụng trong thông báo HTTP, nhưng các trường được hiển thị trong ví dụ đã là đủ để yêu cầu tài nguyên từ máy chủ.
Ngoài các trường trong tiêu đề của yêu cầu, máy khách có thể thêm vào dữ liệu bổ sung khác trong yêu cầu HTTP được gửi đến máy chủ. Nếu dữ liệu này chỉ bao gồm các tham số văn bản đơn giản ở định dạng name=value
thì chúng có thể được thêm vào đường dẫn của phương thức GET. Các tham số sẽ được nhúng trong đường dẫn sau một dấu chấm hỏi và sẽ được phân tách bằng ký tự (&
):
GET /cgi-bin/receive.cgi?name=LPI&email=info@lpi.org HTTP/1.1
Trong ví dụ này, /cgi-bin/receive.cgi
là đường dẫn đến tệp lệnh trên máy chủ; máy chủ sẽ xử lý và có thể sử dụng các tham số name
và email
thu được từ đường dẫn của yêu cầu. Chuỗi tương ứng với các trường ở định dạng name=LPI&email=info@lpi.org
được gọi là chuỗi truy vấn và sẽ được cung cấp cho tệp lệnh receive.cgi
bởi máy chủ HTTP nhận yêu cầu.
Khi dữ liệu được tạo thành từ nhiều trường văn bản ngắn thì việc gửi dữ liệu đó trong phần tải trọng của tin nhắn sẽ phù hợp hơn. Trong trường hợp này, phương thức HTTP POST phải được sử dụng để máy chủ nhận và xử lý tải trọng của thông báo theo thông số kỹ thuật được chỉ ra trong tiêu đề của yêu cầu. Khi phương thức POST được sử dụng, tiêu đề của yêu cầu phải cung cấp kích thước của tải trọng sẽ được gửi tiếp theo và cách định dạng phần thân:
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org Content-Length: 1503 Content-Type: multipart/form-data; boundary=------------------------405f7edfd646a37d
Trường Content-Length
sẽ cho biết kích thước được tính bằng byte của tải trọng và trường Content-Type
sẽ cho biết định dạng của nó. Định dạng multipart/form-data
là định dạng được sử dụng phổ biến nhất trong các biểu mẫu HTML truyền thống sử dụng phương thức POST. Ở định dạng này, mỗi trường được chèn trong tải trọng của yêu cầu sẽ được phân tách bằng mã được chỉ định bởi từ khóa boundary
. Ta chỉ nên sử dụng phương thức POST trong các trường hợp thích hợp vì nó sử dụng lượng dữ liệu lớn hơn một chút so với yêu cầu tương đương được thực hiện bằng phương thức GET. Do phương thức GET sẽ gửi các tham số trực tiếp trong tiêu đề của thông báo yêu cầu nên toàn bộ quá trình trao đổi dữ liệu sẽ có độ trễ thấp hơn do giai đoạn kết nối để truyền nội dung của thông báo có thể được bỏ qua.
Tiêu đề của Phản hồi
Sau khi máy chủ HTTP nhận được tiêu đề của thông báo yêu cầu, máy chủ sẽ trả lại thông báo phản hồi cho máy khách. Một yêu cầu tệp HTML thường sẽ có tiêu đề phản hồi như sau:
HTTP/1.1 200 OK Accept-Ranges: bytes Content-Length: 18170 Content-Type: text/html Date: Mon, 05 Apr 2021 13:44:25 GMT Etag: "606adcd4-46fa" Last-Modified: Mon, 05 Apr 2021 09:48:04 GMT Server: nginx/1.17.10
Dòng đầu tiên cho biết phiên bản của giao thức HTTP được sử dụng trong thông báo phản hồi và phiên bản này phải tương ứng với phiên bản được sử dụng trong tiêu đề yêu cầu. Sau đó, vẫn ở dòng đầu tiên, sẽ là mã trạng thái của phản hồi cho biết cách máy chủ diễn giải và tạo phản hồi cho yêu cầu.
Mã trạng thái là một số có ba chữ số, trong đó chữ số ngoài cùng bên trái xác định hạng phản hồi. Có năm hạng mã trạng thái, được đánh số từ 1 đến 5, mỗi hạng biểu thị một loại hành động được thực hiện bởi máy chủ:
- 1xx (Thông tin)
-
Yêu cầu đã được nhận, tiếp tục quá trình.
- 2xx (Thành công)
-
Yêu cầu đã được nhận, hiểu và chấp nhận thành công.
- 3xx (Chuyển hướng)
-
Cần thực hiện hành động tiếp theo để hoàn thành yêu cầu.
- 4xx (Lỗi máy khách)
-
Yêu cầu chứa cú pháp sai hoặc không thể thực hiện được.
- 5xx (Lỗi máy chủ)
-
Máy chủ không thực hiện được yêu cầu dù yêu cầu có vẻ hợp lệ.
Chữ số thứ hai và thứ ba được sử dụng để chỉ ra các chi tiết bổ sung. Ví dụ như mã 200 sẽ chỉ ra rằng yêu cầu có thể được trả lời mà không gặp bất kỳ sự cố nào. Như được minh họa trong ví dụ, bạn cũng có thể cung cấp một mô tả văn bản ngắn gọn sau mã phản hồi (OK
). Một số mã cụ thể sẽ được đặc biệt quan tâm để đảm bảo rằng máy khách HTTP có thể truy cập tài nguyên trong các tình huống bất lợi hoặc để giúp xác định lý do thất bại trong trường hợp yêu cầu không thành công:
301 Moved Permanently
-
Tài nguyên đích đã được chỉ định một URL vĩnh viễn mới, được cung cấp bởi trường tiêu đề
Location
(vị trí) trong phản hồi. 302 Found
-
Tài nguyên đích đang tạm thời nằm dưới một URL khác.
401 Unauthorized
-
Yêu cầu chưa được áp dụng vì thiếu thông tin xác thực hợp lệ cho tài nguyên đích.
403 Forbidden
-
Phản hồi
Forbidden
chỉ ra rằng, mặc dù yêu cầu hợp lệ nhưng máy chủ được cấu hình để không cung cấp nó. 404 Not Found
-
Máy chủ gốc không tìm thấy biểu diễn hiện tại cho tài nguyên đích hoặc không sẵn sàng tiết lộ biểu diễn có sẵn.
500 Internal Server Error
-
Máy chủ gặp phải tình trạng không mong muốn khiến nó không thể thực hiện được yêu cầu.
502 Bad Gateway
-
Máy chủ trong khi đóng vai trò là cổng hoặc trung gian đã nhận được phản hồi không hợp lệ từ máy chủ đầu vào mà nó đã truy cập trong khi cố gắng thực hiện yêu cầu.
Mặc dù đã cho biết rằng yêu cầu không thể thực hiện được nhưng mã trạng thái 4xx
và 5xx
ít nhất cũng cho ta thấy rằng máy chủ HTTP đang chạy và có khả năng nhận yêu cầu. Các mã 4xx
yêu cầu thực hiện một hành động đối với máy khách vì URL hoặc thông tin xác thực của nó sai. Ngược lại, mã 5xx
cho biết có điều gì đó không ổn ở phía máy chủ. Do đó, trong ngữ cảnh của các ứng dụng web, hai loại mã trạng thái này chỉ ra rằng nguồn gốc của lỗi nằm trong chính ứng dụng (hoặc của máy khách hoặc của máy chủ) chứ không phải ở trong cơ sở hạ tầng.
Nội dung Tĩnh và Động
Máy chủ HTTP sử dụng hai cơ chế cơ bản để thực hiện nội dung theo yêu cầu của khách. Cơ chế đầu tiên cung cấp nội dung tĩnh: nghĩa là đường dẫn được chỉ ra trong thông báo yêu cầu sẽ tương ứng với một tệp trên hệ thống tệp cục bộ của máy chủ. Cơ chế thứ hai cung cấp nội dung động: nghĩa là máy chủ HTTP sẽ chuyển tiếp yêu cầu tới một chương trình khác (có thể là một tệp lệnh) để tạo phản hồi từ các nguồn khác nhau, chẳng hạn như cơ sở dữ liệu và các tệp khác.
Mặc dù có các máy chủ HTTP khác nhau nhưng tất cả chúng đều sử dụng cùng một giao thức truyền thông HTTP và áp dụng ít nhiều các quy ước giống nhau. Một ứng dụng không có nhu cầu cụ thể có thể được triển khai với bất kỳ máy chủ truyền thống nào, chẳng hạn như Apache hoặc NGINX. Cả hai đều có khả năng tạo nội dung động và cung cấp nội dung tĩnh, nhưng sẽ có sự khác biệt nhỏ trong cấu hình của từng loại.
Ví dụ như vị trí của các tệp tĩnh cần được cung cấp được xác định theo các cách khác nhau trong Apache và NGINX. Quy ước ở đây là phải giữ các tệp này trong một thư mục cụ thể cho mục đích này, thư mục đó phải có tên liên quan tới máy chủ lưu trữ, ví dụ như /var/www/learning.lpi.org/
. Trong Apache, đường dẫn này được xác định bởi chỉ thị cấu hình DocumentRoot /var/www/learning.lpi.org
trong phần xác định máy chủ ảo. Trong NGINX, lệnh được sử dụng là root /var/www/learning.lpi.org
trong phần server
của tệp cấu hình.
Cho dù bạn chọn máy chủ nào, các tệp tại /var/www/learning.lpi.org/
cũng sẽ được cung cấp qua HTTP theo cách gần như giống nhau. Một số trường trong tiêu đề phản hồi và nội dung của chúng có thể khác nhau giữa hai máy chủ, nhưng các trường như Content-Type
(Loại Nội dung) sẽ phải có trong tiêu đề phản hồi và phải nhất quán trên mọi máy chủ.
Lưu trữ vào Bộ nhớ Đệm
HTTP được thiết kế để hoạt động trên mọi loại kết nối Internet dù là nhanh hay chậm. Hơn nữa, hầu hết các giao thức trao đổi HTTP đều phải đi qua nhiều nút mạng do kiến trúc phân tán của Internet. Do đó, điều quan trọng là phải áp dụng một số chiến lược lưu trữ nội dung trên bộ nhớ đệm để tránh việc truyền dư thừa nội dung đã tải xuống trước đó. Truyền HTTP có thể hoạt động với hai loại bộ nhớ đệm cơ bản: chia sẻ và riêng tư.
Bộ nhớ đệm chia sẻ sẽ được sử dụng bởi nhiều máy khách. Ví dụ: nhà cung cấp nội dung lớn có thể sử dụng bộ nhớ đệm trên các máy chủ được phân phối theo khu vực để máy khách lấy dữ liệu từ máy chủ gần nhất với chúng. Khi một máy khách đã đưa ra yêu cầu và phản hồi của nó được lưu trữ trong bộ nhớ đệm chia sẻ, các máy khách khác thực hiện cùng một yêu cầu trong cùng khu vực đó cũng sẽ nhận được phản hồi đã được lưu trong bộ nhớ đệm.
Bộ nhớ đệm riêng tư được tạo bởi chính máy khách để sử dụng độc quyền. Đây là loại lưu trữ vào bộ nhớ đệm mà trình duyệt web sẽ thực hiện đối với hình ảnh, tệp CSS, JavaScript hoặc chính tài liệu HTML; vì vậy, chúng sẽ không cần phải tải xuống lại nếu được yêu cầu trong tương lai gần.
Note
|
Không phải yêu cầu HTTP nào cũng phải được lưu vào bộ nhớ đệm. Ví dụ: một yêu cầu sử dụng phương thức POST sẽ đi kèm một phản hồi dành riêng cho yêu cầu cụ thể đó; vì vậy, ta không nên sử dụng lại nội dung phản hồi đó nữa. Theo mặc định, chỉ các phản hồi đối với các yêu cầu được thực hiện bằng phương thức GET mới được lưu vào bộ nhớ đệm. Hơn nữa, chỉ những phản hồi có mã trạng thái kết luận như 200 (OK), 206 (Partial Content), 301 (Moved Permanently) và 404 (Not Found) mới phù hợp để lưu vào bộ nhớ đệm. |
Cả hai chiến lược bộ nhớ đệm chia sẻ và riêng tư đều sử dụng các tiêu đề HTTP để kiểm soát cách nội dung đã tải xuống sẽ được lưu vào bộ nhớ đệm như thế nào. Đối với bộ nhớ đệm riêng tư, máy khách sẽ tham khảo tiêu đề phản hồi và xác minh xem liệu nội dung trong bộ nhớ đệm cục bộ có còn tương ứng với nội dung từ xa hiện tại hay không. Nếu tương ứng, máy khách sẽ từ bỏ việc chuyển tải trọng phản hồi và sử dụng phiên bản cục bộ.
Tính hợp lệ của tài nguyên được lưu trong bộ nhớ đệm có thể được đánh giá theo nhiều cách. Máy chủ có thể cung cấp ngày hết hạn trong tiêu đề phản hồi cho yêu cầu đầu tiên để máy khách loại bỏ tài nguyên được lưu trong bộ nhớ đệm khi kết thúc thời hạn và yêu cầu lại để lấy phiên bản cập nhật. Tuy nhiên, không phải lúc nào máy chủ cũng có thể xác định ngày hết hạn của tài nguyên; do đó, người ta thường sử dụng trường tiêu đề phản hồi ETag
để xác định phiên bản của tài nguyên, ví dụ như Etag: "606adcd4-46fa"
.
Để xác minh xem liệu tài nguyên được lưu trong bộ nhớ đệm có cần cập nhật hay không, máy khách sẽ chỉ yêu cầu tiêu đề phản hồi của nó từ máy chủ. Nếu trường ETag
khớp với trường trong phiên bản được lưu trữ cục bộ, máy khách sẽ sử dụng lại nội dung được lưu trong bộ nhớ đệm. Nếu không khớp, nội dung cập nhật của tài nguyên sẽ được tải xuống từ máy chủ.
Phiên HTTP
Trong một trang web hoặc ứng dụng web thông thường, các tính năng xử lý kiểm soát phiên sẽ dựa trên các tiêu đề HTTP. Ví dụ như máy chủ không thể giả định rằng tất cả các yêu cầu đến từ cùng một địa chỉ IP là từ cùng một máy khách. Phương pháp truyền thống nhất cho phép máy chủ liên kết các yêu cầu khác nhau với một máy khách là sử dụng cookies, tức một loại thẻ nhận dạng được máy chủ cấp cho máy khách và được cung cấp trong tiêu đề HTTP.
Cookies cho phép máy chủ lưu giữ thông tin về một máy khách cụ thể ngay cả khi người điều hành máy khách đó không định danh bản thân họ. Cookies có thể giúp triển khai các phiên mà trong đó thông tin đăng nhập, giỏ hàng, tùy chọn, v.v., được lưu giữ giữa các yêu cầu khác nhau được thực hiện cho cùng một máy chủ đã cung cấp chúng. Cookies cũng được sử dụng để theo dõi quá trình duyệt web của người dùng; vì vậy, điều quan trọng ở đây là phải yêu cầu sự đồng ý trước khi gửi chúng.
Máy chủ sẽ đặt cookies trong tiêu đề phản hồi bằng cách sử dụng trường Set-Cookie
. Giá trị trường là một cặp name=value
được chọn để biểu thị một số thuộc tính được liên quan tới một máy khách cụ thể. Ví dụ: máy chủ có thể tạo số nhận dạng cho máy khách yêu cầu tài nguyên lần đầu tiên và chuyển nó cho máy khách trong tiêu đề phản hồi:
HTTP/1.1 200 OK Accept-Ranges: bytes Set-Cookie: client_id=62b5b719-fcbf
Nếu máy khách cho phép sử dụng cookies, các yêu cầu mới gửi đến cùng một máy chủ này sẽ có trường cookies trong tiêu đề:
GET /en/ HTTP/1.1 Host: learning.lpi.org Cookie: client_id=62b5b719-fcbf
Với số nhận dạng này, máy chủ có thể truy xuất các định nghĩa cụ thể cho máy khách và tạo một phản hồi tùy chỉnh. Cũng có thể sử dụng nhiều trường Set-Cookie
để gửi các cookie khác nhau cho cùng một máy khách. Bằng cách này, có thể có nhiều định nghĩa được lưu giữ ở phía máy khách.
Cookies gây ra các vấn đề về cả quyền riêng tư lẫn các lỗ hổng bảo mật tiềm ẩn bởi có khả năng chúng sẽ được chuyển sang một máy khách khác có thể được máy chủ xác định là máy khách ban đầu. Các cookies được sử dụng để duy trì các phiên có thể cấp quyền truy cập vào các thông tin nhạy cảm từ máy khách ban đầu. Do đó, điều quan trọng đối với các máy khách là áp dụng các cơ chế bảo vệ cục bộ để ngăn cookise của họ bị trích xuất và tái sử dụng trong khi không được cho phép.
Bài tập Hướng dẫn
-
Thông báo yêu cầu sau sử dụng phương thức HTTP nào?
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: */* Content-Length: 27 Content-Type: application/x-www-form-urlencoded
-
Khi một máy chủ HTTP lưu trữ nhiều trang web, làm cách nào để nó có thể xác định yêu cầu nào là dành cho trang nào?
-
Tham số nào sẽ được cung cấp bởi chuỗi truy vấn của URL
https://www.google.com/search?q=LPI
? -
Tại sao yêu cầu HTTP sau đây lại không phù hợp với bộ nhớ đệm?
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: */* Content-Length: 27 Content-Type: application/x-www-form-urlencoded
Bài tập Mở rộng
-
Làm thế nào để có thể sử dụng trình duyệt web để theo dõi các yêu cầu và phản hồi được thực hiện bởi một trang HTML?
-
Các máy chủ HTTP cung cấp nội dung tĩnh thường ánh xạ đường dẫn được yêu cầu thành một tệp trong hệ thống tệp của máy chủ. Điều gì sẽ xảy ra khi đường dẫn trong yêu cầu trỏ đến một thư mục?
-
Nội dung của các tệp được gửi qua HTTPS được bảo vệ bằng mã hóa; vì vậy, các máy tính giữa máy khách và máy chủ không thể đọc được chúng. Mặc dù vậy, những máy tính ở giữa này có thể xác định được tài nguyên nào mà máy khách đã yêu cầu từ máy chủ không?
Tóm tắt
Bài học này đã trình bày các kiến thức cơ bản về HTTP, giao thức chính được máy khách sử dụng để yêu cầu tài nguyên từ máy chủ web. Bài học đã nhắc tới các khái niệm sau:
-
Thông báo yêu cầu, trường tiêu đề và phương thức.
-
Mã trạng thái phản hồi.
-
Cách máy chủ HTTP tạo phản hồi.
-
Các tính năng HTTP hữu ích cho bộ nhớ đệm và việc quản lý phiên.
Đáp án Bài tập Hướng dẫn
-
Thông báo yêu cầu sau sử dụng phương thức HTTP nào?
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: */* Content-Length: 27 Content-Type: application/x-www-form-urlencoded
Phương thức POST.
-
Khi một máy chủ HTTP lưu trữ nhiều trang web, làm cách nào để nó có thể xác định yêu cầu nào là dành cho trang nào?
Trường
Host
trong tiêu đề yêu cầu sẽ cho biết trang web mục tiêu. -
Tham số nào sẽ được cung cấp bởi chuỗi truy vấn của URL
https://www.google.com/search?q=LPI
?Tham số có tên
q
với giá trịLPI
. -
Tại sao yêu cầu HTTP sau đây lại không phù hợp với bộ nhớ đệm?
POST /cgi-bin/receive.cgi HTTP/1.1 Host: learning.lpi.org User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0 Accept: */* Content-Length: 27 Content-Type: application/x-www-form-urlencoded
Bởi vì các yêu cầu được thực hiện bằng phương thức POST ám chỉ một thao tác ghi trên máy chủ nên chúng không được lưu vào bộ nhớ đệm.
Đáp án Bài tập Mở rộng
-
Làm thế nào để có thể sử dụng trình duyệt web để theo dõi các yêu cầu và phản hồi được thực hiện bởi một trang HTML?
Bên cạnh nhiều các công cụ khác thì tất cả các trình duyệt phổ biến đều cung cấp các công cụ phát triển có thể hiển thị tất cả các giao dịch mạng đã được thực hiện bởi trang hiện tại.
-
Các máy chủ HTTP cung cấp nội dung tĩnh thường ánh xạ đường dẫn được yêu cầu thành một tệp trong hệ thống tệp của máy chủ. Điều gì sẽ xảy ra khi đường dẫn trong yêu cầu trỏ đến một thư mục?
Việc này phụ thuộc vào cách máy chủ được cấu hình. Theo mặc định, hầu hết các máy chủ HTTP sẽ tìm kiếm một tệp có tên
index.html
(hoặc một cái tên được xác định trước khác) trong cùng thư mục đó và sẽ gửi nó dưới dạng phản hồi. Nếu tệp không có ở đó, máy chủ sẽ đưa ra phản hồi404 Not Found
. -
Nội dung của các tệp được gửi qua HTTPS được bảo vệ bằng mã hóa; vì vậy, các máy tính giữa máy khách và máy chủ không thể đọc được chúng. Mặc dù vậy, những máy tính ở giữa này có thể xác định được tài nguyên nào mà máy khách đã yêu cầu từ máy chủ không?
Không, bởi vì bản thân tiêu đề của các yêu cầu và phản hồi HTTP cũng sẽ được mã hóa bởi TLS.