Корпоративная сеть – сеть масштаба предприятия, объединяет множество локальных сетей территориально разнесенных на значительные расстояния. Такая сеть обслуживает тысячи пользователей, часто включает множество серверов обеспечивающих разнообразные сетевые службы, реализует связь с внешним миром. От работоспособности вычислительной сети предприятия, зачастую, зависит эффективность функционирования предприятия в целом. В таких условиях к сети предъявляется ряд жестких требований, важнейшими из которых являются требования высокой производительности, отказоустойчивости, хорошей масштабируемости, эффективности администрирования и управления. Указанные требования обеспечиваются соответствующими проектными решениями. Выбор оптимальной топологии сети, создание рациональной схемы адресации, выбор и реализация работы разнообразных программных средств поддерживающих работу сети являются важнейшими проектными задачами, рациональное решение которых обеспечит эффективное функционирование сети, наиболее возможную простоту администрирования и хорошую масштабируемость сети. Фирма S.N.I.T это фирма , которая занимается куплей- продажей и строительством недвижимости. Она имеет множество филиалов во многих городах Туниса. Важнейшая задача фирмы - это обеспечение рынка недвижимости, а так же обмен информацией для пополнения базы данных, между филиалами. Также, нужен учёт количества денег полученных каждым филиалом от заключенных сделок. Эти данные должны поступать в течение дня в главный офис от каждого филиала. Для передачи этих данных и нужно распределенная корпоративная сеть. Так как фирма имеет много клиентов и филиалов, то она без сети не может обеспечить своевременную доставку информации и финансовых проводок в филиалы и, наоборот, из филиалов в главный офис .

2. АНАЛИЗ ПРОБЛЕМЫ ПЕРЕГРУЗОК В КОМПЬЮТЕРНЫХ СЕТЯХ

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

Рисунок 1.1 - Зависимость количества доставленных пакетов от нагрузки сети

Когда число пакетов, посылаемых хостами в сеть, не превышает ее пропускной способности, все они доставляются адресатам (кроме не6ольшого процента поврежденных ошибками передачи). При этом количество доставленных пакетов пропорционально количеству посланных. Однако по мере роста трафика маршрутизаторы перестают успевать обрабатывать все пакеты и начинают их терять. При дальнейшем увеличении числа отправляемых пакетов ситуация продолжает ухудшаться. Когда число пакетов достигает максимального уровня, производительность сети начинает снижаться. При очень высоком уровне трафика производительность сети падает до совсем низкого уровня и практически никакие пакеты не доставляются Перегрузка может быть вызвана несколькими факторами. Если вдруг потоки пакетов начинают прибывать на маршрутизатор сразу по трем или четырем входным линиям и всем им нужна одна и та же выходная линия, то образуется очередь. Когда у маршрутизатора закончится свободная память для буферизации всех прибывающих пакетов, их негде будет сохранять и они начнут теряться. Увеличение объема памяти маршрутизаторов может в какой-то степени помочь, но Нэгл (Nagle) в 1987 году показал, что даже если у маршрутизаторов будет бесконечное количество памяти, ситуация с перегрузкой не улучшится, а, наоборот, ухудшится, так как к тому времени, когда пакеты доберутся до начала очереди, они уже запоздают настолько, что источником будут высланы их дубликаты. Все эти пакеты будут посланы следующему маршрутизатору, еще более увеличивая нагрузку на всем протяжении маршрута к получателю . Многие проблемы, возникающие в сложных системах, таких как компьютерные сети, следует рассматривать с точки зрения теории управления. При таком подходе все решения делятся на две группы: без обратной связи и с обратной связью. Решения без обратной связи заключаются в попытках решить проблему с помощью улучшения дизайна системы, пытаясь, таким образом, в первую очередь предотвратить возникновение самой ситуации перегрузки. Никаких корректирующих действий во время работы системы не предпринимается. К методам управления без обратной связи относятся решения о том, когда разрешать новый трафик, когда отвергать пакеты и какие именно, а также составление расписаний для различных участков сети. Общее в этих решениях то, что они не учитывают текущего состояния сети. Решения с обратной связью, напротив, основываются на учете текущего состояния системы. Этот подход состоит из трех следующих частей:

1. Наблюдения за системой с целью определить, где и когда произойдет перегрузка.

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

3. Принятия необходимых мер при работе системы для устранения перегрузки. При наблюдении за состоянием подсети с целью обнаружения перегрузки могут измеряться различные параметры. Среди них следует выделить следующие: процент пакетов, отвергаемых из-за отсутствия свободного места в буфере; средняя длина очереди; процент пакетов, переданных повторно по причине истекшего времени ожидания подтверждения; среднее время задержки пакетов и среднеквадратичное отклонение задержки пакетов. Во всех случаях увеличивающиеся значения параметров являются сигналами о растущей перегрузке. Второй этап борьбы с перегрузкой состоит в передаче информации о перегрузке от места ее обнаружения туда, где могут быть приняты какие-то меры по ее устранению. Очевидное решение заключается в том, чтобы маршрутизатор, обнаруживший перегрузку, пересылал источнику или источникам трафика пакет с извещением о наличии проблемы. Такие пакеты, конечно, окажут дополнительную нагрузку на сеть как раз в тот момент, когда нагрузку необходимо снизить. Существуют, однако, и другие решения. Например, можно зарезервировать в каждом пакете бит или поле, которые будут заполняться маршрутизаторами при достижении перегрузкой порогового уровня. Таким образом, соседи этого маршрутизатора будут предупреждены о том, что на данном участке сети наблюдается перегрузка. Еще один метод состоит в том, что хосты или маршрутизаторы периодически посылают пробные пакеты, явно спрашивая друг друга о перегрузке. Собранная таким образом информация может затем использоваться для выбора маршрутов в обход участков сети, в которых возникла проблема с перегрузкой. Так, некоторые радиостанции обзавелись вертолетами, летающими над городами и сообщающими слушателям о заторах на дорогах в надежде, что слушающие их водители выберут маршруты для своих пакетов (то есть машин) в обход пробок. Все системы с обратной связью предполагают, что получившие информацию о перегрузке в сети хосты и маршрутизаторы предпримут какие-нибудь действия для устранения перегрузки. Однако в действительности чаще всего информация о перегрузке если и не игнорируется, то только заносится в системный журнал, или в лучшем случае – выдается предупреждение системному администратору. Для принятия оперативных действий с обратной связью необходимо, чтоб все звенья на пути передачи данных согласованно принимали меры по устранению перегрузки. При существующем разнообразии видов оборудования такая возможность практически нереальна. Поэтому чаще всего меры по устранению перегрузок сводятся к увеличению пропускной способности линий связи. Однако эти меры далеко не всегда приводят к положительному эффекту. Например сообщается об измерении FTP-трафика с удивительными результатами.

3. Протокольные средства 2, 3 и 4 уровня для решения проблемы перегрузок:

Стратегия повторной передачи определяет, насколько быстро у отправителя и стекает время ожидания подтверждения и что он передает после того как время ожидания истекло. Отправитель, у которого время ожидания истекает слишком быстро и который повторно посылает все неподтвержденные пакеты с помощью алгоритма возврата на п, окажет более сильную нагрузку на сеть, нежели отправитель, использующий выборочный повтор. Тесно связана с этим стратегия кэширования. Если получатели просто игнорируют все пакеты, приходящие не в том порядке, то все проигнорированные пакеты придется передавать позднее еще раз, что окажет дополнительную нагрузку на сеть. Стратегия подтверждений также влияет на перегрузку. Если каждый пакет немедленно подтверждается получателем, то пакеты с подтверждениями образуют дополнительный трафик. Однако если подтверждения добираются обратно «верхом» на попутном потоке кадров, то количество трафика в сети снижается, зато увеличивается среднее время получения подтверждений, что может, в свою очередь, вызвать увеличение повторно переданных пакетов вследствие истечения времени ожидания подтверждений. Более жесткая схема управления потоком (например, с небольшим размером окна) уменьшает скорость передачи данных и помогает бороться с перегрузкой. Существует также зависимость перегрузки от того, является ли сетевой уровень дейтаграммным или он основан на виртуальных каналах, так как многие алгоритмы борьбы с перегрузкой работают только в подсетях с виртуальным каналами. Политика очередей пакетов и обслуживания определяет количество очередей у каждого маршрутизатора — например, одна общая очередь для всех линий, или по очереди для каждой линии, или какой-нибудь комбинированный вариант. Она также определяет порядок обработки пакетов (например, поочередно или в порядке приоритетов). Политика игнорирования пакетов является правилом, определяющим набор пакетов, подлежащих отвержению, когда не хватает памяти. Хорошо продуманная стратегия может облегчить симптомы перегрузки, тогда как неудачная политика может даже ухудшить ситуацию. Хороший алгоритм выбора маршрута может помочь избежать локальной перегрузки, перераспределяя трафик по всем линиям, тогда как неудачный алгоритм может направить слишком большое количество пакетов по одной линии и вызвать затор. Наконец, управление временем жизни пакетов определяет, как долго пакет может перемещаться по сети, прежде чем он будет проигнорирован очередным маршрутизатором. Если это время слишком велико, то потерянные пакеты могут засорять собою сеть, однако если время жизни пакета слишком мало, то пакеты не будут успевать достичь адресата, что приведет к необходимости повторных передач. На транспортном уровне применяются те же стратегии, что и на уровне передачи данных, но к ним добавляется еще и проблема определения времени ожидания подтверждения, что на транспортном уровне осуществить значительно сложнее, поскольку время пересечения всей сети предсказать значительно сложнее, чем время передачи пакета от какого-либо маршрутизатора до его соседа. Если этот интервал слишком короток, будут высылаться излишние повторные пакеты, а если слишком велик — перегрузка снизится, но увеличится задержка в случае потери пакета. Консервативная схема управления потоком может ограничивать пропускную способность транспортного соединения в ситуации с большими задержками. Получатель мог бы увеличить пропускную способность, оптимистично предоставив кредит на место в буфере, которого у него пока нет. Например, буфер получателя заполнен, но получатель полагает, что сможет освободить в нем место для 1000 байт за время, требующееся для распространения сигнала в оба конца соединения. В этом случае он может немедленно выдать кредит в 1000 байт. Если получатель поспевает за отправителем, то такая схема может позволить увеличить производительность. Однако если отправитель быстрее получателя, некоторые сегменты могут отбрасываться, в результате чего потребуется их повторная передача. В противном случае (при надежной сетевой службе) повторные передачи не нужны (в отсутствие перегрузки объединенной сети), поэтому оптимистическая схема управления потоком усложнит протокол.

4. Перспективные средства 5 уровня для решения этой проблемы

Наиболее популярным протоколом транспортного уровня является протокол ТСР (Transmission Control Protocol — протокол управления передачей). Хотя протокол ТСР доказал свое значение в плане поддержания широкого диапазона распределенных приложений, он не годится для обслуживания распределенных приложений реального времени. Под распределенным приложением реального времени мы подразумеваем приложение, в котором источник генерирует поток данных с постоянной скоростью, а один или несколько получателей должны доставлять данные приложению с той же самой постоянной скоростью. Примеры таких приложений включают аудио- и видеоконференции, передачу видеоданных в реальном времени (не для хранения, а для немедленного воспроизведения), совместно используемую рабочую среду, удаленную медицинскую диагностику, телефонию, управляющие и контролирующие системы, распределенные интерактивные симуляторы, игры и мониторинг реального времени. Существует ряд общих характеристик, служащих основанием для определения общего протокола, которым стал протокол RTP (Real-time Transport Protocol — транспортный протокол реального времени, . Протокол RTP лучше всего подходит для гибкого взаимодействия реального времени. Ему не достает механизмов, необходимых для поддержки жесткого трафика реального времени. Протокол RТР следует принципам архитектуры протоколов. Два ключевых понятия, представленных в этой статье, — это формирование кадров на прикладном уровне и интегрированная многоуровневая обработка. В традиционном транспортном протоколе, таком как ТСР, ответственность за восстановление потерянных при передаче данных выполняется на транспортном уровне прозрачно для прикладного уровня. перечисляются два сценария, в которых восстановление потерянных данных лучше переложить на плечи приложения: а) Приложение в определенных пределах способно выдержать несовершенство доставки и продолжать работу. Это, например, аудио - и видеоприложения реального времени. Для таких приложений, возможно, необходимо информировать источник о качестве доставки, а не требовать повторной передачи данных. Если потеряно слишком много данных, источник, возможно, предпочтет перейти на режим передачи с пониженным качеством, предъявляющим более низкие требования к сети, тем самым увеличивая вероятность доставки. в) Возможно, будет лучше, если повторной передачей данных будет заниматься не транспортный, а прикладной уровень. Это может быть полезно в двух случаях: - передающее приложение может пересчитывать, а не хранить потерянные данные; - вместо того чтобы просто передавать еще раз те же потерянные данные, передающее приложение может послать другие данные, пересмотренные в связи с изменившейся ситуацией, или отправить данные, позволяющие скорректировать последствия потери оригинальных данных. Чтобы позволить приложению управлять функцией повторной передачи, предлагается, чтобы нижние уровни, например уровень представления или транспортный уровень, работали с данными в тех же единицах, в которых с ними работает приложение. Приложение должно разбивать поток данных на модули данных прикладного уровня (Application-level Data Unit ADU), а более низкие уровни должны сохранять границы между ADU-модулями при обработке данных. Прикладной уровень является тем уровнем, на котором имеет смысл исправление ошибок отдельных кадров. Если при передаче потеряна часть ADU-модуля, оставшаяся часть модуля, как правило, оказывается бесполезной для приложения. В таком случае прикладной уровень отбрасывает все прибывающие фрагменты и при необходимости организует повторную передачу всего ADU-модуля. Другой подход к управлению перегрузками на 5 уровне реализуется в идее Интегрированной Многоуровневой Обработки. Кратко рассмотрим его. В типичной многоуровневой архитектуре протоколов, такой как ТСР/IP или OSI, каждый уровень архитектуры содержит подмножество функций, необходимых для обмена данными, кроме того, каждый уровень должен быть логически структурированным в виде отдельных модулей оконечных систем. Таким образом, при передаче блок данных перемещается вниз по уровням и последовательно ими обрабатывается. Такая структура не позволяет программисту выполнять функции параллельно или в порядке, отличном от порядка расположения уровней, что могло бы повысить производительность. Лежащая в основе интегрированной многоуровневой обработки идея, предложенная , заключается в том, что соседние уровни могут быть тесно связаны и программисту должна предоставляться воз¬можность совместного использования функций этих уровней. Идея, заключающаяся в том, что жесткое разбиение протокола на уровни может привести к низкой эффективности, высказывалась многими исследователями. Например описываются результаты изучения проблемы неэффективности удаленного вызова процедур (Remote Procedure Call, RPC) поверх протокола ТСР и предлагается более тесное взаимодействие двух уровней. Исследователи доказывают, что метод интегрированной многоуровневой обработки для эффективной передачи данных предпочтительнее. иллюстрирует способ, которым протокол RТР реализует принцип интегрированной многоуровневой обработки. Протокол RТР предназначен для того, чтобы работать поверх не требующего соединения транспортного протокола, например UDP. Протокол UDP обеспечивает базовую функциональность адресации к портам транспортного уровня. Протокол RТР содержит прочие функции транспортного уровня, такие как установление очередности обработки. Однако протокол RТР сам по себе не полон. Чтобы дополнить его функциональностью прикладного уровня, может использоваться модификация и/или дополнение RTP-заголовков.

5. Проблемы обратных связей в системах с управлением потоком