На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
  
> Ограничение размера UDP пакета
    Заголовок IPv4 - 20 байт, заголовок UDP внутри его полезных данных еще 8 байт, итого остается 65507 байт как максимальный размер полезной нагрузки в UDP протоколе. Проверил сейчас экспериментально - проходит в обе стороны в дата центр.

    Зачем некоторые интернет провайдеры (домашние сети) блокируют пакеты длиннее 29-30к? Есть идеи?
    Кому не лень написать пару строчек кода на коленке, проверьте своего провайдера. Вопрос к сообществу, потому как девочки из техподдержки вряд ли на него смогут ответить, не хотел бы их грузить.
      С коленки вариантов нет.
      Единственное более менее объяснение - не хотят фрагментровать.
      Это нагрузка на шлюз.
        Так фрагментация идет разве не по MTU т.е. по 1500 байт? при таких мелких кусках 30к или 65к роли то уже не играет насколько я понимаю
          Цитата Виталь @
          Зачем некоторые интернет провайдеры (домашние сети) блокируют пакеты длиннее 29-30к? Есть идеи?

          Вернемся к исходному заявлению.
          Юридически провайдеру начхать, какой длины пакет приходит к нему. Пров пересылает IP-пакеты, и как вы правильно заметили, что в современных осях фрагментацию - т.е. соблюдение MTU для данной сети - выполняет отправитель. И все наши IP-пакеты в сети Эзернет уходят длиной в 1500-40=1460 байтов полезной нагрузки. UDP-пакет сшивается на стороне приемника.
          И вот причем тут провайдеры совсем непонятно...я такое первый раз слышу.
          Цитата Виталь @
          Проверил сейчас экспериментально - проходит в обе стороны в дата центр.

          Ну вот так и должно быть всегда. :blink:
            Цитата
            И вот причем тут провайдеры совсем непонятно

            Да вот при том что UDP пакеты выше размера который я написал выше (30к) теряются, не доходят до узла назначения, причем как раз по вине проводного интернет-провайдера... думал может там какая специфика задумана.
              Честно говоря, я не могу даже представить, почему какой то реально существующий пров поставил фильтр на UDP-пакеты произвольно им выбранного размера. Надо просто жаловаться на провайдера и требовать лишения его лицензии. Это просто незаконно. Имхо.
                Вообще-то, доставка UDP-пакета, или любой его части после нарезки на куски, не гарантируется. Существует некоторая, не очень большая вероятность, что пакет или его часть потеряются, или передадутся с ошибкой (протокол не предусматривает повторную передачу пакета при ошибке), или пока они путешествуют, истечёт их срок жизни (который довольно велик, и из-за него пропажа происходит редко). При этом в случае потери части пакета пакет не может быть собран приёмником и считается потерянным целиком. Случай потери пакета должен предусматриваться и обрабатываться тем, кто этот протокол использует. Понятно, что пропажа одного куска из тысячи происходит чаще, чем пропажа одного целого куска.
                  ну я вообще писал про тест вида:

                  ExpandedWrap disabled
                    for packetlen:=1 to 65535 do
                    .... sentto() ...

                  на самом деле для поиска предела делал шаг 1000, 10), затем 1 и считал как вверх так и downto. Фильтр как раз не на произвольно выбранный размер а на превышение определенного размера. При таком тесте вариант что пакет случайно потерялся невозможен - получается что пакет на 30 тыс потерялся, на 30001, 30002 и так далее все тоже теряются с вероятностью близкой к 100%.

                  Согласен, надо писать руководству провайдера, пусть что-то решают потому что девочки в техподдержке не понимают даже о чем речь.
                    Виталь
                    Желаю вам успех.

                    Oleg2004
                    Почему по ставил админ понятно вычитал совет в интернете дескать так сеть стабильнее работает. Но честно я не могу понять по чему. Разве что-то где-то аппаратный или программный косяк разработчиков маршрутизатора. При нормальной работе такого ограничения не должно быть.
                      Цитата Pavia @
                      При нормальной работе такого ограничения не должно быть.

                      Полностью согласен.
                      Надо жаловаться. В любом случае очевидно виновать пров - или косяк,или сознательный фильтр, или что еще...
                        периодически ругаться с провайдером, конечно, полезно, но проблему скорее всего не решит. Как терялись длинные пакеты, так и будут теряться. А наткнёшься на грамотного специалиста, так он тебе ещё и объяснит, что прохождение длинных пакетов физически невозможно.
                        Кстати, может ещё действовать вариант, что где-то по пути пакета он собирается в целый пакет, в таком случае провайдер может вообще оказаться ни при чём.
                        Ограничение на длину пакета, скорее всего, всё же не 65535-28, а 32767-28, или около того. То есть поле длины может трактоваться, как число со знаком.

                        В любом случае придётся или фиксировать пакет на размере, гарантированно проходящем через все узлы, или вводить автоматическую подстройку - постепенно уменьшать размер пакета, пока он не начнёт проходить не теряясь.
                          Цитата amk @
                          Как терялись длинные пакеты, так и будут теряться.

                          Не могу полностью согласиться. Современные сети далеко ушли от сетей 20-ти летней давности, когда все терялось. Сейчас в локалке UDP передаются практически стопроцентно. Вероятность потери практически близка к нулю.
                          За пределами - да, вероятность потерь больше. Но только при передаче огромных объемов информации. Но пров сидит с клиентом в одной локалке...поэтому практически никаких проблем с большими пакетами быть не может. Имхо. Скажем тот же битторрент сидит на μTP, а это просто надстройка над UDP, и передаем гигабайты на раз...как посмотришь отчет торрента - количество ошибок передачи - 0.
                            У меня на нормальном направлении пакет 65к минус заголовок доходит стабильно, потерь нет.
                            Вот я и думаю, проектировать ли сразу приложение под автоматический подбор длины пакета, или же остановиться на каком-то гарантированно проходящем...

                            Нет, не число со знаком, значение максимально проходящей длины 29600 или около того.
                            Пока сделал на фиксированную длину пакета, погоняю пруф-оф-концепт у себя, потом решу.
                              Цитата Виталь @
                              У меня на нормальном направлении пакет 65к минус заголовок доходит стабильно, потерь нет.

                              Хорошо бы иметь топологическую расшифровку - что из себя представляет нормальное направление, а что ненормальное. Т.е. конфигурация сети хотя бы в общих чертах... :)
                                Цитата Oleg2004 @
                                Не могу полностью согласиться. Современные сети далеко ушли от сетей 20-ти летней давности, когда все терялось. Сейчас в локалке UDP передаются практически стопроцентно.
                                Так локалку и не называют Интернетом. И почти 100%-я передача по ней определяется всего лишь низкими помехами, проложи кабель возле мощного источника помех, и у тебя пакеты начнут теряться так, как 20 лет назад не терялись (в протоколе Ethernet за последние 20 лет почти ничего не изменилось).
                                Хосты провайдера действительо сидят с абонентом в одной локалке, но остальные то - нет. И там вполне могут ещё действовать правила, установленные почти 50 лет назад.

                                Цитата Виталь @
                                Нет, не число со знаком, значение максимально проходящей длины 29600 или около того.
                                Это ничего не значит. Пакет, в теории, может проходить через соединения, где IP-пакет заворачиваются в пакеты другого типа. Причём может оказаться, что пакет должен заворачиваться целиком, без разрезания. Тогда максимальная длина пакета дополнительно ограничится. Причём с большой вероятностью такое соединение, если существует, существует не физически, а чисто программно.
                                  Цитата amk @
                                  то - нет. И там вполне могут ещё действовать правила, установленные почти 50 лет назад.

                                  Не могут. Законы Мёрфи никто не отменял. Скорость каналов увеличивается. Поэтому стандарты на передачу меняются. Но раз в 10 лет. Вспомнить BASE-10 когда в 80-90 тыг передавали по карбоксилу. А заем ввели витую пару что увеличило надёжность и повысило скорость передачи. И отменило правило 5-4-3.
                                  А затем Base-100 что добавило избыточное кодирование. И вообще переход на оптику и введения стандарта BGP и AS.


                                  Цитата amk @
                                  Это ничего не значит. Пакет, в теории, может проходить через соединения, где IP-пакет заворачиваются в пакеты другого типа. Причём может оказаться, что пакет должен заворачиваться целиком, без разрезания. Тогда максимальная длина пакета дополнительно ограничится. Причём с большой вероятностью такое соединение, если существует, существует не физически, а чисто программно.

                                  В теории не может. Есть стандарты и комитеты по развитию интернета.
                                  И то что происходит на магистральных линиях хорошо известно. А там пакеты собираются в группы так как их быстрее обрабатывать пачками, а не по отдельности. А во вторых фильтрацию на магистрали не делают. Физически из-за скорости не возможно. Для этого есть AS. На уровне IP пакеты раскидываются по AS. А вот сборка пакета уже выполняет AS и она решает отбросить его или нет.

                                  А да на магистрали пакет пропасть не может, только побиться.
                                    Длина пакета "чем больше тем лучше" для уменьшения накладных расходов.
                                    Не хочу чтобы при пакетах по 2 Кб был огромный PPS - это нагрузка и на моем оборудовании, и на оборудовании всех промежуточных сетей.

                                    Почему UDP? Сойдет любой протокол с датаграммами (без установки соединения) но в этом случае UDP это самое простое что можно сделать.
                                      Виталь
                                      Всё равно больше размера MTU не пропихнёшь пакет по сети, большие пакеты будут дробиться и собираться обратно тем же оборудованием. Смысл теряется - лучше слать максимальный пакет, умещающийся в MTU.
                                        Цитата Марсианин @
                                        улетел из приложения пакет 15кб маршрутизатор побил его на 10 по 1,5кб и отправил адресату.

                                        Не может из приложения улететь пакет 15 кб одним куском. :)
                                        Везде в сетевых настройках есть MTU, и все IP-пакеты уходят с компа по 1460 байт полезной нагрузки.
                                        Я опишу Винду.
                                        Инициализация сетевого приложения производится:
                                        int WSAStartup (WORD wVersionRequested, LPWSADATA lpWSAData);
                                        В структуре
                                        ExpandedWrap disabled
                                          typedef struct WSAData
                                          {
                                            WORD              wVersion;
                                            WORD              wHighVersion;
                                            char              szDescription[WSADESCRIPTION_LEN+1];
                                            char              szSystemStatus[WSASYS_STATUS_LEN+1];
                                            unsigned short    iMaxSockets;
                                            unsigned short    iMaxUdpDg;
                                            char FAR *        lpVendorInfo;
                                          } WSADATA;
                                          typedef WSADATA  FAR *LPWSADATA;

                                        есть возвращаемый параметр iMaxUdpDg, который при желании можно посмотреть.
                                        Так вот, для многих реализаций сокетов Berkeley имеется неявный предел в 8192 байтов на UDP-датаграммы (которые затем могут быть фрагментированы в случае необходимости). Реализация сокетов Windows может наложить свой предел, основанный, например, на распределении буферов повторной сборки фрагмента. Минимальное значение iMaxUdpDg для совместимых реализаций Windows Sockets – 512. Обратите внимание, что независимо от значения iMaxUdpDg, нецелесообразно пытаться посылать широковещательную датаграмму, которая больше чем MTU сети. (API Windows Sockets не обеспечивает механизм обнаружения MTU, но он должен быть не меньше чем 512 байтов.) Отметим, ...что iMaxUdpDg в версии WinSock 2.0 не используются и остались только для совместимости с версией 1.1
                                        ========================================
                                        Т.е. все про UDP выше уже устарело.
                                        Т.е. можно конечно же посмотреть, какую датаграмму виндовс дает возможность хранить одним куском в буфере сокета. С другой стороны, этот размер буфера сокета можно изменять по своему соображению, так как если использовать интерфейс WinSock 2.0 и выше - а эти интерфейсы сейчас у всех виндов - то можно в общем то и не заморачиваться или использовать setsockopt() для размера буфера.
                                        Конечно же есть проблема на получателе - в размере буфера приема сокета приемника. Если в него не влазит принимаемая с помощью нескольких IP-пакетов одна датаграмма, то функция recvfrom() не сможет вернуть управление и датаграмма будет отвергнута. Думаю что ваши проблемы именно в этом - провайдер скорее всего не причем. Пров пересылает IP-пакеты с любыми протоколами внутри, а вот на конце это может быть проблема.
                                        Где-то вот так. :)
                                        Надо смотреть на приемнике - какой у него по умолчанию буфер приема для UDP-сокета. Обычно он где-то 8Кб
                                        Сообщение отредактировано: Oleg2004 -
                                          Апну так как проблема в корне все еще не решена, а отложена.
                                          Программа - отправитель и программа - получатель. Одна и та же программа-получатель с одними и теми же буферами стоит на 2 разных машинах, только на одной пакет принимается, а на другую не доходит. Виноват именно провайдер, собственно от его услуг по этой и некоторым другим причинам я пару месяцев назад и отказался. Да, возможно где-то посредине кривая реализация чего-то и размер принимается как целое со знаком, плюс еще какие-то факторы...

                                          Что касается пакетов - возможно действительно стоит пренебречь PPS"ом и слать пакеты поменьше.
                                          Сообщение отредактировано: Виталь -
                                            Виноват не провайдер, а ТС. Если кратко, udp не гарантирует что пакет будет доставлен. Хочешь гарантированной доставки? Используй силуtcp, Люк. Но даже в случае тцп, еcли размер пакета превысит мту, он будет фрагментирован, если конечно ты не догадался поставить флаг DF, в таком случае он будет просто дропнут.

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

                                            А я вот думаю предоставить ОС самой формировать и отправлять пакеты. Самому же сделать микропротокольчик поверх тцп чисто для контроля целостности передаваемых данных, и тогда вопрос про размер пакета отпадёт сам собой.
                                            Сообщение отредактировано: Gonarh -
                                              Цитата
                                              А во вторых фильтрацию на магистрали не делают. Физически из-за скорости не возможно. Для этого есть AS. На уровне IP пакеты раскидываются по AS. А вот сборка пакета уже выполняет AS и она решает отбросить его или нет.

                                              Какая же у тебя каша в голове.
                                              1. Фильтрацию уже давно можно делать на wirespeed, по крайней мере на 10G-линках точно, для этого применяются асики с ткамами.
                                              2. AS к фильтрации не имеет никакого отношения. Совсем. Никак. Это всего лишь 16-битное, а сейчас и 32-битное число, выданное риром, в нашем случае райпом. Применяется в маршрутизации интернет трафика по протоколу BGP.
                                              0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                              0 пользователей:


                                              Рейтинг@Mail.ru
                                              [ Script execution time: 0,0491 ]   [ 16 queries used ]   [ Generated: 28.03.24, 17:44 GMT ]