School recruitment front-end interview frequently asked questions [4] - network and browser
Written in front:
All the interview questions have been sorted out and shared on GitHub. Welcome to star.
Address: https://github.com/shadowings-zy/front-end-school-recruitment-question
1. Network related
Q: Please briefly describe the HTTP protocol and the difference between HTTP1.0/1.1/2.0/3.0?
HTTP protocol: Hypertext Transfer Protocol, which uses TCP/IP protocol to transmit data. It is an application layer protocol.
HTTP1.0: HTTP 1.0 stipulates that the browser and the server only maintain a short connection. Each request of the browser needs to establish a TCP connection with the server, and the server immediately disconnects the TCP connection after completing the request processing. Past requests are not logged. Therefore, HTTP 1.0 has a big performance defect - when accessing a web page that contains many resource files, each request and response needs to establish a separate connection, and each connection only transmits a document and image, completely between requests separate. Even if the image files are very small, it is a relatively time-consuming process for the client and the server to establish and close the connection every time, which will seriously affect the performance.
HTTP 1.1: HTTP protocol that supports long connections, and multiple HTTP requests and responses can be transmitted on one TCP connection. Multiple requests and responses for a web file containing many images can be transmitted in one connection, but each individual web file request and response still needs to use its own connection.
HTTP2.0: HTTP protocol that supports multiplexing. HTTP 2.0 allows multiple request-response messages to be sent simultaneously over a single HTTP 2.0 connection. All communication is done over a single connection, which can carry any number of bidirectional data streams. Due to the slow start feature of TCP, if there are many HTTP connections, it will be very inefficient. HTTP/2 makes more efficient use of TCP connections by allowing all data streams to share the same connection.
HTTP3.0: also known as the QUIC (quick udp internet connection) protocol, is a protocol proposed by Google that uses udp for multiple concurrent transmissions. By using the UDP protocol, the TCP handshake and slow start time are omitted, and the connection establishment delay is extremely low.
Q: Please briefly describe the HTTPS protocol?
Before HTTPS transmits data, a handshake is required between the client and the server. During the handshake, the password information for the encrypted transmission data of both parties will be established. The TLS/SSL protocol is not just a set of encrypted transmission protocols, TLS/SSL uses asymmetric encryption, symmetric encryption and HASH algorithm.
A brief description of the handshake process is as follows:
1. The client sends the encryption rules it supports to the server.
2. The website selects the encryption algorithm and HASH algorithm, and sends the certificate back to the browser. The certificate contains information such as the website address, the encrypted public key, and the issuing authority of the certificate.
3. After obtaining the certificate, the client needs to do the following:
a) Verify the certificate (whether the organization that issued the certificate is legal, whether the website address contained in the certificate is consistent with the address being visited, etc.).
b) If the verification is passed, the browser will generate a random number password and encrypt it with the public key provided in the certificate
c) Calculate the HASH of the handshake information, then encrypt the handshake information, and finally send all the information to the website.
4. After receiving the data sent by the browser, the website needs to do the following operations:
a) Use its own private key to decrypt the information and take out the password, use the password to decrypt the handshake message, and judge whether the HASH is consistent.
b) Calculate the HASH of the handshake, encrypt the handshake message with a password, and send it to the browser.
5. The browser decrypts and calculates the HASH of the handshake message. If it is consistent with the HASH sent by the server, the handshake process ends at this point, and all subsequent communication data will be encrypted by the random password generated by the previous browser.
Q: Please briefly describe the caching strategy in the HTTP protocol?
There are two caching strategies for HTTP: strong caching and negotiation caching.
Strong caching is controlled by the Expires and Cache-Control fields in the http header, which are used to indicate the cache time of resources. In a strong cache, normal refresh will ignore it, but it will not be cleared, and a forced refresh is required.
例如：
cache-control: max-age=691200 （HTTP 1.1）
expires: Fri, 14 Apr 2017 10:47:02 GMT （HTTP 1.0）
The negotiation cache mainly involves two header fields: E-Tag and Last-Modified. Every time the data is read, the customer order will communicate with the server, and the cache ID will be increased. When the server is requested for the first time, the server will return the resource, and return a cache identifier of the resource, which will be stored in the browser's cache database together. When the resource is requested for the second time, the browser will first send the cache ID to the server, and the server will judge whether the ID matches after getting the ID. If it does not match, it means that the resource has been updated, and the server will return the new data and the new cache ID together. to the browser; if the cache identifier matches, it means that the resource has not been updated, and returns 304, and the browser reads the data in the local cache server.
For example:
E-Tag: 123456abcd
Last-Modify: Thu,31 Dec 2037 23:59:59 GMT.
2. Browser related
Q: Please list the types of browser kernels you know?
Trident: IE6, IE7, IE8, IE9, IE10, 360 browser and Cheetah browser.
Gecko: firefox browser.
Blink: The opera browser.
Webkit: sarfari and chrome browsers.
Q: What threads are there in the browser kernel?
The kernel is mainly divided into five parts:
GUI rendering thread: Responsible for rendering browser interface, parsing HTML, CSS, building rendering tree, layout and drawing, etc. This thread executes when the interface needs to be redrawn or reflowed. Note that GUI rendering thread and JS engine thread are mutually exclusive,
JS engine thread: parse and execute javascript.
Event trigger thread: belongs to the browser rather than the JS engine, and is used to control the event loop.
Timer trigger thread: the thread where setInterval and setTimeout are located. The browser timing counter is not counted by the JavaScript engine, so it is timed and triggered by a separate thread (after the timing is completed, it is added to the event queue and executed after the JS engine is idle).
Asynchronous http request thread: After XMLHttpRequest is connected, a new thread request is opened through the browser. When a state change is detected, if a callback function is set, the asynchronous thread will generate a state change event, and then put this callback into the event queue , which is then executed by the JavaScript engine.
Q: Please briefly describe the rendering process of the browser?
After receiving the document, the rendering engine parses the HTML document to generate a DOM tree, parses the CSS file to generate a layout tree; at the same time executes the JavaScript code in the page; finally calculates the style according to the DOM tree and the layout tree to generate a rendering tree, rendering tree In , only the elements that will be displayed on the page and their style information will be included (such as the head element and the element whose display is hidden will not be included in the rendering tree); according to the layout of the rendering tree to calculate the layout of each element on the page s position;
Next, the rendering engine starts to paint, which is divided into several stages:
1. Draw each element of each layer according to the rendering tree.
2. Rasterize the drawn image (convert the nodes in the rendering tree into actual pixels on the screen)
3. Display on the screen.
The drawing of each layer is done by the browser; the final compositing is done by the GPU; and the rasterization process depends on the settings of the browser. Chrome enables GPU rasterization by default, otherwise it is done by the CPU.
Q: What steps does the browser take from inputting the request to rendering the page?
1. URL resolution
2. DNS query
3. TCP connection
4. Processing request
5. Accepting response
6. Rendering page
Q: What is the difference between localstorage and sessionstorage, and what are the usage scenarios?
localStorage: The life cycle is permanent, and the data in localStorage will not disappear after closing the page or browser. localStorage data never disappears unless actively deleted (only strings are stored).
sessionStorage: The life cycle is valid only in the current session. sessionStorage introduces the concept of a "browser window". sessionStorage is data that always exists in windows of the same origin. As long as the browser window is not closed, the data still exists even if the page is refreshed or another page of the same origin is entered. But sessionStorage will be destroyed after closing the browser window. At the same time, the same window and the same page are opened independently, and the sessionStorage is also different.
Instructions:
window.localStorage
window.sessionStorage
API：
setItem(key, value) // 保存数据，以键值对的方式储存信息。
getItem(key) // 获取数据，将键值传入，即可获取到对应的 value 值。
removeItem(key) // 删除单个数据，根据键值移除对应的信息。
clear() // 删除所有的数据
key(index) // 获取某个索引的 key