HTTP protocol detailed > look at http

I. Brief introduction to the application of HTTP protocol

The main features of the HTTP protocol can be summarized as follows:

1. Support client/server mode.
2. Simple and fast: When a customer requests a service from the server, it simply transmits the request method and path. The request method commonly has, POST. Each method specifies a different type of contact between the customer and the server. Because the HTTP protocol is simple, the HTTP server's program size is small, so the communication speed is fast.
3. Flexible: HTTP allows the transfer of any type of data object. The type being transmitted is marked by Content-type.
4. No connection: The meaning of no connection is to limit the processing of only one request per connection. When the server finishes processing the customer's request and receives the customer's answer, the connection is disconnected. In this way, the transmission time can be saved.
5. Stateless: The HTTP protocol is a stateless protocol. Stateless means that the protocol has no memory capacity for transactional processing. A lack of state means that if the previous information is required for subsequent processing, it must be re-routed, which may cause the amount of data to be transferred per connection to increase. On the other hand, it responds faster when the server does not need the previous information.

HTTP protocol for its users is actually transparent, unlike SMTP and other protocols, HTTP messages are not directly delivered to the user to see, the most common scenario is that the HTTP protocol will be handed over to the browser or other hypertext parsing software for processing, Hypertext can use any tag language, such as html,xsl,xml,xhtml.

(1) Static hypertext

Client directly through the URL request to the service retransmitting corresponding resources, the server directly to the database or file system deployed in the label language file to the client, which can include other URLs to enable the client again and other hosts on the network to send HTTP requests to recursively complete the resolution of the hypertext, such as the IMG tag in HTML.

(2) Dynamic hypertext

Dynamic hypertext requires software technology to create and process dynamic text, such as Cgi,javaservlet, in the URL '? ' After the dynamic section to parse and generate dynamic documents, and can be embedded in the scripting language delivered to the browser parsing engine to improve the efficiency of the dynamic document, so that unnecessary duplication of parts of the document to complete independent resolution, and even to implement the active document, A Java program or JavaScript script that runs the bytecode form directly on the document.

Two. HTTP Run transaction

(1) HTTP packet grouping

As shown in the two figure below, for a generic HTTP request and Response message model

Request message Response message

1. Request message

The exact format of an HTTP complete request message is as follows:

A. Request Line-method:

GET: Document requesting the Server

HEAD: Request information about the document, but not the document itself

POST: Send some information from the customer to the server

PUT: Sending documents to customers from the server

TRACE: Send back a request to arrive

CONNECT: Reserved

Delete: Deleting a Web page

Options: Ask about the option available

B. Request Line--url:

URL: The Uniform Resource Locator is the standard for any kind of information that is well known on the Internet, and the URL defines four things:

Protocol://HOST: Port/Path

Specific details do not belong to the category of HTTP content, for the moment do not repeat.

C. Request Line-Version:

Currently the latest version of HTTP is 1.1, the old version has 1.0, etc., the specific definition in the corresponding RFC can be found.

D. The first line of the request message: (This is also called the Head field in individual books)

The first line is the additional information that the customer sends to the server, with a quantity of zero to many, as shown in the format, each header row occupies a header name, a colon, a space, and a header value. The complete list of header values in the RFC and the classifications are as follows: (where the color is the more common header name)

A. Generic header: Can appear in the request message or in the response message. These are common headers that both the client and server can use. can provide some very useful common functionality between the client, the server, and other applications. No matter what type of message it is, it provides some useful information for it. For example, whether to build a request message or a response message, the date and time of the creation of the message is the same meaning, so the first to provide such information is common to both types of messages. A general informational header is given in the form of a table below.

General Informational Header:

Header description
Connection allows clients and servers to specify options related to request/response connections
Date and time flag indicating when the message was created
Mime-version gives the MIME version used by the sending side
Trailer If the message uses a chunked transmission encoding (chunked transfer encoding), it is possible to use this header to list the header set in the Message slipper (Trailer) section.
Transfer-encoding tells the receiver to ensure the reliable transmission of the message, the message adopted what encoding method.
Update gives the new version or protocol that the sending side might want to "upgrade"
Via shows the intermediary node through which the message passes (proxy, Gateway)

Universal Cache Header:

Header description
Cache-control used with message delivery cache indication
Pragma another way of sending instructions with a message, but not dedicated to caching

B. Request header: Provide more information about the request. The request header is a meaningful header in the request message. Used to describe who or what is sending a request, where the request originated, or the client's preferences and capabilities. The server can try to provide a better response to the client based on the client's information given by the request header.

Header description
CLIENT-IP provides the IP address of the machine running the client
From provides the e-mail address of the client user
Host name and port number of the server receiving the request
Referer provides the URL of the document containing the current request URI
Ua-color provides information about the display color of the client display
UA-CPU gives the type or manufacturer of the client CPU
US-DISP provides information about client display (screen) capabilities
Us-os gives the pixel information of the client display
Ua-pixels provides pixel information for the client display
User-agent will initiate the requested application name to inform the server (user-agent) User agent

The Accept header provides the client with a way to inform the server about its preferences and capabilities, including what they want, what they can use, and most importantly, what they don't want. This allows the server to make more informed decisions about what to send, based on this additional information. The Accept header will benefit both ends of the connection. The client gets what they want, and the server does not waste its time and bandwidth to send something that the client cannot use.

Header description
Accept tells the server which media types to send
Accept-charset tell the server which character sets to send
Accept-encoding tell the server which encoding to send
Accept-language tell the server which languages to send
TE tells the server which extended transfer encoding can be used

Conditional Request Header: Sometimes the client wants to add some restrictions to the request. For example, if a client already has a copy, it wants the server to transfer the document only if the document on the server differs from the client-owned copy. With the conditional request header, the client can add this restriction, requiring the server to ensure that a request is true before it is appropriate for the request.

Header description
Expect allows clients to list the server behavior required by a request
If-match if the entity tag matches the current entity tag of the document, or the document
If-modified-since this request is restricted unless the resource has been modified after a specified date
If-range allows conditional requests to a range of documents
If-unmodified-since this request is restricted unless the resource has not been modified after a specified date
Range if the server supports scope requests, the specified range of resources is requested

Security Request Header: HTTP itself supports a simple mechanism to challenge/respond to requests for authentication. This mechanism requires the client to authenticate itself before acquiring a specific resource, so that the transaction can be slightly more secure.

Header description
Authorization contains the data that the client provides to the server to authenticate itself
The Cookie client uses it to send a token to the server-he is not the real security header, but it is an implicit security feature
Cookie2 used to describe the cookie version supported on the requester side

Proxy request header: With the ubiquitous use of proxies on the Internet, several headers have been defined to help them work better.

Header description
Max-forword the maximum number of times a request is forwarded to another proxy or gateway on the path to the source-side server-used with the trace method
The proxy-authorization is the same as the Authorization header, but this header is used when authenticating with the agent.
The proxy-connection is the same as the Connection header, but this header is used when the agent establishes the connection.

C. response header: Provide more information about the response. The response message is set by its own response header. The response header provides some additional information to the client, such as who is sending the response, the function of the responder, and even some special instructions related to the response. These headers help the client to process the response and initiate a better request in the future.

Header description
Age (starting from initial creation) response duration
List of request methods that the public server supports for its resources
Retry-after If the resource is unavailable, retry the date or time again
Name and version of the server application software
Title to the HTML document, which is the source side of the HTML document.
Warning Some more detailed warning messages than the reason phrases

Negotiation header: If there are multiple representations of a resource-for example, if the server has a French and German translation of a document, http/1.1 can provide the server and client with the ability to negotiate resources.

Header description
Accept-ranges for this resource, the types of scopes that the server can accept
A list of other headers viewed by the Vary server may cause the response to change; that is, this is a header list, and the server picks out the most appropriate version of the resource to send to the client based on the contents of the header.

Security Response Header:

We have seen the security request header, which is essentially the response side of the HTTP Challenge/response authentication mechanism.

Header description

Proxy-authenticate the list of challenges from the agent to the client
Set-cookie is not a true security header, but it has security features; You can set a token on the client so that the server identifies the client.
Set-cookie2 is similar to Set-cookie.
Www-authenticate a list of challenges from the server to the client

D, Entity header: Describes the length and content of the subject, or the resource itself. There are many headers that can be used to describe the payload of an HTTP message. These headers may appear in both types of messages because the entity portion may be included in the request and response text. The entity header provides a large amount of information about the entity and its contents, from information about the object type to the various valid request methods that can be used on the resource. In summary, the entity header can tell the recipient of the message what it is dealing with.

Header description
Allow lists the request methods that can be performed on this entity
Location tells the client entity where it is actually located and where to direct the receiving end to the resource

Content Header: The content header provides specific information about the entity's content, describes its type, size, and other useful information needed to process it. For example, a Web browser can learn how to display objects by looking at the type of content returned.

Header description
Content-base the underlying URL to use when parsing relative URLs in the body
content-encoding arbitrary encoding of the principal execution
Content-language the most appropriate natural language to understand the subject
Content-length length or size of the body
Content-location where the resources are actually located
MD5 check of CONTENT-MD5 body
Content-range the byte range represented by this entity in the entire resource
Content-type the object model of this subject

Entity Cache header: The generic cache header describes how or when to cache. The cache header of an entity provides information about the cached entity, such as the information needed to verify that a cached copy of the resource is still valid, and a better estimate of the clues needed to properly invalidate the cached resource.

Header description
An ETAG entity tag related to this entity
Expires entity is not valid, to obtain the date and time of this entity from the original source side again
Last-modified the date and time that this entity was last modified

The first line is sometimes divided into multiple lines to improve readability, dividing its values into multiple continuation lines, with at least one space or a tab in front of each continuation line. The entity that requests the message is some kind of informational message that needs to be sent.

2. Response messages

The exact format of an HTTP full response message is as follows:

A. Status line-version: Same request line-version

B. Status line-Status code:

The approximate classification is as follows:

100-199 is used to specify certain actions that the client should be corresponding.
200-299 is used to indicate a successful request.
300-399 is used for files that have been moved and is often included in the locator header information to specify the new address information.
400-499 is used to indicate client-side errors.
500-599 is used to support server errors.

Specific status code see: http://www.cnblogs.com/lxinxuan/archive/2009/10/22/1588053.html

C. Status line-phrase: the so-called phrase is corresponding to the status code, such as the common 404 status code corresponding to the not found,403 corresponding forbidden

D. Header line of the response message: see header line of the request message

The entity of the response message differs from the request message, and the main store is the document sent by the server to the client, and if the response is not an error message, the entity is in the response message.

(2) Connection model

As shown, although the server uses port 80th as the receiving end of a TCP connection, HTTP itself is a stateless protocol, and the server does not retain information about the client, each time HTTP is always the client initiating the request, and then the server sends back the response.

About long connections and short connections:

Long connections are used by default from HTTP1.1, and the HTTP header connection:keep-alive is used in HTTP1.0 for experimental expansion of long connections. The long connection keeps the TCP connection open after the data transfer is complete, waiting for the same domain name to continue to use the channel to transmit data, which corresponds to a short connection, starting from HTTP1.1 to use Connection:close in the HTTP request message to notify you that you do not want to use a long connection. In a short connection, a TCP connection is established for each request/response, for example, if there are n images on the same server in a hypertext document, then it is necessary to turn on and off the N+1 TCP connection on the server where the image resides, and the short link will bring huge unnecessary overhead to the server. Also slows down the process of connection establishment and shutdown. After a long connection is used, the server allows the TCP connection to be kept to a reduced handshake, the server can close the connection when the client requests it or when the request is over, and in some cases the server does not know the length of the document to be sent, so the server will notify the client of the unknown length and closes the connection after sending the data, so the customer can know where the data is going to end. It is also possible to define the maximum usage time limit for TCP connections by defining the Keep-alive header in the header. Actually, the head has a connection:keep-alive. This header does not necessarily mean that the server will use long connections, and both the client and the service side can ignore this header definition. The connection mode diagram for the long connection is as follows:

Long connection mode. After the client has made a request to the server, how does the client determine that the server's data has been completed? In addition to the passive shutdown of HTTP TCP connections through the server shutdown connection, the message header field content-length can be used to determine whether the data transfer is complete, in bytes, Alternatively, you can use the message header field transfer-encoding to assist in the completion of the judgment, Transfer-encoding:clunk or transfer-encoding:clunked mode can divide the data into a piece of transmission, The specific format of the Clunk encoding is not mentioned here.

About cookies in http:

The essence of a cookie is a key-value pair, and when a client sends a request to the server, the browser looks for the cookie in the cookie directory, and if so, contains the corresponding cookie in the request. When this cookie is included in the request, the server can know that the customer is an old customer, and that the user and consumer of the cookie is the server, which is transparent to both the browser and the consumer. In the HTTP packet grouping, the header associated with its function is the cookie header and the Set-cookie header. The exact format is as follows:

Set-Cookie:value [ ;expires=date][ ;domain=domain][ ;path=path][ ;secure]

Cookie : value

Cookie:value1 ; value2 ; name1=value1

In Set-cookie, you can further determine the function of a cookie by defining the value of the option.

1. Expiration options (the Expires option)

Each option that follows the cookie value is split with semicolons and spaces, and each option specifies when the cookie should be sent to the server. The first option is expires, which specifies when a cookie will no longer be sent to the server, so the cookie may be deleted by the browser. For example:

1	Set-Cookie:name=Nicholas;expires=Sat, 02 May 2009 23:38:25 GMT

In the absence of the Expires option, the lifetime of the cookie is limited to a single session. The closing of the browser means the end of this session, so the session cookie only exists in the state where the browser remains open. That's why you often see a checkbox when you sign in to a web app and ask if you choose to store your login information: If you choose Yes, then a expires option will be appended to the login cookie. If the Expires option sets a past point in time, the cookie is immediately deleted.

2. Domain option

The next option is domain, which indicates which domain or domains the cookie will be sent to. By default, domain is set to the domain name of the page where the cookie was created. For example, the default value for the domain property of the cookie in this site is www.nczonline.com. The domain option is used to extend the number of domains that the cookie value is sent to. For example:

1	Set-Cookie:name=Nicholas;domain=nczonline.net

The value of domain setting must be the domain name that sends the Set-cookie message header. For example, I can't send a cookie to google.com because this creates a security issue. The illegal domain option is simply ignored.

3.Path Options (the path option)

Another way to control when a cookie message header is sent is to specify the path option. As with the domain option, path indicates that a URL path must exist in the requested resource before the cookie message header is sent. This comparison is done by string comparison of the Path property value with the requested URL from the beginning. If the characters match, a cookie message header is sent, for example:

1	Set-Cookie:name=Nicholas;path=/blog

In this example, the path option value matches/blog,/blogrool and so on, and any option that starts with/blog is legal. Note that the Path property is only compared after the domain option has been verified. The default value of the Path property is the path portion of the URL in which the Set-cookie message header is sent.

4.secure option (the secure option)

The last option is secure. Unlike other options, this option is just a token and has no other value. A secure cookie is sent to the server side only when the request is created over SSL and HTTPS. The content of this cookie means that it is of high value and may potentially be cracked to be transmitted in plain text form. For example

1	Set-Cookie:name=Nicholas;secure

In reality, confidential and sensitive information should never be stored or transmitted in cookies because the entire mechanism of cookies is inherently unsafe. By default, cookies transmitted on HTTPS links are automatically added with the secure option.

About the security of http:

HTTP itself does not provide security, however, by using Secure Sockets Layer (SSL) in the transport and application tiers, HTTP can be run in a secure environment where HTTPS,HTTPS can provide confidentiality, client and server authentication, and data integrity.

SSL is designed to provide security and compression services for the data generated by the application layer, in general SSL can receive data from any application-layer protocol, but at most the protocol for the application layer is that HTTP,SSL provides multiple services to the data from the application layer:

Shard: SSL divides data into 14 bytes of data shards with a length of less than or equal to 2

Compression: Data fragmentation is optional by using a lossless compression method negotiated by the client and server.

Message integrity: To protect the integrity of your data, SSL uses a key hash function to create a Mac.

Confidentiality: In order to provide confidentiality, the original data and Mac are encrypted with symmetric key encryption technology.

Group frame: First add a header to the encrypted payload and then pass the bad payload to the reliable Transport layer protocol.

Transferred from: http://www.cnblogs.com/guguli/p/4758937.html

HTTP protocol detailed > look at http