What exactly happens when a user types google.com in the address bar? Part 2
Part 1
The client computer sends the ClientHello message to the server, where it indicates the TLS version, the list of encryption algorithms and the available compression methods. The server responds with a ServerHello message containing the same data, plus a public server certificate. The certificate contains the public key with which the client will encrypt the rest of the greeting. The client verifies that the certificate is signed by someone from the list of trusted CAs (Certificate Authority). If the check passes, the client creates a sequence of pseudo-random bytes and encrypts it with the server's public key. This sequence is used to create a symmetric key.
The server decrypts the sequence with its private key and creates its copy of the symmetric key on its basis. The client sends a Finished message, encrypting the hash of the entire transfer with a symmetric key. The server creates its own hash, and decrypts the hash from the client to verify them. If they are identical, it sends its Finished message, which is also encrypted with a symmetric key.
From this point on, the TLS session transmits data over HTTP protocol, encrypted with a symmetric key.
')
If the user uses a browser from Google, then instead of an HTTP request for the content of the page, they will be sent a request to upgrade the protocol from HTTP to SPDY. If the client does not support the HTTP protocol, it sends a request to the server in the form:
The remaining headers contain key-value pairs, separated by colons. Each pair is separated from the others by a newline character. If the client uses older protocols than HTTP / 1.1, then the request will not contain the Host header and the version in the first line will be different - 1.0 or 0.9
The HTTP / 1.1 protocol specifies the ability to close the connection after the end of the response. The headline looks like this:
If the client does not support persistent connections, it must include such a header in any request.
After sending the request and headers, the browser sends an empty string indicating the end of the request content. The server responds with a code indicating the status of the request, followed by the response headers:
They are followed by an empty line, after which the HTML content of the www.google.com page is thrown out to the client. The server then closes the connection, or leaves it open, depending on client requests.
If the HTTP request headers from the client contained information that can be used to determine that after saving the file in the browser's cache, it did not change on the server (for example, the browser included the ETag header), the server can respond like this:
and do not include the contents of the file. Then the browser loads the file from the cache.
After parsing HTML, the browser with the server repeats this procedure for each resource (images, style files, scripts, etc.) referenced from HTML. Only instead of the GET / HTTP / 1.1 request, it will indicate the path to the GET / $ file (URL relative to www.google.com ) HTTP / 1.1.
If HTML refers to a resource from a domain other than www.google.com , the browser repeats the steps from the moment the domain address is obtained. The Host header in the request will indicate the desired domain name instead of google.com
The HTTPD server (HTTP Daemon) handles requests on the server side. The most popular servers are Apache or nginx for Linux and IIS for Windows. When the server receives a request, it parses it according to the following parameters:
- HTTP request method (GET, POST, HEAD, PUT or DELETE). In our case it will be GET.
- domain, in our case google.com.
- path / page, in our case / (default path)
Server checks:
- the presence of a virtual host corresponding to the requested domain
- this domain accepts GET requests
- the client has the right to make such a request (possible restrictions on ip, authorization, etc.)
If the server has a path conversion module (ap_ for Apache or IIS for Rewrite URL), it tries to match the request to one of the specified rules. If a rule is found, the server converts the request according to it.
Then the server reads the file corresponding to the request. If, for example, Google is working in PHP, then the server uses PHP to interpret the index file, and gives the result of the interpretation to the client.
After the browser receives all the resources (HTML, CSS, JS, images, etc.), the browser parses text resources (HTML, CSS, JS), and launches the page render. For this, a DOM tree is built, then it is processed, the location of the elements is calculated and they are displayed on the screen.
The browser's function is to provide the selected web resource by requesting it from the server, and display it in the window. This is usually an HTML document, but it can be PDF, image and other content. The location of the resource is given by the universal URI.
The way the browser interprets and displays the HTML file is specified in the HTML and CSS specifications that are supported by the World Wide Web Consortium (W3C).
All browsers usually have:
- address bar to insert URI
- back and forth buttons
- ability to bookmark
- refresh and stop buttons
- home button
- user interface - buttons, address bar, menu. This is all, except for the main part of the window in which the page is visible.
- browser engine - handles the interaction of the UI and the render engine
- render engine - visually displays the requested content
- network part - HTTP requests, and so on
- interface backend - draws drop-down menus, windows and other elements. This interface is platform-independent, and its operation is provided by the user interface methods of the specific OS
- JavaScript interpreter - parses and executes code
- data storage - cookies and local storage (localStorage, IndexedDB, WebSQL and FileSystem).
The render engine receives the content of the requested document, usually in 8 KB chunks. The task of the parser is to turn the markup into a tree. The parser tree is a tree structure of DOM elements and nodes. The DOM, or Document Object Model, is the representation of an HTML document and its elements for other engines, for example, for JavaScript. Before processing scripts, DOM has an almost complete one-to-one correspondence with markup.
HTML cannot be parsed with regular parsers running from top to bottom or bottom to top. The markup is too liberal, browsers allow certain errors in the markup, and the work of scripts sometimes forces the parsing process to return to the places already passed. Because of this, the parsing process sometimes changes the input data. Details of the parsing algorithm are described in the HTML5 specification.
The browser requests external resources (CSS, images, JavaScript, etc.). At this stage, the document becomes interactive and scripts begin to be processed that are executed when the document is ready (deferred mode). Then the document status is set to complete and the load event is triggered.
Processing CSS files, tag contents
Tls handshake
The client computer sends the ClientHello message to the server, where it indicates the TLS version, the list of encryption algorithms and the available compression methods. The server responds with a ServerHello message containing the same data, plus a public server certificate. The certificate contains the public key with which the client will encrypt the rest of the greeting. The client verifies that the certificate is signed by someone from the list of trusted CAs (Certificate Authority). If the check passes, the client creates a sequence of pseudo-random bytes and encrypts it with the server's public key. This sequence is used to create a symmetric key.
The server decrypts the sequence with its private key and creates its copy of the symmetric key on its basis. The client sends a Finished message, encrypting the hash of the entire transfer with a symmetric key. The server creates its own hash, and decrypts the hash from the client to verify them. If they are identical, it sends its Finished message, which is also encrypted with a symmetric key.
From this point on, the TLS session transmits data over HTTP protocol, encrypted with a symmetric key.
')
HTTP protocol
If the user uses a browser from Google, then instead of an HTTP request for the content of the page, they will be sent a request to upgrade the protocol from HTTP to SPDY. If the client does not support the HTTP protocol, it sends a request to the server in the form:
GET / HTTP/1.1 Host: google.com Connection: close [ ] The remaining headers contain key-value pairs, separated by colons. Each pair is separated from the others by a newline character. If the client uses older protocols than HTTP / 1.1, then the request will not contain the Host header and the version in the first line will be different - 1.0 or 0.9
The HTTP / 1.1 protocol specifies the ability to close the connection after the end of the response. The headline looks like this:
Connection: close If the client does not support persistent connections, it must include such a header in any request.
After sending the request and headers, the browser sends an empty string indicating the end of the request content. The server responds with a code indicating the status of the request, followed by the response headers:
200 OK [ ] They are followed by an empty line, after which the HTML content of the www.google.com page is thrown out to the client. The server then closes the connection, or leaves it open, depending on client requests.
If the HTTP request headers from the client contained information that can be used to determine that after saving the file in the browser's cache, it did not change on the server (for example, the browser included the ETag header), the server can respond like this:
304 Not Modified [ ] and do not include the contents of the file. Then the browser loads the file from the cache.
After parsing HTML, the browser with the server repeats this procedure for each resource (images, style files, scripts, etc.) referenced from HTML. Only instead of the GET / HTTP / 1.1 request, it will indicate the path to the GET / $ file (URL relative to www.google.com ) HTTP / 1.1.
If HTML refers to a resource from a domain other than www.google.com , the browser repeats the steps from the moment the domain address is obtained. The Host header in the request will indicate the desired domain name instead of google.com
HTTP Server Request Handle
The HTTPD server (HTTP Daemon) handles requests on the server side. The most popular servers are Apache or nginx for Linux and IIS for Windows. When the server receives a request, it parses it according to the following parameters:
- HTTP request method (GET, POST, HEAD, PUT or DELETE). In our case it will be GET.
- domain, in our case google.com.
- path / page, in our case / (default path)
Server checks:
- the presence of a virtual host corresponding to the requested domain
- this domain accepts GET requests
- the client has the right to make such a request (possible restrictions on ip, authorization, etc.)
If the server has a path conversion module (ap_ for Apache or IIS for Rewrite URL), it tries to match the request to one of the specified rules. If a rule is found, the server converts the request according to it.
Then the server reads the file corresponding to the request. If, for example, Google is working in PHP, then the server uses PHP to interpret the index file, and gives the result of the interpretation to the client.
Behind the scenes of the browser
After the browser receives all the resources (HTML, CSS, JS, images, etc.), the browser parses text resources (HTML, CSS, JS), and launches the page render. For this, a DOM tree is built, then it is processed, the location of the elements is calculated and they are displayed on the screen.
Browser
The browser's function is to provide the selected web resource by requesting it from the server, and display it in the window. This is usually an HTML document, but it can be PDF, image and other content. The location of the resource is given by the universal URI.
The way the browser interprets and displays the HTML file is specified in the HTML and CSS specifications that are supported by the World Wide Web Consortium (W3C).
All browsers usually have:
- address bar to insert URI
- back and forth buttons
- ability to bookmark
- refresh and stop buttons
- home button
High-level browser structure
- user interface - buttons, address bar, menu. This is all, except for the main part of the window in which the page is visible.
- browser engine - handles the interaction of the UI and the render engine
- render engine - visually displays the requested content
- network part - HTTP requests, and so on
- interface backend - draws drop-down menus, windows and other elements. This interface is platform-independent, and its operation is provided by the user interface methods of the specific OS
- JavaScript interpreter - parses and executes code
- data storage - cookies and local storage (localStorage, IndexedDB, WebSQL and FileSystem).
HTML parsing (parser)
The render engine receives the content of the requested document, usually in 8 KB chunks. The task of the parser is to turn the markup into a tree. The parser tree is a tree structure of DOM elements and nodes. The DOM, or Document Object Model, is the representation of an HTML document and its elements for other engines, for example, for JavaScript. Before processing scripts, DOM has an almost complete one-to-one correspondence with markup.
Parser algorithm
HTML cannot be parsed with regular parsers running from top to bottom or bottom to top. The markup is too liberal, browsers allow certain errors in the markup, and the work of scripts sometimes forces the parsing process to return to the places already passed. Because of this, the parsing process sometimes changes the input data. Details of the parsing algorithm are described in the HTML5 specification.
At the end of parsing
The browser requests external resources (CSS, images, JavaScript, etc.). At this stage, the document becomes interactive and scripts begin to be processed that are executed when the document is ready (deferred mode). Then the document status is set to complete and the load event is triggered.
CSS Interpretation
Processing CSS files, tag contents
Source: https://habr.com/ru/post/251501/
All Articles