This is the 31st day of my participation in the August More Text Challenge

Does the browser need to view the cache when sending a request? How to check? The server received the request. Do you need to check the cache? What fields are checked? What are the differences between HTTP1.0 and HTTP1.1 caching?

When the browser sends a request, it needs to undergo a strong caching process. First, it needs to check whether the requested resource is cached locally

The returned status code is 200. The cache is expired. The request is sent to verify that the resource matches the negotiated cache. The process of loading resources from the server to return data strong caching is done by the browser alone, and the server is required to negotiate the cache

Strong caching process:

Determine whether a strong Cache has been hit based on the header’s Expires and cache-control. How to check whether a strong Cache has expired

Check whether there are s-maxage or max-age instructions in cache-control. If there are, use the generation time of the response message to obtain the expiration time and compare it with the current time. Compares the expiration time in Expires with the current time. Expires is an absolute time.

Cache-control: cache-control:

No-cache: indicates that the local cache is not used but the negotiated cache is used. That is, the cache is confirmed with the server first. No-store: cache is disabled. Public: indicates that other users can also use the cache. This applies to the case of a public cache server. Private: indicates that only specific users can use the cache. This applies to the case of a public cache server.

Negotiation cache process:

If the cache does not contain an ETag or Last-Modified field, an HTTP request is made. The server returns the resource based on the request and adds the ETag field (identifying string) to the respone header returned. Last-modified If both fields are present, an if-none-match field is added to the request header (If an ETag field is present, The value is the ETag value in the Last response message, and the if-Modified-since field (If there is a last-modified field, the value is the last-modified value returned in the Last request). The server determines whether the resource has changed according to the value sent by the request. If there is no change, 304 is returned. If there is a change, 304 is returned as normal. If last-Modified 304 is updated, the resource is loaded from the cache, otherwise it is loaded directly from the server

Note:

If both if-none-match and if-modified-since fields are sent, the server only needs to compare if-none-match and ETag. If the content is consistent and the server thinks the cache is still available, it returns the status code 304. When an ETag is hit, the ETag is still returned in the response header, even if it has not changed, but if a last-Modified hit is made, no last-Modified field is added to the response header, meaning that the last-Modified expiration time is always determined by the value first returned

Http1.0 and HTTP1.1 caches

In HTTP/1.1, cache-control was introduced. When the header field cache-control has an s-maxage or max-age directive, it takes precedence over HTTP 1.0 Expires to handle s-maxage or max-age. Cache-control: max-age specifies the lifetime of the document, which is a relative time. Expires specifies an absolute time.

ETag is the unique identifier of a resource that is automatically generated by the server on the server side. Each change in the resource generates a new ETag value. Last-modified can be used with ETag, but the server validates the ETag first.

How does the DNS obtain an IP address? The first thing to look for is the browser’s DNS cache, which caches DNS records for a period of time. Therefore, the browser will check its own cache first, and if the domain name is recorded in the cache, it will use the IP address in the cache for further processing. If not, proceed to the next search. Example Query the system cache. If there is no DNS information in the browser cache, the browser will look up the DNS information recorded in the system. Check whether the domain name is stored in the local hosts, and then check other DNS records cached locally. Hosts is a system file without name extension. The hosts file is used to create a database associated with some common url domain names and their corresponding IP addresses. (for example, when we access the test environment, configure the host) router cache. If it still doesn’t find an IP address in the system cache, it sends a request to the router, which then looks up the record in its own router cache, which also stores DNS information (it caches websites you visit, so sometimes the router needs to do a DNS refresh) in the ISP DNS cache. If the local router is still not available, the request is sent to an Internet Service Provider (ISP), which also has an ISP DNS server. Recursive DNS query. If the ISP DNS server does not find it, then DNS recursive query is required. So let’s say I need the IP address of www.baidu.com and I go to the client host and I ask the local DNS server for www.baidu.com and I can’t find it on the local DNS server and the local DNS server goes to the root DNS server and the root DNS server says this is a.com domain name, And then it goes back to the IP address of the top-level domain name server and then the local domain name server goes to the top-level domain name server that manages the.com domain name, and the top-level domain name server says.baidu secondary domain name. The local domain name server (DNS) then returns the IP address of the authoritative DNS server and finally the local domain name server (DNS) then goes to the administrative domain name server (DNS) at baidu to query the IP address of the third level domain name WWW. The IP address is then given to the local DNS server and the local DNS server returns the address to the client host

The query process here includes recursive query and iterative query. The query sent by the client host to the local server is recursive query, and the following three queries are iterative query.

Three-way handshake for establishing A TCP connection First handshake: When establishing a connection, the client sends a SYN packet (SYN = X) to the server and enters the SYN_SENT state, waiting for confirmation from the server. (SYN synchronization sequence Number)

Second handshake: After receiving a SYN packet, the server must acknowledge the client’s SYN (ACK = X +1) and send a SYN packet (ACK = Y). In this case, the server enters the SYN_RECV state.

Third handshake: After receiving the SYN+ACK packet from the server, the client sends an ACK packet (ACK = Y +1) to the server. After the packet is sent, the client and the server enter the ESTABLISHED state (TCP connection is successful) and complete the three-way handshake.

What are the four waves to close TCP? The client sends a FIN to the server to disable data transmission. The client enters the FIN_WAIT_1 state When the server receives a FIN from the client, it sends an ACK whose value is FIN+SEQ to the client. The server enters the CLOSE_WAIT state. The server then sends a FIN to the client to tell the application to shut down. The server enters the LAST_ACK state. After receiving a FIN from the server, the client sends an ACK to the server. The client enters the TIME_WAIT state. The server receives the notification and enters the CLOSED state

The TCP connection is in full duplex, so each direction must be closed separately. This principle is that when a party finishes sending data, it sends a FIN to terminate the connection in this direction. Receiving a FIN only means that no data flows in this direction, that is, no more data is received. However, data can still be sent on this TCP connection until a FIN is also sent in that direction. The party that closes first performs an active shutdown, while the other party performs a passive shutdown

The reason for four waves is to make sure the data is transmitted in its entirety.

When the passive party receives a FIN packet from the active party, it only indicates that the active party has no data to send to the passive party.

However, the passive may not send all the data to the active party completely, so the passive party will not close the SOCKET immediately. It may need to send some data to the active party.

A FIN packet is then sent to the active party to inform the active party that it agrees to close the connection. Therefore, ACK packets and FIN packets are sent separately in most cases.