Как на самом деле работает серверный TIME_WAIT?

Я знаю, что по этому поводу есть довольно много вопросов SE, и я считаю, что прочитал столько из них, сколько имеет значение, прежде чем перейти к этому пункту.

По "стороне сервера" TIME_WAIT"Я имею в виду состояние пары сокетов на стороне сервера, для которой функция close () была инициирована на стороне сервера.

Я часто вижу такие утверждения, которые мне кажутся противоречивыми:

1. На стороне сервера TIME_WAIT безвреден
2. Вы должны спроектировать свои сетевые приложения так, чтобы клиенты инициировали close (), поэтому клиент несет TIME_WAIT

Я считаю это противоречивым, потому что TIME_WAIT на клиенте может быть проблема - у клиента могут закончиться доступные порты, поэтому, по сути, вышесказанное рекомендует перенести бремя TIME_WAIT на стороне клиента, где это может быть проблемой, на стороне сервера, где это не проблема.

Сторона клиента TIME_WAIT это, конечно, проблема только для ограниченного числа случаев использования. В большинстве клиент-серверных решений задействован один сервер и много клиентов, клиенты обычно не имеют дело с достаточно большим объемом соединений, чтобы это было проблемой, и даже если они это сделают, существует ряд рекомендаций для «разумного» ( в отличие от SO_LINGER с 0 таймаутом или вмешательство в tcp_tw sysctls) на стороне клиента TIME_WAIT избегая слишком быстрого создания слишком большого количества подключений. Но это не всегда возможно, например, для таких приложений, как:

• системы мониторинга
• генераторы нагрузки
• прокси

С другой стороны, я даже не понимаю, как на стороне сервера TIME_WAIT вообще полезно. Причина TIME_WAIT есть даже там, потому что он предотвращает введение устаревшего TCP фрагменты в потоки, которым они больше не принадлежат. На стороне клиента TIME_WAIT это достигается тем, что просто делает невозможным создание соединения с одним и тем же ip:port пары, которые могли быть у этого устаревшего соединения (используемые пары заблокированы TIME_WAIT). Но на стороне сервера этого нельзя предотвратить, поскольку локальный адрес будет иметь принимающий порт и всегда будет одним и тем же, и сервер не может (AFAIK, у меня есть только эмпирическое доказательство) отказать в соединении просто потому, что входящий партнер создаст ту же пару адресов, которая уже существует в таблице сокетов.

Я написал программу, которая показывает, что серверные TIME-WAIT игнорируются. Более того, поскольку тест проводился на 127.0.0.1, ядро ​​должно иметь специальный бит, который даже сообщает ему, является ли он стороной сервера или стороной клиента (поскольку в противном случае кортеж был бы одинаковым).

Источник: http://pastebin.com/5PWjkjEf, протестировано на Fedora 22, по умолчанию net config.

$ gcc -o rtest rtest.c -lpthread
$ ./rtest 44400 s # will do server-side close
Will initiate server close
... iterates ~20 times successfully
^C
$ ss -a|grep 44400
tcp    TIME-WAIT  0      0            127.0.0.1:44400         127.0.0.1:44401   
$ ./rtest 44500 c # will do client-side close
Will initiate client close
... runs once and then
connecting...
connect: Cannot assign requested address

Итак, на стороне сервера TIME_WAIT, соединения на одной и той же паре портов могут быть восстановлены немедленно и успешно, а на стороне клиента TIME-WAIT, на второй итерации connect() праведно проиграл

Подводя итог, можно задать два вопроса:

• На стороне сервера TIME_WAIT на самом деле ничего не делает, и просто оставлен таким, потому что RFC требует?
• Причина, по которой клиенту рекомендуется инициировать close (), потому что сервер TIME_WAIT бесполезно?