https://blog.csdn.net/wensishuai/article/details/6429008
1. Establish a connection protocol (three-way handshake)
(1) The client sends a TCP packet with the SYN flag to the server. This is packet 1 during the three-way handshake.(2) The server responds to the client. This is the second message in the three-way handshake. This message carries both the ACK flag and the SYN flag. Therefore, it expresses the response to the SYN message of the client just now; at the same time, it marks the SYN to the client and asks whether the client is ready for data communication.
(3) The client must respond to the service segment again with an ACK message, which is segment 3.
2. Connection Termination Protocol (Four Waves)
Since TCP connections are full duplex, each direction must be closed individually. The principle is that when a party completes its data transmission task, it can send a FIN to terminate the connection in this direction. Receiving a FIN only means that there is no data flow in this direction, a TCP connection can still send data after receiving a FIN. The side that shuts down first will perform an active shutdown, while the other side performs a passive shutdown.
(1) The TCP client sends a FIN to close the data transfer from the client to the server (segment 4).
(2) When the server receives this FIN, it sends back an ACK, confirming that the sequence number is the received sequence number plus 1 (segment 5). Like SYN, a FIN will occupy a sequence number.
(3) The server closes the client's connection and sends a FIN to the client (segment 6).
(4) The client segment sends back an ACK message confirmation, and sets the confirmation sequence number to the received sequence number plus 1 (message segment 7).
CLOSED: There is nothing to say about this, it represents the initial state.
LISTEN: This is also a very easy to understand state, indicating that a SOCKET on the server side is in a listening state and can accept connections.
SYN_RCVD: This state indicates that a SYN message has been received. Under normal circumstances, this state is an intermediate state during the three-way handshake session of the server-side SOCKET when establishing a TCP connection. In this state, unless you specially write a client test program, the last ACK message in the three-way TCP handshake process will not be sent on purpose. Therefore, in this state, after receiving the ACK message from the client, it will enter the ESTABLISHED state.
SYN_SENT: This state echoes the SYN_RCVD vision. When the client SOCKET performs a CONNECT connection, it first sends a SYN message, so it immediately enters the SYN_SENT state and waits for the server to send the second message in the three-way handshake. The SYN_SENT state indicates that the client has sent a SYN message.
ESTABLISHED: This is easy to understand, indicating that the connection has been established.
FIN_WAIT_1: This state needs to be explained well. In fact, the real meaning of the FIN_WAIT_1 and FIN_WAIT_2 states is to wait for the other party's FIN message. The difference between these two states is: the FIN_WAIT_1 state is actually when the SOCKET is in the ESTABLISHED state, it wants to actively close the connection and sends a FIN message to the other party. At this time, the SOCKET enters the FIN_WAIT_1 state. When the other party responds to the ACK message, it enters the FIN_WAIT_2 state. Of course, under normal circumstances, the other party should immediately respond to the ACK message no matter what the situation is. Therefore, the FIN_WAIT_1 state is generally more difficult to see. The FIN_WAIT_2 status can sometimes be seen with netstat.
FIN_WAIT_2: This state has been explained in detail above. In fact, SOCKET in the state of FIN_WAIT_2 represents a semi-connection, that is, one party requests to close the connection, but also tells the other party that I still have some data to send to you for the time being. Close the connection.
TIME_WAIT: Indicates that the FIN message from the other party is received and an ACK message is sent. After 2MSL, it can return to the CLOSED available state. If in the FIN_WAIT_1 state, when receiving a message with both the FIN flag and the ACK flag from the other party, you can directly enter the TIME_WAIT state without going through the FIN_WAIT_2 state.
CLOSING: This state is quite special, it should be rare in actual situations, and it belongs to a relatively rare exception state. Under normal circumstances, when you send a FIN message, it stands to reason that you should first receive (or simultaneously receive) the other party's ACK message, and then receive the other party's FIN message. However, the CLOSING state means that after you send the FIN message, you did not receive the ACK message from the other party, but instead received the FIN message from the other party. Under what circumstances does this happen? In fact, after thinking about it, it is not difficult to come to a conclusion: that is, if both parties are closing a SOCKET at the same time, then there will be a situation where both parties send FIN messages at the same time, that is, the CLOSING state will appear, indicating that both parties are closing the SOCKET connection. .
CLOSE_WAIT: The meaning of this state actually means that it is waiting to close. How to understand it? When the other party closes a SOCKET and sends a FIN message to itself, your system will undoubtedly respond with an ACK message to the other party, and then enter the CLOSE_WAIT state. Next, in fact, what you really need to consider is to see if you still have data to send to the other party. If not, then you can close the SOCKET and send a FIN message to the other party, that is, close the connection. So you are in the CLOSE_WAIT state, what needs to be done is to wait for you to close the connection.
LAST_ACK: This state is relatively easy to understand. It is a passive shutdown party that waits for the other party's ACK message after sending the FIN message. When the ACK message is received, it can enter the CLOSED available state.
In the end, there are 2 answers to the questions, and the conclusions after my own analysis (not necessarily 100% correct)
1. Why is the connection establishment protocol a three-way handshake, but the connection closing is a four-way handshake?
This is because when the SOCKET in the LISTEN state of the server receives the connection establishment request of the SYN message, it can send ACK and SYN (ACK acts as a response, and SYN acts as a synchronization) in one packet to send. But when closing the connection, when receiving the other party's FIN message notification, it just means that the other party has no data to send to you; but not all your data is sent to the other party, so you may not close SOCKET immediately, That is, you may also need to send some data to the other party, and then send a FIN message to the other party to indicate that you agree that the connection can now be closed, so the ACK message and the FIN message here are sent separately in most cases.
2. Why does the TIME_WAIT state need to wait for 2MSL before returning to the CLOSED state?
This is because: although both parties agree to close the connection, and the 4 messages of the handshake have been coordinated and sent, it is reasonable to return to the CLOSED state directly (just like from the SYN_SEND state to the ESTABLISH state); but because we must The hypothetical network is unreliable, and you cannot guarantee that the last ACK message you send will be received by the other party. Therefore, the SOCKET in the LAST_ACK state of the other party may re-send the FIN message because it does not receive the ACK message due to the timeout. So the role of this TIME_WAIT state is to retransmit ACK messages that may be lost.
https://blog.csdn.net/slforeverlove/article/details/47018015
To say that the focus of computer networks must be the TCP/IP protocol family, these two protocols cover almost the entire network communication process. To figure out the communication process between the client and the server is basically the same as TCP/IP. So the next step is to introduce the protagonist of this article, the TCP protocol.
Let's briefly introduce the TCP protocol: it is a connection-oriented, reliable transport protocol. The connection can be abstracted into a quadruple (local_ip, local_port, remote_ip, remote_port), which uniquely identifies a TCP connection. Connection-oriented means that two communicating parties (two processes) must establish a TCP connection before exchanging data with each other. Reliability means that the connection established by the two parties is reliable, and there is basically no loss of data. To sum up, there are four main points of TCP, one is connection, two is reliable transmission, three is data arrival, and four is end-to-end flow control.
TCP header:
The first 20 bytes of the header of the TCP segment are fixed, and the following 4N bytes are options that can be increased as needed. Therefore, the minimum length of the TCP header is 20 bytes.
Source port number and destination port number: used to find the originating and receiving application processes. Different application processes have different port numbers. These two values plus the source IP address and destination IP address in the IP header uniquely identify a TCP connection.
Sometimes, an IP address and a port are called a socket.
Sequence number: It refers to the sequence number of the first byte of the data sent in this segment.
Acknowledgment number: It refers to the sequence number of the first data byte of the next segment of the message expected to be received from the other party. The receiver only acknowledges the highest sequence number in the data that arrives in sequence. For example, serial numbers 31, 32, and 33 are sent at the same time, but 31 is lost in the middle, and 32 and 33 arrive. At this time, the confirmation number given by the receiver is still 31, not 3 2 or 33.
Data offset: Refers to how far the data start of the TCP segment is from the start of the TCP segment.
Reserve:
The meanings of the 6 control bits are as follows:
Urgent URG: Urgent pointer field. When URG=1, it means that there is urgent data in the system, which should be transmitted as soon as possible instead of in the original queuing order.
Acknowledgment ACK: The acknowledgment number field is only valid when ACK=1. TCP stipulates that all transmitted segments should have ACK set to 1 after the connection is established.
Push PSH: When two application processes communicate interactively, sometimes the application process at one end expects to receive a response from the other side immediately after typing a command. In this case, TCP can use the push operation.
Reset RST: When RST=1, it indicates that there is a serious error in the TCP connection (such as due to a host crash or other reasons), the connection must be released, and then the transport connection is re-established.
Synchronization SYN: Used to synchronize the sequence number when the connection is established. When SYN=1 and ACK=0, it indicates that this is a connection request segment. If the other party agrees to establish a connection, it should set SYN=1 and ACK=1 in the message segment of the response. Therefore, SYN=1 indicates that this is a connection request segment or a connection receive segment.
Terminate FIN: used to release a connection. When FIN=1, it indicates that the data sent by this segment has been sent, and the transport connection is required to be released.
Window: Refers to the receiving window of the party sending this segment. The window value tells the other party: from the confirmation number in the header of this segment, the receiver currently allows the other party to send the amount of data.
Checksum: The checksum is the header and the data part.
Urgent pointer: only useful when URG=1.
Establishment and Termination of TCP
1. The establishment of TCP
It is almost known that the establishment of TCP requires three-way handshake, request-response-reconfirmation, in order to establish a reliable TCP connection. Please refer to the following description for the specific process:
If client A wants to communicate with server B, the process of establishing a connection is divided into the following three steps:
The first handshake: Host A sends a bit code of syn=1, and randomly generates a data packet with seq number=1234567 to the server. Host B is known by SYN=1, A requests to establish a connection, and A enters the SYN_SENT state;
The second handshake: Host B needs to confirm the online information after receiving the request, and sends ack number=(host A's seq+1), syn=1, ack=1, randomly generates a packet of seq=7654321, and B enters SYN_RCVD condition;
The third handshake: After host A receives it, check whether the ack number is correct, that is, whether the seq number+1 sent for the first time, and whether the bit code ack is 1, if it is correct, host A will send the ack number=(host B's seq+1), ack=1, after host B receives it and confirms the seq value and ack=1, the connection is established successfully, and A enters the ESTABLISHED state.
After completing the three-way handshake, host A and host B begin to transmit data.
Q1: Why three-way handshake instead of two-way handshake when establishing a connection?
It is to prevent the invalid connection request segment from being suddenly transmitted to the server, resulting in an error.
Q2: SYN attack is a typical DDOS attack, briefly describe its principle.
During the three-way handshake, after the server sends SYN and ACK, the connection before receiving the ACK from the client becomes a semi-connection. At this time, the server is in the SYN_RCVD state and enters the ESTABLISHED state after receiving the ACK from the client. SYN attack is to use this time interval to forge a large number of non-existing IP addresses to continuously send SYN packets to the server, the server replies to the confirmation packet, and waits for the confirmation of the client. Since the source address does not exist, the server needs to retransmit continuously until the timeout. These forged SYN packets will occupy the unconnected queue for a long time, while normal SYN requests are discarded, and the target system runs slowly, causing serious network paralysis. So most operating systems idle the number of half-connections.
2. Termination of TCP
Since TCP is a full-duplex communication mode, that is, both parties in the communication can be both the sender and the receiver of data, so each direction must be closed separately. This feature causes the termination of TCP to require four waves of hands. The specific process of waving four hands is as follows:
Specifically, the following four steps:
1. One of the connected parties first calls close() to initiate an active close. This api will prompt the TCP transport layer to send a FIN packet to the remote peer. This FIN packet indicates that the application of the party that initiated the active close will no longer send data;
2. After receiving the remote peer of the FIN packet, the transport layer replies with an ACK packet confirmation for the other party's FIN packet (the packet sequence of ACK is based on the addition of 1 to the FIN packet);
3. After the application of the application layer receives the EOF (end of file, the FIN packet of the other party is passed to the application of the application layer as EOF), it knows that this connection will not have data transmission, so it also calls close() to close the connection. , the close will prompt the transport layer to send a FIN packet;
4. After receiving the FIN packet from the remote peer, the peer that initiated the active shutdown replies with an ACK packet. At this point, the TCP connection is closed.
这里出现的几种状态要搞清楚它们的含义：
FIN_WAIT 1：主动关闭的一方在发送FIN包后，此时该socket进入FIN_WAIT 1状态；
FIN_WAIT 2：主动关闭的一方收到对方的ACK后，进入FIN_WAIT 2. FIN_WAIT 1和FIN_WAIT 2这两种状态实际上都是在等待对方的FIN报文；
TIME_WAIT：表示收到了对方的FIN包，并发送了ACK包后的状态，也称为2MSL状态；
CLOSE_WAIT：表示正在等待关闭；
LAST_ACK：被动关闭的一方在发送FIN包后，等待对方的ACK包的时候，当收到对方的ACK包后，立马进入CLOSED状态。
Q1：为什么需要TIME_WAIT状态，即为什么需要等待2MSL？
MSL(Max Segment Life)是一个报文段在网络上最大的生存时间。
这里有两个原因需要TIME_WAIT阶段：
第一点：为实现TCP这种全双工（full-duplex）连接的可靠释放
如果客户端在发完ACK之后直接进入CLOSED状态，若由于某种原因这个ACK丢失，那么服务器由于超时将重传FIN包，而此时客户端已经关闭连接，就找不到与重发的FIN包对应的连接，最后服务器收到的将是RST而不是ACK，服务器以为是连接错误而把问题报告给上层。这样的情况虽然不会导致数据丢失，但是却导致TCP协议不可靠。因此，客户端发完ACK之后必须维护这条连接直至2MSL的时间结束。
第二点：为使旧的数据包在网络因过期而消失
若不存在TIME_WAIT阶段，若有一个新的四元组(local_ip,local_port,rempte_ip,remote_port)建立一条新的TCP连接。由于TCP协议栈是无法区分前后两条连接是否相同，在它看来，这条连接跟上一个关闭的连接使用的端口号完全相同。而等待2MSL的时间，保证网络中旧的数据包已经完全消失，这样建立新的连接时可以使用旧的端口号，避免两次连接数据错乱的情况。
Q2：为什么TCP建立连接时是三次握手，而关闭连接时是四次挥手？
这是由于TCP传输协议是全双工的原因造成的。
在建立连接时，服务器收到客户端的SYN包后，可以将应答的ACK包和同步的SYN包放在同一个报文里发送给客户端。但在关闭连接时，当收到对方的FIN包后，仅仅表示对方没有数据传给你了，并不表示你的所有数据都已经传给了对方，因此不必马上关闭SOCKET，先发送一个ACK包确认已收到对方的关闭请求。然后等你的所有数据都发送完了再发送一个FIN包给对方表示同意关闭连接，因此ACK和FIN需要分开发送，故比建立连接时多了一个交互过程。
TCP的流量控制
如果发送方发送的太快，而接收方来不及接收，这样的情况就有可能导致数据丢失。所谓流量控制就是控制发送方的速率，不要让其发送的太快，使得接受方来得及接收。TCP利用滑动窗口协议实现流量控制。
滑动窗口协议允许发送方和接收方各自设置自己的缓存区大小，并且发送方在停止等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此可以提高传输效率。
1、可变滑动窗口
设A向B发送数据，B告知A当前我的rwnd=400,那么发送方A的发送窗口不能超过接收方的接收窗口大小。注意，窗口大小的单位是字节，ACK是确认位，ack是确认序号。
由上图可知，接收方B进行了三次窗口大小设置，第一次是400，第二次是300，最后结束时是0。这里有一个问题是当B设置当前自己的接收窗口大小为0，表示不让A发送数据。A会停止等待一段时间后，等B的缓冲区大小有了富裕，就发送报文通知A可以继续发送数据了。但是这个通知报文有可能丢失，于是就出现A等待B的通知，而B等待A的数据的死锁状态。为了解决这个问题，TCP引入了坚持计时器。当A收到B的零窗口通知时，就启用该计时器，时间一到就发送一个字节的探测报文，对方在此时回应自己的窗口大小，如果仍为0，则重设计时器，继续等待，直至窗口打开。
2、传输效率
TCP使用Negle算法，它只允许一个TCP连接上最多只有一个未被确认的未完成的小分组。
TCP的四种计时器
1、超时重传计时器
TCP是可靠的传输协议，在网络交互的过程中，由于TCP报文是封装在IP中的，而IP是无连接的，就可能导致报文在交互的过程中丢失。因此当TCP发送报文时，就会设置一个超时重传计时器，如果计时器溢出，还没有收到来自对方的确认，它就重传该报文。
2、坚持计时器
是为了解决零窗口大小通知时可能发生的死锁状态。
3、保活计时器
是为了防止在两个TCP连接之间出现的长时间的空闲。若客户端打开了服务器的连接，并且发送了数据，之后就保持沉默状态，也许这个客户发生了故障，但是这个连接会一直处于打开状态。因此在大多数的服务器中设置一个保活计时器，每当服务器接收到客户端的报文时，就将该计时器复位。若发送了10个探测报文时，客户端仍然无应答，则关闭该连接。
4、时间等待计时器
时间等待计时器是在终止TCP连接时的四次握手的时候使用的。时间等待计时器是用来记录2MSL这个时间的，当计时器到了2MSL，客服端才能断开连接。
TCP是如何实现可靠传输的？
可靠传输是TCP的一大特色，它主要从确认连接、检验数据、重新排序、丢重和流量控制这几个方面来提供可靠性的：
1、 当TCP收到对方发来的报文后，会回复一个确认包表明以已收到对方的报文。
2、 当TCP发送一个报文后，会启动一个超时重传计时器，等待对方确认收到这个报文。如果计时器溢出后未收到这个确认，那么将重传这个报文。
3、 TCP将保持它的首部和数据的检验和。这是一个端到端的检验，用以检测数据在传输过程中有无发生差错。若检验和有错，则TCP会丢弃这个报文和不回复确认，等待对方超时重传。
4、 由于TCP报文段是作为IP数据来传输的，而IP数据报的到达可能会失序，因此TCP会对数据进行重新排序，将正确顺序上交给应用层。
5、 由于IP数据会发生重复，因此TCP的接收端必须丢弃重复的数据。
6、 TCP采用流量控制使得发送端只能发送小于接收端窗口大小的报文，以防止较快主机致使较慢主机的缓冲区溢出，从而防止数据丢失。
TCP和UDP的区别
1、 TCP是面向连接的，可靠的传输协议，虽然说网络的不稳定和不安全特性决定了无论多少次握手都不能保证可靠的传输，而TCP的三次握手在很大程度上保证了连接的可靠性；UDP是面向非连接的，在传输数据之前双方不建立连接，接收方对收到的报文不进行确认，当然发送方也不知道报文到底到达目的地没有，也不进行重发，所以UDP是不可靠的。
2、 由于1的特点导致UDP的开销小，传输效率高，实时性较好。
所以使用UDP的QQ比使用TCP的MSN传输文件较快，但并不说明QQ不安全的， 因为程序员可以手动对UDP的数据收发进行确认，比如对发送方的数据进行编号等。