Consider the equation \(x^3-3x-5=0\), we can get the exact solution just as the quadratic equations. But it’s not easy to remember the formula. And for some equations like, \(x-cosx=0\), there’s even no way to get the analytic solutions. As an engineer, sometimes, we just require a acceptable numerical solution that is accurate to a reasonable number of decimal places.

Actually there are two ways to release a TCP connection. The normal way to terminate a TCP connection is for one side to send a FIN segment, and it follows the normal releasing procedure. It’s also ok to send a segment which is called RST segment to release the connection immedietly. The difference between these two ways is that the normal release operation guarantee that the data transferred is reliable, the RST segment cut off the connection imedietly which mostly cause the data loss. Sometimes RST segment is involved into the communication software architecture on purpose, but most of the time when RST is caught in a network, it indicates that something goes wrong in the network.

TIME_WAIT state is the most complicated status among the state transmit of TCP protocal, at first glance its existence is not nessesary, some of the optimization technique eliminate the TIME_WAIT state arbitrarily. But as a part of a protocal which has been applied for so many years, there must be some reason. At least , before eliminating it, we should know the details about it, just as Richard Stevens referred in his book, “Instead of trying to avoid the state, we should understand it”. So what is a TIME_WAIT state TCP endpoint waiting for? Why the endpoint transimit to this state? What’s the problems it brought us? Any way that we can keep away from these problems?

For every instance of a kind of item, in a specific period of time, the instance itself will stay in a specific status. Take a cell phone as example, it can be in IDLE status, ALERTING status, CONNECTED status etc. A process could be in CREATED, READY, BLOCKED, RUNNING, DEAD status. When specific events occur, the status of the item can be transfer from one to another. For a kind of items, we can talk about different kind of status from different point of view, or different dimensions. I notes the transmissions of TCP endpoints in this one.

In Linux, any process that ends up running becomes a zombie process within a certain period, so a single zombie process is not inherently harmful. Only when the number of zombie processes in the system continues to accumulate and not disappear, the safety of the system will be threatened, especially in important server systems, the potential harm of the zombie process requires our special attention. So why does zombie processe exist? How does this process occur? What will happen to the system when zombie processes accumulate in large Numbers? How to avoid the potential harm of zombie process? This article discusses the above issues and briefly summarizes the process control of Linux operating system. The theory and approach to zombie processes are applicable to Solaris, BSD, and the Linux family of operating systems that conform to POSIX standards.

TCP connection can be established by SYN segmentation initiated by both ends to the other party at the same time. At the same time, the established connection must meet one condition. After SYN connection request is issued by both TCP ends, a SYN connection request is still received, and the SYN received is exactly from the end that sent SYN to request connection.So is there a situation like this? A TCP end issues a SYN segment to itself, and the connection requested by the SYN segment is exactly the TCP end itself, which meets the condition of “SYN request is received at the same time as SYN request, and the SYN received happens to be from the end of the requesting connection”. This situation is real and is called TCP self-connection. The existence of self-connectivity often causes inexplicable problems and hard-to-reproduce failures and software bugs.

When communication occurs, in addition to the situation that one end of the communication initiates a communication request and the other end waits passively, there may be the situation that both endpoints of the communication have the intention of communication and both ends initiate a request to each other. When the communication behavior ends, the same situation exists. Both sides have no data to send to each other and finish communication at the same time. TCP supports this communication connection to be established and closed at the same time. When do the simultaneous connection creation and shutdown occur? Is it different from normal procedure? This article simulates and reproduces this kind of TCP connections and do some analysis in detail.

TCP provides reliable byte stream data transfer service for the application layer, while TCP is built on top of the IP layer. When forwarding the packet, the IP layer device simply sends the IP packet down and forwards the IP packet as far as possible. When the IP packet is abandoned by the router or receiver in the transmission process, the user data carried by it will be permanently lost. The IP layer has no remedial measures for the loss of data. In addition, the packet size limit of IP layer depends on the ability of data link layer, so there will be the IP packet size limitation, in another word, when the application layer of the byte stream arrived at the IP layer, the data volume of more than a certain value, they will be divided into multiple IP data packet transmissions, there will be out of order arrival IP packets problem and duplicated IP packets problem. The IP layer can not be trust. How does the TCP protocol over an untrusted IP network ensure reliable byte traffic for the application layer?

When any communication occurs, at least one side participating in the communication makes a communication request to determine whether the other side is available. it is the same in the TCP protocol, the initiating process is known as Synchronization, due to TCP provides the application layer reliable byte stream data transmission, it will asign each byte of the application layer data a sequence number, actually the number of the first byte known as ISN (Initial Sequence Number) is not started with 0 or 1, but generated by a specific algorithm, ISN value in the range of [0, 2^32-1]. The two sides of TCP communication need to swap each other’s ISN to control the transmission of the byte stream. The process of exchanging the ISN is called the TCP connection establishment process, and is also called the virtual connection or virtual circuit establishment process. When communication finishing, both ends also need to have a specific interaction process to release the connection. Why do you need to change the ISN to create a connection? Why doesn’t ISN start with 0 or 1? How does full duplex TCP communication control disconnection? This section focuses on TCP connection management and all these problems.

Essentially, it’s just another way of inter process comunication(IPC) between tcp/ip network applications. The layered structure of the network protocol stack only decouples the complexity of communication in the application layer, which does not need to consider data loss, data duplication and transmission timeliness in the communication process. Such problems are solved by the transport layer, the application layer only focuses on messages and processing logic in the layer. Therefore, the general transport layer modules work in the system kernel to provide the same service for all processes in the system. The operating system encapsulates the transport layer and other underlying protocols and provides uniform access interfaces for the application layer. This article mainly describes how the TCP transport layer provides abstract services for the application layer, and attempts to implement a minimalist application layer protocol based on TCP, observing the TCP protocol from the perspective of the application layer.