Протоколы транспортного уровня

     Рисунок 1.1 Метод подтверждения корректности передачи кадров с простоем  источника 
 
 
 

     Во  втором методе для повышения коэффициента использования линии источнику  разрешается передать некоторое  количество кадров в непрерывном  режиме, то есть в максимально возможном  для источника темпе, без получения на эти кадры ответных квитанций. Таким образом, между отправленными и подтвержденными данными существует окно уже отправленных, но еще неподтвержденных данных. Количество кадров, которые разрешается передавать таким образом, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения. Рисунок 2 иллюстрирует данный метод для размера окна в W кадров. Обычно кадры при обмене нумеруются циклически, от 1 до W. При отправке кадра с номером 1 источнику разрешается передать еще W-1 кадров до получения квитанции на кадр 1. Если же за это время квитанция на кадр 1 так и не пришла, то процесс передачи приостанавливается, и по истечению некоторого тайм-аута кадр 1 считается утерянным (или квитанция на него утеряна) и он передается снова. 

     Рисунок 2.2 Метод «окна» непрерывная отправка пакетов 

     Если  же поток квитанций поступает  более-менее регулярно, в пределах допуска в W кадров, то скорость обмена достигает максимально возможной  величины для данного канала и принятого протокола.

       Последний алгоритм называют  алгоритмом скользящего окна. Действительно,  при каждом получении квитанции  окно перемещается (скользит), захватывая  новые данные, которые разрешается  передавать без подтверждения. 

     2.4 Реализация скользящего окна в протоколе TCP 

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

       Квитанция посылается только  в случае правильного приема  данных, отрицательные квитанции  не посылаются. Таким образом,  отсутствие квитанции означает либо прием искаженного сегмента, либо потерю сегмента, либо потерю квитанции.

       В качестве квитанции получатель  сегмента отсылает ответное сообщение  (сегмент), в которое помещает  число, на единицу превышающее  максимальный номер байта в  полученном сегменте. Если размер окна равен W, а последняя квитанция содержала значение N, то отправитель может посылать новые сегменты до тех пор, пока в очередной сегмент не попадет байт с номером N+W. Этот сегмент выходит за рамки окна, и передачу в таком случае необходимо приостановить до прихода следующей квитанции.  

     2.5 Выбор тайм-аута 

       Выбор времени ожидания (тайм-аута) очередной квитанции является  важной задачей, результат решения  которой влияет на производительность  протокола TCP.

       Тайм-аут не должен быть слишком коротким, чтобы по возможности исключить избыточные повторные передачи, которые снижают полезную пропускную способность системы. Но он не должен быть и слишком большим, чтобы избежать длительных простоев, связанных с ожиданием несуществующей или "заблудившейся" квитанции.

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

     ЗАКЛЮЧЕНИЕ 
 

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

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

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

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

       Напоследок отметим: протокол TCP разбивает поток байт на пакеты; он не сохраняет границ между  записями. Например, если один прикладной  процесс делает 5 записей в TCP-порт, то прикладной процесс на другом  конце виртуального канала может  выполнить 10 чтений для того, чтобы получить все данные. Но этот же процесс может получить все данные сразу, сделав только одну операцию чтения. Не существует зависимости между числом и размером записываемых сообщений с одной стороны и числом и размером считываемых сообщений с другой стороны. 
 
 
 
 
 
 
 
 
 
 
 

     Список  использованной литературы 

1. http://kunegin.com/ref3/tcp/glava4.htm
2. http://latysheva2007.narod.ru/theme20.html
3. http://www.bestreferat.ru/referat-168512.html
4. http://referat.yabotanik.ru/programmirovanie-i-kompjutery/protokoly-transportnogo-urovnya/19290/19303/page2.html