Работа tcp при обнаружении ошибок

Рис.
10.10.
Искаженный сегмент

Рис.
10.11.
Потерянный сегмент

Рис.
10.12.
Потерянное подтверждение

Например, в протоколе TCP, обнаружение ошибок обеспечивается с помощью специального поля в заголовке, которое называется checksum (контрольная сумма). Контрольная сумма вычисляется передающей программой TCP по всему сегменту TCP и помещается в поле checksum. Принимающая программа TCP снова рассчитывает контрольную сумму, если значение вновь вычисленной контрольной суммы будет совпадать со значением контрольной суммы, рассчитанной на передаче, то принимающая программа TCP считает, что сегмент принят правильно (без искажений). Если же значения контрольных сумм не совпадают, то значит сегмент искажён; таким образом обнаружена ошибка. Об обнаружении ошибки принимающая программа TCP сообщает передающей программе TCP, не передавая квитанции подтверждения. А рас квитанция не получена принимающей

программой TCP, значит произошла ошибка.

Если квитанция не пришла к отправителю, то это означает, что либо сегмент искажён, либо сегмент потерян (если сегмент потерян, то и квитанция на него не придёт), либо потеряна квитанция.

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

3.2.7 Исправление ошибок.

Например, в протоколе TCP исправление ошибок обеспечивается за счёт повторной передачи тех сегментов,

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

3.2.8 Перенос срочных данных.

Эта функция имеет реализацию в протоколе TCP. В формате поля заголовка TCP есть поле под названием URG, если это поле установлено в 1, то сегмент с таким значением поля URG будет обрабатываться вне очереди. Например, если приёмный буфер получателя будет полностью заполнен и при этом придёт срочный сегмент, то он будет принят, за счёт вытеснения (удаления) других не срочных сегментов.

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

3.3 Фаза разъединения соединения.

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

Разъединение соединения может включать следующие функции:

3.3.1Уведомление о причине разъединения.

3.3.2Идентификация разъединившегося транспортного

соединения.

3.3.3Перенос данных.

4.Приостановка и продолжение транспортного соединения.

С помощью функции приостановки соединения происходит

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

При выполнении функции приостановки транспортные объекты не могут обмениваться данными.

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

С помощью функции продолжить, транспортный уровень вновь устанавливает сетевое соединение и обмен данными может быть продолжен.

Функции транспортного уровня в режиме без установления соединения:

1.Отображение транспортного адреса на сетевой адрес.

2.Отображение передачи данных в режиме без установления соединения транспортного уровня на передачу в режиме без установления соединения сетевого уровня.

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

3. Обнаружение ошибок и контроль качества обслуживания.

Примером транспортного протокола, работающего в режиме без установления соединения и выполняющего эту функцию, может служить протокол дейтаграмм пользователя UDP (User Datagram Protocol).

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

Несмотря на то, что протокол UDP не обеспечивает высокую

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

5.1 КЛАССЫ И ТИПЫ ТРАНСПОРТНОГО ОБСЛУЖИВАНИЯ

Определены два типа транспортного обслуживания:

1.Обслуживание в режиме с установлением соединения.

2.Обслуживание в режиме без установления соединения.

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

В модели OSI нет никаких определённых классов

транспортного обслуживания.

5.2КАЧЕСТВО ТРАНСПОРТНОГО ОБСЛУЖИВАНИЯ В РЕЖИМЕ

СУСТАНОВЛЕНИЕМ СОЕДИНЕНИЯ

Термин качество обслуживания относится к некоторым характеристикам транспортного соединения.

С помощью параметров качества обслуживания пользователь транспортных услуг TS (Transport Service) задаёт свои требования к тем услугам, которыми он будет пользоваться, то есть исходя из этих требований транспортный уровень будет знать какое качество обслуживания нужно обеспечить для того или иного пользователя TS.

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

качества обслуживания это может означать, что:

1.Задержка увеличивается;

2.Пропускная способность уменьшается;

3.Коэффициент ошибок повышается;

4.Приоритет становиться ниже;

5.Вероятность отказа становится выше;

6.Уровень защиты транспортного соединения понижается.

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

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

Механизм TCP предоставляет

поток данных

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

UDP

, целостность передаваемых данных и уведомление отправителя о результатах передачи.

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

браузером

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

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

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

В момент времени t1 отправитель передает 10 пакетов или октетов данных (в случае TCP это 10 октетов данных).

В момент времени t2 получатель подтверждает эти 10 октетов, и для окна установлено значение 30. Это означает, что отправителю теперь разрешено отправлять еще до 30 октетов данных перед ожиданием следующего подтверждения; другими словами, отправитель может отправить до 40 октетов, прежде чем он должен будет дождаться подтверждения для отправки дополнительных данных.

В момент времени t3 отправитель отправляет еще 5 октетов данных, номера 11–15.

В момент времени t4 приемник подтверждает получение октетов через 15, и окно устанавливается на 40 октетов.

В момент времени t5 отправитель отправляет около 20 октетов данных, пронумерованных 16–35.

В момент времени t6 получатель подтверждает 35, и окно устанавливается на 50.

Следует отметить несколько важных моментов, касающихся этой техники:

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

Если приемник не отправляет подтверждение—к примеру , передатчик отправляет 16-35 в момент времени t5, а приемник не отправляет подтверждение—отправитель будет ждать некоторое время и считать, что данные никогда не поступали, поэтому он будет повторно отправлять данные.

Если получатель подтверждает некоторые данные, переданные отправителем, но не все, отправитель предполагает, что некоторые данные отсутствуют, и ретранслирует с точки, которую подтвердил получатель. Например, если отправитель передал 16-35 в момент времени t6, а получатель подтвердил 30, отправитель должен повторно передать 30 и переслать.

Окно устанавливается как для отправителя, так и для получателя

Вместо использования номеров октетов TCP присваивает каждой передаче порядковый номер; когда приемник подтверждает определенный порядковый номер, передатчик предполагает, что приемник фактически получил все октеты информации вплоть порядкового номера передачи. Для TCP, таким образом, порядковый номер действует как своего рода “стенография” для набора октетов. Рисунок 2 демонстрирует это.

В момент времени t1 отправитель объединяет октеты 1–10 и передает их, помечая их как порядковый номер 1.

В момент времени t2 получатель подтверждает порядковый номер 1, неявно подтверждая получение октетов 1–10.

В момент времени t3 отправитель связывает октеты 11–15 вместе и передает их, помечая их как порядковый номер 2.

В момент времени t4 получатель подтверждает порядковый номер 2, неявно подтверждая октеты, отправленные через 15.

В момент времени t5 предположим, что 10 октетов поместятся в один пакет; в этом случае отправитель отправит два пакета, один из которых содержит 16–25 с порядковым номером 3, а другой — октеты 26–35 с порядковым номером 4.

В момент времени t6 приемник подтверждает порядковый номер 4, неявно подтверждая все ранее переданные данные.

Что произойдет, если один пакет информации будет пропущен?

Что делать, если первый пакет из потока в 100 пакетов не получен? Используя систему, описанную на рисунке 2, получатель просто не подтвердит этот первый пакет информации, вынуждая отправителя повторно передать данные через некоторое время. Однако это неэффективно; каждый потерянный пакет информации требует полной повторной отправки из этого пакета. Реализации TCP используют два разных способа, чтобы получатель мог запросить один пакет.

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

Второй способ заключается в реализации выборочных подтверждений (SACK).15 SACK добавляет новое поле к подтверждению TCP, которое позволяет получателю подтвердить получение определенного набора серийных номеров, а не предполагать, что подтверждение одного серийного номера также подтверждает каждый более низкий серийный номер.

Как долго передатчик ждет перед повторной передачи?

Первый способ, которым отправитель может обнаружить потерянный пакет — это время ожидания повторной передачи (RTO), которое рассчитывается как функция времени приема-передачи (RTT или rtt). Rtt — это временной интервал между передачей пакета отправителем и получением подтверждения от получателя. RTT измеряет задержку в сети от передатчика до приемника, время обработки в приемнике и задержку в сети от приемника до передатчика. Обратите внимание, что rtt может варьироваться в зависимости от пути, по которому каждый пакет проходит через сеть, локальных условий в момент коммутации пакета и т. д.

RTO обычно рассчитывается как средневзвешенное значение, при котором более старые временные интервалы оказывают меньшее влияние, чем более поздние измеренные значения.

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

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

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

Как выбирается размер окна?

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

Окно приема (RWND): объем данных, которые приемник готов принять; это окно обычно устанавливается на основе размера буфера приемника или какого-либо другого ресурса, доступного в приемнике. Это размер окна, объявленный в заголовке TCP.

Окно перегрузки (CWND): объем данных, которые передатчик готов отправить до получения подтверждения. Это окно не объявляется в заголовке TCP; получатель не знает размер CWND.

Порог медленного запуска (SST): CWND, при котором отправитель считает соединение с максимальной скоростью передачи пакетов без возникновения перегрузки в сети. SST изначально устанавливается реализацией и изменяется в случае потери пакета в зависимости от используемого механизма предотвращения перегрузки.

Большинство реализаций TCP начинают сеансы с алгоритма медленного старта. 16 На этом этапе CWND начинается с 1, 2 или 10. Для каждого сегмента, для которого получено подтверждение, размер CWND увеличивается на 1. Учитывая, что такие подтверждения должны занимать ненамного больше времени, чем один rtt, медленный запуск должен привести к удвоению окна каждого rtt. Окно будет продолжать увеличиваться с этой скоростью до тех пор, пока либо пакет не будет потерян (приемник не сможет подтвердить пакет), CWND не достигнет RWND, либо CWND не достигнет SST. Как только любое из этих трех условий происходит, отправитель переходит в режим предотвращения перегрузки.

Примечание. Каким образом увеличение CWND на 1 для каждого полученного ACL удваивает окно для каждого rtt? Идея состоит в следующем: когда размер окна равен 1, вы должны получать один сегмент на каждый RTT. Когда вы увеличиваете размер окна до 2, вы должны получать 2 сегмента в каждом rtt; на 4, вы должны получить 4 и т. д. Поскольку получатель подтверждает каждый сегмент отдельно и увеличивает окно на 1 каждый раз, когда он подтверждает сегмент, он должен подтвердить 1 сегмент в первом rtt и установить окно на 2; 2 сегмента во втором rtt, добавляя 2 к окну, чтобы установить окно на 4; 4 сегмента в третьем RTT, добавив 4 к окну, чтобы установить размер окна равным 8 и т. д.

В режиме предотвращения перегрузки CWND увеличивается один раз за каждый rtt, что означает, что размер окна перестает расти экспоненциально, а вместо этого увеличивается линейно. CWND будет продолжать расти либо до тех пор, пока получатель не подтвердит получение пакета (TCP предполагает, что это означает, что пакет был потерян или отброшен), либо пока CWND не достигнет RWND. Существует два широко распространенных способа, которыми реализация TCP может реагировать на потерю пакета, называемых Tahoe и Reno.

Примечание. На самом деле существует множество различных вариаций Tahoe и Reno; здесь рассматриваются только самые базовые реализации. Также существует множество различных методов реагирования на потерю пакета, когда соединение находится в режиме предотвращения перегрузки.

Если реализация использует Tahoe, и потеря пакета обнаружена посредством быстрой повторной передачи, она установит SST на половину текущего CWND, установит CWND на исходное значение и снова начнет медленный запуск. Это означает, что отправитель снова будет передавать 1, 2 или 10 порядковых номеров, увеличивая CWND для каждого подтвержденного порядкового номера. Как и в начале процесса медленного запуска, это приводит к удвоению CWND каждого rtt. Как только CWND достигнет SST, TCP вернется в режим предотвращения перегрузки.

Если реализация использует Reno, и потеря пакета обнаружена посредством быстрой повторной передачи, она установит SST и CWND на половину текущего CWND и продолжит работу в режиме предотвращения перегрузки.

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

TCP предоставляет две формы обнаружения ошибок и управления ими:

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

Контрольная сумма дополнения единицы, включенная в заголовок TCP, считается более слабой, чем Cyclic Redundancy Check (CRC) и многие другие формы обнаружения ошибок. Эта проверка ошибок служит дополнением, а не заменой, коррекции ошибок, обеспечиваемой протоколами ниже и выше в стеке.

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

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

Номера TCP-портов делятся на два широких класса: хорошо известные и эфемерные. Хорошо известные порты определяются как часть спецификации протокола верхнего уровня; эти порты являются портами «по умолчанию» для этих приложений. Например, службу, поддерживающую Simple Mail Transfer Protocol (SMTP), обычно можно найти, подключившись к узлу с использованием TCP на порт номер 25. Службу, поддерживающую Hypertext Transport Protocol (HTTP), обычно можно найти, подключившись к узлу с использованием TCP на порт 80. Эти службы не обязательно должны использовать эти номера портов; большинство серверов можно настроить на использование какого-либо номера порта, отличного от указанного в спецификации протокола. Например, веб-серверы, не предназначенные для общего (или общедоступного) использования, могут использовать какой-либо другой TCP-порт, например 8080.

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

TCP использует трехстороннее рукопожатие для установки сеанса:

1.

Клиент отправляет синхронизацию (SYN) на сервер. Этот пакет является обычным TCP-пакетом, но с битом SYN, установленным в заголовке TCP, и указывает, что отправитель запрашивает сеанс для настройки с получателем. Этот пакет обычно отправляется на хорошо известный номер порта или на какой-то заранее установленный номер порта, который, как известно клиенту, будет прослушиваться сервером по определенному IP-адресу. Этот пакет включает в себя начальный порядковый номер клиента.

2.

Сервер отправляет подтверждение для SYN, SYN-ACK. Этот пакет подтверждает порядковый номер, предоставленный клиентом, плюс один, и включает начальный порядковый номер сервера в качестве порядкового номера для этого пакета.

3.

Клиент отправляет подтверждение (ACK), включающее начальный порядковый номер сервера плюс один.

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

Установление TCP-соединения происходит до того, как любая из других функций TCP сможет начать свою работу. Установление соединения относится к процессу инициализации полей «Sequence» и «Acknowledgment» и согласования используемых номеров портов. На рисунке 5 показан пример процесса установления соединения.

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

TCP сообщает об установлении соединения, используя 2 бита в полях флагов заголовка TCP. Эти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает «синхронизировать порядковые номера», что является одним из необходимых компонентов при инициализации TCP.

На рисунке 6 показано завершение TCP-соединения. Эта четырехсторонняя последовательность завершения проста и использует дополнительный флаг, называемый битом FIN. (FIN — это сокращение от «finished«, как вы могли догадаться.) Одно интересное замечание: перед тем, как устройство справа отправит третий сегмент TCP в последовательности, оно уведомляет приложение о том, что соединение прерывается. Затем он ожидает подтверждения от приложения перед отправкой третьего сегмента на рисунке. На случай, если приложению потребуется некоторое время, чтобы ответить, ПК справа отправляет второй поток на рисунке, подтверждая, что другой ПК хочет разорвать соединение. В противном случае ПК слева может повторно отправить первый сегмент.

TCP устанавливает и завершает соединения между конечными точками, а UDP — нет. Многие протоколы работают в рамках одних и тех же концепций, поэтому термины «ориентированный на соединение» и «без установления соединения» используются для обозначения общей идеи каждого из них. Более формально эти термины можно определить следующим образом:

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

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

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

TCP обеспечивает надежную передачу данных, что также называется reliability or error recovery. Для обеспечения надежности TCP нумерует байты данных, используя поля «Sequence» и «Acknowledgment» в заголовке TCP. TCP обеспечивает надежность в обоих направлениях, используя поле Sequence Number одного направления в сочетании с полем Acknowledgment в противоположном направлении.

На рисунке 7 показан пример того, как поля TCP Sequence и Acknowledgment позволяют ПК отправлять 3000 байтов данных на сервер, при этом сервер подтверждает получение данных. Сегменты TCP на рисунке расположены по порядку, сверху вниз. Для простоты все сообщения содержат 1000 байтов данных в части данных сегмента TCP. Первый порядковый номер — красивое круглое число (1000), опять же для простоты. В верхней части рисунка показаны три сегмента, каждый из которых на 1000 больше предыдущего, что указывает на первый из 1000 байтов сообщения. (То есть в этом примере первый сегмент содержит байты 10001999; второй — байты 20002999, а третий — байты 30003999.)

Четвертый сегмент TCP на рисунке — единственный, который возвращается от сервера к веб-браузеру — подтверждает получение всех трех сегментов. Как? Значение подтверждения 4000 означает: «Я получил все данные с порядковыми номерами на единицу меньше 4000, поэтому я готов принять ваш байт 4000 следующим«. (Обратите внимание, что это соглашение о подтверждении путем перечисления следующего ожидаемого байта, а не номера последнего полученного байта, называется прямым подтверждением.)

Однако этот пример не исправляет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле порядкового номера для идентификации данных, а хост-получатель использует прямые подтверждения для подтверждения данных. Более интересное обсуждение вращается вокруг того, как использовать эти же инструменты для восстановления ошибок. TCP использует поля «Sequence» и «Acknowledgment«, чтобы принимающий хост мог заметить потерю данных, попросить отправляющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли.

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

​

​

​

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

Получение подтверждения, которое не подтверждает все данные, отправленные на данный момент, заставляет хост-отправитель повторно отправить данные. ПК слева может подождать несколько секунд, чтобы убедиться, что другие подтверждения не поступят (используя таймер, называемый таймером повторной передачи), но вскоре решит, что сервер сообщает: «Мне действительно нужно 2000 — отправьте его повторно». ПК слева делает это, как показано на пятом из шести сегментов TCP на рисунке.

Наконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. В этом случае сервер получил повторно отправленный второй сегмент TCP (данные с порядковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). Следующее поле подтверждения сервера подтверждает данные в обоих этих сегментах с полем подтверждения, равным 4000.

Управление потоком с использованием окон

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

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

Начнем с первого сегмента, отправленного сервером на ПК. Поле Acknowledgment должно быть вам знакомо: оно сообщает ПК, что сервер ожидает следующий сегмент с порядковым номером 1000. Новое поле, поле окна, установлено на 3000. Поскольку сегмент передается на ПК, это значение сообщает ПК, что ПК может послать не более 3000 байтов по этому соединению до получения подтверждения. Итак, как показано слева, ПК понимает, что может отправлять только 3000 байтов, и прекращает отправку, ожидая подтверждения, после отправки трех 1000-байтовых сегментов TCP.

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

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