Вопрос такой появился - сколько времени обычно должно пройти после закрытия сессии, чтобы система смогла открыть другую на тех же портах?

Состояние, в котором модуль TCP находится в это время, называется TIME_WAIT
Получателю могут поступать сегменты и после того, как соединение было им закрыто. Таймер задержки (quiet timer) связан с состоянием ожидания TIME_WAIT, которое предоставляет защиту от опоздавших пакетов, принадлежащих ранним соединениям; при этом они не будут интерпретироваться как часть нового соединения, которое использует те же самые локальный и удаленный IP адреса и номера портов. Это состояние иногда называется состоянием 2MSL – удвоенное время жизни TCP-сегмента Maximum Segment Lifetime.
Следуя RFC-793, в котором MSL определен равным 2 мин., общее время TIME_WAIT составит 4 мин. На практике это обычно не так. Например, в системах, производных от BSD, MSL равно 30 сек., так что состояние TIME_WAIT длится всего 1 мин. Можно встретить и другие значения в диапазоне от 30 сек. до 2 мин. Если в то время, когда процесс находится в состоянии TIME_WAIT, прибывает новый сегмент, то его таймер 2MSL перезапускается.
Возможно, что хост или его процесс, находясь в состоянии 2MSL, вышел из строя, за время 2MSL успел перезапуститься и немедленно установил новые соединения с использованием локальных и удаленных адресов сокетов, которые были в распоряжении процесса в состоянии 2MSL перед выходом из строя. 
В этом случае опоздавшие сегменты из соединения, которое существовало перед выходом из строя сетевой программы хоста, ОС или самого хоста, могут быть ошибочно интерпретированы как принадлежащие новому соединению, созданному после перезапуска. Это может произойти вне зависимости от того, какой начальный номер последовательности сгенерировал модуль TCP после перезагрузки. 
Чтобы защититься от подобных нежелательных ситуаций, RFC-793 указывает, что модуль TCP не должен создавать новые соединения до истечения MSL с момента перезагрузки. Этот период называется "тихое время" (quiet time).

В некоторых реализациях хосты после перезагрузки ожидают даже дольше, чем время MSL.
Для предотвращения такой ситуации в RFC-1337 было предложено изменить протокол TCP так, чтобы в состоянии TIME_WAIT было разрешено игнорировать RST, что и было реализовано в некоторых TCP-стеках.
Теперь рассмотрим другой случай. С помощью опции сокета SO_LINGER программист может самостоятельно отменить состояние TIME_WAIT. Этот прием программирования иногда рекомендуют применять, чтобы вывести "упавший" сервер из состояния TIME_WAIT и запустить его заново. 
Если поле l_linger структуры linger равно нулю, то соединение немедленно разрывается - партнеру на другом конце посылается RST, и соединение закрывается, не переходя в состояние TIME_WAIT. Это и есть преднамеренная принудительная отмена состояния TIME_WAIT. Считается, что такой стиль программирования не является корректным и допустимым, поскольку нарушает надежность TCP-протокола.


Кроме этого, для предотвращение такого поведения сокет может создаваться с опцией
SO_REUSEADDR. Применение ее на серверной стороне возможно с целью наиболее быстрого восстановления работоспособности "упавшего" сервера. Если сервер выполнил активное закрытие, он находится в состоянии TIME_WAIT, и модуль TCP будет помнить адрес сокета, к которому был "привязан" серверный порт , в течении 2MSL, что заставит его при немедленном перезапуске выдать сообщение "Address already in use".

огромное спасибо за такой развернутый ответ!
исходя из него возник второй 
сколько пакетов система может собрать до начального, т.е. пакетов пришедших вне очереди?
например только закончилось время 2MSL, но все приходящие пакеты не являются началом другой сессии, что система с ними делает?
Можно просто номер RFC или тыкнуть пальцем )

Если я вас правильно понял, то вопрос в том, что делает модуль при приходе своих собственных  сегментов - после окончания MSL.
После истечения времени - просто отбрасывает
А вот если в то время, когда процесс находится в состоянии TIME_WAIT, прибывает новый сегмент старого соединения, то его таймер 2MSL перезапускается.
RFC к сожалению для этого случая не помню.
Вам надо погуглить, точно найдете.

благодарю