[reproduced] read the UNIX Network programming Volume 1: Socket Networking API

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
  1. The active side （SYN J） sends, SYN_SENT enters the state
  2. Passive side received （SYN J） , and sent （SYN K, ACK J+1） back, into SYN_RCVD state
  3. The active party （SYN K, ACK J+1） receives, and sends （ACK K+1） back, ESTABLISHED enters the state
  4. 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:

  1. Filter out IP or IP segments of the largest suspected attack
  2. 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".
  3. 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).
  4. Set tcp_abort_on_overflow the options, but simply refuse to handle them.
• disconnected four-time handshake
  1. The active side （FIN M） sends, FIN_WAIT_1 enters the state
  2. Passive side received （FIN M） , and sent （ACK M+1） back, into CLOSE_WAIT state
  3. Active party received （ACK M+1） , enter FIN_WAIT_2 status
  4. The passive side （FIN N） sends, LAST_ACK enters the state
  5. The active party （FIN N） receives, and sends （ACK N+1） back, TIME_WAIT enters the state
  6. Passive party received （ACK N+1） , enter CLOSED status
  7. 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