Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.149.26.151] |
|
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Заголовок IPv4 - 20 байт, заголовок UDP внутри его полезных данных еще 8 байт, итого остается 65507 байт как максимальный размер полезной нагрузки в UDP протоколе. Проверил сейчас экспериментально - проходит в обе стороны в дата центр.
Зачем некоторые интернет провайдеры (домашние сети) блокируют пакеты длиннее 29-30к? Есть идеи? Кому не лень написать пару строчек кода на коленке, проверьте своего провайдера. Вопрос к сообществу, потому как девочки из техподдержки вряд ли на него смогут ответить, не хотел бы их грузить. |
Сообщ.
#2
,
|
|
|
С коленки вариантов нет.
Единственное более менее объяснение - не хотят фрагментровать. Это нагрузка на шлюз. |
Сообщ.
#3
,
|
|
|
Так фрагментация идет разве не по MTU т.е. по 1500 байт? при таких мелких кусках 30к или 65к роли то уже не играет насколько я понимаю
|
Сообщ.
#4
,
|
|
|
Цитата Виталь @ Зачем некоторые интернет провайдеры (домашние сети) блокируют пакеты длиннее 29-30к? Есть идеи? Вернемся к исходному заявлению. Юридически провайдеру начхать, какой длины пакет приходит к нему. Пров пересылает IP-пакеты, и как вы правильно заметили, что в современных осях фрагментацию - т.е. соблюдение MTU для данной сети - выполняет отправитель. И все наши IP-пакеты в сети Эзернет уходят длиной в 1500-40=1460 байтов полезной нагрузки. UDP-пакет сшивается на стороне приемника. И вот причем тут провайдеры совсем непонятно...я такое первый раз слышу. Цитата Виталь @ Проверил сейчас экспериментально - проходит в обе стороны в дата центр. Ну вот так и должно быть всегда. |
Сообщ.
#5
,
|
|
|
Цитата И вот причем тут провайдеры совсем непонятно Да вот при том что UDP пакеты выше размера который я написал выше (30к) теряются, не доходят до узла назначения, причем как раз по вине проводного интернет-провайдера... думал может там какая специфика задумана. |
Сообщ.
#6
,
|
|
|
Честно говоря, я не могу даже представить, почему какой то реально существующий пров поставил фильтр на UDP-пакеты произвольно им выбранного размера. Надо просто жаловаться на провайдера и требовать лишения его лицензии. Это просто незаконно. Имхо.
|
Сообщ.
#7
,
|
|
|
Вообще-то, доставка UDP-пакета, или любой его части после нарезки на куски, не гарантируется. Существует некоторая, не очень большая вероятность, что пакет или его часть потеряются, или передадутся с ошибкой (протокол не предусматривает повторную передачу пакета при ошибке), или пока они путешествуют, истечёт их срок жизни (который довольно велик, и из-за него пропажа происходит редко). При этом в случае потери части пакета пакет не может быть собран приёмником и считается потерянным целиком. Случай потери пакета должен предусматриваться и обрабатываться тем, кто этот протокол использует. Понятно, что пропажа одного куска из тысячи происходит чаще, чем пропажа одного целого куска.
|
Сообщ.
#8
,
|
|
|
ну я вообще писал про тест вида:
for packetlen:=1 to 65535 do .... sentto() ... на самом деле для поиска предела делал шаг 1000, 10), затем 1 и считал как вверх так и downto. Фильтр как раз не на произвольно выбранный размер а на превышение определенного размера. При таком тесте вариант что пакет случайно потерялся невозможен - получается что пакет на 30 тыс потерялся, на 30001, 30002 и так далее все тоже теряются с вероятностью близкой к 100%. Согласен, надо писать руководству провайдера, пусть что-то решают потому что девочки в техподдержке не понимают даже о чем речь. |
Сообщ.
#9
,
|
|
|
Виталь
Желаю вам успех. Oleg2004 Почему по ставил админ понятно вычитал совет в интернете дескать так сеть стабильнее работает. Но честно я не могу понять по чему. Разве что-то где-то аппаратный или программный косяк разработчиков маршрутизатора. При нормальной работе такого ограничения не должно быть. |
Сообщ.
#10
,
|
|
|
Цитата Pavia @ При нормальной работе такого ограничения не должно быть. Полностью согласен. Надо жаловаться. В любом случае очевидно виновать пров - или косяк,или сознательный фильтр, или что еще... |
Сообщ.
#11
,
|
|
|
периодически ругаться с провайдером, конечно, полезно, но проблему скорее всего не решит. Как терялись длинные пакеты, так и будут теряться. А наткнёшься на грамотного специалиста, так он тебе ещё и объяснит, что прохождение длинных пакетов физически невозможно.
Кстати, может ещё действовать вариант, что где-то по пути пакета он собирается в целый пакет, в таком случае провайдер может вообще оказаться ни при чём. Ограничение на длину пакета, скорее всего, всё же не 65535-28, а 32767-28, или около того. То есть поле длины может трактоваться, как число со знаком. В любом случае придётся или фиксировать пакет на размере, гарантированно проходящем через все узлы, или вводить автоматическую подстройку - постепенно уменьшать размер пакета, пока он не начнёт проходить не теряясь. |
Сообщ.
#12
,
|
|
|
Цитата amk @ Как терялись длинные пакеты, так и будут теряться. Не могу полностью согласиться. Современные сети далеко ушли от сетей 20-ти летней давности, когда все терялось. Сейчас в локалке UDP передаются практически стопроцентно. Вероятность потери практически близка к нулю. За пределами - да, вероятность потерь больше. Но только при передаче огромных объемов информации. Но пров сидит с клиентом в одной локалке...поэтому практически никаких проблем с большими пакетами быть не может. Имхо. Скажем тот же битторрент сидит на μTP, а это просто надстройка над UDP, и передаем гигабайты на раз...как посмотришь отчет торрента - количество ошибок передачи - 0. |
Сообщ.
#13
,
|
|
|
У меня на нормальном направлении пакет 65к минус заголовок доходит стабильно, потерь нет.
Вот я и думаю, проектировать ли сразу приложение под автоматический подбор длины пакета, или же остановиться на каком-то гарантированно проходящем... Нет, не число со знаком, значение максимально проходящей длины 29600 или около того. Пока сделал на фиксированную длину пакета, погоняю пруф-оф-концепт у себя, потом решу. |
Сообщ.
#14
,
|
|
|
Цитата Виталь @ У меня на нормальном направлении пакет 65к минус заголовок доходит стабильно, потерь нет. Хорошо бы иметь топологическую расшифровку - что из себя представляет нормальное направление, а что ненормальное. Т.е. конфигурация сети хотя бы в общих чертах... |
Сообщ.
#15
,
|
|
|
Цитата Oleg2004 @ Так локалку и не называют Интернетом. И почти 100%-я передача по ней определяется всего лишь низкими помехами, проложи кабель возле мощного источника помех, и у тебя пакеты начнут теряться так, как 20 лет назад не терялись (в протоколе Ethernet за последние 20 лет почти ничего не изменилось).Не могу полностью согласиться. Современные сети далеко ушли от сетей 20-ти летней давности, когда все терялось. Сейчас в локалке UDP передаются практически стопроцентно. Хосты провайдера действительо сидят с абонентом в одной локалке, но остальные то - нет. И там вполне могут ещё действовать правила, установленные почти 50 лет назад. Цитата Виталь @ Это ничего не значит. Пакет, в теории, может проходить через соединения, где IP-пакет заворачиваются в пакеты другого типа. Причём может оказаться, что пакет должен заворачиваться целиком, без разрезания. Тогда максимальная длина пакета дополнительно ограничится. Причём с большой вероятностью такое соединение, если существует, существует не физически, а чисто программно. Нет, не число со знаком, значение максимально проходящей длины 29600 или около того. |