Как вы знаете, «соседом снизу» транспортного уровня в стеке протоколов является сетевой уровень. В то время как протоколы транспортного уровня обеспечивают логическое соединение между процессами, протоколы сетевого уровня поддерживают логическое соединение между оконечными системами. Данное различие весьма тонкое, однако от этого оно не менее значимо. Мы поясним его на следующем примере. Представьте себе две семьи, одна из которых находится в
В двух предыдущих главах мы коснулись роли транспортного уровня и услуг, предоставляемых его службами прикладному уровню коммуникационной модели. Подведем итог. Протокол транспортного уровня обеспечивает логическое соединение между прикладными процессами, выполняющимися на разных хостах. Логическое соединение с точки зрения приложений выглядит как канал, непосредственно соединяющий процессы, хотя реальная связь между процессами может осуществляться с помощью длинной цепи маршрутизаторов и разнообразных линий
Транспортный уровень, расположенный между прикладным и сетевым уровнями коммуникационной модели, играет ключевую роль в архитектуре Интернета. Особая важность транспортного уровня состоит в том, что он предоставляет услуги непосредственно прикладным процессам, выполняющимся на оконечных системах. Мы продолжим придерживаться установленного ранее подхода, заключающегося в поэтапном изучении базовых принципов организации транспортного уровня и их практического применения в протоколах. Как обычно, наибольшее внимание будет
В качестве примера практического применения методов анализа задержки рассчитаем время ответа для web-страницы, передаваемой по протоколу HTTP, не поддерживающему постоянные соединения. Предположим, что страница состоит из базового HTML-файла и Мрисунков. Для простоты выкладок примем, что размеры всех М + 1 объектов одинаковы и составляют 0 бит. В случае непостоянного HTTP-соединения объекты пересылаются последовательно, один за другим. Таким образом, время ответа
Изменим предыдущую модель, позволив окну перегрузки изменять свой размер. Как мы говорили ранее, в начале передачи сервер устанавливает размер окна перегрузки равным величине MSS и отсылает один сегмент клиенту. Получив квитанцию, сервер увеличивает размер окна перегрузки до величины 2MSS и посылает 2 сегмента с интервалом в S/R с. Получив еще 2 квитанции, сервер увеличивает размер окна перегрузки до величины 4MSS
Несмотря на то что на практике размер окна перегрузки протокола TCP постоянно меняется, для наглядности удобно сначала представить окно перегрузки статическим. Пусть W — положительное целое число, равное размеру статического окна; это означает, что сервер, не ожидая подтверждений, может передать не более W сегментов. Получив запрос, сервер сразу отсылает клиенту W сегментов. Далее сервер пересылает каждый новый сегмент после получения
Мы завершаем эту главу рассмотрением нескольких простых моделей, позволяющих вычислить время, необходимое TCP для передачи объекта (рисунка, текстового файла или музыкального произведения в формате МРЗ). Для каждого объекта мы введем понятие задержки — промежутка времени, проходящего с момента инициирования ТСР-соединения клиентской стороной до полного завершения процесса приема объекта получателем. В моделях, которые будут описаны ниже, учитываются ключевые составляющие задержки: процедура
Даже если механизм, заставляющий UDP-соединения выравнивать пропускные способности линий связи, будет создан, он не решит существующую проблему до конца. Это объясняется тем, что приложениям невозможно запретить использовать параллельные ТСР-соединения. К примеру, параллельные ТСР-соединения применяются web-браузерами для одновременной доставки нескольких объектов web-страницы (число соединений, одновременно поддерживаемых браузером, обычно задается при его настройке). Увеличение числа соединений, устанавливаемых приложением, увеличивает долю пропускной способности,
Выше мы показали, каким образом механизм контроля перегрузки TCP управляет скоростью передачи источника, изменяя размер окна перегрузки. Контролирование перегрузки заставляет многие мультимедиа-приложения (Интернет-телефонию и видеоконференции) отказываться от протокола TCP: снижение скорости передачи для них нежелательно даже при значительных перегрузках в сети. Вместо TCP эти приложения пользуются службами протокола UDP, не имеющего собственного механизма контроля перегрузки. Протокол UDP позволяет приложениям передавать
Предположим, что к TCP-соединений между разными хостами используют одну и ту же проблемную линию связи с пропускной способностью R бит/с (говоря «проблемная линия», мы имеем в виду, что в каждом соединении все остальные линии связи не перегружены и скорость передачи по ним значительно ближе к их пропускной способности, чем по проблемной линии). Предположим, что по каждому из соединений передается файл
Все статьи из рубрики "Транспортный уровень" размещены на сайте Компьютерные сети и многоуровневая архитектура интернета (conlex.kz) в ознакомительных целях.
Уточнения, корректировки и обсуждения статей доступны под текстом статей, в комментариях.
Ответственность, за все изменения, внесённые в систему по советам данных статей, Вы берёте на себя.
Копирование данных статей, без указания ссылки на сайт первоисточника Компьютерные сети и многоуровневая архитектура интернета (conlex.kz), строго запрещено.