Home

Page
Page 1
background image

На   прошлом   занятии   мы   начали   рассмотрение   вопросов,   связанных   с   оптимизацией 

генерации   потока   данных   в  TCP  соединении.   Мы   выяснили,   что   с   одной   стороны   станциям 
выгоднее отправлять сегменты данных как можно большего размера, но с другой стороны станциям 
необходимо   стремится   избегнуть   нежелательной   фрагментации   посылаемых   данных.   Для 
нахождения   максимального   оптимального   размера   данных,   которые   следует   помещать   в   один 
сегмент   используется  TCP  опция  MSS  и   технология  Path  MTU  Discovery,   базирующаяся   на 
функциональных возможностях протоколов IP и ICMP. 

Для начала зададимся вопросом: ВСЕГДА ли стеку отправителю стоит посылать сегменты 

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

Рассмотрим пример: пусть клиент хочет получить с файлового сервера большой файл. Ясно, 

что при передаче этого файла будет иметь место не интерактивный поток данных от сервера к 
клиенту, в обратную сторону потока данных скорее всего не будет, а будет лишь поток квитанций 
(отметим, что это определяется спецификой файлового протокола, например, именно так передает 
файлы   протокол  FTP,   который   будет   нами   изучаться   в этом   курсе).   Ясно,   что   при   передаче 
большого   объема   не   интерактивных   данных   отправителю   (в   данном   случае   серверу)   наиболее 
выгодно использовать сегменты максимально возможного для данного соединения размера. Таким 
образом можно смело предположить, что изучая такой трафик с помощью анализатора протоколов, 
мы увидим сегменты максимально возможного размера. Наверняка размер передаваемого файла не 
кратен  MSS, который используют станции в данном соединении, поэтому логично предположить, 
что по крайней мере последний сегмент, переносящий окончание файла не будет полноразмерным. 
На самом деле ситуация несколько сложнее, при передаче большого массива данных возможно 
появление большего количества не полноразмерных сегментов, однако количество таких сегментов 
в любом случае будет невелико. Чуть позже мы поговорим и о передаче потоков данных подробнее, 
но   пока   отметим,   что   в   первом   приближении   при   передаче   массива   данных   стеку   отправителя 
выгодно использовать полноразмерные сегменты. 

Однако перед тем, как сервер начнет передавать клиенту файл, клиент должен обменяться с 

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

Если стек клиента, будет сохранять такую небольшую порцию данных в буфере дожидаясь, 

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

Именно   для   решения   задачи   об   эффективной   передаче   посредством  TCP  интерактивных 

данных в спецификацию RFC793 и был включен флаг PUSH, к изучению функций которого в TCP 
взаимодействиях   мы   и   переходим.   Рассмотрим,   как   предполагалось   использовать   флаг  PUSH  в 
соответствии со спецификацией RFC793.

При вызове функции (SEND), передающей данные в открытое TCP соединение, приложение 

отправитель должно было в качестве аргумента передать своему локальному стеку данные, которые 
необходимо   отправить   в   соединение,   а   так   же   выставить   специальный   флаг,   указывающий   на 
необходимость   БЕЗОТЛАГАТЕЛЬНО   передать   эти   данные   в   соединение   без   ожидания 
формирования сегмента максимального размера. Отметим, что речь не идет здесь о флаге  PUSH 
непосредственно – действительно, приложение отправитель общается с локальным стеком TCP не 
по протоколу TCP, а с помощью вызова функций соответствующего API, соответственно, пока речь 
идет о флаге, устанавливаемом приложением при вызове функции API, обеспечивающем работу с 
сокетами в некоторой операционной системе клиента. При вызове функции SEND с установленным 
флагом   выталкивания,   локальный  TCP  должен   был   отправить   в   сеть   полученные   данные 
немедленно, т.е. не пытаться задерживать поступившие от приложения данные в буфере с целью 


Copyright © 2017 Файлообменник zFile.in.ua

Использование любых материалов сайта возможно только с разрешения автора.