Recently in TCP Category

Сейчас в end2end-interest идет интересная дискуссия: Why do we need TCP flow control (rwnd). Там выступают очень правильные люди и говорят очень интересные вещи. David P. Reed (тот самый) поделился очень правильной мыслью: So the rwnd parameter is NOT actually measuring buffer pool size. It is actually a control loop that measures the endpoint application's ability to do work.

У меня есть предположение, что мы наблюдаем это прямо сейчас в некоторых реализациях TCP.

Часто на форумах встречаются вопросы про сообщение "TCP: Treason Uncloaked!". Некоторые предполагают, что это атака, некоторые - что это ошибка в реализации TCP.

Код ядра, где возникает это сообщение, вполне прозрачен: если получатель закрыл окно, а у нас есть сегменты "в полете", то что-то здесь не так. В принципе RFC1122 (пункт 4.2.2.16) настоятельно не рекомендует получателю так поступать:

A TCP receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left.  However, a sending TCP MUST be robust against window shrinking

Воспроизвести такое сообщение очень просто. Вот скрипт для hping3, который делает именно это. Если будете экспериментировать, не забудьте зафильтровать исходящие RST.

Я предполагаю, что такое поведение получателя - это не ошибка, а намеренное следование принципу, который высказал David Reed. И в самом деле, у нас теперь много мобильных устройств. Чем они характерны? У них мало памяти и они часто выходят в интернет через соединения с огромным RTT.

В этих условиях будет разумным анонсировать относительно большое окно, но буфер подо все окно не резервировать, а надеяться на то, что приложение будет выгребать данные достаточно быстро, и буфер не успеет заполниться. Конечно, помимо всего прочего, у этих устройств относительно слабый CPU, и приложение иногда не успевает потреблять данные из сокета. Тогда стеку не остается ничего другого, кроме как окошко прикрыть, несмотря на то, что раньше окно было анонсированно довольно большое.

Хорошо такое поведение или плохо? С одной стороны у мобильного стека большого выбора нет: линк с большим RTT хочется держать заполненным, но памяти под соотвествующий буфер нет. С другой, стек сервера в случае tcp treason продолжает режим retransmit'ов, а не входит в tcp persist, как было бы, если окошко закрылось нормально, т.е. генерирует пакетов больше, чем нужно.

Есть у кого-нибудь машина, куда приходит много мобильных клиентов? С благодарностью приму запись трафика TCP-сессий, в которых возникал tcp treason. Хочется навести кое-какую статистику.

Может быть, кто-нибудь хорошо знакомый с реализациями TCP на мобильных устройствах может подтвердить или опровергнуть предположение об аллокации TCP-буферов? Идеально - ссылка на документацию.

Некоторые авторы связывают сообщение "TCP: Treason Uncloaked" с DoS-атаками и странным поведением apache. Но все что удается найти по этому поводу - не более чем circumstatial evidence. Мне не ясен механизм, как таким образом можно заDoSить машину. Исчерпать память ядра буферами? Есть у кого-нибудь из уважаемых читателей более внятные свидетельства о связи tcp treason с DoS-атаками? 

P.S.: Но вот эта презентация, конечно же, вносит некоторую ясность ;)

Сегодня решил саморазвлечься и проделать эксперимент, до которого все никак не доходили руки. Эксперимент без всякой практической ценности, но тем он и хорош. Полезными делами можно заниматься на работе, а развлекаться надо всякими глупостями.

Как-то я писал про истерику М. Литвинович по поводу "блокировки" оппозиционных сайтов. Если помните, одним из замеченных моментов там был изменяющий TTL в пределах TCP-сессии. В порядке общего любопытства я сегодня сляпал простенький сниффер, который смотрит на пробегающие мимо TCP-потоки и докладывает о тех из них, в которых меняется TTL IP-пакетов.

Кое-чего наловилось.

Например, знаменитый Comcast'овский способ "регулирования" P2P-трафика. Они ресетят те TCP-сесии, которые им почему-то не нравятся, но вот правильный TTL в RST они подставить забывают. В принципе, пользуясь этим фактом, можно бороться с этим "регулированием".  Достаточно дропать  RST с "левым" TTL. False positives быть могут, но они довольно маловероятны. Очевидно, дропать такие RST должны оба пира. Вот пример такой сессии: comcast-rst.pcap

А вот http://ibm.com ведет себя крайне интересно. Вот pcap-файл: ibm.com.pcap. За одну сессию TTL пакетов, которые идут оттуда, поменялся 19 раз! Похоже, что это какой-то жутко умный load-balancer. Который как-то раскидывает разные запросы одной keepalive'нутой HTTP-сессии. Но я  никак не пойму, по какому принципу он это делает, и, как он потом это собирает и почему он прокидывает эти запросы "прозрачно". Идеи?

В прошлом посте я кратко упомянул вопрос flow fairness в разрезе P2P, а сегодня вот накопалась интересная статья на предмет flow fairness вообще: Flow Rate Fairness: Dismantling a Religion. Статья написана несколько необычно для такого рода публикаций, вот что пишет сам автор:

It is a classic case of a hegemony where those living within the box don’t recognise the existence of the box, let alone the world outside the box. This paper was written from frustration that no-one inside the box believes that voices outside the box should be listened to. We expect complaints about the blunt style of this paper, but it seemed the only way forward was to force the issue, by making the box look ridiculous in its own terms.

И идеи, которые высказываются в статье, на первый взгляд выглядят неоднозначно. По крайней мере, непривычно. Некоторые из них звучат вполне логично, а некоторые мой разум/опыт сходу не принимает. Но прочитать стоит, и стоит обдумать.

Иногда я захожу почитать rsdn.ru. Из чистого любопытства. Иногда там кроме "жабобыдлокодерства" обсуждается что-нибудь интересное. Сегодня я натолкнулся на тред про TCP.

Вопрос формулируется так: Программы обмениваются сообщениями через TCP. Сообщения короткие, с десяток байт. Возможно ли такое что на принимающей стороне recv вернёт меньшее количество байт чем размер сообщения?

Обсуждение не столько интересное, сколько показательное. Правильные ответы там, естественно, прозвучали, однако завязалась мутная дискуссия, в которой много чего перепуталось. Иными словами, в широких программистских массах есть определенное недопонимание того, что происходит и почему. Видимо, надо раскрыть тему для тех, кто не дочитал Стивенса.

Ничего нового я не расскажу, все это многократно описано.

Миф о Всесильном Тоталитарном Режиме, стремящимся удушить все Силы Добра, никак не дает покоя представителям этих самых сил. Не успела отгреметь истерика по поводу "цензуры" в ЖЖ, как тут же выпрыгнули очередные умучанные от гэбни.

Ко вчерашнему.

Некоторые могли обратить внимание, что если пойти на http://community.livejournal.com/ru_politics, будучи незалогиненым, то ЖЖ честно покажет "This journal has been suspended.". А если пойти залогиненым, то ВСЕ ОПЯТЬ ПОВИСНЕТ, АААА!!!! Псы Тоталитарного Режима отслеживают невинных пользователей, интересующихся крамольным коммьюнити, и берут на карандашик!!! Страшно?

Разберемся.

Нынче модная тема в жж - блокировка слов ru_politics, ru_nbp и еще нескольких.

Цензура, гэбня, удушение свободы слова ...

Некоторые "проводят исследования" и "выясняют масштабы" (на самом деле глупо пиарятся, собирая ссылки на свой журнал): http://insie.livejournal.com/231258.html?style=mine.

Раздаются здравые голоса, что это борьба с DDoS'ом и "цензуру" проводит простой пакетный фильтр, который просто сбрасывает пакеты с ключевыми словами: http://zhuzh.livejournal.com/365653.html.

Разберемся.