TCP three handshake four times to wave the detailed _tcp

The TCP creation process and the link-dismantling process are created automatically by the TCP/IP protocol stack relative to the socket developer. So developers do not need to control this process. But it is very helpful to understand the TCP underlying operating mechanism.

And for the network protocol engineers and so on, almost the content of the test. The company's enthusiasm for this problem is:-) to my surprise. Sometimes in the morning before the interview to emphasize this question, and repeat, almost everyone in the afternoon was asked this question.

So explain these two processes in detail here.

TCP Three-time handshake

The so-called three-time handshake (three-way handshake) means that when a TCP connection is established, the client and the server are required to send a total of 3 packages.

The purpose of the three handshake is to connect the server to the specified port, establish a TCP connection, and synchronize the serial number and acknowledgment number of both sides of the connection and exchange the TCP window size information. In the socket programming, the client executes connect (). The handshake will be triggered three times.

Handshake for the first time:
The client sends a TCP SYN Flag Location 1 packet indicating the port of the server to which the customer intends to connect, and the initial serial number x, stored in the header's serial number (Sequence) field.

Second handshake:
The server sends back a confirmation packet (ACK) response. That is, the SYN flag bit and ACK sign bits are both 1 and the confirmation number (acknowledgement) is set to the customer's I S n plus 1. That is, x+1.

Shake hands for the third time.
The client sends a confirmation packet (ACK) again. The SYN flag bit is a 0,ack flag bit of 1. and send the server to the ACK of the ordinal field +1, placed in the determination field sent to each other. and write +1 of the isn in the data segment.

SYN attack
In three handshake, after the server sends the Syn-ack, the TCP connection before receiving the client's ACK is called a Half-open connect. The server is in the SYN_RECV state. When an ACK is received, the server is transferred to the established state.
SYN attack is to attack the client in a short time to forge a large number of non-existent IP address, continue to send SYN packets to the server, the server reply to confirm the package, and wait for customer confirmation, because the source address is non-existent, the server needs to continue to resend until the timeout, these forged SYN packets will take up a long time disconnected queue, The normal SYN request is discarded, the target system runs slowly, the serious person causes network jam and even the system is paralyzed.
SYN attack is a typical DDoS attack. It is very convenient to detect SYN attacks, when you see a large number of semi-connected states on the server, especially the source IP address is random, it can be concluded that this is a SYN attack. Under Linux, you can check for SYN attacks as follows
Netstat-n-P TCP | grep syn_recv
Generally newer TCP/IP protocol stacks are modified to prevent SYN attack and modify TCP protocol implementation. The main methods are SynAttackProtect protection mechanism, SYN-cookie technology, increasing the maximum half connection and shortening the timeout time.
However, the SYN attack cannot be completely prevented.
TCP four times Wave
The removal of TCP connections requires four packets to be sent, so called four waves (Four-way handshake). The client or the server can initiate a wave action, in the socket programming, any side performs close () operation can produce wave operation.

See Wireshark Grab bag, the results of the measured grab bag did not strictly wave time series. I estimate that the time interval is too short to cause.
Note that the above field label lot and send the received content serial number, there may be a mistake, can't remember which, the back to look at

Part Two: Supplementing the TCP connection process

In the TCP/IP protocol, the TCP protocol provides a reliable connection service, using a three handshake to establish a connection, as shown in Figure 1.

(1) First handshake: When establishing a connection, client A sends a SYN packet (SYN=J) to Server B and enters the syn_send state, waiting for Server B to confirm.

(2) The second handshake: Server B received the SYN packet, must confirm customer a SYN (ACK=J+1), and also send a SYN packet (syn=k), that is Syn+ack packet, when server B into the SYN_RECV state.

(3) Third handshake: Client A receives Server B's Syn+ack packet, sends the confirmation packet ACK (ack=k+1) to Server B, this packet sends over, the client A and Server B enter established state, completes three times handshake.

Completes three handshake, the client and the server begin to transmit the data.

Figure 1 TCP Three-time handshake establish connection

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

(1) Client A sends a fin to turn off client A to Server B for data transfer (message segment 4).

(2) Server B receives this fin, it sends back an ACK, confirming that the serial number is the received number plus 1 (message Segment 5). Like Syn, a fin will occupy an ordinal number.

(3) Server B closes the connection to client A and sends a fin to client a (message segment 6).

(4) Client A sends back ACK message confirmation and sets the confirmation number to receive the serial number plus 1 (message segment 7).

TCP uses four waves to close the connection as shown in Figure 2.

Figure 2 TCP Four-time wave close connection

1. Why the Connection agreement is three times handshake, and closing the connection is four times handshake.

This is because the socket in the listen state of the server receives the SYN message connection request, it can send the ACK and SYN (ACK to respond, and SYN to sync) in a message. But when you close the connection, when receiving a fin message from each other, it simply means that the other party has no data to send to you, but not all of your data is sent to each other, so you may not be able to immediately close the socket, that is, you may also need to send some data to each other after the Send fin message to each other to indicate that you agree that the connection can now be closed, so it's ACK and fin messages are sent in most cases separately.

2. Why the TIME_WAIT state also needs to wait 2MSL before returning to the closed state.

This issue can refer to UNIX network Programming (third edition, 2.7 time_wait state).

The TIME_WAIT state consists of two reasons for existence.

(1) Reliable implementation of TCP Full-duplex link termination.

This is because although both parties agree to close the connection, and the 4 packets of the handshake are coordinated and sent, it is logically possible to return directly to the closed state (as it is from the Syn_send state to the establish state), but because we have to pretend that the network is unreliable, You can not guarantee that your final ACK message will be received by the other side, so the other side in the Last_ack state of the socket may be due to timeout did not receive an ACK message, and resend the fin message, so the role of this time_wait state is to resend the likely loss of the ACK message.

(2) Allow the old repeating section to fade through the network.

Suppose there is a TCP connection between the 12.106.32.254 1500 port and the 206.168.1.112.219 21 port. We close this link and establish another connection at the same IP address and port over a period of time. The latter link becomes the incarnation of the previous one. Because they have the same IP address and port number. TCP must prevent old repetitive groupings from a connection from being reproduced after the connection has terminated, thereby being misinterpreted as belonging to a certain new incarnation of the same link. To do this, TCP will not initiate a new incarnation of the link in the TIME_WAIT state. Since the duration of the time_wait state is twice times that of the MSL, this is enough to allow the group in one Direction to survive up to a maximum of MSL seconds to be discarded, and the answer to the other in the direction of the maximum surviving MSL seconds is discarded. By enforcing this rule, we can ensure that each TCP connection is successfully established. Repeated groupings from the previous incarnation of the link have disappeared on the network.

3. Why not use two times to shake hands to connect.

We know that 3 handshake to complete two important functions, both sides do a good job of sending data preparation (both sides know each other is ready), but also to allow the two sides to negotiate the initial serial number, this serial number in the handshake process is sent and confirmed.
Now it is possible to change the handshake of three times to just two times. As an example, consider the communication between the computer S and C, assuming C sends a connection request group to S, and S receives the packet and sends a confirmation response group. According to the two handshake agreement, S believes that the connection has been successfully established and can begin sending data groupings. However, if C is lost in the transmission of the answer packet of S, it will not know if S is ready, do not know what serial number the s builds up, and C even doubts whether S has received its own connection request grouping. In this case, C considers that the connection has not yet been successful and will ignore any data packets sent by S, waiting only for the connection to confirm the response group. and S sends the same grouping again after the group that it has timed out. This creates a deadlock.

Add:

A. By default (without changing the socket option), when you call Close (or closesocket, the following close does not repeat), if there is data in the send buffer, TCP will continue to send the data out.

B. Sending a fin only means that the end cannot continue sending data (the application tier cannot call send again), but it can also receive data.

C. How the application layer knows the end-to-end shutdown. Typically, in the simplest blocking model, when you call recv, if you return 0, the end is closed. The usual practice at this point is to call close too, so the TCP layer sends the fin and continues to shake hands four times. If you do not call Close, the side is fin_wait_2 and the end is in a close_wait state. This can write code to try.

D. In many cases, the TCP connection will be disconnected automatically by the TCP layer, such as you CTRL + C terminate your program, the TCP connection is still normal shutdown, you can write code to try.

Episode:

A special time_wait state:

From the above TCP connection Shutdown state transition diagram can be seen, the active shutdown side after sending the other Fin message confirmation (ACK) message, will enter the TIME_WAIT state. The TIME_WAIT state is also known as the 2MSL state.

What is 2MSL. The MSL is maximum Segment Lifetime, which is the maximum lifetime of the message, citing the words "TCP/IP Explanation": "It (MSL) is the longest time in the network before any message segment is discarded." "Well, 2MSL is twice times that time," he said. In fact, I don't think it's necessary to understand the exact meaning of this MSL, and what you need to understand is that when a TCP connection completes the exchange of four segments, the active shutdown side will continue to wait for a certain amount of time (2-4 minutes), even if both ends of the application end. You can try to write code, and then use Setstat to view it.

Why 2MSL is needed. According to the "TCP/IP detailed" and "the TCP/IP Guide" in the statement, there are two reasons:

First, to ensure that the ACK sent to each other successfully sent, how to guarantee. I think it might be sent through a timeout timer. This can be very difficult to demonstrate in code.

Second, the message may be confused, meaning that other times the connection may be treated as this connection. The direct reference to the "the TCP/IP Guide": The second is to provide a "buffering period" between the "end of the" connection ENT ones. If not to this period, the it is possible that packets from different connections could, mixed creating.

The impact of the TIME_WAIT state:

When one end of a connection is in a time_wait state, the connection will no longer be used. In fact, for us it is more relevant that this port will no longer be used. When a port is in the TIME_WAIT state (which should actually be the connection), this means that the TCP connection is not disconnected (completely disconnected), so if you bind this port, it will fail. For a server, if the server suddenly crash off, then it will not be able to reboot in 2MSL, because bind will fail. One way to solve this problem is to set the SO_REUSEADDR option for the socket. This option means you can reuse an address.

For the Time_wait episode:

When a TCP connection is established, the server side will continue to listen with the original port and use this port to communicate with the client. The client, by default, communicates with a server-side listening port by using a random port. Sometimes, for server-side security, we need to authenticate the client, which is to qualify a client for a particular port on the IP. A client can use bind to use a specific port. For the server side, when the SO_REUSEADDR option is set, it can be started within 2MSL and listen successful. But for the client, when the

When you use BIND and set SO_REUSEADDR, if you start within 2MSL, Bind will succeed, but connect on the Windows platform will fail. On Linux, there is no such problem. (My experimental platform: WinXP, ubuntu7.10)

To troubleshoot this problem with the Windows platform, you can set the So_linger option. The So_linger option determines the behavior of TCP when you call close. So_linger involves linger structure, if the set structure body L_onoff is not 0,l_linger to 0, then call Close when the TCP connection will be immediately disconnected, TCP will not send the buffer sent the data not sent, but immediately send a RST message to each other, The TCP connection will not enter the TIME_WAIT state at this time. As you can see, this solves the problem, but it is not safe. Setting the So_linger state in the above manner is equivalent to setting the So_dontlinger state.

Unexpected when disconnecting:

This does not count as an accident when a TCP connection occurs when there are physical surprises, such as a disconnected network cable, the TCP implementation on Linux still considers the connection valid, and Windows returns the error message after a certain amount of time. This may seem to be done by setting the so_keepalive option, but it is not known whether this option is valid for all platforms.

Part III: Often meet questions the difference between a TCP protocol and a UDP protocol is what the TCP protocol is connected to, and the connection means that TCP's client and server side must establish a connection through three handshake before the session ends and the connection ends. And UDP is connectionless TCP protocol to ensure that the data are sent in order, according to the order to arrive, provide a time-out to ensure reliability, but UDP does not guarantee the arrival of the order, and even do not guarantee the arrival, but only efforts to deliver, even if the sequence is sent, not guaranteed to be sent to. TCP protocol requires more resources, TCP header requires 20 bytes (not optional), UDP header field only 8 bytes. TCP has flow control and congestion control, UDP does not, network congestion does not affect the sending rate of the sender TCP is a one-to-one connection, while UDP can support one-to-one, many-to-many, one-to-many communication. TCP is oriented to the service of byte stream, UDP is the service of message. Introduction to TCP and UDP describes the process of establishing a connection and terminating a connection in a TCP protocol. A passage that helps to understand two pictures (source): Establish the connection: three times handshake close connection: four times waving three times handshake to establish a connection, the sender again send confirmation of the necessity. The main purpose is to prevent the failed connection request packets from suddenly spread to B, resulting in errors. It is assumed that the first connection request message segment issued by a has not been lost, but has been stranded for a long time at some network nodes and has been delayed until a certain time after the release of the connection to arrive at B, which is already a defunct message segment. However, after receiving this invalid connection request segment, B is mistaken for a new connection request and sends a confirmation message to a and agrees to establish the connection. Assuming that there is no three handshake, a new connection is established as soon as B confirms it, so that a lot of the resources of B are wasted by waiting for a to send the data. Four times to wave to release the connection, wait for the meaning of 2MSL. First, in order to ensure that a send the most of the ACK message segment can reach B. This ACK segment is likely to be lost so that B in the Last-ack state does not receive confirmation of the sent fin and ACK segments. B will time out to retransmit the fin and ACK segment, and a will be able to receive the retransmission Ack+fin message segment within 2MSL. Then a retransmission confirmation. Second, is to prevent the above mentioned invalid connection request message segment appears in this connection, a after sending the most of the ACK message segment, and then through 2MSL, you can make the connection duration of the time generated by all the message segments from the network disappeared.

What are some of the common applications that apply the TCP protocol and which are applied to the UDP protocol, and why they are so designed. The following applications are generally or must be implemented with UDP. Multicast information must be implemented with UDP, because TCP only supports one-to-one communication. If a scenario is mostly short information, suitable for UDP implementation, because UDP is based on the message segment, it directly to the upper application of the data encapsulated into a message segment, and then dropped in the network, if the amount of information is too large, will be fragmented in the link layer, affecting transmission efficiency. If a scenario is more performance than integrity and security, then suitable for UDP, such as multimedia applications, the lack of one or two frames does not affect the user experience, but the need for streaming media to reach faster, so more suitable for UDP if the request fast response, then UDP sounds more appropriate If you want to use the fast response of UDP advantages, but also to reliable transmission, then only to enter the layer of application to make their own rules. Common example of using UDP: Icq,qq chat module. Take QQ as an example of a note (reprint self-knowledge)

Landing using the TCP protocol and HTTP protocol, you and friends to send messages between the main use of UDP protocol, intranet files using Peer-to-peer technology. Always come to say:
1. The landing process, client clients use the TCP protocol to send information to server servers, HTTP protocol download information. After landing, there will be a TCP connection to remain online.
2. And friends send messages, client clients adopt UDP protocol, but need to forward through the server. In order to ensure the reliable transmission of messages, Tencent uses the upper layer protocol to ensure reliable transmission. If a message fails to send, the client prompts the message to fail and can resend it.
3. If it is in the intranet inside the two client file, QQ using Peer-to-peer technology, do not need a server relay.

From:http://www.cnblogs.com/zmlctt/p/3690998.html