потери на icmp никого не волнуют.

Во-вторых, ты не видишь как пакеты идут назад, а ассиметрия в инете - норма жизни.

Измерение скорости и параметров канала только средствами icmp - бред.

Только сервисы типа speedtest.net могут дать реальные данные, а подручными средствами IMHO самое правильное - это проверка скорость скачивания больших файлов с разных зеркал например sourceforge.

ip-шники speedtest-cli не сложно посмотреть в netstat во время тестирования.

умничайте с умом пожалуйста

почему потери на icmp никого не волнуют ? понятно что скорость загрузки файлов очевиднее (и вообще протоколы прикладного уровня), но такой возможности как я понимаю у меня нет. если там коммутаторы и роутеры по пути тормозят.

не вижу как пакеты идут назад ? что вы конкретно имеете ввиду и зачем мне это видеть. пакет обратно или пришел, или не пришел или пришел с существенной задержкой, mtr это отражает. или о чем вы? и ваще мне надо узнать скорость до определенного IP в подробности прохождения трафика мне не надо.

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

пусть метод замера скорости будет не оптимальный, но хоть чтото.

да, ip спидтеста и любой трафан можно посмотреть, но мне это не надо, ближайший в никосии - за пределами turktelekom'a. я хочу померять скорость до хостов turktelecom'a.

Если я начну придираться то как раз speedtest это неочевидная фигня так как работает по http (по крайней мере вебверсия). Для кача торрентов или репозиториев по ssh мне не надо http и там не может попастся по пути никаких веб-проксей (и, кстати турецкого фаервола). так что я как раз верю более низкоуровневым инструментам, там результаты проверки «здоровья канала» будут чище. Вообще speedtest это традиционно инструмент чайников и студентов, однако неплохо помогающий и админам иногда.

Я пойду погуглю правильное применение ping flood с размерами пакетов, а вас прошу не отклонятся от темы и жду конструктивных каментов по теме.

не вижу как пакеты идут назад ? что вы конкретно имеете ввиду и зачем мне это видеть.

От тебя пакет идёт на ya.ru. Пусть он идёт асимметрично. От тебя через узлы 1, 2, 3, а к тебе через узлы а, б, в.

Что в таком случае тебе покажет mtr? Пакет уходя от тебя умирает на роутере, который при этом отправляет ответный пакет. При этом пакеты к тебе идут, очевидно, от узлов 1, 2, 3.

Теперь вопрос, что будет если между узлами «б» и «в» плохая связь?

умничайте с умом пожалуйста

почему потери на icmp никого не волнуют

Потому, что на них выставляются отдельные ограничени по скорости. Это средства диагностики, а не транспортный протокол. Больше определенной емкости канала он кушать не должен. Хоп 3 и 5 тому пример.

На счет прямого и обратного пути - твой туркутелеком может исправно доставлять пакеты, а другая AS по пути назад их может дропать по разным причинам. Определить это сидя у себя дома крайне трудно и практически невозможно используя udp+icmp.

Вообще speedtest это традиционно инструмент чайников и студентов, однако неплохо помогающий и админам иногда.

С его помощью можно собрать статистику для оценки общей ситуации. Эта хрень плохо работает на скоростях больше 100Мбит :(

Утилиты, которая точно говорит кто и где режет скорость не существует. Получить гарантированную скорость через BT крайне трудно. Только если внутри провайдерской сети есть свой торрент-трекер, может быть возможно понять, что режут BT. Ну и что дальше ? В договоре оказания услуг скорее всего есть соответствующий пунктик. Они же только ограничили скорость, а не запретили его совсем.

Из моего окна видно

tracepath -n 78.165.64.1
...
 5:  146.82.54.1                                          13.821ms asymm  4 
 6:  67.17.74.45                                          13.921ms asymm  5 
 7:  67.16.144.202                                        30.761ms 
 8:  146.82.55.22                                        4589.404ms asymm  6
 9:  no reply
10:  81.212.197.202                                       97.484ms asymm  8 
12:  81.212.218.93                                       111.836ms asymm  8 
13:  81.212.222.130                                       99.952ms asymm  9 
14:  78.165.64.1                                         102.129ms reached

Ассиметрия не маленькая. Только tracepath запущенный с обратной стороны может показать все машрутизаторы участвующие в процессе передачи данных. Кстати есть сервисы, которые показывают обратный путь.

Где провайдер режет скорость - на твоем порту или дальше - просто так не выяснишь. DPI очень хитрая вещь - помогает ограничивать всякий трафик в зависимости от условий. Основной приоритет нормальному трафику, а всякие bt остаток полосы.

Торренты, speedtest и т.д. способы определяют скорость уже после сетей местнго провайдера (только если турецкий трекер найти, но я сомневаюсь что он есть, да и неправильно это).

(Дык купи vps/договорись с соседом) подключенный к твоему туркутелеком/провайдеру, подними на нем speedtest-mini и проверяй.

Вы все под ассиметричностью подразумеваете роутинг без сохранения состояния маршрута ? типа как с UDP (без установки соединения, каждый новый пакет и ответный идут как хотят) и TCP (с установкой соединения, роутинг заранее определен) ? icmp как я понимаю работает так же как и UDP, пакеты идут как хотят от адресата до узла и обратно? Вы об этом? Тогда:

- Я думаю mtr или tracerute или другие тулзы обрабатывают эту ситуацию. Есть баг-фича с netcat который считает что udp порты всегда открыты так как в udp-связи нет понятия подтверждения прохождения udp-дэйтаграммы, но в случае с icmp я думал это все как то обрабатывается. протокол был специально придуман для сетевой диагностики все таки.

- Маршрут собственно один, тем более в сетях прова. Нет конечно у них могут быть кольца и параллельные всякие линии на случай падения основного канала, или даже хитрый роутинг с оценкой стоимости маршрута, но все это херня для «пинга сдесь и сейчас» как мне кажется, через час уже может быть выбран другой маршрут. Нет какого то адского бурлящего супа в интернете, как вы думаете а есть :

- есть таблицы маршрутизации на коммутаторах и прочем оборудовании магистральных сетей. маршрутизация может быть динамической, с оценкой состояния маршрута, но для начатой пересылки пакетов между источником и назначением маршрут выбирается единожды и по нему дальше все и прет. - есть сохранение состояния сетевой сессии для любых пар «источник-назначение». например udp-сессии (да есть такое понятие) в conntrack linux ядра так и работают. contrack помнит откуда и куда шел этот udp пакет и в след. раз пошлет его так же, чтобы не думать лишний раз. сети в линуксе работают не по учебнику Олифера, кадеты. я думаю есть и некоторый аналог icmp-сессий. стэйтфул фаервол еще на этом явлении основывается и т.д. Особенно на магистральном оборудовании - думать каждый раз о каждом новом пакете «куда же его отправить то снова» на магистральном оборудовании слишком дорого - при первом пакете создается сессия в аналоге контрака железке, следущие пакеты удовлетворяющие условиям записи идут автоматом туда же. - так что сказки про ассимтричный роутинг каждого icmp пакета мне кажется слегка преувеличены. да он есть, но не постоянно, зачем энтропию увеличивать. - скорее всего как я думаю, эти сессии, создаваемые в контраках истекают по таймауту. прервав пинг и пустив новый пинг туда же через 10 минут (все контраки прочистились), пакеты могут пойти уже по другим маршрутам.

И вообще к чему это вы. Вы хотите сказать что мой mtr на убунточке врет о потерях на этих двух хопах ? Я как то mtr верю больше чем вам. Неубедительно.

Давайте теперь по теме - как померять скорость до следущего хопа, после него ? Если не скорость, то абстрактное «здоровье канала». Где происходит падение скорости в 5 раз у меня?

Да, спасибо, вот тут более дельная инфа.

На счет прямого и обратного пути - твой туркутелеком может исправно доставлять пакеты, а другая AS по пути назад их может дропать по разным причинам.

Помоему внутри прова то нет AS правильно? Меня щас интересут только то что внутри сетей прова творится. AS это уже между магистральщиками все, после выхода из сетей одного прова.

Всякие ужасы и тонкости про QoS и приоретизацию трафика мне кажется тоже преувеличены. Я щас нашел местный узел связи, датацентр, местный коммутатор всех абонентов - это АТС с медными проводами. У них оптика только в Алании. Нет у них никакой приоретизации кроме нарезки скоростей абонентам (я так думаю). Реально примитивно все и сети просто лагают.

Давайте теперь по теме - как померять скорость до следущего хопа, после него ? Если не скорость, то абстрактное «здоровье канала». Где происходит падение скорости в 5 раз у меня?

AFAIK исключительно путём прямого измерения. Т.е. вам надо как-то подключится ДО своего маршрутизатора. Например можете спросить на своём турецком форуме. Если у всех турков такая беда, то проблема действительно глобальная.

Иначе никак. Я встречался с ситуацией, когда icmp криво ходит, а tcp нормально, и наоборот. Т.ч. даже если вы и узнаете «скорость icmp», то она вам всё равно вряд-ли поможет.

Между делом, они там тыкались при мне (бородатые связисты на местном кроссе) в «моем профиле» в своем биллинге и натыкали вместо 4 мбит - 8. собственно по договору так и должно быть было. Я думал что у меня 4 Мбит так как не хватает на всех полосы просто (отелей дохера, гостевых сетей) или «обманывают на скорости специально». У всех соседей ваще типа «мегабит всю жизнь». Потом выставив 8Мбит, потыкал раз 10 кнопку какую то «fizikli kapali», я так понял «порвать связь с физическим лицом», это видимо до моего модема, тыкал до тех пор пока у него там зеленеьким не загорелось, после чего сказал - «проблем йок, модем капалы», типа проблему устранил, рубутни модем. ну вот я дома, пишу вам гневные письма, а инет на speedtest показывает 7 мегабит. Офигенно, теперь как белый человек буду во весь опор кинчики качать и репозитории сливать за минуту. Так что проблема была у них, че то напортачили, накосячили (модем я всю неделю ребутил со своей стороны, не помогало).

Но все равно меня уже не первый раз мучает вопрос замеров скорости до конкретных IP в сети. wget обычно помогает, если это вебсервер, а вот до абстрактного роутера непонятно как «замер» сделать. Так что я продолжаю вас слушать.

Да, узнав «скорость icmp» это будет далеко не исчерпывающая картина, но все же, если тут абстрактная icmp скорость «100%», а на следущем хопе после него «45% от того что было», то становится понятно где сломалось и примерно каковы потери. icmp ping flood может как то наверное помочь в этом (да это грязный тест, ну и что), все лень дочитать, а теперь уже интернет дали (как воду, ей богу).

насчет всех этих кривых прохождений - это все неважно, пусть ходит как хочет, главное знать - хорошо оно доходит или нет - яркий пример, играл в sauerbraten на 0,8 мегабита и в игре ping был 500-800 на разных серверах. это ни что иное как «качество прохождения udp дэйтаграмм до игровых серверов sauerbraten'а». И не важно как там идут эти udp пакеты, ваще насрать.

То же самое мне надо от icmp трафика добиться до роутеров прова.

Так же пример с игрой говорит нам что если сервер отвечает (я ниче не качаю, ну качаю статус игроков, их передвижения, но все это маленькими пакетами), то это уже коннект. То есть не надо для замера скорости обязательно чтото там качать торрентами или wget'ом. Достаточно мерять отклик. В отклике уже есть полезная нагрузка, это как wget на миллисекунду, байты пришли, с какой скоростью?

Так что теоретически можно померять icmp скорость вон до того коммутатора. И мне насрать как там идут пакеты.

И вообще к чему это вы. Вы хотите сказать что мой mtr на убунточке врет о потерях на этих двух хопах ? Я как то mtr верю больше чем вам. Неубедительно.

Согласно тому как я понимаю, а я обрисовал это в описании выше, mtr показывает трассу только «туда» (через узлы 1,2,3). А про узлы, через которые пакеты идут обратно (а, б, в), он просто ничего не знает. Поэтому и о потерях между ними он ничего не знает также. Мало ли узлов в интернете. Все не напингуешься.

Но возможно я что-то понимаю неправильно.

Между делом не работает сам рутрекер, тут вычитал что его досят http://blog.rutracker.org/ . через русские анонимайзеры тоже не работает.

Я тоже не магистральщик но мне кажется что внутри - Турецкого - медного, adsl - примитивного интранета нет такой распределенной сложной маршрутизации о которой вы тут говорите.

Глобально, в инете, между континентами и разными магистральщиками (разными AS) - возможно возвращается не так.

Если допустим от одного хопа ответ нормальный (пусть даже он идет обратно не черех тот же коммутатор, не через предыдущий хоп), а от следущего ответ уже тормозит (пускай этот ответ так же идет обратно не через этот коммутатор), то все равно понятно что «вот с этим хопом проблема». А на самом деле проблема или с ним или с тем роутером через который этот хост отвечает, про который мы не знаем. Ну и что. Участок сети с пепякой обнаружен. И если я знаю ip роутера от которого пакеты не ходяь обратно нормально, то связисты у прова, глянув на него, должны понять что у него на uplink'ах в обе стороны. Не забываем что проблема именно в ближайшем неизвестном нам хопе, так как предыдущий отпработал нормально в оба направления.

А то что вся эта цепочка в ходе моей сессии mtr скорее всего не меняется, я тоже описал почему. Контраки, роуттэйблы и т.д.

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

Я тоже могу чтото тут не понимать, поэтому и общаемся.

Щас замерял с помощью tracepath -n несколько хопов после моего модема в сети турктелекома. Не увидел записей async. Как я и предполагал тут все примитивно. Гирлянда комутаторов до румынии-германии.

Если это сетевое оборудование, то только по тем протоколам, на которые оно отвечает. Можешь для разнообразия mtr -u попробовать - будешь не по icmp echo reply, а по icmp port unreachable мерить. Можешь посканить, нет ли там каких интересных сервисов, но вряд ли.

А зачем тебе это? Провайдер предоставляет доступ к *глобальной* сети, если speedtest на разных ip показывает одну и ту же печальную картину - это повод для претензии.

Спасибо. Да провайдер как всегда отмазывается в абонентском отделе (а кучерявые инженеры на узле связи помогли, благодарен им). Как то позвонил им в абонентский саппорт и они меня 10 минут кормили тем что «перевоткните кабель, перенастройте модем, vci, vpi, по wifi вы не можете попасть в админку модема (а я могу на tplink) - поэтому обязательно воткните кабель. все равно не работает? - вот вам телефон поддержки tplink». 150 р. просадил.

Зачем мне это? - ну интересно, по отклику от железки как то более наглядно определить где затыки, где падения скорости. packet loss это немного абстрактно. было бы круто мерить в какие направления нормальная скорость именной сейчас, а в какие плохая, до любого хоста средствами icmp. Но видимо это фантастика ))

можно попробовать пинговать интересующие хосты флудовым пингом, размером 65000 байт и потом посчитать время пинга и общее кол-во переданных и полученных байт, но реальную картину это все равно не покажет скорее всего.

типа как с UDP (без установки соединения, каждый новый пакет и ответный идут как хотят) и TCP (с установкой соединения, роутинг заранее определен) ?

то, что называется роутинг, за это отвечает протокол ip, а tcp это уровнем выше и никакого роутинга и состояния маршрута и прочих не совсем понятных вещей там нет, tcp хоть голубиной почтой отправляй, хоть на перфокартах печатай ему до этого никакого дела нет

назначением маршрут выбирается единожды и по нему дальше все и прет.

тоже бред, один пакет может пойти по одному маршруту, но если таблица вдруг поменялась, то второй пакет пойдет по новому маршруту, даже если второй маршрут имеет хоп на голубиной почте)))

Олифера

почитайте лучше Тоненбаума про сети, не помню точного названия, у Олифера как раз tcp/ip слабое место, что и видно по вашим рассуждениям))) только не обижайтесь, но у вас каша в голове.

http://www.soslan.ru/tcp/

вот это почитайте, а Олифера в топку, там конечно научно, но tcp/ip там вообще ни о чем

Всё делается элементарно: port-mirroring + iperf, при необходимости добавить щепотку tcpdump
не благодари, помогать людям - моя работа

Читать сначала чужие коменты научитесь. А то ОИНЧ.

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

Читать я тоже могу насоветовать что : «Манн, Крелл: Linux. Администрирование сетей».

не понял как порт-мирроринг относится к моей убунточке?

помогать людям - моя работа

- ты волшебник ? ))

* тем более у моего прова. Тем более за одну активную сессию. Жаль что тут нельзя комменты редактить.

Кстати iptraf же еще есть. он показывает как раз сессии и скорость по ним (помоему и tcp и udp, как надо, но наверное не icmp) - его чтоли потыкать.

С iperf как то раз 100 лет назад работал, ничегоне помню, надо попробовать конечно его тоже на досуге.

я о том и говорю, связисты с коммутацией каналов очень хорошо умеют, а вот с tcp/ip знакомы по наслышке, если конечно мы об одних и тех же связистах говорим.

назначением маршрут выбирается единожды и по нему дальше все и прет.

это кстати и есть коммутация канала, но tcp/ip это коммутация пакетов :)

маршруты иногда меняются, если в такой момент вы качете файл, то пакеты пойдут по новому маршруту, для tcp сессии это будет абсолютно прозрачно.

типа как с UDP (без установки соединения, каждый новый пакет и ответный идут как хотят) и TCP (с установкой соединения, роутинг заранее определен) ?

я не заметил знака вопроса и подумал, что это утверждение. весь роутинг в сетях tcp/ip происходит на уровне ip, маршрут не зависит от того, какой протокол вложен в ip, хотя не исключено, что может зависеть, но это извращение.

и установка tcp соединения != определение маршрута.

все-таки прочитайте по ссылке, которую я вам дал, хотябы только описание tcp

если у вас зарезан канал на tcp/udp, а icmp никак не регулируется, то можно попробовать побыть кулхацкером и проложить тоннель например до домашнего компа на icmp пакетах, если повезет, то может быть даже получите выигрыш

маршруты иногда меняются, если в такой момент вы качете файл, то пакеты пойдут по новому маршруту, для tcp сессии это будет абсолютно прозрачно.

Вот это для меня какая то новость, реально. Как раз думал что установка tcp-сессии - это установка маршрута. То, чего не происходит с udp пакетами. Поэтому на udp трафике сделали телефонию, чтоб перло как можно оптимальнее, если предыдущий маршрут уже неактуален, чтоб по новому пошло, побыстрее. Если бы маршруты на канальном или сетевом уровне (IP) менялись и для TCP, то на нем бы и делали весь реалтайм-чувствительный трафик.

Наверное вы имеете ввиду канальный, сетевой и т.д. уровни ниже прикладных. Типа кольца, динамическая маршрутизация, AS, BGP... Там да, наверное фокус с сменой кабеля по которому пакеты пускать и при этом с сохранением tcp-сессии пройдет. Но я опять спрячусь в коробочку и скажу что у турктелекома скорее всего этого ничего нет. Тут реально очень примитивные сети, это видно во всем.

А udp трафик помимо того что может идти по новым маршрутам на низких уровнях, так же идет как попало еще и на прикладном уровне чтоли? Но там нет маршрутизации, вы сами сказали.

Скорее всего, как я понял, tcp-сессии не меняют маршрутизацию на сетевом уровне, а на всех нижлежащих она может меняться (на сетевом уровне это типа не будет заметно, так?). А udp и icmp трафик типа еще и на сетевом уровне (который IP) прут как хотят, с ассинхронностью там и прочими переменами на-лету. Я правильно вас понял?

Но я про эти нижлежащие уровни и не говорил в этой теме, там понятно что неизвестно что творится. Там от хопа до хопа может быть то медь, то оптика, то спутник, все модемами, все невидимо для убунточки ))

В таком случае, насколько я понимаю, все что ниже сетевого уровня (физический и канальный) - ваще никак не отражаются в mtr, tracepath и т.д. стандартных тулзах. Если между коммутаторами кольцо, и одна хорда отпала, и пакет прошел до коммутатора по другой хорде, то никто об этом не знает и если там и было промежуточное оборудование, то оно ваще не отвечает на сетевом уровне, не меняет ttl, не отражается во всех этих программках. Там всякие аппаратные повторители, мультиплексоры, модемы-коневерторы, прозрачные бриджи и т.д. штуки, о которых мы итак не знаем, они не видимы выше канального уровня. (токенринг например это топология построения сети канального чтоли уровня и ее работа не заметна для сетевого уровня, ну вы об этом и говорите наверное)

Хотя это тоже не совсем так, уровни не совсем изолированы друг от друга, нет четкой иерархии. Это как с делением видов Дарвина - никакого деления на самом деле в природе нет, это абстракция выдуманная человеком, все перемешано, границ м/у видами нет. Но есть граница ниже которой не работают сетевые icmp тулзы на моей убунточке - все оборудование что не работает с сетевым и прикладным уровнем: не отвечает на известные протоколы, не изменяет пакеты, ничего в них не вносит. Как то так.

PS : Я почитаю на что вы дали ссылку, Танненбаум помоему попсовый какой то был, когда я его смотрел. Еще, Олифера я как раз неприемлю за его модель OSI, как и саму эту модель, это вы перечитали, да? Как рабочая неделя начнется, так и тулзы потыкаю, которые в этой теме насоветовали.

У них не шейперы тут а как то что то типа выбора режима работы pppoe от модема абонента или выбор работы сервера принимающего коннекты, я хз, мельком биллинг видел, он параметры соединения мне с 4 до 8 мегабит выставил. Это наверное как зажать порт с 100 до 10 мегабит на коммутаторе, там аж протокол другой будет (10-base-T или как он там). Так что я думаю там все зажимается сразу, а не только tcp/ip. Как же люди привыкли к современным сетям и тонким их администрированием. Тут медные 100 парные кабеля по улицам развешаны. Часто когда в Анталии проблемы со связью, тупо падет (или тормозит) инет везде восточнее нее, инженеры отвечают «глобал проблем» и разводят руками. Тут нет всей той тонкости и хитрости в сетях к которым мы привыкли в россии. У нас например куча магистральщиков в одном городе, между ними AS. Чтобы попасть их дома на городской сайт, 3 провайдера можно приодолеть. Тут один магистральщик, к тому же без конкуренции он почти не улучшает и не делает более отказоустойчивой свою сеть. Это как если вместо государственного медного советского телекома ничего бы у нас не было (на урале это «уралсвязьинформ») - они тоже по adsl все еще интернет раздают. В Турции новых магистральщиков создавать свои сети не пускают, а единстрвенный государственный работает через жопу. Но у меня сейчас 7 мегабит на дайнлоад стало, плачу за это 1100 р. примерно (делим пополам с соедом) и меня это устраивает более чем.

Потому что там рейт лимит, а не потеря пакетов. Когда потеря, на последнем хопе она тоже отображаеться.

И ассеметрия, это когда трафик туда идет одной цепочкой рутеров, а обратно другой.

Чтобы протестировать, нужен vps и запустить мтр до него и с него на твой ип. Иначе ты не видишь есть ли потери на обратном пути. Тест запускать одновременно для точности; маршруты не статичные.

Где рейт лимит ? В моем трейсе на 2х роутерах турктелекома? А типа когда потери, то они отображаются по всей цепочке роутеров и статистика имеет накапливаемый характер и увеличивается по пути к последнему хопу, так?

Да, что такое ассиметрия я понял. Это то, чего не должно быть в турецких сетях )). Трэйспат не показал async флагов.

Достаточно проверить обратный трейс с любого удаленного сервера в россии по ssh ?

С убунточки до сервера ан hezner

$ tracepath *ip сервера на hezner* -b
 1:  remort-turkey.local (192.168.1.103)                   0.087ms pmtu 1500
 1:  192.168.1.1 (192.168.1.1)                            20.491ms 
 1:  192.168.1.1 (192.168.1.1)                             8.242ms 
 2:  192.168.1.1 (192.168.1.1)                             5.449ms pmtu 1480
 2:  78.164.192.1.dynamic.ttnet.com.tr (78.164.192.1)     27.544ms 
 3:  81.212.77.157.static.turktelekom.com.tr (81.212.77.157)  25.551ms 
 4:  antalya-t2-1-antalya-t3-2.turktelekom.com.tr.222.212.81.in-addr.arpa (81.212.222.129)  25.265ms 
 5:  ulus-t2-4-antalya-t2-1.turktelekom.com.tr.204.212.81.in-addr.arpa (81.212.204.173)  38.187ms 
 6:  ulus-t2-2-ulus-t2-4.turktelekom.com.tr.202.212.81.in-addr.arpa (81.212.202.234)  39.023ms asymm  7 
 7:  ams-col-2-ulus-t2-2.turktelekom.com.tr.102.156.212.in-addr.arpa (212.156.102.101) 204.634ms asymm  8 
 8:  r1ams1.core.init7.net (195.69.144.210)               84.734ms asymm 11 
 9:  r1nue1.core.init7.net (77.109.140.26)                94.078ms asymm 10 
10:  gw-hetzner.init7.net (77.109.135.102)               213.361ms asymm 13 
11:  core12.hetzner.de (213.239.245.25)                  204.846ms asymm 10 
12:  core21.hetzner.de (213.239.245.30)                  204.918ms 
13:  juniper1.rz12.hetzner.de (213.239.245.78)           204.726ms asymm 12 
14:  hos-tr1.ex3k6.rz12.hetzner.de (213.239.228.135)     204.653ms 
15:  *ip сервера на hezner*                        204.632ms reached
     Resume: pmtu 1480 hops 15 back 49 

С сервера на hezner до убунточки

$tracepath 78.164.192.1 -b
 1:  *ip сервера на hezner*                           0.093ms pmtu 1500
 1:  static.65.47.63.178.clients.your-server.de (178.63.47.65)   0.804ms 
 1:  static.65.47.63.178.clients.your-server.de (178.63.47.65)   0.672ms 
 2:  hos-tr1.juniper1.rz12.hetzner.de (213.239.228.129)    0.302ms 
 3:  core21.hetzner.de (213.239.245.77)                    0.437ms 
 4:  core11.hetzner.de (213.239.245.225)                   3.016ms 
 5:  juniper4.rz2.hetzner.de (213.239.245.26)              8.849ms 
 6:  ae55.edge7.Frankfurt1.Level3.net (195.16.162.253)    26.158ms asymm 10 
 7:  ae-18-18.ebr2.Berlin1.Level3.net (4.69.153.250)      42.083ms asymm  9 
 8:  ae-1-16.bar2.Vienna1.Level3.net (4.69.153.153)       40.829ms 
 9:  ae-1-12.bar1.Vienna1.Level3.net (4.69.153.145)       30.066ms 
10:  antalya-t2-2-vie-col-2.turktelekom.com.tr.140.156.212.in-addr.arpa (212.156.140.131) 102.411ms asymm 11 
11:  antalya-t3-2-antalya-t2-2.turktelekom.com.tr.222.212.81.in-addr.arpa (81.212.222.134)  89.185ms asymm 12 
12:  izmir-t2-3-vie-col-3.turktelekom.com.tr.140.156.212.in-addr.arpa (212.156.140.14)  90.144ms asymm 10 
13:  78.164.192.1.dynamic.ttnet.com.tr (78.164.192.1)    110.241ms reached
     Resume: pmtu 1500 hops 13 back 243 

Короче на всех участках сети трафан идет по разным каналам (кабелям), asymm флаги внтури turktelekom тоже есть. Но вот если посмотреть ore21.hetzner.de то у него нет asymm, это скорее всего один хост, но IP у него разные (несколько IP на порту в load-balanced наверное).

Запуская несколько раз с перерывами в несколько минут трейс с обоих сторон, маршруты не сильно меняются. От меня в германию всегда идет по тем же роутерам в турктелекоме : анталья - улус - анкара - init7(европа) - hezner. меняются IP при тех же именах хостов, возможно просто много IP на одних и тех же железках, а может и нет, тут я уже не знаю как оно у магистральщиков работает. От германии ко мне идет немного по разному : hezner - (берлин|мюнхен|франкфурт) - вена - турктелеком. То есть сети германии самые современные и поэтому ассиметричные, видимо там самые динамично меняющиеся маршруты, видимо так оптимальнее и быстрей проходит трафик.

Но как видно в общем и целом прямой и обратный трейс довольно разные, даже в сетях турктелекома. От меня например трафан не идет через izmir а ко мне из германии izmir появляется в трейсе. Во времени же как я писал картина самих направлений не сильно менятеся. Из германии всегда через izmir, от меня всегда через какой то ulus (я думаю что через анкару).

Поэтому я думаю что запустить новый трейс с hezner это не есть «посмотреть обратные хопы от трейса из турции». Там другой маршрут скорее всего на-чистую выбирается. А пакеты приходящие на hezner, уже откуда то пришедшие, отвечаются скорее всего более близко к маршруту по которому они уже прошли. Контраки, таблицы состояний и т.д. Но это я так, интуитивно подозреваю.

Поэтому на udp трафике сделали телефонию

нет, дело в том, что телефония это поток, в tcp в общем если образно, то скорость регулируется на дропнутых пакетах, когда один пакет где-то посередине дропнулся, то последовательность нарушена, но отправитель еще продолжает слать пакеты, поскольку это сеть с коммутацией пакетов и есть вероятность, что какой-то затерялся и придет позже, при этом получатель продолжает подтверждать только последний полученный пакет (не подтверждает все то, что отправитель шлет после дропнутого)

если получатель вдруг получил пакет (оказывается не дропнулся,а пошел по более длинному пути) то получатель подтверждает все, что отправитель послал после дропнутого, если по истечении некоторого времени получатель так и не получил дропнутый пакет, то отправитель снова шлет дропнутый и всю последовательность за ним.

так вот представьте, что у вас телефон и вы пропустили один пакет, а поток уже расшифровали и дали послушать абону в трубку, смысла в таком пакете не будет никакого и его придется дропать уже после получения, потому и udp, если что-то дропается на пути, то это по сути не важно, просто ухудшается качество связи. если бы это была эхо конференция, типа как рация, когда вы проговорили прием, то получаете данные, то имел бы смысл tcp.

Это сеть с коммутацией пакетов детка :)

в сетях с коммутацией каналов вообще нет контроля доставки, поскольку мы заранее знаем, что все придет в свое время и ниодин пакет не потеряется, все заранее рассчитано и зарезервировано :)

Скорее всего, как я понял, tcp-сессии не меняют маршрутизацию на сетевом уровне, а на всех нижлежащих она может меняться (на сетевом уровне это типа не будет заметно, так?). А udp и icmp трафик типа еще и на сетевом уровне (который IP) прут как хотят, с ассинхронностью там и прочими переменами на-лету. Я правильно вас понял?

сетевой и транспортый (сетевой это ip, транспортый это tcp/udp и в данном контексте icmp) вообще никак не связаны и никак друг на друга не влияют, tcp сессия это понятие исключительно tcp и к сетям не имеет отношения, в контексте iptables существует еще и udp и icmp сессия, однако это исключительно из области iptables.

строго говоря icmp может влиять на сеть, но это уже другая история.

вообще по логике icmp это сетевой протокол, но по уровню инкапсуляции транспортный

Танненбаум помоему попсовый какой то был, когда я его смотрел

тем не менее tcp/ip у него лучше, чем у Олифера, а по ссылке действительно хорошая книга с использованием юниксовых утилит, жаль купить ее нигде нельзя, она древняя очень.

Ну вы просто более научно говорите мне что коммутация каналов на сетевом уровне работает для всех типов IP трафика одинаково со всеми вытекающими (смена маршрутов, ассиметричность и т.д.), а tcp трафик (и sctp например, но не udp) просто в довесок к этому еще и обременен коммутацией пакетов на уровнем выше (гарантия доставки, контрольные суммы и т.д.), что неудобно для некоторого реалтайм-чувствительного трафика.

То что чексуммы и ожидание потерянных пакетов реалтайм-поток обременяет поток - это понятно.

Я отом же говорю про телефонию, только с точки зрения преимущества UDP а не особенностей TCP. это обратная сторона вашего утверждения - udp трафик не имеет особенностей коммутации транспортного уровня, каждый пакет независимо несет свою порцию информации и не зависит от прохождения соседних. это итак понятно.

И ваще коммутация каналов это больше к телефонии относится. В IP сетях с пакетами роль коммутации каналов частично выполняют контраки, частично протоколы линамич. маршрутизации, периодически опрашивающие соседние роутеры, если ктото сдох или долго отвечает, меняет приоритеты у себя в таблице маршрутизации (bgp, ospf). я бы ваще не употреблял термина «коммутация каналов» для интернет-трафика. Это какаято херня из 70х плохо ложащаяся на современные дигитальные сети. E1 наверное все ще использует коммутацию каналов, так как сделан старомодно.

Да, я обязательно почитаю по ссылке, хотя по оглавлению там много основ и чего то старого. Както нашел в сети описание дистрибутива AIX и его тулз - блин там в комплекте куча системных и сетевых тулз идет которых на debian иногда и в репозиториях нет. Вот где мощь unix )). Еще и с документацией. Тененбаума тоже начну тогда читать с сетей. Но та синяя книжеца которую я приводил возможно лучше и современнее будет и там именно взгляд на сети с точки зрения linux, то есть эта книга лишена таких вещей как : - модель OSI - старых ненужностей и «телефонных» тем как у Олифера и в других старых книгах )) термин CIDR например или сети класса А и B - нет а реальной жизни таких сетей больше. - она тупо современнее, писалась позже - виндозных сетей, никаких вам netbios и т.д. microsoft-related ужасов, скриншотов cmd.exe - там именно по сетям, по интернетикам, туннелям и маршрутизации, никаких вам мультиплексоров или спутников или аналоговых сетей. мультикаст вроде описан.

в контексте iptables существует еще и udp и icmp сессия, однако это исключительно из области iptables.

Я про это и говорил в первых сообщениях. И знать предмет комплексно то дело не в iptables вовсе, а в ядре линукс и его контраке. И в коммутаторах зачастую так же. Я писал об этом: чтобы не думать каждый раз куда отправить пакет, если он идет от известного отправителя уже известному получателю - отправляют туда же куда и предыдущий. Хоть это udp, хоть icmp, хоть ipsec. Так что это вам не «iptables виноват», это нормальная технология, а iptables и statefull firewal лежат выше и основываясь уже на этой технологии. Потом я писал что это можно частично назвать «коммутацией каналов» если этот термин вообще применим к ip сетям.

Я бы даже сказал что эти «сессии связи» на IP уровне это нормально. Это только в windows сетях или по олиферу, например, это считается нонсенсом.

сетевой и транспортый (сетевой это ip, транспортый это tcp/udp и в данном контексте icmp)

потому я избегаю термнов «сетевой уровень», «транспортный уровень», не признаю модель OSI, нет четких границ, про Дарвинизм в сетях тоже я писал. Если сесть и вдумчиво читать теорию по ipsec и пытаться переложить ее на абстракцию модели OSI, то... у вас это не получится сделать. В современных сетях всей этой херни нету, надо сделать протокол - смотрят на реалии современных передающих сред и делают некоторый комплексный механизм тесно работающий сразу на нескольких уровнях приснопямятной модели OSI и она идет к черту.

Да, в твоем трейсе. На промежуточных рутерах потеря может быть хоть 100%. Если это просто дропается исмп, на конечном хопе будет 0%

И тебе нужны 2 трейса, до сервера и от него, иначе получаешь неполную картину.

Про потери и шейпинг понятно.

2 трейса сделал выше и получил неполную как мне кажется картину. Обратный трейс инициированный с сервера - скорее всего не есть трейс ответного пакета пришедшего на сервер. А может и есть.

чего то старого

ну большинство этих протоколов изобретены лет 15 - 20 назад :)

Но та синяя книжеца

я кажется знаю о ней, но руки не дошли

MTR сделай, он % потери показывает. Трейспат только задержку.

Читаю «введение» в этой книге : soslan.ru/tcp. Пока все старая, известная информация, читаю - освежаю и бабах! сети A-B-C-D-E ! Нет такого деления больше, это как «определение преступных наклонностей у индивида по строению черепа» - эта наука призвана псевдонаукой. Сети A-B-C-D это тоже устарело, не используется и неактуально. В wiki есть статья про эти сети и что они устарели: http://ru.wikipedia.org/wiki/Классовая_адресация

Бегите от таких книг и читайте современные по сетям. Они ценнее еще и тем что про сети мало пишут с нуля, заново переосмысляют, все кормят старым шлаком, новых книг мало. Не буду читать эту книгу, она опасна, лучше про ipv6 почитать.

Еще раз всем советую «Манн, Крелл: Linux. Администрирование сетей» - она в наше время писалась. Не советуйте другим читать книги по сетям написанные ранее 2000 года со всякими архаизмами.