TTL spotting
Сегодня решил саморазвлечься и проделать эксперимент, до которого все никак не доходили руки. Эксперимент без всякой практической ценности, но тем он и хорош. Полезными делами можно заниматься на работе, а развлекаться надо всякими глупостями.
Как-то я писал про истерику М. Литвинович по поводу "блокировки" оппозиционных сайтов. Если помните, одним из замеченных моментов там был изменяющий 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-сессии. Но я никак не пойму, по какому принципу он это делает, и, как он потом это собирает и почему он прокидывает эти запросы "прозрачно". Идеи?
Как-то я писал про истерику М. Литвинович по поводу "блокировки" оппозиционных сайтов. Если помните, одним из замеченных моментов там был изменяющий 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-сессии. Но я никак не пойму, по какому принципу он это делает, и, как он потом это собирает и почему он прокидывает эти запросы "прозрачно". Идеи?
0 TrackBacks
Listed below are links to blogs that reference this entry: TTL spotting.
TrackBack URL for this entry: http://net-geek.org/cgi-bin/mt/mt-tb.cgi/261
возможно, это просто смена маршрутов в сети?
Определенно нет. Изменения маршрутизации - штука относительно редкая и случайная. А этот эффект воспроизводится каждый раз при обращении к ibm.com. Ну и изменения TTL между 237 и 40 туда-сюда должны навести на мысль, что это не reroute. К тому же, если внимательно посмотреть на сессию, можно обнаружить, что для этих прыжков TTL существует определенная закономерность. Но _смысл_ этих манипуляций остается не совсем понятным.
а при последовательных запросах одного и того же URL'а вариации меняются или нет?