NGINX: Превышает предел соединений 65535

Question

В отличие от HTTP, websocket поддерживает долговременное соединение после его обновления с HTTP.

Даже если ОС настроена на использование всех портов, все равно всего 65536 портов. Возможно ли, что NGINX превысит этот предел?

Потенциальное решение SO_REUSEPORT, но она отсутствует документ, - по крайней мере, я не нашел, кроме этого нижеследующего пункта

NGINX релиз 1.9.1 вводит новую функцию, которая позволяет использовать SO_REUSEPORT socket, который доступен в более поздних версиях многих операционных систем, включая DragonFly BSD и Linux (ядро версии 3.9 и выше). Эта опция сокета позволяет нескольким сокетам прослушивать один и тот же IP-адрес и комбинацию портов. Затем ядро ​​ загружает входящие соединения через сокеты.

Таким образом, NGINX вызывает accept, чтобы принять входящее соединение.

Системный вызов принимают() используется с установлением соединения на основе типов сокетов (SOCK_STREAM, SOCK_SEQPACKET). Он извлекает первое соединение запрос на очередь ожидающих соединений для прослушивающего сокета, sockfd, создает новый подключенный сокет и возвращает дескриптор , ссылающийся на этот сокет. Созданный сокет не является в состоянии прослушивания. Исходный разъем sockfd не изменяется на этот вызов.

Будет ли новый разъем потреблять порт? Если да, то как превышать ограничение на 65535 соединений?

Answer 1

Комментарий Вы получили это правильно:

TCP соединения определяются 4-кортежа (src_addr, src_port, dst_addr, dst_port). Вы можете подключить к серверу более 65536 клиентов на одном и том же порту, если клиенты используют разные IP-адреса и/или исходные порты. Пример: IP-адрес сервера 0.0.0.1 прослушивает порт 80. Тогда все 4-кортежи могут быть (*, *, 0.0.0.1, 80). До тех пор, пока никакие 4-кортежи не будут одинаковыми, сервер может иметь столько соединений на порту 80, сколько позволит его память. - кукурузные стебли 4 декабря '15 в 2:36

Однако, при оценке, будет ли или не пойти за пределы, вы также должны учитывать, что Nginx не только сервер (с ngx_connection.c#ngx_open_listening_sockets() вызов socket(2), bind(2) и listen(2) системные вызовы для приема таких портов, как 80, а затем вызов accept(2) в бесконечном цикле), но он также потенциально является клиентом восходящего сервера (вызывающий socket(2) и connect(2) для подключения к восходящим потокам на портах, например 8080).

Обратите внимание, что в то время как выполнение TCP-портов не будет возможным для его контекста сервера (поскольку один порт используется сервером во всех его соединениях —, например, порт 80), заканчивается TCP-порт на клиенте сторона - реальная возможность, в зависимости от конфигурации.Вы также должны учитывать, что после того, как клиент делает соединение close(2), state goes to TIME_WAIT в течение примерно 60 секунд или около того (чтобы гарантировать, что, если какие-либо просроченные пакеты пройдут, система будет знать, что делать с их).

Однако, с тем, что, заметим, что the SO_REUSEPORT option к getsockopt(2), по крайней мере, в the sharding context presented in the referenced release notes and reuseport announcement of nginx 1.9.1, совершенно не связан с 65535 дилеммы - это просто строительный блок, имеющий масштабируемую поддержку многопроцессорной между ядром и приложениями, запущенными под ядром:

Я провел контрольный тест с 4 рабочими NGINX на 36-ядерном экземпляре AWS. Чтобы устранить сетевые эффекты, я запустил оба клиента и NGINX на localhost, а также NGINX вернул строку OK вместо файла. Я сравнил три конфигурации NGINX: по умолчанию (эквивалентно accept_mutex on), с accept_mutex off и с повторным использованием. Как показано на рисунке, повторное использование увеличивает количество запросов в секунду в 2-3 раза и уменьшает как латентность, так и стандартное отклонение для латентности.

Что касается вашего основного вопроса, решение uint16_t вопроса исходящего TCP ports, вероятно, будет не использовать движки через TCP, когда это вызывает беспокойство, и/или использовать дополнительные локальные адреса через proxy_bind и др. (И/или ограничить количество TCP-соединений, которые могут быть установлены с бэкэндами).