Когда поступает запрос, он перенаправляется на один из нескольких доступных серверов для запроса. Но доступно только 64 КБ портов, поэтому в любой момент времени может быть не более 64 КБ исходящих запросов. Так как же тогда некоторые веб-сайты могут обслуживать миллионы одновременных запросов? Было бы здорово, если бы кто-то мог прояснить эту путаницу. Спасибо!
Уже связанный Как сайты с высоким трафиком обслуживают более 65535 TCP-соединений? и другие вопросы о переполнении стека объясняют 5-кортеж и то, как это (немного меньше) лимит в 64 КБ на IP - вы получаете соединение на один эфемерный порт. Это по-прежнему относится к рабочим нагрузкам «балансировщика нагрузки», это тоже программный стек IP.
Допустим, вы запускаете службу на IP-адресе 203.0.113.80, порт 443. И каким-то образом каждый из 1 миллиона IP-адресов в 172.16.0.0/12 индивидуально попадает в него. Порты 64K не имеют значения, потому что они уже уникальны по IP-адресу. Клиент 172.16.0.1 может устанавливать 64K соединений, а также клиент 172.16.0.2. Потому что эти потоки разные:
Proto Source IP port Target IP port
TCP 203.0.113.80 443 172.16.0.1 44321
TCP 203.0.113.80 443 172.16.0.2 44321
На практике серверная служба и устройство, поддерживающее соединения, нуждаются в настройке и масштабировании до миллиона. Вам нужно много хозяев и вы настраиваете их TCP-стеки, чтобы достичь этого максимума.
Обычно десятки тысяч соединений происходят между одними и теми же IP-адресами на одном и том же порте только при использовании утилит нагрузочного тестирования. Большинству отдельных IP-адресов не хватает работы, чтобы установить тысячи одновременных подключений.
Это зависит от используемого протокола уровня 4.
Для UDP и других транспортных протоколов без установления соединения (UDP-Lite, RUDP, DCCP и некоторых других) это просто не имеет значения. Поскольку соединения нет, вам не нужно беспокоиться о том, что сокет постоянно связан с конкретным удаленным хостом, и, следовательно, не нужно беспокоиться о том, что номера портов являются 16-битными целыми числами. Вы просто отправляете сообщения на целевой сервер и отслеживаете, что произошло. Однако в зависимости от программного обеспечения балансировки нагрузки и его настройки может существовать функциональное ограничение в 65536 невыполненных запросов к внутренним серверам.
Для SCTP и других транспортных протоколов, ориентированных на мультиплексное соединение (например, TIPC, хотя его почти никто не использует), это тоже не имеет значения. Вы устанавливаете ровно одно соединение от балансировщика нагрузки к каждому внутреннему серверу и просто мультиплексируете столько потоков, сколько вам нужно, через это одно соединение, потому что транспортный протокол поддерживает это. То же самое можно сделать и с некоторыми протоколами прикладного уровня, такими как HTTP / 2 (но не HTTP 1.1 или более ранней версии) или протоколом SSH.
Для TCP и других транспортных протоколов, ориентированных на однопотоковое соединение, это становится немного сложнее. Некоторые конфигурации мультиплексируют запросы через заданное количество постоянных соединений (сохраняя постоянные соединения, вы экономите время, поскольку установка TCP-соединения безумно медленная), в то время как другие используют проприетарные расширения на уровне приложений для мультиплексирования вещей через одно соединение.
Для любого из вышеперечисленных существует также возможность использования нескольких внутренних сетей, либо через несколько физических сетей, через VLAN, либо через какую-либо другую технологию мультиплексирования сети. Этот подход наиболее распространен, когда внутренние серверы являются виртуальными машинами, но он все еще широко используется и в других ситуациях. Имея отдельную подсеть для каждой серверной системы, ваш лимит порта в 64 КБ переходит от внешнего интерфейса к внутреннему (то есть, вместо того, чтобы балансировщик нагрузки разрешал только 64 КБ активных подключений ко всем внутренним серверам, он может обрабатывать 64 КБ до каждый back-end server), что устраняет узкое место из-за количества backends и мощности каждого из них.