Đối với mỗi trạng thái, trong một khoảng thời gian cụ thể, bản thân nó sẽ thể hiện một trạng thái cụ thể. Lấy ví dụ về điện thoại di động, nó có thể ở trạng thái RÃNH RỖI (IDLE), BÁO ĐỘNG (ALERTING), KẾT NỐI (CONNECTED) v.v. Một tiến trình có thể ở trạng thái ĐƯỢC TẠO (CREATED), SẴN SÀNG (READY), BỊ CHẶN (BLOCKED), ĐANG CHẠY (RUNNING), KẾT THÚC (DEAD). Khi các sự kiện cụ thể xảy ra, trạng thái có thể chuyển từ trạng thái này sang trạng thái khác. Đối với mỗi trạng thá, chúng ta có thể nói về các loại trạng thái khác nhau từ các góc nhìn khác nhau, hoặc các chiều khác nhau. Trong trường hợp này, tôi lưu ý đến sự truyền tải của các điểm cuối TCP.

State transmission chart

People usually use a state transmission diagram to describe the state transformations of an item. Before sketching a diagram, there is something that should be clarified. We must tell explicitly the item that we need to describe and list all the states during the whole transformation and the events that triggered the transformation. I still take the cell phone as an example. The phone is the object that has IDLE, SHUTDOWN, ALERTING, and CONNECTED states, the events triggering the transmission are shown with arrows.

TCP endpoints state transmission

TCP protocol describes the communication from endpoint to endpoint. The TCP state transmission diagram describes the endpoints’ state change. It is actually the transmission control block in the os kernel (in most conditions), from the application layer, we can treat it as the socket state transformation. Let’s review the whole process of a TCP segment sending and receiving, the connection is initiated with 3 segments, then established, and shut down with 4 segments(normally). For each endpoint, as the TCP segment’s sending and receiving, the state is changing. I presume there’s no exception during the communication, and the change will be as follows,

The initial state for each point is CLOSED. After the server calls the function Accept(), and the state changes from CLOSED to LISTEN, and stay in LISTEN until an SYN from a client is received. Sometime later, A client sends a [1.SYN] to request a connection. The state of the client transmits from CLOSED to SYN_SENT, here, the client keeps waiting for the end of the 3-way-handshake. After the [1.SYN] is received by the server, it will become SYN_RECEIVED and respond with a [2.SYN， ACK], to answer the [1.SYN], and at the same time to request a connection from server to client. The client answers a [3.ACK], both of the endpoints become ESTABLISHED state, a connection has been established, and the application layer data is sent back and forth.

When either endpoint requires to cut the established connection, it will send a FIN, say, the client sends a [8.FIN] to finish the connection (Maybe the server initiates the release procedure), this action will drive the client going to the state FIN_WAIT_1, in which the client keeps waiting for the ACK from the counterpoint. The server side gets the [8.FIN], notices that there will be no more data from the client side. The server answers the [8.FIN] with an [9.ACK], transfer to the CLOSE_WAIT state to wait for the server application layer to finish sending application data. After getting the [9.ACK], client transfers from FIN_WAIT_1 to FIN_WAIT_2. In FIN_WAIT_2, the client is receiving data only, but will never send anything until the server sends a FIN. At last, the server sends a [10.FIN], the server waits for the last ACK from the client, this state is LAST_ACK. The client acknowledges the [10.FIN] with [11.ACK] as known as the last ACK, and goes to the TIME_WAIT state. The server goes to the CLOSED state after getting the last ACK. After the TIME_WAIT timeouts, the client goes to the CLOSED state.

When we combine the state transformation diagram, we get the one described in RFC793.

TCP abnormal endpoints state transmission

When we consider the RST segment, e.g. the client requests a connection to the server port, on which there’s no processing listening, the server answers with a RST, RST makes the client transfer to the CLOSED state.

TCP simultaneously established a connection

When the endpoints request a connection to each other simultaneously. It’s acting like this, there’s no client or server now, they are both clients or servers.