TCP является комбинацией протоколов ARQ SR и Go-back-N. Поэтому мы должны рассмотреть каким образом подтверждение реализовано в протоколе TCP.

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

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

• «поступление данных от некоторого приложения для передачи протоколу ТСР»: передатчик TCP упаковывает данные в сегменты и отсылает ресиверу; если таймер еще не запущен, то он запускается (для понимания ситуации будем запущенный таймер ассоциировать с самым «старым» неподтвержденным сегментом данных); вычисление значения таймера осуществляется с использованием переменных EstimatedRTT и DeviationRTT, как было показано ранее;

• «истечение таймера»: TCP осуществляет повторную передачу копии необходимого сегмента; вычисляется новое значение таймера и он запускается;

• «поступление подтверждения» для некоторого сегмента: передатчик должен сравнить значение у, содержащееся в подтверждении, со значением параметра send_base, определяющим номер самого «старого» неподтвержденного байта. Как было указано ранее, TCP использует стратегию совокупного подтверждения, поэтому поступивший сегмент АСКу трактуется передатчиком как подтверждение корректной доставки всех байтов (сегментов), вплоть до номера у-1. В результате передатчик обновляет значение send_base и, если в этот момент существуют посланные, но еще не подтвержденные сегменты, вычисляет новое значение и перезапускает таймер.

Далее проанализируем табл. 1.4, в которой представлены рекомендации по посылке сегментов подтверждения протокола TCP (сторона ресивера) в соответствии с документами [RFC 1122, RFC2581 ]. Когда в ресивер поступает сегмент с номером, значение которого больше, чем номер ожидаемого сегмента - определяется так называемый промежуток (дар), т.е. в последовательности один из сегментов отсутствует. В связи с тем, что в протоколе TCP не предусмотрена возможность сообщить передатчику об этом (например, при помощи посылки сегмента отрицательного подтверждения (NACK - negative acknowledgement, [Kurose03]), ресивер просто посылает повторный сегмент подтверждения сегмента, полученного последним в соответствии с нумерацией.

Если передатчик TCP принимает три повторных сегмента подтверждения одного и того же сегмента данных (three duplicate ack), то он предполагает, что сегмент данных, посланный после сегмента, для которого были получены эти подтверждения, потерян. Далее в этом случае передатчик TCP осуществляет процедуру «быстрой повторной передачи» (fast retransmit) [RFC2581], заключающуюся в том, что передатчик осуществляет повторную передачу сегмента, не дожидаясь истечения таймера. Более подробно эта процедура описана ниже, в разделе 1.3.2.5, посвященном управлению перегрузками в протоколе TCP.

Посылка сегментов подтверждения протокола TCP Таблица 1.4

⇐Протокол selective repeat | Управление трафиком и качество обслужевания в сети | Тсриаяо⇒