Реферат: Методы управления трафиком - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Методы управления трафиком

Банк рефератов / Компьютерные сети

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 26 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Методы управления трафиком Непрекращающийся рост Internet и частны х сетей предъявляет новые требования к пропу скной способности . World Wide Web привел к гигантскому ув еличению трафика графической информации . Сегодня еще и голосовые , а также видеоприложения выдвигают свои специфические требования к и без того перегруженн ы м сетям. Чтобы удовлетворить все эти запросы , о дного увеличения емкости сети недостаточно . Ч то действительно необходимо , так это разумные эффективные методы управления трафиком и контроль загруженности. Исторически сети на базе IP пред оставляли всем прилож ениям только простей шую услугу по доставке данных по мере возможности . Однако потребности изменились со временем . Организации , потратившие миллионы д олларов на установку сети на базе IP для передачи данных между локальными сетями , ст алкиваются теперь с те м , что так ие конфигурации не способны эффективно поддер живать новые мультимедийные приложения реального времени с многоадресной рассылкой. ATM - единственная сетевая техноло гия , изначально разрабатывавшаяся для поддержки обычного трафика TCP и UDP наряду с трафико м реального времени . Однако ориентация на ATM означает либо создание новой сетевой инфрас труктуры для трафика реального времени , либо замену имеющейся конфигурации на базе IP, п ричем обе альтернативы обойдутся весьма недеш ево. Поэтому потребность в поддержке нес кольких типов трафика с различными требования ми к качеству услуг в рамках архитектуры TCP/IP весьма насущна . Эту задачу призваны реш ить два ключевых инструмента : транспортный пр отокол реального времени (Real-Time Transport Protocol, RTP) и пр о токол резервирования ресурсов (Resource Reservation Protocol, RSVP). RTP гарантирует доставку данных одному ил и более адресатам с задержкой в заданных пределах . Это означает , что данные могут быть воспроизведены в реальном времени . RSVP позволяет конечным системам резервировать сетевые ресурсы для получения необходимого качества услуг , в особенности ресурсы для трафика реального времени по протоколу RTP. Наиболее широко используемый протокол тра нспортного уровня - это TCP. Несмотря на то чт о TCP позволяет п оддерживать множество разно образных распределенных приложений , он не под ходит для приложений реального времени. В приложениях реального времени отправите ль генерирует поток данных с постоянной с коростью , а получатель (-и ) должен предоставлять эти данные при ложению с той же самой скоростью . Такие приложения включают аудио - и видеоконференции , распространение живого видео (для немедленного воспроизведения ), разд еляемые рабочие области , удаленную диагностику в медицине , компьютерную телефонию , распределен ное и н терактивное моделирование , игры и мониторинг в реальном времени. Использование TCP в качестве транспортного п ротокола для этих приложений невозможно по нескольким причинам . Во-первых , этот протокол позволяет установить соединение только между двумя конечны ми точками , следовательно , он не подходит для многоадресной передачи . Он предусматривает повторную передачу потерянн ых сегментов , прибывающих , когда приложение ре ального времени уже их не ждет . Кроме того , у TCP нет удобного механизма привязки и нформации о синхронизации к сегментам - другое требование приложений реального врем ени. Другой широко используемый протокол транс портного уровня UDP не имеет первых двух огр аничений (соединение точка-точка и передача по терянных сегментов ), но и он не предоставл яет кр итической информации о синхронизаци и . Таким образом , UDP не предоставляет сам по себе каких-либо инструментов общего назначен ия для приложений реального времени. Несмотря на то что каждое приложение реального времени может иметь свои собст венные механизмы для поддержки передачи в реальном времени , они имеют много общ их черт , а это делает определение единого протокола весьма желательным . Стандартный пр отокол такого рода - RTP, определенный в RFC1889. В типичной среде реального времени от правитель генерирует пакеты с постоянной скоростью . Они отправляются им через одинак овые интервалы времени , проходят через сеть и принимаются получателем , воспроизводящим данн ые в реальном времени по их получении. Однако ввиду вариации задержки при пе редаче пакетов по сети они прибывают через нерегулярные интервалы времени . Для к омпенсации этого эффекта поступающие пакеты б уферизуются , придерживаются на некоторое время и затем предоставляются с постоянной скоро стью программному обеспечению , генерирующему выво д . Чтобы такая схе м а работала , каждый пакет получает отметку о времени - таким образом получатель может воспроизвести поступающие данные с той же скоростью , что и отправитель. RTP поддерживает передачу данных в реальн ом времени между несколькими участниками сеан са . (Сеанс - это логическая связь между двумя и более пользователями RTP, поддерживаемая в течение всего времени передачи данных . Процесс открытия сеанса выходит за рамки RTP.). Хотя RTP может использоваться и для одно адресной передачи в реальном времени , его сила в по ддержке многоадресной передачи . Для этого каждый блок данных RTP содержит идентификатор отправителя , указывающий , кто и з участников генерирует данные . Блоки данных RTP содержат также отметку о времени , чтобы данные могли быть воспроизведены с прави льными и нтервалами принимающей стороной. Кроме того , RTP определяет формат полезной нагрузки передаваемых данных . С этим напрям ую связана концепция синхронизации , за котору ю частично отвечает микшер - механизм трансляц ии RTP. Принимая потоки пакетов RTP от одного или более источников , он комбинирует и х и посылает новый поток пакетов RTP одному или более получателям . Микшер может прост о комбинировать данные , а также изменять и х формат. Пример приложения для микшера - комбиниров ание нескольких источников звука . Напри ме р , предположим , что часть систем данного а удиосеанса генерирует каждая свой собственный поток RTP. Большую часть времени только один источник активен , хотя время от времени одновременно "говорят " несколько источников. Если новая система хочет принять уча стие в сеансе , но ее канал до сети не имеет достаточной емкости для под держки всех потоков RTP, то микшер получает в се эти потоки , объединяет их в один и передает последний новому члену сеанса . П ри получении нескольких потоков микшер просто складывает зна ч ения импульсно-кодово й модуляции . Заголовок RTP, генерируемый микшером , включает идентификатор (-ы ) отправителя (-ей ), ч ьи данные присутствуют в пакете. Более простое устройство создает один исходящий пакет RTP для каждого поступающего пакета RTP. Этот механ изм , называемый трансля тором , может изменить формат данных в паке те или использовать иной комплект низкоуровне вых протоколов для передачи данных из одн ого домена в другой . Например , потенциальный получатель может оказаться не в состоянии обрабатывать высо к оскоростной видеос игнал , используемый другими участниками сеанса . Транслятор конвертирует видео в формат бол ее низкого качества , требующий не такой вы сокой скорости передачи данных. Протокол RTP используется только для передач и пользовательских данных - об ычно многоад ресной - всем участникам сеанса . Отдельный прот окол управления передачей в реальном времени (Real-Time Transport Control Protocol, RTCP) работает с несколькими адресатами для обеспечения обратной связи с отправите лями данных RTP и другими учас т никам и сеанса. RTCP использует тот же самый базовый т ранспортный протокол , что и RTP (обычно UDP), но д ругой номер порта . Каждый участник сеанса периодически посылает RTCP-пакет всем остальным участникам сеанса . RFC 1889 описывает три функции , вы полняемые RTCP. Первая функция состоит в обеспечении качества услуг и обратной связи в случае перегрузки . Так как RTCP-пакеты являются мно гоадресными , все участники сеанса могут оцени ть , насколько хороши работа и прием других участников . Сообщения отправителя позвол яют получателям оценить скорость данных и качество передачи . Сообщения получателей содерж ат информацию о проблемах , с которыми они сталкиваются , включая утерю пакетов и изб ыточную неравномерность передачи . Например , скорос ть передачи для аудио /видеоприлож е ния может быть снижена , если линия не обеспечивает желаемого качества услуг п ри данной скорости передачи. Обратная связь с получателями важна т акже для диагностирования ошибок при распрост ранении . Анализируя сообщения всех участников сеанса , администратор сети может определить , касается данная проблема одного участника или носит общий характер. Вторая основная функция RTCP - идентификация о тправителя . Пакеты RTCP содержат стандартное текстово е описание отправителя . Они предоставляют бол ьше информации об отп равителе пакетов данных , чем случайным образом выбранный иде нтификатор источника синхронизации . Кроме того , они помогают пользователю идентифицировать пот оки , относящиеся к различным сеансам . Например , они дают пользователю возможность определит ь , что одн о временно открыты отдель ные сеансы для аудио и видео. Третья функция состоит в оценке разме ров сеанса и масштабировании . Для обеспечения качества услуг и обратной связи с це лью управления загруженностью , а также с ц елью идентификации отправителя , все участн ики периодически посылают пакеты RTCP. Частот а передачи этих пакетов снижается с росто м числа участников. При небольшом числе участников один п акет RTCP посылается максимум каждые 5 секунд . RFC 1889 о писывает алгоритм , согласно которому участники ограничив ают частоту RTCP-пакетов в зависи мости от общего числа участников . Цель сос тоит в том , чтобы трафик RTCP не превышал 5% от общего трафика сеанса. Назначение любой сети состоит в доста вке данных получателем с гарантированным каче ством услуг , включающих проп ускную способ ность , задержку и допустимый предел вариации задержки . С ростом числа пользователей и приложений обеспечить качество услуг станови тся все труднее Просто реагировать на перегрузку уже недостаточно . Необходим инструмент , с помощью которого пере грузок можно было бы изб ежать вообще , т . е . сделать так , чтобы п риложения могли резервировать сетевые ресурсы в соответствии с требуемым качеством услуг. Превентивные меры полезны как при одн оадресной , так и при многоадресной передаче . При одноадресной пер едаче два приложен ия договариваются о конкретном уровне качеств а услуг для данного сеанса . Если сеть сильно загружена , то она может оказаться н е в состоянии предоставить услуги необходимог о качества . В этом случае приложениям прид ется отложить сеанс до лу ч ших времен или попробовать снизить требования к качеству услуг , если это возможно. Решение в данном случае состоит в резервировании одноадресными приложениями ресурсов для обеспечения требуемого уровня услуг . Тогда маршрутизаторы на предполагаемом пути в ыд еляют ресурсы , например место в очер еди и часть емкости исходящей линии . Если маршрутизатор не имеет возможности выделить ресурсы вследствие ранее взятых на себя обязательств , то он извещает об этом приложение . В этом случае приложение может попытаться ин и циировать другой сеа нс с меньшими требованиями к качеству усл уг или перенести его на более поздний срок. Многоадресная рассылка ставит гораздо бол ее сложные задачи по резервированию ресурсов . Она ведет к генерации огромных объемов сетевого трафика в случае , например , таких приложений , как видео , или большой и рассредоточенной группы получателей . Однако трафик от источника многоадресной рассылки может быть в принципе значительно снижен. Для этого есть два основания . Во-первы х , некоторые члены группы могут не н уждаться в доставке данных от конкретного источника в определенный период времени . На пример , члены одной группы могут получать информацию одновременно по двум каналам (от двух источников ), но при этом получатель может быть заинтересован в приеме только о дного канала. Многоадресный трафик можно снизить и вследствие того , что некоторые члены группы в состоянии обрабатывать только часть пере даваемой отправителем информации . Например , видеоп оток может состоять из двух компонентов : о дин с низким качеством карт инки , а другой - с высоким . Такой формат имеет ря д алгоритмов сжатия видео : они генерируют базовый компонент с картинкой низкого качеств а и дополнительный компонент с повышенным разрешением. Некоторые получатели могут не иметь д остаточной вычислительной мо щи для обрабо тки компонентов с высоким разрешением или быть подключены к сети через подсеть и ли канал , не имеющие достаточной емкости , чтобы пропустить полный сигнал. Резервирование ресурсов позволяет маршрутиза торам заранее определить , в состоянии ли о ни осуществить доставку многоадресного траф ика всем получателям. В предыдущих попытках реализации резервир ования ресурсов и в принятых во frame relay и ATM подходах необходимые ресурсы запрашивает источн ик потока данных . Этот метод достаточен в случае одноадр есной передачи , потому что передающее приложение передает данные в определенном темпе , а необходимы уровень качества услуг заложен в схему передачи. Однако такой подход нельзя использовать для многоадресной рассылки . У разных член ов группы могут быть неоди наковые тре бования к ресурсам . Если исходный поток мо жет быть разделен на подпотоки , то некотор ые члены группы , вполне возможно , пожелают получать только один из них . Например , нек оторые получатели могут быть в состоянии обрабатывать только компонент виде о си гнала низкого разрешения . Или если несколько отправителей вещают на одну группу , то получатель может выбрать только одного отп равителя или некоторое их подмножество . Након ец , требования различных получателей к качест ву услуг могут меняться в зависимости от оборудования вывода , мощности процессо ра и скорости канала. По этой причине резервирование ресурсов получателем представляется предпочтительным . Отп равители могут предоставить маршрутизаторам общи е характеристики трафика (например , темп перед ачи данных и вариабельность ), но получате ли должны сами определить требуемый уровень качества услуг . Маршрутизаторы сводят затем воедино запросы на выделение ресурсов на общих участках дерева распространения. В основе RSVP лежат три концепции , касающ иеся потоков данн ых : сеанс , спецификация потока и спецификация фильтра . Сеанс - это поток данных , идентифицируемый по адресату . Отметим , что эта концепция отличается от к онцепции сеанса RTP, хотя сеансы RSVP и RTP могут и меть взаимооднозначное соответствие . После резерв ир о вания маршрутизатором ресурсов для конкретного адресата он рассматривает это как начало сеанса и выделяет ресурсы н а время этого сеанса. Запрос на резервирование от конечной системы-получателя , называемый описателем потока , с остоит из спецификаций потока и фильтра . Спецификация потока определяет требуемое ка чество услуг и используется узлом для зад ания параметров планировщика пакетов . Маршрутизат ор передает пакеты с заданным набором пре дпочтений , опираясь на текущую спецификацию п отока. Спецификация фильтра определяет набор пакетов , под которые запрашиваются ресурсы . Вместе с сеансом она определяет набор пак етов (или поток ), для которых требуемое кач ество услуг должно быть обеспечено . Любые другие пакеты , направляемые этому адресату , об рабатываются постольк у , поскольку сеть в состоянии это сделать. RSVP не определяет содержание спецификации потока , он просто передает запрос . Специфика ция потока включает обычно класс услуг , Rspec (R означает резерв ) и Tspec (Т означает трафик ). Два других параметра представляю т собой набор чисел . Параметр Rspec определяет требуемое качество услуг , а параметр Tspec описывает по ток данных . Содержимое Rspec и Tspec прозрачно для RSVP В принципе спецификация фильтра описывает произвольное подмножество пакетов одного сеа нса (т . е . пакетов , адресат которых оп ределяется данным сеансом ). Например , спецификация фильтра может определять только конкретных отправителей или протоколы либо пакеты , п оля протокольных заголовков которых совпадают с заданными. С точки зрения хоста работа протоко ла состоит из следующих этапов (первые два этапа в этой последовательности имею т иногда обратную очередность ) 1. Получатель вступает в группу многоадре сной рассылки посредством отправки сообщения по протоколу IGMP соседнему маршрутизатору . 2. Потенциальн ый отправитель отправляет сообщение по адресу группы . 3. Получатель принимает сообщение Path, идентифиц ирующее отправителя . 4. Теперь , когда получатель имеет информа цию об обратном пути , он может отправлять сообщения Resv с дескрипторами потока . 5. Сооб щения Resv передаются по сети отправителю . 6. Отправитель начинает передачу данных . 7. Получатель начинает прием пакетов данн ых . Механизм установка соединения с резервиро ванием полосы пропускания. Процедура установки соединения с резервир ованием полосы пропускания проходит следующ им образом : Конечный пользователь , заинтересованный в передаче чувствительного к задержкам трафика , передает в сеть сообщение с указанием ин формации о данных , которые он собирается п ередавать (сюда включается IP адрес источника и номер UDP/TCP порта ),а так же информац ию о типе трафика. Эта информация применяется при настройке механизмов управления потоком данных в п ромежуточных узлах сети для осуществления рез ервирования полосы пропускания , а так же д ля предотвращения избыточного резервирования ресурсов для данного типа трафика. При прохождении по сети этот информац ионный пакет “запоминает” маршрут по которому он дошел до получателя. При получении информационного пакета прие мник анализирует его содержание и , в случа е своей заинтер есованности в данной и нформации , передает в сеть запрос на резер вирование полосы пропускания. Данный запрос , описывающий необходимый ти п сервиса и сетевого соединения , передается по сети от приемника к передатчику по тому же маршруту , что и информационный пакет. Каждый промежуточный узел сети проводит анализ полученного запроса на основании описанных ниже правил . При получении запроса на установку со единения с резервированием ресурса в узле сети включаются два механизма : контроллер р есурсов канала , определ яющий наличие запр ашиваемого ресурса и контроллер доступа , свер яющий права данного пользователя с полученным запросом. Если при отработке обоих механизмов б ыл получен положительный результат , то резерв ирование , в данном узле , считается установленн ым и соот ветствующая информация передаетс я в модули , отвечающие за классификацию по токов и формирование выходных очередей. Если же хотя бы один из механизмо в возвращает отрицательный результат , то прот окол информирует источник запроса о невозможн ости его осуществле ния. Обработка запроса на установление соедине ния с резервированием ресурса проходит по отдельности для каждого типа сетевого соед инения так как протокол RSVP способен различать типы соединения. Тип сетевого соединения определяется трем я параметрами : IP ад рес получателя , тип п ротокола и тип порта назначения. Если полученный запрос удовлетворяет всем требованиям , то узел производит резервирован ие необходимой полосы пропускания и передает запрос дальше , в направлении к передатчик у. Как только передатчик получ ает за прос на резервирование полосы пропускания от приемника соединение считается установленным и начинается обмен информацией. Во время сеанса связи приемник и передатчик периодически подтверждают дальнейшую необходимость в осуществлении резервирования по лосы пропускания путем посылки информацио нных пакетов передатчиком и запросов на р езервирование приемником. Узел сети в праве прекратить резервир ование полосы пропускания как только он н е получает очередного подтверждения от приемн ика или передатчика . Рез ервирование полосы пропускания так же может быть прекращено после передачи приемником или передатчиком запроса на о тмену соединения. Качество услуг . Качество услуг (QoS) - это ключевая фраза для обозначения сетей передачи дан ных без потери ячеек с предск азуемой задержкой из конца в конец и доставк ой в реальном времени после установления соединения . Высококачественное мультимедиа в сети как в реальном времени , так и при воспроизведении аудио - и видеофайлов с серв ера предполагает наличие сети с обеспечение м качества услуг . Такие протоколы , как ATM, разрабатывались специально для предостав ления нескольких уровней услуг . Обеспечение к ачества услуг в случае IP возможно только п ри использовании специальных протоколов , таких как RSVP, для резервирования пропускн о й способности на промежуточных устройствах (ма ршрутизаторах ). Компьютерная телефония. Термин “компьютерная телефония ” (Computer-Telephony Integration, CTI) относится к реализации традиционных аудио - (иногда и видео -) сервисов в сети передачи данных . Сист емы компьютерной телефонии могут быть реализованы как в сетях с гарантированной пропускной способностью (типа ATM), так и в сетях передачи кадров (типа Ethernet или frame relay). CIF. Общий промежуточный формат (Common Intermediate Format) с разрешением 352 пиксела по горизонтали на 288 пикселов по вертикали является наиболее популярным форматом изображе ний в видеоконференциях . При меньшей пропускн ой способности видеосистемы используют , как п равило , либо QCIF (Quarter CIF) с разрешением 176х 144 пиксела , л ибо SQCIF (Sub-Quarter CIF) с разрешением 128х 96 пиксе лов . Видео с высокой пропускной способностью описывается форматом 4CIF (704х 576 пикселов ) или 16CIF (1408х 1152 пиксела ). G.711. Один из основных стандартов ITU-T для аудиокоде ков (кодировщиков-декодир овщиков голоса и музыки ). G.711 является частью более общих мультиме дийных стандартов , таких как H.320 и H.323, кроме т ого , он используется в компьютерной телефонии и сам по себе . G.711 определяет аудиосигнал с шириной полосы 3,4 КГц (иными словами , об ычн ы й аналоговый голосовой сигнал ) по информационным каналам в 64 Кбит /с . Ст андарт G.722 описывает аудиопоток с шириной полос ы 7,0 КГц по каналу в 64 Кбит /с , а стан дарт G.728 - аудиопоток с шириной полосы 3,4 КГц п о каналу в 16 Кбит /с . Стандарт G.723 определя е т передачу компьютерной аудиоинформа ции по узкополостным телефонным линиям . Он описывает уплотненный сигнал в 3,4 КГц для обычных телефонных линий и используется в мультимедийном стандарте H.324. H.233. Стандарт шифровани я данных ITU-T для мультимедийной информации реального времени . H.233 поддерживается целым рядом стандартных служб , в том числе H.320, H.323 и H.324. Стандарт H.234 определяет , каким образом обрабатываю тся ключи шифрования . H.261. Стандарт ITU-T на к одек со сжатием видео . Поддерживаемый H.320, H.323 и H.324, H.261 совместим с форматами изображений CIF и QCIF. H.261 разрабатывался для использования с ISDN и допускает скорости передачи данных , кратные 64 Кбит /с . Новый стандарт H.263 (поддерживаемый H.324) п овышает эффективность H.261 и сов м естим с изображениями в форматах SQCIF, 4CIF, 16CIF. H.320. Один из основн ых стандартов ITU-T для мультимедиа в реальном времени . H.320 - это стандарт для видеоконференций в узкополосных глобальных сетях с коммутац ией каналов , таких как ISDN. Он включает спецификации для данных (T.120), голоса (G.711 и G.728), видео (H.261) и шифрования (H.233 и H.234). H.323 представляет собой усовершенствованный стандарт H.320 для основных се тей с коммутацией пакетов . Родственные станда рты для мультимедиа реального врем е ни , не рассматриваемые отдельно в этом словаре , включают H.321 для широкополосного ISDN и ATM, H.322 для сетей коммутации пакетов с гарантир ованной полосой пропускания и H.310 для мультимед иа высокого разрешения поверх ATM. H.323. В настоящее вре мя шлюзы и клиентское программное обесп ечение являются по большей части нестандартны ми . Если оба компонента не представлены од ной компанией , то , скорее всего , вы не сможете использовать IP-телефонию для звонка др угому абоненту. Здесь приходит на помощь стандарт Н .323, определяющий передачу видео и аудио по сетям с негарантированным качеством усл уг , таким как Ethernet и IP.Н .323 описывает несколько элементов , в том числе аудио - и видеок одеки (кодеры /декодеры ), коммуникационные протоколы и синхронизацию пакетов . Пе р вонач ально стандарт разрабатывался для рынка видео конференций в качестве альтернативы сеансов п о ISDN, но теперь сообщество IP-телефонии адаптиров ало стандарт для своих собственных нужд. Но из-за того , что Н .323 разрабатывался для видеоконференций , далеко не всякий шлюз и клиент IP-телефонии поддерживает стан дарт . Тем не менее эта ситуация постепенно меняется , так как число производителей , в ысказывающихся в пользу стандартов и работающ их над их оптимизацией для IP-телефонии , неу клонно растет . Среди компани й , заявивши х о поддержке Н .323, - VocalTec, Clarent, Dialogic, Array Telecom, Micom, Microsoft, Intel, Brooktrout. В сентябре 1997 года на конфере нции "Голос по сети " в Бостоне производите ли из всех областей рынка IP-телефонии приняли участие в крупнейшей публич ной демонстрации интероперабельности Н .323. H.324. Стандарт ITU-T для передачи мультимедиа в реальном времени по обычным телефонным линиям с помощью модемо в V.34 на 28,8 Кбит /с или более быстрых . Подо бно H.320, H.324 включает стандарт T.120 для разд еления данных , сжатие видео по стандарту H.261, а также стандарты шифрования H.233 и H.234. В отличие от H.320, H.324 использует аудиостандарт G.723. MMX. По утверждению Intel, акроним “ MMX” не имеет какого-либо конкре тного значения , но обычно он расшифр ов ывается как “Мультимедийные расширения” . Более конкретно MMX реализуется как набор новых ком анд для микропроцессоров Pentium с MMX и Pentium II. Однако MMX занимается не только Intel: так , например , компа ния Advanced Micro Devices, конкурирующий произво д итель процессоров , выпустила новое MMX-совместимое семей ство процессоров . Многие новые мультимедийные продукты под Windows для компьютерной телефонии и видеоконференций пишутся с учетом преимущест в новых команд MMX. RTP. Транспортный прото кол реального в ремени - это стандарт IETF для передачи данных , таких как голос или видео , в реальном времени по пакетной сети , не гарантирующей качества услуг . Связа нный с ним стандарт - протокол управления передачей в реальном времени (Real-Time Transport Control Proto c ol, RTCP) – обеспечивает обратную связь между двумя устройствами или группой . Такие мул ьтимедийные стандарты ITU-T для сетей без обеспеч ения качества услуг , как H.323 и H.324, опираются н а RTP/RTCP. T.120. Этот стандарт ITU-T касается разделения мультиме дийных данных по сети в реальном времени . Он служит базисом для таких приложений , как совмест ная работа над проектами при двусторонних или многосторонних сеансах . T.120 является составно й частью некоторых стандартов видеоконференций , например H.320, H.323 и H.324. РЕЗЮМЕ. Вчерашние методы работы с большими об ъемами трафика совершенно непригодны для совр еменных систем . Удовлетворить растущим требования м к передаче данных в связи с ростом их объема , распространением приложений реаль ного времени и многоадресн ой рассылки без новых инструментов невозможно . RTP и RSVP обес печивают надежный фундамент для сетей следующ его поколения.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Если вся фигня что сейчас происходит – это перформанс по поводу столетия начала первой мировой, то оччень интересно, что за шоу ожидает нас в 17-м году?...
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по компьютерным сетям "Методы управления трафиком", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru