TCP status code
Here I use three explanation methods from the Internet
Way 1
closed: No connection is active or in progress
listen: The server is waiting for an incoming call
syn_recv: A connection request has arrived, waiting for confirmation
syn_sent: The application has started, opening a connection
established: Normal data transfer status
fin_wait1: The application says it has completed
fin_wait2 : The other side has agreed to release
itmed_wait: Wait for all packets to die
closing: Both sides try to close at the same
time time_wait: The other side has initialized a release
last_ack: Wait for all packets to die
Method 2
close : starting point, that is, the initial state;
listen : passively opened, the server-side state changes to the listen state (monitoring);
syn-recvd (synchronized reception): after the server-side receives syn, the status is syn, and sends syn+ack;
syn -sent (synchronization has been sent): after the application sends syn, the status is syn-sent;
established (established connection): after syn-recvd receives ack, the status is established, syn-sent receives syn+ack and sends ack , the status is established;
close_wait (closed waiting): After receiving the fin, the server sends ack, and the status changes to close_wait. If the server still has data to transmit at this time, then it will be sent until the data is sent. At this time, The server sends fin, and the status changes to last-ack;
fin-wait-1 : The application sends fin, preparing to disconnect the tcp connection, and the status changes from established to fin-wait-1;
fin-wait-2 : Application The client only received the ack signal from the server and did not receive the fin signal, indicating that the server still has data to transmit, so it is a semi-connection at this time;
time_wait : There are two ways to enter this state:
- 1. Enter from fin-wait-1. At this time, the application port receives fin+ack and sends ack to the server port;
- 2. fin-wait-2 enters. At this time, the application port receives fin and then sends ack to the server;
Time-wait is used to realize the reliability of TCP full-duplex connection and is used to resend the ack message that may be lost. It needs to last for 2 msl. If the application port does not receive fin within 2 msl after entering time_wait, , indicating that the last ack sent by the application has been received;
Method three
closed : initial state, indicating that the tcp connection is "closed" or "unopened".
listen : Indicates that a socket on the server is in listening state and can accept connections from clients.
syn_rcvd : Indicates that the server has received the syn message from the client requesting a connection. Under normal circumstances, this state is an intermediate state during the three-way handshake session when the server-side socket establishes a TCP connection. It is very short-lived. Basically, it is difficult to see this state using netstat, unless a monitoring program is deliberately written to change the three-way handshake. The last ack message during the TCP handshake will not be sent. When the tcp connection is in this state, it will enter the established state after receiving the ack message from the client.
syn_sent : This state echoes the syn_rcvd state. When the client socket executes connect() to connect, it first sends a syn message, and then enters the syn_sent state and waits for the server to send the second message in the three-way handshake. . The syn_sent status indicates that the client has sent a syn message.
established : Indicates that the tcp connection has been successfully established.
fin_wait_1 : This state needs to be explained carefully. In fact, the real meaning of both 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 actually means that 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 with the ack message, it enters the fin_wait_2 state. Of course, under actual normal circumstances, no matter what situation the other party is in, it should respond to the ack message immediately, so the fin_wait_1 status is generally difficult to see, and the fin_wait_2 status can sometimes still be seen using netstat.
fin_wait_2 : The origin of this state has been explained above. In fact, the socket in the fin_wait_2 state represents a semi-connection, that is, one party calls close() and actively requests to close the connection. Note: fin_wait_2 has no timeout (unlike the time_wait state). In this state, if the other party does not close (does not cooperate to complete the 4 wave processes), then this fin_wait_2 state will remain until the system restarts, and more and more fin_wait_2 states will appear. Will cause kernel crash.
time_wait : Indicates that the other party's fin message has been received and an ack message has been sent. The TCP connection in the time_wait state will wait for 2*msl (max segment lifetime, maximum segment lifetime, which refers to the longest survival time of a TCP message on the Internet. Each specific TCP protocol implementation must choose a certain MSL value, rfc 1122 recommends 2 minutes, but the traditional BSD implementation uses 30 seconds. Linux can see this value of this machine by cat /proc/sys/net/ipv4/tcp_fin_timeout), and then it can return to the closed and available state. If in the fin_wait_1 state, the other party receives a message with both the fin flag and the ack flag, it can directly enter the time_wait state without going through the fin_wait_2 state. (This situation should be the situation where four waving turns into three waving)
closing : This state should be rare in actual situations and is a relatively rare exception state. Under normal circumstances, when one party sends a fin message, it stands to reason that it should first receive (or receive at the same time) the other party's ack message, and then receive the other party's fin message. However, the closing status means that after one party sent the fin message, it did not receive the other party's ack message, but instead received the other party's fin message. Under what circumstances would this happen? That is, when both parties close() a socket at almost the same time, both parties will send fin messages at the same time. In this case, the closing state will appear, indicating that both parties are closing the socket connection.
close_wait : Indicates that it is waiting to be closed. How to understand it? When the other party closes () a socket and then sends a fin message to itself, your system will undoubtedly respond with an ack message to the other party. At this time, the tcp connection enters the close_wait state. Next, you need to check whether 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 your connection to the other party. If there is data, it depends on the program's policy and continues to be sent or discarded. Simply put, when you are in the close_wait state, what needs to be done is to wait for you to close the connection.
last_ack : When the passively closed party waits for the other party's ack message after sending the fin message, it is in the last_ack state. After receiving the ack message from the other party, it can enter the closed and available state.
The bit code is the TCP flag, and there are 6 types of markings:
ACK (acknowledgement confirmation)
PSH (push transmission)
FIN (finish)
RST (reset)
URG (urgent)
SYN (synchronous establishment of connection)
Sequence Number (sequence number)
Acknowledge Number (confirmation number)
The diagram of the whole process of Tcp connection and disconnection is as follows:
TCP state migration process:
客户端：
CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
服务端
CLOSED -> LISTEN->SYN_RECEIVED->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSE
[TCP/IP] Common HTTP status codes
1XX Informational status code Accepted request is being processed
2XX Success status code Request processing completed
3XX Redirect status code Additional action is required to complete the request
4XX Client error status code The server was unable to process the request
5XX Server error status code The server had an error processing the request
14 common HTTP status codes
1 200 OK
一切正常，对GET和POST请求的应答文档跟在后面
2 204 No Content
没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新
3 206 Partial Content
客户端发送了一个带有Range头的GET请求，服务器完成了它
4 301 Moved Permanently
客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
5 302 Found
类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。
6 303 See Other
类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取
7 304 Not Modified
客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
8 307 Temporary Redirect
和302（Found）相同。许多浏览器会错误地响应302应答进行重定向，即使原来的请求是 POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清楚地区分几个状态代码： 当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。
9 401 Unauthorized
客户试图未经授权访问受密码保护的页面。应答中会包含一个WWW-Authenticate头，浏览器据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求。
10 403 Forbidden
资源不可用。
11 404 Not Found
无法找到指定位置的资源
12 406 Not Acceptable
指定的资源已经找到，但它的MIME类型和客户在Accpet头中所指定的不兼容
13 500 Internal Server Error
服务器遇到了意料不到的情况，不能完成客户的请求
14 503 Service Unavailable
服务器由于维护或者负载过重未能应答。例如，Servlet可能在数据库连接池已满的情况下返回503。服务器返回503时可以提供一个Retry-After头