The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

24.12.2008 15:06

"Allowing more than 64k bound connections" - патч позволяющий организовать обработку в Linux более 64 тысяч одновременных соединений через один bind() с указанием нулевого порта (номер порта будет выбран из группы доступных локальных адресов).

  1. Главная ссылка к новости (http://marc.info/?l=linux-netd...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/19545-linux
Ключевые слова: linux, connect, bind, patch, kernel
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Frank (??), 16:41, 24/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень нужная штука!
     
  • 1.2, Аноним (2), 16:55, 24/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    соеденить с nginx и будет не хуже чем на фре, как Игорь рассказывал про 200 тысяч соединений
     
     
  • 2.3, Аноним (-), 17:50, 24/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >соеденить с nginx и будет не хуже чем на фре, как Игорь
    >рассказывал про 200 тысяч соединений

    очень много зависит от софта (скриптов сайта), который крутится на вебсервере

     
  • 2.5, Аноним (2), 00:46, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >соеденить с nginx и будет не хуже чем на фре, как Игорь
    >рассказывал про 200 тысяч соединений

    Подозреваю Игорь говорил про входящие соединения. C ними и в linux все прекрасно.
    А тема-то про ИСХОДЯЩИЕ, когда их больше 64k. Я сам в bsd не разбираюсь, но не верится что там 200 тысяч будет легко.

     
     
  • 3.8, User294 (??), 03:32, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >но не верится что там 200 тысяч будет легко.

    А цифирь в 200 000 для *исходящих* соединений - это откуда вообще?Я так понимаю что оно кратно 64К (ну ладно, в теории 65К) - теоретический максимум N * 65K при имеющихся N айпи адресах.Потому что мы можем открыть скажем пяток соединений на одни и те же IP и порт некоего сервера и соединения как-то потом надо между собой отличать, что достигается назначением разных номеров локальных портов таким соединениям, по которым их и отличают.

    В случае входящих соединений такого лимита разумеется нет: там локально ip и порт всегда одни и те же а меняются ip и порт ремотных юзеров.Ессно сочетаний IP:port ремотных юзеров может быть и 200 000 и больше (по сути меняться могут аж 6 байтов так что в теории можно получить аж почти 2^48 входящих соединений в IPv4, на практике ессно сильно меньше т.к. не все юзеры сразу лезут на сервер и не все норовят открыть по 65К соединений с своих IP адресов).

     
     
  • 4.9, nickelodeon (?), 07:21, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Господа, не имеет значения, входящее соединение, или исходящее. Т.к. для передачи данных необходимы две оконечные точки - локальная и удаленная. В IP сетях этими оконечными точками являются сокеты - пары адрес:порт. Для передачи данных по TCP (ведь мы говорим о "соединениях" - UDP не трогаем) нужно установить соединение, распределив локальный сокет и удаленный. Т.к. поле порта в IPv4 имеет размер 16 бит - всего вариантов возможных 65535. Отнимаем 1024 - в *nix они биндятся только под привилегиями рута - вот и суммарное количество входящих и исходящих TCP соединений существующих одновременно на одном IP адресе.
     
     
  • 5.10, Аноним (2), 09:00, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Господа, не имеет значения, входящее соединение, или исходящее. Т.к. для передачи данных
    > необходимы две оконечные точки - локальная и удаленная. В IP сетях
    >этими оконечными точками являются сокеты - пары адрес:порт.

    Только слушающий сокет и все принятые им подключения занимают 1 (один) локальный порт. Сколько бы он подключений не принял!

     
     
  • 6.11, Антон (??), 09:14, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Только слушающий сокет и все принятые им подключения занимают 1 (один) локальный
    >порт. Сколько бы он подключений не принял!

    Неправда

     
     
  • 7.15, Аноним (2), 13:01, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Неправда

    Ещё какая правда. Не веришь - посмотри текущие сокеты.
    Все апачи занимают один 80 порт. Все ftpd один 21
    У lighttpd каждый сокет имеет локальный порт общий с другими.

    Так accept работает. Он возвращает сокет с локальным портом который был у listen сокета. Отличается только адрес другой стороны.

     
     
  • 8.16, Serega (??), 13:38, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Товарищ, читайте Стивенса На 80 порту только слушающий сокет, во время установк... текст свёрнут, показать
     
     
  • 9.17, Аноним (2), 14:03, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Предпочитаю читать код и верить своим тому что вижу в выводе ss или netstat Как... текст свёрнут, показать
     
  • 9.18, uldus (ok), 14:23, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Похоже вам самому не мешало бы Стивенса почитать, вы там что-то недопоняли При ... текст свёрнут, показать
     
     
  • 10.21, Dvorkin (??), 10:33, 26/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    ну пал палыч порт для Accept - одна штука когда соединение принято - появляе... текст свёрнут, показать
     
     
  • 11.22, User294 (??), 18:35, 26/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А расскажите пожалуйста, как эта ваша красивая сказка выглядит с точки зрения пр... текст свёрнут, показать
     
  • 5.19, User294 (??), 02:23, 26/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Господа, не имеет значения, входящее соединение, или исходящее.

    Имеет...

    >Т.к. для передачи данных необходимы две оконечные точки - локальная и удаленная.

    Вот на основе этого и посчитайте сколько возможно уникальных (различимых между собой) вариантов конечных точек так и эдак.Впрочем я за вас это уже сделал - просто посмотрите выше...

    >В 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 с клиентской стороны.

     
  • 2.7, User294 (??), 03:05, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >соеденить с nginx и будет не хуже чем на фре, как Игорь
    >рассказывал про 200 тысяч соединений

    Я так понимаю что они про исходящие соединения говорили?И вообще - такое ощущение что под линукс лучше заточен lighttpd.Все-таки его изначально под оные и делали вроде.

     

  • 1.4, Anonymous (?), 21:18, 24/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А еще лучше написать собственный модуль ядра - сервер и дергать TCP/IP стэк напрямую =) Так можно будет и миллион соединений обработать.
     
     
  • 2.20, User294 (??), 02:37, 26/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А еще лучше написать собственный модуль ядра - сервер и дергать TCP/IP
    >стэк напрямую =)

    Боян.Хотя-бы на википедию или в гугл ходите до того как высказать "гениальную" мысль.Просто для проверки того что велосипед не изобрели до вас.Hint: вы далеко не первый кому пришла в голову такая мысль :D

    >Так можно будет и миллион соединений обработать.

    Исходящих?Может еще и с одного айпи и даже на один и тот же хост?Ну, попробуйте, ага, потом расскажете как получилось.Интересно правда что вы будете делать для отличения соединений друг от друга потому как портов всего 65К а айпишников... при исходящих соединениях вы не можете рассчитывать что софт не откроет скажем эн конекций на порт 80 вон того сервака, поэтому чтобы гарантированно отличать соединения вам придется ограничиться 65К соединениями на порт, т.к. IP:port назначения у таких соединений имеют право совпадать (скажем юзер в 5 потоков файл с сервера качает) - придется для отличения оных раздавать им разные локальные порты коих всего 65К на каждом из имеющихся IP-адресов.

     

  • 1.6, Аноним (2), 01:39, 25/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как написано по сцылке, патч позволяет ядерному аллокатору портов выделять больше 64 тысяч соединений при вызове bind() с нулевым портом. В Linux (и bsd наверное тоже) есть опция SO_REUSEADDR, которая позволяет биндить несколько сокетов на один и тот же порт, если они используют разные адреса. Если вызывать bind() с нулевым портом, то он сам выберет порт, так вот патча bind() остановится после 64 тысяч сокетов, даже адреса были разные (т.е. для двух адресов должно быть 64k*2 bound сокетов, а будет только 64k). В блоге есть обновленная версия, где оптимизируется сам вызов bind() для таких сокетов.
     
     
  • 2.14, XoRe (ok), 12:49, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Как написано по сцылке, патч позволяет ядерному аллокатору портов выделять больше 64
    >тысяч соединений при вызове bind() с нулевым портом. В Linux (и
    >bsd наверное тоже) есть опция SO_REUSEADDR, которая позволяет биндить несколько сокетов
    >на один и тот же порт, если они используют разные адреса.
    >Если вызывать bind() с нулевым портом, то он сам выберет порт,
    >так вот патча bind() остановится после 64 тысяч сокетов, даже адреса
    >были разные (т.е. для двух адресов должно быть 64k*2 bound сокетов,
    >а будет только 64k). В блоге есть обновленная версия, где оптимизируется
    >сам вызов bind() для таких сокетов.

    Чтобы было понятнее:
    так вот ДО патча bind() остановится после 64 тысяч сокетов

     

  • 1.12, Аноним (2), 11:49, 25/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а куда комментарии деваются? было же больше
     
     
  • 2.13, Maxim Chirkov (ok), 12:05, 25/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >а куда комментарии деваются? было же больше

    Как было 11 комментариев, так и осталось. В этой ветке модераторы ничего не удаляли.

     
     
  • 3.23, User294 (??), 18:45, 26/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Как было 11 комментариев, так и осталось. В этой ветке модераторы ничего
    >не удаляли.

    Есть такое подозрение что после правки новостей и принятия правок коменты под новостью сносятся в ноль, что и порождает такие слухи.Было немало прецедентов когда народ настрочил к новости кучу коментов а потом - бац и их всех и разом нет, при том такое было не раз.Сомнительно чтобы модераторы настолько сурово, кардинально и неоднократно злобствовали - видимо у вас есть какой-то баг, одно из предположений я озвучил.

     
     
  • 4.24, Maxim Chirkov (ok), 20:31, 26/12/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Есть такое подозрение что после правки новостей и принятия правок коменты под
    >новостью сносятся в ноль, что и порождает такие слухи.Было немало прецедентов

    Скорее всего при правке внимание привлекает повальный оффтопик в комментариях, что и приводит к их удалению ;-) Чаще всего обсуждение вырастает из одного оффтопичного комментария, на который нельзя или нет желания закрывать глаза, а так как приктикуется при удалении сообщения удалять и ответы на него, приходится удалять всю нить. Но такое бывает очень редко, это скорее единичные случаи, как и случаи случайного удаления всей нити вместо одного сообщения в ней, при клике не на той ссылке.

    Новость с комментариями весьма условно связана, если бы терялась связность - ветка обсуждения все равно оставалась бы висеть в форуме.

    Для более подробного анализа пришлите ссылку на новость у которой пропали комментарии, я детально по логам прослежу. Для текущей новости все добавленные комментарии на месте, ничего никто не удалял.

     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру