Могут ли исходные и целевые порты TCPv4 конфликтовать друг с другом? Или порты источника и назначения живут в своих собственных адресных пространствах?

Question

Позвольте мне более конкретно рассказать о моем вопросе на примере: допустим, у меня есть множество маленьких серверов, которые запускаются на разных портах с использованием TCPv4. Конечно, эти порты будут портами назначения. Предположим также, что эти маленькие серверы не просто запускаются во время загрузки, как обычный сервер, а скорее динамически изменяются в зависимости от спроса. Они запускаются, когда это необходимо, и могут на некоторое время отключаться, а затем снова включаются.

Теперь давайте предположим, что на этом же компьютере у нас также есть множество клиентских процессов, отправляющих запросы серверным процессам на других компьютерах через TCPv4. Когда клиент делает такой запрос, он назначает порт источника операционной системой.

Скажем для примера, что клиентский процесс отправляет веб-запрос на сервер RESTful, работающий на другом компьютере. Скажем также, что исходный порт, назначенный ОС для этого запроса, - это порт 7777.

Для этого примера давайте также скажем, что, хотя вышеупомянутый запрос все еще выполняется, один из наших маленьких серверов хочет запустить и хочет запустить порт назначения 7777.

Мой вопрос: это вызовет конфликт? Т.е. сервер получит ошибку, потому что порт 7777 уже используется? Или все будет хорошо, потому что эти два разных типа портов живут в разных адресных пространствах, которые не могут конфликтовать друг с другом?

Одна из причин, по которой я беспокоюсь о возможном конфликте, заключается в том, что я видел веб-страницы, на которых написано, что «выбор временного порта источника» обычно выполняется в диапазоне номеров портов, который начинается с относительно большого числа. Вот такая веб-страница:

https://www.cymru.com/jtk/misc/ephemeralports.html

Естественное предположение о том, почему исходные порты должны начинаться с больших чисел, а не просто с 1, состоит в том, чтобы избежать конфликта с портами назначения, используемыми процессами сервера. Хотя я еще не видел ничего, что было бы явно сказано и говорило, что это так.

P.S. Конечно, существует потенциальная разница между тем, что спецификация протокола TCPv4 должна сказать по этому вопросу, и тем, что на самом деле делают операционные системы. Например, возможно протокол является независимым, но операционные системы склонны использовать только одно адресное пространство? Или, может быть, разные ОС по-разному относятся к этой проблеме?

Лично меня сейчас больше всего интересует, что будет делать Linux.

Answer 1

Спецификация TCP говорит, что соединения идентифицируются кортежем:

{local addr, local port, remote addr, remote port}

Исходя из этого, теоретически не должно быть конфликта между локальным портом, используемым в существующем соединении, и попыткой связать этот же порт для прослушивания сервером, так как прослушивающий сокет не имеет удаленного адреса / порт (они представлены в спецификации подстановочными знаками).

Однако большинство реализаций TCP, включая API сокетов Unix, более строгие, чем это. Если локальный порт уже используется в каком-либо существующем сокете, вы не сможете связать его, вы получите ошибку EADDRINUSE. Специальное исключение делается, если все существующие сокеты находятся в состоянии TIME_WAIT, а новый сокет имеет опцию SO_REUSEADDR socket; используется для перезапуска сервера, пока сокеты, оставшиеся от предыдущего процесса, все еще ожидают истечения времени ожидания.

По этой причине диапазон портов обычно делится на диапазоны с различным использованием. Когда сокет не связывает локальный порт (либо потому, что он просто вызывал connect() без вызова bind(), либо путем указания IPPORT_ANY в качестве порта в bind()), порт выбирается из эфемерного Диапазон , который обычно имеет очень высокие номера портов. С другой стороны, ожидается, что серверы будут привязаны к портам с низким номером. Если сетевые приложения следуют этому соглашению, вы не должны сталкиваться с конфликтами.