Chapter 1 introduces the basics of Web-level networks

1.1 TCP/IP protocol family

The networks we typically use are based on the TCP/IP protocol family (the set of rules that computers use to communicate with each other), of which HTTP is a subset.

Layered management of TCP/IP

Appendix: Five layer agreement

1.2 URi-url-urn

URI— — Uniform Resource Identifier (URL) identifies an Internet resource. The ability to uniquely identify a resource under certain rules. In real life, a URI is an ID number. The home address also identifies the person, so the home address is also a URI.

URL- uniform resource locator (URL), which represents the address (location on the Internet) of a resource. A home address identifies a person and acts as a URI, a subset of a URI.

URN– Unified resource name. Like a person’s ID number, it acts as a URI, a subset of the URI.

Because URNs haven’t caught on, URIs on the Internet are almost invariably urls.

Chapter 2 simple HTTP protocol

2.1 Request Packets and Response Packets

A request message consists of the request method, request URI (Uniform Resource Identifier (URL)), protocol version, optional request header fields, and content entities.

2.2 HTTP is stateless

HTTP is a stateless protocol that does not save state. The HTTP protocol itself does not store the communication status between the request and response, and does not persist. So cookie technology was introduced to preserve state, more on that later.

2.3 HTTP Uses URIs to locate Internet resources

The HTTP protocol uses URIs to locate resources on the Internet. Because of the specific functionality of URIs, resources can be accessed anywhere on the Internet.

2.4 HTTP method to inform the server of intent

2.5 Persist connections so that requests are piped

HTTP Persistent Connections (also known as HTTP keep-alive or HTTP Connection reuse) method. The characteristic of a persistent connection is that the TCP connection remains as long as neither end explicitly disconnects. In HTTP/1.1, all connections are persistent by default.

Persistent connections make it possible to send most requests as pipelining. After sending the previous request, wait and receive the response before sending the next request. With the advent of pipelining, the next request can be sent directly without waiting for a response. This makes it possible to send multiple requests simultaneously in parallel without having to wait for one response after another.

2.6 Using Cookies for state Management

Cookie technology controls client status by writing Cookie information in request and response packets.

The Cookie notifies the client to save the Cookie based on the set-cookie header field in the response packet sent from the server.

When the client sends a request to the server next time, the client automatically adds the Cookie value to the request packet and sends the request packet. After discovering the Cookie sent by the client, the server will check which client sent the connection request, and then compare the records on the server to obtain the previous status information.

Chapter 3 HTTP Information in HTTP Packets

3.1 Structure of HTTP Packets

3.2 Content Negotiation

If the default language of the browser is English or Chinese and you access the Web page with the same URI, the English or Chinese version of the Web page is displayed. Such a mechanism is called Content Negotiation.

Content negotiation mechanism means that the client and the server negotiate the resource content of the response, and then provide the most suitable resource to the client. Content consultation is based on the language, character set, encoding method of the responding resource.

Chapter 4 HTTP status code returned

Chapter 6 Header fields

6.1 HTTP Header

HTTP request and response packets must contain the HTTP header, which provides information for the client and server to process the request and response respectively.

HTTP request packet

In a request, an HTTP packet consists of methods, URIs, HTTP versions, and HTTP header fields.

The following example is the header of a request message when accessing hackr.jp

HTTP response packet

In the response, the HTTP packet consists of the HTTP version, status code (number and reason phrase), and HTTP header field.

The following example is the header of the response message returned when hackr.jp/ was requested earlier.

Among many fields in packets, the HTTP header field contains the most abundant information. The header field exists in both the request and response packets and contains information related to HTTP packets.

6.2 HTTP header Fields

6.2.1 Transferring Important Information in the HTTP header Field

The HTTP header field is one of the elements of HTTP packets. In HTTP communication between client and server, headers are used in both requests and responses

Part field, which plays a role in passing additional important information. The header field provides the browser and server with information such as the size of the packet body, language used, and authentication information.

6.2.2 HTTP header Field Structure

HTTP header fields consist of header field names and field values separated by colons (:).

Header field name: field value copy codeCopy the code

For example, the content-type field in the HTTP header indicates the object Type of the packet body.

Content-type: text/ HTML Copy codeCopy the code

In the example above, the header field is called Content-Type and the string text/ HTML is the field value.

6.2.3 Four TYPES of HTTP header Fields

HTTP header fields are classified into the following four types based on actual usage.

  • General Header Fields: The Header used by both request and response packets.
  • Request Header Fields: The Header used when sending Request packets from the client to the server. Supplementary information about the additional content of the request, client message information, priority of the response content, and so on.
  • Response Header Fields: The Header used to return Response packets from the server to the client. Additional content added to the response also requires the client to attach additional content information.
  • Entity Header Fields: the Header used for the Entity part of the request and response packets. Added entity-related information such as when the resource content was updated.

6.2.4 HTTP/1.1 Header Fields overview

1. Generic header field

2. Request header field

3. Response header field

  1. Entity head field

6.7 is the header field of the Cookie service

6.7.1 the Set – cookies

Set-Cookie: status=enable; Expires =Tue, 05 Jul 2020 07:26:31 Duplicates codeCopy the code

When the server is ready to start managing the state of the client, various information is given in advance.

The Set value of a field – cookies

6.7.2 cookies

Cookie: status=enable Copy codeCopy the code

The header field Cookie informs the server that the client will include the Cookie received from the server in the request when it wants HTTP state management support. Received multiple

Cookies can also be sent in the form of multiple cookies.

8. Verify the authentication of the access user

Some Web pages only want to be viewed by certain people. To achieve this goal, authentication is essential. Let’s learn about the authentication mechanism.

HTTP Authentication mode

  • BASIC Certification
  • DIGEST Authentication
  • SSL client authentication
  • FormBase authentication [form-based authentication]

8.1 BASIC Authentication (Early, insecure and not commonly used)

BASIC authentication is an authentication method defined from HTTP/1.0. Even now there are still some websites that use this authentication method. The authentication mode is used between the Web server and the communication client. Authentication mode between clients.

Step 1: When requested resources require BASIC authentication, the server returns a response with the WWW-Authenticate header field along with the status code 401Authorization Required. This field contains the authentication mode (BASIC) and the Request-URI security domain string (realm).

Step 2: The client receiving the status code 401 needs to send the user ID and password to the server in order to pass BASIC authentication. The sent string consists of the user ID and password, which are concatenated with a colon (:) and then Base64 encoded.

Step 3: The server that receives the Authorization request containing the first field verifies the correctness of the authentication information. If the validation is successful, a response containing the request-URI resource is returned.

BASIC authentication is Base64 encoding, but it is not encryption. It can be decoded without any additional information. In other words, BASIC authentication on unencrypted communication lines such as HTTP is highly likely to be stolen if wiretapped because the user ID and password are encoded in plaintext.

BASIC authentication is not flexible enough to use and does not offer the level of security that most Web sites expect, so it is not commonly used.

8.2 DIGEST authentication

To compensate for BASIC’s weaknesses, DIGEST authentication has been available since HTTP/1.1. DIGEST authentication also uses challenge/response, but does not send a plaintext password as BASIC does.

In the so-called challenge response mode, one party first sends the authentication request to the other party, and then calculates the response code using the challenge code received from the other party. Finally, the response code is returned to the other party for authentication.

Step 1: When requesting resources to be authenticated, the server returns a response with the wwW-Authenticate header field along with the 401Authorization Required status code.

This field contains the temporary challenge code (random number, Nonce) required for the authentication of the query response mode.

Step 2: The client that receives the 401 status code returns a response containing the Authorization information of the header field required for DIGEST authentication.

Step 3: After receiving the Authorization request of the first field, the server confirms the correctness of the authentication information. After authentication, a response containing the request-URI resource is returned.

In this case, some information about successful Authentication is written to the header field authentication-info.

DIGEST authentication provides a higher level of security than BASIC authentication, but is still weak compared to HTTPS client-side authentication. DIGEST authentication provides a protection mechanism against password eavesdropping, but there is no protection mechanism against user impersonation.

DIGEST authentication, like BASIC authentication, is not as flexible to use and still falls short of the high level of security that most Web sites seek. So its scope of application is limited.

8.3 SSL Client Authentication (Charging)

SSL client authentication uses the HTTPS client certificate to complete the authentication. With client certificate authentication (explained in the HTTPS chapter), the server can verify whether access is available

From a logged in client.

8.3.1 Procedure for SSL Client Authentication

To implement SSL client authentication, distribute the client certificate to the client and install the certificate on the client.

Step 1: After receiving a request for authentication resources, the server sends a CertificateRequest packet asking the client to provide a client certificate.

Step 2: After the user selects the Client Certificate to be sent, the Client sends the Client Certificate information to the server in the form of Client Certificate packets.

Step 3: The server can obtain the public key of the client after verifying the client certificate and start HTTPS encryption communication.

8.3.2 Two-factor AUTHENTICATION is adopted for SSL Client Authentication

In most cases, SSL client authentication does not rely solely on certificates, but is usually combined with form-based authentication (explained later) to form two-factor authentication. The so-called two-factor authentication refers to the authentication process requires not only the password factor, but also the applicant to provide other information, so as to act as

Another factor is the way authentication is used in combination with it.

In other words, the SSL client certificate of the first authentication factor is used to authenticate the client computer, and the password of the other authentication factor is used to determine that this is the user’s behavior. After two-factor authentication, you can confirm that the user himself is accessing the server using the correctly matched computer.

8.4 Form-based Authentication (Common)

Form-based authentication is not defined in the HTTP protocol. The client sends the login information (Credential) to the Web application on the server for authentication based on the verification result of the login information. I’m not going to go into that.

Manage sessions using cookies

Using cookies to manage sessions makes up for the state management functionality that does not exist in HTTP.

Refer to the article

Links: juejin. Cn/post / 690051…