Протокол TCP как происходит управление потоком

В предыдущих статьях были разобраны такие темы как: “Основы протокола TCP” и “Протокол TCP: формат заголовка”. 

Управление потоком в TCP

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

Но что произойдет, если получает данные не высокопроизводительный сервер, а маленький телефон, смартфон, планшет или какое-то другое медленное устройство? В этом случае получатель примет несколько сегментов, а остальные будет вынужден отбросить. 

Задача предотвращения отправки быстрым отправителем слишком большого количества сегментов, которые не могут быть получены медленным получателем, так называемого “затопления” в TCP называется управление потоком (flow control).

Задача предотвращения отправки быстрым отправителем слишком большого количества сегментов, которые не могут быть получены медленным получателем, так называемого “затопления” в TCP называется управление потоком (flow control). 

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

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

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

Размер окна в заголовке TCP

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

Рассмотрим, как используются это поле на практике. Предположим, что размер буфера у получателя равен восьми сегментам. Отправитель передает один сегмент он записывается в буфер, получатель передает подтверждение получение этого сегмента. В подтверждение, кроме номера следующего ожидаемого байта, указывается также размер окна 10 220 что соответствует семи сегментам (7*1460). Мы используем сеть Ethernet в который размер кадра 1500 байт, если вычтем заголовок TCP 20 байт и IP 20 байт, размер данных сегмента получится 1460 байт.

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

Предположим, что приложение занято какими-то делами и ничего из буфера не читает.

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

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

Например, сегмент с новым размером окна мог потеряться по сети, приложение могло прочитать данные, но по каким-то причинам транспортная подсистема это еще не обнаружила, либо у получателя произошла какая-то критическая ошибка и соединение уже разорвано. В ответ на сегмент Zero Window Probe получатель может отправить сообщение, что размер окна по-прежнему равен нулю, это значит отправитель должен ждать либо новый размер окна, значит отправитель может передавать данные.

Заключение

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

Оцените статью
Все о технологиях, мобильных приложениях и тарифах на связь
Adblock
detector