Для полной картины понимания реализации протокола АЯ(2 в ТСР необходимо рассмотреть три важных примера и сравнить их. Предположим, что существуют два хоста: А - источник и В - приемник. Между ними установлено соединение ТСР.
Пусть в первом примере (см. рис. 1.16) хост А посылает В один сегмент данных, номер сегмента 92 и содержит он 8 байтов данных. После посылки А инициализирует таймер. Хост А ожидает прихода сегмента подтверждения от В, содержащего номер сегмента, который хост В готов принять следующим. Здесь необходимо отметить, что в протоколе ТСР для нумерации сегментов применяются номера байтов, т.е. в рассматриваемом случае после сегмента номер 92 с длиной поля данных 8 байт будет следовать сегмент номер 100. Далее, пусть сегмент данных безошибочно принят ресивером, и соответствующий сегмент подтверждения был послан, но потерян при передаче. Таким образом, по истечении таймера хост А осуществляет повторную передачу сегмента данных номер 92. В результате в ресивер поступает копия сегмента номер 92. Ресивер определяет, что сегмент был уже принят, сбрасьшает его копию и повторно посылает сегмент подтверждения сегмента данных номер 92.
Рис. 1.16. Повторная передача по причине потери сегмента подтверждения Пусть во втором примере (см. рис. 1.17) хост А посылает два сегмента один за другим, первый сегмент имеет номер 92 и содержит 8 байт данных, а второй - номер 100 и 20 байт данных. Предположим, что оба сегмента поступают в ресивер хоста А безошибочно и в правильном порядке. Пусть ресивер посылает два отдельных сегмента подтверждения для каждого поступившего сегмента данных, т.е. АСК100 и АСК120, где число означает номер ожидаемого сегмента. Далее, пусть ни один сегмент подтверждения не достигает передатчика хоста А вплоть до истечения таймера. Передатчик осуществляет повторную передачу сегмента номер 92 и запускает таймер. Далее, до истечения таймера для сегмента данных номер 92 в передатчик поступают сегменты подтверждения АСК100 и АСК120. Следовательно, повторной передачи сегмента номер 100 не производится.
Рис. 1.17. Повторная передача сегмента.с номером 100 не осуществляется Пусть в третьем примере (см. рис. 1.18) хост А посылает два сегмента один за другим точно так же, как и во втором примере. Пусть сегмент подтверждения АСК100 для первого посланного сегмента данных был потерян, а второй сегмент подтверждения АСК120 был доставлен передатчику до истечения таймера передатчика для первого посланного сегмента. Таким образом, на основе АСК120 источник хоста А предполагает, что все данные вплоть до байта номер 119 были успешно получены ресивером, т.е. А принял АСК120 за совокупное подтверждение. Повторной передачи сегмента номер 92 осуществлено не будет.
Проан&чизировав представленные примеры, можно предположить, что протокол TCP реализован в соответствии со стратегией Go-back-N. Это действительно так, потому что применяются совокупные подтвер-
Рис. 1.18. Идентификация совокупного подтверждения ждения и безошибочно, но вне очереди принятые сегменты не подтверждаются индивидуальными сегментами подтверждения. Поэтому, также ранее было показано, что протокол TCP, реализованный в передатчике, управляет всего двумя переменными send_basе и next_seq_nurr.. Однако следует помнить, что хоть TCP и реализован в соответствии со стратегией Go-back-N, он не является ее чистой реализацией - существуют определенные различия.
Рассмотрим пример. Предположим, что передатчик посылает последовательность сегментов данных 1, 2, …, N и все эти сегменты поступают в ресивер безошибочно и в порядке очереди. Далее пусть сегмент подтверждения для некоторого пакета п, где n < N, был потерян, но остальные N-1 сегментов подтверждения были доставлены передатчику вовремя, т.е. до истечения соответствующих таймеров. В этом случае протокол Go-back-N осуществит лишь повторную передачу всех сегментов с номерами > п, но меньше N. Протокол же TCP осуществит повторную передачу только одного сегмента номер п, и то не всегда, а только если сегмент его подтверждения не поступит в передатчик до истечения соответствующего таймера.
В ряде работ RFC2018, Fall96, Mathis96] было предложено расширить функции протокола TCP в соответствии со стратегией SR. Идея, стоящая за этими предложениями, может быть сформулирована как реализация поддержки в протоколе TCP возможности явного информирования передатчика о том, какие сегменты были получены ресивером корректно, а какие еще не получены вообще. В [RFC 1072] было предложено использовать в TCP протокол «выборочного подтверждения» (selective acknowledgement), позволяющий ресиверу TCP подтверждать сегменты, поступающие вне очереди индивидуально, вместо посылки совокупного подтверждения последнего корректно принятого сегмента данных. Таким образом, функционируя совместно, протоколы «выборочный повтор» и «выборочное подтверждение» обеспечивают оптимальное функционирование протокола TCP, т.к. не осуществляется повторая передача сегментов, которые были индивидуально подтверждены.
⇐Обработка сегментов подтверждения аск в tcp | Управление трафиком и качество обслужевания в сети | Управление потоком в протоколе tcp⇒