Это путаница между базовыми стандартами, которые, действительно работают, и тем, что кому-то хотелось бы, чтобы оно работало. Покажите мене в дампе между рутерами пакеты, соответствующие той теории, на которую Вы пытаетесь ссылаться. Только не в теории на стенде, а чтобы это точно ходило между разными автономными системами
Я не пойму, вы меня на бесплатную лекцию по принципам работы сетей пытаетесь раскрутить что ли?
Если да, то могли бы сразу так и сказать - мне не жалко, рассказал бы, что знаю. А если кроме шуток, то давайте пойдём другим путём.
Выполняется ли маршрутизаторами Internet Protocol версий 4 и 6? Да/Нет.
Выполняется ли маршрутизаторами Internet Control Message Protocol? Да/Нет.
Существуют ли на маршрутизаторах очереди отправки пакетов? Да/Нет.
Если ответ на все три вопроса - "да", то никакие другие стандарты не нужны. Потому что как происходит передача данных? Отправитель начинает посылать получателю пакеты. По Internet Protocol. Они могут проходить через несколько подсетей, в каждой из которых своя скорость передачи данных. В маршрутизаторах более медленных сетей соответственно будет происходить заполнение очередей отправки. Если очередь заполнена, то маршрутизатор выдаст инициатору отправки соответствующее сообщение по протоколу ICMP. Что в ответ сделает отправляющая сторона - целиком зависит от неё. Однако в большинстве случаев отправляющий маршрутизатор притормозит отправку пакетов (работа того самого шейпера, уже упоминавшегося здесь, если конечно я ничего не путаю). Что в свою очередь вызовет заполнение его очереди и отправку сообщения ICMP дальше по цепочке. И т.д., пока вся эта волна не докатится до машины отправителя. Дальше всё зависит от поведения программы на машине отправителя, которая инициировала отправку - настроил ли программист обработку таких ситуаций или нет, и как настроил. Однако, независимо от настроек, ближайший к отправителю маршрутизатор не примет пакеты, пока его очередь не освободится. Здесь возможны различные варианты создания очередей и работы с ними, на этот счёт есть целые теории, однако база в данном случае - IP и ICMP.
Всё вышеописанное работает как в случае связи клиент-сервер по протоколу TCP, так и в случае с UDP. Потому что оба вышеуказанных протокола работают поверх IP и ICMP. И с точки зрения маршрутизатора нет никакой разницы устанавливаете ли вы соединение по протоколу TCP с сервером, который имеет скорость передачи данных в 10 раз выше скорости вашего приёма, или устанавливаете вы p2p соединение с помощью протокола UDP с 10 сидами торрент-раздачи, скорость передачи каждого из которых равна вашей скорости приёма. Если у вас на маршрутизаторе правильно настроена работа с очередями, то ни в первом, ни во втором случае никаких проблем быть не должно. Если же работа с очередями настроена неправильно, то одинаковые проблемы будут в обоих случаях.
Торрент-протокол же лишь позволяет использовать выделенные вам провайдером возможности на полную мощность, не более того. Благодаря наличию не одного условного сервера, который может иметь свои ограничения по скорости отдачи, а нескольких.
Ограничения, которые накладывают на торренты операторы мобильной связи, не что иное, как следствие недобросовестности и криворукости. Во-первых, количество абонентов. В проводной связи у вас всегда известное количество физических портов, а значит и пиковые нагрузки вполне известны, от них вы, как провайдер и пляшете. На вышку же связи может подключаться сильно разное количество абонентов. А поскольку ставить нормальное оборудование дорого, то мы поставим что подешевле, а абонентам срежем скорость - норму прибыли сокращать нельзя, пусть лучше быдл..., простите, клиенты страдают. И платят. За то, чего не получают: хоть в тарифном плане и стоит "безлимит, скорость N килобит/сек", в реальности такая скорость у вас будет в лучшем случае в середине ночи, когда все спят и никто ничего не качает. А скорее всего заявленной скорости вы не увидите никогда. На всё это ещё накладываются чисто радиотехнические проблемы с частотами и их "забиванием". Как результат "безлимит" превращается в очень даже "лимит", причём сильно отличный даже от теоретически заявленного. Ну и торрент в данном случае совершенно недопустим, поскольку из-за кривых настроек маршрутизаторов забьёт наглухо все очереди в них. Или, что вероятнее, забьёт все порты (имею ввиду порты Internet Protocol), которых ввиду экономии едва-едва хватает на работу браузеров у всех желающих. Правда, блокировка всего этого весьма условная, потому что пускаем закачку торрента через прокси и... всё внезапно работает. Но таким хитрожо...умным уже просто в наглую режут скорость, только и всего.
