Original: http://cstdlib.com/tech/2014/10/09/read-unix-network-programming-1/
The article is written very clearly, suitable for beginners
Recently read the "UNIX Network programming Volume 1: Socket Networking API," the English name is UNIX network programming, and later on the Internet check, generally called UNP force lattice will be higher, just like Apue. Their authors are all W. Richard Stevens. In addition, he is also the author of TCP/IP illustrated. Rely on, after reading the author profile, simply adore pleasantly surprised.
Let me tell you something more impressive in this book, I've only read the main parts of the book about TCP and UDP and skipped over some chapters, so there may be some omissions.
- Working procedures for TCP and UDP
- How TCP connections work in an "unhealthy" situation
- Various I/O models (blocking/non-blocking/io multiplexing/signal-driven/asynchronous)
- How Daemons and inetd work
- Server Programming Paradigm
- Client Programming Paradigm
working procedures for TCP and UDP
UDP works simply by encapsulating user data in an IP datagram and sending it to a destination, rather than focusing on other aspects.
TCP is an extremely complex protocol, and the following is just the tip of the iceberg
- three-time handshake to establish a connection
- The active side
(SYN J)
sends, SYN_SENT
enters the state
- Passive side received
(SYN J)
, and sent (SYN K, ACK J+1)
back, into SYN_RCVD
state
- The active party
(SYN K, ACK J+1)
receives, and sends (ACK K+1)
back, ESTABLISHED
enters the state
- Passive party received
(ACK K+1)
, also entered ESTABLISHED
status
The above process is as follows:
Notice that during the TCP three handshake, the server has one of the following:
2. Passive side received (SYN J)
, and sent (SYN K, ACK J+1)
back, into SYN_RCVD
the state
After the SYN_RCVD
server enters the state (when the connection is called a half-open connection), you should expect to receive an ACK again. If the timeout does not receive an ACK from the client, (SYN K, ACK J+1)
The server will be re-issued. So, there is a kind SYN Flooding
of attack method called. The attacker sends (SYN J)
the server at high speed (and the IP address in the SYN section can be set to a random number), and then no longer (SYN K, ACK J+1)
resumes after receiving the server reply, which causes a lot of half-open connections on the server. These half-open connections typically last for 63 seconds (under Linux, the default retry count is 5 times, the retry interval is doubled from 1s each time, 5 retries interval is 1s, 2s, 4s, 8s, 16s, the 5th time after the issuance of 32s all know that the 5th time also expires, so, a total need 1s + 2s + 4s+ 8s+ 16s + 32s = 63s,tcp will disconnect this connection). Its harm has two aspects, on the one hand is the resource that occupies the server naturally, on the other hand is fills the half open connection the queue, causes the legitimate SYN sub-section to be unable to queue.
According to the attack principle of SYN flooding, its prevention mainly has the following measures:
- Filter out IP or IP segments of the largest suspected attack
- Will
tcp_synack_retries
be set to 0, indicating that after the second (SYN K, ACK J+1)
handshake package is sent to the client, if the ACK is not received, no retries are made to expedite the reclamation of the "half-open connection".
- The
tcp_max_syn_backlog
parameters are appropriately adjusted according to the memory condition, which generally refers to the length of the queue that maintains the half-open connection (different OS).
- Set
tcp_abort_on_overflow
the options, but simply refuse to handle them.
- disconnected four-time handshake
- The active side
(FIN M)
sends, FIN_WAIT_1
enters the state
- Passive side received
(FIN M)
, and sent (ACK M+1)
back, into CLOSE_WAIT
state
- Active party received
(ACK M+1)
, enter FIN_WAIT_2
status
- The passive side
(FIN N)
sends, LAST_ACK
enters the state
- The active party
(FIN N)
receives, and sends (ACK N+1)
back, TIME_WAIT
enters the state
- Passive party received
(ACK N+1)
, enter CLOSED
status
- When the active
TIME_WAIT
party times out in the state CLOSED
, it enters the state
The above process is as follows:
It's actually 2 times, except that TCP is full duplex, so both the sender and the receiver need fin and ack. However, one side is passive, so it looks like a 4-time handshake.
Notice that there's a state in the TIME_WAIT
end that's involved
7. When the active TIME_WAIT
party times out in the state CLOSED
, enter the state
There are two TIME_WAIT
reasons for the need to pass a CLOSED
timeout state instead of direct entry, one is to ensure that there is enough time for the peer to receive an ACK, and the second is to allow the old sub-section to slowly fade away in the network.
However, if there are a large number of short links in the system, TIME_WAIT
then a large number of States will become a burden on the system. Online some of the tcp_tw_reuse
information mentioned and tcp_tw_recycle
options to solve the problem, but it is best not to use, as if Coolshell mentioned, there may be a lot of strange problems. can also be tcp_max_tw_buckets
adjusted, when the TIME_WAIT
concurrency of Too much, will be more directly to the destory off, and then in the log to make a warning. Quote "In fact, time_wait means that you are active disconnect, so, this is called No Zuo, no die."
How TCP connections work in an "unhealthy" situation
- Server process termination
First, the server process terminates (Received SIGKILL
signal). As part of the Process abort processing, all open descriptors of the process are closed, which causes the (FIN N)
to be sent to the peer (client), and the client replies with the (ACK n+ 1)
, which is the first half of the TCP disconnect.
Then, at this point, the client receives (FIN N)
and does not mean that the connection is broken (although in this case, it is really disconnected), just means that the server is no longer sending data to the client. The client can also continue to send data to the server. If the client also continues to send data to the server at this point, the server TCP will discover that the previous process that opened the socket has terminated, and responds with a RST
. The read operation before the client receives this rst
will return EOF, and the read operation after receiving this rst
will return econnreset
Error, the write operation after receiving this RST
causes the current process to receive the sigpipe
Signal.
The procedure above is as follows:
- Server Host Crashes
Server host crashes means that there is no warning that the host will not be able to work if it is too late to send any messages on the network. This situation is equivalent to directly cut off the network, or in layman's words, you can directly unplug the cable to simulate this situation.
At this point, if the client sends data to the server, and then calls the read operation, TCP waits for the server's ACK acknowledgement message, and the constant time-out retransmission (according to the Berkeley implementation, retransmission 12 times, a total of 9 minutes) ETIMEOUT
, until the number of retransmissions, return Error. If it is determined by the intermediate router that the server host is unreachable, the response "Destination unreasonable" ICMP message EHOSTUNREACH
will ENETUNREACH
return and error.
- Server host crashes after restarting
The server after the reboot has lost the previous TCP information, so even if the TCP data sent by the client is received, it will RST
reply, and the situation in the future is similar to that mentioned in "Server host Crash".
- Server Main Office Machine
When the UNIX system shuts down, the init process usually sends SIGTERM
a signal to other processes and waits around 10s to send SIGKILL
a signal to the process that is still running. So if the process does SIGTERM
not capture the signal, SIGKILL
It will be signaled by the signal, similar to that mentioned in "Server process termination".
Then the I/O model, the daemon and the inetd, the server programming paradigm, the client programming paradigm, have time to write in a few days.
[reproduced] read the UNIX Network programming Volume 1: Socket Networking API