По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! Сегодня в статье мы ходим рассмотреть различия между двумя системами телефонии от компании Cisco – Cisco Unified Communications Manager (CUCM) и Cisco Unified Communications Manager Express (CUCME или CME).
/p>
CME
Cisco Unified Communications Manager Express является многофункциональным решением начального уровня для IP-телефонии начального уровня. CUCME позволяет малым предприятиям и автономным филиалам внедрять IP-телефонию, голосовую и информационную инфраструктуры на единой платформе для небольших офисов, тем самым оптимизируя сеть и снижая затраты.
Ключевые особенности:
Обработка вызовов и управление устройством - CME действует как устройство управления вызовами все-в-одном. Он обрабатывает передачу сигнальных сообщений конечным точкам, отвечает за маршрутизацию вызовов, завершение вызов и функции вызова
Конфигурация в командной строке или графическом интерфейсе – поскольку Cisco интегрировала CME непосредственно в IOS, можно использовать полную гибкость конфигурации CLI, однако также можно использовать GUI утилиту, такую как Cisco Configuration Professional (CCP)
Служба локального каталога – Маршрутизатор CME может размещать локальную базу данных пользователей, которая может использоваться для аутентификации в сети IP-телефонии (IPT)
Поддержка интеграции компьютерной телефонии (CTI) – CTI позволяет сети IPT интегрироваться с приложениями, запущенными в сети передачи данных. Например, использовать Cisco Unified CallConnector для совершения вызовов непосредственно из списка контактов Microsoft Outlook
Транкинг к другим системам VoIP – хотя CME может работать как автономное решение, непосредственно связанное с PSTN, оно также может интегрироваться с другими развертываниями VoIP. Например, использовать CME для небольшого офиса с 40 пользователями и иметь возможность подключаться непосредственно к сети передачи данных к корпоративной штаб-квартире, поддерживаемой полным сервером Cisco Unified Communications Manager (CUCM)
Прямая интеграция с Cisco Unity Express (CUE) – CUE, которая работает через модуль, установленный на маршрутизаторе Cisco, может предоставлять функции голосовой почты для IP-телефонов.
CUCM
Система Cisco Unified Communications Manager в свою очередь расширяет возможности функций корпоративной телефонии для IP-телефонов, устройства обработки мультимедиа, шлюзов передачи голоса по IP и мультимедийных приложений. Дополнительные сервисы передачи данных, голоса и видео, такие как: унифицированный обмен сообщениями, мультимедийные конференц-связи, совместные контактные центры и интерактивные системы реагирования, взаимодействуют через API.
Ключевые особенности:
Полная поддержка аудио и видеотелефонии – основная функция, предоставляемая Cisco Unified Communications Manager. CUCM поддерживает аудио и видеовызовы для среднего бизнеса корпораций корпоративного класса
Защищенное ядро – современные версии CUCM работают как аплаенс, что означает, что базовая операционная система защищена и недоступна
Резервный серверный кластер – CUCM поддерживает резервные серверы, настроенные как кластер. Возможности кластеризации реплицируют данные базы данных (содержащие статические данные, такие как каталог, номера и план маршрутизации) и информацию в реальном времени (содержащую динамические данные, такие как активные вызовы). Кластеры CUCM могут масштабироваться до 30 000 IP-телефонов (SCCP или SIP в незащищенном режим) или 27 000 IP-телефонов (SCCP или SIP в защищенном режиме)
Управление межкластерными и голосовыми шлюзами – хотя у кластера CUCM есть предел в 30 000 IP-телефонов, можно создать столько кластеров, сколько необходимо и подключать их вместе с помощью межкластерных соединительных линии. В дополнение к использованию межкластерных соединительных транков для вызова вне кластера, CUCM также может подключаться к голосовым шлюзам (таким как маршрутизатор Cisco),которые могут быть соединены с различными сетям голосовой связи (таким как PSTN или старая PBX система)
Встроенная система аварийного восстановления (DRS) – встроенная функция Disaster Recovery System позволяет создавать резервные копии базы данных CUCM (и любых дополнительных файлов, которые необходимы) на сетевом устройстве или через Secure FTP (SFTP)
Поддержка виртуализации VMWare – Начиная с версии 8.0 CUCM поддерживается в среде VMWare ESXi. Это приносит максимум доступности и масштабируемости виртуализации для развертывания CUCM
Поддержка или интеграция службы каталогов – сети VoIP могут использовать учетные записи сетевых пользователей для различных целей (управление телефоном, управление консолью оператора и т. Д.). CUCM имеет возможность быть собственным сервером каталогов для хранения учетных записей пользователей или может интегрироваться в существующую структуру корпоративного каталога (например, Microsoft Active Directory) и извлекать информацию об учетной записи пользователя оттуда.
Итог
Платформа CME CUCM
Аппаратные средства
Маршрутизатор Integrated Services Router (ISR)
Сервер в кластере с ISR в качестве PSTN шлюза
Управление вызовами
Unified Communications Manager Express
Unified Communications Manager
Модель вызовов
Распределенная
Централизованная
Количество площадок
Неограниченно
Неограниченно
Возможность расширения
До 450 пользователей
До 30 000 пользователей в кластере
Управление
Command-Line Interface, Cisco Configuration Professional, Cisco Configuration Professional Express Command-Line Interface, Веб-интерфейс CUCM
Порты
PSTN и голосовые порты могут быть расположены на CME
PSTN и голосовые порты не могут быть расположены на CUCM Необходим голосовой шлюз или CME в этой роли
Поддержка JTAPI/TAPI
Не поддерживает
Поддерживается
Поддержка JTAPI/TAPI
TAPI ограничено. JTAPI не поддерживает
Поддерживается
Кластеризация
Не поддерживается. CME не может быть членом кластера CUCM
Поддерживается до 21 ноды в кластере
CiscoWorks IP Telephony Environment Monitor (ITEM)
Не поддерживается
Поддерживается
У веб-разработчиков, которые используют язык программирования Python, есть широкий выбор веб-фреймворков, которые они могут использовать для создания веб-сайтов. Это дает возможность веб-разработчику выбрать тот фреймворк, который наиболее точно подходит для его задачи и его навыков. Среди множества популярных вариантов чаще всего сравниваются Django и Flask. Вероятно, это из-за того, что у них есть некоторые сходства, но также у них много различий. Каждый фреймворк имеет свои уникальные особенности, поэтому мы можем использовать его в соответствии с требованиями конкретного проекта. Как веб-фреймворк полного цикла, Django больше подходит для разработки больших и сложных веб-приложений, а Flask – это простой и расширяемый фреймворк, который позволяет разрабатывать небольшие веб-приложения. В Django вам понравится его «укомплектованность» и доступ к большему количеству функциональных возможностей.
Вы все еще не уверены, какой фреймворк использовать для веб-разработки? Несмотря на то, что каждая из этих сред имеет свои уникальные особенности, есть также множество факторов, которые следует учитывать при выборе одной из них для своего приложения.
Что такое Django?
Django – это платформа с открытым исходным кодом на основе Python для разработки веб-приложений. Она была создана Адрианом Головати и Саймоном Уиллисоном в 2003 году. Это веб-фреймворк высокого уровня, который был создан для ускорения и повышения эффективности процесса веб-разработки. Django был вдохновлен многими старыми, фреймворками, такими как CherryPy, Zope, Plone и т.д. Django – это бесплатный ресурс с расширенными функциями и повышенной производительностью. Разработчики выбирают Django, поскольку он позволяет использовать его для стандартных функций с ограниченным внешним воздействием систем, протоколов и методов управления.
Django еще называют «фреймворком для нервных людей с дедлайнами», поскольку он способствует быстрой разработке и имеет понятный и практичный дизайн. Гибкая разработка фреймворка направлена исключительно на обеспечение качества, быстроты и эффективности. Django достаточно быстро справляется с некоторыми основными функциями разработки, такими как карты веб-сайта, организация контента, информация о клиенте и многое другое. Он фокусируется на том, чтобы завершить разработку приложения как можно быстрее.
Компании, которые используют Django
Django используют следующие компании-гиганты:
Instagram
Coursera
Mozilla
Pinterest
National Geographic
Spotify
Udemy
Zapier и т.д.
Ключевые особенности: Django
Вот некоторые из ключевых особенностей Django:
Скорость: он безумно быстрый. Безо всяких сомнений, рабочий процесс Django от создания концепции до его завершения происходит очень быстро.
Универсальность: Django – это универсальный фреймворк, позволяющий разработчикам работать на различных платформах, от систем организации информационного наполнения, таких как WordPress и т.д., до социальных сетей, таких как LinkedIn, YouTube и т.д., и новостных сайтов, таких как The New York Times, CNN и т.д.
Адаптируемость: Django адаптируется к различным форматам, таким как JSON, HTML, XML и многим другим.
Масштабируемость: это фреймворк, который обеспечивает масштабируемость (система позволяет вносить изменения и обновления на разных уровнях без особых затрат и усилий, т.е. каждый уровень независим) и обслуживание (структура и код не подвержены дублированию и, следовательно, код можно использовать повторно и поддерживаться должным образом).
Безопасность: Django гарантирует безопасность, используя мощные системы и протоколы аутентификации, чтобы избежать кликджекинга, несанкционированного доступа, кибератак и т.д.
Переносимость: Django – это фреймворк на основе Python, а значит, он является переносимым.
Что такое Flask?
Flask – это микрофреймворк на основе Python, который используют для разработки веб-приложений. Он был представлен Армином Ронахером в 2011 году как пробный метод объединения двух решений – Werkzeug (серверная инфраструктура) и Jinja2 (библиотека шаблонов).
Предполагалось, что это будет тестовый запуск в zip-файле, который в конечном итоге стал не тестовым благодаря хорошему впечатлению от Flask.
Flask классифицируется как микрофреймворк, потому что он не зависит от внешних библиотек при выполнении своих задач. У него есть собственные инструменты, технологии и библиотеки для поддержки функций разработки веб-приложений.
Многие разработчики предпочитают начинать именно с Flask, поскольку он более независимый и гибкий.
Компании, которые используют Flask
Flask используют следующие компании-гиганты:
Netflix
Airbnb
MIT
Reddit
Lyft
Zillow
Mozilla
MailGui и т.д.
Ключевые особенности: Flask
Вот некоторые из ключевых особенностей Flask:
Простота: это достаточно простая структура, так как она не зависит от внешних библиотек. Это дает возможность быстро и просто приступить к процессу веб-разработки сложных веб-приложений.
Независимость: Flask предоставляет разработчику независимый или полный контроль над созданием приложений. Вы можете экспериментировать с архитектурой или библиотеками фреймворка.
Встроенное модульное тестирование: встроенная система модульного тестирования Flask обеспечивает более быструю отладку, надежную разработку и свободу действий.
Безопасные cookie-файлы: безопасный cookie-файл – это атрибут HTTP-запроса, который обеспечивает безопасность каналов и гарантирует, что неавторизированный пользователь не получит доступ к тексту. Flask поддерживает безопасные cookie-файлы.
Совместимость: Flask совместим с новейшими технологиями, такими как машинное обучение, облачные технологии и т.д.
Гибкость и масштабируемость: поддержка шаблонов WSGI, которые обеспечивают гибкость и масштабируемость веб-приложений.
Идет вместе со встроенным сервером и отладчиком.
Простые и адаптируемые конфигурации.
Flask vs Django: разберемся детально
Прочитав подробное описание обоих фреймворков на основе Python, Django и Flask, вы, наверняка, поняли, что у них столько же сходств, сколько и различий.
И теперь для лучшего понимания и выбора фреймворка вам следует посмотреть на прямое сравнение фреймворков, которое подчеркнет разницу между Flask и Django.
Ниже вы можете видеть эту разницу.
Параметр
Django
Flask
Тип фреймворка
Django – это веб-фреймворк полного цикла, который позволяет использовать готовые «укомплектованные» решения.
Flask – это упрощенный фреймворк, который предоставляет множество функций без внешних библиотек и лишних функций.
Принцип работы фреймворка/модели данных
Django следует объектно-ориентированному подходу, который обеспечивает объектно-реляционное сопоставление (связывание баз данных и таблиц с классами).
Flask использует модульный подход, который позволяет работать с внешними библиотеками и программными расширениями.
Макет проекта
Django подходит для многостраничных приложений.
Flask подходит только для одностраничных приложений.
Инструмент начальной загрузки
Django-admin – это встроенный в Django инструмент начальной загрузки, который позволяет создавать веб-приложения без какого-либо внешнего ввода.
Flask идет без встроенного инструмента начальной загрузки.
Поддержка базы данных
Django поддерживает самые популярные системы управления реляционными базами данных, такие как MySQL, Oracle и т.д.
Flask не поддерживает базовую систему управления базами данных и использует SQLAlchemy для обращения к базе данных.
Гибкость
Django менее гибок из-за встроенных функций и инструментов. Разработчики не могут вносить изменения в модули.
Flask – это микрофреймворк с расширяемыми библиотеками, это делает его гибким для разработчиков.
Механизм шаблонов
Django вдохновлен шаблоном Ninja2, но имеет встроенный шаблон представления модели, который упрощает процесс разработки.
Flask использует проект шаблона Ninja2.
Контроль
Разработчики не имеют полного контроля над модулями и функциями Django из-за встроенных библиотек.
Flask позволяет разработчикам полностью контролировать создание приложений без каких-либо зависимостей от внешних библиотек.
Стиль работы
Стиль работы Django – единый.
Стиль работы Flask – множественный.
Отладчик
Django не поддерживает виртуальную отладку.
Flask имеет встроенный отладчик, который позволяет поддерживать виртуальную отладку.
Маршрутизация и представления
Платформа Django поддерживает преобразование URL-адресов в представления через запрос.
Веб-фреймворк Flask позволяет преобразовывать URL-адрес в представление на основе классов при помощи Werkzeug.
Структура
Структура фреймворка Django более стандартная.
Структура веб-фреймворка Flask произвольная.
HTML
Django поддерживает динамические HTML-страницы.
Платформа Flask не поддерживает динамические HTML-страницы.
Лучшая особенности
· Открытый исходный код
· Большое сообщество
· Быстрая разработка
· Легко изучить
· Безопасность
· Подробная документация
· Простота
· Минимум функций
· Полный контроль над процессом разработки
· Открытый исходный код
Применение
Django подходит для высокотехнологичных компаний, таких как Instagram, Udemy, Coursera и т.д.
Flask подходит для компаний и проектов, которые хотят поэкспериментировать с модулями и архитектурой платформы, например, для Netflix, Reddit, Airbnb и т.д.
Django vs Flask: что лучше?
Теперь вы хорошо знакомы с концепциями и различиями между Flask и Django. Каждый из этих фреймворков имеет свои индивидуальные особенности и характеристики, которые отличают их по своим функциональным возможностям и применению.
А теперь, для того, чтобы вы могли выбрать один фреймворк из двух, вам также следует ознакомиться со списками плюсов и минусов каждого из них. Итак, давайте рассмотрим основные плюсы и минусы Django и Flask.
Flask: плюсы и минусы
Плюсы/преимущества
Адаптируется к новейшим технологиям
Независимая структура позволяет экспериментировать с архитектурой и библиотеками
Подходит для небольших проектов
Для простых функций требуется небольшая кодовая база
Обеспечивает масштабируемость для простых приложений
Легко построить быстрый прототип
Функции маршрутизации URL через Werkzeug упрощают процесс
Простая разработка и обслуживание приложений
Простая интеграция с базой данных
Расширяемая и простая базовая система
Производительность фреймворка заключается в его минималистичных функциях
Гибкость и возможность полного контроля доступа
Минусы/недостатки
Процесс разработки MVP (Minimum Viable Product – минимальный рабочий прототип) проходит медленно
Не подходит для больших приложений и проектов
Трудоемкое обслуживание сложных реализаций или системных обновлений
Нет встроенного сайта-администратора для обслуживания моделей, вставки, модификации и удаления записей
Не поддерживает элементарную систему баз данных и не имеет отображения объектных отношений
Нет большого сообщества для поддержки и роста
Нет надлежащего уровня безопасности, нет функции аутентификации пользователя или входа в систему.
Django: плюсы и минусы
Плюсы/преимущества
Процесс настройки и запуска фреймворка прост и быстр
Удобный и простой пользовательский интерфейс для функций административного управления
Встроенная система интернационализации позволяет создавать многоязычные веб-сайты
Встроенное модульное тестирование веб-приложения
Поддержка динамических HTML-страниц
Востребованный фреймворк среди ведущих компаний
Простая и тщательно разработанная документация
Поддерживает полнофункциональный интерфейс администрирования
Максимальная масштабируемость при меньшей стоимости услуг хостинга
Высокозащищённый фреймворк
Используется для ограничения скорость запросов API от одного пользователя
Помогает определить модели для URL-адресов в вашем приложении
Обеспечивает быструю разработку благодаря встроенному проекту шаблонов
Есть определенные перспективы, и они оптимистичны
Минусы/недостатки
Единый стиль работы усложняет некоторые вещи и делает их фиксированными
Необходимо предварительное знание фреймворка
Размер кодовый базы относительно больше
Слишком много функций и слишком высококлассный фреймворк для простого проекта
Основан сугубо на Django ORM
Управление URL через регулярное выражение контроллера усложняет кодовую базу
Заключение
И вот наконец, мы подошли к вопросу, какой же все-таки лучше?
Django vs Flask: первый – это фреймворк с открытым исходным кодом для быстрой разработки, а второй – облегченный фреймворк для стандартных функций. Django и Flask – это фреймворки, написанные на Python. Согласно опросу разработчиков, который был проведен в 2018 году, эти фреймворки считаются одними из самых популярных для веб-разработки.
После прочтения такой подробной информации об этих веб-фреймворках можно легко сделать вывод о том, что каждый из них имеет свои собственные особенные функциональные возможности. А это значит, что должна быть какая-то причина, по которой они оба попали в список самых популярный фреймворков на основе Python в области веб-разработки.
Flask обеспечивает полный контроль и отлично подходит для небольших проектов, требующих свободу действий.
Django более сложный и требует хороших знаний, но он выделяется как один из лучших фреймворков для создания сложных приложений.
Вы можете начать свой путь с фреймворка Flask, а потом освоить сложные инструменты и разработку с помощью Django. Любой веб-разработчик должен знать оба этих фреймворка. Благодаря наличию фундаментальных знаний и понимания питоновских Flask и Django вы можете оказаться на голову выше других кандидатов при приеме на работу.
Так что, вы можете выбрать то, что захотите, но освойте это на профессиональном уровне, поскольку эти фреймворки пользуются спросом (и он только растет) и незаменимы в индустрии веб-разработки.
Часто задаваемые вопросы
В: Flask проще, чем Django?
Да, процесс обучения Flask намного проще, чем Django.
В: Что лучше для новичка – Django или Flask?
Для новичков лучше выбрать Flask. Его легко освоить, и он используется для создания небольших приложений, дающих простор для экспериментов и полный контроль над процессом разработки.
В: Django – это про клиента или про сервер?
Django – это веб-фреймворк полного цикла, который подходит для разработки как серверной, так и клиентской части приложений.
В: Почему Flask предпочтительнее Django?
Встроенные библиотеки, которые идут вместе с Django, не дают разработчикам полного контроля над модулями и функциями, которые он предоставляет. Платформа Flask же дает разработчикам полный контроль над созданием приложений без использования внешних библиотек. У Flask множественный стиль работы. И в настоящее время Django не поддерживает виртуальную отладку.
Почитать лекцию №19 про Connection-oriented protocols и Connectionless протоколы можно тут.
Протоколы передачи данных часто бывают многоуровневыми, причем нижние уровни предоставляют услуги по одному переходу, средний набор уровней предоставляет услуги от конца до конца между двумя устройствами и, возможно, набор уровней предоставляет услуги от конца до конца между двумя приложениями или двумя экземплярами одного приложения. Рисунок 1 иллюстрирует это.
Каждый набор протоколов показан как пара протоколов, потому что, как показано в модели рекурсивной архитектуры Интернета (RINA), рассмотренной в предыдущих лекциях, транспортные протоколы обычно входят в пары, причем каждый протокол в паре выполняет определенные функции. В этой серии лекций будут рассмотрены физические протоколы и протоколы передачи данных, как показано на рисунке 1. В частности, в этой лекции будут рассмотрены два широко используемых протокола для передачи данных "точка-точка" в сетях: Ethernet и WiFi (802.11).
Ethernet
Многие из ранних механизмов, разработанных для того, чтобы позволить нескольким компьютерам совместно использовать один провод, были основаны на проектах, заимствованных из более ориентированных на телефонные технологии. Как правило, они фокусировались на передаче токенов и других более детерминированных схемах для обеспечения того, чтобы два устройства не пытались использовать одну общую электрическую среду одновременно. Ethernet, изобретенный в начале 1970-х Bob Metcalf (который в то время работал в Xerox), разрешал перекрывающиеся разговоры другим способом-с помощью очень простого набора правил для предотвращения большинства перекрывающихся передач, а затем разрешал любые перекрывающиеся передачи путем обнаружения и обратного отсчета.
Первоначальное внимание любого протокола, который взаимодействует с физической средой, будет сосредоточено на мультиплексировании, поскольку до решения этой первой проблемы можно решить лишь несколько других проблем. Поэтому эта лекция будет начинаться с описания мультиплексирующих компонентов Ethernet, а затем рассмотрены другие аспекты работы.
Мультиплексирование
Чтобы понять проблему мультиплексирования, с которой столкнулся Ethernet, когда он был впервые изобретен, рассмотрим следующую проблему: в сети с общим носителем вся общая среда представляет собой единую электрическую цепь (или провод).
Когда один хост передает пакет, каждый другой хост в сети получает сигнал. Это очень похоже на беседу, проводимую на открытом воздухе- звук, передаваемый через общую среду (воздух), слышен каждому слушателю. Нет никакого физического способа ограничить набор слушателей во время процесса передачи.
CSMA/CD
В результате система, получившая название множественного доступа с контролем несущей и обнаружением коллизий (CSMA/CD), работает с использованием набора шагов:
Хост слушает среду, чтобы увидеть, есть ли какие-либо существующие передачи; это часть процесса со стороны оператора связи.
Узнав, что другой передачи нет, хост начнет сериализацию (передача битов сериями) битов кадра в сеть.
Эта часть проста - просто слушать перед передачей. Конечно, передачи двух (или более) хостов могут конфликтовать, как показано на рисунке 2. На рисунке 2:
В момент времени 1 (T1) A начинает передачу кадра на совместно используемый носитель. Для прохождения сигнала от одного конца провода к другому требуется некоторое время - это называется задержкой распространения.
В момент времени 2 (T2) C прослушивает сигнал на проводе и, не обнаружив его, начинает передачу кадра на совместно используемый носитель. В этот момент уже произошла коллизия, поскольку оба A и C передают кадр в один и тот же момент, но ни один из них еще не обнаружил коллизию.
В момент времени 3 (T3) два сигнала фактически сталкиваются в проводе, в результате чего они оба деформируются и, следовательно, не читаются.
Столкновение можно обнаружить в точке А в тот момент, когда сигнал от С достигает точки А, прослушав свой собственный сигнал, передаваемый по проводу. Когда сигнал от С достигнет А, А получит искаженный сигнал, вызванный комбинацией этих двух сигналов (результат столкновения). Это часть обнаружением столкновений (участок СD) работы локальные сети CSMA/CD.
Что должен сделать хост при обнаружении столкновения? В оригинальном конструкции Ethernet хост будет посылать сигнал блокировки достаточно долго, чтобы заставить любой другой хост, подключенный к проводу, обнаружить конфликт и прекратить передачу. Длина сигнала блокировки изначально была установлена таким образом, чтобы сигнал блокировки потреблял, по крайней мере, время, необходимое для передачи кадра максимального размера по проводу по всей длине провода. Почему именно столько времени?
Если при определении времени передачи сигнала помехи использовался более короткий, чем максимальный кадр, то хост со старыми интерфейсами (которые не могут посылать и принимать одновременно) может фактически пропустить весь сигнал помехи при передаче одного большого кадра, что делает сигнал помехи неэффективным.
Важно дать хозяевам, подключенным на самом конце проводов, достаточно времени, чтобы получить сигнал помехи, чтобы они почувствовали столкновение и предприняли следующие шаги.
Как только сигнал помехи получен, каждый хост, подключенный к проводу, установит таймер обратного отсчета, так что каждый из них будет ждать некоторое случайное количество времени, прежде чем пытаться передать снова. Поскольку эти таймеры установлены на случайное число, когда два хоста с кадрами, ожидающими передачи, пытаются выполнить свою следующую передачу, столкновение не должно повториться.
Если каждый хост, подключенный к одному проводу, получает один и тот же сигнал примерно в одно и то же время (учитывая задержку распространения по проводу), как любой конкретный хост может знать, должен ли он на самом деле получать определенный кадр (или, скорее, копировать информацию внутри кадра из провода в локальную память)? Это работа Media Access Control (MAC).
Каждому физическому интерфейсу назначается (как минимум) один MAC-адрес. Каждый кадр Ethernet содержит MAC-адрес источника и назначения; кадр форматируется таким образом, что MAC-адрес назначения принимается раньше любых данных. После того, как весь MAC-адрес назначения получен, хост может решить, следует ли ему продолжать прием пакета или нет. Если адрес назначения совпадает с адресом интерфейса, хост продолжает копировать информацию с провода в память. Если адрес назначения не совпадает с адресом локального интерфейса, хост просто прекращает прием пакета.
А как насчет дубликатов MAC-адресов? Если несколько хостов, подключенных к одному и тому же носителю, имеют один и тот же физический адрес, каждый из них будет получать и потенциально обрабатывать одни и те же кадры. Существуют способы обнаружения повторяющихся MAC-адресов, но они реализуются как часть межслойного обнаружения, а не самого Ethernet;
MAC-адреса будут правильно назначены системным администратором, если они назначены вручную.
MAC-адреса назначаются производителем устройства, поэтому дублирование MAC-адресов исключено, независимо от того, сколько хостов подключено друг к другу.
(Поскольку MAC-адреса обычно перезаписываются на каждом маршрутизаторе, они должны быть уникальными только в сегменте или широковещательном домене. В то время как многие старые системы стремились обеспечить уникальность каждого сегмента или широковещательного домена, это обычно должно быть обеспечено с помощью ручной конфигурации, и поэтому в значительной степени было отказано в пользу попытки предоставить каждому устройству глобальный уникальный MAC-адрес, "вшитый" в чипсете Ethernet при создании.)
Первое решение трудно реализовать в большинстве крупномасштабных сетей- ручная настройка MAC-адресов крайне редка в реальном мире вплоть до ее отсутствия. Второй вариант, по существу, означает, что MAC-адреса должны быть назначены отдельным устройствам, чтобы ни одно из двух устройств в мире не имело одного и того же MAC-адреса. Как такое возможно? Путем назначения MAC-адресов из центрального хранилища, управляемого через организацию стандартов. Рисунок 3 иллюстрирует это.
Рис. 3 Формат адреса MAC-48/EUI-48
MAC-адрес разбит на две части: уникальный идентификатор организации (OUI) и идентификатор сетевого интерфейса. Идентификатор сетевомого интерфейса присваивается заводом-изготовителем микросхем для Ethernet. Компаниям, производящим чипсеты Ethernet, в свою очередь, присваиваются уникальный идентификатор организации Институтом инженеров электротехники и электроники (Institute of Electrical and Electronic Engineers -IEEE). До тех пор, пока организация (или производитель) назначает адреса чипсету с его OUI в первых трех октетах MAC-адреса и не назначает никаким двум устройствам один и тот же идентификатор сетевого интерфейса в последних трех октетах MAC-адреса, никакие два MAC-адреса не должны быть одинаковыми для любого набора микросхем Ethernet.
Два бита в пространстве OUI выделяются, чтобы сигнализировать, был ли MAC-адрес назначен локально (что означает, что назначенный производителем MAC-адрес был переопределен конфигурацией устройства), и предназначен ли MAC-адрес в качестве одного из следующих:
Unicast адрес, означает, что он описывает один интерфейс
Multicast-адрес, означает, что он описывает группу получателей
MAC-адрес состоит из 48 бит- при удалении двух битов пространство MAC-адресов составляет 46 бит, что означает, что оно может описывать 246-или 70,368,744,177,664- адресуемых интерфейсов. Поскольку этого (потенциально) недостаточно, чтобы учесть быстрое количество новых адресуемых устройств, таких как Bluetooth-гарнитуры и датчики, длина MAC-адреса была увеличена до 64 бит для создания MAC-адреса EUI-64, который построен таким же образом, как и более короткий 48-битный MAC-адрес. Эти адреса могут поддерживать 262-или 4,611,686,018,427,387,904-адресуемые интерфейсы.
Конец эпохи CSMA / CD
Модель развертывания Ethernet с разделяемой средой в значительной степени (хотя и не полностью!) заменена в большинстве сетей. Вместо общей среды большинство развертываний Ethernet теперь коммутируются, что означает, что одна электрическая цепь или один провод разбивается на несколько цепей путем подключения каждого устройства к порту на коммутаторе. Рисунок 4 демонстрирует это.
На рисунке 4 каждое устройство подключено к разному набору проводов, каждый из которых оканчивается одним коммутатором. Если сетевые интерфейсы на трех хостах (A, B и C) и сетевые интерфейсы коммутатора могут отправлять или получать в любой момент времени вместо того, чтобы делать и то, и другое, A может отправлять, пока коммутатор тоже отправляет. В этом случае процесс CSMA / CD все равно должен соблюдаться для предотвращения коллизий, даже в сетях, где только два передатчика подключены к одному проводу. Такой режим работы называется полудуплексом.
Однако, если наборы микросхем Ethernet могут одновременно прослушивать и передавать данные для обнаружения коллизий, эту ситуацию можно изменить. Самый простой способ справиться с этим - разместить сигналы приема и передачи на разных физических проводах в наборе проводов, используемых в кабеле Ethernet. Использование разных проводов означает, что передачи от двух подключенных систем не могут конфликтовать, поэтому набор микросхем может передавать и принимать одновременно. Чтобы включить этот режим работы, называемый полнодуплексным, витая пара Ethernet передает сигнал в одном направлении по одной паре проводов, а сигнал в противоположном направлении - по другому набору проводов. В этом случае CSMA / CD больше не нужен (коммутатор должен узнать, какое устройство (хост) подключено к каждому порту, чтобы эта схема работала).
Контроль ошибок
CSMA/CD предназначен для предотвращения одного вида обнаруживаемой ошибки в Ethernet: когда коллизии приводят к искажению кадра. Однако в сигнал могут входить и другие виды ошибок, как и в любой другой электрической или оптической системе. Например, в кабельной системе с витой парой, если скрученные провода слишком сильно "разматываются" при установке коннектора, один провод может передавать свой сигнал другому проводу через магнитные поля, вызывая перекрестные помехи. Когда сигнал проходит по проводу, он может достигать другого конца провода и отражаться обратно по всей длине провода.
Как Ethernet контролирует эти ошибки? Оригинальный стандарт Ethernet включал в себя 32-битную циклическую проверку избыточности (Cyclic Redundancy Check-CRC) в каждом кадре, которая позволяет обнаруживать большой массив ошибок при передаче. Однако на более высоких скоростях и на оптических (а не электрических) транспортных механизмах CRC не обнаруживает достаточно ошибок, чтобы повлиять на работу протокола. Чтобы обеспечить лучший контроль ошибок, более поздние (и более быстрые) стандарты Ethernet включили более надежные механизмы контроля ошибок.
Например, Gigabit Ethernet определяет схему кодирования 8B10B, предназначенную для обеспечения правильной синхронизации часов отправителя и получателя; эта схема также обнаруживает некоторые битовые ошибки. Ten-Gigabit Ethernet часто реализуется аппаратно с помощью Reed-Solomon code Error Correction (EC) и системы кодирования 16B18B, которая обеспечивает прямое исправление ошибок (FEC) и синхронизацию часов с 18% -ными издержками.
Схема кодирования 8B10B пытается обеспечить наличие примерно одинакового количества битов 0 и 1 в потоке данных, что позволяет эффективно использовать лазер и обеспечивает встроенную в сигнал тактовую синхронизацию. Схема работает путем кодирования 8 бит данных (8B) в 10 передаваемых битов по проводу (10B), что означает около 25% накладных расходов на каждый передаваемый символ. Ошибки четности одного бита могут быть обнаружены и исправлены, потому что приемник знает, сколько "0" и "1" должно быть получено.
Маршалинг данных
Ethernet передает данные пакетами и кадрами: пакет состоит из преамбулы, кадра и любой конечной информации. Фрейм содержит заголовок, который состоит из полей фиксированной длины и переносимых данных. На рисунке 5 показан пакет Ethernet.
На рисунке 5 преамбула содержит маркер начала кадра, информацию, которую приемник может использовать для синхронизации своих часов для синхронизации с входящим пакетом, и другую информацию. Адрес назначения записывается сразу после преамбулы, поэтому получатель может быстро решить, копировать этот пакет в память или нет. Адреса, тип протокола и передаваемые данные являются частью кадра. Наконец, любая информация FEC и другие трейлеры добавляются в кадр, чтобы составить последний раздел (ы) пакета.
Поле type представляет особый интерес, поскольку оно предоставляет информацию для следующего уровня-протокола, предоставляющего информацию, переносимую в поле data - для идентификации протокола. Эта информация непрозрачна для Ethernet-чипсет Ethernet не знает, как интерпретировать эту информацию (только где она находится) и как ее переносить. Без этого поля не было бы последовательного способа для передачи переносимых данных в правильный протокол верхнего уровня, или, скорее, для правильного мультиплексирования нескольких протоколов верхнего уровня в кадры Ethernet, а затем правильного демультиплексирования.
Управление потоком
В исходной CSMA / CD реализации Ethernet сама совместно используемая среда предоставляла своего рода базовый механизм управления потоком. Предполагая, что никакие два хоста не могут передавать одновременно, и информация, передаваемая по какому-то протоколу верхнего уровня, должна быть подтверждена или отвечена, по крайней мере, время от времени, передатчик должен периодически делать перерыв, чтобы получить любое подтверждение или ответ. Иногда возникают ситуации, когда эта довольно грубая форма регулирования потока не работает- спецификация Ethernet предполагает, что некоторый протокол более высокого уровня будет контролировать поток информации, чтобы предотвратить сбои в этом случае.
В коммутируемом полнодуплексном Ethernet нет CSMA/CD, так как нет общей среды. Два хоста, подключенные к паре каналов передачи, могут отправлять данные так быстро, как позволяют каналы связи. Фактически это может привести к ситуации, когда хост получает больше данных, чем может обработать. Чтобы решить эту проблему, для Ethernet был разработан фрейм паузы. Когда получатель отправляет фрейм паузы, отправитель должен прекратить отправку трафика в течение определенного периода времени.
Фреймы паузы массово не применяются.
Важно
Многие протоколы не содержат все четыре функции, описанных как часть модели рекурсивной архитектуры Интернета (RINA): контроль ошибок, управление потоком, транспортировка и мультиплексирование. Даже среди тех протоколов, которые реализуют все четыре функции, все четыре не всегда используются. Обычно в этой ситуации разработчик протокола и/или сети передает функцию на более низкий или более высокий уровень в стеке. В некоторых случаях это работает, но вы всегда должны быть осторожны, предполагая, что это будет работать без ошибок. Например, существует разница между hop-by-hop шифрованием и end-to-end шифрованием. End-to-end передача хороша для приложений и протоколов, которые выполняют шифрование, но на самом деле не каждое приложение шифрует передаваемые данные. В этих случаях hop-by-hop шифрование может быть полезно для менее безопасных соединений, таких как беспроводные соединения.