форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Обработка в Linux более 64 тысяч одновременных соединений "

Сообщение от opennews (??) on 24-Дек-08, 16:41

"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 Новость: https://www.opennet.ru/opennews/art.shtml?num=19545

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Обработка в Linux более 64 тысяч одновременных соединений "

Сообщение от Frank (??) on 24-Дек-08, 16:41

Очень нужная штука!

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Обработка в Linux более 64 тысяч одновременных соединений "

Сообщение от Аноним (??) on 24-Дек-08, 16:55

соеденить с nginx и будет не хуже чем на фре, как Игорь рассказывал про 200 тысяч соединений

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Аноним (??) on 24-Дек-08, 17:50
	>соеденить с nginx и будет не хуже чем на фре, как Игорь >рассказывал про 200 тысяч соединений очень много зависит от софта (скриптов сайта), который крутится на вебсервере
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Аноним (??) on 25-Дек-08, 00:46
	>соеденить с nginx и будет не хуже чем на фре, как Игорь >рассказывал про 200 тысяч соединений Подозреваю Игорь говорил про входящие соединения. C ними и в linux все прекрасно. А тема-то про ИСХОДЯЩИЕ, когда их больше 64k. Я сам в bsd не разбираюсь, но не верится что там 200 тысяч будет легко.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от User294 (??) on 25-Дек-08, 03:32
	>но не верится что там 200 тысяч будет легко. А цифирь в 200 000 для *исходящих* соединений - это откуда вообще?Я так понимаю что оно кратно 64К (ну ладно, в теории 65К) - теоретический максимум N * 65K при имеющихся N айпи адресах.Потому что мы можем открыть скажем пяток соединений на одни и те же IP и порт некоего сервера и соединения как-то потом надо между собой отличать, что достигается назначением разных номеров локальных портов таким соединениям, по которым их и отличают. В случае входящих соединений такого лимита разумеется нет: там локально ip и порт всегда одни и те же а меняются ip и порт ремотных юзеров.Ессно сочетаний IP:port ремотных юзеров может быть и 200 000 и больше (по сути меняться могут аж 6 байтов так что в теории можно получить аж почти 2^48 входящих соединений в IPv4, на практике ессно сильно меньше т.к. не все юзеры сразу лезут на сервер и не все норовят открыть по 65К соединений с своих IP адресов).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от nickelodeon on 25-Дек-08, 07:21
	Господа, не имеет значения, входящее соединение, или исходящее. Т.к. для передачи данных необходимы две оконечные точки - локальная и удаленная. В IP сетях этими оконечными точками являются сокеты - пары адрес:порт. Для передачи данных по TCP (ведь мы говорим о "соединениях" - UDP не трогаем) нужно установить соединение, распределив локальный сокет и удаленный. Т.к. поле порта в IPv4 имеет размер 16 бит - всего вариантов возможных 65535. Отнимаем 1024 - в *nix они биндятся только под привилегиями рута - вот и суммарное количество входящих и исходящих TCP соединений существующих одновременно на одном IP адресе.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Аноним (??) on 25-Дек-08, 09:00
	>Господа, не имеет значения, входящее соединение, или исходящее. Т.к. для передачи данных > необходимы две оконечные точки - локальная и удаленная. В IP сетях >этими оконечными точками являются сокеты - пары адрес:порт. Только слушающий сокет и все принятые им подключения занимают 1 (один) локальный порт. Сколько бы он подключений не принял!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Антон (??) on 25-Дек-08, 09:14
	>Только слушающий сокет и все принятые им подключения занимают 1 (один) локальный >порт. Сколько бы он подключений не принял! Неправда
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Аноним (??) on 25-Дек-08, 13:01
	>Неправда Ещё какая правда. Не веришь - посмотри текущие сокеты. Все апачи занимают один 80 порт. Все ftpd один 21 У lighttpd каждый сокет имеет локальный порт общий с другими. Так accept работает. Он возвращает сокет с локальным портом который был у listen сокета. Отличается только адрес другой стороны.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Serega (??) on 25-Дек-08, 13:38
	>>Неправда > >Ещё какая правда. Не веришь - посмотри текущие сокеты. >Все апачи занимают один 80 порт. Все ftpd один 21 >У lighttpd каждый сокет имеет локальный порт общий с другими. > >Так accept работает. Он возвращает сокет с локальным портом который был у >listen сокета. Отличается только адрес другой стороны. Товарищ, читайте Стивенса. На 80 порту только слушающий сокет, во время установки соединения (accept на серверном сокете) создаётся новый сокет и порт для него выбирается из резервного диапазона. Через слушающий сокет не передаётся никаких данных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Аноним (??) on 25-Дек-08, 14:03
	>Товарищ, читайте Стивенса. Предпочитаю читать код и верить своим тому что вижу в выводе ss или netstat. >На 80 порту только слушающий сокет, во время установки >соединения (accept на серверном сокете) создаётся новый сокет и порт для >него выбирается из резервного диапазона. Какого такого резервного диапазона? И что другая сторона начинала слать на «новый» порт? Ну чушь пишете же )) Может быть 20 лет назад и выдавал accept другой порт, чтобы различать локальные сокеты, но сейчас сокет в linux идентифицируется в хеш таблице 2 адресами и 2 портами. И когда accept создаёт новый сокет, то ЛОКАЛЬНЫЙ АДРЕС И ПОРТ ТАКОЙ ЖЕ как был у listen сокета. Ядро сокеты различает по адресу и порту другой стороны. > Через слушающий сокет не передаётся никаких данных. Да на здоровье, только это не в тему.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от uldus (ok) on 25-Дек-08, 14:23
	> Товарищ, читайте Стивенса. На 80 порту только слушающий сокет, во время установки > соединения (accept на серверном сокете) создаётся новый сокет и порт для него выбирается > из резервного диапазона. Через слушающий сокет не передаётся никаких данных. Похоже вам самому не мешало бы Стивенса почитать, вы там что-то недопоняли. При создании нового сокета никакого выделения дополнительного порта на принимающей соединение стороне не происходит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Dvorkin (??) on 26-Дек-08, 10:33
	ну пал палыч!!! порт для Accept - одна штука. когда соединение принято - появляется еще один порт из диапазона > 1024. чтобы как-то различать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от User294 (??) on 26-Дек-08, 18:35
	>когда соединение принято - появляется еще один порт из диапазона > 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 для этого насколько я помню.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от User294 (??) on 26-Дек-08, 02:23
	>Господа, не имеет значения, входящее соединение, или исходящее. Имеет... >Т.к. для передачи данных необходимы две оконечные точки - локальная и удаленная. Вот на основе этого и посчитайте сколько возможно уникальных (различимых между собой) вариантов конечных точек так и эдак.Впрочем я за вас это уже сделал - просто посмотрите выше... >В 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 с клиентской стороны.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от User294 (??) on 25-Дек-08, 03:05
	>соеденить с nginx и будет не хуже чем на фре, как Игорь >рассказывал про 200 тысяч соединений Я так понимаю что они про исходящие соединения говорили?И вообще - такое ощущение что под линукс лучше заточен lighttpd.Все-таки его изначально под оные и делали вроде.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Обработка в Linux более 64 тысяч одновременных соединений "

Сообщение от Anonymous on 24-Дек-08, 21:18

А еще лучше написать собственный модуль ядра - сервер и дергать TCP/IP стэк напрямую =) Так можно будет и миллион соединений обработать.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от User294 (??) on 26-Дек-08, 02:37
	>А еще лучше написать собственный модуль ядра - сервер и дергать TCP/IP >стэк напрямую =) Боян.Хотя-бы на википедию или в гугл ходите до того как высказать "гениальную" мысль.Просто для проверки того что велосипед не изобрели до вас.Hint: вы далеко не первый кому пришла в голову такая мысль :D >Так можно будет и миллион соединений обработать. Исходящих?Может еще и с одного айпи и даже на один и тот же хост?Ну, попробуйте, ага, потом расскажете как получилось.Интересно правда что вы будете делать для отличения соединений друг от друга потому как портов всего 65К а айпишников... при исходящих соединениях вы не можете рассчитывать что софт не откроет скажем эн конекций на порт 80 вон того сервака, поэтому чтобы гарантированно отличать соединения вам придется ограничиться 65К соединениями на порт, т.к. IP:port назначения у таких соединений имеют право совпадать (скажем юзер в 5 потоков файл с сервера качает) - придется для отличения оных раздавать им разные локальные порты коих всего 65К на каждом из имеющихся IP-адресов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Обработка в Linux более 64 тысяч одновременных соединений "

Сообщение от Аноним (??) on 25-Дек-08, 01:39

Как написано по сцылке, патч позволяет ядерному аллокатору портов выделять больше 64 тысяч соединений при вызове bind() с нулевым портом. В Linux (и bsd наверное тоже) есть опция SO_REUSEADDR, которая позволяет биндить несколько сокетов на один и тот же порт, если они используют разные адреса. Если вызывать bind() с нулевым портом, то он сам выберет порт, так вот патча bind() остановится после 64 тысяч сокетов, даже адреса были разные (т.е. для двух адресов должно быть 64k*2 bound сокетов, а будет только 64k). В блоге есть обновленная версия, где оптимизируется сам вызов bind() для таких сокетов.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от XoRe (ok) on 25-Дек-08, 12:49
	>Как написано по сцылке, патч позволяет ядерному аллокатору портов выделять больше 64 >тысяч соединений при вызове bind() с нулевым портом. В Linux (и >bsd наверное тоже) есть опция SO_REUSEADDR, которая позволяет биндить несколько сокетов >на один и тот же порт, если они используют разные адреса. >Если вызывать bind() с нулевым портом, то он сам выберет порт, >так вот патча bind() остановится после 64 тысяч сокетов, даже адреса >были разные (т.е. для двух адресов должно быть 64k*2 bound сокетов, >а будет только 64k). В блоге есть обновленная версия, где оптимизируется >сам вызов bind() для таких сокетов. Чтобы было понятнее: так вот ДО патча bind() остановится после 64 тысяч сокетов
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Обработка в Linux более 64 тысяч одновременных соединений "

Сообщение от Аноним (??) on 25-Дек-08, 11:49

а куда комментарии деваются? было же больше

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Maxim Chirkov (ok) on 25-Дек-08, 12:05
	>а куда комментарии деваются? было же больше Как было 11 комментариев, так и осталось. В этой ветке модераторы ничего не удаляли.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от User294 (??) on 26-Дек-08, 18:45
	>Как было 11 комментариев, так и осталось. В этой ветке модераторы ничего >не удаляли. Есть такое подозрение что после правки новостей и принятия правок коменты под новостью сносятся в ноль, что и порождает такие слухи.Было немало прецедентов когда народ настрочил к новости кучу коментов а потом - бац и их всех и разом нет, при том такое было не раз.Сомнительно чтобы модераторы настолько сурово, кардинально и неоднократно злобствовали - видимо у вас есть какой-то баг, одно из предположений я озвучил.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Обработка в Linux более 64 тысяч одновременных соединений "
	Сообщение от Maxim Chirkov (ok) on 26-Дек-08, 20:31
	>Есть такое подозрение что после правки новостей и принятия правок коменты под >новостью сносятся в ноль, что и порождает такие слухи.Было немало прецедентов Скорее всего при правке внимание привлекает повальный оффтопик в комментариях, что и приводит к их удалению ;-) Чаще всего обсуждение вырастает из одного оффтопичного комментария, на который нельзя или нет желания закрывать глаза, а так как приктикуется при удалении сообщения удалять и ответы на него, приходится удалять всю нить. Но такое бывает очень редко, это скорее единичные случаи, как и случаи случайного удаления всей нити вместо одного сообщения в ней, при клике не на той ссылке. Новость с комментариями весьма условно связана, если бы терялась связность - ветка обсуждения все равно оставалась бы висеть в форуме. Для более подробного анализа пришлите ссылку на новость у которой пропали комментарии, я детально по логам прослежу. Для текущей новости все добавленные комментарии на месте, ничего никто не удалял.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]