Почему нельзя расширить количество сетевых портов?

Question

[frutonyanya]

Высоконагруженные системы упираются в ограничение количества портов. Используют балансировшики, разводят сервисы по нескольким серверам/адресам. IPv6 призван решить эту проблему поддерживая назначение серверу множества ip-адресов.
А почему нельзя было просто расширить 16-и битное поле в заголовке IP до 32 бит (или больше).
Крупным компаниям не пришлось бы владеть кучей ip-шников для обеспечения доступности. 4294967296 - портов хватило бы за глаза. Это точно лучше чем 10-20-30 адресов с 65535 портами.
Да и в IPv6 тоже ограничились 16 битами для номера порта.
Это имеет какие-то серьёзные предпосылки?

Comments

[frutonyanya]

pygame: Ну я у провайдера работал. 12000 клиентов - даже по паре соединений от каждого и половина занята. по этому провайдеры и берут подсети /22 /21. Исходяших ip около 30 . Даже в офисе со 100 компами наступает дедлок иногда.

[frutonyanya]

pygame: Не может быть мультиплексирования. идентификатором TCP сессии подключения является ip и port. Два подключения на один порт невозможны. По этому их перебрасывает на другие после хэндшейка

[hobbyte]

Вопрос: вы ведёте речь про натирование клиентов провайдером? Если да, то на 1 ip можно не напрягаясь повесить 1к клиентов.

[frutonyanya]

hobbyte: ну пусть будет nat. было бы под порт больше бит , для 1М клиентов можнобыло бы юзать 1 ip. И снова вопрос: почему 16 бит такое принципиальное ограничение? далже в ipv6 его не поменяли.

[hobbyte]

frutonyanya: не уверен, думаю это завязано на ресурсы оборудования. Под каждую рару источник-получатель необходима запись в таблице. Не в любое выходящее в сеть устройство можно впихнуть достаточно оперативки. 65к сессий - это ~26Мб оперативки. И да, NAT - костыль, призваный решить проблему адресации.

[АртемЪ]

frutonyanya: Ограничение в ipv4 сложилось исторически такой протокол, да и собственно никому не требуется больше.
А NAT это костыль. И ipv6 как раз и создан для того чтобы он не требовался.

Answer 1

[Андрей]

Вы не представляете масштаб legacy ...

Answer 2

[Иван]

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

Comments

[frutonyanya]

а исходящие порты ? А то что соединение только сначала идёт на 80, а потом перекидывается на другой, иначе после первого же подключившегося сервис становился бы недоступен? а когда у тебя 30000 клиентов по 2 порта на каждого, балансировка не только отказоустойчивость - тупо не хватает портов.

[ldv]

frutonyanya: все-равно остается 80 порт, посмотрите сниффером

[Иван]

Запрос то принимается на порт, на кой его куда то перекидывать? Отправил запрос - получил ответ на произвольный порт выше 1024, причем этот порт на клиентской машине. А со стороны сервера лишь 80-й

[frutonyanya]

Amigo83: Вы вообще с TCP знакомы? Если один на порту повиснет больше никто не подключится.

[ldv]

frutonyanya: если запустите tcpdump port 80 и откроете toster.ru в браузере, то увидите, что в пакетах на стороне сервера всегда 80 порт

[Иван]

frutonyanya: Я не сетевик, но думаю TCP умеет работать с параллельными сессиями

[frutonyanya]

Amigo83: TCP различает между соединения не по номеру локального порта, а по тупле {local_addr,local_port,remote_addr,remote_port}. И если речь идет о входящих соединениях, то у всех у них локальный порт будет один и тот же - тот, на который вы сказали listen(), и тем не менее все будет автоматически прекрасно работать. А вот для исходящих соединених автоматически и прекрасно не получается.

Answer 3

[throughtheether]

Высоконагруженные системы упираются в ограничение количества портов.

Это вы про TCP порты? Не могли бы вы развить эту мысль? Я вас не вполне понимаю.

IPv6 призван решить эту проблему поддерживая назначение серверу множества ip-адресов.

А в случае IPv4, по-вашему, так сделать нельзя, то есть назначить серверу множество адресов?

На мой взгляд, основную проблему в стеке TCP/IP представляет отсутствие внятного сеансового уровня (session layer в терминах ISO OSI). Поэтому каждый сервис/уровень по-своему категоризирует трафик по сессиям, например TCP по кортежу адресов и портов источника и назначения, HTTP по cookie и так далее. В IPv6 действительно есть релевантное этой проблеме нововведение в виде поля flow label, интересно, какие появятся варианты его практического применения.

Ну и нельзя забывать о том, что сеть - это инфраструктура, а менять инфраструктуру, особенно развитую, долго и трудно.

Comments

[frutonyanya]

1) Да если подключений (постоянных) больше больше количества портов приходится выдумывать решения. Например на шлюзе за которым сидит много людей или сервер с миллионом посетителей.
2) IPv4 тоже поддерживает мульти IP-шники - через субинтерфейсы. А в ipv6 это нативно.
Инфраструктуру ломать тяжело, но раз уж попёр ipv6 то можно было поля в заголовках расширить. Этого не делается, видимо, из-за аппаратных ограничений сетевух или чего-то ещё. В том-то и вопрос: почему 16 бит?

[throughtheether]

Да если подключений (постоянных) больше больше количества портов приходится выдумывать решения.

Не думаю, что это связано с исчерпанием пространства номеров(адресов) портов. Клиенты же устанавливают соединение с одним и тем же портом.

Например на шлюзе за которым сидит много людей или сервер с миллионом посетителей.

Это две разные ситуации. В случае шлюза, скорее всего, имеет место трансляция адресов (NAT/PAT), здесь действительно адреса портов расходуются. В случае сервера - нет.

В том-то и вопрос: почему 16 бит?

Единственная, на мой взгляд, распространенная причина увеличить пространство нумерации портов - PAT. При проектировании IPv6 же люди в некоторой мере тешили себя иллюзией, что в светлом будущем NAT и PAT не понадобятся.

Answer 4

[Руслан Федосеев]

Количество портов - это ограничение всплывает ровно в одном месте - на нате. Для www сервера нужно два порта - 80 и 443. Для других сервисов тоже самое.
А вот та проблема, что клиенту невозможно адрес на соединение назначить - это реальность. Приходится клиентов на нат уводить ;) И развивать IPv6

Comments

[Иван]

Автор вопроса говорит, что на веб сервере нельзя создать больше одного подключения на 80-й порт

[Руслан Федосеев]

кхм... Автор уверен в своих словах? ;)

Answer 5

[АртемЪ]

Высоконагруженные системы упираются в ограничение количества портов

Нет!
Большинство сервисов принимают подключения на один порт, и не парятся.
Так собственно во всех высоконагруженных системах.
Один порт открыт на нем сотни тысяч подключений, остальные порты закрыты файерволом за ненадобностью.

Чтобы вам не хватило количества портов нужно сильно постараться.
У вас что там на одном физическом сервере - 30тысяч сервисов, и каждый висит на своем порту?
Это дикость.
Обычно сервисов единицы поэтому востребованы один- два порта. Ну десяток.

Answer 6

[Клёвый Админ]

Хорошая гипотеза, но нет. Портов у нас достаточно, у нас количество коннектов на одном процессоре обработать сложновато, скажем больше 10к коннектов, потому что мы начинаем упираться в шедуллер ОС, который просто не справляется с таким количеством потоков.

Answer 7

[Redaicd]

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