22ticket
1. Понятия сетевого шлюза, маршрутизатора, прокси-сервера и межсетевого экрана. Программная и аппаратная реализация сетевых шлюзов.
Конвертирует протоколы одного типа физической среды в протоколы другой физической среды (сети). Например, при соединении локального компьютера с сетью Интернет обычно используется сетевой шлюз. Сетевые шлюзы работают на всех известных операционных системах. Основная задача сетевого шлюза — конвертировать протокол между сетями. Роутер сам по себе принимает, проводит и отправляет пакеты только среди сетей, использующих одинаковые протоколы. Сетевой шлюз может с одной стороны принять пакет, сформатированный под один протокол (например Apple Talk) и конвертировать в пакет другого протокола (например TCP/IP) перед отправкой в другой сегмент сети. Сетевые шлюзы могут быть аппаратным решением, программным обеспечением или тем и другим вместе, но обычно это программное обеспечение, установленное на роутер или компьютер. Сетевой шлюз должен понимать все протоколы, используемые роутером. Обычно сетевые шлюзы работают медленнее, чем сетевые мосты, коммутаторы и обычные маршрутизаторы. Сетевой шлюз — это точка сети, которая служит выходом в другую сеть. В сети Интернет узлом или конечной точкой может быть или сетевой шлюз, или хост. Интернет-пользователи и компьютеры, которые доставляют веб-страницы пользователям — это хосты, а узлы между различными сетями — это сетевые шлюзы. Например, сервер, контролирующий трафик между локальной сетью компании и сетью Интернет — это сетевой шлюз. В крупных сетях сервер, работающий как сетевой шлюз, обычно интегрирован с прокси-сервером и межсетевым экраном. Сетевой шлюз часто объединен с роутером, который управляет распределением и конвертацией пакетов в сети.
Проф. жарг. рýтер или роутер транслитерация от англ. router /ˈɹu:tə(ɹ)/ или /ˈɹaʊtəɹ/[1], /ˈɹaʊtɚ/) — специализированный компьютер, который пересылает пакеты между различными сегментами сети на основе правил и таблиц маршрутизации[2]. Маршрутизатор может связывать разнородные сети различных архитектур. Для принятия решений о пересылке пакетов используется информация о топологии сети и определённые правила, заданные администратором. Маршрутизаторы работают на «сетевом» (третьем) уровне сетевой модели OSI, в отличие от коммутаторов (свитчей) и концентраторов (хабов), которые работают соответственно на втором и первом уровнях модели OSI. Обычно маршрутизатор использует адрес получателя, указанный в заголовке пакета, и определяет по таблице маршрутизации путь, по которому следует передать данные. Если в таблице маршрутизации для адреса нет описанного маршрута — пакет отбрасывается. Существуют и другие способы определения маршрута пересылки пакетов, когда, например, используется адрес отправителя, используемые протоколы верхних уровней и другая информация, содержащаяся в заголовках пакетов сетевого уровня. Нередко маршрутизаторы могут осуществлять трансляцию адресов отправителя и получателя, фильтрацию транзитного потока данных на основе определённых правил с целью ограничения доступа, шифрование/расшифровывание передаваемых данных.
От англ. proxy — представитель, уполномоченный; часто просто прокси, сервер-посредник) — промежуточный сервер (комплекс программ) в компьютерных сетях, выполняющий роль посредника между пользователем и целевым сервером (при этом о посредничестве могут как знать, так и не знать обе стороны), позволяющий клиентам как выполнять косвенные запросы (принимая и передавая их через прокси-сервер) к другим сетевым службам, так и получать ответы. Сначала клиент подключается к прокси-серверу и запрашивает какой-либо ресурс (например e-mail), расположенный на другом сервере. Затем прокси-сервер либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша (в случаях, если прокси имеет свой кэш). В некоторых случаях запрос клиента или ответ сервера может быть изменён прокси-сервером в определённых целях. Прокси-сервер позволяет защищать компьютер клиента от некоторых сетевых атак и помогает сохранять анонимность клиента, но также может использоваться мошенниками для скрытия адреса сайта, уличённого в мошенничестве, изменения содержимого целевого сайта (подмена), а также перехвата запросов самого пользователя. Чаще всего прокси-серверы применяются для следующих целей: обеспечение доступа компьютеров локальной сети к сети Интернет; кэширование данных: если часто происходят обращения к одним и тем же внешним ресурсам для снижения нагрузки на канал во внешнюю сеть и ускорения получения клиентом запрошенной информации; сжатие данных: прокси-сервер загружает информацию из Интернета и передаёт информацию конечному пользователю в сжатом виде для экономии внешнего сетевого трафика клиента или внутреннего — организации
Программный или программно-аппаратный элемент компьютерной сети, осуществляющий контроль и фильтрацию проходящего через него сетевого трафика в соответствии с заданными правилами.
Как уже было упомянуто в начале статьи все системы IP- телефонии условно можно разделить на базовых схемы: для пользователей персональных компьютеров и пользователей телефонной сети (осуществляющих связь через интернет без использования компьютера.) Для первой схемы мы можем говорить о двух вариантах реализации: программном (когда все процедуры делает персональный компьютер со встроенной звуковой картой), и программно-аппаратном (когда в компьютер устанавливается специализированная DSP карта, выполняющая основные функции и разгружая тем самым компьютер для другой работы). Первый вариант нашел воплощение в значительном множестве программных продуктов, выпускаемых различными фирмами. Среди них наиболее распространен известный продукт Net Meeting фирмы Microsoft. Второй вариант также в настоящее время достаточно широко распространен. Для второй схемы можно говорить только об аппаратно-программной реализации, когда в систему входит набор специализированных DSP карт или модулей, работающих, как правило, под управлением некоторого модуля центрального процессора (CPU). Первые продукты такого рода появились примерно 1.5 -2 года тому назад и были реализованы на основе плат фирмы Dialogic (мирового лидера в области компьютерной телефонии) и программного обеспечения, разработанного фирмой VocalTech (пионера в области Интернет-телефонии). Шлюз назывался VocalTech Gateway и коммерчески доступен в настоящее время. Подобный продукт V/IP был создан фирмой Micom и также представляет собой DSP плату в конструктиве IBM-PС, работающую под управлением специального ПО. Подобные способы построения шлюзов достаточны удобны для офисных и возможно (в некоторых случаях) для корпоративных применений, но для крупных интернет-провайдеров и телекоммуникационных компаний, которым необходима установка многоканальных систем, такая реализация малопригодна из-за ненадежности функционирования и сложности обеспечения большого числа каналов. Задачи повышения надежности и обеспечения многоканальности должны решаться при разработке аппаратного обеспечения шлюза с учетом ограничения удельной стоимости на канал. Современное развитие элементной базы и стандартизации в области промышленных компьютеров (в том числе с конкретными особенностями для телекоммуникаций) позволяют достаточно эффективно решать эти задачи. Основной компонент для реализации аппаратного обеспечения шлюзов - это цифровые процессоры обработки сигналов (DSP). В последние годы наблюдается необычайно бурный рост номенклатуры приборов, их производительности, расширение функциональных свойств чипов. Особо следует отметить появление DSP, специально предназначенных для многоканальной обработки, что существенно снижает удельную стоимость оборудования. Первым и наиболее мощным DSP этого класса является TMS320C6201 фирмы Texas Instruments с производительностью до 1600 MIPs, на котором возможна реализация 16 и более голосовых каналов через IP. В гонку за лидером включилась компания Analog Devices, анонсировавшая недавно свой 600 MIPs DSP с плавающей точкой ADSP21160, который несмотря на некоторый проигрыш по производительности имеет свои больший объем внутренней памяти и улучшенную архитектуру.
Что бы не столкнутся с проблемами и ошибками слияния и обновления на веб-серверах применяют системы управления версиями, которые облегчат распределенную разработку сайта в романе «Шантарам» Грегори Робертс писал, что зло бывает порождено стараниями людей изменить что-то к лучшему. При попытке улучшить web ресурс таким злом является возникновение регрессивных ошибок. Обычнок разработчики используют какое-то ПО с функциями публикации и резервного копирования, не задумываясь о контроле обновлений версий. Но иногда, потрудившись над сложной доработкой, он видит, что его чудо скрипт затерт файлом коллеги, который не посмотрел на дату изменений.
(Version Control System, VCS) системы управления версиями используются для контроля изменений и возможности создания нескольких версий разрабатываемого проекта. Во время распределенной разработки они помогают систематизировать работу с несколькими версиями одних и тех же документов. Все изменения в проекте размещаются в структурированном хранилище (репозитории), с помощью которго взаимодействуют разработчики. Репозиторий содержит служебные файлы проекта – это проиндексированные и шифрованные изменения. Кроме того содержит рабочую версию проектов. Благодаря этому все разработчики могут получать различные версии документов из репозитория, создавать свою ветку изменений, фиксировать изменения (создавать ревизию), а также откатывать рабочую копию к любой предыдущей версии. Данный метод позволяет обеспечить синхронизацию обновлений.
Стандартная схема поддержки веб-проекта выглядит следующим образом: разработчики вносят изменения на web-сервер сайта, который в свою очередь просматривают пользователи. Если несколько разработчиков изменяют один и тот же документ, то первое изменения будет стерто вторым, и пользователь получит некорректную информацию. Потребуется найти предыдущие версии, чтобы откатить проект, и выяснить причину получившегося несоответствия.
- Исключение конфликта слияния изменений. Благодаря синхронизации хранилищ не требуются специальные правила для выполнения обновлений.
- Распределенная разработка. Система управления версиями позволяет использовать ветвление, то есть создание различных вариантов документа с общей историей изменений до точки ветвления и с разными после нее. Когда ветвь достигает стабильности, происходит слияние. Параллельное выполнение нескольких задач является особенно актуальным для современной веб-разработки, так как обычно при создании и поддержке проекта точное планирование невозможно.
- Сохранение истории изменений. Так как основная информация об обновлениях фиксируется, и при необходимости имеется возможность одной командой восстановить любую из предыдущих версий документа.
- Простота управления исходным кодом. Средства системы позволяют сравнивать версии файлов построчно, контролируя их изменения.
- Простота интеграции. Данную систему можно применить к запущенному сайту без закрытия на обслуживание и перемещение файлов.
- Бесплатное программное обеспечение. Большинство систем управления версиями является свободно распространяемыми
Git была создана для того, чтобы тысячи разработчиков, находящихся в различных точках земного шара и обладающих разного качества подключением к Интернет, могли совместно работать над одним проектом, не сталкиваясь с серьезными проблемами производительности или доступа. Эти фундаментальные требования поддерживаются в Git благодаря следующим важным аспектам: Использование центрального репозитория с одновременным предоставлением каждому разработчику полной копии исходного кода проекта. Это гарантирует, что все разработчики могут выполнить свою работу независимо от текущего состояния своего соединения. Обеспечение быстрой и надежной поддержки создания внутри проекта отдельных рабочих пространств, называемых ветвями, и слияний, т.е. распространения изменений из одной ветви проекта в другие. Ветви облегчают поддержку различных версий пакета, независимо от того, являются ли эти версии постоянными или же они созданы для экспериментов. Слияния являются ключевым аспектом всех систем управления версиями, а особое распространение они имеют в VCS, ориентированных на ветви. Реалзация легкого обмена изменениями в ветвях и коде между группами разработчиков без необходимости занесения этих изменений в центральный репозиторий. Эти архитектурные решения и их реализация являются ключевыми аспектами успеха Git и удобства его использования. Конечно же, Git также удовлетворяет стандартным требованиям к VCS по неизменяемости и подотчетности. Неизменяемость означает, что изменения, будучи добавлены в репозиторий, становятся неотъемлемой частью истории проекта. Хотя изменения впоследствии могут быть удалены (так называемый reverting – отмена изменений), тем не менее, и изменения, и удаление этих изменений являются неотъемлемой частью истории проекта. Подотчетность означает, что можно легко отследить, кто и когда внес определенные изменения. Для чего было сделано изменение, может оставаться загадкой (хотя при внесении изменений необходимо заполнять комментарий), но, по крайней мере, всегда можно узнать, кого об этом следует спросить. Git использует внутренний индекс для отслеживания состояния файлов и директорий в репозитории. Также, для облегчения последующих обновлений, она хранит объекты, отражающие сделанные в этих файлах и директориях изменения. Индекс и объекты изменений отличаются от фактических файлов и директорий, представленных в локальном репозитории. Такая модель позволяет легко определять изменения, которые сделаны локально в файлах и директориях, и еще не занесены в локальный репозиторий или удаленный центральный репозиторий (если такой имеется). Некоторые команды Git работают с индексом, в то время как другие работают с фактическим содержимым файлов и директорий, поэтому иногда использование неподходящей команды может привести к непониманию, почему же файлы не обновились.
Репозитории, например такой, какой мы создали выше, содержат рабочую копию всех файлов проекта Git, а также файлы, необходимые Git для отслеживания изменений, ветвей, меток и т.д. По умолчанию, при публикации изменений в репозитории Git, содержащем рабочие копии файлов проекта, происходит только обновление индекса, но не самих файлов проекта. Так сделано потому, что при обновлении файлов могут возникать конфликты слияния изменений, если вы в данный момент работаете с теми же самыми файлами. Чтобы при публикации изменений выполнялось обновление файлов, нужно создать так называемый пустой репозиторий—– т.е. репозиторий, не имеющий рабочей копии ваших файлов, но содержащий индекс Git, объекты, отражающие изменения этого индекса и другие файлы, необходимые Git. Так как пустой репозиторий не содержит рабочей копии ваших файлов, то в нем никто не может работать, и он служит просто точкой сбора изменений, поступающих от всех разработчиков, работающих над проектом.
Git - это мощная, гибкая VCS, которая предоставляет распределенной команде широкие возможности для сотрудничества. Git позволяет вести совместную разработку, в том числе разработку Web-сайтов, Web-приложений и т.д., используя новые подходы. Время, потраченное на понимание ее работы и изучение часто используемых команд, окупится сполна.