Р.Л. Смелянский - Компьютерные сети. Том 2. Сети в ЭВМ (1130083), страница 28
Текст из файла (страница 28)
После этого машина А блокирует- ":,511 . ся, что происходит на восьмом шаге. На девятом шаге у машины А °:.«:,-::-",-Срабатывает таймер по истечении 1ппе-опг на подтверждение сегмен' -''-'",'т та 2, поэтому она посылает этот сегмент еше раз. На десятом шаге '~~=','..машина В подтверждает получение всех отправленных сегментов и ,"~!:,','Выделяет буферное пространство машине А. На одиннадцатом шаге :;, машина В выделяет буфер под один сегмент ',~~.;.! А Сообщение *уз!< ':. 1 <гейпезт 8 Ьп1тегз> А хочет 8 буферов „,'.~',".',.".,1 2 <аск — 15, Ьпг' — 4> В гарантирует получение сообщений с О по 3 3 <аеч — О, бага — шО> УА осталось 3 буфера :,";;:."'*=,"' 4 <зеЧ вЂ” 1, ОаГа — ш1> У А осталось 2 буфера 5 <зея — 2, дага — ш2> " Сообщение потеряно, но А попашет, что осталось одно - 1Г1з' " 6 <ас1с — 1, Ьпт — 3> В подтверждает О и 1, разрешает отправку 2-4 7 <зед — 3, дага — шз> УА остался буфер 8 <зеч — 4, Оаьз — гп4> УА осталось О буферов, и он должен остановиться ,~!:;;;.' 9 <зол — 2, дага — гп2> УА срабатывает таймаут, н он перепосьщает сообщение *;,):;-'.,' 10 <аск — 4, Ьпт — О> Все подтверждения прихолят, но.4 все еще блокирован П <асх — 4, Ьпу — 1> теперьА может отправить 5 12 <аса — 4.
Ьпу — 2> У В появился еше буфер 13 <зеч — 5, дага — т5> У А остался 1 буфер 14 <зеч — 6, дага — шб> А снова заблокирован 15 <асŠ— 6, Ьпт — 0> А все еще заблокирован 16 "- <аск — 6, Ьст — 4> Потенциальный дедлок Рнс. 3.7. Динамическое выделение буферов Описанная схема таит одну опасность. Дело в том, что управляющие сегменты не подтверждаются, поэтому если сообщение, посланное машиной В на шестнадцатом шаге о выделении буферного пространства машине А, будет утеряно, то машина А окажется надолго в ожидании выделения буферного пространства. Чтобы предотвратить такис ситуации, каждая машина должна периодически посылать по каждому транспортному соединению сегменты с подтверждениями па полученные сегменты и информацию об имеющихся буферах. Далее при рассмотрении протокола ТОР будет приведена схема управления размером скользящего окна, определяемым исходя из текущей пропускной способности канала.
Такая схема обеспечивает наиболее полное использование возможностей канала. Подробно вопросы управления буферизацией рассмотрены в [59, 71]. 3.2.6. Мультиплексирование Потребность в мультиплексировании нескольких потоков данных одного уровня на одном соединении, виртуальном канале, физической линии нижерасположенного уровня возникала у нас и ранее. Возникает она и на транспортном уровне. Например, если пользователь за терминалом установил транспортное соединение и отошел попить кофе, то транспортное соединение продолжает поддерживаться, под него резервируется буферное пространство, пространство в таблице маршрутизации и т.д. В целях снижения стоимости можно отобразить несколько транспортных соединений на одно сетевое.
Такое отображение называется нисходящим мультиплексированием. В некоторых случаях, наоборот, в целях увеличения пропускной способности по отдельным транспортным соединениям можно отобразить транспортное соединение на несколько сетевых, и на каждом сетевом соединении иметь свое скользящее окно. Тогда, быстро исчерпав возможности одного буферного пространства в одном окне, можно переключиться на другое сетевое соединение и продолжить передачу по этому соединению. В результате получим канал, пропускная способность которого равна сумме пропускных способностей отдельных каналов на сетевом уровне. Такое мульти плексирование называется восходящим.
3.2. 7. Восстановление после сбоев Восстановление после сбоев рассмотрим в предположении, что транспортный агент целиком располагается на абонентской машине. Восстановить сетевой уровень достаточно просто. Если сетевой уровень предоставляет дейтаграммный сервис, то транспортный уровень 120 :.!..:-'; ', должен быть ориентирован на то, что ТРОН-сегменты будут терять- ,'~',,'-, 'ся, и поэтому он должен уметь исправлять подобные ситуации.
При сервисе, ориентированном на соединение, транспортный уровень .должен уметь восстанавливать потерянное соединение и стараться в диалоге с транспортным агентом на другой стороне выяснить, что успели перелать, а что не успели Проблема усложняется, когда надо восстанавливать работоспособность машины, включая транспортный уровень.
Рассмотрим случай, когда транспортный сервер взаимодействует с клиентами. Предпо!::, ложим, сервер «упал» и надо восстановить его функционирование Прежде всего, серверу необходимо узнать у клиента, какой ТРОН- сегмент был последним неподтвержленным, и попросить повторить :,'!:.: его. В свою очередь, клиент может находиться в одном из следующих состоянии: 5 ~ — имеется неподтвержденный ТРО1.1-сегмент; Я0 — все ТРОН-сегменты подтверждены Казалось бы все просто. Однако рассмотрим проблему вниматель;='-'.;",::: нее. Сервер, получив ТРОН-сегмент, либо сначала посылает под:~з",," стверждение, а затем записывает полученное ТРОН в буфер прило.;~~:::: —: жения, либо сначала записывает полученное ТРОН, а затем посыла- ,~.';: ет подтверждение.
Если сервер «упал э, послав подтверждение, но до того, как он осуществил запись, то клиент будет находиться после ;:~.; восстановления сервера в состоянии Бм хотя подтвержденный ТР!Н1- .~~!,:: сегмент потерян. Пусть, наоборот, сервер сначала записал ТРОН:;:.:.'!"!,': сегмент, а затем «упал». Тогда после сбоя сервер найдет клиента в ' 2::,:;;:; состоянии Ь, и решит, что надо повторить неподтвержденный ТРОН;;"-;"„: сегмент. В результате получим повторный ТРОН-сегмент Можно формально показать, что проблема восстановления после сбоев только средствами транспортного уровня не решается.
Необ;-'"'".,'.;,;::.'.ходимо, записав ТРОН-сегмент, информировать об этом приложение "'~~::,'",:., и только после этого посылать подтверждение. При восстановлении следует опрашивать не только клиента на транспортном уровне, но ;:,;.::;:. 'и приложение. 3.3. Транспортные протоколы в Интернете 3.3. г. Общие сведения э-' В Интернете имеется два основных транспортных протокола ТСР— протокол, ориентированный на соединение, и НОР— протокол, не ориентированный ца соединение, Поскольку сервис, реализуемый протоколом НОР— это практически сервис, реализуемый протоколом !Р с добавлением небольшого заголовка, то основное внимание мы уделим рассмотрению протокола ТСР ТСР (Тгапаппаа1оп Сов!го! Рго1осо1) — специально созданный протокол для надежной передачи потока байтов по соединению типа 121 точка — точка через ненадежную сеть, ТСР был сознательно разработан таким образом.
чтобы он мог адаптироваться к условиям и особенностям разных сетей, устойчиво и эффективно функционировать в условиях Интернета !нескольких сетей). На каждой машине, полдерживаюшей ТСР, есть ТСР-агент, который располагается либо в ялре операционной' системы, либо в процессе.
который управляет ТСР-потоками и доступом к сервису !Р-протокола. ТСР получает данные в виде потока байтов от приклалного процесса, дробит этот поток на сегменты не более чем по 65 Кбайт (на практике не более 1,5 Кбайт) таким образом, чтобы сегмент помешался в 1Р-пакет, добавляет 20-байтовый заголовок и отправляет сегменты па сетевой уровень. Поскольку !Р-уровень не гарантирует доставку каждого пакета, то в задачи ТСР-агента входят опрелеление потерь и организация повторной передачи потерянного.
Поскольку на сетевом уровне в Интернете соединения не поддерживаются, то сегменты могут поступать к получателю в произвольном порядке и задачей ТСР-агента является восстановление исхолного порядка. 3.3.2. Модель сервиса ТСР Доступ к ТСР-сервису происходит через сокет. Сокет состоит из !Р-алреса хоста и 16-разрялного локального номера на хосте, называемого аорт.
Сокеты создаются как отправителем, так и получателем. Порт — это ТВАР для ТСР. Каждое соединение илентифицируется парой сокетов, между которыми оно установлено. Один и тот жс сокет может быть использован для разных соединений. Никаких дополнительных виртуальных соединений не создается. Порты ло 256 номера зарезервированы для станлартных сервисов, которые постоянно активны и готовы к работе. Например, для обеспечения ГТР-передачи файла (см, гл, 4) соединение должно выполняться через 2!-й порт, где находится ГТР-демон, а для ТЕ! ХЕТ вЂ” через 23-й порт. Полный список таких портов можно найти в йГС 1700. Все ТСР-соединения — дуплексные, т.
е. передача по ним проис- холит независимо в оба направления. ТСР-соединение поддерживает только соединение точка — точка. Не сушествует ТСР-соединений типа «от одного ко многимхь ТСР-агент поддерживает поток байтов. а не поток сообшений. Напомним, это означает, что границы сообшений не подлерживаются автоматически в потоке. Например, если по ТСР-соединению перелается текст, разбитый на страницы, то ТСР-агент не будет каким-либо образом обозначать конец каждой страницы. После передачи приложением ланных ТСР-агенту, эти данные могут быль отправлены сразу на сетевой уровень, а могут быть буферизованы. Как поступить в этом случае решает ТСР-агент. Однако в ряде случаев бывает необходимо, чтобы данные были отправлены 122 „1Ь~;-':,"-::сразу, например если эти данные представляют собой команду для :"":...;;::: удаленной машины. Для этого в заголовке ТСР-сегмента имеется флаг .'=!:;:;,.: Р13ЯН, и если он установлен, то это говорит ТСР-агенту о том, что ~ц данные должны быть переданы немедленно Наконец, если в заголовке ТРОП-сегмента установлен флаг ,:",;, 13ВОЕ1')Т, то ТСР-агент передает такой сегмент незамедлительно Когда срочные данные поступают к месту назначения, то их пере- Ь' дают получателю немедленно 3.3.3.
Протокол ТСР Как уже говорилось, приложение передает на транспортный ура':-';;";: 'вень поток байтов. Каждый байт в ТСР-соединении имеет 32- ,; разрядный номер. В сети с пропускной способностью 10 Мбит(с по„'г"",'.;":.' требуется не менее часа, чтобы исчерпать все номера с 0 до 2з~.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
