Giao thức HTTP

Mô tả chi tiết về cách thức hoạt động của giao thức HTTP và Web

HTTP (Giao thức truyền siêu văn bản) là một trong những giao thức ứng dụng của TCP / IP, bộ giao thức hỗ trợ Internet.

Hãy để tôi sửa điều đó: nó không phảimộttrong số các giao thức, đó là giao thức thành công và phổ biến nhất, xét trên mọi phương diện.

HTTP là thứ làm cho World Wide Web hoạt động, cung cấp cho các trình duyệt một ngôn ngữ để giao tiếp với các máy chủ từ xa lưu trữ các trang web.

HTTP được chuẩn hóa lần đầu tiên vào năm 1991, là kết quả của công việc mà Tim Berners-Lee đã làm tại CERN, Trung tâm Nghiên cứu Hạt nhân Châu Âu, kể từ năm 1989.

Mục đích là cho phép các nhà nghiên cứu dễ dàng trao đổi và liên kết với nhau các bài báo của họ. Nó được coi là một cách để cộng đồng khoa học làm việc tốt hơn.

Hồi đó, các ứng dụng chính trên internet về cơ bản bao gồm FTP (Giao thức truyền tệp), Email và Usenet (nhóm tin tức, ngày nay hầu như bị bỏ rơi).

Năm 1993 Mosaic, trình duyệt web đồ họa đầu tiên, được phát hành, và mọi thứ đã tăng vọt từ đó.

Web trở thành ứng dụng sát thủ của Internet.

Theo thời gian, Web và hệ sinh thái xung quanh nó đã phát triển đáng kể, nhưng những điều cơ bản vẫn còn nguyên. Một ví dụ về sự phát triển: HTTP hiện cung cấp sức mạnh, ngoài các trang web, REST API, một cách phổ biến để truy cập theo chương trình một dịch vụ qua Internet.

HTTP có một bản sửa đổi nhỏ vào năm 1997 với HTTP / 1.1 và vào năm 2015 người kế nhiệm của nó,HTTP/2, đã được tiêu chuẩn hóa và hiện nó đang được triển khai bởi các Máy chủ Web lớn được sử dụng trên toàn cầu.

Giao thức HTTP được coi là không an toàn, giống như bất kỳ giao thức nào khác (SMTP, FTP ..) không được phân phát qua kết nối được mã hóa. Đây là lý do tại sao ngày nay có một sự thúc đẩy lớn đối với việc sử dụng HTTPS, HTTP được phân phát qua TLS.

Điều đó nói rằng, các khối xây dựng của HTTP / 2 và HTTPS có nguồn gốc từ HTTP và trong bài viết này, tôi sẽ giới thiệu cách thức hoạt động của HTTP.

Tài liệu HTML

HTTP là cáchtrình duyệt webnhư Chrome, Firefox, Edge và nhiều loại khác (còn được gọi làkhách hàngtừ đây trở đi) giao tiếp vớimáy chủ web.

Cái tên Giao thức truyền siêu văn bản xuất phát từ nhu cầu chuyển không chỉ các tệp, như trong FTP - “Giao thức truyền tệp”, mà còn các siêu kỹ thuật, sẽ được viết bằng HTML, và sau đó được trình duyệt biểu diễn bằng đồ thị với một bản trình bày đẹp mắt và tương tác các liên kết.

Các liên kết là động lực thúc đẩy việc áp dụng, cùng với việc dễ dàng tạo các trang web mới.

HTTP là thứ chuyển các tệp siêu văn bản đó (và như chúng ta sẽ thấy cả hình ảnh và các loại tệp khác) qua mạng.

Bên trong trình duyệt web, một tài liệu có thể trỏ đến một tài liệu khác bằng các liên kết.

Một liên kết được tạo bởi một phần đầu tiên xác định giao thức và địa chỉ máy chủ, thông qua tên miền hoặc IP.

Tất nhiên, phần này không phải là duy nhất của HTTP.

Sau đó là phần tài liệu. Bất kỳ thứ gì được nối vào phần địa chỉ sẽ đại diện cho đường dẫn tài liệu.

Ví dụ: địa chỉ tài liệu này làhttps://flaviocopes.com/http/:

  • httpslà giao thức.
  • flaviocopes.comlà tên miền trỏ đến máy chủ của tôi
  • /http/là URL của tài liệu liên quan đến đường dẫn gốc của máy chủ.

Đường dẫn có thể được lồng vào nhau:https://flaviocopes.com/page/privacy/và trong trường hợp này, URL của tài liệu là/page/privacy.

Máy chủ web chịu trách nhiệm giải thích yêu cầu và sau khi đã phân tích, đưa ra phản hồi chính xác.

Một yêu cầu

Có gì trong một yêu cầu?

Điều đầu tiên làURL, mà chúng ta đã thấy trước đây.

Khi chúng tôi nhập địa chỉ và nhấn enter trong trình duyệt của mình, máy chủ sẽ gửi đến địa chỉ IP chính xác một yêu cầu như sau:

GET /a-page

where /a-page is the URL you requested.

The second thing is the HTTP method (also called verb).

HTTP in the early days defined 3 of them:

  • GET
  • POST
  • HEAD

and HTTP/1.1 introduced

  • PUT
  • DELETE
  • OPTIONS
  • TRACE

We’ll see them in detail in a minute.

The third thing that composes a request is a set of HTTP headers.

Headers are a set of key: value pairs that are used to communicate to the server-specific information that is predefined, so the server can know what we mean.

I described them in detail in the HTTP request headers list.

Give that list a quick look. All of those headers are optional, except Host.

HTTP methods

GET

GET is the most used method here. It’s the one that’s used when you type an URL in the browser address bar, or when you click a link.

It asks the server to send the requested resource as a response.

HEAD is just like GET, but tells the server to not send the response body back. Just the headers.

POST

The client uses the POST method to send data to the server. It’s typically used in forms, for example, but also when interacting with a REST API.

PUT

The PUT method is intended to create a resource at that specific URL, with the parameters passed in the request body. Mainly used in REST APIs

DELETE

The DELETE method is called against an URL to request deletion of that resource. Mainly used in REST APIs

OPTIONS

When a server receives an OPTIONS request it should send back the list of HTTP methods allowed for that specific URL.

TRACE

Returns back to the client the request that has been received. Used for debugging or diagnostic purposes.

HTTP Client/Server communication

HTTP, as most of the protocols that belong to the TCP/IP suite, is a stateless protocol.

Servers have no idea what’s the current state of the client. All they care about is that they get request and they need to fulfill them.

Any prior request is meaningless in this context, and this makes it possible for a web server to be very fast, as there’s less to process, and also it gives it bandwidth to handle a lot of concurrent requests.

HTTP is also very lean, and communication is very fast in terms of overhead. This contrasts with the protocols that were the most used at the time HTTP was introduced: TCP and POP/SMTP, the mail protocols, which involve lots of handshaking and confirmations on the receiving ends.

Graphical browsers abstract all this communication, but we’ll illustrate it here for learning purposes.

A message is composed by a first line, which starts with the HTTP method, then contains the resource relative path, and the protocol version:

GET /a-page HTTP/1.1

After that, we need to add the HTTP request headers. As mentioned above, there are many headers, but the only mandatory one is Host:

GET /a-page HTTP/1.1
Host: flaviocopes.com

How can you test this? Using telnet. This is a command-line tool that lets us connect to any server and send it commands.

Open your terminal, and type telnet flaviocopes.com 80

This will open a terminal, that tells you

Trying 178.128.202.129...
Connected to flaviocopes.com.
Escape character is '^]'.

You are connected to the Netlify web server that powers my blog. You can now type:

GET /axios/ HTTP/1.1
Host: flaviocopes.com

and press enter on an empty line to fire the request.

The response will be:

HTTP/1.1 301 Moved Permanently
Cache-Control: public, max-age=0, must-revalidate
Content-Length: 46
Content-Type: text/plain
Date: Sun, 29 Jul 2018 14:07:07 GMT
Location: https://flaviocopes.com/axios/
Age: 0
Connection: keep-alive
Server: Netlify

Redirecting to https://flaviocopes.com/axios/

See, this is an HTTP response we got back from the server. It’s a 301 Moved Permanently request. See the HTTP status codes list to know more about the status codes.

It basically tells us the resource has permanently moved to another location.

Why? Because we connected to port 80, which is the default for HTTP, but on my server I set up an automatic redirection to HTTPS.

The new location is specified in the Location HTTP response header.

There are other headers, all described in the HTTP response headers list.

In both the request and the response, an empty line separates the request header from the request body. The response body in this case contains the string

Redirecting to https://flaviocopes.com/axios/

which is 46 bytes long, as specified in the Content-Length header. It is shown in the browser when you open the page, while it automatically redirects you to the correct location.

In this case we’re using telnet, the low-level tool that we can use to connect to any server, so we can’t have any kind of automatic redirect.

Let’s do this process again, now connecting to port 443, which is the default port of the HTTPS protocol. We can’t use telnet because of the SSL handshake that must happen.

Let’s keep things simple and use curl, another command-line tool. We cannot directly type the HTTP request, but we’ll see the response:

curl -i https://flaviocopes.com/axios/

this is what we’ll get in return:

HTTP/1.1 200 OK
Cache-Control: public, max-age=0, must-revalidate
Content-Type: text/html; charset=UTF-8
Date: Sun, 29 Jul 2018 14:20:45 GMT
Etag: "de3153d6eacef2299964de09db154b32-ssl"
Strict-Transport-Security: max-age=31536000
Age: 152
Content-Length: 9797
Connection: keep-alive
Server: Netlify

<!DOCTYPE html> <html prefix=“og: http://ogp.me/ns#” lang=“en”> <head> <meta charset=“utf-8”> <meta http-equiv=“X-UA-Compatible” content=“IE=edge”> <title>HTTP requests using Axios</title> …

I cut the response, but you can see that the HTML of the page is being returned now.

Other resources

An HTTP server will not just transfer HTML files, but typically it will also serve other files: CSS, JS, SVG, PNG, JPG, lots of different file types.

This depends on the configuration.

HTTP is perfectly capable of transferring those files as well, and the client will know about the file type, thus interpret them in the right way.

This is how the web works: when an HTML page is retrieved by the browser, it’s interpreted and any other resource it needs to display property (CSS, JavaScript, images..) is retrieved through additional HTTP requests to the same server.


More network tutorials: