ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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.

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

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


 




Copyright © Lexa Software, 1996-2009.