TCP protocol and Web service fundamentals

The TCP protocol works in the transport layer of the OSI model, providing a reliable connection-oriented service whose reliability lies in establishing an end-to-end virtual circuit on both sides of the communication, establishing communication through three handshakes, and requiring four handshakes to disconnect the communication. The connection model is as follows:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/57/34/wKioL1SVAyGAqF47AAIy7bia9XE438.jpg "title=" The interactive process for TCP connections. png "alt=" wkiol1svaygaqf47aaiy7bia9xe438.jpg "/>

1. Establish Connection Agreement (three handshake)

(1) The client sends a TCP message with a SYN flag to the server. (Message 1)

(2) A TCP message with an ACK flag and a SYN flag on the client side of the server response. (Message 2). Indicates the response to the client's SYN message, and also flags the SYN to the client, asking the client if it is ready for data communication.

(3) The client responds again to a TCP message with an ACK flag on the server side. (Message 3)

2. Connection Termination protocol (four handshake)

Because TCP connections are full-duplex, each direction must be closed separately. The principle is that when a party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means there is no data flow in this direction, and a TCP connection can still send data after receiving a fin. The first party to close will perform an active shutdown, while the other side performs a passive shutdown.

(1) The TCP client sends a fin to turn off the client-to-server data transfer (message 4).

(2) The server receives this fin, it sends back an ACK. (Message 5).

(3) The server shuts down the client connection and sends a FIN to the client (message 6).

(4) The client sends back ACK message acknowledgement (message 7).

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/57/37/wKiom1SVArHS6YaIAAL8eAJDxfA592.jpg "title=" TCP state transition diagram. jpg "alt=" wkiom1svarhs6yaiaal8eajdxfa592.jpg "/>

CLOSED: Indicates the initial state.

LISTEN: Indicates that a socket socket socket on the server side is listening and can accept the connection.

Syn_sent: This state indicates that the client has sent a SYN message. When the client socket socket performs a connect connection, it sends a SYN message first, so it then enters the syn_sent state and waits for the server to send the 2nd message in the three handshake.

SYN_RCVD: This status indicates that a SYN message is received, under normal circumstances, this state is a server-side socket socket in the establishment of a TCP connection during the three handshake session in the process of an intermediate state, very short, basically with Netstat is difficult to see this state. Therefore, when the ACK message is received from the client, it goes into the established state.

Established: Indicates that the connection has been established.

Fin_wait_1: This state is actually when the socket socket is in the established state, it wants to actively close the connection, send the FIN message to the other side, when the socket socket is entered into the fin_wait_1 state. And when the other party responds to the ACK message, then into the fin_wait_2 state, of course, under the actual normal circumstances, regardless of the circumstances of each other, should immediately respond to the ACK message, so fin_wait_1 state is generally more difficult to see, and Fin_wait_ 2 states are also often seen with netstat.

Fin_wait_2: In fact, the socket socket in the fin_wait_2 state, that is, a semi-connection, that is, one side asked to close the connection, but also tell the other side, I have some data to send to you, and then close the connection later.

Time_wait: Said to receive the other side of the fin message, and sent out an ACK message, just wait for 2MSL to return to the closed usable state. If the fin_wait_1 state, received the other side with the FIN flag and the ACK flag message, you can directly into the time_wait state, without having to go through the fin_wait_2 state.

Close_wait: The meaning of this state is actually expressed in waiting to be closed. How do you understand it? When the other side closes a socket socket and sends a FIN message to itself, the system will undoubtedly respond to an ACK message to the other, and then enter the Close_wait state. Next, the real thing you really need to consider is whether or not you have the data sent to the other person, if not, then you can close the socket socket, send fin messages to each other, that is, close the connection. So what you need to accomplish in the close_wait state is waiting for you to close the connection.

Last_ack: It is a passive shutdown after sending a fin message and finally waiting for the other party's ACK message. When an ACK message is received, it is also possible to enter the closed available state.

The Web service is a C/s structure that uses the TCP-based HTTP protocol to accomplish client-server data interaction. The client uses a user agent (such as a browser, etc.) to establish a connection to the server, while the server listens on TCP port 80, waiting for the client's connection request.

Once the web transaction is the client making the request, the server side issues the corresponding interactive process as follows:

Establish connection: Receive client's connection request, (3 TCP handshake, identify client IP address according to client's HTTP request message).

Receive requests: Receive HTTP request messages from clients, read specific resource requests

Processing request: The HTTP request message parsing, according to the HTTP request packet header, to obtain the client requested resources and other information.

Access resource: Access the resource's storage directory according to the requested resource

Build a response message: Build the requested resource information into a response message

Send Response message: Send the response message back to the client

Log access logs: Log connection requests and resource request information from the client to the HTTP log

The Web service that implements the HTTP protocol is a stateless protocol that provides two ways to complete user responses in both persistent and non-persistent connections. HTTP has HTTP request and HTTP response of two message formats. Both of these messages are made up of three parts:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/57/35/wKioL1SVFrnwRIDdAAD_QIzhwRk154.jpg "title=" HTTP component. png "alt=" wkiol1svfrnwriddaad_qizhwrk154.jpg "/>

HTTP Request message Format:

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M00/57/35/wKioL1SVFumSJPOcAACtqAHCvTg456.jpg "title=" http Request message format. png "alt=" wkiol1svfumsjpocaactqahcvtg456.jpg "/>

method: means the action that the client wants to perform on the server resource;

Common methods of HTTP <method>:

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/57/35/wKioL1SVF3Sz4LMZAAKOAUO1JWo171.jpg "title=" HTTP common methods. png "alt=" wkiol1svf3sz4lmzaakoauo1jwo171.jpg "/>

Request-url: The request URL, the specific resource path requested, can be a relative URL, and also an absolute URL

version: HTTP protocol versions, http/1.1,http/1.0.

Header:

General header: Both request and response messages can be used;

Date: The time the message was created;

Connection: Specify options related to request/response

Via: Displays the intermediate node through which the message passes;

Cache-control: Cache Control

A common request header

A. Informational Header:

CLIENT-IP: Client IP

Host: hostname and port number of the requested server

Referer: An upper-level resource URL containing the URL of the currently requested resource;

User-agent: Client Agent

b.accept Header:

Accept: The type of media that the notification server can send, MIME

Accept-charset: The character set that the notification server can send

Accept-encoding: The notification server is able to send encoding, such as gzip

Accept-language: The language that the notification server can send

C. Conditional request Header:

Expect: The type of media expected to be sent by the server

If-modified-since: Whether a change has occurred since the specified time;

If-none-match: The ETag of the locally cached document does not match the etag of the server-side document;

D. Security Request Header:

Authorization: Send authentication information to the server;

Cookie: Customer service sends the identity to the server;

E. Proxy request header:

Proxy-authorization: Similar to Authorization, but this is used when authenticating with an agent

HTTP Response message Format:

650) this.width=650; "src=" http://s3.51cto.com/wyfs02/M01/57/35/wKioL1SVGAmRZMShAADB_O_sCx8549.jpg "title=" http Response message format. png "alt=" wkiol1svgamrzmshaadb_o_scx8549.jpg "/>

version: HTTP protocol versions

Status: State code, three-digit number, first digit used to describe the status category;

Response Status code for http:

100-199:100-101 hint information, the rest has not been defined

200-299:200-206 success, the rest has not yet been defined

300-399:300-305 Redirect, others not yet defined

400-499:400-415 Client error, remainder not defined

500-599:500-505 Service-side error, the rest has not been defined

200: Successful, all requested data is sent through the body portion of the response message, the reason phrase is OK

301: The requested URL has been removed, but the response message header indicates where the resource is now located by location; The reason phrase is moved Permanently

302: Similar to 301, but in the response message header through the location resource's temporary position; The reason phrase is found

304: The customer makes a conditional request, if the server discovers that the resource has not changed, it can tell the client through the response message; The reason phrase is not Modified

401: Need to enter account number and password, reason phrase is unauhtorized

403: the request is forbidden; The reason phrase is forbidden

404: The server cannot find the resource corresponding to the requested URL, the reason phrase is not Found

500: Server internal error, reason phrase Internal server error

502: The proxy server received a pseudo-response from the backend service; The reason phrase is bad Gateway

reason-phrase: The reason phrase, the code readable version of the State;

Headers:

General header: Both request and response messages can be used;

Date: The time the message was created;

Connection: Specify options related to request/response

Via: Displays the intermediate node through which the message passes;

Cache-control: Cache Control

A common response header:

A. Informational Header:

Age: Duration of response

Server: Notifies the client server of the version

B. Consultation header:

Vary: Server and client Negotiate response format for client view

C. Security response Header:

Www-authentication: Send authentication challenge information to client;

Set-cookie: Set cookies to send identity tokens to the client;

Proxy-authentication: Agent sends authentication challenge information to client

Example: Access HTTP request and HTTP response messages for the www.lcu.edu.com host

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/57/38/wKiom1SVF6uDuiGVAAKc9K_yKTU950.jpg "title=" HttpRequest, httpresponse instance. png "alt=" wkiom1svf6uduigvaakc9k_yktu950.jpg "/>

This article is from the "Huaguoshan II" blog, please be sure to keep this source http://948555452.blog.51cto.com/9146446/1591962

TCP protocol and Web service fundamentals