Comments 15
Как можно воспользоваться данным выводом ss?
По netstat я мониторю открытые порты и кто их слушает, а что можно делать с этим?
Автор, я проглядел, но чем вы на картинках указатели делали? Удобно для анализа.
Картинки делались в app.diagrams.net (первое попавшееся online приложение для рисования диаграмм)
Спасибо! И оффлайн версия: https://github.com/jgraph/drawio-desktop/releases
Слышал, что предел linux это 65k сокетов включая tw на интерфейс. Nginx запросто всё съедает.
Обойти можно ?
Да. Классический способ обхода — биндинг слушающего бэкенда на 2+ адреса/порта и/или биндинг исходящего трафика reverse proxy на 2+ адреса. Поскольку каждое TCP соединение определяется четверкой {src_ip, src_port, dst_ip, dst_port} получаем почти неограниченные возможности.
Это подразумевает rr dns на входе и source routing при исходящем, так ?
Нет. Как-то так:
a) nginx может указывать в качестве src_ip требуемые адреса. Естественно их нужно поднять перед этим на интерфейсе. Если nginx и backend в одной сети, то поднимаем на lo нужное количество адресов из 127.0.0.0/8.
b) backend может слушать как на разных портах, так и на разных ip. Так же как с nginx их нужно поднять на интерфейсе.
Используя все вместе (или по отдельности из того, что технически возможно) получаем практические неограниченное число возможных комбинаций { src_ip, src_port, dst_ip, dst_port }.
a) nginx может указывать в качестве src_ip требуемые адреса. Естественно их нужно поднять перед этим на интерфейсе. Если nginx и backend в одной сети, то поднимаем на lo нужное количество адресов из 127.0.0.0/8.
b) backend может слушать как на разных портах, так и на разных ip. Так же как с nginx их нужно поднять на интерфейсе.
Используя все вместе (или по отдельности из того, что технически возможно) получаем практические неограниченное число возможных комбинаций { src_ip, src_port, dst_ip, dst_port }.
С backend понятно, proxy_bind супер — ещё и transparent есть.
Что с входящим ?
А с входящим трафиком обычно никаких проблем в контексте количества сокетов нет — он же с различных клиентских адресов идет. Так что тут лишь бы CPU хватило на терминацию TLS соединений, а количество соединений уже особого значения не имеет. Когда кончится CPU переходим к L3 балансировке трафика на разные физические машинки, где схема выше повторяется.
А вроде как бы и не так?
на входе пары { src_ip, dst_ip } для https с http2 и фактически можно терминировать не более 64k соединений на интерфейс. Разве нет?
про балансер понятно.
на входе пары { src_ip, dst_ip } для https с http2 и фактически можно терминировать не более 64k соединений на интерфейс. Разве нет?
про балансер понятно.
На входе все та же четверка { client_ip, client_port, server_ip, server_port }. Пара { server_ip, server_port } не меняется (на ней listen socket), но { client_ip, client_port } в обычном мире всегда разный.
Есть краевой случай, когда клиент откроет 65K соединений из одного и того же места (src_ip) и действительно получит ограничение. Но это ограничение будет для исходящих соединений клиента, а не для входящих сервера — сервер продолжит обслуживать эти 65К соединений клиента (которые он все же смог открыть) плюс все соединения других клиентов.
Если же подобному клиенту нужно более 65К соединений (я не представляю зачем, но допустим), то ему нужно будет использовать разные src_ip (но кажется это уже проблемы клиента, а не наши).
Есть краевой случай, когда клиент откроет 65K соединений из одного и того же места (src_ip) и действительно получит ограничение. Но это ограничение будет для исходящих соединений клиента, а не для входящих сервера — сервер продолжит обслуживать эти 65К соединений клиента (которые он все же смог открыть) плюс все соединения других клиентов.
Если же подобному клиенту нужно более 65К соединений (я не представляю зачем, но допустим), то ему нужно будет использовать разные src_ip (но кажется это уже проблемы клиента, а не наши).
хабр торт!
Sign up to leave a comment.
Что обозначает вывод «ss -s»