shutdown on a socket is similar to close on a pipe in what information it gives to the program on the other side. But it does not close the file handle.

shutdown(0) is like close on a pipe that you are reading from -- it tells the other side that you will no longer be reading (which will change how select behaves, for example). shutdown(1) is like close on a pipe that you are writing to -- it sends an end-of-file to the reader on the other side. shutdown(2) says both of these things, but doesn't close the handle.

The reason for shutdown(0) and shutdown(1) is easy to see because a socket is two-way and you couldn't use close to send an end-of-file but still continue to read from the socket.

"perldoc -f shutdown" says that shutdown is "a more insistent form of close because it also disables the file descriptor in any forked copies in other processes". It is saying that just closeing the socket doesn't prevent any forked processes that also have the same socket open from deciding to read or write data. But it doesn't free any file handles or file descriptors, in any process, including the current one.

So the basic answer is to close after you shutdown.

I had always assumed that the last close on a socket also did a shutdown(2). However, it now appears that some TCP/IP stacks don't do this (I consider this a bug and I'm rather surprised by it, but it is the simplest explanation I've found for the very high number of incoming web connections that we see that must time out because they never appear to close). So, a good network citizen will shutdown(2) before they close (if the close is meant to end communication rather than just turn communication responsibilities over the some other process).