Re: nginx SSL offload в highload проекте

[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'а если 
он в пакете уже есть, и результирующий "полноMSS'ный" пакет 
превысит MTU линка.  
Как показывает практика (~30k pppoe пользователей на одной из 
предыдущих работ) - mss fixup'ы на настроенном провайдерском 
оборудовании работают вполне корректно. 

То же, что делаете вы - скопом понижаете MSS для всего интернета 
в целом (в том числе для подавляющего большинства пользователей
у которых нет проблем с MTU) - ну, ok, за счет некоторого overhead'а
для всех пользователей вы добавляете возможность работы для некоторого
(подозреваю, довольно малого) количества пользователей из "недонастроенных"
сетей, то есть маскируете проблему. Как следствие - а) overhead таки
есть и б) если так будут поступать все - проблему никогда и не починят, 
просто потому что не заметят ;) 

Считать ли это нюансом - на ваше усмотрение ;) 

-- 
In theory, there is no difference between theory and practice. 
But, in practice, there is. 

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru