Description of HTTP packets
There are two types of HTTP packets: request packets and response packets. HTTP messages are the way data is exchanged between the server and the client. There are two types of messages: requests — sent by clients to trigger an action on a server; Responses — responses from the server.
HTTP request packets
How to first on the diagram and then detailed analysis.
An HTTP request packet consists of three parts: the request line, the request header, and the requested data (entity).
Request line (the first line of an HTTP request message)
The request line consists of the method field, URL field, and HTTP protocol version field. Method fields are case sensitive, and methods in the current HTTP protocol are uppercase. The sections of the request line are described as follows:
Methods field
①GET: Request the resource identified by the request-URI (URI: generic resource identifier,URL is a subset of it, URI focuses on identification, and URL emphasizes location)
②POST: Appends new data to the resource identified by the request-URI. Support for HTML form submission, which contains user-entered data that is sent to the server and stored by the server in a location (such as a send handler)
③HEAD: Request the resource response message header identified by the request-URI. The HEAD method can respond without returning the message body.
④PUT: In contrast to GET, a Request server stores a resource and identifies it with a request-URI. For example, release systems.
⑤DELETE: requests to DELETE the resource pointed to by the URL
⑦TRACE: traces the firewall, proxy, or gateway through which the request passes, mainly used for testing or diagnosis
⑧CONNECT: Reserved for future use
URL
A complete including type, host name and optional path name of the resource reference name, such as: www.example.com/path/to/fil…
HTTP Version
There are HTTP/0.9, HTTP/1.0, HTTP/1.1, HTTP/2.0. The current mainstream version is HTTP/1.1
Request header: Located below the request line
Common request headers in request packets are as follows:
Request header | describe |
---|---|
Connetion | Connection management |
The Host header | Specify the host requesting the resource |
Range | Request the byte range of the entity |
User-Agent | Contains information about the user that made the request |
Accept | A list of MIME types expected by the user agent |
Accept-Language | Lists the page language expected by the user agent |
Note: For more HTTP request headers click here
HTTP headers allow clients and servers to pass additional information through request and response. A request header consists of a name (case insensitive) followed by a colon (:) followed by a specific value (without a newline character). The boot whitespace before this value is ignored.
Custom private headers can be added with the ‘X-‘ prefix; However, this usage was explicitly deprecated by the IETF in RFC5548, published in June 2012, due to the inconvenience it can cause when non-standard fields become standards; The other headers are listed in the IANA registry, and their original contents are defined in RFC 4229. In addition, IANA maintains the proposed new HTTP header registry.
Depending on the context, the header can be divided into:
General Headers: A header that applies to both request and response messages, but has nothing to do with the data being transferred in the final message body.
Request Headers: A header that contains more information about the resource to be fetched or about the client itself.
Response Headers: A header that contains supplementary information about the Response, such as its location or the server itself (name and version, etc.).
Entity Headers: Contains more information about the Entity body, such as the content-Length degree of the body or its MIME type.
Message headers can also be divided according to how the broker handles them:
End-to-end headers: This type of header must be transmitted to the ultimate message receiver, that is, the requesting server or the responding client. The intermediate proxy server must forward the unmodified end-to-end headers and must cache them.
Hop-by-hop headers: This type of header is meaningful only for a single transport connection and cannot be reforwarded by proxy or cache. These headers include Connection, keep-alive, proxy-Authenticate, proxy-authorization, TE, Trailer, Transfer-encoding and Upgrade. Note that you can only set a hop-by-hop header using Connection.
The HTTP header:
Generic header: used for both requests and responses;
Connection: defines options between C/S regarding requests/responses. For HTTP /1.0, Connection: keep-alive
Cache-control: indicates the Cache
Entity header: Used to specify entity attributes
The entity body is used in the POST method. When a user submits form data to the Web server, the POST method is used. In this case, the body contains the values of each attribute field added by the user in the form. After receiving the HTTP request packet from the POST method, the Web server can retrieve the required attribute field values from the entity.
In other words, when a user sends a request to a Web server through a Web browser, the Web browser will select different HTTP request methods according to the user’s specific request, and then fill the corresponding URL and HTTP protocol version and related header in the header line. In the case of POST method, it will also fill the related form data into the entity body. Generates an HTTP request packet and sends the packet to the Web server.
Location: new Location of the resource Allow: request method that is allowed to be used for this resource
1. Content header: content-encoding: supported Encoding Content-language: supported natural Language Content-Length: text Length content-location: Location of resources content-range: The range of bytes represented by this entity in the entire resource content-Type: the object Type of the subject
2, cache header: ETag Expires: entity tag Expires: last-modified: Last Modified time
Request header:
Host: the requested Host name and port number, used for different virtual hosts in the virtual Host environment
Referer: Indicates the URL of the original resource that requested the current resource
User-agent: The User Agent. What tool is used to make the request
Accept header: The user indicates the capabilities that the customer is more likely to support
- Accept: Indicates the media type that the server can send
- Accept-charset: Character set supported
- Accept-encoding: Indicates the Encoding mode supported
- Accept-language: supported Language
Condition request header:
- Expect: Tells the server which media types can be sent
- If-modified-since: Whether the resource has been Modified Since the specified time
- If-none-match: Gets the document If the entity tag provided does not Match the entity tag of the current document
Security-related request headers:
- Authorization: Authentication data submitted by the client to the server, such as accounts and passwords
- Cookie: the identity identifier sent by the client to the server
Let’s look at a request made by the browser.
The figure above shows the attributes of a generic request.
I’m the dividing line
2. HTTP response packets
Same old rule. Picture first.
The HTTP response packet is also divided into three parts: the status line, the header line, and the entity
Status line: the first line of the HTTP response packet
The status line contains three fields: protocol version, status code, and cause phrase.
The HTTP response status code indicates whether a particular HTTP request has completed successfully. Responses fall into five categories: message response (100-199), success response (200-299), redirection (300-399), client error (400-499), and server error (500-599). Status codes are defined by Section 10 of RFC 2616.
Note: Click here for more status code meanings
Status code:
1XX: This type of status code indicates that the request has been accepted and needs to be processed. This type of response is a temporary response, containing only the status line and some optional response header information, and ending with an empty line.
2XX: This type of status code indicates that the request has been successfully received, understood, and accepted by the server.
3XX: This type of status code indicates that the client needs to take further action to complete the request. Typically, these status codes are used for redirection, and subsequent request addresses (redirect targets) are specified in the Location field of this response.
4xx: This type of status code represents a client class error
5xx: Server class error.
Response header (header line) : after the status line of the response message
Date header: the time when the message was generated
Age header :(since initial creation) duration of response
Server header: Identifies the Server program name and version to the client
ETage header: Opaque verifier
Location header: Alternate Location of the URL
Content-length Header: the Length of the entity
Content-type Header: the media Type of the entity
Negotiation first:
- Accept-ranges: The type of range acceptable to the server for the current resource
- Vary: Header list, the server selects the most appropriate version based on the list and sends it to the client
Security-related response headers:
- Set-cookie: the server issues a token to a client upon its first request
- Www-authentication: query, that is, require the customer to provide the account and password
The response header usually contains the following content:
I’m the dividing line
Three, the actual combat part
For HTTP:
We know that Hypertext Transfer Protocol (HTTP) is a simple request-response Protocol that usually runs on top of TCP. It specifies what messages the client might send to the server and what responses it might get. The headers of the request and response messages are given in ASCII form; The message content has a MIME-like format.
Then the question comes, can we connect one to establish a TCP connection, and then splice the packet to the Web server using socket, can the server parse and respond?
The answer is yes.
1. Obtain the destination address
Say dry dry, take Baidu start it. First we get baidu’s IP, because HTTP protocol must have a Host request header.
ping www.baidu.com
Copy the code
Shell interaction is as follows:
2. Assemble packets
Following the HTTP request message in section 1, we assemble the message.
Echo -e 'GET/HTTP/1.1\r\nHost: 163.177.151.110:80\r\n\r\n'Copy the code
Note: the -e argument escapes characters such as \r\n
3. Establish the TCP connection
The exec 8 < > / dev/TCP / 163.177.151.110/80Copy the code
Note: there is a special file called /dev/tcp. Opening this file is like issuing a socket call to establish a socket connection. Reading and writing this file is like transferring data in the socket connection.
4. Write data to the Socket
Write the data to the Socket you just created
Echo -e 'GET/HTTP/1.1\r\nHost: 163.177.151.110:80\r\n\r\n' >&8Copy the code
5. Read response data
We read the data from file descriptor 8 using the cat command.
Here are the miracle moments:
cat <&8
Copy the code
6. Close the connection
exec 8<&-
Copy the code
Four, the last
This is the end of the article, my level is limited, I do not know how much can help you, to the last hope you give feedback, let me have the motivation to create.
The New Year is coming. I hope everyone will be strong and prosperous in the New Year.
And finally, if you can see all of you here, give it a thumbs up.
References:
- HTTP document – MDN
- HTTP- Baidu Encyclopedia
- HTTP messaging – Rookie tutorial