What exactly is HTTP
HTTP is a kind of Hypertext Transfer Protocol (Hypertext Transfer Protocol). How to understand the Hypertext Transfer Protocol is the first question to be discussed in this paper. The following three terms of Hypertext, transmission and Protocol are explained.
hypertext
Text is better understood as string. In the era when computers were just invented, network communication only transmitted strings. Later, with the development of technology, we are not only satisfied with the transmission and communication of strings, but also involved in the transmission of pictures, audio and video, typesetting (CSS), interactive behavior (JS) and other resources. When the text transmitted before is gradually enriched, the semantic of the text is enlarged. We call the enlarged text Hypertext.
transmission
The process of parsing the aforementioned hypertext into binary packets and sending them from one device to another via a carrier such as a network cable is called transmission.
agreement
Computers communicate with each other by following certain rules, which define how the requestor passes parameters and how the responder parses data. This is the network protocol.
We now know that HTTP (Hypertext Transfer Protocol) is the specific specification and convention for the transfer of text, pictures, audio and video content between multiple network devices. In addition to HTTP, common network protocols include email transfer protocol SMTP, file upload protocol FTP and domain name resolution protocol DNS.
How does an HTTP request complete communication
HTTP is a network communication protocol. In addition to HTTP, you must have heard of TCP/IP. TCP/IP is an integral part of HTTP communication.
Relationship between HTTP and TCP/IP
The reason why TCP/IP is an indispensable part of HTTP communication is that THE HTTP protocol itself does not have the capability of data transmission. HTTP is mainly responsible for the standard definition of the request response (such as packets) between the client and the server, and data transmission depends on TCP/IP. Therefore, you need to start with TCP/IP to understand HTTP.
TCP/IP
TCP/IP (Transmission Control Protocol/Internet Protocol) is used to transfer information and data between different networks. Although it is called TCP/IP, it is actually a Protocol family. Includes not only TCP and IP protocols, but also UDP, ICMP, ARP, etc. TCP and IP protocols are the two most core protocols, so they are referred to in the title.
The core idea of TCP/IP is layered management, which is divided into four layers: application layer, transport layer, network layer, and link layer. The advantage of layered design is that each layer is only responsible for its own tasks and does not need to consider the tasks of other layers. When each layer interacts, it only needs to call each other’s interfaces. Of course, it has disadvantages that each layer needs to transfer information from bottom to top when communicating with each other, which has certain impact on performance.
- Application layer: encryption, decryption, data formatting, domain name resolution, business oriented. HTTP, FTP, DNS
- Transport layer: Provides the ability to transfer data between two computers. TCP, UDP
- Network layer: Establishes and terminates network connections and searches for IP addresses. IP, ICMP, IPV6
- Link layer: The part of hardware that handles network connections.
HTTP
HTTP is a TCP/IP application layer protocol. HTTP is responsible for the standard definition of request responses (such as packets) between clients and servers.
FTP
FTP is a TCP/IP application layer protocol. FTP is a file transfer protocol used to distribute and share files between users.
DNS
We can locate a device through IP. When we open the IP address of Baidu http://202.108.22.5/, we open the home page of Baidu, but this IP address is undoubtedly anti-human and difficult to remember, so we have a domain name. So if we open http://www.baidu.com/, we can also open baidu’s home page.
The Domain Name System (DNS), as a distributed database that maps Domain names and IP addresses, makes it easier for people to access the Internet.
The DNS protocol is used to convert a domain name to an IP address, or an IP address to a domain name. Currently, each level of a domain name is limited to 63 characters, and the total length of a domain name cannot exceed 253 characters.
TCP
TCP (Transmission Control Protocol) is a TCP/IP transport layer protocol. TCP provides reliable byte stream transmission capability. Byte stream refers to the transmission management of large chunks of data by dividing them into packet segments for convenient transmission. Reliable indicates that TCP adopts the three-way handshake to ensure reliable data transmission. After sending a packet, THE TCP protocol does not ignore the situation after transmission. It must confirm whether the packet is successfully delivered to the other party. If there is an exception, the retransmission mechanism is enabled. HTTP uses the transport capabilities provided by TCP to communicate.
UDP
UDP (user datagram protocol) is a TCP/IP transport layer protocol, UDP also provides data transmission capacity, the UDP protocol defines the port, when after the packets to the host, you can find the corresponding application according to the port, the more simple, implementation is easy, but it has not confirmed mechanism, packet once issued, cannot know whether the other side received, Therefore, the reliability is poor. UDP is similar to TCP, but simpler and less reliable than TCP. UDP is fast and consumes less resources.
In other words the UDP just hair, regardless of the other party received, such as broadcast, video chat can use UDP, because this need to delay sexual requirement is very high, if use TCP for video chat, bad network packet loss serious when, the TCP will resend, this will lead to see picture may have been sent before each other for a minute, If I use UDP to do this, if I lose a packet when the network is bad, it will lose the packet, and it will not resend the packet, but will always send the latest data, so I can keep the picture I see in real time.
UDP another application scenario is DNS, DNS also use the UDP protocol, UDP protocol when a request, a response, and using the TCP protocol will shake hands three times four times to wave a further waste of network resources, based on the data level, DNS packet is not that big, so use UDP does not need to consider the subcontract, If the packet is lost then all the packet is lost, if the data is received then all the data is received, even if the packet is lost then it is good to request again.
IP
IP is a PROTOCOL at the TCP/IP network layer. IP uses IP addresses to locate each unique device on the Internet, and uses ARP to obtain the MAC address of the transfer device to solve addressing problems.
IPV6
IPV4 address length is 4 8-bit bytes, IPV4 address will be exhausted sooner or later, to solve this problem, the development of IPV6, IPV6 address length is 4 times the original, usually written as 8 16-bit bytes, IPV6 address is inexhaustible, inexhaustible.
TCP and UDP
When the client wants to establish the connection with the server via TCP, first sends a communication request, the request must be sent to a specific address, and received a reply, after completing the process of “handshake” on both sides, the TCP connection is established, until one side close “handshake” disconnected again, this is “three-way handshake and four waves”, UDP has no handshake or wave mechanism, which is why TCP is more reliable.
TCP three-way handshake
During the handshake, TCP flags SYN and ACK are used. The sender sends a packet with THE SYN flag to the other end. After receiving the packet, the receiver sends a packet with the SYN/ACK flag to convey the confirmation information. If the handshake is interrupted at some point, the TCP protocol sends the same packet again with the same flow.
-
First handshake: The client sends a SYN packet to the server, and the server receives a SYN packet. (The server confirms that the client sends normally and receives normally by itself)
-
Second handshake: The server sends a SYN+ACK packet to the client and the client enters the ACK state. Then the client receives the SYN+ACK packet. (The client confirms that the server can receive and send normally, and that it can receive and send normally)
-
Third handshake: The client sends an ACK packet to the server, and the server receives the ACK packet. The connection is established. (The server confirms that the client can receive and send normally, and the server can receive and send normally.)
TCP waved four times
-
Wave for the first time: when the client’s data transfer is completed, the client to the server contains FIN flag bit connection release a message (data when he didn’t finish, of course, also can send the connection release message and stop sending data), it’s important to note that the client will not be able to send data after sending FIN, but can also be normal to collect data. (The client tells the server that MY data has been sent)
-
Second wave: After receiving the FIN packet from the client, the server sends an ACK packet to the client. In this case, instead of sending FIN packets to the client immediately, the server is in the closed waiting state. This state lasts for a period of time because the server may not finish sending data. (The server tells the client that I received your disconnection request)
-
Third wave: After sending the last data, the server sends a connection release packet to the client. The packet contains the FIN and ACK flags to disable data transmission from the server to the client. In this case, the server is disconnected and waiting. (The server tells the client that MY data has also been sent)
-
Fourth wave: After the client receives the service side of the FIN packet, send confirmation message to the service end, confirm the message contains an ACK flag bit, after the client send confirmation message is not immediately release a TCP connection but after MSL 2 (the longest period of life of the message 2 times the length), the server as soon as we receive confirmation from the client message immediately release a TCP connection, Therefore, the server ends the TCP connection earlier than the client.
Why three handshakes instead of two
The three-way handshake ensures that the sending and receiving capabilities of the server and client are normal, preventing data loss and ensuring information transmission reliability. To solve this problem, triple communication is the minimum value in theory. If only two shake hands, the second time when shaking hands with the server to the client’s confirmation message if lost (the client receives data exception), the client has been in a wait state, it is not clear where the problem is my first handshake message not delivered to the server or server response packet lost, cause the client cannot send data to the server. If the three-way handshake is used, data loss is not a problem. For example, the server loses the confirmation packet sent by the client for the third handshake. If the server does not receive the confirmation packet within a period of time, the server re-shakes the handshake.
Why is a wave four times and not three times (why is a handshake three times and a wave four times)
The connection can be disconnected only when no data is sent from both the client and server. When the client sends FIN packets, the client can only ensure that no data is sent from the server. After client FIN message server received so can only reply to a confirmation message to the client first told the client server your FIN message has been received, but there are still some data server didn’t send out, such as the data is sent over the server to send the client FIN packet (so cannot one-time to send confirmation message and FIN message to client).
Why does the client not immediately release the TCP connection after sending the fourth wave acknowledgement packet
Packet loss is also considered here. If the fourth wave packet is lost, the server will resend the third wave packet without receiving the ACK packet. In this way, the longest time for the packet to go back is 2MSL, so the client needs to wait this long time to confirm that the server has received the packet.
The connection has been established. What if the client suddenly fails
TCP has a timer mechanism, every time the server receives the client request will reset the timer, when a certain period of time did not receive client information server measure will send a message, if there is no response after every 75 s to send again, if there is no response for 10 probe message server that the client fails, Automatically closes the connection.
What happens when we type the URL into the browser
We in http://www.baidu.com/index.html, for example, to analyze the browser address bar enter the URL after what happened, only request related content analysis and network, first do not involve a large number of page rendering.
- The DNS server performs domain name resolution (query the cache and local hosts first)
www.baidu.com
The projected IP address, and then initiates a TCP connection to the server on the client side (three-way handshake). - The client sends an HTTP request packet to the server over a TCP connection, which contains the requested resource path
/index.html
, and other parameters. - The server receives the request packet, parses the request, queries the database, and reads disk resources, encapsulates the HTTP response packet, and sends it to the client.
- The TCP connection is closed after the HTTP client receives the response packet (wave four times).
- Browsers render content.
The actual ‘request -> response’ process is much more complex, and page rendering will be covered later.
The characteristics of HTTP
-
Client/server MODE HTTP works on the client server architecture. The browser as the client sends requests to the Web server through URLS, and the Web server sends response information to the client based on the received requests.
-
When a simple and fast client requests a server, it only needs to send the request method and path. The commonly used request methods are GET, HEAD, and POST. Each method has different communication characteristics between the client and the server. Because HTTP protocol is simple, the HTTP server program size is small, so the communication speed is fast, and HTTP protocol uses plaintext transmission developers do not need to use third-party tools can be tested. HTTP protocol is the main component of header + body, header information is a simple semantic multi-line text, on this basis, request header, status code and other support for developers to customize, so flexible enough, as long as the server and the client on the request header field semantic agreement, new functions can be easily added in.
-
Flexible HTTP allows the transmission of any Type of data object. The specific transmission Type is determined by the value of content-Type. The transmission Type can be image (image/ PNG image/ GIF), application/ JSON (JSON), or HTML (text/ HTML). Because HTTP has no restrictions on language and platform, it has the advantage of cross-language cross-platform, and because of its simplicity and flexibility, almost all languages have HTTP related research solutions.
-
None Connection None Indicates that only one request can be processed for each connection. The server disconnects from the client after processing the request and receiving the response from the client. This method saves resources.
Early the reason for this is the HTTP protocol on the Internet, because the server needs to deal with hundreds of thousands, millions of web pages for the client to access to the entire world at the same time, but each client (browser) for exchanging data between servers and the intermittent is larger, and web browsing associative, divergent lead to two transmit data correlation is very low, Most channels are actually idle, leading to resource hogging. Therefore, HTTP designers deliberately took advantage of this feature by designing the protocol to establish connections at request time and release connections at request time, in order to free up resources for other clients as quickly as possible.
As time goes by, the web page becomes more and more complex, and many images may be embedded in it. At this time, it becomes inefficient to establish a TCP connection every time an image is accessed. Later, Keep-Alive (HTTP1.1) is proposed to solve the problem of low efficiency. The keep-alive function keeps the connection from the client to the server Alive and prevents the re-establishment of the connection when there is a subsequent request to the server.
We should always assume that the connection is closed when the HTTP request ends, which is a feature of HTTP, because it does not change whether the upper implementation closes the connection or not, which is essentially different from WebSocket long connections.
-
Stateless HTTP protocol is stateless, stateless refers to the agreement for the transaction without memory ability, it won’t do to the state of the request and response persistent storage, each request is independent, if subsequent requests need the previous information, then it must be the retransmission, unable to support the successive multiple steps of business operation, This can result in an increase in the amount of data transferred per connection. On the other hand, because the server does not need to manage state, its response is faster.
This feature has both advantages and disadvantages. The advantages are that it frees up the server and does not tie up unnecessary connections with each “click” request, and the disadvantages are that a large number of duplicate content messages are transferred per request.
After the emergence of Web applications (WebApps) for dynamic interaction between the client and the server, the stateless feature of HTTP has seriously hindered the implementation of these WebApps. After all, interaction needs to connect the past and the future, so two technologies for maintaining the HTTP connection state have emerged, one is Cookie. And the other one is Session.
Cookies can keep login information to the user’s next session with the server, in other words, the next time you visit the same website, the user will find that they have logged in without entering a user name and password (of course, the user does not rule out manually deleting cookies). Some cookies are deleted when the user exits the session, which effectively protects personal privacy.
Session can be understood as the Cookie of the server. When the client accesses the server, the server sets the Session as required, saves the Session information on the server, and transmits the Session ID to the browser of the client. The browser stores this SessionId in memory, and the server can retrieve data from the client based on this SessionId. The SessionId is cleared when the browser closes and does not exist in the user’s Cookie temporary file. If the client browser shuts down unexpectedly, the Session data saved by the server is not released immediately. At this time, the data still exists. As long as we know the SessionId, we can continue to request the Session information, because the background Session still exists at this time. Of course, we can set a Session timeout period. Once the timeout period expires and there is no client request, the server will clear the Session information corresponding to the Session ID.
-
Proclaimed in the HTTP protocol has a characteristic is definitely transmission, specifically refers to the message does not use the binary data transmission phase, but use, can be directly read text, relative merits such binary protocol TCP is can not to use external tools directly caught (browser network) debugging, defect is not safe, can be monitored and tampered with.
message
What is a message?
A packet is a collection of parameters and declarations transmitted in HTTP interactions. A packet is a string of multi-line text that is called a request packet sent from the client to the server and a response packet sent from the server to the client. A packet consists of four parts: the start line, the header field, the blank line, and the body. In the request packet, the start line is also called the request line, and in the response packet, the start line is also called the status line.
The request message
The request message consists of four parts, namely, the request line, the Header field, the blank line and the body. The request line and the Header field together are commonly referred to as Req Header. According to the HTTP protocol, each request must send the request Header, while the request body is optional. Blank lines are used to separate the header from the body.
-
Request line The request line describes what the request does, and defines the request method, address, and HTTP version in the request line.
-
Header field The header field is in the form of key-value and ends with a newline. Header fields are extensible, allowing you to customize new field names that are case-sensitive and usually uppercase only. If duplicate field names are defined, only one field name is retained and the value is overwritten by the following one. The HTTP protocol does not impose a limit on the overall length of the header field, but in server practice length exceeding a certain rating of 4K or 8K will actively throw an error for safety reasons. There are four types of headers for header fields: common headers, request headers, response headers, and entity headers, which will be covered later.
-
Empty lines separate the header from the request body, telling the server that what follows is the request body.
-
The main body
The response message
The response packet consists of four parts: the status line, the Header field, the blank line, and the body. The combination of the status line and the Header field is the Res Header.
-
The status line defines the HTTP version, the status code, and the phrase message. The phrase message provides a textual interpretation of the status code. There is a one-to-one correspondence between the status code and the phrase message, for example, 200 corresponds to OK.
-
Header field Indicates the header field of the request packet
-
A blank line separates the response header from the response body, telling the client that what follows is the response body.
-
The main body
Header fields
Header fields are divided into the following five categories: general header, request header, response header, entity header, and extension header.
-
Generic headers: Applies to both request headers and response headers, such as content-Type fields.
Header field key An optional value instructions Connection Keep alive, the close Persistent connection determines whether the network connection will be closed after the current transaction (a three-way handshake and a four-way wave) completes. Date Indicates the time when a packet is created Transfer-Encoding chunked Inform the receiver of the encoding mode used to ensure reliable transmission of packets Cache-Control Controlling cache behavior Via Proxy server information -
Request header: appears only in the request packet, such as the Origin field.
Header field key An optional value instructions Host The domain (or IP) and port of the server receiving the request User-Agent Client information, web is common browser kernel and version Accept Application/json, etc Tells the server the type of data it expects to receive Accept-Language Useful – CN, etc Tells the server the language type it expects to receive Accept-Encoding gzip Tells the server what encoding it expects to receive Accept-Charset Tells the server what character set it expects to receive Authorization The authentication data that the client provides to the server, the client token, is usually written into the Authorization field. Cookie Carry a Cookie Referer Address from which the client initiates the request -
Response header: appears only in response packets, such as the Server field.
Header field key An optional value instructions Set-Cookie The server actively sets an identity token on the client, which automatically writes cookies. Access-Control-Allow-Origin Specify the domain name or * Tell the client which domain of the source is allowed for resource access Keep-Alive timeout=8, max=3 Timeout: indicates the minimum duration of the continuous connection. Max: indicates the maximum number of requests for a single connection. Server Server Information -
Entity header: describes the header field of the packet body, such as the Content-Length field. It is important to note that both request and response packets may contain entity parts, so entity headers may appear in both types of packets.
Header field key An optional value instructions Content-Type application/json The body type to send Content-Encoding gzip Sent code Content-Language zh-CN Sent language Content-Length 100{Number} The length of the sending entity, in bytes. -
Extended header: Not a specified standard header field, but a developer-defined header field.
Difference between Content-type and Accept
Application /json indicates the JSON data format, which is also the value of the Content-Type and Accept fields. The difference between them is that the Content-Type is the entity header, which appears in the request header and response header, indicating that the data body is in JSON format. Accept is the request header, indicating that the request client expects the server to return data in JSON format.
The request url
In http://www.baidu.com:80/assets/public/index.html?a=1&b+2#/path/main, for example to analyze the composition of the request url:
http://: tell the browser which version it is currently using, mostly HTTP or the more secure HTTPS protocol.
www.baidu.com: A domain name is used to locate a machine and send requests to the machine. Of course, a domain name can be replaced with an IP address, but it is not common to use an IP address in the production environment.
:80: Port is also required, the IP is used to locate the machine, and the port is used to determine which server on the machine to initiate a request to. The default HTTP port is 80, and HTTPS port is 443. 80 and 443 can be omitted. Other ports must be specified in the request address.
/ assets/public/index. HTML: resource path begins with a port at the back of the first /, to? The sign ends, and the/in the middle represents the hierarchy.
? A = 1 & b + 2: from? Between # and # are parameters. The parameters of the GET request are carried directly in the URL, and the parameters of the POST request are carried in the request body.
#/path/main: # Start the route for the front-end, the page will not refresh, so that the front-end single page application, the route is not transmitted to the server.
Status code
The status line of the response packet states the status code of the request. The meanings of different status codes are as follows:
Status code | instructions |
---|---|
1xx | Indicates that the request has been received and processing is continuing. |
200 | A successful response |
204 | The request was processed successfully, but no resources can be returned |
206 | The entity Content in a Range specified by content-range that responds to a portion of a resource. |
301 | Permanent redirection. The requested resource has been reassigned its URI, and the resource’s existing URI should be used later |
302 | Temporary redirection. The requested resource has been assigned a new URI and is expected to be accessed by the user (this time) using the new URI. |
303 | Because the resource corresponding to the request has another URI, the GET method should be used to target the requested resource. |
304 | A condition in which the server allows the request to access a resource when the client sends a conditional request, but the condition is not met. |
307 | Temporary redirect. The status code has the same meaning as 302 Found. |
400 | A syntax error occurred in the request packet. Procedure When an error occurs, you need to modify the content of the request and send the request again. |
401 | Unauthorized request |
403 | This status code indicates that access to the requested resource was denied by the server. |
404 | This status code indicates that the requested resource could not be found on the server. |
500 | This status code indicates that an error occurred on the server side while executing the request. |
503 | This status code indicates that the server is temporarily overloaded or is down for maintenance and is unable to process requests at this time. |
Overall 1xx is progress, 2xx is success, 3xx is redirection, 4xx is client error, 5xx is server error.
Request method
Common request methods
- GET: gets resources from the server without a principal.
- POST, which sends data to the server (a common scenario is form submission) has a body.
- DELETE deletes a resource from the server without a principal.
- PUT, updates the resource, has a body.
- The HEAD method is the same as the GET method, except that it does not return the body of the message. This parameter is used to check URI validity and resource update time.
- OPTIONS, pre-request, asking for supported methods.
- TRACE: Traces the path. The TRACE method is a method that allows the Web server to loop back the previous request traffic to the client.
- CONNECT: connects the proxy with the tunnel protocol. The CONNECT method requires that a tunnel be established when communicating with the proxy server to realize TCP communication using the tunnel protocol. Used for Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols to encrypt communication content and transmit it through network tunnels.
GET and POST
The above request method is commonly used only GET and POST, other methods are basically not used, in the work of update and DELETE will not specifically use DELETE and PUT methods, but uniformly use POST to solve. There are a couple of differences between POST and GET that we’re going to give you directly.
- Generally, GET is used for data acquisition (search), and POST is used for data submission (add, delete, modify).
- POST is more secure than GET because parameters are not directly visible in the address bar. (HTTP itself is plaintext transmission POST packet capture parameters can also be viewed)
- The GET parameter in the URL has a length limit of 2KB, while POST does not have this limit for transferring files.
- The GET argument is passed through the URL, and the POST is placed in the RequestBody. (GET requests on the Web do not have reqbodies themselves)
- The POST method passes json data more semantically through the RequestBody. (Json is better for hierarchical data)
- GET requests have better performance and faster speeds
- GET requests are idempotent
There are also the following features when accessing GET addresses directly from the address bar (non-Ajax) :
- GET is harmless (cached) when the browser falls back, whereas POST resubmits the request.
- The URL generated by GET can be saved by the browser, but POST cannot.
- GET requests are actively cached by browsers, whereas POST is not, unless set manually.
- GET requests can only be URL encoded, while POST supports multiple encoding methods.
- GET request parameters are retained in browser history, while parameters in POST are not.
- GET accepts only ASCII characters for the data type of the argument, while POST has no restrictions.
These features only apply to the Web, or, more appropriately, to the browser. HTTP is not just used in the browser, but a few differences on the Web need to be reinterpreted. GET and POST are methods defined by HTTP. HTTP transmission depends on TCP. There is no standard for GET and POST at the TCP layer, so GET and POST are essentially semantic and normative differences.
GET sends the parameter in the url and the length is less than 2kb. POST sends the parameter through ReqBody
GET in the url and the cords and the length is less than 2 KB (no limit) on the measured the browser is no problem, because the browser vendors to GET request in order to conform to the specifications and semantic restrictions only allowed via the url parameter, as for the 2 KB limit because the browser in order to avoid the url is too long on transmission efficiency do to address bar. As mentioned above, all parts of the URL can be transmitted to the server except the route after #. Query, which is independent of the request method. Since the data can reach the server, it can be read as long as it is parsed, so the POST request can also be passed through the URL. The discussion of GET and POST should not be limited to browsers (HTTP is cross-platform), but browser GET requests can also be passed with ReqBody, as shown in the screenshot below via Node + Axios. The conclusion is that while a GET request can be passed through ReqBody, it is not recommended by the specification. Different browser vendors, different servers, and third-party frameworks may implement this specification differently, which does not guarantee availability and stability. However, technically, BOTH GET and POST are TCP based transmission implementations, and there is no essential difference between them. GET can be transmitted through ReqBody, and POST can be transmitted through URL.
GET Obtains data. POST Submits data
Since GET and POST can be passed as urls and reqBodies, it is not necessary to use GET to fetch data and POST to submit data. You can use it the other way around if you want, only semantically.
POST is more secure than GET
The security here is only because the PARAMETERS of THE POST request are not visible on the URL, but when it comes to security, it is often linked with the attack and defense. HTTP itself transmits the POST request in plaintext, grabs any packet or you can see the detailed parameters on the network.
GET requests have better performance and faster speeds
GET sends only one data packet during the request, sending the header and data together to the server, while POST sends two data packets. The server returns 100 and then data, and the server returns 200. The process of returning the status code 100 is not visible in the browser network. You can see the process of 100 through (new XMLHttpRequest()).onreadyStatechange = e => console.log(ajax.status). GET sends only one packet and limits the URL length, so the performance is better than POST. (GET sends only one packet, which is also related to the browser implementation. Some browsers also send two packets like POST.)
GET requests are idempotent
Idempotent means that multiple requests to the same interface should return the same data (without changing the state of the server), and the request can be repeated. Repeated requests can cause unexpected consequences when POST adds data.
How do I optimize HTTP requests
The most important aspect of Web performance optimization is to reduce the length of HTTP requests and content in each response:
- Domain name resolution: Minimize the number of domain name resolution —– Reduce cross-site and external resource references
- Create connections: Reduce connection creation times —– Use keep-alive to avoid duplicate connections
- Send requests: Try to reduce the number of requests —– Properly set Expires time and resource merge
- Waiting for response: Improves the running speed of the server —– Improves the speed of data calculation and query
- Receive response: Minimize response data length —– Enable compression
CDN
The full name of CDN is Content Delivery Network, which applies the caching and proxy technology in HTTP protocol to respond to client requests instead of the source site. CDN is a network built on the basis of the existing network. It relies on the edge servers deployed in various places to enable users to obtain the content they need nearby through the load balancing, content distribution, scheduling and other functional modules of the central platform, so as to reduce network congestion and improve user access response speed and hit ratio. ** The key technologies of CDN mainly include content storage and distribution technology.
HTTTPS
HTTP is a plaintext transmission, which makes it easy for attackers to steal important information. Therefore, HTTPS was born. HTTPS stands for Hyper Text Transfer Protocol over SecureSocket Layer. The difference between HTTPS and HTTP is that HTTPS is an HTTP channel aimed at security. Based on HTTP, the security of the transmission process is guaranteed by transmission encryption and identity authentication. HTTPS adds an SSL layer to HTTP, that is, HTTPS = HTTP + SSL.
Reference documentation
MDN HTTP Headers
RFC