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

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

Варьируя величину окна, можно влиять на загрузку сети. Чем больше окно, тем большая порция неподтвержденных данных может быть послана в сеть. Но если пришло большее количество данных, чем может быть принято модулем ТС Г данные будут отброшены. Это приведет к излишним пересылкам информации и ненужному увеличению нагрузки на сеть и модуль TCP.

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

Управлять размером окна приема может не только та сторона, которая посылает это окно, чтобы регулировать поток данных в свою сторону, но и вторая сторо­на — потенциальный отправитель данных. Если вторая сторона фиксирует нена­дежную работу линии связи (регулярно запаздывают квитанции, часто требуется повторная передача), то она может по собственной инициативе уменьшить окно. В таких случаях действует правило: в качестве действующего размера окна вы­бирается минимальное из двух значений — значения, диктуемого приемной сто­роной, и значения, определяемого «на месте» отправителем.

Признаком перегрузки TCP-соединения является возникновение очередей на промежуточных узлах (маршрутизаторах) и на конечных узлах (компьютерах). При переполнении приемного буфера конечного узла «перегруженный» про­токол TCP, отправляя квитанцию, помещает в нее новый, уменьшенный размер окна. Если он совсем отказывается от приема, то в квитанции указывается окно нулевого размера. Однако даже после этого приложение может послать сообще­ние на отказавшийся от приема порт. Для этого сообщение должно сопровож­даться указателем срочности. В такой ситуации порт обязан принять сегмент, даже если для этого придется вытеснить из буфера уже находящиеся там дан­ные. После приема квитанции с нулевым значением окна протокол-отправитель время от времени делает контрольные попытки продолжить обмен данными. Если протокол-приемник уже готов принимать информацию, то в ответ на кон­трольный запрос он посылает квитанцию с указанием ненулевого размера окна.

Как видно из нашего далеко не полного описания двух протоколов транспортно­го уровня стека TCP/IP, на один из них — TCP — возложена сложная и очень важная задача обеспечение надежной передачи данных через ненадежную сеть.

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