Network knowledge is something every front-end engineer should have. Many of you who work on the front end have not systematically studied computer networks and HTTP. In the absence of an overall knowledge system, there will be a feeling of answering questions one station at a time, each knowledge point roughly know the answer to the question, but always uncertain, more do not know what is going on. This paper systematically combs the network knowledge closely related to the front end. (This is a summary of my study, sorted out notes, and shared with you)

The code demonstrations in this article are organized inThe Beauty of Node.js ：

It’s the same old rule. Before learning, let’s test ourselves. I’ll sort out the knowledge and see what questions we need to master. Then we sum up the questions by connecting them together.

Will:

• What are the contents of HTTP packets?
• What are the important parts of the HTTP protocol header, the HTTP status code?
• HTTP Status code What are the status codes?
• What is strong caching? What is weak caching?
• What is the browser’s live caching mechanism? How do I set up HTTP caching?
• What HTTP methods do you know? What’s the difference between POST and PUT?
• How to compress data (ZLIB), Gzip? What is the scope of compression, and does the request header compress?
• Cross-domain, why does JS restrict cross-domain? How are cross-domains allowed?

Basis:

• What are the reasons that affect the speed of the network? What is the main cause of network packet loss?
• What are the five layers of reference models for network architecture? What is the relationship between them?
• We often hear about packets, segments (groups), datagrams, frames, and packets. What are the relationships between them?
• Ajax can send HTTP requests. How does it relate to HTTP?
• What problems did HTTP1.0 to HTTP1.1 solve?
• What are the features of HTTP2?
• Why does HTTP1.1 have queue head blocking?
• SSL and TLS relationship? How to implement THE HTTPS protocol?

Make up and expand :(update slowly)

• What are the commonly used transport layer protocols? What are the characteristics of TCP and UDP?
• Explain TCP’s three-way handshake and four-way wave?
• Why TCP may be the bottleneck of network communication? How to solve TCP queue head blocking?
• Why is Google’s new QUIC based on UDP?
• What are the new features and problems that QUIC solves?

It must be something related to the HTTP protocol that is most associated with front-end work. But without an Internet foundation, it’s like castles in the air. Unable to build a knowledge system. Therefore, this article will put the will and the foundation together, which is the content of chapter 1-5 of this article.

Make up and extend: To learn more about the next generation QUIC, you must understand how TCP and UDP work. That’s why there’s a secret tutorial here. Some commonly used extensions will also be covered in later chapters.

This article uses Node to demonstrate the code, which is available on Github. For those of you who don’t know much about Node, I’ve compiled all the code in this chapter into a node learning document. The Little Beauty of Node.js. There will be some exercises in each section to reinforce the review, and I will add them slowly.

1 Network Basics

Let’s start with question 1. When the browser visits www.jd.com, we all know that the browser sends an HTTP request to the server, and sends the request to the server. So let me just do a little rough analysis of what’s going on.

1.1 Packet Transfer

The browser generates an HTTP message (message) based on the HTTP protocol and splits the message into different groups (packets). Send to the route. Routes are cached and then forwarded to the next route based on the routing table until they reach the server.

Client --> Route --> Route....... ----> Routing --> ServerCopy the code

Why don’t we just send messages to the server, why do we have to subcontract?

First of all, routing is cached and then forwarded. If the entire packet is directly sent to the server, the routing memory requirements are very high. Another important concept is the bandwidth of the network, also known as the transmission rate over the link, which is determined by the amount of data that can be transmitted per unit of time. Not our physical distance, for example.

(1) Basic questions (from Pupil of Ali Technology)

Use a truck to transport n 1TB hard disks full of data and travel 1000km at 80km/h to deliver the data to the destination. How many hard disks must the truck transport for the transfer rate to exceed 1000Gbit/s? The problem can be reduced to two schemes transferring the same amount of data in the same amount of time. Truck time: 1000km ÷ 80Km = 12.5h The amount of data transmitted in the network in the same time: 12.5H * 3600s/h * 1000Gbit/s ÷ 8B /B = 5625000GB. So trucks need to transport the same amount of computation, 5625000GB ÷ 1000GB = 5625 pieces. Summary: Bandwidth: Transmission rate on the link (bit/ SEC, that is, BPS) Bit (bit) // 1 Byte = 8 bitCopy the code

Extension: So let’s analyze the delivery time now

There is now A 5Mbits packet, which is 1Mbps on broadband, sent from client C1 to server H2, through routers A and B. Ignore other influences. C1-- > A ----> B ---- H2 Delivery time of packet exchange C1-- > A: 5Mbits / 1Mbps = 5s A --> B: 5Mbits / 1Mbps = 5s B --> H2: 5Mbits / 1Mbps = 5s 15 seconds if the packet is divided into 5000 groups, each packet is 1bits. H1-- > A: 1bits / 1Mbps = 1ms When the first arrives at A, it takes 1ms for the second to set off. When the second arrives at A, the first arrives at B. When the 5000th arrives at A, the 4999th arrives at B, and the rest arrives. It's going to take 5s and when the 5,000th one gets to H2, it's going to take 5 seconds and 2 milliseconds. Summary: - Packet: M bits - Link broadband: R BPS - Number of routers: N - Packet Length: L bits - Packet exchange Delivery time: T = (N +1) x (M /R) - Packet exchange delivery time: T = M /R + nL/RCopy the code

Therefore, packet switching performs better than single packet interaction. The time taken is called the transmission delay

Transmission delay is the most important factor affecting network speed, so here are some other factors affecting network speed:

• Queue delay: for example, when the first packet arrives at A, it waits in many queues if several other clients have already arrived before it. The time spent in the queue is the queue delay.
• Node processing delay: After queuing, node A performs some processing on the packet. This processing time is called node processing delay, usually in milliseconds. The impact is very small.
• Propagation delay: After A starts, it takes A certain physical distance to propagate from A to B on the link, but the transmission speed is very fast, usually 0.7 times the speed of light, and the time used is called propagation delay.
• Packet loss: If multiple clients send data packets to node A at the same time, the subsequent data packets are discarded when the cache of node A is full. This is the main cause of lost bags.

Q: Now that we have a rough idea of the process, what exactly do we go through?

1.2 Network Architecture

Let’s start with the 70 percent reference model explained by OSI.

• Layering: We layer the network model according to different functions.
• Protocol: Different protocols are specified between different layers. Each layer complies with the network protocol of each layer to complete the function.
• Interfaces: Layers interact with each other through interfaces.

So this is also consistent with the modularity of our functions. Low-level functions define their interface apis, and you call the dependent function according to the function’s interface documentation, and then wait for it to handle it. In actual development, this is how we do it.

Each layer adds control information and constructs protocol data unit PUD through the protocol of this layer.

Application layer:

• The browser generates a packet header and body based on the HTTP protocol
• Encode, encrypt, and compress parallel messages.
• After the data is encapsulated, it is handed over to the next layer. We call the PUD of this layer message.

Transport layer:

• Packets are grouped on the browser side and reassembled on the server side.
• At the head of each group, it adds its own protocol information.
• The main functions of these protocol information are SAP addressing, connection control, flow control and error control
• After encapsulating the data, pass it to the next layer. We call this layer’s PUDS segments.

Network layer:

• The network layer takes each segment and adds its own protocol information based on the IP protocol
• The protocol information is used for logical addressing (IP address) routing and forwarding.
• After wrapping the data, we hand it to the next layer, which we call a datagram.

The link layer:

• The network layer takes each segment and adds its own protocol information based on the IP protocol
• The protocol information provides the following functions: physical address (MAC address), traffic control, error control, and access control.
• After encapsulating the data, we hand it over to the next layer, and we call this layer’s PUD frame.

The physical layer:

• The physical layer takes a frame and converts it into bits, which are bits, binary code.
• And then I’m going to represent those binaries in terms of their physical properties, like electrical signals.
• And then you hand it over to the physical medium

So now we know that every HTTP request sent is a request and a response to the application layer. The application layer only goes back and forth once. But the transport layer underneath it has to break up the packet into a bunch of packets and pass them to the next layer, which is the famous TCP triple link. Therefore, one request and response at the application layer may go through many links. Each package must definitely have each layer of protocol, can not have only the upper layer without the lower layer. When we talk about packets, it should be a segment (packet) that is processed into bits and then transmitted over a link.

You notice we didn’t talk about the presentation layer and the session layer, right? because

The application layer and transport layer will be covered in more detail later. Here we talk about the network layer, the link layer, the physical layer.

1.3 Link Layer and Physical Layer

As we know, the physical layer transmits bits over physical media. So the mainframe may be connected to multiple computers, so how does the binary code know which computer it is sending and which network cable it is using?

We know that the physical address (MAC address) to access the host is added at the link layer, so if the network cable is connected to multiple computers, it will be sent to each computer, converted back to the frame at the physical layer, and if it is not the MAC address of the target computer, it will not be processed. Until it finds the computer with the target Mac address. This is the MAC protocol.

1.4 Network Layer and Link Layer

So how does the link layer know the Mac address of the target machine?

At the network layer, we know the IP address to access the server. First, the operating system determines whether it is a local IP address, and if not, it sends it to the gateway. When the operating system is started, the DHCP protocol is configured with an IP address and the default gateway IP address 192.168.1.1. The operating system will broadcast. Who is 192.168.1.1? The gateway will answer it, I am, this is the Mac address. So we know the Mac address. The protocol by which this broadcast gets the Mac address is ARP.

A gateway is usually a router that knows how to get to an IP address. This is called a routing table. So it pulls the datagram out of the frame, and when it sees the IP you want to go to, it tells you which route you should go and which route to go to. The Mac address of that route is then written into the frame encapsulated at the link layer.

How does a route know what to do? Because routes talk to routes. The communication protocols are called routing protocols. OSPF and BGP are commonly used.

(Test 1) Optional layer 7 network protocol (from JINGdong autumn 2018)

What protocols can be used to access www.jd.com using a browser? A MAC B HTTP C SMTP D ARP E RTSP MAC and ARP are protocols used at the data link layer and the network layer. SMTP is a mail transfer protocol, and RTSP is a real-time stream transfer protocol. We don't need it when we visit www.jd.com.Copy the code

2 the application layer

2.1 Application Layer Protocols

The application layer is based on transport layer protocols. Common transport layer protocols are TCP and UDP.

• TCP based: HTTP (Hypertext Transfer Protocol),FTP (File Transfer Protocol),SMTP(Mail Transfer Protocol)
• Based on UDP: DNS (Domain name System) and more recently QUIC (Google’s Low latency Internet Transport Layer protocol)

The function of the application layer is to complete the client and server message exchange. If you want to complete the information exchange, you must know the location of the resource. How do we agree on the location of the resource?

2.2 URL: Uniform resource Locator

Grammar:

Protocol :// Username: password @subdomain name. Top-level domain name: port number/directory/file name. File suffix? Parameter = valueSign #

http://username:password@host:80/directory/file.html?query#ref
ftp://username:password@host:21/directory/file.html
news://news.newsgroup.com.hk
Copy the code

Note:

If the parameter has! , %, &, /,? ,=, and other non-Western European characters need encode method to preprocess URL

• Decode decode into a common string
• Encode MIME strings (Application/X-www-form-urlencoded MIME strings)

2.3 Code Demonstration

The function of the application layer is to complete the client and server message exchange.

• When the browser sends an HTTP request, the IP service and port are entered
• The port number that the server listens for and responds to when it receives a request

The code shows node creating a TCP server

And then we’re going to look over our shoulder and say, in the bottom left corner of our browser, is that waiting for a response because we haven’t returned any data yet, so let’s give it some data back.

We won’t worry about the details of TCP here, but we’ll cover them in the transport layer.

Question: Now that we have a general understanding of the application layer protocols, let’s go into the HTTP protocol

3 HTTP protocol:

The content of this section, but the front end of the skill, we must correspond to the code to knock out their own, see the effect

• HTTP is the Hypertext Transfer protocol, a transport protocol from the WWW browser to the local browser,
• HTTP protocol is constrained and normalized by requests from client to server and responses from server to client.

3.1 HTTP message

HTTP packet: The information used for HTTP communication is called HTTP packet.

• The packets on the Request end are called Request packets
• Response packets are called response packets

In the last video, we took the response packet as an example, and we said that you have to conform to the HTTP protocol rules, so what are the HTTP rules?

letResponseDataTpl = 'HTTP/1.1 200 OK Connection:keep-alive Date:${new Date()}
Content-Length: 12
Content-Type: text/plain

Hello world!
`;
Copy the code

• There must be empty lines between the packet header and the packet body (CR+LF: Enter + line feed).
• Header: Processing the information provided by the request and response (various information set above)
• Message body: all required resources are present (e.g. the returned text message is Hello World)

Packet header: There are four types according to the actual usage

• General header field: field used in both request and response packets
• Requse Header: indicates the Header used by the request packet
• Response Header: indicates the Header used in Response packets
• Entity Header: A field that contains information about the Entity

So in Chrome’s Network, the header will read:

• General
• Response Headers
• Requse Headers

The entity header fields are written into the request header and the response header. For get requests, the Parameters following the get request are displayed in the Query String Parameters

In the above TCP server, we found that it was very troublesome to write the response packet in accordance with the HTTP protocol format every time. Why didn’t we encapsulate it? Yes, so in the following example we use the packaged HTTP module.

Code demo: build HTTP server with Node

We see ‘content-type’ in the code, which specifies the format of the Content.

Question: Now you change the actual status code to 400 and find that the page is still accessible. This is what you and the backend order according to the standard, so what is the standard?

3.2 HTTP status Code

HTTP status code: describes the status of a request sent by a client to a server. Status code: consists of 3 digits and reason phrases such as (200 OK and 206 Partial Content)

The first digit represents the category:

-1XX: informational status code (the received request is being processed) -2XX: success status code (the request is successfully processed) -3XX: Redirection status code (additional operations need to be performed to complete the request) -4XX: client error status code (the server cannot process the request) -5XX: Server error status code (server processing request error)Copy the code

Therefore, the status code is a convention for the communication between the front and back ends. In principle, as long as you follow the definition of the status code category, you can change the status code defined by RFC2616 or create it yourself.

If you change your status from 200 to 400, it’s like if you change your red light to green, old drivers get confused. Now let’s take a look at some of the most popular status codes for older drivers.

OK - 200: -206 Partial Content: The request was successfully processed but No resource was returned. -206 Partial Content: The request was successfully processed but No resource was returned. -301 Moved Permanently: Permanently redirected (the URL of the resource has been updated) -302 Found: temporarily redirected (the URI of the resource has been temporarily located to another location) -303 See -304 Not Modified: The client sends a conditional request and the server allows the request to access the resource but the condition is Not met. -307 Temporary Redirect: -400 Bad Request: a syntax error exists in the Request packet. -401 Unauthorized: HTTP authentication is required. -403 Forbidden: -404 Not Found: The resource is Not Found on the Server. -500 Internal Server Error: The Server fails to execute the request. -503 Service Unavailable: The server is overloaded and is being shut down for maintenanceCopy the code

Code demonstration: with the URL path module, complete the Node route

(Quiz 3) Single choice HTTP status code (from Pupil of Ali Technology)

If the HTTP status code of a static resource is ___, you need to forcibly refresh it to obtain the latest version of the static resource. A 204 B 304 C 403 D 501 A 304 B 304 C 403 D 501 A 304 C 403 D 501Copy the code

Question: We know what status codes mean, but under what circumstances do they appear? Let’s study one by one

3.2 HTTP Compression Protocol

HTTP compression protocol is easy to understand, just like you want to upload a 1G file to your friend on QQ, it takes 10 minutes, wow, the Internet speed is so fast. But if you compress it, the file becomes 300M. It might take three minutes to send it to your friend. Then you compress it in a minute, he decompresses it in a minute. So you’ll be done in five minutes. Same idea.

• HTTP request headers: accept-encoding: gzip, deflate, br

This is where the browser tells the server what compression formats I support and what the priority is.

• HTTP response header: Content-encoding: gzip

This is the server to tell the browser I have been compressed by what format, decompression work you please

In the browser, we need to determine what compression is supported based on the accept-encoding in the request header. And then I compress it and tell the browser what I’ve compressed for you.

Code demo: 2.5 use gzip to compress the file

3.3 HTTP Cache Protocol

3.3.1 strong cache

Catche Contrl: : is the generic header field, which is used by both the sending and response packets. You can set the cache of referenced resources in a file

Here’s a simple example:

Visit http://localhost:10080/ -'Request message without cache-control'The client says I want to access the home page server to return data -'Response packet: cache-control: max-age = 604800'The server says to give you index.html and load the resources in it, and tells you not to revisit http://localhost:10080/ for a week without confirming that the browser has refreshed the page - the resources in it will no longer be requested and will be taken directly from the cache You'll see in Chrome, Network that Time is 0(from memory catch). The server returns data - the server only returns the index.html file and you force the browser to refresh.command+shift+R) 
  -       'Request message with Catche Contrl: no-cache'The client says I don't want cached data, I want the data from the source server the server returns the data - the server returns the index.html file and the dependent resourcesCopy the code

This is called strong caching. Strong caching means that the resources on which your web page depends will not send HTTP requests. You can take it directly from the web.

Code demo: browser cache protocol implementation

3.3.2 Negotiating cache

There are two:

First: if-modified-since/last-modified

The server sends a last-modified time. The browser then remembers this time. An if-modified-since time is added when the browser requests it a second time. The server can compare whether the file has been modified since if-modified-since. If not, return 304.

• Last-modified: Indicates when the response resource was Last Modified. When the Web server responds to a request, it tells the browser when the resource was last modified.
• If-modified-since: When a resource expires (using the max-age identified by cache-control) and the resource is found to have a last-Modified statement, a request to the Web server is made with If- -modified-since, indicating the request time. When the Web server receives the request, it finds the if-modified-since header and compares it with the last modification time of the requested resource. If the last modification time is relatively new, indicating that the resource has been changed again, then the entire resource content (written in the response message package), HTTP 200; If the last modification time is old, it indicates that the resource has not been modified. In this case, HTTP 304 is used to inform the browser to continue using the saved cache.

Code demo: browser cache protocol implementation

In the above code our server does not implement to record file modification time, we just take a period of time to compare. We know that with if-modified-since, the server records the modification time of the file one at a time. So it’s not a good time to judge.

Second: Etag/ if-none-match

The server Etag will issue a string, which the browser will then carry in if-none-match on the second request. The server can compare the two strings, and if they are the same, tell the browser to fetch them from the cache.

• Etag: A unique identifier that tells the browser that the current resource is on the server when the Web server responds to a request (generation rules are determined by the server)
• If-none-match: When the resource expires (using the max-age identified by cache-control) and the resource is found to have an Etage statement, the web server requests the resource again with if-none-match (the Etag value). If the web server receives the request and finds the if-none-match header, it compares it with the corresponding checksum string of the requested resource and returns either 200 or 304.

Code demo: browser cache protocol implementation

So now that you’ve learned about both caches, you might ask, if there’s both, how does the browser know?

3.3.3 Browser Caching Mechanism

So you can see that strong caching takes precedence over negotiated caching.

(Problem 4) HTTP cache (from JD.com 2018 autumn recruitment questions)

Which of the following protocol headers are used by the browser caching mechanism in HTTP requests? A. Last B. Last C. Last D. LastCopy the code

3.4 HTTP methods

There seems to be a lot of debate these days about the difference between post and GET. Since these are application-level protocols, let’s get back to the basics. Let’s take a look at the HTTP methods and the differences between POST and GET.

3.4.1 track HTTP methods

• GET: Obtains resources
• POST: transmits the entity body
• PUT: transfers files
• HEAD: obtains the packet HEAD
• DELETE: deletes a file
• OPTIONS: query supported methods
• TRACK: Tracks the path
• CONNECT: The tunnel protocol is required to CONNECT to the agent

3.4.2 Differences between GET and POST

Does the protocol define the behavior and agreement of both parties at the application layer? So let’s look at the browser and the server separately.

Browser:

• GET is a request for data, passing parameters using a URL or Cookie. POST is the transfer entity body so it puts the parameters in the message
• GET data is placed in the URL. The browser limits the URL size, so the data size is limited. POST is the transfer entity body, so there is no limit to its size
• GET data is stored in the URL, so it can’t be used to pass sensitive information. POST is relatively safe
• GET requests data so the URL can be backed up, whereas POST sends data not.
• GET is a request so it will be actively cached by the browser, while POST is sending data so it won’t be unless set manually.

Server:

• Get puts parameters into the URL for processing
• Post triggers a request event that the server listens for, and the server may process it, affecting the return result

If it is not understood here, it is recommended to take a look at this section of the actual code: 2.6 browser caching protocol implementation

Now that you’ve seen how the service responds, do you understand the following sentence?

“The main difference between GET and POST is that GET requests are idempotent, whereas POST requests are not. Idempotent means that one and multiple requests for a resource should have the same side effects. This simply means that multiple requests to the same URL should return the same result.”

So many answers, I don’t know if you noticed. Everything the browser does is based on these two actions. So when do you use GET and when do you use POST?

According to the agreement to use ah, not to your provisions? Get is used when requesting data and POST is used when transferring entity bodies.

Problem: ha ha, learn this, you are not gradually understand, and find the reason that has been learning bad network, all blame browser too intelligence! Yes, modern browsers are very smart, so a lot of times, even if the code is not high quality, it can give you a good optimization. But we still need to be a qualified front-end engineer, so let’s get into the browser in the next section

4 Browser and Protocol

4.1 XHR with AJAX

AJAX is all too familiar to front-end engineers, as we know it’s used to send HTTP requests. So what does it have to do with HTTP? So let’s write an AJAX first.

• AJAX stands for Asynchronous JavaScript and XML. Asynchronous JS is easier for us to understand. So what is XHR.

• XHR stands for XMLHttpRequest, which is an HTTP request for XML. This is actually a browser-level API. In plain English, this is the HTTP function that the browser gives you wrapped.

In the previous lectures, we sent HTTP requests that the browser made voluntarily. If, the browser does not open such a feature. You certainly don’t have the ability to actively fetch data from the server. So there’s no interaction. This is why the solution is to refresh the page before AJAX.

So how do we understand XHR as a browser-level API?

• As we know from the Node server, we often need to manipulate the data in the request header, for example, according to the compression mechanism in the request header. But when we get the data on the front end using Ajax. Compression is not a concern, just because XHR is a browser-level API. It hides a lot of low-level processing from us, such as compression and caching. In other words, the browser doesn’t open up the ability to do these things.

• To sum up, it makes sense that our Web pages run on a browser, which is smart but generic, not customized for us. This is why webApps aren’t as smooth as native apps. The original app can be interpreted as (browser + page). Webapps are about writing content in the browser.

But browsers simply sending HTTP requests is not enough for our daily development needs. In order to achieve more functionality, we have long polling, and the browser also provides websocket API. This relates specifically to the functionality of the business scenario. Write a single essay sometime.

Q: We know that browsers have a lot of limitations, but what are the business implications?

4.2 Browser Security and Cross-domain

So we have a lot of restrictions on XHR, one of which has a big impact on us is that requests with different protocols, addresses and port numbers are not allowed.

There are three common solutions:

• Jsonp: Requests disguised as tags. Since tags are requested by the browser itself, they are not affected by the same origin policy
• Proxy server: This is also easy to understand, I send all requests to the non-cross-domain proxy server, but the server is fine, just process the data back to the browser.
• CORS: That’s what we’re going to talk about today. Since it is you who set the limit, you must give me a solution. The solution that the browser provides is CORS.

The cORS approach is also simple:

• If the browser finds that you have crossed domains it will send a request header with the original IP Origin: http://localhost:8088
• Do you want localhost:8088 to Access your file? If the browser agrees, reply with access-Control-allow-Origin: http://localhost:8088. This IP address is accessible
• The server then makes a formal request
• If the server does not return access-Control-allow-Origin to the browser or does not Allow Access to this address, the browser reports a cross-domain request error

Of course, CORS requests ignore user credentials such as cookies and HTTP authentication for security reasons. If you want to use it, also send some parameters when requesting the Origin header. The server also tells the browser to agree or disagree on the first return.

Code demo: 2.8 Node handles cross-domain

5 HTTP development

5.1 HTTP1.0 to http1.1

• With HTTP1.0, a TCP connection was established and then disconnected each time an HTTP request was sent

• Http1.1 introduced a Connection:keep-alive mechanism to continue sending requests
• But each request is the first to come back, the second to go. Pipelining connections have since been introduced in browsers.

• Within a TCP Connection, multiple HTTP requests can be made in parallel, and the next HTTP request is made before the previous HTTP request has been answered. This does not need to be set up. Connection:keep-alive is introduced, and the browser automatically handles this. There is a problem with this, however, because the HTTP1.1 server must return the response data in the same order as the client request, thus requiring first-in, first-out (FIFO). So it’s easy to get stuck at the head of the queue. If you don’t return your first request, you’ll have to wait for the rest of it.

So the point of this section is that HTTP2 solves the problem of queue head blocking. But HTTP2 is based on HTTPS, so let’s learn about HTTPS first

5.2 the HTTPS

HTTPS is an improvement on HTTP security. Let’s take a look at HTTP security

• Communication is plaintext
• Communication party identity is not verified
• Packet integrity could not be proved

** So HTTS = HTTP + encryption + authentication + integrity protection **

So now let’s look at how to encrypt and decrypt?

• Let’s say I have a piece of data for you, and ALL I have to do is encrypt it, and you’re decrypting it so it’s safe.

• So I have a private key for encryption, and the public key for decryption

• But at this point, there is no guarantee that someone else’s public key is my public key. If the data stays the same but the public key is hijacked, the decrypted content is not what I want to send to the other party

• So I submit the public key to a third-party CA for authentication, and the third party turns the public key into a certificate

• So when the browser gets the certificate I sent it, it goes to the third-party CA and asks if it’s his certificate.

• The third party said yes, so we’re safe.

• Similarly, the browser encrypts and decrypts the data sent to the server using the same private key and certificate. During the third party certification, we will register our information in detail. And so we have each other’s identities.

• Finally, the encryption algorithm also uses digests to ensure data integrity

We now know that data is encrypted and decrypted using a private key and certificate. Therefore, THE HTTPS protocol only replaces the HTTP communication interface with SSL protocol. And this is what SSL protocol is all about. It was invented by Netscape and later handed over to the IETF, which developed TLS (renamed TLS) on top of SSL.

Code demo: 3.1 HTTPS node server construction

5.2 HTTP2.0

Now we’re finally at http2. Remember what we said about http1.1 opponent blocking. Http2 solves this problem.

• (1) multiplexing does not follow fifO.

So there is a problem with http2, since there is no FIFO, so important files load slowly, that is not embarrassing.

• (2) Http2 defines the request priority

We can make some important requests load first. Browsers also intelligently display pages according to the priority rules defined by HTTP2.

• (3) head compression

We know that we are using Gzip to compress the text. Http2 also compresses the header. You can’t underestimate the packet header, the average web page packet header can account for 40% of the packet. After compression, it can be reduced by about 60%.

• (4) Added binary frame layer in performance. I got a big promotion. The minute – hand layer corresponds to HTTP packets. So HTTP /1.1 is a text protocol, while HTTP2 is a completely binary protocol.

Let’s do it now.

Finally, write very tired… I don’t think I can finish this one. It’s too rough in the back. I’ll change it slowly. You can write at your leisure.