23 августа 2012 г., 17:50 пользователь Alexandre Snarskii
<snar@snar.spb.ru>написал:

> 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.
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru