<br><br><div class="gmail_quote">23 августа 2012 г., 17:05 пользователь Alexandre Snarskii <span dir="ltr"><<a href="mailto:snar@snar.spb.ru" target="_blank">snar@snar.spb.ru</a>></span> написал:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div class="HOEnZb"><div class="h5">On Thu, Aug 23, 2012 at 04:24:26PM +0600, Илья Шипицин wrote:<br>
>              <br>
>             pmtu вам в помощь короче говоря <br>
>              <br>
>         про pmtu я в курсе. но, если я контролирую только серверную часть (и не<br>
>         блокирую исходящие от меня icmp), какие у меня есть возможности в плане<br>
>         pmtu ?<br>
>          <br>
>         кроме "понизить mss до безопасного уровня, чтобы везде пролазило", что<br>
>         я могу сделать ?<br>
><br>
>     <a href="http://en.wikipedia.org/wiki/Path_MTU_Discovery" target="_blank">http://en.wikipedia.org/wiki/Path_MTU_Discovery</a><br>
>     Some implementations of PMTUD attempt to prevent this problem by inferring<br>
>     that large payload packets have been dropped due to MTU rather than because<br>
>     of link congestion. <br>
>     найти "правильную" реализацию pmtud ... <br>
>      <br>
>      <br>
><br>
>  <br>
> у меня все равно не выстраивается картина.<br>
>  <br>
> вот смотрите, допустим по цепочке от пользователя  до сервера НЕ фильтруется<br>
> icmp, в этом случае все будет хорошо и, если я на сервере скажу "icmp dest<br>
> unreah frag required", то пользователь это увидит.<br>
>  <br>
> в противном случае, если в транзите режется icmp, то сколько я ни говори, он не<br>
> услышит.<br>
>  <br>
> как в этом случае поможет "attempt to prevent this problem by inferring that<br>
> large payload packets have been dropped due to MTU" ? ну ок, я сказал, по<br>
> дороге icmp потерялось, меня никто не услышал.<br>
>  <br>
> или я что-то упускаю из вида ?<br>
<br>
</div></div>Подразумевается, видимо, что-то типа того, что на сервере можно<br>
"увидеть" tcp retransmit'ы. Если это ретрансмит первого же "полного"<br>
пакета, можно предположить, что до пользователя есть проблема с mtu и<br>
понизить mtu для данного адреса.<br></blockquote><div> </div><div> </div><div>сам по себе MTU не особо интересен. интереснее MSS. мы на OpenBSD столкнулись с тем, что они живут каждый своей жизнью (на линуксе - mss вычисляется исходя из mtu). </div>
<div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<br>
Но ловить проблемы с PMTU таким образом - это все-таки жестоко,<br>
начиная с того, что придется перехватывать (либо на уровне bpf,<br>
либо рисовать ядрёный патч) весь траффик и вести tcp state machine.<br>
jimho, не стоит овчинка выделки.<br></blockquote><div> </div><div>то есть, понижая MSS до "безопасного" уровня я по сути делаю то, что подразумевается в "умных pmtu устройствах" ? или есть нюансы ?</div>
<div> </div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
In theory, there is no difference between theory and practice.<br>
But, in practice, there is.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br>