Принципы сетевых приложений

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

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

Архитектура сетевых приложений возможна двух типов:

  • Клиент-серверная (Google, Amazon, любой сайт)
  • Одноранговая (BitTorrent, Skype, Git)

Взаимодействие процессов в сети

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

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

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

HTTP определяет структуру этих сообщений и порядок обмена между клиентом и сервером.

Веб-страница (также называемая документом) состоит из объектов. Объект — это простой файл, имеющий уникальный URL-адрес, например файл формата HTML, изображение в формате JPEG. Каждый URL-адрес состоит из двух частей: имени сервера, содержащего объект и пути до этого объекта. Например, URL-адрес.
Виды HTTP-соединений:

  1. Непостоянные
  2. Постоянные
Службы протокола TCP
Модель обслуживания протокола TCP включает службу установления логического соединения, а также службу надежной передачи данных. Перед тем как начинают передаваться сообщения прикладного уровня, протокол TCP обеспечивает обмен управляющей информацией между клиентом и сервером на транспортном уровне. Эта так называемая процедура рукопожатия предупреждает клиентскую и серверную сторону, позволяя им подготовиться к началу обмена пакетами.
Службы протокола UDP
UDP представляет собой простой протокол транспортного уровня, предлагающий минимальный набор служб. UDP является протоколом без установления соединения, то есть процедуры рукопожатия перед тем, как два процесса начинают взаимодействовать, не происходит. UDP обеспечивает ненадежную передачу данных.

Популярные Интернет-приложения и используемые ими протоколы прикладного и транспортного уровней:
Ниже представлено типичное сообщение-запрос протокола HTTP:
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
Схема сообщения HTTP-запроса:
Сообщение-ответ протокола HTTP:
HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html

# (данные данные данные данные данные...)
Общий формат сообщения-ответа протокола HTTP
Коды состояния
Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трёх цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделенная пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.

1xx - Служебные информационные.
2xx - Успешное завершение.
3xx - Перенаправление.
4xx - Ошибка на стороне клиента.
5xx - Ошибка на стороне сервера.

Примеры:
200 Ok
201 Webpage Created
403 Access allowed only for registered users
404 Not found
500 Internal server error
Заголовки
Заголовки HTTP (англ.HTTP Headers) — это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см. RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.

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

  1. General Headers («Основные заголовки») — могут включаться в любое сообщение клиента и сервера;
  2. Request Headers («Заголовки запроса») — используются только в запросах клиента;
  3. Response Headers («Заголовки ответа») — только для ответов от сервера;
  4. Entity Headers («Заголовки сущности») — сопровождают каждую сущность сообщения.
Именно в таком порядке рекомендуется посылать заголовки получателю.

Все необходимые для функционирования HTTP заголовки описаны в основных RFC. Если не хватает существующих, то можно вводить свои. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими. Например, как в заголовках X-Powered-By или X-Cache. Некоторые разработчики используют свои индивидуальные префиксы.

Http-Методы

  • HEAD - запрашивает информацию из указанного источника и не влияет на его содержимое, в ответе сервера содержится только заголовок, без тела. Возвращая статус 200 (Ok). Обычно применяется для того, чтобы проверить, существует ли ресурс по указанному адресу, а также не изменился ли он с момента последнего обращения.
  • GET - запрашивает информацию из указанного источника и не влияет на его содержимое. Запрос доступен для кеширования данных и добавления в закладки. возвращая статус 200 (Ok). Длина запроса ограничена (макс. длина URL - 2048).
  • POST - Загружает данные запроса на указанный в запросе URI, что может оказывать влияние на содержимое целевого ресурса. возвращая статус 200 (Ok).
    В отличие от метода GET запросы POST не могут быть кешированы, они не остаются в истории браузера и их нельзя добавить в закладки. Запросы POST не ограничиваются в объеме.
  • PUT - Загружает содержимое запроса на указанный в запросе URI. Если по заданному URI ресурса нет, то сервер создает его, возвращая статус 201 (Created).
  • PATH - Загружает содержимое запроса на указанный в запросе URI. Если по заданному URI ресурс существует то сервер частично изменяет целевой ресурс, возвращая статус 200 (Ok).
  • DELETE - удаляет ресурс по указанному URL. При успешном удалении возвращается 200 (OK) код HTTP, совместно с телом ответа, содержащим данные удаленного ресурса.
  • CONNECT - запускает двустороннюю связь с запрошенным ресурсом. Метод можно использовать для открытия туннеля.
    К примеру, метод CONNECT может использоваться для доступа к сайту, который использует SSL (HTTPS). Клиент запрашивает HTTP-прокси-сервер для туннелирования TCP-соединения с желаемым назначением. За тем сервер переходит к подключению от имени клиента. После того, как соединение установлено сервером, прокси-сервер продолжает проксировать поток TCP к клиенту и от него.
    Для того, чтобы узнать какие методы запросов поддерживаются сервером, можно направить OPTIONS запрос. Ответ будет следующим:

    HTTP/1.1 200 OK Allow: OPTIONS, GET, HEAD, POST Cache-Control: max-age=604800 Date: Thu, 13 Oct 2016 11:45:00 GMT Expires: Thu, 20 Oct 2016 11:45:00 GMT Server: EOS (lax004/2813) x-ec-custom-error: 1 Content-Length: 0
  • OPTIONS - используется для описания параметров соединения с ресурсом.
  • TRACE - выполняет вызов возвращаемого тестового сообщения с ресурса
Cookie-файлы
Мы упомянули выше, что HTTP-сервер не сохраняет состояние соединения. Это упрощает разработку серверного программного обеспечения и позволяет создавать высокопроизводительные веб-серверы, способные обрабатывать тысячи одновременных TCP-соединений. Однако очень часто возможность идентифицировать пользователей очень даже желательна либо по причине того, что серверу нужно ограничить пользовательские права доступа, либо чтобы предоставлять набор услуг в зависимости от идентификации пользователя. Для этих целей в протоколе HTTP используются объекты cookie («Куки»).