Файл: Шпора.docx

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

1xx Informational (русск. Информационный)

2xx Success (русск. Успешно)

3xx Redirection (русск. Перенаправление)

4xx Client Error (русск. Ошибка клиента)

5xx Server Error (русск. Ошибка сервера)

Заголовки

Заголовки HTTP (Headers) — это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.

Примеры заголовков:

Server: Apache/2.2.11 (Win32) PHP/5.3.0

Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT

Content-Type: text/plain; charset=windows-1251

Content-Language: ru

Каждая строка представляет собой один заголовок. До первого двоеточия имя, после — значением.

Все заголовки разделяются на четыре основных группы:

General Headers (русск. Основные заголовки) — должны включаться в любое сообщение клиента и сервера.

Request Headers (русск. Заголовки запроса) — используются только в запросах клиента.

Response Headers (русск. Заголовки ответа) — только для ответов от сервера.

Entity Headers (русск. Заголовки сущности) — сопровождают каждую сущность сообщения.

GET-запрос

Запрос клиента:

GET/wiki/страницаHTTP/1.1

Host: ru.wikipedia.org

User-Agent: Mozilla/5.0

Accept: text/html

Connection: close

Вопрос № 35

Талон безопасности (securitytoken). Принципы использования.

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

1. Атрибут принадлежности человека к компании является E-mail. Для того, что провести аутентификацию, регистрирующемуся пользователю необходимо отправить письмо наe-mailс просьбой подтверждения

2. Следует использовать e-mailв качестве имени пользователя

При регистрации пользователь вводит свою почту и жмет кнопку регистрация. На эту почту приходит письмо с просьбой подтвердить регистрацию. В этом письму присутствует ссылка типа:

http://mysite.com?token=6789928xcVhY76

token– это токен безопасности, то есть электронная подпись, она будет представлять собой время до которого действительна эта ссылка и имя пользователя закодированные секретным ключом (у пользователя нет ни секретного, ни открытого ключа, а подписание и проверку подписи осуществляет сайт-аутентификатор)

При переходе по этой ссылке сайту отправится токен безопасности. Сайт его декодирует и проверяет не прошло ли указанное время. При этом, перед отправкой письма можно проверить допустимость доменного имени e-mail’a(обычно используется корпоративный почтовый сервер)

Перейдя по ссылке, человек попадает на страницу компании по HTTPS, где ему предлагается задать пароль. Тут принципиально использованиеHTTPS, так как будет передаваться пароль и он должен передаваться в зашифрованном виде. В пароль должны использоваться:

1. Строчные

2. Прописные

3. Цифры

4. Специальные символы

Хранить пароли в базе небезопасно (базу могут украсть) Поэтому, обычно в базе хранят хэш пароля, SHA1(Password) –SHA1 – 160 бит. Подобрать хэш нереально а подобрать сам пароль намного проще и если есть доступ к базе, то можно перебрать пароли, генерировать хэши и искать хэши в базе. Поэтому правильнее сделать так:

Самым надежным будет делать так:

Keyхранится не в базе и никто к нему не имеет доступа.

Если пользователь забыл пароль, то ему предлагается ввести свой логин (т.е. почту). В базе имеется этот логин. Если такой логин существует, то на почту пользователя отправляется письмо со ссылкой:

http://mysite.com/ResetPasssword?token=6789928xaBGQ1

После чего в базу заносится новый пароль зашифрованный по тому же алгоритму.

Итого:

1. При регистрации использовать письма с ссылками, снабженными токеном безопасности.

2. Передавать данные только по HTTPS

3. Хэшировать пароли так: SHA(Login+Password, Key)

Вопрос № 36

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

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

Поэтому при работе по HTTPсоединение не закрывается а остается живым для повторного использования (HTTPConnectionpooling). Причем это соединение будет использовано и при открытии ссылки в новой вкладке.

На сервере устанавливается количество соединений, которые он может создать с одним IP-адресом. Обычно ограничение равнодвум (этого вполне достаточно, учитывая, что все страницы можно загружать по одному соединению) Это делается для того, чтобы не дать одному клиенту открыть 1000 соединений и заставить работать сервер только на себя.

Но если у нас клиенты находятся на NAT, то сервер не может определить, сколько на самом деле клиентов хотят с ним общаться, ведь сообщения от них всех приходят с одного и того жеIP(IPNAT’a).

Таким образом, после того, как NATдостигнет лимита соединений с сервером, клиенты за ним перестанут мочь устанавливать соединения с этим сервером до тех пор, пока одно из установленных соединений не будет разорвано.

При этом, если достигнут лимит соединений, то в ответ на запрос соединения сервер будет периодически посылать пакет с флагом ACK:

Это означает: «соединения не было установлено, ожидайте». Таким образом установление соединения может длиться бесконечно долго (попытка соединения не закончится неудачей, а будет ожидать, пока на сервере не освободится соединение для данного IP)

К подобной проблеме менее уязвимы системы с множеством серверов (например Google)

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

Вопрос № 37

Принципы архитектуры Web-службSOA.

1. Программы могут разделять только данные, но не код

2. Клиент и сервер должен разделять «контракт». Контракт определяет, какие операции поддерживает сервер, какие он принимает параметры и их типы. Для описания контракта используется язык XML, а конкретнее его диалектWSDL. Инструментарий позволяет сгенерировать поWSDL-схемеproxyдля любого языка.

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

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

5. Согласно принципам SOA, не только конфигурация должна быть отделена от функциональности, но и хостинг сервиса так же должен быть отделен от функционала.

Сервера, занимающиеся rendering’гомHTM-страниц и сервера, занимающиеся обеспечением функционала, разносятся для разделения нагрузки и более эффективного кэширования.

Базы данных крайне неэффективно работают на виртуальных серверах.

Для Presentationlayerважна мощность процессора.

Для Businesslayerважен объем оперативной памяти.

Для Datalayerважны скорость и объем жесткого диска.

Вопрос № 38

Технология WCF. ПримерWCF-службы и ее клиента.

Windows Communication Foundation (WCF) — программный фреймворк, используемый для обмена данными между приложениями и входящий в состав .NET Framework.

WCF делает возможным построение безопасных и надёжных транзакционных систем через упрощённую унифицированную программную модель межплатформенного взаимодействия. Комбинируя функциональность существующих технологий .NET по разработке распределённых приложений (ASP.NET XML Web Services — ASMX, WSE 3.0, .NET Remoting, .NET Enterprise Services и System.Messaging).

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

Хостинг

Класс службы WCF не может существовать самостоятельно. Каждая служба WCF должна находиться под управлением некоторого процесса Windows, называемого хостовым процессом. Существует различные варианты хостинга:

Автохостинг

Хостинг в одном из Windows service

Хостинг WAS (Windows Activation Services)

Хостинг IIS (Internet Information Server)

Подробно: http://www.gotdotnet.ru/blogs/sergun/6549/

Вопрос № 39

Управление поведением WCF-службы при создании ее экземпляров и обработке параллельных запросов.

Вопрос № 40

Протокол HTTPRESTиWCF-службы на его основе.

Передача состояния представления (Representational State Transfer (REST)) — это стиль архитектуры программного обеспечениядляраспределенныхгипермедиасистем, подобныхВсемирной паутине. Термин Передача состояния представления введен и определен в 2000 годуРоем Филдингомв его кандидатской диссертации. Филдинг является одним из основных авторов спецификациипротокола передачи гипертекста(HTTP) версий 1.0 и 1.1.

Соответствие ограничениям REST называется «RESTful».

Архитектура в стиле REST состоит из клиентов и серверов. Клиенты инициируют запросы к серверам; серверы обрабатывают запросы и возвращают подходящие ответы. Запросы и ответы создаются на базе передачи представлений ресурсов. Ресурс может являться практически любым понятным и значимым адресуемым объектом. Представление ресурса — это обычно документ, отражающий текущее или требуемое состояние ресурса.