I just came to The Nuggets, this is the first article published, and I will gradually synchronize the github articles to the Nuggets in the future, so that we can communicate, learn and consult together, please give us a lot of guidance and care!

HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP HTTP

For more articles in this series, feel free to pokegithub

And welcome to minesegmentfault

This article mainly records and HTTP related specific concepts and knowledge, about the birth and history of HTTP protocol, not much introduction, but since it is written HTTP, by the way, two sentences, context can also connect on.

It was slowly born when Dr Tim Berners-Lee of CERN, the European Organisation for Nuclear Research, came up with an idea that would allow far-flung researchers to share knowledge.

In addition, HTTP protocol is stateless protocol, so in order to save the user’s state, cookie was born.

The HTTP protocol is based on the TCP connection. When a browser enters a URL for access, the browser resolves the host name and port in the URL and establishes a connection with the Web server before making an HTTP request.

Establishing and terminating a TCP connection

Establishing a TCP connection (three-way handshake)

A three-way handshake is required to establish a TCP connection before the client and server can communicate with each other through HTTP

(1) Requesting a new TCP connection, the client sends a small TCP packet that sets a special SYN flag to indicate a client request.

(2) If the server accepts the connection, it evaluates some connection parameters and sends back a TCP packet to the client, sending SY and ACK flags to indicate that the connection request has been accepted

(3) Finally, the client sends a confirmation message back to the server, notifying the server that the connection has been established.

Disconnecting TCP connections (disconnecting four times)

It takes three handshakes to establish a connection and four handshakes to terminate a connection. This is caused by TCP half-close. Since a TCP connection is full-duplex (that is, data can be transmitted in both directions at the same time), each direction must be closed separately. The principle is that a party can send a FIN to terminate the connection when it has completed its data transmission task. When one end receives a FIN, it must notify the other end of the application layer that it has terminated traffic in that direction several times. Sending FIN is usually the result of an application layer shutdown.

(1) The client sends the FIN flag to the server, indicating that the client initiates to close the connection

(2) The server receives the FIN mark from the client and sends the ACK mark of the FIN to the client

(3) The server sends the FIN to the client and closes the connection

(4) The server sends an ACK flag of the FIN to confirm that the connection is closed

Request and response interactions to establish persistent connections:

Using wireshark to capture packets:

Wireshark is a packet capture software, which can be used to analyze the process of establishing and disconnecting TCP connections and capturing HTTP requests and related information. The following is a screenshot of the packet capture data during the communication between the client and server:

The HTTP message

HTTP packets are data blocks sent between applications, that is, information exchanged between clients and servers. Client packets are called request packets and server packets are called response packets.

HTTP Packet Composition

An HTTP packet consists of a start line, a header, and the body of the entity (also known as the packet body or principal). The start line and header end with a carriage return and a newline character, and the body can be binary or empty.

1. The starting line

Start line of request message:

The start line of the request message describes what to do and consists of the request method, request URI, and protocol version.

GET/index. HTTP / 1.1 HTMLCopy the code

Start line of response message:

The start line of the response packet consists of the protocol version, status code, and cause phrase.

HTTP/1.1 200 OK // OK is the cause phraseCopy the code

2. The first

Header field classification

• 1. Gm head

A header that can be used by both clients and servers

Common header field table:

• 2. Request header

The header of the request message provides some additional information to the server, supplementing information about the additional content of the request, client information, priority related to the response content, and so on.

Request header field

• 3. Response header

Fields unique to the response message

Response header field table:

• 4. Physical headers

The header used for the body part of the request message and response message

• 5. Expand the header

Extension headers are non-standard headers created by application developers but not yet added to an approved HTTP standard.

The HTTP status code

The status code is responsible for describing the returned request results when the client sends a request to the server. The status code lets the user know whether the server handled the request normally or if an error occurred.

Status code classification:

State code area	category
100 ~ 199	Informational status code
200 ~ 299	Success status code
300 ~ 399	Redirection status code
400 ~ 499	Client error status code
500 ~ 599	Server error status code

List of common status codes:

Status code	The reason the phrase	meaning
200	OK	Indicates that the request from the client is processed on the server
204	No Content	The status code indicates that the request received by the server is successfully processed, but the response packet returned does not contain the body part of the entity. Also, it is not allowed to return the body of any entity.
301	Moved Permanently	Permanent redirection. This status code indicates that the requested resource has been assigned a new URI and that the URI to which the resource now refers should be used later
302	Found	Temporary redirect, a status code that indicates that the requested resource has been assigned a new URI and that the user is expected to access it using the new URI
303	See Other	The 303 status code has the same functionality as the 302 Found status code, but differs from the 302 status code in that the 303 status code explicitly states that the client should use the GET method to obtain the resource
304	Not Modified	The cache
307	Temporary Redirect	Temporary redirect, same as 302
400	Bad Request	The status code indicates that a syntax error exists in the request packet. When an error occurs, you need to modify the content of the request and send the request again. In addition, the browser treats the status code as if it were 200 OK
401	Unauthorized	The status code indicates that the request must be authenticated through HTTP (BASIC authentication or DIGEST authentication)
403	Forbidden	This status code indicates that access to the requested resource was denied by the server
404	Not Found	This status code indicates that the requested resource could not be found on the server
500	Internal Server Error	This status code indicates that an error occurred on the server side while executing the request. It could also be a Web application bug or some temporary glitch
502	Bad Gateway	Gateway error
503	Service Unavailable	This status code indicates that the server is temporarily overloaded or is down for maintenance and is unable to process requests at this time. If you know in advance how long this will take, it is best to write the RetryAfter header field and return it to the client

The role of header fields in different HTTP scenarios

1. CORS cross-domain resource sharing

Cross-domain resource sharing (CORS) is a mechanism that uses additional HTTP headers to tell browsers to allow Web applications running on one Origin (domain) to access specified resources from different source servers. When a resource requests a resource from a different domain, protocol, or port than the server on which the resource itself resides, the resource makes a cross-domain HTTP request. –MDN

The following uses NodeJS to build a simple server to introduce a solution to a cross-domain problem

// index.html <! DOCTYPE html> <html> <head> <meta charset="utf-8" />
    <title>CORS</title>
</head>
<body>
    Hello World
<script>
    fetch('http://127.0.0.1:8081')
</script>
</body>
</html>
Copy the code

// server.js

const http = require('http')

http.createServer(function(req, res) {
    res.writeHead('200', {   
        'Access-Control-Allow-Origin': 'http://localhost:8082'
    })
}).listen(8081)
Copy the code

If the source address is http://localhost:8082 and the request is http://localhost:8081, it is a cross-domain request. The browser automatically sends the Origin Header field in the Request Header and sets the value to the source. In this example, http://localhost:8082. The server needs to set access-Control-Allow-Origin in the response header to tell the browser that it can process the returned data. If the response header is not set to Access-Control-Allow-Origin, an error is reported, but a status code of 200 is returned. Cross-domain is actually a security mechanism for the browser itself.

// server2.js // start the 8082 port service, visit http://127.0.0.1:8082 in your browser, return the content of index.html const HTTP = require('http')
const fs = require('fs')
http.createServer(function(req, res) {
    var page = fs.readFileSync('index.html'.'utf-8')
    res.writeHead(200, {
        'Content-Type': 'text/html'
    })
    res.end(page)
}).listen(8082)
Copy the code

Classification of CORS cross-domain requests:

1. Simple request:

Simple requests require that all of the following conditions be met

(1) Request method:

GET, POST, HEADCopy the code

(2) The request header cannot be other than the following fields

Accept Accept-Language Content-Language The content-type value must be one of Application/X-www-form-urlencoded, multipart/form-data, text/plainCopy the code

2. Non-simple request:

Non-simple request: If the request information does not meet the requirements of simple request, the browser sends a pre-request in the form of OPTIONS, containing the request method and request header field to be used. After receiving permission from the server, the browser sends another request based on the request method and header information to be used.

Now modify the above example below:

// index.html <! DOCTYPE html> <html> <head> <meta charset="utf-8" />
    <title>CORS</title>
</head>
<body>
    Hello World
<script>
    fetch('http://127.0.0.1:8081', {
        method: 'PUT',
        headers: {
            X-Coustom-Head: 'abc'
        }
    })
</script>
</body>
</html>
Copy the code

// server.js

const http = require('http')

http.createServer(function(req, res) {
    res.writeHead('200', {   
        'Access-Control-Allow-Origin': 'http://localhost:8082'
    })
}).listen(8081)
Copy the code

An error is reported if the server does not set the appropriate Settings to tell the browser to allow cross-domain access

However, the pre-request return status code is 200

// server2.js // start the 8082 port service, visit http://127.0.0.1:8082 in your browser, return the content of index.html const HTTP = require('http')
const fs = require('fs')
http.createServer(function(req, res) {
    var page = fs.readFileSync('index.html'.'utf-8')
    res.writeHead(200, {
        'Content-Type': 'text/html'
    })
    res.end(page)
}).listen(8082)
Copy the code

Now let’s modify the following server.js

// server.js

const http = require('http')

http.createServer(function(req, res) {
    res.writeHead('200', {   
        'Access-Control-Allow-Origin': 'http://localhost:8082'.'Access-Control-Allow-Headers': 'X-Coustom-Head'.'Access-Control-Allow-Methods': 'PUT'
    })
}).listen(8081)
Copy the code

Restart the Node service, visit http://locaohost:8082, and you can see that the browser continues to send PUT requests after sending pre-requests

Other Settings for CORS are not covered here, but an example is used to illustrate the following different HTTP fields in a cross-domain scenario.

2. 缓存 (Cache-Control的作用)

This example uses the Node service to illustrate the cache-control function, and creates three new files

// index.html <! DOCTYPE html> <html> <head> <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>Cache-Control</title>
    <meta name="viewport" content="width=device-width, initial-scale=1">
</head>

<body>
    <script src="/script.js"></script>
</body>

</html>
Copy the code

// script.js
console.log('script.js')
Copy the code

// server.js
const http = require('http')
const fs = require('fs')


http.createServer(function(req, res) {
    if (req.url === '/') {
        let page = fs.readFileSync('index2.html'.'utf-8')
        res.writeHead(200, {
            'Content-Type': 'text/html'
        })
        res.end(page)
    }

    if (req.url === '/script.js') {
        let page = fs.readFileSync('script.js'.'utf-8')
        res.writeHead(200, {
            'Content-Type': 'text/javascript'.'Cache-Control': 'max-age=10'
        })
        res.end(page)
    }
}).listen(8082)
Copy the code

The first time a script.js resource is requested, a request is sent to the server

When the server returns a response with cache-control: ‘max-age=10’, it will fetch the script.js resource from the Cache and print ‘script.js’ within 10 seconds after modifying the script.js resource.

// script.js
console.log('script-modify.js')
Copy the code

Cache-control () : cache-control () : cache-control () : cache-control () : cache-control () : cache-control () : cache-control ();

Cache-control Cache request instruction:

Cache-control Cache response command:

3. cookie

Data (usually encrypted) stored on a user’s local terminal by a web site for identification and session tracking. The browser sends the cookie to the server on the next visit.

Cookie if the expiration time is not set, the expiration time will be invalid when the browser is closed. If necessary, you can set the expiration time. Continue with the code example 🌰 and create two new files as follows

// index.html <! DOCTYPE html> <html> <head> <meta charset="utf-8" />
    <title>Cookie</title>
</head>
<body>
    Cookie
<script>
    console.log(document.cookie)
</script>
</body>
</html>
Copy the code

// server.js

const http = require('http')
const fs = require('fs')

http.createServer(function(req, res) {
    if (req.url === '/') {
        let page = fs.readFileSync('index.html'.'utf-8')
        res.writeHead(200, {
            'Content-Type': 'text/html'.'Set-Cookie': ['a=1; max-age:5'.'b=2; HTTPOnly']
        })
        res.end(page)
    }
}).listen(8082)
Copy the code

Start the Node service, access localhost:8082, and see that the cookie has been set successfully

The set-cookie field is Set in the response header

The HttpOnly attribute is set to b=2, which does not allow JavaScript to obtain the cookie from the script

Since the cookie is sent to the server in the request header when the request is made again, the cookie a=1 is set to expire after 5 seconds, and the page is refreshed after 5 seconds, the cookie in the request header is only A =1

Send a second request within 5 seconds, cookie A =1 is not invalid, cookie A =1 in the request header; B =2 will be sent to the server

In addition, other Settings for cookies such as Expires and domain are not introduced here

4. The redirection

When the server returns 301, 302, and 307 status codes, it indicates that the resource has been redirected to another location. 301 indicates that the URI is permanently changed, and 302 and 307 indicate that the resource is temporarily redirected to a URI

This example uses a server to return a 302 status code example, directly on the code:

// server.js

const http = require('http');
const fs = require('fs')

http.createServer((req, res) => {
	if (req.url === '/') {
        res.writeHead(302, {
			'Location': '/redirect'
        })
        res.end()
	}

	if (req.url === '/redirect') {
		res.end('redirect')
	}
}).listen(8082);
Copy the code

When you visit localhost:8082 and the server returns a 302 status code, set the Location header field in the corresponding header and the browser continues to send requests to the redirected address

Differences between HTTP and HTTPS

First of all, what is HTTPS

HTTPS (full name: Hyper Text Transfer Protocol over Secure Socket Layer (Hypertext Transfer Protocol Secure) is a Secure HTTP channel. It is simply a secure version of HTTP. That is, add SSL layer to HTTP, and SECURE Sockets Layer (SSL) is the basis of HTTPS security. Therefore, SSL is required for details of encryption. — Baidu Encyclopedia

HTTPS = HTTP+ encryption + Authentication + Integrity protection

Most importantly, an SSL layer is added between the application layer and the transport layer. Generally, HTTP communicates directly with TCP. When SSL is used, it communicates with SSL first and then with SSL and TCP.

The difference between HTTP and HTTPS:

• (1) HTTP is plaintext transmission, while HTTPS is encrypted by SSL. Only the client and server encrypt and decrypt according to the public and private keys. Any transmission link cannot obtain the transmission information, so HTTPS is safer than HTTP

• (2) HTTPS must be purchased from a digital certificate authority

• (3) The default HTTP server port is 80, and the default HTTPS server port is 443

This article focuses on HTTP, but that’s all you have to say about HTTPS.

HTTP2

I want to say something about HTTP2, but I am small white, put a baidu encyclopedia link to HTTP2.

Come back and update this article as we continue to learn.

HTTP/2 is the Future of the Web, and it is here!

Finally, this article mainly introduces some basic knowledge of HTTP in Web development. The screenshots of concepts and illustrated processes are basically taken from TCP/IP Volume 1: Protocols, Illustrated HTTP, and the Authoritative GUIDE to HTTP. The author’s skills are really limited, if you have any questions, please point out more, mutual learning and progress, also hope through my study and practice process, sorted out notes can be helpful to you, thank you.

References:

TCP/IP Volume 1: protocol

The illustration of HTTP

The Definitive GUIDE to HTTP

Detailed explanation of cross-domain resource sharing CORS — Ruan Yifeng