This is the 9th day of my participation in Gwen Challenge

1. Header field:

Request header:

  • Accept: The client tells the server which MIME types it supports, including the following:
    • Text: text/ HTML, text/plain, text/ CSS, etc
    • Image: image/ GIF, image/ JPEG, image/ PNG, etc
    • Audio/Video: Audio/MPEG, Video/MP4 etc
    • Application: Application /json, application/javascript, Application/PDF, application/octet-stream
  • Content-Type: Indicates the data type of the request body of the request packet, that is, the data type submitted by the client to the server. Specific can include the following:
    • Application/X-www-form-urlencoded: Most commonly used for transmitting simple data, request body similar toa=1&b=2This format
    • Multipart /form-data: uploads files
    • Application/JSON: Used to transfer data. The request body is a serialized JSON string

Header:

  • Allow: The server tells the client which request method it supports
  • Content-Type: Data type of the response body of the response packet, that is, what type of data is returned to the client by the server, such as Text/HTML, image/ GIF, application/ JSON

2. Request method

What are the request methods?

  • GET: Usually used to obtain resources
  • HEAD: Obtains the meta information of the resource. (HEAD is HEADER, the request HEADER that stores the meta information of the resource.)
  • POST: data is submitted, that is, uploaded
  • PUT: Modifies data
  • DELETE: Deletes a resource (hardly needed)
  • CONNECT: establishes the connection tunnel for the proxy server
  • OPTIONS: Lists the request methods that can be applied to resources for cross-domain requests
  • TRACE: Traces the transmission path of the request and response

What’s the difference between GET and POST?

  • Parameters: GET parameters are attached to the URL. POST parameters are attached to the body of the request.

  • Security: In fact, if HTTP is transmitted in plaintext, neither GET nor POST is secure, regardless of whether the data is transmitted using a URL or a body

  • Idempotent: Repeated GETS always return the same result and have no side effects on the data to be accessed, so GET is idempotent; Repeated Posts can have side effects, so posts are non-idempotent

  • Caching: Because GET is idempotent, the results of A GET can be cached in a browser or proxy server, whereas POST cannot

  • Encoding: GET usually transfers data through a URL, which determines that it only supports ASCII; POST usually transfers data through body, which determines that it can support any binary

  • Length: GET usually transmits data through a URL, and the URL length is limited, so the length of data that can be transmitted by GET is limited. POST usually transmits data through the body, so you can think of it as transmitting an infinite amount of data

  • Number of requests: It is generally assumed that a GET request needs to be sent once, whereas a POST request needs to be sent twice — the first time the request header is sent, the second time the body is sent after the 100 (continue) response status code is received. This situation should be understood as a means of optimization, not as a fundamental difference between GET and POST. Such as user through a POST request to upload a large file, then you can start request header, the service side if the judge this request is illegal (for example, users do not have permission to upload), you can directly return 4 xx, the client would be no need to send the request body, compared to a one-time send all data, this approach to reduce the waste of bandwidth. But then again, if the data in the POST is very, very small, then it’s ok to POST the header and the body all at once. Finally, whether to send once or twice depends on the strategy the browser is using, but it is not absolute.

3. The cache

HTTP cache

1) Strong cache and negotiated cache

Cache-control: must-revalidate set cache-control: must-revalidate

  • When the browser requests resource A for the first time, it checks whether the cache exists. Because there is none, the request goes to the server and gets the resource
  • A moment later, the browser makes another request for resource A to see if there is A cache, and there is the last cache, so it then looks to see if it is expired (or if the cache is “fresh”)
    • The cache is not expired: resource A is fetched directly from the cache at this point. This is called strong cache route, hit strong cache;
    • The cache is out of date: the browser needs to negotiate with the server: should the browser use the old cache from the last time, or use a new cache that may have been updated? This is called taking the negotiated cache route and not hitting the strong cache.
      • If the first response contains an e-tag field, the browser uses the e-tag field as the if-none-match field to send a conditional request to the server, which is equivalent to asking the server: == When the resource was sent to me, the unique identifier of the resource was e-tag. Does this hash value still match the current resource hash value? == The server will compare the value of this field with the current latest resource hash value. If the value is consistent, the resource has not changed, and the 304 status code is returned, allowing the browser to use the old cache. If no, the resource has been modified. In this case, the browser responds to the new resource
      • If the first response does not carry an e-tag field, but carries a last-Modified field: The browser sends a conditional request to the server using the last-Modified field value as the if-Modified-since field value. == When the resource was sent to me, the last time it was modified was last-modified. Has the resource not been modified again since this time? == The server will compare the received value of this field with the latest resource modification time. If the time matches, the resource has not been modified. In this case, the 304 status code will be returned to allow the browser to use the old cache. If the time does not match, the resource has been modified. In this case, the browser responds to the new resource
      • If neither field is carried: then the normal request response occurs

PS: The e-tag field is checked first because it is more accurate. There are actually two problems with last-Modified validation that affect whether the resource has actually been modified:

  • One is to mistake not modifying for modifying. Last-modified is more accurately defined as the last time the resource was modified, rather than the last time it was modified. By “modified”, it means that the resource is not necessarily modified, or the modification is insignificant, but because the edit time was changed, the server still gives the result that the resource has been modified.
  • Second, the modification is mistaken for no modification. Last-modified is only accurate to the order of a second, which means that if a resource has been modified multiple times within a second, the server will not notice and will still give the result that the resource has not been modified.

Remember with this picture:

When cache-control: must-revalidate is set, cache-control: must-revalidate is set, and cache-control: must-revalidate is set, and cache-control: must-revalidate is set. If cache-control: no-cache is set, the server is first checked by e-tag or last-Modified, regardless of whether the cache is expired. If cache-control: no-store is set, no caching is performed and there is no strong or negotiated caching.

2) Cache expiration time

In fact, the client can use expiration caching by setting the relevant header field.

  • max-stale = 5: Allows the client to use an expired cache, but the cache is allowed to expire for 5 seconds at most
  • min-fresh = 5: The client requires a fresh, unexpired cache that is fresh after at least 5s

In fact, it is possible for clients to use stale caches — you can use a max-stale setting to allow clients to use stale caches for as long as they are not stale.

Proxy server cache

The vary header field in the response message is used in the proxy server cache. In fact, the Vary field assists in content negotiation, preventing clients from returning cached resources incorrectly.

Suppose you have two clients, A and B. A supports GZIP encoding and B does not.

  • The first time A sends A request that is forwarded by the proxy server to the server, the server returns the resource to the proxy server and adds A vary field to the response message, such as Vary: Accept-Encoding. The proxy server caches the resource and marks it with vary in the response message, such as accept-encoding: gzip, to indicate that the resource is compressed using gZIP encoding.
  • Suppose A makes A second request moments later for the same resource, since there is also an accept-encoding: gzip, so the proxy server can return the cache to client A
  • Suppose B also makes a request, but since B does not support gZIP encoding, it does not carry the accept-Encoding: gzip field, and the proxy server does not return the cached resource to B

So vary effectively marks the proxy server’s cache resources, and if the source server does not return the Vary field, then when B requests a resource, the proxy server mistakenly returns it to B, which can’t use it because it doesn’t support GZIP encoding.

4. HTTP performance optimization

HTTP performance optimization can be started from three aspects, namely server, client and transport link:

  • Server: Related indicators include throughput (RPS, TPS, QPS, namely the number of requests per second), concurrency (how many clients can be supported), response time, utilization of other resources (CPU, memory, network card, hard disk, etc.)
  • Client: The basic indicator is latency, which is related to geographical distance, bandwidth, DNS query, TCP handshake, etc
  • Transmission link: first kilometre bandwidth, middle kilometre (CDN)

5. Changes brought by HTTP/2

The head of compression

In HTTP 1.x, content-Encoding: gzip can be used to compress the body of the response message, but there is no corresponding compression optimization method for the response header that may be larger than the response entity. To this end, HTTP2 introduces header compression, which is implemented based on the HPACK algorithm.

binary

Instead of using the ASCII text format, packets use the binary format. On this basis, the previous header + body structure is broken into binary frames. The HEADERS frame is responsible for storing the header DATA, and the DATA frame is responsible for storing the entity DATA

flow

Before explaining flows, let’s look at how multiple HTTP requests have been sent over the course of HTTP:

  1. Short connection: A TCP connection can only handle one round of request-response. Once the server returns a response, the TCP connection is broken. The next round of request-response must create a new TCP connection

    Disadvantages: Short connections require frequent creation of TCP connections, frequent handshaking and waving, which can be time-consuming

  2. Long/Persistent/connection alive/connection multiplexing: Allows a TCP connection to be used for multiple rounds of request-response. HTTP 1.0 explicitly declares connection: keep-alive to enable long connections. HTTP 1.1 explicitly declares connection: keep-alive to enable long connections

    Disadvantages: Cannot solve queue head blocking problem. Request-response is serial. A request B can be sent only after A request returns A response. If A request fails to return A response, the request B will be blocked

  3. Pipelining: HTTP 1.1 introduces pipelining, allowing multiple requests to be made simultaneously without waiting for the response to return

    Disadvantages: still can’t fundamentally solve the problem of team head blocking. Because the order in which the response is returned is the same as the order in which the request was sent, if A request fails to return A response, the response for B request will also fail to return

  4. TCP concurrent connection: If the same TCP connection can be blocked, open several MORE TCP connections and “move” blocked requests to other TCP connections so that they do not affect each other. The browser allows up to 6-8 concurrent TCP connections for a domain name

  5. Domain name sharding: If the simple TCP concurrent connections cannot meet the requirements, domain names can be sharded, that is, multiple domain names can be mapped to the same server. In this way, the actual number of concurrent TCP connections is domain names x 6-8

  6. Multiplexing: HTTP 2 implements multiplexing, which really solves the HTTP header blocking problem. Multiplexing allows multiple request-responses to be made simultaneously on the same TCP connection without any interaction (assuming no dependencies), sequence, or blocking problems

Stream is the basis of multiplexing to avoid queue head blocking. At the “flow” level, messages are ordered sequences of “frames”, while at the “connection” level, messages are out-of-order “frames”. There is no sequential relationship between multiple requests/responses, so there is no need to queue, and queue head blocking problem will not occur, which reduces latency and greatly improves connection utilization.

server push

Server push refers to the server’s ability to return resources that the client may request in the future. For example, if the client only requests index.html from the server, but references other resources (such as style.css) in the index. HTML, the server will return these resources, so that the client does not need to send a request for these resources again.

Pseudo header fields replace request/status lines

HTTP 1.x has request lines and status lines, whereas HTTP 2 directly turns request lines and status lines into pseudo-header fields.

In HTTP 1.x, the request line looks like this:

GET / HTTP/1.1
Host： www.example.com
Copy the code

In HTTP 2, these are converted to pseudo-header fields like this:

:scheme: https
:method: GET
:path: /
:authority: www.example.com
Copy the code

In HTTP 1.x, the status line looks like this:

HTTP/1.1 200 OK
Copy the code

In HTTP 2, this translates to the following pseudo-header field:

:status: 200
Copy the code