Click on the above “Programmer Interview Circle“, select “Pin or Star“

Grow Together with You～

Next, I want to systematically review the TCP/IP protocol suite. Of course, most of this was learned in college, but as the saying goes, it’s essential to revisit the basics from time to time. The upcoming blogs will all be about the TCP/IP protocol suite. This blog will first briefly discuss the TCP/IP protocol suite, then talk about the HTTP protocol, and finally discuss SSL over HTTP (i.e., HTTPS). The TCP/IP protocol suite is a well-trodden topic, and there are plenty of articles online about it, but given its importance, it is still necessary to summarize it systematically.

Overview of the TCP/IP Protocol Suite

Before discussing HTTP and HTTPS, let’s briefly talk about the TCP/IP protocol suite. TCP/IP does not only refer to the TCP and IP protocols but encompasses various related protocols. For example, HTTP, FTP, DNS, TCP, UDP, IP, SNMP, etc., all belong to the TCP/IP protocol suite.

Layering of TCP/IP Protocols

The TCP/IP protocol suite is managed in layers. According to the OSI standard, it can be divided into seven layers (Application Layer, Presentation Layer, Session Layer, Transport Layer, Network Layer, Data Link Layer, Physical Layer, remembered as: App, Pres, Sess, Trans, Net, Data, Phys). In this blog, we will adopt the four-layer model of the TCP/IP protocol suite (Application Layer, Transport Layer, Network Layer, Link Layer). Below is a brief introduction to each layer:

• Application Layer: This layer is user-facing, meaning users can directly operate at this layer. It determines the communication activities when providing application services to users. The HTTP (HyperText Transfer Protocol) discussed in this blog is located at this layer. The commonly used FTP (File Transfer Protocol) and DNS (Domain Name System) are also at this layer. Simply put, FTP is used for file transfer, while DNS is responsible for domain name resolution, converting domain names (e.g., www.cnblogs.com) to IP addresses (201.33.xx.09) and vice versa. In the seven layers, this layer is further divided into the Application Layer, Presentation Layer, and Session Layer.

• Transport Layer: Below the Application Layer is the Transport Layer, which receives data from the Application Layer for transmission. TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are located at this layer. As the names suggest, this layer is used for direct data transmission between two computers connected over a network. TCP requires a three-way handshake to establish a connection, while UDP does not have this process. More details will be provided later.

• Network Layer: Below the Transport Layer is the Network Layer, which handles data packets flowing over the network. IP (Internet Protocol) is located at this layer. This layer is responsible for selecting a transmission path among numerous network lines. Of course, this selection process requires support from IP addresses and MAC addresses.

• Link Layer: In the seven-layer protocol, the Link Layer is divided into the Data Link Layer and the Physical Layer. This part mainly deals with the hardware aspects of the network. The commonly referred to NIC (Network Interface Card) is part of this layer, and fiber optics are also part of the Link Layer.

In the TCP/IP protocol suite, the cooperation and interaction during data transmission can be illustrated with a diagram from the book “HTTP Illustrated.” The following diagram shows how these four layers work during the data transmission process. The diagram is quite intuitive. At the sender’s end, the process of encapsulation from the Application Layer to the Link Layer adds a header at each layer. At the receiving end, the process of decapsulation from the Link Layer to the Application Layer removes the corresponding header at each layer.

Three-Way Handshake of TCP

Before discussing the HTTP protocol, let’s briefly talk about the process of TCP’s three-way handshake. In the following blogs, we will detail the TCP and IP protocols, but for now, we will just cover the basics for the HTTP protocol.

The TCP protocol is located at the Transport Layer. To ensure reliable transmission, the TCP protocol requires a three-way handshake (Three-way handshaking) when establishing a connection. The diagram below illustrates the process of the three-way handshake when establishing a connection with the TCP protocol.

• First Handshake: The sender sends a data packet with the SYN (Synchronize) flag to the receiver to inquire whether the receiver can accept it. If so, the second handshake will proceed.

• Second Handshake: The receiver sends back a data packet with the SYN/ACK (Acknowledgement) flag to the sender, indicating that it has received the SYN flag sent by the sender and is sending back an ACK flag. Can you receive it? If the sender receives the SYN/ACK packet, it confirms that the receiver has received the previously sent SYN, and then the third handshake will proceed.

• Third Handshake: The sender sends a data packet with the ACK flag to the receiver, informing the receiver that it can receive the SYN/ACK flag sent by the receiver. If the receiver receives this ACK flag from the client, it means the three-way handshake is complete, the connection is established, and data transmission can begin.

Structure of HTTP Messages

The full name of the HTTP protocol is HyperText Transfer Protocol, which governs the communication between user clients and servers. The currently widely used version is HTTP/1.1. The protocol essentially serves as a specification. As mentioned earlier, “interface-oriented” programming is actually “protocol-oriented” programming. First, define the protocol for the class, which is the interface, and the related classes adhere to this protocol. This way, we standardize the calling methods of these classes. The HTTP protocol is the specification for communication between clients and servers. This means that all clients or servers that adhere to the HTTP communication protocol have a consistent interface for data transmission, allowing for a connection pipeline to facilitate transmission.

These protocols serve as interfaces, sharing a common communication protocol, enabling multiple endpoints to communicate with each other. Using the same protocol facilitates communication between devices. The functions of the HTTP protocol are as follows:

The HTTP protocol serves to standardize the content of communication, which can be divided into request messages and response messages. As the names imply, the request message is the information sent by the requester, while the response message is the content returned by the responder after receiving the request. Next, let’s take a look at the overall structure of request and response messages.

Structure of Request Messages

Below is the overall structure of a request message. A request message is mainly divided into two parts: the request header (Request Headers) and the request body (Request Body). These two parts are separated by a blank line. The request header is further divided into the request line (Request Line), request header fields, general header fields, and entity header fields, which will be detailed later. Below is the structure of a request message.

The screenshot below shows the Request Headers when requesting a certain page from cnblogs. In the request line, the first “GET” is the current request method, which will be introduced later. The middle part is the path of the requested resource, and the last part, HTTP/1.1, indicates the current request protocol and its version. The following are the request headers, which will be explained later. The request body is the data you send to the server, such as form data.

Structure of Response Messages

After discussing request messages, let’s talk about response messages. The structure of a response message is similar to that of a request message, also divided into a header and a body. Below is the structure diagram of a response message. The response header (Response Headers) is divided into the status line (State Line), response header fields, general header fields, and entity header fields. There is also a blank line separating the response header from the response body.

The screenshot below shows the response headers after the above request message was sent. The response body contains the corresponding HTML and other frontend resources. In the response header, the first line is the status line, where “HTTP/1.1” indicates the version of the HTTP protocol used, the status 200 indicates a successful response, and “OK” is the reason phrase for the status. Common statuses will be detailed later.

HTTP Request Methods and Response Status Codes

The “GET” mentioned in the request message refers to the request method, while the “200” status code mentioned in the response message refers to the response status code. Request methods and response status codes are relatively important content in the HTTP protocol. Previously, when we used the Perfect framework to develop the server side, we discussed the request methods including GET, POST, PUT, and DELETE, and these four methods can be used in conjunction with REST. This section will discuss request methods and response status codes from the perspective of the HTTP protocol, so there will be slight differences from before.

Request Methods

The request methods we will discuss next include GET, POST, PUT, HEAD, DELETE, OPTIONS, TRACE, and CONNECT. The above methods are based on HTTP/1.1, and we will not discuss the unique methods of HTTP/1.0.

• GET—-Retrieve Resource: The GET method is generally used to retrieve resources from the server. When the server receives a GET request, it understands that the client wants to obtain the corresponding resource from the server, and it will return the required resource to the client based on the parameters in the request message. When using the GET method, the parameters are appended to the URI.

• POST—-Data Submission: The POST method is generally used for form submissions, sending the client’s data in the request body to the server.

• PUT—-File Upload: The PUT method is mainly used for uploading files, sending the file content in the request message body to the server. Since the PUT method in HTTP/1.1 does not have a built-in verification mechanism, anyone can upload files, which poses security risks. Therefore, it is not recommended to use it for file uploads. However, when designing interfaces using REST standards, PUT can be used for updating relevant content.

• HEAD—-Retrieve Response Header: When the responder receives a HEAD request, it will only return the corresponding response header without the response body.

• DELETE—-Delete File: DELETE is used to delete the resource specified by the URI. Like PUT, it also does not have a built-in verification mechanism, but it can be used to perform the delete function of the corresponding API in REST standards.

• OPTIONS—-Query Supported Methods: The OPTIONS method is used to query which request methods the server can respond to, and the returned content is the methods supported by the responder.

• TRACE—-Trace Path: The TRACE method can trace the proxy path that the request has passed through. When sending a request, it fills in the Max-Forwards header field with a number, and each time it passes through a proxy, the value of Max-Forwards decreases by one until it reaches zero, at which point it returns 200. Because this method can easily lead to XST (Cross-Site Tracing) attacks, it is not commonly used.

• CONNECT—-Establish Tunnel Protocol Connection: The CONNECT method requests to establish a tunnel for TCP communication when communicating with a proxy server. It mainly uses SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols to encrypt the communication content and transmit it over the network tunnel.

Response Status Codes

After discussing request methods, let’s talk about the response status codes of the HTTP protocol. As the name implies, response status codes indicate the status of the HTTP response, which consists of the response status code and the response reason phrase. There are many types of status codes, and this section will discuss some commonly used status codes. Below are the main categories of response status codes:

• 1xx —- Informational: Indicates that the accepted request is being processed.

• 2xx —- Success: Indicates that the request has been successfully processed.

• 3xx —- Redirection: Indicates that the request needs to be redirected, except for 304.

• 4xx —- Client Error: Indicates that the server cannot process the request.

• 5xx —- Server Error: Indicates that an error occurred while the server was processing the request.

Above is the overall classification of response status codes. Next, we will introduce some commonly used response status codes.

• (01) 200 OK: Indicates that the server has correctly processed the request sent by the client.

• (02) 204 No Content: Indicates that the server has correctly processed the request but has no message body to return.

• (03) 206 Partial Content: Indicates that the server has correctly processed the client’s range request and returned the specified range of entity content.

• (04) 301 Moved Permanently: Permanent redirection; if the previous URI was saved as a bookmark, update the URI in the bookmark.

• (05) 302 Found: Temporary redirection; this redirection will not change the content in the bookmark.

• (06) 303 See Other: Temporary redirection; similar to 302, but the 303 status code explicitly indicates that the client should use the GET method to retrieve the resource.

• (07) 304 Not Modified: Resource not modified; this status code is not related to redirection. When this status code is returned, it informs the client that the requested resource has not been updated, and the response message body will not return the requested content.

• (08) 400 Bad Request: Indicates that the request message contains syntax errors.

• (09) 401 Unauthorized: Indicates that the sent request requires HTTP authentication from the client (to be discussed later).

• (10) 404 Not Found: Indicates that the server cannot find the resource requested by the client.

• (11) 500 Internal Server Error: Indicates that an error occurred on the server while processing the request, resulting in an exception.

• (12) 503 Service Unavailable: Indicates that the server is down and cannot process the request sent by the client.

Original Link

https://www.cnblogs.com/ludashi/p/6232060.html

– end –

Heartfelt sharing of interview knowledge, being a warm-hearted coder

Remember to tell yourself every day: You are the best!

Previous Recommendations:

888G Interview Resource Sharing

Summary of Classic Java Interview Questions