Разное

Иногда в некоторых тарифных планах заложено ограничение на скорость. А как это делаеться технически? Вот к примеру, размер tcp-окна у меня 5 tcp-пакетов. Сервер мне их сразу все отправляет, они проходят через магистральные маршрутизаторы, попадают в маршрутизатор последней мили, ветка которого идёт на меня. И что, этот маршрутизатор в своей памяти запоминает эти 5 tcp-пакетов, а затем, просто в зависимости от тарифного плана, передаёт их или с большим промежутком времени или с меньшим?

У провайдеров все сложнее, во-первых вы находитесь в их локальной сети, т.е. он знает MAC-адерс вашей сетевой карты. Он просто ограничит вашему адрес (выставив вам соответствующую пропускную способность, чтобы фрейм схлапывался при достижении этого предела). Более того, у него стоит могучая железка NAT, которая позволяет делать с вами все что угодно, хоть скорость вам урезать, до тарифной, хоть торрент-трафик отсечь, или урезать по нему скорость.

[QUOTE]
чтобы фрейм схлапывался при достижении этого предела)
[/QUOTE]
А как они выставят эту пропускную способность? Вот что к примеру мне мешает перепрограммировать сетевую плату так, чтобы она с большим кадром перегоняла данные? И как быть в случае с 3G-модемом?

Ваша плата ничего не решает - она только MAC-адрес предоставляет, провайдеру все-равно какой MAC-адрес (хоть каждый день меняйте), он ориентируется на логин и пароль (в случае 3G-модема соответственно телефонный номер). Перепрограммировать на их стороне нужно.

А как происходит, ограничение скорости? Ведь если сервер, который отправил мне 5 tcp-пакетов, то он должны в конечном итоге оказаться на маршрутизаторе конечной мили, и следовательно в его памяти. Что происходит в этом случае?

Сервер не отправит больше, чем запросит клиент. Если клиент имеет пропускную способность 1Мбит/с - он и будет просить соответствующее количество пакетов в секунду, сервер не будет ему наваливать лишние пакеты. А в случае провайдера, не вы выходите в Интернет, а провайдер, а вы просто участник его локальной сети, с которой он может делать что хочет. Это он отправляет запросы от вашего имени, через NAT и отправляет с той скоростью, с которой считает нужной, а все ответы по вашим запросам пересылает вам. Именно поэтому ваш IP-адрес в локальной сети провайдера (то что вы видите со своего компьютера), зачастую не совпадает с тем IP-адресом, из под которого вы попадаете на сайт. Мне мой компьютер сообщает, что сейчас у меня IP-адрес 10.210.213.137 - таких IP-адресов в Интернете не бывает, с 10. начинаются адреса локальных сетей, т.е. я в локальной сети провайдера и он мне скармливает Интернет с NAT (с нужной ему скоростью), который и выходит в глобальную сеть. Более того, провайдеры за отдельную плату могут назначать статический IP-адрес участникам своей сети, но все-равно вы будете идти через NAT, а не напрямую.

Т.е. если я к примеру со своего компьютера до NAT отправлю слишком много пакетов за 1 секунду, то часть из будет обрезана, не отправлена?

Не совсем так, отправлять запросов вы можете сколько угодно и NAT все их передаст (если вы не забьете полностью канал отправки данных), но с сервером он "договорится" о том, что ответов вы получили столько, чтобы уложиться в выделенную вам пропускную способность. Если он "увидит", что скорость у вас в последние несколько секунд выше, чем вам назначено, он пошлет серверу анонс на меньшее окно и сервер сбавит обороты, будет отправлять меньше данных. Если вы как-то искусственно разовьете бурную деятельность, то NAT ряду источников вообще будет отправлять нулевые анонсы окон и сервер вообще перестанет вам что-либо отправлять.

Вот к примеру я отправил на сервер tcp-пакет, в котором указал, что размер окна у меня 100 килобайт. В этом случае провайдер с помощью NAT возьмёт и исправит мой tcp-пакет, переписав в нём размер окна?

Запросто, причем очень эффективно и быстро за один такт.

Ну а если речь идёт об udp? И что будет если, сервер не "послушаеться NAT", а будет отправлять tcp-пакеты не обращая внимания на размер окна?

UDP-пакеты, если их невозможно принять, просто отбрасываются... на самом деле и с TCP-пакетами такое тоже случается. Однако, если клиент видит, что он не получил и должным образом не обработал TCP-пакет - он пошлет повторный запрос, через некоторое время. В UDP такое просто не предусмотрено - не дошел пакет и черт с ним.

Т.е если к примеру сервер проигнорировал установленное NAT значение размера tcp - окна, и отправил, скажем 13 tcp-пакетов, вместо 5, установленных NAT, то эти лишних 8 пакетов будут не доставлены клиенту?

Серверу совершенно нет смысла выполнять лишнюю работу и игнорировать размер окна. Тут чаще другая картина - клиент попросил 5 пакетов, 5 пакетов ему и пошло, а дошло до него только 3. Если это UDP-протокол, никто даже заморачиваться не будет куда делось 2 пакета, если это TCP-протокол, то клиент пошлет запрос: мне нужен этот и этот пакет, сервер еще раз пошлет их. И так будет продолжаться до тех пор, пока все нужные пакеты не будут успешно доставлены.

А какие ещё существуют механизмы ограничения скорости, помимо замены значения размера окна в tcp-пакетах?

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

А как происходит, ограничение скорости?
На последней миле...на маршрутизаторе, к примеру, по LAN портам можно выставить ограничение по определенной скорости.... сам ставил....