What is an http request. URL - what is it

HTTP. It is based on interaction" client-server", that is, it is assumed that:
  1. Consumer- client having initiated a connection with the provider-server, sends it a request;
  2. Supplier- server, having received the request, performs the necessary actions and returns a response with the result back to the client.

    In this case, there are two possible ways to organize the work of the client computer:

    • Thin client is a client computer that transfers all information processing tasks to the server. An example of a thin client is a computer with a browser that is used to work with web applications.
    • Fat client, on the contrary, processes information independently of the server, using the latter mainly only for data storage.

Before moving on to specific client-server web technologies, let's consider the basic principles and structure of the basic HTTP protocol.

HTTP protocol

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) is an application layer protocol for transferring hypertext.

The central entity in HTTP is resource The URL pointed to in the client request. Typically, these resources are files stored on the server. A feature of the HTTP protocol is the ability to specify in the request and response the method of representing the same resource according to various parameters: format, encoding, language, etc. It is thanks to the ability to specify the method of encoding a message that the client and server can exchange binary data, although initially this protocol designed to transmit symbolic information. At first glance, this may seem like a waste of resources. Indeed, data in symbolic form takes up more memory, messages create additional load on communication channels, but this format has many advantages. Messages transmitted over the network are readable, and after analyzing the received data, system administrator can easily find the error and fix it. If necessary, a person can play the role of one of the interacting applications by manually entering messages in the required format.

Unlike many other protocols, HTTP is a memoryless protocol. This means that the protocol does not store information about previous client requests and server responses. Components using HTTP can independently maintain state information associated with recent requests and responses. For example, client web application, sending requests, can monitor response delays, and web server can store IP addresses and request headers of recent clients.

All software for working with the HTTP protocol is divided into three main categories:

  • Servers- providers of information storage and processing services (request processing).
  • Clients- end consumers of server services (sending requests).
  • Proxy servers to support the work of transport services.

The main clients are browsers eg: Internet Explorer, Opera, Mozilla Firefox, Netscape Navigator and others. The most popular web server implementations are: Internet Information Services (IIS), Apache, lighttpd, nginx. The most well-known proxy server implementations: Squid, UserGate, Multiproxy, Naviscope.

The “classic” HTTP session scheme looks like this.

  1. Establishing a TCP connection.
  2. Client request.
  3. Server response.
  4. Terminating the TCP connection.

Thus, the client sends a request to the server, receives a response from it, after which the interaction stops. Typically, the client request is a request to transfer an HTML document or some other resource, and the server response contains the code for this resource.

The HTTP request sent by the client to the server includes the following components.

  • Status line (sometimes the terms status line or query line are also used to refer to it).
  • Header fields.
  • Empty string.
  • Request body.

Status bar along with header fields sometimes also called request header.


Rice. 2.1.

Status bar has the following format:

request_method URL_pecypca protocol_version HTTP

Let's look at the components of the status bar, with special attention to the request methods.

Method specified in the status line determines how the resource whose URL is specified in the same line is affected. The method can take the values ​​GET, POST, HEAD, PUT, DELETE, etc. Despite the abundance of methods, only two of them are truly important for a web programmer: GET and POST.

  • GET. According to the formal definition, the GET method is intended to obtain a resource with a specified URL. Upon receiving a GET request, the server must read the specified resource and include the resource code as part of the response to the client. The resource whose URL is passed as part of the request does not have to be an HTML page, image file, or other data. The resource URL can point to executable program code that, if certain conditions are met, must be executed on the server. In this case, the client is returned not the program code, but the data generated during its execution. Although, by definition, the GET method is intended to retrieve information, it can be used for other purposes. The GET method is quite suitable for transferring small pieces of data to the server.
  • POST. According to the same formal definition, the main purpose POST method- data transfer to the server. However, like the GET method, the POST method can be used in many different ways and is often used to retrieve information from a server. As with the GET method, the URL specified in the status bar points to a specific resource. The POST method can also be used to start a process.
  • The HEAD and PUT methods are modifications of the GET and POST methods.

Protocol version HTTP is typically specified in the following format:

HTTP/version.modification

Header fields, following the status line, allow you to refine the request, i.e. transmit additional information to the server. The header field has the following format:

FieldName: Value

The purpose of a field is determined by its name, which is separated from the value by a colon.

The names of some of the most common header fields in a client request and their purpose are shown in Table 2.1.

Table 2.1. HTTP request header fields.
Header fields HTTP -request Meaning
Host Domain name or IP address of the host that the client is accessing
Referrer URL of the document that references the resource listed in the status bar
From Address email user working with a client
Accept MIME types of data processed by the client. This field can have multiple values, separated by commas. Often the Accept header field is used to tell the server what types of graphics files the client supports
Accept-Language A set of two-character identifiers, separated by commas, that indicate the languages ​​supported by the client
Accept-Charset List of supported character sets
Content-Type MIME type of data contained in the request body (if the request does not consist of a single header)
Content-Length Number of characters contained in the request body (if the request does not consist of a single header)
Range Present if the client does not request the entire document, but only part of it
Connection Used to manage TCP connection. If the field contains Close, this means that the server should close the connection after processing the request. The Keep-Alive value suggests keeping the TCP connection open so that it can be used for subsequent requests
User-Agent Client information

In many cases, when working on the Web, there is no request body. When CGI scripts are run, the data passed to them in the request can be placed in the body of the request.

HTTP(HyperText Transfer Protocol - “hypertext transfer protocol”) is an application layer protocol for data transfer (initially in the form of hypertext documents). The basis of HTTP is the client-server technology, that is, it assumes the existence of consumers (clients) who initiate the connection and send a request, and providers (servers) who wait for the connection to receive the request and make necessary actions and return a message with the result.

HTTP is also used as a "transport" for other application layer protocols, such as SOAP, XML-RPC, WebDAV.

The main object of manipulation in HTTP is the resource pointed to by the URI (Uniform Resource Identifier) ​​in the client request. Typically these resources are files stored on the server, but they can be logical objects or something abstract. A feature of the HTTP protocol is the ability to specify in the request and response the method of representing the same resource according to various parameters: format, encoding, language, etc. It is thanks to the ability to specify the method of encoding a message that the client and server can exchange binary data, although this protocol is text.

HTTP is an application layer protocol, similar to it are FTP and SMTP - Simple Mail Transfer Protocol. Messages are exchanged according to the usual request-response scheme. HTTP uses global URIs to identify resources. Unlike many other protocols, HTTP is stateless. This means that there is no persistence of intermediate state between request-response pairs. Components using HTTP can independently maintain state information associated with recent requests and responses. The browser sending the requests can track response delays. The server can store the IP addresses and request headers of the latest clients. However, the protocol itself is not aware of previous requests and responses, it does not provide internal state support, and no such requirements are imposed on it.

    Extensibility

The protocol's capabilities are easily extended by introducing its own headers, while maintaining compatibility with other clients and servers. They will ignore headers unknown to them, but at the same time they can get the necessary functionality for solving specific problems.

    HTTP/1.1 - current version protocol. New in this version was the “ permanent connection": A TCP connection can remain open after sending a response to a request, allowing multiple requests to be sent in a single connection. The client is now required to send information about the name of the host to which it is accessing, which made it possible to organize virtual hosting more easily.

HTTP doesn't store information about transactions, so you have to start all over again in the next transaction. The advantage is that HTTP server can serve many more clients in a given period of time because the additional overhead of tracking sessions from one connection to another is eliminated. There is also a drawback: saving information on transactions is more complex CGI programs must use hidden input fields or external means such as Cookies.

HTTP request methods

HTTP method- a sequence of any characters, except for controls and separators, indicating the main operation on the resource. Typically the method is a short English word written in capital letters. Please note that the method name is case sensitive.

Every server must support at least the GET and HEAD methods. If the server does not recognize the method specified by the client, then it should return status 501 (Not Implemented). If the server knows the method, but it is not applicable to a specific resource, then a message with code 405 (Method Not Allowed) is returned. In both cases, the server SHOULD include an Allow header in the response message with a list of supported methods.

In addition to the GET and HEAD methods, the POST method is often used.

  • HTTP request, response, entity headers (parameters)

    All headers in the HTTP protocol are divided into four main groups (it is recommended to send headers to the recipient in the order below):

      General Headers(Main headers) - must be included in any client and server message.

      Request Headers(Request headers) - used only in client requests.

      Response Headers(Response headers) - only for responses from the server.

      Entity Headers(Entity Headers) - accompany each message entity. IN separate class Entity headers are highlighted to avoid confusion with request headers or response headers for multiple content transfer (MIME).

    All headers necessary for HTTP to function are described in the main RFCs. If necessary, you can create your own headings. Traditionally, the names of such additional headers are prefixed with "X-" to avoid name conflicts with possibly existing ones.

    The lines after the main request line (GET /index.html HTTP/1.1) have the following format: Parameter: value. This is how the request parameters are set. This is optional; all lines after the main query line may be missing; in this case, the server accepts their value by default or based on the results of the previous request (when working in Connection: Keep-Alive mode).

      Parameter Connection(connection) - can take the values ​​Keep-Alive and close. In HTTP 1.0, the server's transmission of the requested data is followed by a disconnection from the client, and the transaction is considered complete unless the Connection: Keep Alive header is sent. In HTTP 1.1, the server does not close the connection by default and the client can send other requests. Because many documents have other documents embedded—images, frames, applets, etc.—this saves time and costs for the client, who would otherwise have to connect multiple times to the same server to get just one page. Thus, in HTTP 1.1, a transaction can loop until the client or server explicitly closes the connection.

      Parameter User-Agent- the value is the "code" of the browser.

      Parameter Accept- a list of content types supported by the browser in order of their preference for this browser.

      Parameter Host- the name of the domain from which the resource is requested. Useful if the server has several virtual servers under one IP address. In this case the name virtual domain determined by this field.

      Parameter Last-Modified(modified in last time) (W3C Last-Modified) - date and time last change document. Using it, the client, similar to the case with ETag, can contact the server with an "If-Modified-Since" request - in this case, the server must compare the last modification date of the copy stored on the client with the actual last modification date. If they match, this means that the copy in the client's cache is not out of date, and re-download not necessary (response code "304 Not Modified"). Last-Modified is also necessary for the correct processing of the site by robots, which use information about the date of modification of pages to sort search results by date, as well as to determine the frequency of updating your site.

    For SSI documents, Apache will issue "Last-Modified" if the "XBitHack full" directive is specified (for example, in the .htaccess file)

      Parameter ETag(object tag) - introduced in HTTP 1.1 (W3C ETag). ETag is used to assign each page unique identifier, the value of which changes when the page (document) changes. ETag is a hash (“fingerprint”) of the bytes of the document; if even one byte in the document changes, then the ETag will change. ETag is used when caching a document. This header is stored on the client, and in case of repeated access to the document, it allows the browser to contact the server with an 'If-None-Match' request, and the server must determine by the value of the ETag tag whether the document (page) has changed, and if not, respond with the code '304 Not Modified'.

      Parameter Expires(expiration)(W3C Expires) - it tells the browser what time period it can assume that the copy of the page in the cache is fresh, and not contact the server with requests at all. This is convenient for files that you know for sure will not change for the next hour/day/month: background picture pages, for example.

    Other HTTP headers:

      HTTP_X_FORWARDED_FOR

      HTTP_X_FORWARDED

      HTTP_FORWARDED_FOR

    • HTTP_X_COMING_FROM

      HTTP_COMING_FROM

    • HTTP_X_CLUSTER_CLIENT_IP

    • HTTP_XROXY_CONNECTION

      HTTP_PROXY_CONNECTION

      HTTP_USERAGENT_VIA - proxy

    Example of HTTP request analysis

    An HTTP request consists of three parts: a request (response) line, a header section, followed by an optional body. Headers are plain text, with each header separated from the next by a newline character (\r\n), while the body can be either text or binary data. The body is separated from the headers by two newlines.

    The request header consists of the main (first) line of the request and subsequent lines that clarify the request in main line. Subsequent lines may also be missing.

    The client initiates a transaction as follows:

      The client establishes a connection with the server using the assigned port number, official number The default port is 80. The client then sends a document request, specifying the method, document address, and HTTP version number. For example, in the main request line GET /index.html HTTP/1.1

      The GET method is used to request the index.html document using HTTP version 1.1.

      The client sends header information (optional; the host header is required) to tell the server its configuration information and information about the document formats it can accept. All header information is listed line by line, with each line containing a name and value. For example, the following header sent by a client contains its name and version number, as well as information about some of the client's preferred document types: Host: list.mail.ru User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv :8.0) Gecko/20100101 Firefox/8.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

      The header ends with an empty line.

      Having sent a request and headers, the client can send additional data, for example, for CGI scripts.

    The server responds to the client request as follows:

      The first part of the server response is the status line, which contains three fields: HTTP version, status code, and description. The version field contains the HTTP version number that this server uses to send the response. The status code is a three-digit number indicating the result of the server processing the client request. The description that follows the status code is simply human readable text that explains the status code. For example, HTTP/1.1 status bar 304 Not Modified

      indicates that the server uses HTTP version 1.1 to respond. Status code 304 means that the client requested the document using the GET method, used the If-Modified-Since or If-None-Match header, and the document has not changed since the specified moment.

      After the status line, the server sends header information to the client containing information about the server itself and the requested document. Below is an example header: Date: Thu, 15 Dec 2011 09:34:15 GMT Server: Apache/2.2.21 (Debian) X-Powered-By: PHP/5.3.8-1+b1 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip Keep- Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8

      The header ends with an empty line.

      If the client's request is successful, then the requested data is sent. This could be a copy of a file or the result of a CGI program. If the client's request cannot be satisfied, additional data is transmitted in the form of a user-friendly explanation of the reasons why the server was unable to fulfill the request.

    HTTP status code

    HTTP status code is part of the first line of the server response. It is a three-digit integer. The first digit indicates the class of the condition. The response code is usually followed by an explanatory phrase separated by a space. English, which explains to the person the reason for this particular answer.

    The client may not know all status codes, but it must respond according to the class of the code. There are currently five classes of status codes:

      1xx: Informational. Informational status codes that tell the client that the server is in the process of processing a request. The client's reaction to these codes is not required;

      2xx: Success.

      1. 200 OK(Fine). Introduced in HTTP/1.0. Successful resource request. If the client requested any data, it is found in the header and/or body of the message.

      3xx: Redirection. Class 3xx codes tell the client that a different request (usually to a different URI) must be made for the operation to succeed. Of this class, five codes 301, 302, 303, 305 and 307 relate directly to redirects (redirect). The address to which the client should make the request is indicated by the server in the Location header. Many clients, when redirecting with codes 301 and 302, mistakenly apply the GET method to the second resource, despite the fact that the request to the first was with a different method. To avoid misunderstandings, in version HTTP/1.1 codes 303 and 307 were introduced instead of 302. You need to change the request method only if the server responded with 303. In other cases, make the next request using the original method.

      1. 302 Found(Found). Introduced in HTTP/1.0. The requested document is temporarily available at a different URI specified in the header in the Location field.

      4xx: Client Error. The 4xx code class is intended to indicate errors on the client side. When using all methods except HEAD, the server must return a hypertext explanation to the user in the body of the message.

      1. 404 Not Found(Not found). Introduced in HTTP/1.0. The server understood the request, but did not find a corresponding resource at the specified URI.

      5xx: Server Error(Server error)

    HTTP 1.1 Related Links

    HTTP/2

    HTTP/2 (originally HTTP/2.0) is the second major version of the HTTP network protocol. The protocol is based on SPDY (HTTP compatible protocol developed by Google).

    The HTTP/2 protocol is binary. Compared to the previous standard, the methods of breaking data into fragments and transporting them between the server and client have been changed.

    In HTTP/2, the server has the right to send content that has not yet been requested by the client. This will allow the server to immediately send additional files, which the browser will need to display pages, without the browser having to parse the main page and request the necessary additions.

An HTTP request, or message, consists of three parts: the query line, and the body of the HTTP message.

Query string, or start line: in a request to the server, a line that contains the type of request (method), URI of the requested page, and version (for example HTTP/1.1). In the response from the server, this line contains the HTTP protocol version and the response code. The response code is a three-digit integer. It is usually followed by a space-separated explanatory phrase that explains the code, for example: 200 OK, or 404 Not Found.

HTTP request methods (types): GET, POST, PUT, PATCH, HEAD, DELETE, TRACE. Most often, the GET or POST methods are used in an HTTP request: GET is used to request the content of a web page at the specified URI. URI is the address of the page without specifying , for example: /internet/chto-takoe-http-zapros-soobshhenie/ instead of site/internet/chto-takoe-http-zapros-soobshhenie/. The browser can pass parameters in a GET in the URI after the "? ": GET /index.php?param1=value1¶m2=value2. Except conventional method GET, there are also conditional GET and partial GET. Conditional GET requests contain If-Modified-Since , If-Match , If-Range and similar headers.

POST - used to send information to . When sending data using the POST method, it is indicated in the body of the HTTP message, and not in the address input line in the browser, as is done when sending data using the GET method. For example, when sending a comment through the form located under the article, information is transmitted to the server using the POST method. Files are also uploaded to the server using the POST method.

- this is part of the request, which contains various parameters that are used to correctly build the web page.

HTTP message body— contains data received from the server, for example a generated web page in the form of HTML code, or a resource, for example a picture.

Example HTTP messages:

HTTP request to the server:

GET /internet/chto-takoe-http-zapros-soobshhenie/ HTTP/1..9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 ( KHTML, like Gecko) Chrome/40.0.2150.0 Accept-Encoding: gzip, deflate, sdch Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: wp- settings-1=hidetb%3D; wp-settings-time-1=1424958215; wordpress_test_cookie=WP+Cookie;

Response from the server:

HTTP/1.1 200 OK - response start line: Server: nginx/1.6.2 Date: Sun, 19 Apr 2015 00:22:50 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 9431 Connection: keep-alive Keep-Alive: timeout=30 X-Powered-By: PHP/5.5.22 Expires: Wed, 11 Jan 1984 05:00:00 GMT Cache-Control: no-cache, must-revalidate, max-age=0 Pragma: no-cache Vary: Accept-Encoding Content-Encoding: gzip The response body (html page) follows.

If you wanted to know how data is transferred on the Internet, this article is for you. I will tell you everything I know about the HTTP and HTTPS protocols, show the difference and differences between them. Happy reading!

HTTP 1.1 - what is this protocol?

HTTP (English: Hypertext Transfer Protocol) - network protocol top level for transmitting hypertext and arbitrary data on the Internet.

At HTTP help the browser receives data from web servers and can display it in a form that is acceptable and understandable to Internet users. The reverse process occurs in exactly the same way - sending user data back to the server (for example, during registration).

Content sent from and to the server can be presented in any form: pictures, files, documents, links and code - in any case, it is thanks to HTTP that people can use the Internet and load hundreds of web pages in the browser.

Current version protocol - 1.1. Its description is in the RFC specification.

HTTP is used in the client-server data transfer infrastructure. How does this work? The application on the “client” side generates a request for processing on the “server” side, after which the response is sent back to the “client”. The “client” can then initiate additional requests and receive new responses. And so on.

The most common “client” application is a web browser through which web resources are accessed. With development mobile technologies more browsers have been added mobile applications on a variety of smartphones and tablets. Moreover, the server side of modern multidisciplinary applications can simultaneously process data from both the browser and the smartphone. All this is done via the HTTP protocol.

Moreover, HTTP often acts as a transport protocol for transferring other application protocols and their APIs: WebDAV, XML-RPC, REST, SOAP. Well, the data transmitted via the API can have the most different format: XML, JSON and others.

How is this data transmitted? Most often over a TCP/IP connection: the client application uses TCP port 80 by default, and the server can use any other, but usually this is also port 80.

An HTTP manipulation object is a resource specified in the request URI of a client application to correctly identify “what is actually needed.” Typically these are files, data or logical objects that are stored on a server. In this case, the request can indicate exactly how to present the same data: which format, encoding, language to choose. This “feature” allows you to exchange not only hypertext, but also binary data.

The second feature of HTTP is that it does not save state between successive request-response pairs. But this is not a problem because application components on the client or server side can themselves store information about the state of the latest requests and responses. On the client side, such information is called cookies, on the server side - sessions.

At the same time, it is not a problem for the client browser to monitor the server response delay, and for the server it is not a problem to store the headers of the latest requests and client IP addresses. But, I emphasize once again, the protocol itself knows nothing about this - it only transmits data.

Intermediaries (proxy servers) can also take part in data transfer in order to distinguish proxies from end servers (the so-called “source server”).

The real magic begins when the same program (client or server) can perform the functions of an intermediary, a client, or a server - depending on the tasks.

HTTP/2 - what kind of protocol is this?

The original version of the HTTP protocol appeared at CERN in 1991. Already in 1992, the public version of HTTP 0.9 and its specification were published, thanks to which the rules of interaction between client and server applications, as well as a clear delineation of functionality.

HTTP/1.0 appeared in 1996, and modern version protocol - HTTP/1.1 - in 1999. At the turn of the millennium, the HTTP protocol learned to support persistent connection mode, i.e. leave the connection open after a response to a request has been received. This made it possible to send several requests at once in one connection, rather than opening and closing the session every time.

Time passed and as the Internet developed, the size of pages increased, the number of requests grew - more and more resources were required. This is how the need for a new protocol arose.

And sixteen years later, in 2015, the final version of the draft specification for the next version of the protocol, HTTP/2, was published. The binary protocol HTTP/2 is more prepared for modern realities than its predecessor HTTP 1.1 because the new protocol solves the most significant problem of data transfer on the Internet - multiple open connections.

And all because current sites load a lot of elements, both from their server and from the CDN: JS scripts, CSS styles, fonts and images. When transferring complete set files using the HTTP 1.1 protocol, multiple connections are created. If in the future we switch to the HTTP/2 protocol, the transfer will occur within a single connection between the client and the server, which will significantly speed up and optimize the loading of site content.

Key features of HTTP/2 that will be useful for websites:

  • Arranging and managing priorities of requests/flows - the client independently sets the priority of resources and data for the server
  • HTTP header compression;
  • Request multiplexing or parallel loading of several site elements over a TCP connection - several requests are sent through one connection, and the client can receive responses in any order, i.e. now you don't need several open TCP connections;
  • Availability and support from the server of proactive push notifications - the server can independently send data to the client that the client has not yet requested (for example, based on information about which page the user will open after this one).

Of course, the main thing here is stream multiplexing. The principle of operation is easy to explain: TCP/IP connection packets are mixed within one connection. Thus, in mixed mode, several “data cars” are connected into one “train”, which are separated “upon arrival”. Previously, the “cars” were forced to travel longer and separately, but now they will travel together and faster.

The above advantages of the HTTP/2 protocol will allow web developers to breathe deeply and abandon such “crutches” as:

  • Usage more related domains to ensure installation large quantity TCP/IP connections (for downloading files);
  • Image sprites - when images are combined into one file to reduce the number of requests to the web server (and the file itself “bloats” because more images are written to it);
  • Combining CSS and JS files, which are also made to reduce requests.

Latest obvious advantage The problem is that you don’t need to do anything additional with the site itself (to enable HTTP/2) - all work is carried out on the server in almost “1 click”, and for clients of shared and VPS hosting it will generally go unnoticed.

In a word, we will live!

HTTP/2 was created and developed based on the draft SPDY/3 protocol (Google) and surpassed it - Google recognized the advantages of HTTP/2 as more promising and will abandon support for SPDY/2 in the future.

The predicted acceleration of server response via HTTP/2 protocol will be about 30%, - real tests have already shown speeds 19-23% higher and this is not the limit.

According to the results of tests by Airi.rf, the speed increase from just enabling the HTTP/2 protocol is 13-18% (without optimization). Why is this important?

Despite the fact that the site does not support the HTTP/2 protocol at the moment does not directly affect the ranking of sites in Google and Yandex; positions in search results are affected by loading speed. And since the protocol shows more high speed downloads (which is a fairly significant factor), it indirectly affects rankings.

Primarily due to behavioral factors. Loading acceleration allows users to be less tired and more focused on exploring the site: view more pages and not leave the site due to long loading time(failures are reduced).

Most modern browsers already support HTTP/2 - ~70% of Internet traffic passes through them:

  • Chrome 41-52 and Chrome 46+ on Android;
  • Firefox 36-48 and Firefox 41+ on Android;
  • Opera 28-34 and Opera 30+ on Android;
  • Safari 9 and Safari in iOS 9.1;
  • IE 11 on Windows 10 and Edge browser 12, 13.

It is not yet clear when a full transition to HTTP/2 will occur - most likely in the very near future. The main thing is that no one is going to hastily abandon HTTP/1.x. As they say: “If it works, don’t touch it.”

What does the HTTPS protocol mean and where is it used?

Well, you already know everything about data exchange using the HTTP protocol: any data transfer is carried out through requests using this transport protocol. Why then do we need HTTPS and what is it? After all, we lived normally without him?

The problem is that data via HTTP is not protected and is transmitted to open form. Internet - global distributed network nodes And if you transmit open data via an unsecured protocol (Wi-Fi in a shopping center also applies here), then one of these nodes can intercept it.

Not on purpose, of course, it could just be hacking by criminals. HTTPS was created to ensure that the connection is secure and the data is transmitted in encrypted form using the SSL/TLS cryptographic protocol. This is a special “wrapper” on top of HTTP; it encrypts data, making it inaccessible to attackers and strangers.

HTTPS - English " secure protocol hypertext transmission."

So, unlike the default port 80 in HTTP, HTTPS uses TCP port 443 and has an encryption key. The key can be 40, 56, 128 or 256 bits long; a sufficient level of security currently starts with 128-bit keys.

Now all browsers support HTTPS - it is turned on automatically when possible and the server requires it.

It is vital to use HTTPS in the following services:

  • Electronic payment systems (banks, electronic money, etc.);
  • Services that receive and send private information and personal data, for example, Yandex has: Passport, Taxi, Direct, Metrica, Mail, Money, Webmaster and others;
  • Social media And personal accounts in Internet services;
  • Search engines.

HTTPS works simply. I'll explain with an example.

you put important information(login, password, card details, personal data) into a cell, “lock it with a key”: the cell encrypts your data using this key.

Now send it by mail to the addressee. The addressee receives the parcel cell, but cannot open it - he does not have the key. Then he locks (encrypts) the cell with a second lock and returns the parcel back to you. You receive a package with two locks, but you have the key to one. Now you can unlock your lock (decrypt the data) and send the package back again to the original recipient.

At the same time, the data remains protected - after all, it has not been viewed or changed by anyone and until it is received by the recipient, it is protected by an encrypted key. The addressee receives the parcel, already with one lock, decrypts it and processes your data. For example, it carries out your transaction.

That's it - that's how HTTPS works.

The trick here is that during the first such exchange, the encryption key is exchanged so that it is known to both final recipients, but not known to any of the nodes along the data route. After exchanging the cipher, you can freely exchange messages (encrypted) without fear of interception of this data, because without the cipher key it will not be possible to open and read it.

The only caveat here is that you need to know that you are sending the data exactly where it is needed. And that the final point is the destination. But you need to confirm and know for sure that the final destination exists and is controlled by the very server where the data is sent.

To do this, servers receive special HTTPS security certificates from certification centers, which confirm the “finality” of the destination (that the site is not a node transmitting data further) and the functionality of SSL/TLS encryption technology, i.e. connection security.

And here's what the certificate itself looks like:

Currently HTTPS is built into everything modern browsers and all that is required from the user to maintain the security of sending data via HTTPS is to regularly update the software for surfing, receiving and sending important data on the Internet.

Carrying out client-server interaction via HTTPS protocol you don’t have to worry about the safety of your data - you are reliably protected from eavesdropping network connection: sniffer attacks and man-in-the-middle.

What does the crossed out HTTPS icon and the green HTTPS icon mean, what is the difference? Safe. Green is safe, red and crossed out are unsafe.

And it is very convenient that the crossed out HTTPS icon means that despite the use of this protocol, the connection is not secure. This happens when site elements are not loaded via HTTPS or the certificate has expired. The user can immediately see - yeah, it’s unsafe. And he can leave the site, or risk his data.

Which is better HTTP 1.1, HTTP/2 or HTTPS?

To summarize, I will touch on the topic of preferable use of protocols.

It is clear that at the moment HTTP 1.1 is the most common protocol and is used by default. The time for HTTP/2 has not yet come, but soon most Internet traffic will go through the second version of the HTTP protocol. This will make life easier for users because sites will load faster. Server and website administrators will also be happy, because the new protocol allows you to optimize websites in a new way, speeding up the loading and uploading of data.

That being said, it is hardly possible that all sites will switch to HTTPS, because for consumption purposes entertainment content encryption is useless. Yes, now 10% of sites use HTTPS in the Alexa ranking of the most visited web resources. But this is only ten percent, including such giants as Google, PayPal, Amazon, Aliexpress and others. That is, there are many sites where not using HTTPS means violating the Internet user’s right to security and integrity of data.

But ordinary sites like the blog of seven bloggers do not need HTTPS - there is no reception of personal or payment data, no registration and sending important messages.

So in the near future we will gradually move away from HTTP 1.1 in favor of HTTP/2 and HTTPS.

The response format is very similar to the request format: it also has a header and body separated by an empty line.

The header also consists of a main line and parameter lines, but the format of the main line is different from that of the request header.

The main query string consists of 3 fields separated by spaces:

Protocol version- similar to the corresponding request parameter.

Error code- code designation of the “success” of the request. Code 200 means "everything is normal" (OK).

Verbal description of the error- “deciphering” the previous code. For example, for 200 it is OK, for 500 - Internal Server Error.

The most common http response parameters:

Connection- similar to the corresponding request parameter.
If the server does not support Keep-Alive (there are some), then the Connection value in the response is always close.

Therefore, in my opinion, the correct browser tactic is the following:
1. issue Connection: Keep-Alive in the request;
2. The connection status can be judged by the Connection field in the response.

Content-Type(“content type”) - contains a designation of the content type of the response.

Depending on the Content-Type value, the browser interprets the response as an HTML page, gif picture or jpeg, as a file to be saved to disk, or whatever, and takes appropriate action. The Content-Type value for the browser is the same as the file extension value for Windows.

Some content types:

text/html - text in HTML format(web page);
text/plain - plain text (similar to Notepad);
image/jpeg - picture in JPEG format;
image/gif - the same, in GIF format;
application/octet-stream - a stream of "octets" (i.e. just bytes) to write to disk.

There are actually many more types of content.

Content-Length("content length") - the length of the response content in bytes.

Last-Modified(“Last modified”) - the date the document was last modified.