[Interface Automation Test] Detailed explanation of HTTP protocol

protocol

To simply understand, the communication language between computers is called a protocol. Different computers can communicate only by using the same protocol. So a network protocol is a collection of rules, standards or conventions established for data exchange in a computer network.

OSI model

In 1978, the International Standards Organization proposed the "Open System Internet Reference Model", the famous OSI model. It divides the communication protocol of the computer network architecture into 7 layers, from top to bottom: physical layer, data link layer, network layer, transport layer, session layer, presentation layer and application layer. (What is the default value of layer 7 network depends on Baidu)

So our topic today, the HTTP protocol, is in the application layer, and it is also the most commonly used protocol in the application layer.

HTTP

Hypertext Transfer Protocol is a distributed, collaborative, application-layer oriented hypermedia information system. It is a general-purpose, stateless protocol.

principle

The HTTP protocol works on a client-server architecture, with the client sending all requests to the server through URLs. The server sends response information to the client based on the received request. The HTTP protocol defines how the client sends a request to the server, and how the server transmits the response request to the client, so the HTTP request protocol adopts the request/response model.

 

client

The client has two main functions:

1. Send a request to the server

2. Receive the message returned by the server and interpret it into friendly information for us to read

The client probably includes: browser, application, etc.

What we may use most nowadays is the browser. When a user enters a URL in the address bar and presses Enter, the browser will do the following:

1.Resolve protocols and domain names

2. Use HTTP protocol and create a request message to send a request to the server

3. Receive the content returned by the server and display it to the client

Server

The server will start processing the request after receiving the request sent by the client.

The server processing process is as follows

The server software is always listening to the port to see if new requests arrive. For example, after building a web site, iis or tomcat will always listen to port 80 by default and wait for HTTP requests to arrive at the server.

1. Establish a connection: If the client has opened a persistent connection to the server, it can be used directly. Otherwise, the client needs to open a new connection on the server.

2. Receive the request message: When data arrives on the connection, the web server will read the data from the network connection and parse the content in the request message.

3. Process the request: After the request is received, the server can process it according to the request message. For example, in the post method, the data of the message body is extracted and inserted into the database.

4. Access resources: After the request is processed, for example, the web will generate a series of HTML pages or pictures and other information based on the data. This step will access these physical files stored on the server.

5. Construct a response: After the web server identifies the resource, it constructs a response message. The response message includes: status code, response header, response body, etc.

6. Send response: The server sends the response data to the client machine

7. Logging: When the request ends, the server will record a request log in the log file.

Everyone knows that the browser sends a request to the client through the URL address, so let's take a look at the composition of the URL.

URL
实例URL:https://i.cnblogs.com/EditPosts.aspx?postid=10913098&update=1#name

composition

A URL mainly consists of the following parts:

1. Agreement part

The protocol of this URL is HTTP

2. Domain name part

The domain name part of the URL is /www.kath2.com. The IP address can also be used as the domain name in the URL.

3.Port part

The port part follows the domain name:. If not, it means that the URL uses the default port 80, and the port is not a required part of the URL.

4. Virtual directory part

From the first / after the domain name to the last /, the virtual directory is not a required part of the URL.

5. File name part

Last one/to? No. is the file name part. if there is not? No., then until No. #, if not? and # sign, then the file name part is from the last/beginning to the end of the domain name. The file name part in the example is EditPosts.aspx

6.Anchor part

From # to the end

7. Parameter part

from? Starting with the sign and ending with the sign #, multiple parameters are separated by the ampersand.

message

The carrier used for information transfer between the client and the server is called a message. The message is divided into two parts: request and response.

request message

The process of the client sending data to the server is called a request

composition

The request message is divided into 4 parts

1. Request the first line

Contains the request method, the resource to be accessed, and the requested HTTP version

2. Request header

Specifies additional information to be used by the server

3. Blank line

The blank line after the request message header is required

4. Request body

Get often does not have a request body, and the post request body contains the requested parameters.

Format

 

Example

get request instance

post request example

Request method

The main request methods are get, post, put, delete, etc.

get request

1. Obtain data from the server and return the entity part of the response, which can be compared to the select operation of the database and will not affect the database itself.

2. No request body

3. The request parameters are appended to the URL, with? Starting with number, multiple parameters are separated by &

4. Generally, get requests are used for requests that are not data sensitive, because it is not safe to follow the parameters after the URL.

5. The length of transmitted parameters is limited

post request

1. Submit data to the specified resource to process the request (such as submitting a form or uploading a file). The data is included in the request body. POST requests may result in the creation of new resources and/or modification of existing resources.

2. Usually the post request contains the request body

3. The request parameters are stored in the request body and can be in any format

4. Data is relatively safe

5. There is no size limit for request data and can be considered unlimited

Other requests will not be introduced.

response message

The client sends a request to the server, and the process of the server returning data to the client after processing is called a response.

composition

The response message also contains 4 parts

1. Respond to the first line

Protocol version, status code, success and failure status information

2. Response header

Used to describe some additional information to be used by the client

3. Blank line

A blank line after the response header is required

4.Response data

Data and other information returned to the client

Format

 

Example

get response instance

 post response example

 

Response status code
HTTP extension
Cookie mechanism

What are cookies?

Everyone knows that when we log in to a website, we often see a "remember me" option below when entering our account and password. So as long as we check this option, we don't need to enter our account and password when we log in again. You can log in to the website with your password, and this method is implemented through the Cookie mechanism. Used to record the user's status and user's identity

Cookies are special information sent by the server to the client. This information is stored on the client in the form of text files. Then the client will bring this special information every time it sends a request to the server so that the server can identify it.

Cookie handling process

When the user requests the server for the first time, the request message does not contain Cookie information. When the server receives the client's request, it will respond with the information to the client. At this time, the header of the response message will contain a set-Cookie field information and contains the user's identity information. When the client receives set-Cookie, it will save the cookie locally (in memory or hard disk)

When the client sends a request message to the server again, the header of the request message will carry the Cookie information and send it to the server. The server analyzes the information contained in the Cookie and dynamically generates data corresponding to the client.

Example

first visit

http://120.78.128.25:8765 website, we use Fiddler to capture the request message and response message for the homepage of this website

It can be seen that when the website is requested for the first time, the request message does not contain cookie information, and the response message returns a set-Cookie to the client.

second visit

In the second request message and response message, we can see that changes have occurred

The request message already carries Cookie information, but the response message no longer carries set-Cookie information.

So as long as we don’t know the cookie information, we can directly access this website within the validity period in the future.

Session mechanism

What is Session?

Session is another mechanism for recording client status and identity. The difference is that Cookie is stored locally on the client, while Session is stored on the server.

It has the same function as the Cookie mechanism, except that Cookie confirms the customer's identity by checking the pass on the customer, while Session confirms the customer's identity through the customer details table on the server.

Session processing

When the client requests the server for the first time, the server will create a Session and assign a unique identifier Session id to the Session, and add content to the Session. After the server receives the client's request, it will return the response information to the client, then The response message header will carry the Session id and return it to the client.

When the client requests the server again, the request message header will carry the previous Session ID (the session ID needs to be passed through a cookie). After receiving the request, the server searches for the corresponding session content based on the Session ID, and analyzes and compares whether it is the same session. The request is sent by the client, and then the corresponding data is returned to the client.

the difference

Finally, we use an example in life to deeply understand the difference between the two.

A coffee shop I often visited offered a free cup of coffee for 5 cups of coffee. However, the chance of consuming 5 cups of coffee at one time is very slim. In this case, some way is needed to record the consumption quantity of a certain customer. Imagine that there are actually no more than the following options:

    1. The clerk in this store is very good. He can remember the consumption quantity of each customer. As soon as the customer walks into the coffee shop, the clerk knows how to treat him. This approach is that the protocol itself supports state.

    2. Issue a card to the customer, which records the amount of consumption and usually has an expiration date. Every time a purchase is made, if the customer presents this card, the purchase will be linked to previous or future purchases. This approach is to maintain state on the client side.

    3. Issue a membership card to the customer, and record no information except the card number. Every time a customer makes a purchase, if the customer presents the card, the clerk will find the record corresponding to the card number in the store's record book and add some consumption information. . This approach is to maintain state on the server side.

Since the HTTP protocol is stateless, and for various reasons we do not want to make it stateful, the latter two solutions have become realistic choices. Specifically, the cookie mechanism uses a solution that maintains state on the client side, while the session mechanism uses a solution that maintains state on the server side. At the same time, we have also seen that since the solution of maintaining state on the server side also needs to save an identity on the client side, the session mechanism may need to use the cookie mechanism to achieve the purpose of saving the identity, but in fact it has other options.

Thank you to everyone who reads my article carefully. There is always a courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly:

These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends. This warehouse has also accompanied tens of thousands of test engineers through the most difficult journey. I hope it can also help you! Anyone in need Partners can click on the small card below to receive it  

 

Guess you like

Origin blog.csdn.net/kk_lzvvkpj/article/details/133083939