подтверждение получения данных в tcp осуществляется за счет

Transmission Control Protocol (TCP)

Функции TCP

Использование портов

TCP и UDP используют порты, которые в свою очередь, делятся на зарезервированные порты и динамические:

Таблица 5.1 Список зарезервированных портов

Что бы лучше понять, что такое порты и как их «едят», разберем пример соединений с использованием портов.

Рисунок 5.1 Передача данных с использованием портов

Компьютер Андрея запросил с веб-сервера три веб-страницы (открыл три «вкладки» в браузере). На рисунке 5.1, Веб-сервер отправляет пакеты с одинаковыми заголовками (в заголовках одинаковые IP адреса), но заголовки сегментов различаются ( обратите внимание на порт отправителя (S_PORT) и порт получателя (D_PORT)). Изначально компьютер Андрея привязал к каждому соединению определенный порт, который был определен случайным образом из динамически распределяемого диапазона (от 1023 до 65535), а обратился он на зарезервированный порт 80 (HTTP). Так происходит со всеми передаваемыми данными, к каждому приложению присваивается определенный порт/порты, таким образом данные получает то приложение, которому они предназначены. Еще можно схематично представить наш пример.

Рисунок 5.2 Схематичное представление соединений

Сегментация

Прежде чем данные будут переданы по сети они должны быть разбиты на сегменты, обычно не превышающие 1460 байт.

Например, вы хотите передать видео файл размером 200Кбайт. Видео не будет передаваться одним целым файлом, оно будет разбито на сегменты, после чего по сети будут передаваться около 137 сегментов (200 000/1460

Установление соединений

Устанавливаются соединения в 3 сообщения, рисунок 5.3.

После этих трех сообщений соединение считается установленным, и клиент отправляет запрос на получение данных с сервера.

Завершаются соединения в четыре сегмента, здесь этот процесс рассмотрен не будет.

Восстановление после ошибок

На рисунке 5.4 изображена передача сегментов, и 3-й сегмент не приходит получателю. Введем некоторое пояснение, SEQ, помимо номера сегмента, обозначает количество переданных байт, например, первый сегмент 1400 байт, второй сегмент имеет такой же размер, но номер его 2800, он означает, что при получении этого сегмента будет передано уже 2800 байт. Вернемся к нашему примеру, веб-сервер передает не сразу все сегменты, а по частям, ожидая подтверждения каждой части. Так например, если бы передача прошла успешно, веб сервер бы получил ACK=7000. В нашем примере 3-й сегмент потерялся, поэтому клиент отправляет подтверждение ACK=4200 (как бы спрашивая у сервера, «Где сегмент №4200?»), а сервер это будут трактовать как сегмент с номером 4200 был потерян, и веб-сервер отправляет его еще раз. Вот так и осуществляется востановление данных после ошибок.

Источник

Подтверждение Получения Сегментов

Одна из функций TCP заключается в проверке того, что каждый сегмент достигает своего места назначения. Службы TCP на хосте назначения подтверждают данные, которые они получили, исходному приложению.

Порядковый номер последовательности в заголовке сегмента и номер подтверждения используются вместе, чтобы подтвердить получение байтов данных, содержащихся в сегментах. Порядковый номер последовательности является относительным числом байтов, которые были переданы в этом сеансе плюс 1 (что равно номеру первого байта данных в текущем сегменте). TCP использует номер подтверждения в сегментах, отосланных назад к источнику, чтобы указать на следующий байт в этом сеансе, который получатель ожидает получить. Это называют подтверждением с ожидаемым значением.

Источник информируется, что узел назначения получил все байты в этом потоке данных вплоть до, но не включая, байта, обозначенного числом подтверждения. Предполагается, что передающий узел отправит сегмент, который использует порядковый номер, который равен номеру подтверждения.

Помните, что каждое соединение является фактически двумя односторонними сеансами. Порядковыми номерами и числами подтверждения обмениваются в обоих направлениях.

В примере на рисунке узел слева отправляет данные узлу справа. Он отправляет сегмент, содержащий 10 байтов данных для этого сеанса и порядковый номер в заголовке, равный 1.

Получающий хост справа получает сегмент на Уровне 4 и определяет, что порядковый номер 1 и что у имеется 10 байтов данных. Узел тогда отсылает сегмент назад к хосту слева, чтобы подтвердить получение этих данных. В этом сегменте узел устанавливает номер подтверждения 11, чтобы указать, что следующий байт данных, который он ожидает получить в этом сеансе, является байтом номер 11. Отметьте, значение Ack. на узле источника остается 1, чтобы указать, что сегмент является частью продолжающегося диалога, и что поле Номера Подтверждения задействовано.

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

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

Например, начиная с порядкового номера последовательности 2000, если бы 10 сегментов (по 1000 байтов каждый) были приняты, число подтверждения 12000 было бы возвращено к источнику.

Объем данных, который источник может передать до того как подтверждение должно быть получено, называется размером окна. Размер окна является полем в заголовке TCP, которое позволяет управлять потерянными данными и контролировать поток.

Источник

Протокол TCP простым и понятным языком — как работает

На этом уровне есть два протокола, протокол UDP, который уже рассматривали и протокол TCP, который является одним из основных протоколов стека TCP/IP и интернет.

TCP — расшифровывается как (Transmission Control Protocol) протокол управления передач. В отличии от UDP, TCP обеспечивает надежную доставку данных. Сервис предоставляемый TCP называются надежная передача потока байт или (reliable byte stream) по-английский. TCP обеспечивает как гарантию доставки данных, так и гарантию сохранения порядка следования сообщений.

Поток байт

От приложения, протокол TCP получает поток байт, который может быть очень большим. Например, вы можете скачивать из интернета файл, который составляет несколько мегабайт или несколько гигабайт. Данные файлы приходят на транспортный уровень в виде одного большого потока байт.

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

Гарантия доставки: подтверждение получения

Для того чтобы обеспечить гарантию доставки данных, TCP использует подтверждение получения сообщения. Рассмотрим, как это работает. Отправитель пересылает по сети некоторый сегмент данных, получатель принимает сегмент и посылает отправителю подтверждение, сокращенно ACK от английского Acknowledgment, которая говорит о том что сегмент данных получен. Затем отправляется следующий сегмент данных, снова подтверждение и так далее.

Гарантия доставки: повторная отправка

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

Предположим, что в этот раз сегмент дошел, получатель отправляет подтверждение, отправитель может передавать следующий сегмент данных.

Протокол TCP: скользящее окно

Работа протокола TCP отличаются от той схемы, которую мы сейчас рассмотрели. Подтверждается не каждый сегмент, а несколько сегментов следующие друг за другом, этот механизм называется скользящее окно.

Варианты подтверждения доставки

Рассмотрим остановку и ожидание. Отправитель передает данные и останавливается ожидая подтверждение. Получатель присылает подтверждение после этого передается следующая порция данных. Снова подтверждение, снова данные и снова подтверждение.

Другой вариант скользящее окно. В этом случае отправитель передает сразу несколько порций данных не дожидаясь подтверждения. Получатель отправляет одно подтверждение которое называется кумулятивное. Это означает, что получатель получил последнюю порцию данных и все предыдущие.

Время передачи сообщения

Почему на транспортном уровне эффективно использовать скользящее окно? Дело в том, что сообщение по сети передается хотя и быстро, но не мгновенно. Поэтому в среде передачи данных может находиться некоторый объем данных, который определяется скоростью передачи данных умноженной на задержку передачи данных. Этот объем небольшой для локальных сетей, где отправитель и получатель находится рядом друг с другом, поэтому задержка небольшая.

В локальных сетях, например Wi-Fi используется метод подтверждения остановка и ожидания. В крупных современных сетях с высокоскоростными каналами связи большой протяженности, например если вы хотите скачать чего-нибудь с американского сайта, такой объем данных может быть очень большой. И в этой ситуации ожидания подтверждения приводит к существенному снижению производительности.

Пример подтверждения доставки

Рассмотрим на примере работу сети.

Скользящее окно

Почему термин называется скользящее окно? Удобно представлять себе окно, которое скользит по потоку байт получаемых от приложений. У есть поток байт, разделенный на отдельные сегменты, часть сегментов уже передана, часть еще не отправлены. Для некоторых сегментов, которые уже переданы, получено подтверждение. И отправлено некоторое количество сегментов соответствующие размеру окна, для которых подтверждение не получено.

Размер окна — это количество байтов данных, которые могут быть переданы без получения подтверждения.

В примере размер окна 8 сегментов. Что происходит, если мы получили очередное подтверждение? Мы можем передвинуть окно дальше по данным, в него попадает новая порция не отправленных данных. Можно отправить эти данные получателю, после этого отправитель останавливается и дожидаются подтверждения получения следующей порции данных. Таким образом, окно скользит вдоль нашего потока байт от приложения.

Тип подтверждения

Есть два типа подтверждения, которые могут использоваться совместно с алгоритмом скользящего окна.

Для устранения этой проблемы предложено выборочное подтверждение. В этом случае получатель подтверждает получение диапазона принятых байт. Он получил первые 500 мегабайт и вторые 500 мегабайт из гигабайта и не получил всего лишь один сегмент. Отправитель вместо вторых 500 мегабайт, повторно передает всего лишь один недостающий сегмент. Выборочное подтверждение эффективно при большом размере окна TCP, но выборочное подтверждение по умолчанию не используется для этого необходимо применение дополнительных полей заголовка TCP, которые называются параметрами.

Порядок следования сообщений

Но подтверждений и повторной отправки данных недостаточно для обеспечения надежной передачи потока байт. Это защищает только от потери сегментов, но не обеспечивает сохранение порядка следования сообщений.

Какие проблемы могут произойти? Протокол IP не сохраняет порядок следования сообщений и поэтому сегменты могут прийти к получателю не в том порядке в котором они были отправлены. Кроме того, некоторые сегменты могут прийти два и более раз. Рассмотрим одну из возможных причин дублирования сегментов.

Дублирование сегментов

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

Это один из возможных вариантов, на самом деле, таких вариантов еще очень много, поэтому в протокол TCP встроен механизм защиты от дублирования и нарушение порядка следования сообщений.

Механизм очень простой, все сообщения нумеруются. В TCP нумеруются не сегменты, так как разные сегменты могут иметь разный размер, а байты.

В нашем примере 4 сегмента первый сегмент содержит байты от 0 до 1023, второй от 1024 до 2047 и так далее.

Нумерация байтов

При передаче отправитель включают в сегмент номер первого байта данных, которые в нем содержатся.

Дублирование сегментов

Рассмотрим как решается ситуация с дублированием сегментов.

Соединение TCP

TCP для передачи данных использует соединение. Соединение нужно установить перед тем, как начать передачу данных, а после того как передача данных завершена, соединение разрывается.

Задачи соединения

Установка соединения в TCP

Получатель в ответ передаёт сообщение SYN, куда включает подтверждение получения предыдущего сообщения ACK от слова acknowledge и порядковый номер байта, который он ожидает 7538, потому что на предыдущем этапе был получен байт с номером 7537.

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

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

Разрыв соединения в TCP

Протокол TCP предусматривает два варианта разрыва соединения: корректное, с помощью одностороннего разрыва соединения и сообщения FIN и разрыв из-за критической ситуации с помощью сообщения RST.

Рассмотрим, как выполняется корректный разрыв соединения. Сторона, которая хочет разорвать соединение пересылает другой стороне сообщение FIN и в ответ получает сообщение ACK. Однако соединение разорвано только с одной стороны.

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

Для разрыва соединения в критической ситуации из-за ошибок в приложении или с оборудованием используется одно сообщение RST. В этом случае соединение закрывается в обе стороны. Хотя сообщение RST предназначено для использования в критических ситуациях, некоторые протоколы используют его для быстрого закрытия соединения.

Заключение

Итак мы рассмотрели протокол TCP — протокол управления передачей данных. TCP обеспечивают надежную передачу потока байт от одного приложения к другому. При этом TCP обеспечивает, как гарантию доставки данных, так и гарантию сохранении порядка следования сообщений.

TCP использует соединение между отправителем и получателем, которое необходимо установить до того, как начнется передача данных, а после завершения передачи соединение необходимо разорвать.

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

Прежде чем передавать данные в TCP, необходимо сначала установить соединение, а после завершения передачи соединение необходимо разорвать. Для установки соединения в TCP используется схема трехкратного рукопожатия. Сначала передается сообщение SYN потом SYN + ACK и на третьем шаге ACK.

Для разрыва соединения возможны две схемы. Корректное закрытие соединения требует корректной отправки обеими сторонами сообщения FIN и получении подтверждения. Разрыв соединения в критической ситуации может быть выполнен быстро, отправкой одного сообщения RST. Таким образом накладные расходы в TCP особенно при передаче небольшого объема данных значительно выше чем в UDP, но соединение и отправка подтверждений позволяют TCP обеспечивать гарантию доставки и гарантию сохранения порядка следования сообщений.

Источник

Подтверждение получения данных в tcp осуществляется за счет

Глава 17 TCP: Transmission Control Protocol

В этой главе описаны сервисы, которые TCP предоставляет приложениям. Здесь же рассмотриваются поля TCP заголовка. В следующих главах мы подробно рассмотрим эти поля и расскажем, как TCP функционирует.

Описанию TCP посвящена эта глава, и следующие семь глав. В главе 18 будет рассказано, как устанавливаются и разрываются TCP соединения, в главе 19 и главе 20 мы рассмотрим обычную передачу данных, как в диалоговом использовании (удаленный заход), так и передачу файлов. В главе 21 мы подробно рассмотрим, как TCP осуществляет тайм-ауты и повторные передачи. И в главе 22 и главе 23 мы рассмотрим некоторые таймеры TCP. И в заключение, в главе 24 мы рассмотрим новые характеристики и производительность TCP.

Основная спецификация TCP находится в RFC 793 [ Postel 1981c], однако некоторые ошибки этого RFC исправлены в требованиях к хостам Host Requirements RFC.

Несмотря на то, что TCP и UDP используют один и тот же сетевой уровень (IP), TCP предоставляет приложениям абсолютно другие сервисы, нежели UDP. TCP предоставляет основанный на соединении надежный сервис потока байтов.

Всегда существуют две конечные точки, которые общаются друг с другом с помощью TCP соединения. Концепции, о которых мы говорили в главе 12, широковещательная рассылка и групповая рассылка, не имеют отношения к TCP.

Между двумя приложениями по TCP соединению осуществляется обмен потоком 8-битовых байтов. Автоматически TCP не вставляет записи маркеров. Это называется сервисом потока байтов (byte stream service). Если приложение на одном конце записало сначала 10 байт, затем 20 байт и затем еще 50 байт, приложение на другом конце соединения не может сказать какого размера была каждая запись. На другом конце эти 80 байт могут быть считаны, например, за 4 раза по 20 байт за каждый раз. Один конец соединения помещает поток байт в TCP, и точно так же идентичный поток байт появляется на другом конце.

TCP не интерпретирует содержимое байтов. TCP понятия не имеет о том, происходит ли обмен двоичными данными, ASCII символами, EBCDIC символами или чем-либо еще. Эта интерпретация потока байтов осуществляется приложениями на каждой стороне соединения.

Вспомним, что данные TCP инкапсулируются в IP датаграммы, как показано на рисунке 17.1.

Рисунок 17.1 Инкапсуляция TCP данных в IP датаграмму.

На рисунке 17.2 показан формат TCP заголовка. Обычно его размер составляет 20 байт, если не присутствуют опции.

Рисунок 17.2 TCP заголовок.

Каждый TCP сегмент содержит номер порта (port number) источника и назначения, с помощью которых идентифицируются отправляющее и принимающее приложения. Эти два значения вместе с IP адресом источника и назначения в IP заголовке уникально идентифицируют каждое соединение.

Так как каждый байт, который участвует в обмене, пронумерован, номер подтверждения (acknowledgment number) это следующий номер последовательности, который ожидает получить отправитель подтверждения. Это номер последовательности плюс 1 последнего успешно принятого байта данных. Это поле принимается в рассмотрение, только если флаг ACK (описан ниже) взведен.

Отправка ACK не стоит ничего (это означает, что на подтверждение не тратится сегмент), потому что 32-битное поле номера подтверждения всегда является частью заголовка, так же как и флаг ACK. Мы увидим, что когда соединение установлено, это поле всегда установлено и флаг ACK всегда взведен.

TCP предоставляет для прикладного уровня полнодуплексный сервис. Это означает, что данные могут передаваться в каждом направлении независимо от другого направления. Однако, на каждом конце соединения необходимо отслеживать номер последовательности данных, передаваемых в каждом направлении.

Длина заголовка (header length) содержит длину заголовка в 32-битных словах. Это объясняется тем, что длина поля опций переменная. С 4-битным полем у TCP есть ограничение на длину заголовка в 60 байт. Без опций, однако, стандартный размер составляет 20 байт.

В TCP заголовке существуют 6 флаговых битов. Один или несколько из них могут быть установлены в единицу в одно и то же время. Здесь мы кратко опишем их использование, а позже опишем каждый флаг более подробно в соответствующих главах.

Указатель срочности (urgent pointer) будет рассмотрен в разделе «Режим срочности (Urgent Mode)» главы 20.

Номер подтверждения необходимо принять в рассмотрение (acknowledgment).

Получатель должен передать эти данные приложению как можно скорее (глава 20, раздел «Флаг PUSH»).

Синхронизирующий номер последовательности для установления соединения. Этот следующий флаги описаны в главе 18.

Отправитель заканчивает посылку данных.

Контрольная сумма (checksum) охватывает собой весь TCP сегмент: TCP заголовок и TCP данные. Это обязательное поле, которое должно быть рассчитано и сохранено отправителем, а затем проверено получателем. Контрольная сумма TCP рассчитывается так же как контрольная сумма UDP, с использованием псевдозаголовка, как описано в разделе «Контрольная сумма UDP» главы 11.

Указатель срочности (urgent pointer) действителен только в том случае, если установлен флаг URG. Этот указатель является положительным смещением, которое должно быть прибавлено к полю номера последовательности сегмента, чтобы получить номер последовательности последнего байта срочных данных. Режим срочности TCP это способ, с помощью которого отправитель передает срочные данные на удаленный конец. Мы рассмотрим эту характеристику в разделе «Режим срочности (Urgent Mode)» главы 20.

На рисунке 17.2 мы видели, что раздел данных в TCP сегменте необязателен. В главе 18 мы увидим, что когда устанавливается соединение или когда соединение разрывается, сегменты содержат только TCP заголовки с возможными опциями. Заголовок без данных также используется, чтобы подтвердить принятые данные, если в этом направлении не надо передавать данные. Также существует несколько случаев тайм-аутов, когда сегмент может быть отправлен без данных.

TCP предоставляет надежный, ориентированный на соединения, и ориентированный на поток байтов сервис транспортного уровня. Мы коротко рассмотрели все поля TCP заголовка, подробное описание полей приведено в следующих главах.

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

TCP используется множеством популярных приложений, таких Telnet, Rlogin, FTP и электронная почта (SMTP).

Источник