Компьютерные сети

Многоуровневая архитектура Интернета

Архив за апреля, 2008

Для того чтобы переместить пакеты от хоста-отправителя к хосту-получателю, сетевой уровень должен определить путь, или маршрут, следования пакетов. Независимо от того, какую службу предоставляет сетевой уровень, деитаграммную службу (в этом случае различные пакеты данной пары отправитель-получатель могут двигаться по разным маршрутам) или службу виртуальных каналов (в этом случае все пакеты, передаваемые данным отправителем данному получателю, будут перемещаться по одному и тому же пути), сетевой уровень должен определить путь продвижения пакета. Этим занимается протокол маршрутизации сетевого уровня.
Как правило, хост напрямую подключен к одному из маршрутизаторов, так называемому маршрутизатору по умолчанию, или маршрутизатору первого ретрансляционного участка. Когда хост передает пакет, этот пакет попадает на маршрутизатор по умолчанию. Мы будем называть маршрутизатор по умолчанию хоста-источника маршрутизатором-источником, а маршрутизатор хоста-приемника по умолчанию маршрутизатором-приемником. Задача выбора пути пакета от хоста-источника к хосту-приемнику, очевидно, сводится к задаче выбора пути пакета от маршрутизатора-источника к маршрутизатору-приемнику.
Сердцевиной любого протокола маршрутизации является алгоритм, определяющий путь пакета от маршрутизатора-источника к маршрутизатору-приемнику (алгоритм маршрутизации). Задача алгоритма маршрутизации проста: для заданного множества маршрутизаторов и линий, соединяющих маршрутизаторы, алгоритм маршрутизации находит «оптимальный» путь от маршрутизатора-источника к маршрутизатору-приемнику. Как правило, «оптимальный» означает путь с «минимальной стоимостью». Мы увидим, однако, что на практике в игру часто вступают такие стратегические соображения, как вопросы безопасности (например, такое требование, как «маршрутизатор X, принадлежащий организации Y, не должен переправлять пакеты, исходящие из сети, принадлежащий организации Z»), усложняя концептуально простые и элегантные алгоритмы, на теории которых покоится практика маршрутизации в современных сетях.
Читать далее »

Популярность: 0

Находится в разделе Основы маршрутизации

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

Популярность: 0

Находится в разделе Модели сетевого обслуживания

Понятие модели сетевого обслуживания

Опубликовано 28 апреля, 2008

Когда транспортный уровень передающего хоста посылает пакет в сеть (то есть передает его сетевому уровню того же хоста), может ли транспортный уровень положиться на сетевой уровень в деле доставки пакета получателю? Когда посылается большое количество пакетов, будут ли они доставлены транспортному уровню в том же порядке, в котором были отправлены? Сохранятся ли длительности временных интервалов между двумя последовательными пакетами? Будет ли сеть предоставлять обратную связь, извещая о перегрузке? Каковы абстрактные свойства канала, соединяющего транспортные уровни передающего и принимающего хостов? Ответы на эти вопросы определяются моделью обслуживания, предоставляемого сетевым уровнем. Модель сетевого обслуживания определяет характеристики сквозного транспорта данных между двумя периферийными устройствами сети, то есть между передающей и получающей оконечными системами.
Читать далее »

Популярность: 0

Находится в разделе Модели сетевого обслуживания

На рис. 4.1 изображена схема простой сети с двумя хостами, H1 и Н2, и несколькими маршрутизаторами на пути от хоста H1 до хоста Н2. Пусть хост H1 посылает информацию хосту Н2. Рассмотрим роль сетевого уровня на этих хостах и промежуточных маршрутизаторах. Сетевой уровень хоста HI принимает сегменты от транспортного уровня хоста H1, инкапсулирует каждый сегмент в дейтаграмму (единицу обмена сетевого уровня), после чего отправляет дейтаграммы в путь к их адресату; то есть он посылает дейтаграммы своему ближайшему маршрутизатору R1. На принимающем хосте Н2 сетевой уровень получает дейтаграммы от своего ближайшего маршрутизатора (в данном случае R2), извлекает сегменты транспортного уровня и доставляет их транспортному уровню хоста Н2. Основная задача маршрутизаторов заключается в «продвижении» дейтаграмм из входных линий связи в выходные линии. Обратите внимание, что на рис. 4.1 маршрутизаторы показаны с сокращенным стеком протоколов, то есть без уровней выше сетевого, потому что на маршрутизаторах не работают протоколы прикладного и транспортного уровней (исключая задачи контроля).
Читать далее »

Популярность: 0

Находится в разделе Модели сетевого обслуживания

Расчет времени ответа для протокола HTTP

Опубликовано 26 апреля, 2008

В качестве примера практического применения методов анализа задержки рассчитаем время ответа для web-страницы, передаваемой по протоколу HTTP, не поддерживающему постоянные соединения. Предположим, что страница состоит из базового HTML-файла и Мрисунков. Для простоты выкладок примем, что размеры всех М + 1 объектов одинаковы и составляют 0 бит.
Читать далее »

Популярность: 0

Находится в разделе Модель задержек протокола TCP

Динамическое окно перегрузки

Опубликовано 25 апреля, 2008

Изменим предыдущую модель, позволив окну перегрузки изменять свой размер. Как мы говорили ранее, в начале передачи сервер устанавливает размер окна перегрузки равным величине MSS и отсылает один сегмент клиенту. Получив квитанцию, сервер увеличивает размер окна перегрузки до величины 2MSS и посылает 2 сегмента с интервалом в S/R с. Получив еще 2 квитанции, сервер увеличивает размер окна перегрузки до величины 4MSS и отсылает клиенту 4 сегмента также с интервалом в S/R с. Таким образом, каждый раз по истечении времени оборота окно перегрузки увеличивается вдвое, как показывает временная диаграмма на рис. 3.53.
Читать далее »

Популярность: 0

Находится в разделе Модель задержек протокола TCP

Статическое окно перегрузки

Опубликовано 24 апреля, 2008

Несмотря на то что на практике размер окна перегрузки протокола TCP постоянно меняется, для наглядности удобно сначала представить окно перегрузки статическим. Пусть W — положительное целое число, равное размеру статического окна; это означает, что сервер, не ожидая подтверждений, может передать не более W сегментов. Получив запрос, сервер сразу отсылает клиенту W сегментов. Далее сервер пересылает каждый новый сегмент после получения одной квитанции от клиента; процесс продолжается до завершения передачи объекта. Возможны два случая.

□ WS/R > RTT + S/R. Это соотношение означает, что сервер получает квитанцию для первого сегмента первого окна до завершения передачи сегментов первого окна.
□ WS/R < RTT + S/R. Это соотношение означает, что сервер заканчивает передачу сегментов окна раньше, чем получает квитанцию для первого сегмента окна.

Рассмотрим первый из случаев (рис. 3.51). Размер окна положен равным четырем сегментам: W= 4. Инициирование ТСР-соединения занимает все время оборота; на втором обороте клиент отсылает серверу запрос на получение объекта, вложенный в последний сегмент тройного рукопожатия. Таким образом, прием объекта клиентом начинается по истечении удвоенного времени. Новые сегменты поступают к клиенту с периодичностью в S/R с и подтверждаются им. Поскольку сервер получает первое подтверждение до завершения передачи сегментов окна, он имеет возможность передавать сегменты следующего окна сразу по завершении передачи сегментов предыдущего окна. Все подтверждения поступают на сервер с периодичностью S/R с, поэтому сервер передает новые сегменты без простоев в ожидании подтверждений. Таким образом, если передача объекта начата со скоростью R, то такая скорость сохраняется на протяжении всего процесса передачи, а следовательно, задержка составляет

2RTT + 0/R

351.png
Читать далее »

Популярность: 0

Находится в разделе Модель задержек протокола TCP

Мы завершаем эту главу рассмотрением нескольких простых моделей, позволяющих вычислить время, необходимое TCP для передачи объекта (рисунка, текстового файла или музыкального произведения в формате МРЗ). Для каждого объекта мы введем понятие задержки — промежутка времени, проходящего с момента инициирования ТСР-соединения клиентской стороной до полного завершения процесса приема объекта получателем. В моделях, которые будут описаны ниже, учитываются ключевые составляющие задержки: процедура рукопожатия, медленный старт, время передачи объекта.
Читать далее »

Популярность: 0

Находится в разделе Модель задержек протокола TCP

Даже если механизм, заставляющий UDP-соединения выравнивать пропускные способности линий связи, будет создан, он не решит существующую проблему до конца. Это объясняется тем, что приложениям невозможно запретить использовать параллельные ТСР-соединения. К примеру, параллельные ТСР-соединения применяются web-браузерами для одновременной доставки нескольких объектов web-страницы (число соединений, одновременно поддерживаемых браузером, обычно задается при его настройке). Увеличение числа соединений, устанавливаемых приложением, увеличивает долю пропускной способности, «захватываемую» для передачи данных этого приложения. Представьте линию связи с пропускной способностью R, обслуживающую одновременно 9 приложений клиент/сервер, каждое из которых устанавливает одно TCP-соединение. В случае появления в линии связи еще одного соединения все соединения получат возможность передавать данные со скоростью приблизительно R/10. Однако если эта линия станет использоваться приложением, установившим И параллельных TCP-соединений, то окажется, что оно будет передавать свои данные со скоростью, превышающей R/21 Поскольку web-трафик составляет значительную часть общего трафика Интернета, подобные ситуации, к сожалению, нередки.

Популярность: 0

Выравнивание скоростей и UDP

Опубликовано 21 апреля, 2008

Выше мы показали, каким образом механизм контроля перегрузки TCP управляет скоростью передачи источника, изменяя размер окна перегрузки. Контролирование перегрузки заставляет многие мультимедиа-приложения (Интернет-телефонию и видеоконференции) отказываться от протокола TCP: снижение скорости передачи для них нежелательно даже при значительных перегрузках в сети. Вместо TCP эти приложения пользуются службами протокола UDP, не имеющего собственного механизма контроля перегрузки. Протокол UDP позволяет приложениям передавать данные с любой нужной им скоростью, не ограничивая их равными долями пропускной способности и допуская потери пакетов при наступлении перегрузок. С позиций TCP мультимедиа-приложения не обеспечивают выравнивание скоростей, поскольку не взаимодействуют с другими соединениями и не регулируют свои скорости передачи. Одной из главных задач, стоящих перед современными исследователями в области Интернет-технологий, является создание механизмов контроля перегрузки, ограждающих пропускную способность Интернета от «губительного» воздействия UDP-соединений.

Популярность: 0