TCP Correlation (Control bit, 3 handshake, 4 wave, port number classification time_wait status ...) ）

TCP Message Format

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/85/9B/wKioL1epzQfRY5fxAACqF1nJug0426.png "title=" TCP message format. png "alt=" Wkiol1epzqfry5fxaacqf1njug0426.png "/>

The difference between Urg and PSH in one or 6 control positions:

(1) emergency Urg (URGent), when Urg=1, indicates that the tight- pressing pointer field is valid . It tells the operating system that there are emergency data in this message and should be transmitted as soon as possible (equivalent to high-priority data) instead of being routed in the original queue order. For example, a long program has been sent to run on a remote host, but later there are some problems that need to be canceled to run the program. Because the user sends the interrupt instruction from the keyboard (CONTROL+C), if no emergency data is used, then two characters are stored at the end of the cache receiving TCP . Only after all the data has been processed will the two characters be delivered to the recipient's application process. It took a long time to do so.

When Urg 1 o'clock, the sending application process should tell the other sender that TCP has emergency data to transmit. The sender TCP then inserts the emergency data to the front of the data in this section, and the data behind the emergency data is still normal data. This is used in conjunction with the Emergency pointer field in the header.

(2) push PSH (push) when two processes are communicating interactively, sometimes the application process at one end wants to be able to receive a response immediately after typing a command. In this case, TCP can use push operations. At this point, the sender TCP puts PSH 1, and immediately creates a message segment to send out. The receiver TCP receives the Psh=1 segment and delivers it to the receiver application process as soon as possible (i.e. "push" forward), rather than waiting for the entire receive cache to fill up before delivery.

Difference:

1.URG means not to enter the cache buffer directly handed over to the application application;

2.PSH means that each bit is separated into a packet (TCP is based on a stream that waits for subsequent input) and does not need to wait for subsequent characters. such as Telnet. After receiving the PSH, TCP submits the cache to the application process, regardless of any subsequent messages.

Two, 3 handshake

1.3-Time handshake process

TCP is the Transport layer protocol in the Internet, using three-time handshake protocols to establish a connection. When the active party sends a SYN connection request, wait for the other person to answer syn+ack[1], and eventually perform an ACK acknowledgment on the other's syn. This method of establishing a connection prevents the wrong connection from being generated, and the traffic control protocol used by TCP is a variable-sized sliding window protocol.

The process for the TCP three-time handshake is as follows:

(1) The client sends a SYN (SEQ=X) message to the server side and enters the Syn_send state.

(2) The server receives the SYN message, responds to a SYN (seq=y) ACK (ack=x+1) message, and enters the SYN_RECV state.

(3) The client receives the server-side SYN message, responds to an ACK (ack=y+1) message, and enters the established state. After the server receives an ACK, it also enters the established state.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M00/85/9B/wKioL1epzV_w8fbOAABEFSWEhY4566.png "title=" 3-time handshake. png "alt=" Wkiol1epzv_w8fboaabefswehy4566.png "/>

Three times the handshake is complete, the TCP client and server side successfully establish the connection and can begin transmitting data.

Shaking hands and waving is a need for one party to initiate the establishment.

2, why is 3 times handshake? Why not 2 times, or 4 times?

Reason: In the network send, there is a principle: to the current self-sent messages, they do not confirm whether the other party received, but can confirm that, when they receive the other side of the message, they can confirm that they sent the message before the other party is received.

The handshake is that the two sides confirm each other that they have received their message, so at least 3 times.

2 times, like

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/85/9B/wKioL1epzaCT-QZFAAA4gaYJ8Fw675.png "title=" 2-time handshake. png "alt=" Wkiol1epzact-qzfaaa4gayj8fw675.png "/>

The client sends a message to the server and the client receives a message from the server but only the client can confirm that he sent the message 1server received, but the message sent by the server is not confirmed by the client.

For example:

Scenario 1:(message lost in the middle) "assume two handshake" the client sends a request to the server, the server replies, but the reply is lost in the middle. The server thought the handshake was a success. But the client thinks it has failed, so the client re-sends the handshake new connection, but the server thinks the connection has been established, he waits for the client's message instead of the client's connection request, the client does not receive the request reply, unceasingly sends the request. Cause a deadlock.

Scenario 2: (Message lag arrives) "Assuming two handshake"

Normal situation: Clinet send a request connection is lost, the request server is confiscated, the client sends a connection request, the connection is established, the data is sent out, the connection is released. In this process, the client sends a total of 2 connection requests.

Exception: The client sends the first request connection message segment is not lost, but because the network problem is stranded, but after the connection has been released at some point to the server, and the server thought is a client sent a request connection message, A confirmation message is sent to the client, and the server considers the connection to be established, and the client does not send a request to the server to establish a connection, ignoring the acknowledgement from the server. The server, while waiting for the client to send a paper, will cause a deadlock. In the case of a three-time handshake, the client does not acknowledge confirmation from the server, and when the server does not receive confirmation from the client, the client is not required to establish a connection

Summary: actually 4 times 5 times 6 times ... Handshake can be, as long as 3 times and more than 3 times, both sides can confirm that the other received the message they sent.

3-time handshake a multiple confirmation is to prevent a failed request message segment from being re-routed to B, resulting in an error "Scenario 2"

Three, 4 wave process

1, the establishment of a connection requires three handshake, and terminate a connection to go through four handshake, which is caused by the semi-shutdown of TCP (Half-close). The exact process is shown. [1]

Termination of TCP connections

(1) An application process first calls close, which is said to perform "active close" on that side. TCP on that side then sends a FIN section indicating that the data has been sent.

(2) The peer of the fin is received to perform a "passive shutdown" (passive close), which is confirmed by TCP.

Note: The receive of fin is also passed as a file terminator (End-of-file) to the receive end application process, placed after any other data that has been queued for the application process, because the receipt of fin means that the receiving application process has no additional data to receive on the corresponding connection.

(3) After a period of time, the application process that receives this file terminator will call close to close its socket. This causes its TCP to also send a fin.

(4) The original sender TCP receiving this final fin (i.e. the end of the active shutdown) confirms the fin.

Since each direction requires a fin and an ACK, it usually requires 4 sub-sections.

Attention:

(1) "Usually" means that, in some cases, the fin of step 1 is sent along with the data, and the sections sent by step 2 and step 3 are from the end of the passive shutdown, and may be merged into a sub-section.

(2) Between step 2 and step 3, from the execution of the passive closed end to the execution of the active closed one end of the flow of data is possible, this is called "semi-closed" (half-close).

At this point, the client-to-server connection has been freed and the client cannot send data to the server, but the server-to-client connection is not released. It can also continue sending. This state is called a "semi-closed" state. This state will last for some time. The client enters the "Fin-wait-2" state after receiving the ACK message sent by the server, and the server enters the "close-wait" state.

(3) When a UNIX process terminates either voluntarily (calling exit or returning from the main function) or involuntarily (receiving a signal terminating the process), all open descriptors are closed, which also causes a fin to be emitted on any TCP connection that is still open.

Either the client or the server can perform an active shutdown on either side. Typically, the client performs an active shutdown, but some protocols, such as http/1.0, are actively shut down by the server.

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M01/85/9B/wKioL1epziyA0vD_AAECEI6gR9E046.png "title=" 4 times wave. png "alt=" Wkiol1epziya0vd_aaecei6gr9e046.png "/>

2. Why do you wave 4 times?

Client confirms that it sent the message "I want to disconnect" server has received (two times)

Server confirms that it sent "messages I want to disconnect" client has received (two times)

Iv. Status of Time_wait

1, the TIME_WAIT state is four times the server sends the fin to the client after terminating the connection to the State, the TIME_WAIT state is active to close the state that is unique "under the client actively shut down the server passive shutdown as an example."

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/85/9B/wKiom1epzqKxt4xXAABjU1gYE3I037.png "title=" time_ Wait.png "alt=" Wkiom1epzqkxt4xxaabju1gye3i037.png "/>

You can see that the TIME_WAIT state exists when the client receives the server fin and returns an ACK.

when in the TIME_WAIT state, we cannot create a new connection because the port is occupied.

2. time_wait state function

The reasons are two points:

(1) reliable termination of TCP connections

If the client in time_wait sends a message to the server to confirm that the packet is missing, the server will resend the fin segment, and the client must be in a state that can be received time_wait instead of the close state.

(2) ensure that the belated TCP segment has enough time to be identified and discarded

There is a TCP port in Linux that cannot be opened two or more times, and when the client is in the TIME_WAIT state, we will not be able to make a new connection using this port, and if there is no time_wait state, the new connection may receive data from the old connection. The time_wait duration is 2MSL (MSL's longest message life), which ensures that old data can be discarded because the largest amount of data in the network exists in MSL.

3, how to avoid time_wait State occupation resources?

the resource that is in the TIME_WAIT state is not freed by the kernel.

When TCP is in time_wait, it must wait for 2 MSL to time out to reclaim the port, and bind error:address already in is present once the TCP connection server exits unexpectedly without releasing the port number. How to solve?  

Problem Description: The server will kill the server immediately after connecting with the client and then start the server with the error Address already in use Linux medium up to a half minute to start the server

[Email protected] tcp]$/server_1_simplebind and listen success, wait accept...get Connect, IP is:13.0.0.0 port is:10 32^c[[email protected] tcp]$./server_1_simplebind Error, error code is:98, errno string is:address already in use

Workaround:

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M01/85/9B/wKioL1epzwaTLnGWAAAl1eJgRDM382.png "title=" Timewait workaround. png "alt=" Wkiol1epzwatlngwaaal1ejgrdm382.png "/>

options for setting the socket descriptor via socksetopt SO_REUSEADDR is 1 , even if the sock is in the TIME_WAIT state, the socket address that is bound to it can be reused immediately.

Five, port number

The port addresses in TCP and UDP segment structures are 16-bit and can have port numbers in the range of 0---65535 . The following classifications are available for these 65,536 port numbers:

(1) The known port number is 0-1023. These port numbers have IANA distribution and control. When possible, the same port number is assigned to TCP and UDP for the same given service. For example, 80 is used by the TCP and UDP protocol Web servers

(2) The registered port is 1024-49151 , which is not controlled by the IANA, but is registered by the IANA and provides a list of their usage to facilitate the entire population. When possible, the same port number is assigned to TCP and UDP for the same given service.

(3)49152-65535 is a dynamic or private port . IANA regardless of these ports, they are the ephemeral ports we call our usual.

Note: The UNIX system has the concept of a reserved port, which is less than 1024 of any port and can only be assigned to the super user process socket. Therefore, the well-known ports are reserved ports, and these ports must have administrator privileges when the server is started.

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M02/85/9B/wKioL1epz0WjBSJ3AAASaRpXSrE528.png "title=" Port number. png "alt=" Wkiol1epz0wjbsj3aaasarpxsre528.png "/>

This article is from the "City Hunter" blog, please be sure to keep this source http://alick.blog.51cto.com/10786574/1836284

TCP Correlation (Control bit, 3 handshake, 4 wave, port number classification time_wait status ...) ）