6-ПпротоколTCP (1086226), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

2354 2355 3816 3817 5275 5276 8400

t1 t2 t3 t4

2354 2355 3816 3817 5275 5276 8400 10567 12430

t1 t2 t3 t4 t5

Рис. 8. Накопительный принцип квитирования: а — плотное заполнение буфера,

в момент t4 передается квитанция, б — неплотное заполнение буфера,

в момент t5 снова передается квитанция 8401

Время ожидания квитанции

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

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

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

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

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

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

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

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

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

Протокол UDP

В отличие от TCP, он не ориентирован на соединение и не обеспечивает подтверждение приема, управление потоком, сегментацию и гарантированную доставку. В результате UDP намного проще TCP и создает гораздо меньше нагрузки на сеть. Это связано не только с тем, что заголовок UDP короче заголовка TCP (8 байтов против не менее 20). В UDP нет специальных управляющих сообщений, например, сообщений для установки или разрыва соединения. Транзакция UDP состоит всего из двух сообщений — запроса и ответа, причем последний служит также неявным подтверждением приема. По этим причинам, приложения, использующие UDP, могут передавать лишь небольшие порции данных, которые могут уместиться в единственное сообщение. В основ­ном сообщения UDP применяются протоколами прикладного уровня DNS и DHCP. В определенных ситуациях UDP можно использовать и для передачи больших объемов данных, например, в аудио- и видеопотоках. В данном случае использование UDP допустимо, поскольку периодическая потеря пакетов важной роли не сыграет.

Рис. 9. Формат сообщения UDP

Функции полей сообщения UDP таковы.

• Порт источника (Source Port) (2 байта) — идентификатор процесса в передающей системе, который
сгенерировал информацию в поле данных.

• Порт приемника (Destination Port) (2 байта) — идентификатор процесса в принимающей системе, которому предназначается информация в поле данных.

• Длина (Length) (2 байта) — длина заголовка и данных UDP в байтах.

• Контрольная сумма (Checksum)(2 байта) — код CRC, вычисленный передающей системой. Целевая система использует его для обнаружения ошибок в заголовке UDP, данных и частях заголовка IP.

• Данные (Data) (переменной длины) — данные, сгенерированные процессом прикладного уровня, номер которого указан в поле Source Port.

Поля Source Port и Destination Port в заголовке UDP выполняют те же функции, что и в заголовке TCP. В поле Length указано количество данных, включенных в сообщение UDP. Как и в TCP, контрольная сумма вычисляется для заголовка сообщения, данных и псев­дозаголовка IP. В стандарте UDP использование контрольной суммы не является обязательным. Если она не используется, передающая система заполняет поле Checksum нулями. По поводу включения контрольной суммы в сообщения UDP было много споров. В документе RFC 768 указано, что во все системы UDP должна включаться возможность проверки контрольной суммы, и этот метод обнаружения ошибок действительно используется в большинстве реализации протокола UDP.

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

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

Выводы

• В то время как задачей протокола IP является передача данных между любой парой сетевых интерфейсов в составной сети, задача протоколов TCP и UDP заключается в передаче данных между любой парой прикладных процессов.

• Системные очереди к точкам входа прикладных процессов называют портами. Порты идентифицируются номерами и однозначно определяют приложе­ние в пределах компьютера.

• Приложения, которые передают данные на уровень IP, используя протокол UDP, получают номера, называемые портами UDP. Аналогично, приложени­ям, обращающимся к протоколу TCP, выделяются порты TCP.

• Если процессы представляют собой популярные общедоступные службы, такие как FTP, telnet, HTTP, TFTP, DNS и т. п., то за ними централизовано за­крепляются стандартные присвоенные (assigned) номера.

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

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

• Надежность передачи данных протоколом TCP достигается за счет того, что он основан на установлении логических соединений между взаимодействую­щими процессами.

• Прикладной процесс в сети однозначно определяется сокетом (socket), который представляет собой пару (IP-адрес, номер порта). В свою очередь, пара сокетов взаимодействующих процессов идентифицирует соединение. Каждый процесс одновременно может участвовать в нескольких соединениях.

• В рамках TCP-соединения происходит договорный процесс о следующих па­раметрах процедуры обмена данными между двумя процессами: максималь­ном размере сегмента, максимальном объеме данных, которые можно переда­вать без получения подтверждения (окне приема), о начальном порядковом номере байта, с которого начинается отсчет потока данных в рамках данного соединения.

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

9

Характеристики

Список файлов лекций