23 августа 2012 г., 17:50 пользователь Alexandre Snarskii <snar@xxxxxxxxxxx> написал:
On Thu, Aug 23, 2012 at 05:26:47PM +0600, Илья Шипицин wrote:
> >
> > у меня все равно не выстраивается картина.
> >
> > вот смотрите, допустим по цепочке от пользователя до сервера НЕ
> фильтруется
> > icmp, в этом случае все будет хорошо и, если я на сервере скажу "icmp
> dest
> > unreah frag required", то пользователь это увидит.
> >
> > в противном случае, если в транзите режется icmp, то сколько я ни говори,
> он не
> > услышит.
> >
> > как в этом случае поможет "attempt to prevent this problem by inferring
> that
> > large payload packets have been dropped due to MTU" ? ну ок, я сказал, по
> > дороге icmp потерялось, меня никто не услышал.
> >
> > или я что-то упускаю из вида ?
>
> Подразумевается, видимо, что-то типа того, что на сервере можно
> "увидеть" tcp retransmit'ы. Если это ретрансмит первого же "полного"
> пакета, можно предположить, что до пользователя есть проблема с mtu и
> понизить mtu для данного адреса.
>
>
>
> сам по себе MTU не особо интересен. интереснее MSS. мы на OpenBSD столкнулись с
> тем, что они живут каждый своей жизнью (на линуксе - mss вычисляется исходя
> из mtu).
>
>
>
> Но ловить проблемы с PMTU таким образом - это все-таки жестоко,
> начиная с того, что придется перехватывать (либо на уровне bpf,
> либо рисовать ядрёный патч) весь траффик и вести tcp state machine.
> jimho, не стоит овчинка выделки.
>
>
> то есть, понижая MSS до "безопасного" уровня я по сути делаю то, что
> подразумевается в "умных pmtu устройствах" ? или есть нюансы ?
Что вы подразумеваете под "умным pmtu устройством" ? Если это
устройство абонентского доступа (например, pppoe'шный/pptp'шный
концентратор или клиентская короёбочка/роутер, цепляющаяся по
pppoe/pptp) - то да, именно он (а не конечный сервер, то есть
не вы) и должен заниматься переписыванием значения mss'а если
как вы понимаете, это рассылка про nginx. соответственно, речь идет про те настройки, которые можно сделать именно на сервере.
он в пакете уже есть, и результирующий "полноMSS'ный" пакет
превысит MTU линка.
Как показывает практика (~30k pppoe пользователей на одной из
предыдущих работ) - mss fixup'ы на настроенном провайдерском
оборудовании работают вполне корректно.
То же, что делаете вы - скопом понижаете MSS для всего интернета
в целом (в том числе для подавляющего большинства пользователей
у которых нет проблем с MTU) - ну, ok, за счет некоторого overhead'а
для всех пользователей вы добавляете возможность работы для некоторого
(подозреваю, довольно малого) количества пользователей из "недонастроенных"
сетей, то есть маскируете проблему. Как следствие - а) overhead таки
есть и б) если так будут поступать все - проблему никогда и не починят,
просто потому что не заметят ;)
проблему и не заметят.
не так много приложений, включающих флаг DF.
если у пользователя открывается ВКонтакт, но не открывается настроенный мной SSL-ный сайт (на который он пришел с включенным DF, потому что Windows так всегда делает), то крайним буду я.
Считать ли это нюансом - на ваше усмотрение ;)
мы с этим довольно давно живем и вполне успешно.
--
In theory, there is no difference between theory and practice.
But, in practice, there is.