WCF basics: About socket. tcp. UDP

1. Establish a connection protocol (three-way handshake)

(1) the client sends a TCP packet with SYN flag to the server. This is packet 1 during the three-way handshake.

(2) The server responds to the client. This is the first packet in the three-way handshake. This packet carries both the ACK mark and SYN sign. Therefore, it indicates the response to the client SYN Packet. It also marks the SYN message to the client and asks whether the client is ready for data communication.

(3) The customer must re-respond to an ACK packet in the service segment, which is packet segment 3.

2. Connection termination agreement (four waves)

Because the TCP connection is full-duplexMust be disabled separately.. This principle is that when one party completes its data sending task, it can send a fin to terminate the connection in this direction. Receiving a fin only means that there is no data flow between the two parties. a tcp connection can still send data after receiving a fin. First, the party that closes the service will take the initiative to close the service, and the other party will passively close the service.

(1) The tcp client sends a fin to disable data transmission from the client to the server (packet segment 4 ).

(2) When the server receives the fin, it sends back an ACK and confirms that the serial number is 1 (packet segment 5 ). Like SYN, a fin occupies a sequence number.

(3) The server closes the client connection and sends a fin to the client (packet segment 6 ).

(4) The customer segment sends back the ACK message for confirmation, and sets the confirmation sequence number to receive the serial number plus 1 (packet segment 7 ).

Closed: There is nothing to say, indicating the initial state. Listen: this is also an easy-to-understand state, indicating that a socket on the server is in the listening state and can accept connections.

Syn_rcvd: This status indicates that the SYN packet is received. Normally, this status is an intermediate status of the server socket during the three-way handshake session when a TCP connection is established. It is very short, basically, you can hardly see this state with netstat unless you write a client to testProgramThe last ACK packet in the three TCP handshakes will not be sent. Therefore, when an ACK packet is received from the client, it enters the established status.

Syn_sent: This status echo syn_rcvd. When the client socket executes the connect connection, it first sends the SYN packet, and then it enters the syn_sent status, and wait for the server to send 2nd messages in the three-way handshake. Syn_sent status indicates that the client has sent Syn packets.

Established: This is easy to understand, indicating that the connection has been established.

Fin_wait_1: The fin_wait_1 and fin_wait_2 statuses both indicate waiting for the FIN packets of the other party. The difference between the two States is that the fin_wait_1 state is actually when the socket is in the established State, it wants to actively close the connection and send a FIN packet to the other party, the socket enters the fin_wait_1 state. When the other Party responds to the ACK packet, it enters the fin_wait_2 status. Of course, under normal circumstances, the other party should immediately respond to the ACK packet, regardless of the situation, therefore, the fin_wait_1 status is generally difficult to see, while the fin_wait_2 status is often seen using netstat.

Fin_wait_2: The above has already explained in detail this status. In fact, the socket in the fin_wait_2 status indicates a semi-connection, that is, either party requires a close connection, but also tells the other party, I have some data to send to you, and close the connection later.

Time_wait: Indicates that the other party's FIN packet is received, and the ACK packet is sent concurrently. After 2msl is sent, it can return to the available state of closed. If fin_wait_1 receives a message with both the fin mark and ACK mark, it can directly enter the time_wait status without passing through the fin_wait_2 status.

Closing: This status is special. It should be rare in actual situations and is a rare exception. Normally, when you send a FIN packet, you should first (or simultaneously) receive the ACK packet from the other party and then receive the FIN packet from the other party. However, the closing status indicates that after you send the FIN packet, you have not received the ACK packet from the other party, but have also received the FIN packet from the other party. Under what circumstances will this happen? In fact, it is not difficult to come to the conclusion that if both parties close a socket at the same time, both parties may send FIN packets at the same time, that is, the closing status may occur, both parties are closing the socket connection.

Close_wait: The meaning of this state is actually waiting to close. How can this problem be solved? When the other party closes a socket and sends a FIN packet to itself, your system will undoubtedly respond to an ACK packet to the other party, and then enters the close_wait status. Next, in fact, what you really need to consider is to check if you still have data to send to the other party. If not, you can close the socket and send the FIN packet to the other party, that is, close the connection. So what you need to do in close_wait is to wait for you to close the connection.

Last_ack: This status is easy to understand. It passively closes a side and waits for the other side's ACK packet after sending the FIN packet. After receiving the ACK message, you can enter the closed available status.

Finally, I have two answers. I have analyzed the results (not necessarily 100% correct)

1. Why is the three-way handshake while the four-way handshake when the connection is closed?This is because the socket in the listen status of the server can respond to ack and SYN after receiving the SYN Packet connection request) it is sent in a message. However, when the connection is closed, when the other party receives the fin Message notification, it only indicates that the other party has no data to send to you; but not all your data may have been sent to the other party, therefore, you may not close the socket immediately, that is, you may need to send some data to the other party, and then send the fin message to the other party to indicate that you agree to close the connection now, therefore, the ACK messages and fin messages are sent separately in most cases.

2. Why does the time_wait status still need to be 2 MSL before it can be returned to the closed status?This is because, although both parties agree to close the connection, and the four packets of the handshake are also coordinated and sent, it can be directly returned to the closed state (just like from syn_send to establish State), but because we must assume that the network is unreliable, you cannot guarantee that the last ACK message you sent will be received by the other party. Therefore, the socket in the last_ack status of the other party may fail to receive the ACK message due to timeout, but resend the fin message, therefore, the time_wait status is used to resend potentially lost ACK packets.

(Reprinted)

It is found that in many cases, the transmission of MSN files is slower than that of QQ, not to say that MSN is not fast, but most of the time it is really slower than QQ, even those who are nervous about me have noticed that some people have answered the question after Google. Basically, MSN uses TCP to transmit files, while QQ uses UDP, the rest is to demonstrate that TCP transmission files are not UDP fast. The following are some points of view:

1. TCP is reliable, and it is necessary to verify whether the data arrives and whether it is correct. UDP is unreliable and does a lot of things, so MSN's file transmission is slower than QQ.

I laughed at the time and used QQ for a long time. I never found any problems with the file transfer. I also used UDP as the protocol for a long time and did not use the application layer to verify retransmission.CodeI am afraid to write. This is the reason for failure.

2. TCP requires three handshakes to establish a connection, but UDP does not. Therefore, TCP is slow.

The three handshakes are indeed true. Fortunately, I am not so easy to be fooled. It takes a few seconds to shake hands before two people talk, but what is the speed of the conversation? If the ping value of the network reaches 300 ms, you may not be able to play online games, otherwise, the dying boss will be happy to find that you suddenly become a puppet, and you can beat and not fight back at will. In the end, you can only scold China Telecom Netcom and then rise again for a few minutes. However, for TCP, the ping value usually does not take one second for three handshakes. It seems unreliable to set this as the culprit for slowly uploading files. This is the reason for failure.

3. Once a link is established for TCP, the route is determined, while UDP is an uncertain route mode, and the route for which the speed is faster or faster.

In this case, the author does not understand the TCP/IP protocol. The TCP link is only a logic, and no physical link is established. The next step is the IP package. This package follows this path, the package may take another path, which is similar to TCP and UDP. The reason continues to fail.

4. Is the MSN server abroad?

Some truth, but I heard a friend from the United States say that he also likes to use QQ to upload files.

So what is going on? Is Microsoft not doing well? (In other words, I do think that MSN is slower than QQ's rapid progress.) QQ's fans began to shake their hands, and some people who do not like M $ began to lose bricks. No matter what the standpoint is, we still need to explore the facts. In the spirit of not seeking for a thorough solution, thin accumulation, and simple introduction, I think there are several possible reasons:

1. When both file transfer clients are behind NAT (you do not know what Nat means? For example, if multiple people share a cat's Internet access through a vro, you are usually behind Nat.) Technically, TCP is much more troublesome than UDP in this case. As long as UDP starts several negotiation packets that pass through NAT, the server needs to switch over the file data. The subsequent file data can be directly transmitted between the two clients. However, TCP can only be transferred through the server throughout the process, which one will be faster? Why does TCP need server transfer? Let's take a look at Nat. I have heard that some people can use raw sock to handle it. I don't have any intermediate servers.

2. However, even if the above conditions are not true, MSN is generally slower than QQ. The problem is that TCP is reliable and UDP is unreliable, but UDP is used for file transmission, you must write a verification protocol at the application layer. Otherwise, the uploaded files will be scolded by users if they have no arm or legs. It is not difficult to say it is an agreement. For example:

Long long ago, Jia Baoyu is in Beijing, and Lin Daiyu is in Changsha. How can I send a letter to each other! The journey is far away. How do I know if I receive the message? Call to ask? At that time, if I invented this, I didn't have to send a letter. I had to check whether Jia Ding had received a reply. If I find that my family has not returned for a month, most of them will be lost, and the traffic jam will be hit by a mountain thief or when I drive to Yangzhou, and I will send another person! This is what TCP does. UDP also needs to do so in the application layer protocol, but sometimes there are differences in implementation.

The road between Beijing and Changsha is not only run by one person. It is often congested. If Jia Ding hasn't returned for a long time, the TCP version of Jia Baoyu will send another mail, however, he will be more knowledgeable and will write less to reduce the sending speed. One letter a day may have been sent one week now. He thought, if everyone had done this, the road would not be so crowded. This method makes sense. If everyone wants to get plug-ins, they can only get plug-ins more and more plug-ins. In the end, everyone will not be able to move, so it is better to let each other wait in line slowly. The UDP version of Jia Baoyu is also so collectivism, then it is called a TCP-friendly stream, and it is not TCP-friendly if it only needs to squeeze it out.

If any TCP protocol finds congestion, it will immediately reduce its transmission speed. If the UDP-based protocol is not used in this way, the network will only get congested when the IP packet in the original congestion is added with the resend packet. In the end, all TCP streams that stick to the collectivism will be sacrificed, give the bandwidth to some non-TCP-friendly UDP streams. Therefore, unless the network conditions are very good, TCP is not a TCP-friendly protocol.

I doubt (I only doubt it, and I have no conditions or time to verify it). QQ's file transmission mechanism is not so TCP-friendly, and it is more "I Can ", in this way, although it is not a good thing for the entire network load, it is wise for a single user, as if you look at multi-thread download or P2P.