Результаты закрытия сокета с помощью close() существенно отличается от результата вызова shutdown(). По сути вызов shutdown() не закрывает сокет по-настоящему, даже если он осуществлен с параметром 2. Ни сокет, ни ассоциированные с ним ресурсы (за исключением буфера приема при how=0 или 2) система не освобождает.
Особо отметим, что вызов shutdown() воздействует на все процессы, для которых этот сокет является открытым (например, в дочернем процессе после вызова fork()). В результате вызов shutdown() с параметром how=1 запретит запись в этот сокет всем использующим его процессам. При вызове же close() или его Windows-аналога closesocket() все другие процессы могут продолжать пользоваться сокетом.
Если надо окончательно закрыть (и уничтожить) конкретный сокет в данном процессе, после shutdown() с параметрами 0 или 1 надо вызывать close().
Вызывая shutdown() с how=1, отправитель будет точно знать, что другая сторона получит признак конца переданного файла EOF, даже если этот сокет открыт и другими процессами. При вызове close() или closesocket() это не гарантируется, поскольку TCP не пошлет FIN-сегмент, пока счетчик ссылок на данный сокет не станет равным нулю – т.е. когда все процессы закроют этот сокет.
С помощью shutdown() реализуется так называемое аккуратное размыкание (orderly release) соединения, в результате чего обе стороны получат все предназначенные им данные до того, как соединение будет разорвано.
Резюме: В Windows принято, что после вызова closesocket() соединение закрывается. Так же соединения закрываются при закрытии программы. Система знает, какому процессу соответствуют сокеты, и закрывает их при смерти приложения.
В Linix и FreeBSD это не так. Необходимо явно сказать shutdown() (посылка FIN) и close() (разъединение дескриптора и сокета). Если этого не сделать, то после закрытия приложения сокеты еще будут висеть в системе некоторое время, в течение которого bind() на "занятые" порты будет возвращать ошибку.

Таймаут на recv ставится когда тебе нужно обязательно получить строго определённое количество данных, причём лично я обычно ставлю 30 сек. Но использую такое крайне редко.
Если поставить маленький таймаут, то recv может отвалится во время получения данных, просто не успеет всё вычитать, либо сервер не успеет передать. Тогда ты не отличишь сбой соединения от нормальной работы.

Обычно перед вызовом recv, я получаю кол-во данных в буфере сокета, FIONREAD, затем вызываю recv.