HTTP
- HTTP
- 1. Basic Concepts
- Request and response messages
- URL
- HTTP method
- GET
- HEAD
- POST
- PUT
- PATCH
- DELETE
- OPTIONS
- CONNECT
- TRACE
- HTTP status code
- 1 xx information
- 2 xx success
- 3 xx redirection
- 4XX Client error
- 5XX Server error
- HTTP header
- Generic header field
- Request header field
- Response header field
- Entity head field
- Five, specific application
- Connection management
- Cookie
- The cache
- Content negotiation
- Content encoding
- Scope of the request
- Block transfer encoding
- A collection of multipart objects
- Virtual host
- Communication data forwarding
- Six, HTTPS
- encryption
- certification
- Integrity protection
- The disadvantage of the HTTPS
- Seven, HTTP / 2.0
- HTTP / 1 x defects
- Binary frame layer
- Server push
- The first compression
- New HTTP/1.1 features
- Compare GET and POST
- role
- parameter
- security
- idempotence
- cacheable
- XMLHttpRequest
- The resources
- 1. Basic Concepts
1. Basic Concepts
Request and response messages
The client sends a request packet to the server. The server processes the information in the request packet and returns the processing result to the client in the response packet.
Request message structure:
- The first line contains the request method, URL, and protocol version.
- The following lines are the request Header, each with a Header name and corresponding value.
- A blank line separates the header from the content Body
- Finally, the content body of the request
GET http://www.example.com/ HTTP / 1.1 Accept: text/HTML and application/XHTML + XML, application/XML. Q = 0.9, image/webp image/apng, * / *; Q = 0.8, application/signed - exchange; v=b3; Q =0.9 Accept-encoding: gzip, deflate Accept-language: zh-cn,zh; Q = 0.9, en. Q =0.8 cache-control: max-age=0 Host: www.example.com if-modified-since: Thu, 17 Oct 2019 07:18:26 GMT if-none-match: "3147526947+gzip" Proxy-Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla / 5.0 XXX param1 = 1 & param2 = 2Copy the code
Response message structure:
- The first line contains the protocol version, status code, and description, most commonly 200 OK indicating that the request was successful
- The following lines are also the first content
- A blank line separates the header from the content body
- Finally, the content body of the response
HTTP/1.1 200 OK Age: 529651 Cache-Control: max-age=604800 Connection: keep-alive Content-encoding: gzip Content-Length: 648 Content-Type: text/html; charset=UTF-8 Date: Mon, 02 Nov 2020 17:53:39 GMT Etag: "3147526947+ident+gzip" Expires: Mon, 09 Nov 2020 17:53:39 GMT Keep-Alive: timeout=4 Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT Proxy-Connection: keep-alive Server: ECS (sjc/16DF) Vary: Accept-Encoding X-Cache: HIT <! Doctype HTML > < HTML > <head> <title>Example Domain</title> </body> </html>Copy the code
URL
HTTP Uses urls (U Niform Resource Locator) to locate resources. Urls are a subset of Uniform Resource Identifiers (URIs). Urls add location capabilities to URIs. A URI contains a Uniform Resource Name (URN) as well as a URL. A URI defines a Resource Name but does not have the ability to locate the Resource. An example is URN: ISBN :0451450523, which defines the name of a book but does not indicate how to find it.
- Wikipedia: Uniform Resource Identifier
- wikipedia: URL
- Rfc2616:3.2.2 HTTP URL
- What is the difference between a URI, a URL and a URN?
HTTP method
The first line of the request packet sent by the client contains the method field.
GET
Access to resources
The vast majority of current network requests use the GET method.
HEAD
Obtaining packet header
Similar to the GET method, but does not return the body part of the packet entity.
It is used to verify the validity of the URL and the date and time of resource update.
POST
Transport entity body
POST is used to transfer data, while GET is used to obtain resources.
See Chapter 9 for more POST and GET comparisons.
PUT
Upload a file
Since there is no authentication mechanism, anyone can upload files. Therefore, this method is generally not used because of security problems.
HTML HTTP/1.1 Host: example.com Content-Type: text/ HTML Content-Length: 16<p>New File</p>
Copy the code
PATCH
Modify some resources
PUT can also be used to modify resources, but can only completely replace the original resources. PATCH allows partial modification.
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100
[description of changes]
Copy the code
DELETE
Delete the file
It is the opposite of PUT and also does not have authentication.
DELETE/file. HTTP / 1.1 HTMLCopy the code
OPTIONS
Query supported methods
Queries methods supported by the specified URL.
Allow: GET, POST, HEAD, OPTIONS, etc.
CONNECT
Requires that a tunnel be established while communicating with the proxy server
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are used to encrypt communications and transmit them through network tunnels.
The CONNECT www.example.com:443 HTTP / 1.1Copy the code
TRACE
Tracking path
The server returns the communication path to the client.
When the request is sent, a value is filled in the max-forwards header field, minus 1 for each server passed, and the transmission is stopped when the value reaches zero.
TRACE is not usually used, and it is vulnerable to XST attacks (cross-site Tracing).
- Rfc2616:9 Method Definitions
HTTP status code
The first behavior status line in the response message returned by the server contains the status code and reason phrase to inform the client of the result of the request.
Status code | category | meaning |
---|---|---|
1XX | Informational (Informational status code) | The received request is being processed |
2XX | Success (Success Status code) | The request is successfully processed |
3XX | Redirection (Redirection status code) | Additional action is required to complete the request |
4XX | Client Error (Client Error status code) | The server cannot process the request |
5XX | Server Error | The server failed to process the request |
1 xx information
- 100 Continue: Indicates that everything is fine so far and the client can Continue sending the request or ignore the response.
2 xx success
-
200 OK
-
204 No Content: The request has been processed successfully, but the response message returned does not contain the body of the entity. Typically used when you only need to send information from the client to the server without returning data.
-
206 Partial Content: Indicates that the client sends a Range request. The response packet contains the entity Content specified by Content-range.
3 xx redirection
-
301 Moved Permanently: Permanent redirection
-
302 Found: Temporary redirection
-
303 See Other: Provides the same functions as 302, but 303 explicitly requires that the client use the GET method to obtain resources.
-
Note: Most browsers will change POST to GET for 301, 302, and 303 redirects, although HTTP does not allow you to change POST to GET for 301, 302, and 303 redirects.
-
304 Not Modified: If the request header contains some conditions, for example: If-match, if-modified-since, if-none-match, if-range, if-unmodified-since, If the condition is not met, the server returns the 304 status code.
-
307 Temporary Redirect: indicates that the browser does not change the POST method to GET method for redirecting requests.
4XX Client error
-
400 Bad Request: Syntax errors exist in the Request packet.
-
401 Unauthorized: This status code indicates that the request to be sent requires authentication information (BASIC authentication and DIGEST authentication). If the request has been made before, the user authentication failed.
-
403 Forbidden: The request is rejected.
-
404 Not Found
5XX Server error
-
500 Internal Server Error: An Error occurred while the Server was performing a request.
-
503 Service Unavailable: The server is temporarily overloaded or is down for maintenance and cannot process requests now.
HTTP header
There are four types of header fields: general header fields, request header fields, response header fields, and entity header fields.
The various header fields and their meanings are as follows (not necessary to remember all, just for reference) :
Generic header field
Header field name | instructions |
---|---|
Cache-Control | Controls the behavior of caching |
Connection | Controls header fields that are no longer forwarded to agents and manages persistent connections |
Date | Date and time when the packet was created |
Pragma | Packet instructions |
Trailer | View the header of the packet end |
Transfer-Encoding | Specifies the transmission code of the packet body |
Upgrade | Upgrade to another protocol |
Via | Proxy server information |
Warning | Error notification |
Request header field
Header field name | instructions |
---|---|
Accept | The type of media that the user agent can handle |
Accept-Charset | Preferred character set |
Accept-Encoding | Priority content encoding |
Accept-Language | Preferred language (natural language) |
Authorization | Web Authentication Information |
Expect | Expect specific behavior from the server |
From | Email address of the user |
Host | Request the server where the resource resides |
If-Match | Compare Entity Tag (ETag) |
If-Modified-Since | Compares the update times of resources |
If-None-Match | Compare entity tags (as opposed to if-match) |
If-Range | Send scope requests for entity Byte when the resource is not updated |
If-Unmodified-Since | Compare resource update times (as opposed to if-modified-since) |
Max-Forwards | Maximum transmission hop by hop |
Proxy-Authorization | The proxy server requires authentication information of the client |
Range | Byte range request for the entity |
Referer | The original acquirer of the URI in the request |
TE | Priority of transmission encoding |
User-Agent | HTTP client program information |
Response header field
Header field name | instructions |
---|---|
Accept-Ranges | Whether to accept byte range requests |
Age | Calculate the elapsed time of resource creation |
ETag | Matching information of resources |
Location | Causes the client to redirect to the specified URI |
Proxy-Authenticate | The proxy server authenticates the client |
Retry-After | Request the timing of the request to be made again |
Server | HTTP server installation information |
vary | Proxy server cache management information |
WWW-Authenticate | Authentication information about the server to the client |
Entity head field
Header field name | instructions |
---|---|
Allow | HTTP methods supported by the resource |
Content-Encoding | The encoding method applicable to the entity body |
Content-Language | The natural language of entity subjects |
Content-Length | The size of the entity body |
Content-Location | Replace the URI of the corresponding resource |
Content-MD5 | The packet digest of the entity body |
Content-Range | The location range of the entity body |
Content-Type | The media type of the entity body |
Expires | The date and time when the entity body expires |
Last-Modified | The last modified date and time of the resource |
Five, specific application
Connection management
1. Short connection and long connection
When a browser accesses an HTML page with multiple images, it requests image resources in addition to the HTML page resources requested. If you had to create a TCP connection for every HTTP communication, it would be expensive.
A long connection requires only one TCP connection to carry out multiple HTTP communications.
- Starting from HTTP/1.1, the default connection is long. To disconnect the connection, the client or server must request to disconnect the connection
Connection : close
; - Short connections were the default prior to HTTP/1.1, and long connections were used if needed
Connection : Keep-Alive
.
2. The assembly line
By default, HTTP requests are made sequentially, and the next request is made only after the current request has received a response. Due to network latency and bandwidth constraints, it can take a long time before the next request is sent to the server.
Pipelining can reduce latency by continuously making requests over the same long connection without waiting for a response to return.
Cookie
The HTTP protocol is stateless, mainly to keep HTTP as simple as possible so that it can handle a large number of transactions. HTTP/1.1 introduced cookies to store state information.
Cookie is a small piece of data that the server sends to the user’s browser and saves locally. It will be carried when the browser sends another request to the same server, which is used to tell the server whether the two requests come from the same browser. Since each subsequent request will need to carry Cookie data, there is an additional performance overhead (especially in a mobile environment).
Cookies were once used to store client data as the only storage method because there was no other suitable storage method, but now as modern browsers begin to support a variety of storage methods, cookies are gradually phased out. New browser apis already allow developers to store data directly locally, such as using the Web Storage API (local and session storage) or IndexedDB.
1. Use
- Session state management (such as user login status, shopping cart, game score, or other information that needs to be logged)
- Personalization (such as user-defined Settings, themes, etc.)
- Browser behavior tracking (e.g. tracking and analyzing user behavior, etc.)
2. Creation process
The response packet sent by the server contains the set-cookie header field. After receiving the response packet, the client saves the Cookie content to the browser.
HTTP/1.0 200 OK Content-Type: text/ HTML set-cookie: yummy_cookie=choco set-cookie: tasty_cookie=strawberry [page content]Copy the code
When the client later sends a request to the same server, it will fetch the Cookie information from the browser and send it to the server through the Cookie request header field.
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry
Copy the code
Classification of 3.
- Session Cookie: It is automatically deleted after the browser is closed, that is, it is valid only during the session.
- Persistent Cookie: A Cookie that becomes persistent after an expiration or max-age is specified.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
Copy the code
4. The scope
The Domain identifier specifies which hosts can accept cookies. If this parameter is not specified, it defaults to the host of the current document (excluding the subdomain name). If Domain is specified, subdomain names are generally included. For example, if you set Domain=mozilla.org, cookies are also included in the subdomain (e.g. Developer.mozilla.org).
The Path identifier specifies which paths under the host can accept cookies (the URL Path must exist in the request URL). Child paths are also matched with the character %x2F (“/”) as the path separator. For example, if Path=/docs is set, the following addresses will match:
- /docs
- /docs/Web/
- /docs/Web/HTTP
5. JavaScript
The document.cookie property allows the browser to create new cookies and access cookies that are not HttpOnly tagged.
document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
Copy the code
6. HttpOnly
Cookies marked HttpOnly cannot be called by JavaScript scripts. Cross-site scripting (XSS) attacks often use JavaScript’s Document. cookie API to steal user cookie information, so using HttpOnly markup can avoid XSS attacks to some extent.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
Copy the code
7. Secure
Cookies marked Secure can only be sent to the server through requests encrypted by THE HTTPS protocol. But even if Secure flags are set, sensitive information should not be transmitted through cookies because cookies are inherently insecure and Secure flags do not provide a guarantee of security.
8. Session
In addition to storing user information in the browser through cookies, Session can also be used to store information on the server, which is more secure.
Sessions can be stored in files, databases, or memory on the server. Sessions can also be stored in an in-memory database such as Redis, which is more efficient.
The process of using Session to maintain user login status is as follows:
- When a user logs in, the user submits a form containing the user name and password and sends it to the HTTP request packet.
- The server verifies the user name and password, and if correct, stores the user information in Redis. Its Key in Redis is called Session ID.
- The set-cookie header field of the response packet returned by the server contains the Session ID. After receiving the response packet, the client saves the Cookie value in the browser.
- The Cookie value will be included when the client makes a request to the same server. After receiving the Cookie, the server extracts the Session ID and the user information from Redis to continue the previous business operations.
Note that the Session ID cannot be easily obtained by malicious attackers. In this case, you cannot generate an easily guessed Session ID value. In addition, Session ids need to be regenerated frequently. In scenarios with high security requirements, such as transfer of money, you need to use Session to manage user status and re-authenticate users, such as re-entering passwords or using SMS verification codes.
9. Disable cookies in the browser
In this case, you cannot use cookies to save user information. Only Session can be used. In addition, the Session ID can no longer be stored in cookies. Instead, the URL rewriting technology is used to pass the Session ID as the URL parameter.
10. Cookie and Session selection
- Cookies can only store ASCII characters, while sessions can store any type of data. Therefore, Session is preferred when considering data complexity.
- Cookies are stored in a browser and can be viewed maliciously. If you want to store some privacy data in cookies, you can encrypt the Cookie value, and then decrypt it on the server;
- For large web sites, it is very expensive to store all user information in a Session, so it is not recommended to store all user information in a Session.
The cache
1. The advantages
- Relieve server stress;
- Reduce client latency in obtaining resources: Caches are usually in memory and can be read faster. Also, the cache server may be geographically closer than the source server, such as the browser cache.
2. Implementation method
- Let the proxy server cache;
- Let the client browser cache.
3. Cache-Control
HTTP/1.1 controls caching through cache-control header fields.
3.1 Cache Is Disabled
The no-store directive states that no part of the request or response can be cached.
Cache-Control: no-store
Copy the code
3.2 Enforce acknowledgement cache
The no-cache directive specifies that the cache server must first verify the validity of the cache resource from the source server. Only when the cache resource is valid can the cache be used to respond to client requests.
Cache-Control: no-cache
Copy the code
3.3 Private and public Caches
The private directive specifies that resources be kept as a private cache that can only be used by individual users, typically stored in the user’s browser.
Cache-Control: private
Copy the code
The public directive specifies a resource as a public cache that can be used by multiple users and is typically stored in a proxy server.
Cache-Control: public
Copy the code
3.4 Cache expiration mechanism
If the max-age directive appears in the request message and the cache resource is cached for less than the time specified in the directive, the cache is accepted.
The max-age directive appears in the response message, indicating the time that the cache resource is kept in the cache server.
Cache-Control: max-age=31536000
Copy the code
The Expires header field can also be used to tell the cache server when the resource will expire.
Expires: Wed, 04 Jul 2012 08:26:05 GMT
Copy the code
- In HTTP/1.1, max-age directives take precedence;
- In HTTP/1.0, max-age directives are ignored.
4. Cache verification
The ETag header field is the unique identifier of the resource. URL cannot uniquely represent resources. For example, http://www.google.com/ has two resources in Chinese and English. Only ETag can uniquely identify the two resources.
ETag: "82e22293907ce725faf67773957acd12"
Copy the code
After receiving the request, the server checks whether the ETag value of the cache resource is consistent with the latest ETag value of the resource. If the ETag value is consistent, the cache resource is valid and 304 Not Modified is returned.
If-None-Match: "82e22293907ce725faf67773957acd12"
Copy the code
The last-Modified header field can also be used for cache validation. It is included in the response message sent by the source server and indicates when the resource was Last Modified by the source server. But it is a weak validator because it is accurate to only one second, so it is often used as an alternative to ETag. If the response header field contains this information, the client can validate the cache with if-modified-since in subsequent requests. The server will only return the requested resource if its contents have been modified after a given date and time, with a status code of 200 OK. If the requested resource has Not been Modified since then, a 304 Not Modified response message with no entity body is returned.
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
Copy the code
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
Copy the code
Content negotiation
Content negotiation is performed to return the most appropriate content, for example, whether to return to the Chinese or English screen based on the default language of the browser.
Type 1.
1.1 Server driven
The client sets specific HTTP header fields, such as Accept, accept-charset, accept-encoding, and Accept-language, and the server returns specific resources based on these fields.
It has the following problems:
- It is difficult for the server to know all the information about the client’s browser;
- The information provided by the client is verbose (HTTP/2’s header compression mitigates this) and has privacy risks (HTTP fingerprinting);
- Given resources need to return different representations, shared caches become less efficient, and server-side implementations become more complex.
1.2 Agent-driven
The server returns 300 Multiple Choices or 406 Not Acceptable, from which the client selects the most suitable resource.
2. Vary
Vary: Accept-Language
Copy the code
In the case of content negotiation, the cache can only be used if the cache in the cache server meets the content negotiation criteria, otherwise the resource should be requested from the source server.
For example, after a client sends a request that contains the accept-language header field, the source server returns a response that includes Vary: Accept-language content. The cache server caches the response and returns the cache the next time the client accesses the same URL resource and the accept-language matches the corresponding value in the cache.
Content encoding
Content encoding compresses the entity body to reduce the amount of data transferred.
The commonly used content encodings are gzip, COMPRESS, Deflate, and Identity.
The browser sends the accept-Encoding header, which contains the supported compression algorithms and their respective priorities. The server chooses one of these, uses the algorithm to compress the body of the response message, and sends the Content-Encoding header to tell the browser which algorithm it chose. Because the Content negotiation process selects the representation of the resource based on the Encoding type, the Vary header field in the response message must contain at least content-Encoding.
Scope of the request
If there is a network outage and the server sends only part of the data, a range request enables the client to request only that part of the data that the server did not send, avoiding the server from resending all the data.
1. Range
Add the Range header field to the request message to specify the Range of the request.
GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023
Copy the code
If the request is successful, the server returns a response containing 206 Partial Content status codes.
HTTP/1.1 206 Partial Content Content-range: bytes 0-1023/146515 Content-Length: 1024... (binary content)Copy the code
2. Accept-Ranges
The accept-ranges field in the response header tells the client whether it can handle a range request. Bytes can be used, but None is used otherwise.
Accept-Ranges: bytes
Copy the code
3. Response status code
- In the case of a successful request, the server returns the 206 Partial Content status code.
- If the Requested Range is out of bounds, the server returns the 416 Requested Range Not Satisfiable status code.
- In cases where range requests are not supported, the server returns a 200 OK status code.
Block transfer encoding
Chunked Transfer Encoding, which splits data into chunks and lets the browser progressively display the page.
A collection of multipart objects
A message body can contain multiple types of entities and be sent at the same time. Each part is separated by the delimiter defined by the Boundary field. Each part can have a header field.
For example, you can upload multiple forms as follows:
Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="submit-name"
Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--AaB03x--
Copy the code
Virtual host
HTTP/1.1 uses virtual hosting technology to allow a single server to have multiple domain names and be logically treated as multiple servers.
Communication data forwarding
1. The agent
The proxy server accepts requests from clients and forwards them to other servers.
The main purposes for using proxies are:
- The cache
- Load balancing
- Network access control
- Access logging
Proxy servers are classified into forward proxy and reverse proxy:
- The user detects the presence of a forward proxy.
- A reverse proxy is usually located on an internal network and is invisible to users.
2. The gateway
Unlike proxy servers, gateway servers convert HTTP to other protocols for communication, thus requesting services from other than HTTP servers.
3. The tunnel
A secure communication line is established between the client and server using encryption methods such as SSL.
Six, HTTPS
HTTP has the following security issues:
- Plaintext communications can be intercepted.
- If the identity of the communicating party is not verified, the identity of the communicating party may be disguised;
- The integrity of the packet cannot be proved and the packet may be tampered with.
HTTPS is not a new protocol. It allows HTTP to communicate with SSL (Secure Sockets Layer), and then SSL and TCP, which means HTTPS uses tunnels to communicate.
Using SSL, HTTPS has encryption (anti-eavesdropping), authentication (anti-counterfeiting), and integrity protection (anti-tampering).
encryption
1. Symmetric key encryption
Symmetric-key Encryption: The same Key is used for Encryption and decryption.
- Advantages: fast operation speed;
- Disadvantages: Cannot securely transfer the key to the communicator.
2. Asymmetric key encryption
Asymmetric Key Encryption, also known as public-key Encryption, uses different keys for Encryption and decryption.
The public key is available to all. After obtaining the public key of the receiver, the sender can use the public key to encrypt the communication, and the receiver uses the private key to decrypt the communication.
In addition to encryption, asymmetric keys can also be used for signing. Because the private key cannot be obtained by others, the communication sender uses its private key to sign, and the communication receiver uses the public key of the communication sender to decrypt the signature to determine whether the signature is correct.
- Advantages: The public key can be transmitted to the communication sender more securely.
- Disadvantages: Slow operation speed.
3. HTTPS encryption mode
As mentioned above, symmetric Key encryption has higher transmission efficiency, but the Secret Key cannot be securely transmitted to the communicator. Asymmetric Key encryption can ensure the security of transmission, so we can use asymmetric Key encryption to transmit the Secret Key to the communicator. HTTPS uses a hybrid encryption mechanism that takes advantage of the scheme mentioned above:
- The asymmetric Key encryption mode is used to transmit the Secret Key required by the symmetric Key encryption mode to ensure security.
- After obtaining the Secret Key, use the symmetric Key encryption mode for communication to ensure efficiency. (The Session Key in the figure below is the Secret Key)
certification
The communicator is authenticated by using a certificate.
A digital Certificate Authority (CA) is a third-party organization trusted by both the client and the server.
The operator of the server applies for a public key to the CA. After identifying the identity of the applicant, the CA digitally signs the applied public key, assigns the signed public key, and binds the signed public key into the public key certificate.
During HTTPS communication, the server sends the certificate to the client. After obtaining the public key, the client uses the digital signature for verification. If the verification succeeds, the client can start communication.
Integrity protection
SSL provides packet summarization to protect packet integrity.
HTTP also provides MD5 packet summarization, but it is not secure. For example, if the MD5 value is recalculated after the packet content is tampered, the receiver cannot be aware of the tampering.
The packet summarization function of HTTPS is secure because it combines encryption and authentication. If an encrypted message is tampered with, it is difficult to recalculate the message digest because the plaintext is not readily available.
The disadvantage of the HTTPS
- Because of the need for encryption and decryption process, so the speed will be slower;
- A high fee for certificate authorization is required.
Seven, HTTP / 2.0
HTTP / 1 x defects
HTTP/1.x implementation simplicity comes at the expense of performance:
- Clients need to use multiple connections to achieve concurrency and reduce latency;
- Does not compress the request and response headers, resulting in unnecessary network traffic;
- No valid resource priority is supported, resulting in low utilization of underlying TCP connections.
Binary frame layer
HTTP/2.0 divides packets into HEADERS frames and DATA frames, both of which are in binary format.
During communication, only one TCP connection exists, which hosts any number of two-way streams.
- A data Stream has a unique identifier and optional priority information for carrying two-way information.
- A Message is a complete set of frames corresponding to a logical request or response.
- Frames are the smallest unit of communication. Frames from different data streams can be sent interlaced and then reassembled according to the data stream identifier of each Frame header.
Server push
When a client requests a resource, HTTP/2.0 sends the related resource to the client, so that the client does not need to make the request again. For example, when a client requests a page.html page, the server sends script.js and style.css related resources to the client.
The first compression
HTTP/1.1 comes with a lot of information in the header and is sent repeatedly each time.
HTTP/2.0 requires both the client and server to maintain and update a table of previously seen header fields at the same time, thus avoiding repeated transfers.
In addition, HTTP/2.0 also uses Huffman encoding to compress the header field.
New HTTP/1.1 features
See above for details
- The default is long connection
- Support pipeline
- Multiple TCP connections can be opened simultaneously
- Support for virtual hosting
- Added status code 100
- Supports block transfer encoding
- Added the cache processing instruction max-age
Compare GET and POST
role
GET is used to GET resources, and POST is used to transport entity bodies.
parameter
Both GET and POST requests can use additional parameters, but the parameters of GET appear in the URL as a query string, while the parameters of POST are stored in the entity body. Just because the POST parameter is stored in the body of the entity does not mean it is more secure, as it can still be viewed with some packet capture tool (Fiddler).
Because THE URL only supports ASCII codes, if there are Chinese characters in the parameters of GET, they need to be encoded first. For example, Chinese will be converted to %E4%B8%AD%E6%96%87, and Spaces will be converted to %20. The POST parameter supports the standard character set.
GET /test/demo_form.asp? Name1 = value1 & name2 = value2 HTTP / 1.1Copy the code
Asp HTTP/1.1 Host: w3schools.com name1=value1&name2=value2Copy the code
security
A secure HTTP method does not change server state, which means it is only readable.
The GET method is secure, but the POST method is not, because the purpose of POST is to transmit the entity body content, which may be form data uploaded by the user. Once the upload is successful, the server may store this data in the database, thus changing the state.
There are other secure methods besides GET: HEAD, OPTIONS.
In addition to POST, other insecure methods are PUT and DELETE.
idempotence
Idempotent HTTP methods, the same request is executed once as many times in a row, and the state of the server is the same. In other words, idempotent methods should not have side effects (except for statistical purposes).
All security methods are idempotent.
Methods like GET, HEAD, PUT, and DELETE are idempotent when implemented correctly, but POST is not.
GET /pageX HTTP/1.1 is idempotent, and the client receives the same result from multiple consecutive calls:
GET /pageX HTTP/1.1 GET /pageX HTTP/1.1 GET /pageX HTTP/1.1Copy the code
POST /add_row HTTP/1.1 is not idempotent, and if it is called more than once, multiple lines will be added:
POST/add_ROW HTTP/1.1 -> Adds a 1nd row POST/add_ROW HTTP/1.1 -> Adds a 2nd row POST /add_row HTTP/1.1 -> Adds a 3rd rowCopy the code
DELETE /idX/ DELETE HTTP/1.1 is idempotent, even if different requests receive different status codes:
DELETE /idX/ DELETE HTTP/1.1 -> Returns 200 If idX exists DELETE /idX/ DELETE HTTP/1.1 -> Returns 404 as it just got Deleted DELETE /idX/ DELETE HTTP/1.1 -> Returns 404Copy the code
cacheable
If you want to cache the response, the following conditions need to be met:
- The HTTP methods of request messages themselves are cacheable, including GET and HEAD, but PUT and DELETE are not cacheable, and POST is not cacheable in most cases.
- The response message status code is cacheable, including: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501.
- The Cache is not specified in the cache-control header field of the response packet.
XMLHttpRequest
To illustrate another difference between POST and GET, you need to understand XMLHttpRequest:
XMLHttpRequest is an API that provides the client with the ability to transfer data between the client and server. It provides an easy way to get data through a URL without having to refresh the entire page. This allows the web page to update only a portion of the page without disturbing the user. XMLHttpRequest is widely used in AJAX.
- When using the POST method of XMLHttpRequest, the browser sends the Header first and then the Data. But not all browsers do this. Firefox, for example, does not.
- The GET methods Header and Data are sent together.
The resources
- Ueno Xuan. Graphic HTTP[M]. Posts and Telecommunications Press, 2014.
- MDN : HTTP
- Introduction to the HTTP / 2
- htmlspecialchars
- Difference between file URI and URL in java
- How to Fix SQL Injection Using Java PreparedStatement & CallableStatement
- Discussion on the difference between Get and Post in HTTP
- Are http:// and www really necessary?
- HTTP (HyperText Transfer Protocol)
- Web-VPN: Secure Proxies with SPDY & Chrome
- File:HTTP persistent connection.svg
- Proxy server
- What Is This HTTPS/SSL Thing And Why Should You Care?
- What is SSL Offloading?
- Sun Directory Server Enterprise Edition 7.0 Reference-key Encryption
- An Introduction to Mutual SSL Authentication
- The Difference Between URLs and URIs
- The difference between cookies and sessions
- What’s the difference between cookies and sessions
- Cookie/Session mechanism and security
- Principles of HTTPS Certificates
- What is the difference between a URI, a URL and a URN?
- XMLHttpRequest
- XMLHttpRequest (XHR) Uses Multiple Packets for HTTP POST?
- Symmetric vs. Asymmetric Encryption — What are Differences?
- Web Performance optimization with HTTP/2
- Introduction to the HTTP / 2