ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 30.07.2025

Просмотров: 1817

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Вопрос № 1

Понятие вычислительной сети.

Классификация сетей эвм.

Локальные и глобальные вычислительные сети (лвс и гвс).

Понятия трафика и пропускной способности

Функции отдельных уровней osi

Вопрос № 3

Физический уровень osi.

Разновидности физических сетевых топологий.

Сравнительный анализ топологий "шина", "звезда", "кольцо".

Вопрос № 4

1. Коаксиальный кабель:

2. Витая пара

3. Оптические линии связи

4. Радиосвязь, инфракрасная связь.

Вопрос № 5

Вопрос № 6

Канальный уровень osi.

Метод доступа к среде передачи данных csma/cd

Диаграмма перехода между состояниями.

Вопрос № 7

Метод доступа к среде передачи данных csma/ca.

Вопрос № 8

Шина с передачей маркера.

Диаграмма перехода между состояниями.

Вопрос № 9

Вопрос № 10

Сетевой уровень osi.

Маршрутизация пакетов Соединение n- сетей с помощью (n–1)-мостов

Вопрос № 11

Транспортный уровень osi. Задачи и функции уровня.

Классы транспортных протоколов

Передача данных с установкой и без установки соединения вопрос № 12

Задачи и функции уровня

Вопрос № 13

Вопрос № 14

Прикладной уровень osi. Задачи и функции уровня

Примеры прикладных протоколов

Вопрос № 15

Вопрос № 16

Классы ip-адресов

Двоичная форма записи ip-адресов

Особые ip-адреса

Использование масок для ip-адресации

Вопрос № 17

Вопрос № 18

Вопрос № 19

Вопрос № 20

Вопрос № 21

Принцип скользящего окна в протоколе tcp

Проблемы tcp

Вопрос № 22

Механизм установки tcp-соединения

Уязвимость tcp-протокола вида «парадокс дней рождения»

Вопрос № 23

Вопрос № 24

Вопрос № 25

Основные функции

Вопрос № 26

Вопрос № 27

Динамические системы именования

Принципы организации dns. Рекурсивные и итеративные запросы.

Вопрос № 28

Вопрос № 29

Вопрос № 30

Вопрос № 31

Вопрос № 32

Электронная почта

Методы проверки подлинности пользователя в imap

Команда login

Команда authenticate

Клиентская часть протокола imap Флаги почтового сообщения imap

Команды протокола

Преимущества по сравнению с pop3

Вопрос № 33

Протокол Telnet

Протокол ftp

Вопрос № 34

Структура протокола

Стартовая строка

Коды состояния

Заголовки

Вопрос № 35

Вопрос № 36

Вопрос № 37

Вопрос № 38

Хостинг

Вопрос № 39

Вопрос № 40

Вопрос № 41

Вопрос № 42

Вопрос № 43

Вопрос № 44

Вопрос № 45

Вопрос № 46

Вопрос № 47

В определенный момент времени клиент может находиться либо в состоянии перехода между состояниями приложения или «в покое». Клиент в состоянии покоя способен взаимодействовать со своим пользователем, но не создает нагрузку и не потребляет места для хранения клиентов на серверах или в сети.

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

REST изначально описан в контексте HTTP, но не ограничен этим протоколом. Архитектуры типа RESTful могут быть основаны на других протоколах прикладного уровня, если они уже реализуют обширный и единый словарь для приложений, основанных на передаче значимых представлений состояний. Приложения RESTful увеличивают использование уже существующих хорошо определенных интерфейсов и других встроенных возможностей, предлагаемых выбранным сетевым протоколом, а также сокращают добавление к нему новых возможностей, специфичных для приложения.

Архитектурный стиль REST описывает следующие шесть ограничений, налагаемых на архитектуру, оставляя реализацию индивидуальных компонентов свободной:

Технология «клиент-сервер»

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

Без состояния

Взаимодействие клиент-сервер ограничивается далее отсутствием сохранения контекста клиента на сервере между запросами. Каждый запрос от любого клиента содержит всю информацию, необходимую для его обслуживания, а любое состояние сессии хранится в клиенте. Сервер может быть с состоянием; это ограничение требует, чтобы состояние на стороне сервера было адресуемо через URL как ресурс. Это не только делает серверы болеевидимыми для мониторинга, но и делает их болеенадежнымив случае частичного отказа сети, а также дополнительно улучшает их масштабируемость.


Кэшируемость

Как и во Всемирной паутине, клиенты могут кэшировать ответы. Поэтому ответы должны, явно или неявно, определять себя кэшируемыми или нет, чтобы предотвратить использование клиентом старые или неподходящие данные при ответе на следующие запросы. Хорошо управляемое кэширование частично или полностью устраняет некоторые взаимодействия клиента и сервера, повышая далее масштабируемость и производительность.

Многоуровневая система

Клиент не может однозначно определить, подключается ли он непосредственно к серверу или к посреднику по пути подключения. Посредник сервера может улучшить масштабируемость системы, обеспечивая балансировку нагрузки и обеспечивая общий кэш. Он может также потребовать соблюдения политики безопасности.

Код по требованию (опционально)

Серверы могут временно расширить или настроить функциональность клиента, передавая ему исполняемую логику. Примерами этого могут служить скомпилированные компоненты, такие как Java-апплетыи клиентские сценарии, такие какJavaScript.

Единый интерфейс

Единый интерфейс между клиентами и серверами, обсуждаемый ниже, упрощает и разделяет архитектуру, позволяя каждой части развиваться самостоятельно. Четыре руководящих принципа такого интерфейса подробно описаны ниже.

Руководящие принципы интерфейса

Единый интерфейс, которому должен удовлетворять любой интерфейс REST считается фундаментальным для разработки любой службы REST.[8]

Идентификация ресурсов

Индивидуальные ресурсы идентифицируются в запросах, например, с помощью URIв системах REST на основе Веб. Сами ресурсы концептуально отделены от представлений, возвращаемых клиенту. Например, сервер отправляет не свою базу данных, а, возможно, некоторый файлHTML,XMLилиJSON, представляющий некоторые записи базы данных, выраженные например, на финском и закодированные вUTF-8, в зависимости от деталей запроса и реализации сервера.

Манипуляция ресурсами через их представления

Когда клиент содержит представление ресурсов, включая любые присоединенные метаданные, он имеет достаточно информации для того, чтобы изменить или удалить ресурс на сервере, если он имеет на это разрешение.

Самоописывающие сообщения

Каждое сообщение содержит достаточно информации, чтобы описать способ обработки сообщения. Например, определение того, какой анализатор следует вызвать, можно выполнить через тип содержимого Интернет(ранее известный как типMIME). Ответы также явно указывают возможность кэширования.[1]


Гипермедиа как машина состояния приложения

Клиенты выполняют переходы в состояния только с помощью действий, которые динамически определены в гипермедиа на сервере (например, ссылкойв структурегипертекста). Кроме простой фиксированной точки входа в приложение, клиент предполагает, что никакое конкретное действие, кроме описанных в представлениях, полученных ранее от сервера, не будет доступно для любого конкретного ресурса.

Единственным дополнительным ограничением архитектуры REST является код по требованию. Если служба нарушает какие-либо другие ограничения, она не может быть однозначно названа RESTful.

Соблюдение этих ограничений, и, следовательно, соответствие архитектурному стилю REST, позволит любой распределенной системе гипермедиа иметь требуемые свойства, такие как производительность, масштабируемость, простота, модифицируемость, видимость, мобильность и надежность.

RESTful веб-служба (также называемая RESTful web API) — это простая веб-служба, реализованная с использованием HTTP и принципов REST. Она представляет собой набор ресурсов с тремя определенными аспектами:

базовый URI для веб-службы, например http://example.com/resources/

тип содержимого Интернетдля данных, поддерживаемых веб-службой. Часто этоJSON,XMLилиYAML, но можно использовать любой другой действительный тип содержимого Интернет.

множество операций, поддерживаемых веб-службой, используя основные механизмы протокола(то есть, POST, GET, PUT или DELETE).


Вопрос № 41

Рассеянные (облачные) вычисления (cloudcomputing). Основные понятия, принципы организации и функционирования.

Облачные вычисления(англ.cloud computing) — это модель обеспечения повсеместного и удобного сетевого доступа по требованию к общему пулу конфигурируемых вычислительных ресурсов (напримерсетям передачи данных, серверам, устройствам хранения данных, приложениям и сервисам — как вместе, так и по отдельности), которые могут быть оперативно предоставлены и освобождены с минимальными эксплуатационными затратами и/или обращениями к провайдеру.[1]

Потребители облачных вычислений могут значительно уменьшить расходы на инфраструктуру информационных технологий (в краткосрочном и среднесрочном планах) и гибко реагировать на изменения вычислительных потребностей, используя свойства вычислительной эластичности(англ.Elastic computing) облачных услуг.

[править] Характеристики

Национальным институтом стандартов и технологий СШАзафиксированы следующие обязательные характеристики облачных вычислений[6]:

Самообслуживание по требованию(англ.self service on demand), потребитель самостоятельно определяет и изменяет вычислительные потребности, такие как серверное время, скорости доступа и обработки данных, объём хранимых данных без взаимодействия с представителем поставщика услуг;

Универсальный доступ по сети, услуги доступны потребителям по сети передачи данных вне зависимости от используемого терминального устройства;

Объединение ресурсов(англ.resource pooling), поставщик услуг объединяет ресурсы для обслуживания большого числа потребителей в единыйпулдля динамического перераспределения мощностей между потребителями в условиях постоянного изменения спроса на мощности; при этом потребители контролируют только основные параметры услуги (например, объём данных, скорость доступа), но фактическое распределение ресурсов, предоставляемых потребителю, осуществляет поставщик (в некоторых случаях потребители всё-таки могут управлять некоторыми физическими параметрами перераспределения, например, указывать желаемый центр обработки данных из соображений географической близости);

Эластичность, услуги могут быть предоставлены, расширены, сужены в любой момент времени, без дополнительных издержек на взаимодействие с поставщиком, как правило, в автоматическом режиме;


Учёт потребления, поставщик услуг автоматически исчисляет потреблённые ресурсы на определённом уровне абстракции (например, объём хранимых данных, пропускная способность, количество пользователей, количество транзакций), и на основе этих данных оценивает объём предоставленных потребителям услуг.

С точки зрения поставщика, благодаря объединению ресурсов и непостоянному характеру потребления со стороны потребителей, облачные вычисления позволяют экономить на масштабах, используя меньшие аппаратные ресурсы, чем требовались бы при выделенных аппаратных мощностях для каждого потребителя, а за счёт автоматизации процедур модификации выделения ресурсов существенно снижаются затраты на абонентское обслуживание.

С точки зрения потребителя, эти характеристики позволяют получить услуги с высоким уровнем доступности(англ.high availability) и низкими рисками неработоспособности, обеспечить быстрое масштабирование вычислительной системы благодаряэластичностибез необходимости создания, обслуживания и модернизации собственной аппаратной инфраструктуры.

Удобство и универсальность доступа обеспечивается широкой доступностью услуг по и поддержкой различного класса терминальных устройств (персональных компьютеров,мобильных телефонов,интернет-планшетов).

[править] Модели обслуживания

[править] Программное обеспечение как услуга

Основная статья:SaaS

Программное обеспечение как услуга(SaaS,англ.Software-as-a-Service) — модель, в которой потребителю предоставляется возможность использованияприкладного программного обеспеченияпровайдера, работающего в облачной инфраструктуре и доступного из различных клиентских устройств или посредствомтонкого клиента, например, избраузера(например, веб-почта) или интерфейс программы. Контроль и управление основной физической и виртуальной инфраструктурой облака в том числе сети, серверов, операционных систем, хранения, или даже индивидуальных возможностей приложения (за исключением ограниченного набора пользовательских настроек конфигурации приложения) осуществляется облачным провайдером.

[править] Платформа как услуга

Основная статья:PaaS

Платформа как услуга(PaaS,англ.Platform-as-a-Service) — модель, когда потребителю предоставляется возможность использования облачной инфраструктуры для размещения базового программного обеспечения для последующего размещения на нём новых или существующих приложений (собственных, разработанных на заказ или приобретённых тиражируемых приложений). В состав таких платформ входят инструментальные средства создания, тестирования и выполнения прикладного программного обеспечения — системы управления базами данных, связующее программное обеспечение, среды исполнения языков программирования — предоставляемые облачным провайдером.