Что такое протокол udp. Чем отличается протокол TCP от UDP, простым языком. Надежность и решения проблемы перегрузок
Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.
Привет, меня зовут Гленн Фидлер и я приветствую вас в первой статье из моей онлайн-книги “Сетевое программирование для разрабочиков игр”.
В этой статье мы начнем с самых базовых аспектов сетевого программирования - приема и передачи данных по сети. Прием и передача данных - это основная и наиболее простая часть из всего круга задач, которыми занимаются сетевые программисты, но часто бывает сложно определить, каким путем лучше двигаться. Уделите этой части достаточно внимания - если у вас останется непонимание, то это может привести к ужасным последствиям для вашей многопользовательской игры в дальнейшем!
Вы, скорее всего, уже что-нибудь слышали о сокетах, и, возможно, знаете, что они делятся на два основных типа - TCP и UDP. Первое, что нужно решить при разработке многопользовательской игры - это какой тип сокетов использовать - TCP, UDP, или оба?
Выбор типа сокетов полностью зависит от жанра игры, которую разрабатываете. В данном цикле статей я буду считать, что вы пишете игру в стиле action - наподобие Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress и т.п.
Теперь мы более подробно рассмотрим свойства каждого типа сокетов (учитывая тот факт, что мы разрабатыватаем игру в стиле action), и немного углубимся в детали работы сети интернет. После подробного обзора правильный вариант станет очевиден!
TCP расшифровывается как “transmission control protocol” (протокол контроля передачи), а IP - как “internet protocol”. Вместе они лежат в основе практически всего, что вы делаете в сети, начиная от просмотра веб-страниц и кончая общением в IRC и электронной почтой - все это работает на основе TCP/IP.
Если вы когда-либо уже использовали TCP сокеты, то вы должны знать, что TCP - это протокол, использующий принцип надежного соединения. Это означает, что вы устанавливаете соединение между двумя компьютерами, и затем пересылаете данные между ними подобно тому, как если бы вы записывали информацию в файл на одном компьютере, а на другом - считывали бы ее из того же файла.
При этом соединение считается надежным и последовательным - то есть, вся информация, которую вы посылаете, гарантированно должна дойти до получателя в том же порядке, в каком была отправлена. Также TCP соединение можно считать непрерывным потоком данных - протокол сам заботится о разбивке данных на пакеты и пересылке их по сети.
Еще разок - все просто, как обычная запись или чтение из файла. Элементарно, Ватсон!
Но такая простота в обращении совершенно отличается от того, что на самом деле происходит «под капотом», на более низком уровне - уровне протокола IP.
На этом уровне нет понятия соединения - вместо этого отдельные пакеты передаются от одного компьютера к другому. Можно представить этот процесс как передачу записки от одного человека к другому в комнате, полной народу: в конце концов записка попадает к кому надо, но при этом пройдя через множество рук.
При этом нет никакой гарантии того, что записка дойдет до адресата. Отправитель просто отправляет записку в надежде, что она дойдет, но при этом даже не знает, дошло ли послание или нет - до тех пор, пока получатель не решит написать в ответ.
Естественно, в реальности все немного сложнее, поскольку компьютер-отправитель не знает точную последовательность компьютеров в сети, через которые надо передать пакет, чтобы он добрался как можно быстрее. Иногда IP передает несколько копий одного и того же пакета, которые могут идти до адресата разными путями - и, скорее всего, дойдут в разное время.
А что, если мы захотим пересылать информацию между компьютерами не в стиле чтения/записи в файл, а непосредственно отправляя и получая отдельные пакеты?
Что ж, мы можем сделать это, используя UDP. UDP расшифровывается как “user datagram protocol” (протокол пользовательских датаграмм), и он работает поверх IP (как и TCP), но вместо добавления кучи функциональности он представляет собой лишь небольшую надстройку над IP.
Используя UDP, мы можем отослать пакет по определенному IP адресу (к примеру, 112.140.20.10) и порту (к примеру, 52423), и он будет передаваться от компьютера к компьютеру, пока не достигнет цели (или не потеряется по пути).
При этом, на стороне приемника мы просто сидим и ждем, прослушивая определенный порт (52423 в нашем случае), и, когда на него приходит пакет от кого-либо (помним, что соединения не используются), мы получаем об этом уведомление с адресом и портом компьютера-отправителя, размером пакета, и после этого можем прочитать данные из этого пакета.
Протокол UDP не гарантирует доставку данных. На практике большинство пакетов, конечно, доходят, но всегда имеются потери около 1-5%, а иногда бывают периоды времени, в которые пакеты вообще не доходят (помните, что между отправителем и получателем могут находиться тысячи компьютеров, на любом из которых что-то может отказать или сломаться).
Также UDP не гарантирует порядок доставки пакетов. Вы можете отправить пять пакетов по порядку - 1, 2, 3, 4, 5 - а прийти они могут совершенно в другом порядке - к примеру, 3, 1, 2, 5, 4. Опять же, на практике, они скорее всего придут в правильном порядке в большинстве случаев, но полагаться на это нельзя!
Наконец, хоть UDP и ничего особо не добавляет к IP, одну вещь он все-таки гарантирует. Если вы пересылаете пакет, то он либо дойдет полностью, либо не дойдет вообще. Так, если вы пересылаете пакет в 256 байт другому компьютеру, то он не может получить только первые 100 байт от пакета - он обязательно должен получить все 256 байт. Это реально единственная вещь, которую гарантирует протокол UDP - все остальное ложится на ваши плечи.
Итак, нам нужно решить - использовать TCP или UDP сокеты? Давайте взглянем на их свойства:
- Использует принцип соединений
- Гарантирует доставку и очередность
- Автоматически разбивает информацию на пакеты
- Следит за тем, чтобы не пересылать данные слишком интенсивно (контроль потока данных)
- Легко использовать - как запись/чтение из файла
- Не использует принцип соединений - придется реализовывать это вручную
- Не гарантирует доставку и порядок доставки пакетов - они могут дойти в неправильном порядке, с дубликатами, или вообще не дойти!
- Нужно вручную разбивать данные на пакеты и отправлять их
- Нужно следить за тем, чтобы не пересылать данные слишком интенсивно
- Если пакет потеряется, то нужно как-то это отследить, и в случае необходимости переслать его заново
А вот и нет.
Использовать TCP - это наверное, худшая ошибка, которую можно совершить, разрабатывая многопользовательскую игру. Чтобы понять почему, давайте разберемся, что делает TCP таким простым в использовании!
Как работает TCP
TCP и UDP оба работают поверх IP, но по факту они совершенно разные. UDP ведет себя очень похоже на IP, в то время как TCP абстрагирует пользователя от всех проблем с пакетами, делая взаимодействие с ним похожим на чтение/запись в файл.Итак, как же он это делает?
Во-первых, TCP использует абстракцию потока данных - вы можете просто записывать байты данных в этот поток, и TCP позаботится о том, чтобы они дошли до адресата. Так как протокол IP передает данные пакетами, а TCP работает поверх IP, TCP должен разбивать поток входных данных пользователя на отдельные пакеты. Таким образом, внутри TCP некоторая логика собирает данные в очередь, и, когда их накапливается достаточно много, она формирует пакет и отправляет его адресату.
Такое поведение может стать проблемой для нашей многопользовательской игры, если нужно передавать очень маленькие пакеты. Может случиться так, что TCP решит не передавать наши данные, пока их не накопится достаточно, чтобы сформировать пакет определенного размера (скажем, больше ста байт). И это - большая проблема, потому что необходимо передавать данные с клиента (нажатия клавиш игрока) на сервер как можно быстрее, и если при этом будут возникать задержки из-за буферизации данных протоколом, то для игрока на клиентской стороне игра будет происходить далеко не самым приятным образом. При этом обновление объектов игры будет происходить с задержкой и редко - тогда как нам нужно делать обновление объектов вовремя и часто.
В TCP есть опция, призванная исправить это - “TCP_NODELAY”. Она говорит протоколу, чтобы он не ждал накопления данных в очереди на отправку, а отсылал их сразу.
К сожалению, даже с установленной данной опцией, у TCP наблюдается множество проблем при использовании его в сетевых играх.
Корень всех проблем заключается в том, каким образом TCP обрабатывает пакеты, потерянные или пришедшие вне очереди, создавая иллюзию надежного и последовательного соединения.
Как TCP обеспечивает надежность соединения
При передаче TCP разбивает поток данных на отдельные пакеты, пересылает их по сети, используя ненадежный протокол IP, и затем на принимающем компьютере восстанавливает из принятых пакетов первоначальный поток.Но что будет, если один из пакетов не дойдет? Или если пакеты придут не по порядку, или с дубликатами?
Если особо не углубляться в детали работы TCP (а это реально очень сложная тема - можете почитать в TCP/IP Illustrated), процесс выглядит так: TCP отправляет пакет, определяет, что пакет не дошел, и заново отправляет тот же пакет адресату. Дублирующиеся пакеты отсеиваются на стороне адресата, а пакеты, пришедшие не по порядку - переупорядочиваются, чтобы все было как надо - надежно и по порядку.
Проблема заключается в том, что когда TCP таким образом “синхронизирует” поток данных, в случае потери пакета передача останавливается до тех пор, пока потерянный пакет не будет отправлен заново (и получен адресатом). Если во время ожидания придут новые данные, они будут поставлены в очередь, и вы не сможете прочитать их, пока не дойдет тот самый потерянный пакет. Сколько времени занимает посылка пакета заново? Она занимает как минимум время, равное времени прохождения пакета туда и обратно (когда TCP определяет, какой пакет надо отправить заново), плюс время на повторную доставку потерянного пакета. Так что, если пинг между компьютерами составляет 125 мс, повторная передача пакета займет примерно одну пятую секунды, а в худшем случае - до полсекунды (представьте, если вдруг заново отправленный пакет тоже потеряется). Веселуха!
Почему никогда не стоит использовать TCP для многопользовательских игр
Проблема с использованием TCP в сетевых играх заключается в том, что, в отличие от браузеров, электронной почты и прочих приложений, игры завязаны на взаимодействии в реальном времени. Для многих аспектов игры, например, нажатых пользователем клавиш и положения игроков в игре, неважно, что происходило секунду назад, а важно только наиболее актуальное состояние игрового мира.Рассмотрим простой пример многопользовательской игры, например, 3d-шутер. Сетевая часть в игре построена очень просто: каждую итерацию цикла игры клиент посылает на сервер описание всех действий игрока (нажатые клавиши, положение мыши и т.п.), и каждую итерацию сервер обрабатывает эти данные, обновляет модель игрового мира и посылает обратно клиенту текущие позиции объектов мира, чтобы тот отрисовал игроку новый кадр.
Итак, в нашей игре, если пакет будет потерян при передаче по сети, игра останавливается и ждет, пока пакет не будет доставлен заново. На клиентской стороне игровые объекты замирают, и на сервере игроки также не могут двигаться или стрелять, так как сервер не может принимать новые пакеты. Когда потерянный пакет наконец доходит, в нем содержится уже устаревшая информация, которая уже является неактуальной. К тому же после этого приходят и все те пакеты, которые накопились в очереди за время ожидания, и их всех нужно обработать за одну итерацию цикла. Полная неразбериха!
К сожалению, изменить такое поведение TCP никак нельзя, да и не надо, так как в нем и заключается смысл TCP. Это - необходимость, чтобы сделать передачу данных через интернет надежным и последовательным потоком данных.
Но нам не нужен надежный и последовательный поток данных.
Нам нужно, чтобы данные доходили от клиента к серверу как можно быстрее, и мы не хотим ждать повторной отправки данных.
Вот почему никогда не следует использовать TCP для многопользовательских игр.
Но подождите! Почему я не могу использовать и UDP, и TCP вместе?
Для игровых данных реального времени, например, нажатий пользователя и состояния игрового мира, важны только наиболее актуальные данные, но для других типов данных, например, наборов команд, пересылаемых от одного компьютера к другому, надежность и последовательность канала может быть очень важна.
Конечно, велико искушение использовать UDP для передачи данных пользовательского ввода и состояния мира, а TCP - для тех данных, которые должны быть гарантированно доставлены. Возможно, вы даже думаете, что можно сделать несколько “потоков” команд - например, один для загрузки уровней, другой - для команд AI. Вы думаете: “Мне не нужно, чтобы команды AI ждали в очереди, если потеряется пакет с данными для загрузки уровня, ведь они же совершенно не связаны!”. В данном случае вы правы, и вы можете решить создать по TCP сокету на каждый поток команд.
На первый взгляд, это отличная идея. Но проблема в том, что раз TCP и UDP оба работают поверх IP, пакеты обоих протоколов будут влиять друг на друга - уже на уровне IP. Как конкретно будет проявляться это влияние - очень сложный вопрос, и связан он с механизмами обеспечения надежности в TCP. Но, в любом случае, знайте, что использование TCP обычно приводит к увеличению потерь UDP пакетов. Если хотите узнать об этом больше, можете прочитать
Говоря о безопасности информации, мы имеем в виду конфиденциальность, целостность и доступность информации в каждый момент времени. И если с конфиденциальностью и доступностью все понятно, то как обеспечить целостность информации при ее передаче по сети? Для решения этой задачи нам пригодится знание сетевых протоколов. В данной статье мы рассмотрим протоколы TCP и UDP. Они входят в стек протоколов TCP/IP, относятся к транспортному уровню модели OSI и используются для передачи информации от узла к узлу.
Что из себя представляет каждый из этих протоколов, в чем их отличие и когда целесообразнее использовать UDP подключение, а когда TCP.
UDP
UDP protocol – протокол, обеспечивающий передачу данных (датаграмм) без предварительного создания соединения между хостами. При отправке датаграмм нет уверенности в существовании получателя и его готовности к обмену. Сетевой протокол UDP не обеспечивает также упорядочивание датаграмм при получении. Он используется приложениями для которых существенное значение имеет время доставки, когда нет возможности ждать задержавшиеся или запрашивать потерянные пакеты, например, в системах реального времени. Датаграммы могут доставляться не в заданном порядке, дублироваться или вовсе не доставляться. Поэтому протокол UDP называют «ненадёжным протоколом датаграмм».
Приложения, использующие протокол UDP не чувствительны к потерям данных, нарушению порядка получения датаграмм и дублированию. При этом они могут использовать механизмы обеспечения надёжности на прикладном уровне.
TCP
Протокол передачи данных TCP – протокол обеспечивающий надежную доставку пакетов данных, он обеспечивает установку соединения между двумя хостами методом «рукопожатия», после которого может осуществляться обмен данными.
Перед началом передачи пакетов через TCP соединение устанавливается сессия с получателем, в рамках которой затем производится передача данных. Это позволяет убедиться в том, что получатель существует и готов принимать данные. После завершения передачи сессия закрывается, получатель извещается о том, что данных больше не будет, а отправитель извещается о том, что получатель извещён.
Каждый пакет при обмене имеет свой порядковый номер. TCP автоматически упорядочивает пакеты, используя порядковый номер, и передает после склейки на уровень приложений. После отправки нескольких пакетов, ожидается подтверждение и порядковый номер следующего пакета. Если подтверждение не получено, отправка повторяется, если попытки не увенчались успехом, сессия разрывается. Количество пакетов данных, на которые будет запрашиваться подтверждение, зависит от надежности сети. Если данные теряются, то подтверждение автоматически запрашивается чаще. Это называется механизмом скользящего окна (sliding window), благодаря которому TCP может работать с сетями, независимо от уровня их надежности.
Применение TCP целесообразно там, где недопустима потеря данных, например, при авторизации, а также при передаче шифрованной информации.
TCP и UDP отличия
Означает ли это, что протокол UDP не стоит использовать? Вовсе нет. За счет отсутствия «гарантии доставки» протокол UDP обеспечивает более высокую скорость передачи данных, чем TCP. По этой причине UDP оптимален для сетевых и онлайн игр, просмотра потокового видео, организации видео-связи и IP телефонии.
Делитесь полезной информацией с близкими.
8 ответов
TCP - ориентированный на соединение поток по IP-сети. Он гарантирует, что все отправленные пакеты достигнут адресата в правильном порядке. Это подразумевает использование пакетов подтверждения, отправленных обратно отправителю, и автоматическую повторную передачу, вызывая дополнительные задержки и общую менее эффективную передачу, чем UDP .
UDP - протокол без подключения. Связь ориентирована на датаграмму. Целостность гарантируется только на одной дейтаграмме. Дейтаграммы достигают цели и могут выходить из строя или вообще не поступать. Он более эффективен, чем TCP , потому что он использует не ACK. Он обычно используется для обмена в режиме реального времени, когда небольшой процент потери пакетов лучше, чем накладные расходы на соединение TCP .
В определенных ситуациях используется UDP , поскольку он позволяет передавать пакетную передачу. Это иногда является фундаментальным в таких случаях, как протокол DHCP , поскольку клиентская машина еще не получила адрес IP (это протокол протокола t26 >), и не будет никакого способа установить TCP поток без адреса IP .
UDP (User Datagram Protocol) - это обычный широко используемый протокол в Интернете. Однако UDP никогда не используется для отправки важных данных, таких как веб-страницы, сведения о базе данных и т.д.; UDP обычно используется для потоковой передачи аудио и видео. Потоковые медиа, такие как аудиофайлы Windows Media (.WMA), Real Player (.RM) и другие, используют UDP, потому что он предлагает скорость! Причина, по которой UDP работает быстрее, чем TCP, заключается в том, что нет контроля потока или исправления ошибок. На данные, отправленные через Интернет, влияют столкновения, и ошибки будут присутствовать. Помните, что UDP касается только скорости. Это основная причина, по которой потоковые медиа не являются качественными.
1) TCP является ориентированным на соединение и надежным, когда UDP является соединением меньше и ненадежным.2) TCP требует дополнительной обработки на уровне сетевого интерфейса, где, как и в UDP, нет.
3) TCP использует трехстороннее рукопожатие, управление перегрузкой, управление потоком и другой механизм, чтобы обеспечить надежную передачу.
4) UDP в основном используется в случаях, когда задержка пакета более серьезна, чем потеря пакетов.
Подумайте о TCP как о запланированном расписании UPS/FedEx по расписанию UPS/FedEx пакетов между двумя местоположениями, в то время как UDP эквивалентен отправке открытки в почтовый ящик.
UPS/FedEx сделает все возможное, чтобы убедиться, что пакет, на который вы отправляете почту, попадает туда и получает его вовремя. С почтовой карточкой вам повезло, если она вообще придет, и она может выйти из строя или поздно (сколько раз вы получили открытку от кого-то ПОСЛЕ того, как они вернулись домой из отпуска?)
TCP как можно ближе к гарантированному протоколу доставки, так как вы можете получить UDP - это просто "лучшее усилие".
Причины UDP используются для DNS и DHCP:
DNS - TCP требует больше ресурсов с сервера (который прослушивает подключения), чем от клиента. В частности, когда соединение TCP закрыто, сервер должен помнить данные соединения (удерживая их в памяти) в течение двух минут во время состояния, известного как TIME_WAIT_2. Это функция, которая защищает от ошибочно повторяющихся пакетов из предыдущего соединения, которые интерпретируются как часть текущего соединения. Поддержание TIME_WAIT_2 использует память ядра на сервере. Запросы DNS небольшие и часто поступают от разных клиентов. Эта модель использования усугубляет нагрузку на сервер по сравнению с клиентами. Считалось, что использование UDP, не имеющего соединений и не поддерживающего состояние на клиенте или сервере, улучшит эту проблему.
DHCP - DHCP является расширением BOOTP. BOOTP - это протокол, который клиентские компьютеры используют для получения информации о конфигурации с сервера, в то время как клиент загружается. Чтобы найти сервер, широковещательная передача отправляется с запросом на серверы BOOTP (или DHCP). Трансляция может быть отправлена только через протокол без установления соединения, такой как UDP. Поэтому BOOTP требовал хотя бы одного UDP-пакета для широковещательной передачи на сервере. Кроме того, поскольку BOOTP работает, пока клиент... загружается, и это период времени, когда клиент может не загружать и запускать весь свой стек TCP/IP, UDP может быть единственным протоколом, который клиент готов обрабатывать при этом время. Наконец, некоторые клиенты DHCP/BOOTP имеют только UDP на борту. Например, некоторые IP-термостаты реализуют только UDP. Причина в том, что они построены с такими крошечными процессорами и небольшим объемом памяти, которые не могут выполнять TCP, но им все равно нужно получить IP-адрес при загрузке.
Как уже упоминалось, UDP также полезен для потоковой передачи мультимедиа, особенно аудио. Разговоры лучше звучат в зависимости от сетевого отставания, если вы просто отбрасываете задержанные пакеты. Вы можете сделать это с помощью UDP, но с TCP все, что вы получаете во время задержки, - это пауза, за которой следует звук, который всегда будет задерживаться на столько, сколько он уже приостановил. Для двусторонних телефонных разговоров это неприемлемо.
Одним из отличий является сокращение
UDP
. Отправляйте сообщение и не смотрите назад, если он достиг цели, протокол без установления соединения
TCP
: отправить сообщение и гарантировать, что вы достигнете адресата, протокол, ориентированный на соединение
User Datagram Protocol - UDP
Протокол UDP - это один из двух протоколов транспортного уровня, которые используются в стеке протоколов TCP/IP. UDP позволяет прикладной программе передавать свои сообщения по сети с минимальными издержками, связанными с преобразованием протоколов уровня приложения в протокол IP. Однако при этом, прикладная программа сама должна заботиться о подтверждении того, что сообщение доставлено по месту назначения. Заголовок UDP-датаграммы (сообщения) имеет вид, показанный на рисунке 2.10.
Рис. 2.10. Структура заголовка UDP-сообщения
Единица данных протокола UDP называется UDP-пакетом или пользовательской дейтаграммой (user datagram). UDP-пакет состоит из заголовка и поля данных, в котором размещается пакет прикладного уровня. Заголовок имеет простой формат и состоит из четырех двухбайтовых полей:
UDP source port - номер порта процесса-отправителя,
UDP destination port - номер порта процесса-получателя,
UDP message length - длина UDP-пакета в байтах,
UDP checksum - контрольная сумма UDP-пакета
Не все поля UDP-пакета обязательно должны быть заполнены. Если посылаемая дейтаграмма не предполагает ответа, то на месте адреса отправителя могут помещаться нули. Можно отказаться и от подсчета контрольной суммы, однако следует учесть, что протокол IP подсчитывает контрольную сумму только для заголовка IP-пакета, игнорируя поле данных
Порты в заголовке определяют протокол UDP как мультиплексор, который позволяет собирать сообщения от приложений и отправлять их на уровень протоколов. При этом приложение использует определенный порт. Взаимодействующие через сеть приложения могут использовать разные порты, что и отражает заголовок пакета. Всего можно определить 216 разных портов. Первые 256 портов закреплены за, так называемыми "well known services", к которым относятся, например, 53 порт UDP, который закреплен за сервисом DNS.
Поле Length определяет общую длину сообщения. ПолеChecksum служит для контроля целостности данных. Приложение, которое использует протокол UDP должно само заботится о целостности данных, анализируя поля Checksum и Length. Кроме этого, при обмене данными по UDP прикладная программа сама должна заботится о контроле доставки данных адресату. Обычно это достигается за счет обмена подтверждениями о доставке между прикладными программами.
Наиболее известными сервисами, основанными на UDP, является служба доменных имен BIND и распределенная файловая система NFS. Если возвратиться к примеру traceroute, то в этой программе также используется транспорт UDP. Собственно, именно сообщение UDP и засылается в сеть, но при этом используется такой порт, который не имеет обслуживания, поэтому и порождается ICMP-пакет, который и детектирует отсутствие сервиса на принимающей машине, когда пакет наконец достигает машину-адресата.
Transfer Control Protocol - TCP
Если для приложения контроль качества передачи данных по сети имеет значение, то в этом случае используется протокол TCP. Этот протокол еще называют надежным, ориентированным на соединение и потокоориентированным протоколом. Прежде чем обсудить эти свойства протокола, рассмотрим формат передаваемой по сети датаграммы (рисунок 2.11). Согласно этой структуре, в TCP, как и в UDP, имеются порты. Первые 256 портов закреплены за WKS, порты от 256 до 1024 закреплены за Unix-сервисами, а остальные можно использовать по своему усмотрению. В поле Sequence Number определен номер пакета в последовательности пакетов, которая составляет все сообщение, за тем идет поле подтвержденияAsknowledgment Number и другая управляющая информация.
Рис. 2.11. Структура пакета TCP
Порт источника (SOURS PORT) занимает 2 байта, идентифицирует процесс-отправитель;
Порт назначения (DESTINATION PORT) занимает 2 байта, идентифицирует процесс-получатель;
Последовательный номер (SEQUENCE NUMBER) занимает 4 байта, указывает номер байта, который определяет смещение сегмента относительно потока отправляемых данных;
Подтвержденный номер (ACKNOWLEDGEMENT NUMBER) занимает 4 байта, содержит максимальный номер байта в полученном сегменте, увеличенный на единицу; именно это значение используется в качестве квитанции;
Длина заголовка (HLEN) занимает 4 бита, указывает длину заголовка сегмента TCP, измеренную в 32-битовых словах. Длина заголовка не фиксирована и может изменяться в зависимости от значений, устанавливаемых в поле Опции;
Резерв (RESERVED) занимает 6 битов, поле зарезервировано для последующего использования;
Кодовые биты (CODE BITS) занимают 6 битов, содержат служебную информацию о типе данного сегмента, задаваемую установкой в единицу соответствующих бит этого поля:
URG - срочное сообщение;
ACK - квитанция на принятый сегмент;
PSH - запрос на отправку сообщения без ожидания заполнения буфера;
RST - запрос на восстановление соединения;
SYN - сообщение используемое для синхронизации счетчиков переданных данных при установлении соединения;
FIN - признак достижения передающей стороной последнего байта в потоке передаваемых данных.
Окно (WINDOW) занимает 2 байта, содержит объявляемое значение размера окна в байтах;
Контрольная сумма (CHECKSUM) занимает 2 байта, рассчитывается по сегменту;
Указатель срочности (URGENT POINTER) занимает 2 байта, используется совместно с кодовым битом URG, указывает на конец данных, которые необходимо срочно принять, несмотря на переполнение буфера;
Опции (OPTIONS) - это поле имеет переменную длину и может вообще отсутствовать, максимальная величина поля 3 байта; используется для решения вспомогательных задач, например, при выборе максимального размера сегмента;
Заполнитель (PADDING) может иметь переменную длину, представляет собой фиктивное поле, используемое для доведения размера заголовка до целого числа 32-битовых слов.
Надежность TCP заключается в том, что источник данных повторяет их посылку, если только не получит в определенный промежуток времени от адресата подтверждение об их успешном получении. Этот механизм называется Positive Asknowledgement with Retransmission (PAR) . Как мы ранее определили, единица пересылки (пакет данных, сообщение и т.п.) в терминах TCP носит название сегмента. В заголовке TCP существует поле контррольной суммы. Если при пересылке данные повреждены, то по контрольной сумме модуль, вычленяющий TCP-сегменты из пакетов IP, может определить это. Поврежденный пакет уничтожается, а источнику ничего не посылается. Если данные не были повреждены, то они пропускаются на сборку сообщения приложения, а источнику отправляется подтверждение.
Ориентация на соединение определяется тем, что прежде чем отправить сегмент с данными, модули TCP источника и получателя обмениваются управляющей информацией. Такой обмен называется handshake (буквально "рукопожатие"). В TCP используется трехфазный hand-shake:
Источник устанавливает соединение с получателем, посылая ему пакет с флагом "синхронизации последовательности номеров" (Synchronize Sequence Numbers - SYN). Номер в последовательности определяет номер пакета в сообщении приложения. Это не обязательно должен быть 0 или единица. Но все остальные номера будут использовать его в качестве базы, что позволит собрать пакеты в правильном порядке;
Получатель отвечает номером в поле подтверждения получения SYN, который соответствует установленному источником номеру. Кроме этого, в поле "номер в последовательности" может также сообщаться номер, который запрашивался источником;
Источник подтверждает, что принял сегмент получателя и отправляет первую порцию данных.
Графически этот процесс представлен на рисунке 2.12.
Рис. 2.12. Установка соединения TCP
После установки соединения источник посылает данные получателю и ждет от него подтверждений о их получении, затем снова посылает данные и т.д., пока сообщение не закончится. Заканчивается сообщение, когда в поле флагов выставляется бит FIN, что означает "нет больше данных".
Потоковый характер протокола определяется тем, что SYN определяет стартовый номер для отсчета переданных байтов, а не пакетов. Это значит, что если SYN был установлен в 0, и было передано 200 байтов, то номер, установленный в следующем пакете будет равен 201, а не 2.
Понятно, что потоковый характер протокола и требование подтверждения получения данных порождают проблему скорости передачи данных. Для ее решения используется "окно" - поле - window. Идея применения window достаточно проста: передавать данные не дожидаясь подтверждения об их получения. Это значит, что источник предает некоторое количество данных равное window без ожидания подтверждения об их приеме, и после этого останавливает передачу и ждет подтверждения. Если он получит подтверждение только на часть переданных данных, то он начнет передачу новой порции с номера, следующего за подтвержденным. Графически это изображено на рисунке 2.13.
Рис. 2.13. Механизм передачи данных по TCP
В данном примере окно установлено в 250 байтов шириной. Это означает, что текущий сегмент - сегмент со смещением относительно SYN, равном 250 байтам. Однако, после передачи всего окна модуль TCP источника получил подтверждение на получение только первых 100 байтов. Следовательно, передача будет начата со 101 байта, а не с 251.
Таким образом, мы рассмотрели все основные свойства протокола TCP. Осталось только назвать наиболее известные приложения, которые использует TCP для обмена данными. Это в первую очередь TELNET и FTP, а также протокол HTTP, который является сердцем World Wide Web.
Прервем немного разговор о протоколах и обратим свое внимание на такую важнейшую компоненту всей системы TCP/IP как IP-адреса.
Протокол UDP
User Datagram Protocol (UDP) - это простой, ориентированный на дейтаграммы протокол без организации соединения, предоставляющий быстрое, но необязательно надежное транспортное обслуживание. Он поддерживает взаимодействия "один со многими" и поэтому часто применяется для широковещательной и групповой передачи дейтаграмм.
Internet Protocol (IP) является основным протоколом Интернета. Transmission Control Protocol (TCP) и UDP - это протоколы транспортного уровня, построенные поверх лежащего в основе протокола.
TCP/IP - это набор протоколов, называемый также "пакетом протоколов Интернета" (Internet Protocol Suite), состоящий из четырех уровней. Запомните, что TCP/IP не просто один протокол, а семейство или набор протоколов, который состоит из других низкоуровневых протоколов, таких, как IP, TCP и UDP. UDP располагается на транспортном уровне поверх IP (протокола сетевого уровня). Транспортный уровень обеспечивает взаимодействие между сетями через шлюзы. В нем используются IP-адреса для отправки пакетов данных через Интернет или другую сеть с помощью разнообразных драйверов устройств.
Прежде чем приступать к изучению работы UDP, обратимся к основной терминологии, которую нужно хорошо знать. Ниже вкратце определим основные термины, связанные с UDP:
ПакетыВ передаче данных пакетом называется последовательность двоичных цифр, представляющих данные и управляющие сигналы, которые передаются и коммутируются через хост. Внутри пакета эта информация расположена в соответствии со специальным форматом.
ДейтаграммыДейтаграмма - это отдельный, независимый пакет данных, несущий информацию, достаточную для передачи от источника до пункта назначения, поэтому никакого дополнительного обмена между источником, адресатом и транспортной сетью не требуется.
MTU (Maximum Transmission Unit)MTU характеризует канальный уровень и соответствует максимальному числу байтов, которое можно передать в одном пакете. Другими словами MTU - это самый большой пакет, который может переносить данная сетевая среда. Например, Ethernet имеет фиксированный MTU, равный 1500 байтам. В UDP, если размер дейтаграммы больше MTU, протокол IP выполняет фрагментацию, разбивая дейтаграмму на более мелкие части (фрагменты) так, чтобы каждый фрагмент был меньше MTU.
ПортыЧтобы поставить в соответствие входящим данным конкретный процесс, выполняемый в компьютере, UDP использует порты. UDP направляет пакет в соответствующее место, используя номер порта, указанный в UDP-заголовке дейтаграммы. Порты представлены 16-битными номерами и, следовательно, принимает значения в диапазоне от 0 до 65 535. Порты, которые также называют конечными точками логических соединений, разделены на три категории:
Хорошо известные порты - от 0 до 1023
Регистрируемые порты - от 1024 до 49151
Динамические / частные порты - от 49152 до 65535
Заметим, что порты UDP могут получать более одного сообщения в каждый промежуток времени. В некоторых случаях сервисы TCP и UDP могут использовать одни и те же номера портов, например 7 (Echo) или 23 (Telnet).
UDP использует следующие известные порты:
Перечень портов UDP и TCP поддерживается агентством IANA (Internet Assigned Numbers Authority) .
IP-адресаДейтаграмма IP состоит из 32-битных IP-адресов источника и назначения. IP-адрес назначения задает конечную точку для дейтаграммы UDP, а IP-адрес источника используется для получения информации о том, кто отправил сообщение. В пункте назначения пакеты фильтруются, и те из них, адреса источников которых не входят в допустимый набор адресов, отбрасываются без уведомления отправителя.
Однонаправленный IP-адрес уникально определяет хост в сети, тогда как групповой IP-адрес определяет конкретную группу адресов в сети. Широковещательные IP-адреса получаются и обрабатываются всеми хостами локальной сети или конкретной подсети.
TTLЗначение времени жизни, или TTL (time-to-live), позволяет установить верхний предел числа маршрутизаторов, через которые может пройти дейтаграмма. Значение TTL не дает пакетам попасть в бесконечные циклы. Оно инициализируется отправителем и уменьшается на единицу каждым маршрутизатором, обрабатывающим дейтаграмму. Когда значение TTL становится нулевым, дейтаграмма отбрасывается.
Групповая рассылкаГрупповая рассылка - это открытый, базирующийся на стандартах, метод одновременного распространения идентичной информации нескольким пользователям. Групповая рассылка является основным средством протокола UDP, она невозможна для протокола TCP. Групповая рассылка позволяет добиться взаимодействия одного со многими, например, делает возможными такие использования, как рассылка новостей и почты нескольким получателям, интернет-радио или демонстрационные программы реального времени. Групповая рассылка не так сильно нагружает сеть, как широковещательная передача, поскольку данные отправляются сразу нескольким пользователям:
Принцип работы UDP
Когда приложение, базирующееся на UDP, отправляет данные другому хосту в сети, UDP дополняет их восьмибитным заголовком, содержащим номера портов адресата и отправителя, общую длину данных и контрольную сумму. Поверх дейтаграммы UDP свой заголовок добавляет IP, формируя дейтаграмму IP:
На предыдущем рисунке указано, что общая длина заголовка UDP составляет восемь байтов. Теоретически максимальный размер дейтаграммы IP равен 65 535 байтам. С учетом 20 байтов заголовка IP и 8 байтов заголовка UDP длина данных пользователя может достигать 65 507 байтов. Однако большинство программ работают с данными меньшего размера. Так, для большинства приложений по умолчанию установлена длина приблизительно 8192 байта, поскольку именно такой объем данных считывается и записывается сетевой файловой системой (NFS). Можно устанавливать размеры входного и выходного буферов.
Контрольная сумма нужна, чтобы проверить были ли данные доставлены в пункт назначения правильно или были искажены. Она охватывает как заголовок UDP, так и данные. Байт-заполнитель используется, если общее число октетов дейтаграммы нечетно. Если полученная контрольная сумма равна нулю, получатель фиксирует ошибку контрольной суммы и отбрасывает дейтаграмму. Хотя контрольная сумма является необязательным средством, ее всегда рекомендуется включать.
На следующем шаге уровень IP добавляет 20 байтов заголовка, включающего TTL, IP-адреса источника и получателя и другую информацию. Это действие называют IP-инкапсуляцией.
Как упоминалось ранее, максимальный размер пакета равен 65 507 байтам. Если пакет превышает установленный по умолчанию размер MTU, то уровень IP разбивает пакет на сегменты. Эти сегменты называются фрагментами, а процесс разбиения данных на сегменты - фрагментацией . Заголовок IP содержит всю информацию о фрагментах.
Когда приложение-отправитель "выбрасывает" дейтаграмму в сеть, она направляется по IP-адресу назначения, указанному в заголовке IP. При проходе через маршрутизатор значение времени жизни (TTL) в заголовке IP уменьшается на единицу.
Когда дейтаграмма прибывает к заданному назначению и порту, уровень IP по своему заголовку проверяет, фрагментирована ли дейтаграмма. Если это так, дейтаграмма собирается в соответствии с информацией, имеющейся в заголовке. Наконец прикладной уровень извлекает отфильтрованные данные, удаляя заголовок.
Недостатки UDP
По сравнению с TCP UDP имеет следующие недостатки:
Отсутствие сигналов квитирования . Перед отправкой пакета UDP, отправляющая сторона не обменивается с получающей стороной квитирующими сигналами. Следовательно, у отправителя нет способа узнать, достигла ли дейтаграмма конечной системы. В результате UDP не может гарантировать, что данные будут действительно доставлены адресату (например, если не работает конечная система или сеть).
Напротив, протокол TCP ориентирован на установление соединений и обеспечивает взаимодействие между подключенными к сети хостами, используя пакеты. В TCP применяются сигналы квитирования, позволяющие проверить успешность транспортировки данных.
Использование сессий . Ориентированность TCP на соединения поддерживается сеансами между хостами. TCP использует идентификатор сеанса, позволяющий отслеживать соединения между двумя хостами. UDP не имеет поддержки сеансов из-за своей природы, не ориентированной на соединения.
Надежность . UDP не гарантирует, что адресату будет доставлена только одна копия данных. Чтобы отправить конечной системе большой объем данных, UDP разбивает его на небольшие части. UDP не гарантирует, что эти части будут доставлены по назначению в том же порядке, в каком они создавались в источнике. Напротив, TCP вместе с номерами портов использует порядковые номера и регулярно отправляемые подтверждения, гарантирующие упорядоченную доставку данных.
Безопасность . TCP более защищен, чем UDP. Во многих организациях брандмауэры и маршрутизаторы не пропускают пакеты UDP. Это связано с тем, что хакеры могут воспользоваться портами UDP, не устанавливая явных соединений.
Управление потоком . В UDP управление потоком отсутствует, в результате плохо спроектированное UDP-приложение может захватить значительную часть пропускной способности сети.
Преимущества UDP
По сравнению с TCP UDP имеет следующие преимущества:
Нет установки соединения . UDP является протоколом без организации соединений, поэтому он освобождает от накладных расходов, связанных с установкой соединений. Поскольку UDP не пользуется сигналами квитирования, то задержек, вызванных установкой соединений, также удается избежать. Именно поэтому DNS отдает предпочтение UDP перед TCP - DNS работала бы гораздо медленнее, если бы она выполнялась через TCP.
Скорость . UDP работает быстрее TCP. По этой причине многие приложения предпочитают не TCP, a UDP. Те же средства, которые делают TCP более устойчивым (например сигналы квитирования), замедляют его работу.
Топологическое разнообразие . UDP поддерживает взаимодействия "один с одним" и "один с многими", в то время как TCP поддерживает лишь взаимодействие "один с одним".
Накладные расходы . Работа с TCP означает повышенные накладные расходы, издержки, налагаемые UDP, существенно ниже. TCP по сравнению с UDP использует значительно больше ресурсов операционной системы, и, как следствие, в таких средах, где серверы одновременно обслуживают многих клиентов, широко используют UDP.
Размер заголовка . Для каждого пакета заголовок UDP имеет длину всего лишь восемь байтов, в то время как TCP имеет 20-байтовые заголовки, и поэтому UDP потребляет меньше пропускной способности сети.
