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

TCP-отправитель ограничивает передачу данных, чтобы избежать переполнения буфера на стороне получателя. Теоретически в TCP Можно передавать данные в то время, когда приложение записывает данные в сокет. Однако TCP ограничивает передачу данных по двум существенным причинам. Во-первых, отправитель не должен передавать больше данных, чем получатель может хранить в своих буферах, — передача излишпих данных приведет к переполнению буфера на стороне получателя и к утере пакетов. Во-вторых, отправитель не должен передавать данные быстрее, чем сеть может их обработать, — слишком «агрессивная» передача может привести к перегрузке сети и возникновению заторов, которые увеличивают время ожидания и повышают вероятность утери пакетов. Каждый TCP-отправитель ограничивает число ожидающих обработки (неподтвержденных) байтов в сети, используя технологию управления потоком с помощью скользящих окон. Чтобы избежать перейолнепия буфера у получателя, пакеты от В к А содержат в ТСР-заголовке окно приема.

Рис. 5.6. Пример 4000-байтпого окпа приема

Окно приема определяет число байтов, которые приложение А может отправить после последнего байта, подтвержденного приложением В. Предположим, что операционная система, под управлением которой выполняется приложение В, выделила 4000-байтовый входной буфер для хранения входящих данных для этого ТСР-соединения, как показано на рис. 5.6. Предположим также, что приложение В получило и подтвердило прием 2500 байтов от А, и 2000 байтов из этих 2500 байт были прочитаны приложением В. Тогда во входном буфере остается еще 500 байтов данных. Приложение В не может обработать более 3500 дополнительных байтов дапных. АСК-пакет приложению А подтверждает получение первых 2500 байт и сообщает о размере окпа приема в 3500 байтов. После получения пакета ACK приложепие А может продолжить передавать данные. Однако А не может отправить более 3500 дополнительных байтов данных. В противном случае может произойти переполнение входного буфера на стороне приложения В. Допустим, что А отправляет дополнительные 2000 байтов, что составит всего 4500 байт. Первые 2000 байт были отправлены, получеиы, подтверждены и нрочитапы. Следующие 500 байт были отправлены, получеиы и подтверждены, по не были прочитапы приложением В. Поскольку следующие 2000 байтов были отправлены, по не подтверждены, А не знает о том, что они были получены.

Следующие 1500 байт могут быть переданы немедленно. Приложение А не может отправлять оставшиеся данные без риска вызвать иереполпепие входного буфера на стороне В. В любой заданный момент времени А не может передать данные, если они выходят за границу текущего окна приема, которая определяется суммой последнего числа подтверждения и размером окпа, полученного от В. Умалчиваемый размер входного буфера TCP является настраиваемым параметром операционной системы. На практике большинство операционных систем выделяют буфер размером 8 Кб, 16 Кб или 32 Кб. Приложения могут с помощью системного вызова увеличить размер буфера приема. Для пары хостов с большим временем доставки (например, если клиентом и сервером находится большое число маршрутизаторов) размер буфера приема может ограничивать производительность. Например, предположим, что пара хостов имеет время доставки в 500 мс, а размер входного буфера на стороне В равен 8 Кбайтам. Отправитель А не может передать более 8 Кбайтов каждые полсекунды. Это соответствует максимальной скорости передачи 128 Кб/с вне зависимости от пронускпой способности соединения от А к В. В общем случае производительность TCP обратио пропорциопальиа вре’мепи доставки данных между отправителем и получателем.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100