А. Робачевский - Операционная система UNIX (1114671), страница 78
Текст из файла (страница 78)
Данные буферизи!руются обоими коммуникационными узлами TCP!канала. Как правило,модуль TCP самостоятельно принимает решение, когда именно сформиро!вать сегмент для отправки и когда передать полученные данные процессу!адресату.В случае, когда требуется немедленная передача данных, без ожидания за!полнения сегмента определенного размера, протокол верхнего уровня(приложение) устанавливает флаг PSH, который указывает модулю TCP нанеобходимость немедленной доставки данных, находящихся в очереди наотправление. Это может потребоваться, например, при передаче пользова!тельского ввода при удаленном доступе (протокол Telnet).Как уже говорилось, протокол TCP обеспечивает надежный последова!тельный виртуальный канал передачи данных между приложениями.Значение MSL, рекомендованное в RFC 793 "Transmission Control Protocol", составляет2 минуты. Однако в реальных системах типичными значениями MSL являются 30 секунд,1 или 2 минуты.Эта информация представлена соответствующими структурами данных, называемыми ТСВ(Transmission Control Block).
Как правило, коммуникационный узел, представляющий се!тевой интерфейс для взаимодействующих процессов, хранит указатель на эти управляю!щие данные. Более подробно архитектура сетевых интерфейсов U N I X описана в следую!щих разделах.www.books-shop.comтранспортного уровняскольку нижележащий сетевой протокол IP является по определению не!надежным, а среда передачи вносит дополнительные ошибки, переданныеданные могут быть утеряны, продублированы или испорчены, при этомпорядок их доставки может быть нарушен.
В случае ошибочности полу!ченного сегмента модуль TCP узнает об этом, проверив контрольную сум!му. Другие ошибки являются более сложными, и TCP должен обеспечитьих определение и исправление.Рассмотренные выше порядковый номер и номер подтверждения играютключевую роль в обеспечении надежности доставки. По существу поряд!ковый номер адресует каждый октет логического потока данных междуисточником и получателем, позволяя последнему определить правильностьдоставки (порядок доставки и потерю отдельных октетов). TCP являетсяпротоколом с позитивным подтверждением и повторной передачей(Positive Acknowledgement and Retransmission, PAR). Это означает, что еслиданные доставлены без ошибок, получатель подтверждает это сегментомАСК.
Если отправитель не получает подтверждения в течение некотороговремени, он повторно посылает данные. В любом случае отсутствует нега!тивное подтверждение (NAK).В качестве примера рассмотрим передачу данных между двумя хостамисети А и В, проиллюстрированную на рис. 6.13. Для простоты предполо!жим симплексную передачу большого количества данных от хоста А к В.Начиная схост А посылает хосту В 200 октетов. Первый послан!ный сегментдоставлен без ошибок и подтвержден хостом В(АСК=301).
Следующий сегмент передан с ошибкой и не доставлен полу!чателю. Таким образом, хост А не получает подтверждения на второй сег!мент и повторно посылает его после определенногоВ конеч!ном итоге все данные, переданные хостом А будут получены и подтвер!ждены хостом В.Говоря об управлении потоком данных, следует отметить, что TCP пред!ставляет собой протокол со скользящим окном. Окно определяет объемданных, который может быть послан (send window — окно передачи) илиполучен (receive window — окно приема) TCP!модулем.
Размеры оконфактически отражают состояние буферов приема коммуникационных уз!лов. Так окно приема свидетельствует о количестве данных, которое при!нимающая сторона готова получить, а окно передачи определяет количе!ство данных, которое отправителю позволяется послать, не ожидая под!тверждения о получении. Несомненно, между этими двумя параметрамисуществует связь — окно передачи одного узла отражает состояние буфе!На самом деле ситуация, скорее всего, окажется более печальной, поскольку хост А про!должит отправку последующих сегментов в пределах окна отправки, не дожидаясь под!тверждений. Не получив подтверждения на второй сегмент, хост А повынужденбудет повторно передать все сегменты, начиная со второго. Более подробно мы рассмот!рим этот аспект в разделе "Стратегии реализации TCP" далее в этой главе.www.books-shop.comГлава 6.412в операционной системе UNIXров другого (его окно приема) и наоборот.
Принимающая сторона имеетвозможность изменять окно передачи отправителяпомощью подтвер!ждения или явного обновления значения окна в поле Window заголовкапередаваемого сегмента), и, таким образом, регулировать трафик.Рис. 6.13. Повторная передачаИнтерпретация отправителем окна передачи показана на рис. 6.14. Размерокна передачи отправителя в данном случае покрывает с 4 по 8 байт. Этоозначает, что отправитель получил подтверждения на все байты, включая3, а получатель анонсировал размер окна равным 5 байтам. Это также оз!начает, что отправитель может еще передать 2 байта (7 и 8). По мере под!тверждения получения данных окно будет смещаться вправо, открываяновые "горизонты" для передачи.
Однако окно может изменять свои раз!меры, при этом имеет значение, смещение какого края окна (правого илилевого) приводит к изменению размера.Окно закрывается по мере смещения левого края вправо. Это проис!ходит при отправлении данных.Окно открывается по мере смещения правого края вправо. Это про!исходит в соответствии с освобождением буфера приема получателяданных.www.books-shop.comПротоколы транспортного уровня413Окно сжимается, когда правый край смещается влево.
Хотя такоеповедение не рекомендуется, модуль TCP должен быть готов к обра!ботке этой ситуации.Если левый край окна достигает правого, размер окна становится равнымнулю, что запрещает дальнейшую передачу данных.Рис. 6.14. Окно передачи TCPСуммируя вышесказанное, можно отметить, что размер окна, сообщаемыйполучателем данных отправителю, является предлагаемым окном (offeredwindow), которое вслучае равно размеру свободного места вбуфере приема. При получении этого значения отправитель данных вы!числяет фактическое, доступное дляокно (usable window), ко!торое равно предлагаемому за вычетом объема отправленных, но не под!твержденных данных.
Таким образом, доступное для использования, илипросто доступное, окно меньше или равно предлагаемому. Неэффективнаястратегия подтверждений может привести к чрезвычайно малым значени!ям доступного окна и, как следствие, к низкой производительности пере!дачи данных. Это явление, известное под названием синдром "глупого окна"(Silly Window Syndrome, SWS), будет рассмотрено ниже.Стратегии реализации TCPРассмотренный стандарт протокола TCP определяет взаимодействие междуудаленными объектами, достаточное для обеспечения совместимых реали!заций. Другими словами, модуль протокола, в точности следующий спе!цификации стандарта, является гарантированно совместимым с модулямиTCP, разработанными другими производителями.
Тем не менее ряд во!просов функционирования протокола остается за рамками стандарта идопускает различные реализации, в конечном итоге влияющие не на со!вместимость, а на производительность приложений, использующих этотпротокол. В данном разделе мы рассмотрим различные подходы к реали!зации TCP, направленные на повышение его производительности.www.books-shop.comГлава 6.в операционной системе UNIXСиндром "глупого окна"Механизм подтверждения получения данных является ключевым в прото!коле TCP. Стандарт указывает, что подтверждение должно быть переданобез задержки, но не определяет конкретно, насколько быстро данныедолжны быть подтверждены, и объем подтверждаемых данных. К сожале!нию, корректная с точки зрения спецификации протокола, но неопти!мальная реализация стратегии подтверждения приводит к неудовлетвори!тельной работе механизма управления потоком данных (оконного меха!низма), что приводит к синдрому "глупого окна" (SWS).Для иллюстрации этого явления рассмотрим передачу файла большогоразмера между двумя приложениями, использующими протокол TCP.
До!пустим, что модуль протокола осуществляет передачу сегментами, размеркоторых составляет 200 октетов. В начале передачи предлагаемое окно от!правителя — 1000 октетов. Он полностью использует этот кредит, пославпять сегментов по 200 октетов каждый. После обработки первого получен!ного сегмента адресат отправляет подтверждение (сегменткотороетакже содержит обновленное значение предлагаемого окна. Предположим,что адресат передал полученные данные приложению, и таким образом егобуфер приема вновь содержит 1000 байтов свободного места. Поэтому об!новленное значение окна будет также равным 1000 октетов.
Эта ситуацияпоказана на рис. 6.15.При получении подтверждения отправитель вычисляет доступное окно.Поскольку получение 800 октетов данных еще не подтверждено, значениедоступного окна получается равным 200.Рассмотрим теперь процесс возникновения SWS. Предположим, что от!правитель вынужден передать сегмент размером 50 октетов (например, ес!ли приложение указало флаг PSH). Таким образом, он отправляет 50 бай!тов, и вслед за этим следующий сегмент, размером 150 октетов (посколькуразмер доступного окна равен 200). Через некоторое время адресат полу!чит 50 байтов, обработает их и подтвердит получение, не изменяя значе!ния предлагаемого окна (1000 октетов).
Однако теперь при вычислениидоступного окна, отправитель обнаружит, что не подтверждены 950 бай!тов, и, таким образом, его окно равняется всего 50 октетам. В результатеотправитель вновь вынужден будет передать всего 50 байтов, хотя прило!жение этого уже не требует.Если мы продолжим анализировать передачу данных, то заметим, что ри!сунок транзакций будет периодически повторяться, т.
е. отправитель будетвынужден периодически передавать сегмент необоснованно малого разме!ра. Этот порочный круг не может быть разорван естественным образом.Происхождение сегментов малого размера очевидно: периодически у от!правителя возникает необходимость разделить доступное окно на несколь!ко мелких сегментов. При непрерывной передаче больших объемов дан!ных такие ситуации будут время от времени возникать, оставляя неизгла!www.books-shop.comПротоколы транспортного уровняслед на характере транзакций. В результате это может привести к"засорению" сети множеством мелких пакетов в одну сторону и множест!вом подтверждений в другую.6.15.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
