"Allowing more than 64k bound connections (http://www.ioremap.net/node/97)" - патч (http://marc.info/?l=linux-netdev&m=122963561613278&w=2) позволяющий организовать обработку в Linux более 64 тысяч одновременных соединений через один bind() с указанием нулевого порта (номер порта будет выбран из группы доступных локальных адресов).URL: http://marc.info/?l=linux-netdev&m=122963561613278&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=19545
Очень нужная штука!
соеденить с nginx и будет не хуже чем на фре, как Игорь рассказывал про 200 тысяч соединений
>соеденить с nginx и будет не хуже чем на фре, как Игорь
>рассказывал про 200 тысяч соединенийочень много зависит от софта (скриптов сайта), который крутится на вебсервере
>соеденить с nginx и будет не хуже чем на фре, как Игорь
>рассказывал про 200 тысяч соединенийПодозреваю Игорь говорил про входящие соединения. C ними и в linux все прекрасно.
А тема-то про ИСХОДЯЩИЕ, когда их больше 64k. Я сам в bsd не разбираюсь, но не верится что там 200 тысяч будет легко.
>но не верится что там 200 тысяч будет легко.А цифирь в 200 000 для *исходящих* соединений - это откуда вообще?Я так понимаю что оно кратно 64К (ну ладно, в теории 65К) - теоретический максимум N * 65K при имеющихся N айпи адресах.Потому что мы можем открыть скажем пяток соединений на одни и те же IP и порт некоего сервера и соединения как-то потом надо между собой отличать, что достигается назначением разных номеров локальных портов таким соединениям, по которым их и отличают.
В случае входящих соединений такого лимита разумеется нет: там локально ip и порт всегда одни и те же а меняются ip и порт ремотных юзеров.Ессно сочетаний IP:port ремотных юзеров может быть и 200 000 и больше (по сути меняться могут аж 6 байтов так что в теории можно получить аж почти 2^48 входящих соединений в IPv4, на практике ессно сильно меньше т.к. не все юзеры сразу лезут на сервер и не все норовят открыть по 65К соединений с своих IP адресов).
Господа, не имеет значения, входящее соединение, или исходящее. Т.к. для передачи данных необходимы две оконечные точки - локальная и удаленная. В IP сетях этими оконечными точками являются сокеты - пары адрес:порт. Для передачи данных по TCP (ведь мы говорим о "соединениях" - UDP не трогаем) нужно установить соединение, распределив локальный сокет и удаленный. Т.к. поле порта в IPv4 имеет размер 16 бит - всего вариантов возможных 65535. Отнимаем 1024 - в *nix они биндятся только под привилегиями рута - вот и суммарное количество входящих и исходящих TCP соединений существующих одновременно на одном IP адресе.
>Господа, не имеет значения, входящее соединение, или исходящее. Т.к. для передачи данных
> необходимы две оконечные точки - локальная и удаленная. В IP сетях
>этими оконечными точками являются сокеты - пары адрес:порт.Только слушающий сокет и все принятые им подключения занимают 1 (один) локальный порт. Сколько бы он подключений не принял!
>Только слушающий сокет и все принятые им подключения занимают 1 (один) локальный
>порт. Сколько бы он подключений не принял!Неправда
>НеправдаЕщё какая правда. Не веришь - посмотри текущие сокеты.
Все апачи занимают один 80 порт. Все ftpd один 21
У lighttpd каждый сокет имеет локальный порт общий с другими.Так accept работает. Он возвращает сокет с локальным портом который был у listen сокета. Отличается только адрес другой стороны.
>>Неправда
>
>Ещё какая правда. Не веришь - посмотри текущие сокеты.
>Все апачи занимают один 80 порт. Все ftpd один 21
>У lighttpd каждый сокет имеет локальный порт общий с другими.
>
>Так accept работает. Он возвращает сокет с локальным портом который был у
>listen сокета. Отличается только адрес другой стороны.Товарищ, читайте Стивенса. На 80 порту только слушающий сокет, во время установки соединения (accept на серверном сокете) создаётся новый сокет и порт для него выбирается из резервного диапазона. Через слушающий сокет не передаётся никаких данных.
>Товарищ, читайте Стивенса.Предпочитаю читать код и верить своим тому что вижу в выводе ss или netstat.
>На 80 порту только слушающий сокет, во время установки
>соединения (accept на серверном сокете) создаётся новый сокет и порт для
>него выбирается из резервного диапазона.Какого такого резервного диапазона? И что другая сторона начинала слать на «новый» порт? Ну чушь пишете же ))
Может быть 20 лет назад и выдавал accept другой порт, чтобы различать локальные сокеты, но сейчас сокет в linux идентифицируется в хеш таблице 2 адресами и 2 портами. И когда accept создаёт новый сокет, то ЛОКАЛЬНЫЙ АДРЕС И ПОРТ ТАКОЙ ЖЕ как был у listen сокета. Ядро сокеты различает по адресу и порту другой стороны.
> Через слушающий сокет не передаётся никаких данных.
Да на здоровье, только это не в тему.
> Товарищ, читайте Стивенса. На 80 порту только слушающий сокет, во время установки
> соединения (accept на серверном сокете) создаётся новый сокет и порт для него выбирается
> из резервного диапазона. Через слушающий сокет не передаётся никаких данных.Похоже вам самому не мешало бы Стивенса почитать, вы там что-то недопоняли. При создании нового сокета никакого выделения дополнительного порта на принимающей соединение стороне не происходит.
ну пал палыч!!!порт для Accept - одна штука.
когда соединение принято - появляется еще один порт из диапазона > 1024. чтобы как-то различать.
>когда соединение принято - появляется еще один порт из диапазона > 1024.А расскажите пожалуйста, как эта ваша красивая сказка выглядит с точки зрения протокола TCP\IP? С указанием того что кидается в сторону ремоты чтобы уведомить ее о том что пакеты теперь надо слать не на порт 80 вон того сервака на на порт старше 1024 вон того сервака?Распишите по пакетам TCP\IP протокола плиз.Подкрепите это RFCами.И так далее.
Вообще-то то что вы описали насколько я помню актуально только для ИСХОДЯЩИХ соединений и как раз и делается для того чтобы ремота слушающая на одном порту (как это обычно делают сервера) могла соединения отличать, поскольку если вы откроете с одного вашего порта на один и тот же ремотный порт пачку соединений - их пакеты будет просто невозможно отличать (у них совпадают все айпи адреса и все порты и хрен их пакеты отличишь друг от друга).Поэтому когда программы делают множество исходящих соединений - они используют для каждого нового соединения новый локальный порт из диапазона больше чем 1024.Отсюда и ограничение 64K исходящих соединений на 1 айпи адрес.Для ВХОДЯЩИХ соединений такой проблемы не существует и никаких фокусов с портами не требуется: в силу указанного поведения принимающая сторона всегда может отличить соединения друг от друга за счет того что ip:port должны быть всегда разные для всех входящих соединений.Поэтому лимит на входящие соединения - 64K с каждого айпи, а поскольку IP адресов много - можно принять на одном порту немеряно соединений (2^32 IP и 2^16 port это 2^48 битов на перебор, реально несколько меньше из-за резервирования айпи и портов но реальные операционки 1 фиг стушуются гораздо быстрее чем выберется теоретический лимит не столь далекий от 2^48 соединений).
>чтобы как-то различать.
А, простите, почему соединение нельзя отличить по РЕМОТНЫМ хосту и порту?Ремотные клиенты выбирают при конекте новый порт >1024 для этого насколько я помню.
>Господа, не имеет значения, входящее соединение, или исходящее.Имеет...
>Т.к. для передачи данных необходимы две оконечные точки - локальная и удаленная.
Вот на основе этого и посчитайте сколько возможно уникальных (различимых между собой) вариантов конечных точек так и эдак.Впрочем я за вас это уже сделал - просто посмотрите выше...
>В IP сетях этими оконечными точками являются сокеты - пары адрес:порт.
Не в "IP сетях" а конкретно TCP/IP или UDP/IP.Другие протоколы даже пользуясь услугами IP могут не иметь понятия "порт" вообще.
>Для передачи данных по TCP (ведь мы говорим о "соединениях" - UDP не трогаем)
А тут не настолько уж принципиально.В конечном итоге TCP - это набор пакетов.UDP тоже.Для сетевого стека главное - определить кому отдавать прилетевшее.Это будет сделано по уникальности src ip:port + dst ip:port.Так?Ну вот и думайте дальше.
>- вот и суммарное количество входящих и исходящих TCP соединений существующих
>одновременно на одном IP адресе.Какой вы умный.Я именно это и сказал.А для *входящих* соединений у клиентов может быть куча айпи адресов.Ажно почти 2^32 айпишника.И каждый из них может на ваш IP:port открыть свои 65K соединений.И что интересно - вы все эти соединения сможете отличать.За счет разных IP:port с клиентской стороны.
>соеденить с nginx и будет не хуже чем на фре, как Игорь
>рассказывал про 200 тысяч соединенийЯ так понимаю что они про исходящие соединения говорили?И вообще - такое ощущение что под линукс лучше заточен lighttpd.Все-таки его изначально под оные и делали вроде.
А еще лучше написать собственный модуль ядра - сервер и дергать TCP/IP стэк напрямую =) Так можно будет и миллион соединений обработать.
>А еще лучше написать собственный модуль ядра - сервер и дергать TCP/IP
>стэк напрямую =)Боян.Хотя-бы на википедию или в гугл ходите до того как высказать "гениальную" мысль.Просто для проверки того что велосипед не изобрели до вас.Hint: вы далеко не первый кому пришла в голову такая мысль :D
>Так можно будет и миллион соединений обработать.
Исходящих?Может еще и с одного айпи и даже на один и тот же хост?Ну, попробуйте, ага, потом расскажете как получилось.Интересно правда что вы будете делать для отличения соединений друг от друга потому как портов всего 65К а айпишников... при исходящих соединениях вы не можете рассчитывать что софт не откроет скажем эн конекций на порт 80 вон того сервака, поэтому чтобы гарантированно отличать соединения вам придется ограничиться 65К соединениями на порт, т.к. IP:port назначения у таких соединений имеют право совпадать (скажем юзер в 5 потоков файл с сервера качает) - придется для отличения оных раздавать им разные локальные порты коих всего 65К на каждом из имеющихся IP-адресов.
Как написано по сцылке, патч позволяет ядерному аллокатору портов выделять больше 64 тысяч соединений при вызове bind() с нулевым портом. В Linux (и bsd наверное тоже) есть опция SO_REUSEADDR, которая позволяет биндить несколько сокетов на один и тот же порт, если они используют разные адреса. Если вызывать bind() с нулевым портом, то он сам выберет порт, так вот патча bind() остановится после 64 тысяч сокетов, даже адреса были разные (т.е. для двух адресов должно быть 64k*2 bound сокетов, а будет только 64k). В блоге есть обновленная версия, где оптимизируется сам вызов bind() для таких сокетов.
>Как написано по сцылке, патч позволяет ядерному аллокатору портов выделять больше 64
>тысяч соединений при вызове bind() с нулевым портом. В Linux (и
>bsd наверное тоже) есть опция SO_REUSEADDR, которая позволяет биндить несколько сокетов
>на один и тот же порт, если они используют разные адреса.
>Если вызывать bind() с нулевым портом, то он сам выберет порт,
>так вот патча bind() остановится после 64 тысяч сокетов, даже адреса
>были разные (т.е. для двух адресов должно быть 64k*2 bound сокетов,
>а будет только 64k). В блоге есть обновленная версия, где оптимизируется
>сам вызов bind() для таких сокетов.Чтобы было понятнее:
так вот ДО патча bind() остановится после 64 тысяч сокетов
а куда комментарии деваются? было же больше
>а куда комментарии деваются? было же большеКак было 11 комментариев, так и осталось. В этой ветке модераторы ничего не удаляли.
>Как было 11 комментариев, так и осталось. В этой ветке модераторы ничего
>не удаляли.Есть такое подозрение что после правки новостей и принятия правок коменты под новостью сносятся в ноль, что и порождает такие слухи.Было немало прецедентов когда народ настрочил к новости кучу коментов а потом - бац и их всех и разом нет, при том такое было не раз.Сомнительно чтобы модераторы настолько сурово, кардинально и неоднократно злобствовали - видимо у вас есть какой-то баг, одно из предположений я озвучил.
>Есть такое подозрение что после правки новостей и принятия правок коменты под
>новостью сносятся в ноль, что и порождает такие слухи.Было немало прецедентовСкорее всего при правке внимание привлекает повальный оффтопик в комментариях, что и приводит к их удалению ;-) Чаще всего обсуждение вырастает из одного оффтопичного комментария, на который нельзя или нет желания закрывать глаза, а так как приктикуется при удалении сообщения удалять и ответы на него, приходится удалять всю нить. Но такое бывает очень редко, это скорее единичные случаи, как и случаи случайного удаления всей нити вместо одного сообщения в ней, при клике не на той ссылке.
Новость с комментариями весьма условно связана, если бы терялась связность - ветка обсуждения все равно оставалась бы висеть в форуме.
Для более подробного анализа пришлите ссылку на новость у которой пропали комментарии, я детально по логам прослежу. Для текущей новости все добавленные комментарии на месте, ничего никто не удалял.