Network.md

Сеть - REST, AJAX, JSON, CORS и т.д.

Порт

• Номер выданный операционной системой каждой программе, которая хочет отсылать данные в сеть.

Протокол

• Сетевой протокол — набор правил, по которым реализуется соединение и обмен данными между несколькими устройствами в сети.
• Некоторые протоколы:
  • TСP - создание интернет пакетов и их обратную сборку в нужном порядке в месте получения. Проверяет целостность информации. Если часть пакетов утеряна в процессе передачи, они передаются повторно.
  • IP - для доставки информации по нужному адресу.
  • UDP - надо передать быстро, но без гарантий доставки (например передача аудио)
  • ICMP - в диагностических или сервисных целях. Например передача сообщений об ошибках и других исключительных ситуациях
  • SMTP, POP, IMAP - Почтовые протоколы
  • HTTP — передача данных при клиент-серверном взаимодействии.
  • FTP — передача файлов
  • ARP — определение MAC-адреса другого компьютера по известному IP-адресу.
• Для одновременной работы серверов по протоколам SMTP, POP, IMAP, HTTP, HTTPS, FTP и др. вовсе не требуются отдельные компьютеры или ip-адреса. Все эти сервера можно установить на один компьютер с одним ip-адресом. Это достигается за счет то, что каждый из протоколов использует свой порт.
• Ссылки
  • Сетевые протоколы – IP, ICMP, TCP, UDP, POP, SMTP, POP/POP3, IMAP, HTTP/HTTPS, FTP и другие

URL, URI, URN

• Общее

  • URI (унифицированный идентификатор ресурс) — строка символов, для идентификации ресурса по его адресу или имени, или тому и тому вместе.
  • URL (унифицированный указатель ресурса) — строка символов, для идентификации ресурса только по его адресу. Веб-адрес, используемый для идентификации ресурсов в интернете
  • URN (унифицированный идентификатор ресурс) — строка символов, для идентификации ресурса, только по его имени.

  
  

• URL состоит из

  • Протокола — набор правил соединение и обмена данными между устройствами в сети. Например: http:
  • Домена — имя для идентификации одного или нескольких IP-адресов, на которых расположен ресурс.
  • Пути — местоположение ресурса на сервере
  • Параметров — дополнительные данные, для идентификации или фильтрации ресурса на сервере

  
  

• Кодировка URL

  • URL-адреса используют ASCII-кодировку.
  • Если есть символы не из набора ASCII — URL-адрес конвертируется в допустимый формат ASCII.
  • Перекодироваться должны буквы кириллицы, буквы с диакритическими знаками, лигатуры, иероглифы...
  • Кодирование URL конвертирует этот адрес в ASCII формат.
  • Кодировщик URL заменяет небезопасные символы ASCII знаком %, за которым следуют два шестнадцатиричных числа, которые соответствуют значениям символов из кодировки ISO-8859-1.
  • URL не должен содержать пробелы. Кодировщик URL обычно заменяет пробелы знаком %20.

  
  

• Национальные кодировки

  • Для введения многоязычных доменов используют технологию преобразования кодировки.
  • Работает поверх старой системы DNS, не требует никаких изменений в последней.
  • Преобразование имён происходит на стороне клиента, до отправки запроса в систему DNS.
  • Доменные имена с символами нац. алфавитов, которые пользователь набирает в адресной строке, преобразуются браузером в кодировку ASCII.

  
  

Модель TCP/IP *

• Общее

  • Модель, теоретическое описание принципов работы набора сетевых протоколов, взаимодействующих друг с другом.
  • Сетевая модель передачи данных, представленных в цифровом виде.
  • Предполагает прохождение информации через 4 уровня, каждый из них описан набором правил (протоколом передачи).
  • Модель TCP/IP возникла как развитие модели OSI (там 7 уровней).
  • TCP/IP — набор протоколов, среди них два основных: TCP (Transmission Control Protocol ) и IP (Internet Protocol).
  • Были первыми разработаны и описаны в данном стандарте.
  • Стек протоколов — конкретные наборы протоколов (правил, по которым идёт соединение и обмен данными между устройствами в сети).
  • Иначе говоря — вложенность протоколов (TCP поверх IP поверх Ethernet).

  
  

• 4 уровня стека TCP/IP

  • Прикладной уровень (Application Layer)
    • Зачем: поддержка сеанса связи, преобразование протоколов и информации, взаимодействие пользователя и сети...
    • Примеры: HTTP, RTSP, FTP, DNS...
  • Транспортный уровень (Transport Layer)
    • Зачем: доставка переданной информации без дублирования, потерь и ошибок, в необходимой последовательности.
    • В стеке TCP/IP транспортные протоколы определяют, для какого именно приложения предназначены эти данные.
    • Примеры: TCP, UDP, SCTP, DCCP
  • Межсетевой уровень (Сетевой уровень) (Internet Layer)
    • Зачем: регламентирует взаимодействие между отдельными подсетями.
    • Интернет состоит из множества локальных сетей, объединенных протоколом связи TCP/IP.
    • Маршрутизация осуществляется путем обращения к определенному IP-адресу с использованием маски.
    • Примеры: Для TCP/IP это IP
  • Канальный/Сетевой уровень (Network Access Layer)
    • Зачем: кодирование информации, ее деление на пакеты, отправка по нужному каналу. Измерение параметров сигнала ( задержки ответа, расстояния между хостами...)
    • Для взаимодействия с сетевыми технологиями — Ethernet, Wi-Fi и т. д.
    • Примеры: Ethernet, IEEE 802.11 WLAN, SLIP, Token Ring, ATM и MPLS, физическая среда и принципы кодирования информации, T1, E1

  
  

• Отличия моделей TCP/IP и OSI

  • TCP/IP — стек протоколов, представляющий собой основу Интернета.
  • OSI (Базовая Эталонная Модель Взаимодействия Открытых Систем) — подходит для описания самых разных сетей.

  
  

• Альтернативы TCP

  • Один из вариантов: протокол UDP.
  • Поверx него используем QUIC, поверх HTTP/3.
  • Подробнее

  
  

• Дополнять — там еще много всего

• .

• Ссылки

  • Timeweb - Что такое TCP/IP и как работает этот протокол
  • Proglib - Компьютерные сети от А до Я: стек протоколов TCP/IP
  • Habr - Основы TCP/IP для будущих дилетантов
  • Wiki - TCP/IP
  • Proglib - Компьютерные сети от А до Я: классификация, стандарты и уровни. OSI

  
  

Протокол HTTP

• Ссылки

  • HyperText Transfer Protocol (протокол передачи гипертекста) — протокол передачи данных.
  • Для передачи произвольных данных при клиент-серверном взаимодействии.
  • Протокол прикладного уровня — верхний 7-й уровень модели OSI, 4 уровень TCP/IP
  • Предполагает использование клиент-серверной структуры передачи данных:
    • клиентское приложение формирует запрос и отправляет его на сервер
    • серверное программное обеспечение обрабатывает данный запрос, формирует ответ и передаёт его обратно клиенту
    • клиентское приложение может продолжить отправлять другие запросы (будут обработаны аналогично).
  • HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня (например SOAP, XML-RPC и WebDAV). В таком случае говорят, что протокол HTTP используется как «транспорт».
  • API многих программ также используют HTTP для передачи данных — сами данные могут иметь любой формат (например XML или JSON).
  • Обычно передача данных по протоколу HTTP осуществляется через TCP/IP-соединения.

  
  

• Клиент, Сервер, Прокси

  • 3 главных объекта, которые обмениваются сообщениями:
  • Клиент (user agent)
    • программа, которая отправляет запросы, получает и обрабатывает ответы от имени пользователя на устройстве пользователя,
    • Например, браузер.
  • Сервер (веб-сервер)
    • программа, которая работает на сервере, принимает и обрабатывает запросы от клиента, а затем отправляет ответы клиенту.
    • Это веб-сервер.
  • Прокси (прокси-сервер)
    • программа, которая работает на сервере, пропускает через себя запросы и ответы и выступает в роли посредника между клиентом и сервером.
    • Функции:
    • Кэшировать данные запроса или ответа — для улучшения производительности и снижения сетевого трафика.
    • Фильтровать данные — например сканировать данные антивирусом или использовать родительский контроль.
    • Балансировка нагрузки — распределение запросов между разными серверами.
    • Аутентификацию клиентов — для управления доступом к ресурсам.
    • Логировать — хранение информации о запросах клиентов и ответах сервера.
    • Защищать — обнаружение некоторых типов атак. Например: определение подозрительного трафика или DDoS-атаки.

  
  

• Общий алгоритм

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

  
  

• Сессия, cookie

  • Протокол HTTP не хранит состояние => количество соединений не приводит к существенному усложнению взаимодействия.
  • Но есть понятие сессии, с помощью которой можно передавать и хранить необходимые данные, относящиеся к конкретному сеансу связи.
  • Данные сессии сохраняются на клиенте и на сервере.
  • Например: доступен идентификатор сессии, который позволяет не проводить авторизацию клиента при каждом обращении к серверу.
  • Часто для хранения данных о сессии используются Cookie.

  
  

• HTTP-сообщения

  • HTTP-сообщение — обычный текст в кодировке ASCII.
  • В версиях HTTP/1.1 и раньше — сообщения пересылались в качестве обычного текста.
  • В версии HTTP/2 — текстовое сообщение разделяется на фреймы. Позволяет выполнить оптимизацию и повысить
  • производительность.
  • Два типа сообщений:
    • запросы — от клиента
    • ответы — от сервера
  • Структура:
    • Стартовая строка — описывает запрос, или статус (успех или сбой)
    • Заголовки — передают сервисную информацию, определяют запрос или описывают тело сообщения.
    • Тело сообщения (опционально) — представляет данные в текстовом виде. Может отсутствовать (у всех HEAD-запросов, у некоторых GET-запросов...)
  • Стартовую строку вместе с заголовками сообщения HTTP называют головой запроса, а его данные - телом.

  
  

• HTTP-сообщения - стартовая строка

  • Стартовая строка запроса
    • Метод HTTP — какое действие хочу совершить (GET, PUT, POST, HEAD, OPTIONS...).
      • OPTIONS — для определения возможностей сервера по преобразованию данных. Предварительный запрос к серверу при кросс-доменном запросе. Не кэшируется (???).
      • GET — для получения данных от сервера. Не имеет тела, информацию можно передать только через querystring. Кэшируется.
      • HEAD — для получения данных от сервера. Как GET, но не возвращает данных в ответе. Для проверки существования сайта, получения метаданных. Кэшируется.
      • POST — для отправки данных на сервер. Не кэшируется.
      • PUT — для добавления новых или изменения существующих данных на сервере. Не кэшируется.
      • PATCH — для добавления новых или изменения существующих данных на сервере. Как PUT, но для обновления части данных.
      • DELETE — для удаления данных на сервере. Не кэшируется.
      • TRACE — возвращает запрос от клиента так, что в ответе будет информация о преобразованиях запроса на промежуточных серверах.
      • CONNECT — переводит текущее соединение в TCP/IP-туннель. Обычно используется для установления защищённого SSL-соединения.
    • Цель запроса — адрес. Обычно URL или абсолютный путь протокола. Формат зависит от HTTP-метода.
      • Абсолютный путь, '?' и строка запроса — самая распространённая форма, исходная формой (origin form).
        • Для методов GET, POST, HEAD, и OPTIONS.
        • POST / HTTP 1.1
        • GET /background.png HTTP/1.0
        • HEAD /test.html?query=alibaba HTTP/1.1
        • OPTIONS /anypage.html HTTP/1.0
      • Полный URL - абсолютная форма (absolute form) , обычно используется с GET при подключении к прокси.
        • GET http://developer.mozilla.org/ru/docs/Web/HTTP/Messages HTTP/1.1
      • Компонента URL "authority", состоящая из имени домена и (необязательно) порта (предваряемого символом ':'), называется authority form. Используется только с методом CONNECT при установке туннеля HTTP.
        • CONNECT developer.mozilla.org:80 HTTP/1.1
      • Форма звёздочки (asterisk form), просто "звёздочка" ('*') используется с методом OPTIONS и представляет сервер.
        • OPTIONS * HTTP/1.1
    • Версия HTTP — определяет структуру остального сообщения. Какую версию лучше использовать для ответа.
  • Стартовая строка ответа (строка статуса)
    • Версия протокола (обычно HTTP/1.1)
    • Код состояния — был ли запрос успешным.
      • 1xx — обработка данных на сервере продолжается;
      • 2xx — успешная обработка данных;
      • 3xx — перенаправление запросов (редирект);
      • 4xx — ошибка по вине клиента;
      • 5xx — ошибка по вине сервера.
      • MDN - Коды ответа HTTP
      • Яндекс.Справка - Справочник по кодам статуса HTTP
    • Пояснение — краткое описание кода состояния
    • Пример строки статуса: HTTP/1.1 404 Not Found.

  
  

• HTTP-сообщения - заголовки

  • Структура заголовка: строка, завершаемая (':') и значение, структура которого определяется заголовком.
  • Весь заголовок, включая значение, представляет собой одну строку, может быть довольно длинной.
  • 4 группы заголовков:
    • Основные заголовки — могут включаться в любые сообщения клиента и сервера.
    • Заголовки запроса — используются только в сообщениях клиента.
    • Заголовки ответа — используются только в сообщениях сервера.
    • Заголовки сущности — описывают данные в сообщении.
  • В заголовках указывается информация необходимая для работы веб-сервера или клиента.
  • Например:
    • есть адрес домена, к которому обращается клиент
    • информация об авторизации пользователя.
    • информацию о настройках кэширования на клиенте и сервере
    • формат передаваемых данных
    • языке
    • последних дате и времени модификации данных
    • ...
  • Пример
    • Для экономии трафика часто используют сжатие данных: архивация данных перед пересылкой и разархивация после пересылки.
    • Для этого применяют несколько алгоритмов сжатия (gzip, brotli...)
    • Чтобы пользоваться сжатием, необходимо дать понять клиенту и серверу, что это вообще возможно и какой алгоритм сжатия применять.
    • Клиент должен сообщить серверу, что сжатие поддерживается.
    • Сервер должен сообщить что данные сжаты и их необходимо распаковать перед использованием.
    • Клиент, сообщает о поддержке сжатия gzip, br или deflate используя заголовок: Accept-Encoding: gzip, br, deflate
    • Сервер для передачи данных в сжатом формате gzip шлёт заголовок: Content-Encoding: gzip
  • Ссылки
    • MDN - Заголовки HTTP

  
  

• HTTP-сообщения - тело

  • Данные, которые будут отправлены с запросом, или данные, полученные с ответом.

  • Может отсутствовать — для всех HEAD-запросов, для некоторых GET-запросов, у ответов с кодом состояния 201 (создано), 204 (Нет содержимого) и др.

  • Формат данных тела сообщения

    • Бывает нескольких типов.
    • Чаще всего встречаются типы:
      • text/html.
      • application/json.
      • multipart/form-data.

  • Тело запроса

    • Может отсутствовать — для всех HEAD-запросов, для некоторых GET-запросов (запрос клиента, где указан метод GET для получения данных).
    • Запросы, собирающие (fetching) в нем обычно не нуждаются ресурсы (GET, HEAD, DELETE, или OPTIONS).
      
    • Некоторые запросы отправляют на сервер данные для обновления, как это часто бывает с запросами POST (содержащими данные HTML-форм).
    • можно разделить на 2 категории:
      • Одноресурсные тела — состоят из одного отдельного файла, определяемого двумя заголовками: Content-Type и Content-Length.
      • Многоресурсные тела — состоят из N частей, каждая содержит свой бит информации. Обычно связаны с HTML-формами.

  • Тело ответа

    • есть не у всех ответов: у ответов с кодом состояния 201 (создано), 204 (нет содержимого) и др.
    • можно разделить на 3 категории:
      • Одноресурсные тела из отдельного файла известной длины, определяемые двумя заголовками: Content-Type и Content-Length.
      • Одноресурсные тела из отдельного файла неизвестной длины, разбитого на небольшие части (chunks) с заголовком Transfer-Encoding, значением которого является chunked.
      • Многоресурсные тела состоящие из многокомпонентного тела, каждая часть которого содержит свой сегмент информации. Довольно редки.

  • Ссылки

    • MDN - Сообщения HTTP.Тело

  
  

• Ссылки

  • Дока - Протокол HTTP
  • MDN - Основы HTTP

  
  

Протокол UDP *

• Передача данных между сервером и браузером опирается на протоколы транспортного уровня TCP и UDP. Знание о том, как они работают, позволяет оптимизировать передачу данных и улучшить пользовательский опыт.
• На практике TCP используется в случаях, когда необходимо гарантировать целостность и порядок приходящих данных в ущерб скорости их передачи. Это важно для обмена файлами (например, запрос на получение файлов разметки HTML или стилей CSS).
• UDP используется, если скорость важнее соблюдения подобных требований (например, доставка потокового аудио или видео). Гарантий доставки и порядка получения данных нет.
• Расширенная UDP-TCP шутка
  • Я знаю отличную шутку про UDP, но не факт, что она до вас дойдет.
  • Я знаю отличную шутку про TCP, но если она до вас не дойдет, то я повторю.
  • А кто знает отличную шутку про ARP?
  • А вы слышали шутку про ICMP?
  • Вам еще кто-то рассказывал шутку про STP?..
• Ссылка
  • Протоколы TCP и UDP

HTTP/2

• Общее

  • Вторая версия сетевого протокола HTTP.
  • Для повышения эффективности передачи данных по сети.
  • Разработан рабочей группой Hypertext Transfer Protocol working group
  • Утверждён в 2015
  • В 2021 около 50% из 10 млн самых популярных интернет-сайтов поддерживают протокол HTTP/2.

  
  

• Цели

  • Добавить механизмы согласования протокола - клиент и сервер могут использовать HTTP 1.1, 2.0 или, гипотетически, иные, не HTTP-протоколы.
  • Уменьшение задержек доступа для ускорения загрузки страниц, в частности путём:
    • Сжатия данных в заголовках HTTP
    • Использования push-технологий на серверной стороне
    • Конвейеризации запросов
    • Устранения проблемы блокировки «head-of-line» протоколов HTTP 1.0/1.1
    • Мультиплексирования множества запросов в одном соединении TCP
  • Сохранение совместимости с существующими применениями HTTP

  
  

• Отличия от HTTP 1.1

  • Протокол HTTP/2 является бинарным. По сравнению с предыдущим стандартом изменены способы разбиения данных на фрагменты и транспортирования их между сервером и клиентом.
  • В HTTP/2 сервер имеет право послать то содержимое, которое ещё не было запрошено клиентом. Это позволит серверу сразу выслать дополнительные файлы, которые потребуются браузеру для отображения страниц, без необходимости анализа браузером основной страницы и запрашивания необходимых дополнений.
  • Также часть улучшений получена за счёт мультиплексирования запросов и ответов для преодоления проблемы «head-of-line blocking» протоколов HTTP 1; сжатия передаваемых заголовков и введения явной приоритизации запросов.

  
  

• Server Push

  • HTTP/2 вводит технологию Server Push — позволяет серверу отправлять данные в клиентский кэш по собственной инициативе.
  • Однако, при использовании этой технологии данные нельзя отправлять прямо в приложение.
  • Данные, отправленные сервером по своей инициативе, обрабатывает браузер, при этом нет API, которые позволяют, например, уведомить приложение о поступлении данных с сервера и отреагировать на это событие.

  
  

• SSE

  • Server-Sent Events (SSE) — механизм, который позволяет серверу асинхронно отправлять данные клиенту после установления клиент-серверного соединения.
  • После соединения сервер может отправлять данные по своему усмотрению, например, когда окажется готовым к передаче очередной фрагмент данных.
  • Можно представить себе как одностороннюю модель издатель-подписчик.
  • Кроме того, в рамках этой технологии существует стандартное клиентское API для JavaScript, называемое EventSource, реализованное в большинстве современных браузеров как часть стандарта HTML5 W3C.
  • Технология SSE основана на HTTP => она отлично сочетается с HTTP/2. Можно скомбинировать с некоторыми возможностями HTTP/2, что открывает дополнительные перспективы.
    • HTTP/2 даёт эффективный транспортный уровень, основанный на мультиплексированных каналах,
    • а SSE даёт приложениям API для передачи данных с сервера.
  • Технология SSE основана на HTTP. Это означает, что с использованием HTTP/2 не только несколько SSE-потоков могут передавать данные в одном TCP-соединении, но то же самое может быть сделано и с комбинацией из нескольких наборов SSE-потоков (отправка данных клиенту по инициативе сервера) и нескольких запросов клиента (уходящих к серверу).
  • Благодаря HTTP/2 и SSE теперь имеется возможность организации двунаправленных соединений, основанных исключительно на возможностях HTTP, и имеется простое API, которое позволяет обрабатывать в клиентских приложениях данные, поступающие с серверов.
  • Недостаточные возможности в сфере двунаправленной передачи данных часто рассматривались как основной недостаток при сравнении SSE и WebSocket. Благодаря HTTP/2 подобного недостатка больше не существует. Это открывает возможности по построению систем обмена данными между серверными и клиентскими частями приложений исключительно с использованием возможностей HTTP, без привлечения технологии WebSocket.

  
  

• Ссылки

  • Все, что нужно знать о HTTP/2
  • Wikipedia

  
  

HTTP/2. Технология Server Push

• HTTP/2 вводит технологию Server Push, которая позволяет серверу отправлять данные в клиентский кэш по собственной инициативе. Однако, при использовании этой технологии данные нельзя отправлять прямо в приложение. Данные, отправленные сервером по своей инициативе, обрабатывает браузер, при этом нет API, которые позволяют, например, уведомить приложение о поступлении данных с сервера и отреагировать на это событие.
• Именно в подобной ситуации весьма полезной оказывается технология Server-Sent Events (SSE). SSE — это механизм, который позволяет серверу асинхронно отправлять данные клиенту после установления клиент-серверного соединения.
• Ссылки
  • Legmo - Работа браузера
  • Habr - HTTP/2 Server Push не так прост, как я думал

HTTPS

• Общее

  • Расширение протокола HTTP, реализует упаковку данных в криптографический протокол SSL или TLS.
  • Имеют 3 уровня защиты:
    • Шифрование данных — позволяет избежать их перехвата;
    • Сохранность данных — любое изменение данных фиксируется;
    • Аутентификация — защищает от перенаправления пользователя.

  
  

• В каких случаях необходим сертификат HTTPS?

  • Обязательное использование защищенного протокола передачи данных требует вся информация, касающаяся проведения платежей в интернете: оплата товаров в интернет-магазинах любым способом (индивидуальная платежная карта, онлайн системы платежей и пр.), оплата услуг через интернет-банкинг, совершение платежей в онлайн сервисах (казино, online-курсы и т.п.) и многое другое.
  • Также рекомендуется на сайтах, которые для доступа к определенному контенту запрашивают личные данные пользователей, например, номер паспорта – такие данные необходимо защищать от перехвата злоумышленниками.

  
  

• Как использовать HTTPS. Сертификаты

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

  
  

• Ссылки

  • Proglib - Что такое HTTP и HTTPS?

  
  

HTTP-протокол — Методы

• Метод — это указание операции над ресурсом.
• Методы HTTP-протокола:
  • OPTIONS — для определения возможностей сервера по преобразованию данных. Предварительный запрос к серверу при кросс-доменном запросе. Не кэшируется (???).
  • GET — для получения данных от сервера. Не имеет тела, информацию можно передать только через querystring. Кэшируется.
  • HEAD — для получения данных от сервера. Как GET, но не возвращает данных в ответе. Для проверки существования сайта, получения метаданных. Кэшируется.
  • POST — для отправки данных на сервер. Не кэшируется.
  • PUT — для добавления новых или изменения существующих данных на сервере. Не кэшируется.
  • PATCH — для добавления новых или изменения существующих данных на сервере. Как PUT, но для обновления части данных.
  • DELETE — для удаления данных на сервере. Не кэшируется.
  • TRACE — возвращает запрос от клиента так, что в ответе будет информация о преобразованиях запроса на промежуточных серверах.
  • CONNECT — переводит текущее соединение в TCP/IP-туннель. Обычно используется для установления защищённого SSL-соединения.
• Ссылки
  • Методы HTTP-запроса
  • Habr - Простым языком об HTTP

HTTP-протокол — Кэширование

• Общее

  • Кэширование — временное сохранение контента из предыдущих запросов.
  • Позволяет хранить веб-ресурсы на удалённых точках по пути от вашего сервера к пользовательскому браузеру.
  • Браузер тоже хранит у себя кэш, чтобы клиенты не запрашивали у вас постоянно одни и те же ресурсы.
  • Веб-кэширование является основной конструктивной особенностью протокола HTTP, предназначенного для минимизации сетевого трафика и улучшения отзывчивости системы в целом. Контент кэшируется на каждом уровне от исходного сервера до браузера.
  • Веб-кеширование работает путем кэширования HTTP-ответов для запросов в соответствии с определенными правилами. Последующие запросы кэшированного контента затем можно извлечь из ближайшего кэша, а не отправлять запрос обратно на веб-сервер.
  • Кеш надо правильно сконфигурировать: ресурсы редко остаются неизменными, так что копию требуется хранить только до того момента, как ресурс изменился, но не дольше.
  • Главной целью политики кэширования является достижение баланса, который позволяет применять агрессивное кэширование, когда это возможно, и оставляет возможность аннулировать записи при внесении изменений.
    
  • Скорее всего, на каждом сайте будут:
    • Агрессивно кэшируемые элементы.
    • Элементы с коротким сроком свежести и необходимостью валидации.
    • Элементы, которые не кэшируются вообще. Цель — по возможности перемещать контент в первые категории, при сохранении приемлемого уровня точности.
  • Здесь будет говориться в основном о кешах браузеров и прокси, но существуют также кеши шлюзов, CDN, реверсные прокси кеши и балансировщики нагрузки...

  
  

• Зачем

  • Настройки кэширования веб-трафика крайне важны для посещаемых сайтов.
  • Например, если платишь за траффик или важна скорость/посещаемость.
  • Основной источник повышения производительности веб-сайтов
  • Сокращается задержка — уменьшается время, необходимое для отображения ресурсов
  • Снижается сетевой трафик
  • Снижается нагрузка на сервер, которому не приходится самому обслуживать всех клиентов
  • Повышается производительность — кеш ближе к клиенту и ресурс передаётся быстрее.

  
  

• Коэффициент попадания в кэш

  • Мера измерения продуктивности кэша.
  • Отношение количества запросов, которые можно обслужить из кэша, к общему количеству запросов. Высокий коэффициент попадания в кэш означает, что из кэша можно извлечь высокий процент контента. Обычно к такому результату стремится большинство администраторов.

  
  

• Валидация / Инвалидация

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

  
  

• Что кэшировать?

  • Лучше кэшировать
    • Логотипы и изображения бренда.
    • Не ротируемые изображения в целом (например, значки навигации).
    • Стили.
    • Общие файлы Javascript.
    • Загружаемый контент.
    • Файлы мультимедиа.
  • Кэшировать с оторожностью
    • HTML-страницы.
    • Ротируемые изображения.
    • Часто изменяемые Javascript и CSS.
    • Контент, запрашиваемый с помощью файлов cookie.
  • Лучше не кэшировать
    • Активы, связанные с конфиденциальными данными. (банковская информация и т. д.)
    • Контент, который зависит от пользователя и часто изменяется.

  
  

• Виды кеширования по роли в архитектуре

  • серверное
    • серверное кэширование страниц сайта — веб-сервер
    • кэширование кода интерпретатора PHP
    • кэширование запросов к базе данных.
  • прокси-серверы
    • любой сервер между клиентом и сервером, может кэшировать определенный контент. Эти кэши могут поддерживаться интернет-провайдерами или другими независимыми сторонами.
  • клиентское
    • на уровне браузера. Обычно пользовательский контент или контент, который часто запрашивается и сложно извлекается.

  
  

• Виды кеширования по доступу

  • приватные кеши — предназначен для отдельного пользователя
    • Приватный (private) кеш браузера — содержит все документы, загруженные данным пользователем по HTTP.
  • кеши совместного использования (shared cache) — хранятся копии, которые могут направляться разным пользователям.
    • кеш, который сохраняет ответы, чтобы их потом могли использовать разные пользователи. Например, в локальной сети вашего провайдера или компании, может быть установлен прокси, обслуживающий множество пользователей, чтобы можно было повторно использовать популярные ресурсы, сокращая тем самым сетевой трафик и время ожидания.

  
  

• Заголовки кэширования (основные)

  • Большая часть поведения при кэшировании определяется политикой, которую устанавливает владелец контента.
  • Эти политики в основном формулируются с помощью HTTP-заголовков.
  • Есть разные версии протокола HTTP => есть разные заголовки кэширования, с разными уровнями сложности.
  • Expires — устаревший. Очень простой. Устанавливает время в будущем, когда истекает срок действия контента.
  • Cache-Control — задание инструкций кеширования для запросов и ответов.
    • Можно установить несколько инструкций политики кэширования. Инструкции разделяются запятыми.
    • Стандартные инструкции для запроса
      • Cache-Control: max-age=<seconds> — максимальное время в течение которого ресурс будет считаться актуальным
      • Cache-Control: max-stale[=<seconds>] — клиент хочет получить ответ, для которого было превышено время устаревания.
      • Cache-Control: min-fresh=<seconds> — клиент хочет получить ответ, который будет актуален как минимум указанное количество секунд.
      • Cache-Control: no-cache — необходимость отправить запрос на сервер для валидации ресурса перед использованием закешированных данных.
      • Cache-Control: no-store —
      • Cache-Control: no-transform —
      • Cache-Control: only-if-cached — необходимость использования только закешированных данных. Запрос на сервер не должен посылаться.
    • Стандартные инструкции для ответа
      • Cache-Control: must-revalidate — Кеш должен проверить статус устаревших ресурсов перед их использованием.
      • Cache-Control: no-cache — Кеш должен проверить статус устаревших ресурсов перед их использованием. Применим только к разделяемым кешам (например, прокси), игнорируется частными кешами.
      • Cache-Control: no-store — Кеш не должен хранить никакую информацию о запросе и ответе
      • Cache-Control: no-transform — Никакие преобразования не должны применяться к ресурсу.
      • Cache-Control: public — ответ может быть закеширован в любом кеше.
      • Cache-Control: private — ответ предназначен для одного пользователя и не должен помещаться в разделяемый кеш. Только частный кеш.
      • Cache-Control: proxy-revalidate —
      • Cache-Control: max-age=<seconds> —
      • Cache-Control: s-maxage=<seconds> —
  • Etag — для валидации кэша.
    • Сервер может предоставить уникальный Etag для элемента.
    • Когда придет время проверить кэшированный контент, кэширующий сервер может отправить обратно Etag контента.
    • Исходный сервер либо сообщит ему, что контент не изменился, либо отправит обновленный контент (с новым Etag).
  • Last-Modified — когда элемент был изменен в последний раз.
    • Часть стратегии валидации для обеспечения свежего контента.
  • Content-Length — размер отправленного тела объекта в байтах.
    • Некоторые программы отказываются кэшировать контент, если заранее не знают о размере кэша.
  • Vary — сообщает системе, по каким заголовкам кэширования она может понять, что в кэше находится правильный контент.
    • Дает возможность хранить разные версии одного и того же контента за счет разбавления записей в кэше.
    • Чаще всего используют для указания ключа заголовка Accept-Encoding — чтоб различать сжатый / несжатый контент.
  • ...

  
  

• Приёмы веб-разработчика для улучшения кэширования сайта

  • Установите определенные каталоги для изображений, css и общего контента.
    • Размещение контента в выделенных каталогах позволит вам легко ссылаться на них с любой страницы вашего сайта.
  • Используйте один и тот же URL-адрес для ссылки на одни и те же элементы.
    • Поскольку кэш отталкивается как от хоста, так и от пути к запрошенному контенту, убедитесь, что вы ссылаетесь на свой контент на всех ваших страницах одинаково.
  • Используйте CSS-спрайты, где это возможно.
    • CSS-спрайты для элементов, таких как значки и навигация, уменьшают количество раундов, необходимых для рендеринга вашего сайта, и позволяют сайту кешировать этот единственный спрайт в течение длительного времени.
  • По возможности храните сценарии и внешние ресурсы локально.
    • Если вы используете скрипты javascript и другие внешние ресурсы, подумайте о том, чтобы разместить эти ресурсы на своих собственных серверах.
    • Обратите внимание, что вам нужно знать о любых обновлениях, чтобы вовремя обновить локальную копию.

  
  

• Ссылки

  • Habr - Гид по заголовкам кэширования HTTP для начинающих
  • MDN - HTTP-кеширование
  • MDN - Cache-Control
  • Повышение производительности приложений с помощью HTTP-заголовков кеширования
  • Основы кэширования: терминология, основные HTTP-заголовки и стратегии
  • Что такое кэширование

  
  

HTTP-протокол — Коды состояний

• Основные группы кодов состояний

  • 1xx - Information
  • 100 - Continue
  • 2xx - Success
  • 200 - OK
  • 201 - Created
  • 202 - Accepted
  • 204 - No Content
  • 3xx - Redirect
  • 301 - Moved Permanently
  • 307 - Temporary Redirect
  • 4xx - Client Error
  • 400 - Bad Request
  • 401 - Unauthorized
  • 403 - Forbidden
  • 404 - Not Found
  • 5xx - Server Error
  • 500 - Internal Server Error
  • 501 - Not Implemented
  • 502 - Bad Gateway
  • 503 - Service Unavailable
  • 504 - Gateway Timeout

• Ссылки

  • Яндекс.Справка - Справочник по кодам статуса HTTP
  • MDN - Коды ответа HTTP

REST (REpresentational State Transfer) *

• Общее

  • Aрхитектурный стиль. Набор правил которые должны быть выполнены при проектировании распределенной системы.
  • Облегчает системам обмен данными.
  • RESTful — системы, отвечающие требованиям REST.
  • REST API - интерфейс приложения который не нарушает ограничений REST. Набор классов, функций, констант и т.д.
  • Автор идеи и термина Рой Филдинг 2000 г.
  • REST на сегодняшний день практически вытеснил все остальные подходы, в том числе дизайн основанный на SOAP и WSDL.
  • Современная альтернатива — GraphQL
  • Важно!
    • Архитектура REST не привязана к конкретным технологиям и протоколам.
    • В реальности построение RESTful API почти всегда подразумевает использование HTTP и каких-то популярных форматов представления ресурсов (например JSON или XML).

  
  

• Преимущества REST

  • Масштабируемости взаимодействия компонентов системы (приложения)
  • Общность интерфейсов
  • Независимое внедрение компонентов
  • Промежуточные компоненты, снижающие задержку, усиливающие безопасность
  • Отсутствие дополнительных внутренних прослоек, что означает передачу данных в том же виде, что и сами данные. Т.е. данные не оборачиваются в XML, как это делает SOAP и XML-RPC, не используется AMF, как это делает Flash и т.д. Просто отдаются сами данные.
  • Каждая единица информации (ресурс) однозначно определяется URL — это значит, что URL по сути является первичным ключом для единицы данных. Причем совершенно не имеет значения, в каком формате находятся данные по адресу — это может быть и HTML, и jpeg, и документ Microsoft Word.
  • Как происходит управление информацией ресурса — это целиком и полностью основывается на протоколе передачи данных. Наиболее распространенный протокол конечно же HTTP. Для HTTP действие над данными задается с помощью методов : GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить). Таким образом, действия CRUD (Create-Read-Update-Delete) могут выполняться как со всеми 4-мя методами, так и только с помощью GET и POST.

  
  

• Правила RESTful систем

  • Ключевое:
    • не имеют сохранения состояния
    • разделяют интересы клиента и сервера.
  • Распределенная система считается сконструированной по REST архитектуре (RESTful) если она:
    1. Client-Server — разделение на клиентов и серверы.
       • Например, клиенты не связаны с хранением данных, которое остается внутри каждого сервера, так что мобильность кода клиента улучшается.
       • Серверы не связаны с интерфейсом пользователя или состоянием, так что серверы могут быть проще и масштабируемы.
       • Серверы и клиенты могут быть заменяемы и разрабатываться независимо, пока интерфейс не изменяется.
       • Преимущества:
         • упрощает переносимость пользовательского интерфейса между платформами. Например клиент может быть реализован как для Desktop так и для мобильных, может использовать различные front-end фреймворки — это не отразится на серверной части.
         • улучшает масштабируемость, т.е упрощает серверную часть.
    2. Stateless — отсутствие состояния
       • Сервер не хранит информации о клиентах.
       • В запросе должна храниться вся необходимая информация для обработки запроса и если необходимо, идентификации клиента.
       • В периоды между запросами клиента никакая информация о состоянии клиента на сервере не хранится => каждый запрос клиента должен содержать всю информацию необходимую для выполнения запроса.
       • Пример: клиент наполняет корзину интернет-магазина — мы не должны отправлять промежуточные состояния для временного хранения на сервер. Данные должны быть переданы единым запросом при оформлении покупки.
       • Преимущества:
         • улучшает мониторинг системы, т.к. при анализе данных один запрос содержит все необходимые данные.
         • повышает надежность системы, упрощая задачу восстановления данных при возникновения сбоя.
         • повышает масштабируемость, т.к. отсутствует необходимость в хранении состояния между запросами позволяя серверным компонентам быстрее освобождать ресурсы и упрощая их реализацию.
    3. Cache — кэширование
       • Каждый ответ сервера должен быть отмечен: является ли он кэшируемым или нет.
       • Для предотвращения повторного использования клиентами устаревших или некорректных данных в ответ на дальнейшие запросы.
       • Если ответ сервера отмечен как кэшируемый, клиентский кэш может быть подключен для повторного использования компонента. Это может исключить некоторые взаимодействия между клиентом и сервером => увеличит производительность, снизит время отклика клиента.
    4. Uniform Interface — единообразный интерфейс
       • Единый интерфейс определяет интерфейс между клиентами и серверами.
       • Упрощает и отделяет архитектуру, которая позволяет каждой части развиваться самостоятельно.
       • 4 принципа единого интерфейса:
         • Идентификация ресурсов.
           • В REST ресурсом является все то, чему можно дать имя. Например: пользователь, изображение, предмет (майка, голодная собака, текущая погода) и т.д.
           • Все ресурсы должны быть идентифицированы стабильным идентификатором, который не меняется при изменении состояния.
           • Идентификатором в REST является URI (единый идентификатор ресурса). См. URI, URL (Где и как найти что-то?), URN (Как это что-то идентифицировать&)
           • Ресурсы концептуально отделены от представлений возвращаемых клиентам.
             Например: ресурсы хранятся на сервере как записи в базе данных, а клиенту отдаются в виде представлений ( JSON или XML).
         • Манипуляции над ресурсами через представления
           • Представление используется для выполнения действий над ресурсами.
           • Если клиент хранит представление ресурса, он обладает достаточной информацией для модификации или удаления ресурса.
             Например: получив представление статьи в виде JSON, клиент может сформировать запрос на изменение данной статьи либо ее удаление по идентификатору статьи указанному в поле id.
           • Представление ресурса представляет собой текущее или желаемое состояние ресурса.
             Например: если ресурсом является пользователь, то представлением может являться XML или HTML описание этого пользователя.
         • Cамоописываемые сообщения.
           • Как в примере с данными о статье блога в виде JSON можно интуитивно понять какую информацию несет каждое из полей.
           • Таким образом имена полей описывают их назначение.
           • Запрос и ответ должны хранить в себе всю необходимую информацию для их обработки.
             Не требуются доп. сообщения или кэши для обработки одного запроса.
             Т.е. отсутствует состояние, сохраняемое между запросами к ресурсам.
             Очень важно для масштабирования системы.
         • Гипермедиа как средство изменения состояния приложения.
           • Клиенты изменяют состояние системы только через действия которые динамически определены в гипермедиа на сервере (к примеру гиперссылки). Клиент не может предполагать, что доступна операция над каким либо ресурсом если не получил информацию об этом в предыдущих запросах к серверу.
           • Статус ресурса передается через содержимое body, параметры строки запроса, заголовки запросов и запрашиваемый URI (имя ресурса). Это называется гипермедиа (или гиперссылки с гипертекстом).
           • Также означает, что, при необходимости ссылки могут содержатся в теле ответа (или заголовках) для поддержки URI, извлечения самого объекта или запрошенных объектов.
    5. Layered System - разделение системы на уровни
       • В REST допускается разделить систему на иерархию слоев.
       • Но с условием, что каждый компонент может видеть компоненты только непосредственно следующего слоя.
       • Например: если вы вызывайте службу PayPal а он в свою очередь вызывает службу Visa, вы о вызове службы Visa ничего не должны знать.
    6. Code-On-Demand — код по требованию (опциональное требование).
    • В REST позволяется загрузка и выполнение кода или программы на стороне клиента.
  • Серверы могут временно расширять или кастомизировать функционал клиента, передавая ему логику, которую он может исполнять. Например, это могут быть скомпилированные Java-апплеты или клиентские скрипты на Javascript

  
  

• HTTP методы для создания RESTful сервисов *

  • Подробнее расписать методы REST. Добавить ссылки на подробные примеры и документацию
  • GET
    • Используется для получения (или чтения) представления ресурса. В случае “удачного” (или не содержащего ошибок) адреса, GET возвращается представление ресурса в формате XML или JSON в сочетании с кодом состояния HTTP 200 (OK). В случае наличия ошибок обычно возвращается код 404 (NOT FOUND) или 400 (BAD REQUEST).
    • GET http://www.example.com/api/v1.0/users (вернуть список пользователей)
    • GET http://www.example.com/api/v1.0/users/12345 (вернуть данные о пользователе с id 12345)
    • GET http://www.example.com/api/v1.0/users/12345/orders
  • PUT
    • обычно используется для предоставления возможности обновления ресурса. Тело запроса при отправке PUT-запроса к существующему ресурсу URI должно содержать обновленные данные оригинального ресурса (полностью, или только обновляемую часть).
    • Для создания новых экземпляров ресурса предпочтительнее использование POST запроса. В данном случае, при создании экземпляра будет предоставлен корректный идентификатор экземпляра ресурса в возвращенных данных об экземпляре.
    • При успешном обновлении посредством выполнения PUT запроса возвращается код 200 (или 204 если не был передан какой либо контент в теле ответа). PUT не безопасная операция, так как вследствии ее выполнения происходит модификация (или создание) экземпляров ресурса на стороне сервера, но этот метод идемпотентен. Другими словами, создание или обновление ресурса посредством отправки PUT запроса — ресурс не исчезнет, будет располагаться там же, где и был при первом обращении, а также, многократное выполнение одного и того же PUT запроса не изменит общего состояния системы-
    • PUT http://www.example.com/api/v1.0/users/12345 (обновить данные пользователя с id 12345)
    • PUT http://www.example.com/api/v1.0/users/12345/orders/98765 (обновить данные заказа с id 98765 для пользователя с id 12345)
  • POST
    • Запрос наиболее часто используется для создания новых ресурсов.
    • На практике используется для создания вложенных ресурсов. Другими словами, при создании нового ресурса, POST запрос отправляется к родительскому ресурсу и, таким образом, сервис берет на себя ответственность на установление связи создаваемого ресурса с родительским ресурсом, назначение новому ресурсу ID и т.п.
    • При успешном создании ресурса возвращается HTTP код 201, а также в заголовке Location передается адрес созданного ресурса.
    • POST не является безопасным или идемпотентным запросом. Потому рекомендуется его использование для не идемпотентных запросов. В результате выполнения идентичных POST запросов предоставляются сильно похожие, но не идентичные данные.
    • POST http://www.example.com/api/v1.0/customers (создать новый ресурс в разделе customers)
    • POST http://www.example.com/api/v1.0/customers/12345/orders (создать заказ для ресурса с id 12345)
  • DELETE
    • Используется для удаления ресурса, идентифицированного конкретным URI (ID).
    • При успешном удалении возвращается 200 (OK) код HTTP, совместно с телом ответа, содержащим данные удаленного ресурса. Также возможно использование HTTP кода 204 (NO CONTENT) без тела ответа. Согласно спецификации HTTP, DELETE запрос идемпотентен. Если вы выполняете DELETE запрос к ресурсу, он удаляется. Повторный DELETE запрос к ресурсу закончится также: ресурс удален. Если DELETE запрос используется для декремента счетчика, DELETE запрос не является идемпотентным. Используйте POST для не идемпотентных операций.
    • Тем не менее, существует предостережение об идемпотентности DELETE. Повторный DELETE запрос к ресурсу часто сопровождается 404 (NOT FOUND) кодом HTTP по причине того, что ресурс уже удален (например из базы данных) и более не доступен. Это делает DELETE операцию не идемпотентной, но это общепринятый компромисс на тот случай, если ресурс был удален из базы данных, а не помечен, как удаленный.
    • DELETE http://www.example.com/api/v1.0/customers/12345 (удалить из customers ресурс с id 12345)
    • DELETE http://www.example.com/api/v1.0/customers/12345/orders/21 (удалить у ресурса с id 12345 заказ с id 21)

  
  

• Отличия от GrpahQL

  • REST API — точка входа /users возвращает пользователей с заранее оговоренным набором полей.
  • GraphQL — клиент определяет какие данные сейчас нужны. Отправляет запрос на единую точку, получает в ответе только нужные данные.
  • Например, запрос user { name age } вернет только имя и возраст пользователя.

  
  

• Ссылки

  • lexover.ru - Для чего нужен REST API?
  • Habr - REST, что же ты такое? Понятное введение в технологию для ИТ-аналитиков
  • [Medium - REST: простым языком](https://medium.com/@andr.ivas12/rest-%D0%BF%D1%80%D0%BE%D1%81%D1%82%D1%8B%D0%BC-%D1%8F%D0%B7%D1%8B%D0%BA%D0%BE%D0%BC-90a0bca0bc78
  • tproger.ru - Основы REST: теория и практика

  
  

JSON (Javascript Object Notation)

• Формат данных, который используется для представления объектов в виде строки.

• Если нужно с сервера взять объект с данными и передать его клиенту, то в качестве промежуточного формата – для передачи по сети, почти всегда используют именно его.

• Данные в формате JSON (RFC 4627) представляют собой:

  • JS-объекты { ... }
  • Массивы [ ... ]
  • Значения одного из типов:
    • строки в двойных кавычках,
    • число,
    • логическое значение true/false,
    • null.

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

• Альтернативы

  • XML (1980-е) - язык разметки
  • JSON (~2000) - текстовый формат данных, для обмена. Основан на JS.
  • YAML (2001) - не является языком разметки. Формат сериализации данных, концептуально близкий к языкам разметки. Похож на XML и JSON, но использует более минималистичный синтаксис при сохранении аналогичных возможностей.
  • BSON (2009) - формат двоичной сериализации. Разработан для хранения данных, изначально не предполагался для их передачи по сети. Поддерживает дополнительные типы данных (например Date, ObjectId, Null и бинарные данные) и возможности частичного чтения / изменения данных. Мало распространён. Компрессия не очень — сравним по размеру с JSON.
  • CBOR (2013) - бинарный формат представления данных
  • MessagePack (~2014) - формат данных. Популярная современная алтернатива JSON. Полностью совместим с JSON. Неплохо жмет данные. Можно добавлять поддержку своих типов данных. Поерживается многими языками программирования. Можно использовать streaming API
  • ELDF (2018) - текстовый формат данных

• Ссылки

  • https://learn.javascript.ru/json
  • Habr - Сериализация данных или диалектика общения: простая сериализация (2016)

AJAX (Asynchronous JavaScript and XML)

• Общее

  • Технология отправки запросов к серверу из клиентского кода JavaScript без перезагрузки страницы
  • Слать AJAX-запросы к серверам с другим доменом запрещено на уровне браузера.
  • AJAX не кроссдоменный, но подходит много для каких задач.

  
  

• Асинхронный

  • Браузер предоставляет для AJAX специальный API: конструктор XMLHttpRequest
  • AJAX работает через XMLHttpRequest (XMLHTTP, XHR), т.е. через запросы HTTP/HTTPS
  • Т.е. асинхронный обмен данными (JSON/XML/TXT) через HTTP/HTTPS запросы

  
  

• Общая схема работы

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

  
  

• AJAX использует два метода работы с веб-страницей

  • изменение Web-страницы без перезагрузки, используя DHTML (совокупность технологий CSS, DOM и JavaScript)
  • динамическое обращение к серверу. Может осуществляться несколькими способами, в частности, XMLHttpRequest, и использование техники скрытого фрейма.

  
  

• Алгоритм запроса к серверу

  • Проверка существования на странице объекта XMLHttpRequest. Создание данного объекта для каждого типа браузера — уникальный процесс.
  • Инициализация соединения с сервером.
  • Посылка запроса серверу (GET или POST)
  • Обработка полученных данных.

  
  

• От сервера можно получить данные нескольких видов

  • Обычный текст
  • JSON
  • XML. Сейчас чаще используют формат JSON.

  
  

• Альтернативы AJAX

  • Java-апплеты, позднее технология JavaFX;
  • Технология Silverlight корпорации Microsoft;
  • Протокол WebSocket.

  
  

• Ссылки

  • https://learn.javascript.ru/ajax
  • https://habr.com/ru/post/14246/

  
  

DHTML (Dynamic HTML)

• Совокупность технологий HTML, CSS, DOM и JavaScript.

• Обычный HTML код, дополненный скриптами и каскадными таблицами стилей.

• В отличие от статических сайтов, создаваемых посредством обычного HTML, все элементы страницы динамического сайта фактически являются скриптами, программами, которые создают интерактивную среду для посетителей.

• Позволяет делать веб-страницы "интерактивными". Определенные действия посетителя ведут к изменениям внешнего вида и содержания страницы без обращения к серверу.

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

• Технология такова, что формирование и интерактивное динамическое поведение таких страниц реализуется именно в самом браузере, как говорят «на стороне клиента». В устаревших браузерах DHTML веб-страницы будут представлены как обычные, статические.

• Подход к созданию интерактивного веб-сайта, использует сочетание:

  • статичного языка разметки HTML,
  • встраиваемого (и выполняемого на стороне клиента) скриптового языка JavaScript,
  • CSS (каскадных таблиц стилей)
  • DOM (объектной модели документа).

• Конкурирующая техника включала в себя «Adobe Flash» и «Silverlight».

• Ссылки

  • Wikipedia

JSONP (JSON with Padding - JSON с набивкой) *

• Общее

  • Протокол. Дополнение к формату JSON. Способ запросить данные с сервера, находящегося в другом домене.
  • Не имеет отношения к AJAX.
  • Устаревший но хитрый способ двунаправленного кроссдоменного взаимодействия, основанный на загрузке скрипта с другого домена.
  • В частности, с помощью протокла JSONP можно организовать некоторые разновидности технологии COMET.
  • Насколько я понимаю, работает также с использование XMLHttpRequest, т.е. поверх HTTP/HTTPS
  • Согласно политике ограничения домена, веб-страница, расположенная на сервере server1.example.com, не может связаться с сервером, отличным от server1.example.com. Эта операция запрещена в большинстве браузеров.
  • Идея основана на лазейке в стандартах: загружать скрипты с других доменов не запрещено!
  • Запросы для JSONP получают не JSON, а произвольный JavaScript-код. Они обрабатываются интерпретатором JavaScript, а не парсером JSON.
  • Существуют серьезные риски, связанные с безопасностью при использовании JSONP, в большинстве ситуаций использование CORS является лучшим выбором.
  • JSONP кроссдоменный, но подходит только для случаев, когда надо кроссдоменно передать JSON.
  • Уточнить:
    • В основу технологии JSONP положен тот факт, что политика безопасности браузера не запрещает использовать HTML-элемент <script type="text/javascript" src="…"/> для обращения к серверам, отличным от сервера, с которого произошла загрузка страницы. Используя открытую политику для элементов <script>, некоторые страницы используют их, чтобы загружать JavaScript-код, оперирующий динамически создаваемыми JSON-данными из других источников.

  
  

• Набивка (префикс)

  • Набивка обычно является именем функции обратного вызова, определённой внутри контекста выполнения в браузере. Кроме имени функции префикс может означать имя переменной, оператор if, или любой другой оператор JavaScript. Ответ на JSONP-запрос (строго говоря — запрос, соответствующий паттерну JSONP) не является объектом JSON и не расценивается браузером, как таковой. «Начинка» может быть любым выражением на JavaScript, и вовсе не требует, чтобы внутри обязательно был JSON. Но обычно это фрагмент JavaScript, применяющий вызов функции к неким JSON-данным.
  • Другими словами, типичное применение JSONP предоставляет междоменный доступ к существующему JSON API путём оборачивания начинки JSON в вызов функции.

  
  

• Недостатки

  • Прежде всего, это лазейка, костыль. Разработчики стандартов просто не были настолько хитры, чтобы предугадать динамическое взаимодействие на уровне скриптов.
  • Безопасность. Подгрузка скриптов ни разу не безопасней, чем Аякс. Целое семейство вирусов занимается тем, что добавляет на страницу браузера скрипты для отрисовки баннеров порно и казино. Когда вы подключаетесь к интернету через мобильных операторов, обсосы вставляют в HTML-трафик скрипты для отрисовки виджетов (если соединение не HTTPS)
  • Только GET. JSONP работает только методом GET, что сводит на нет возможности REST-интерфейса. Для REST-сервисов приходится писать прокладки-прокси, т.е. множить костыли. Неустранимое ограничение — позволяет только получение данных GET методом, то есть отправка данных через POST метод остается недоступной.
  • Нельзя отслеживать. Добавив скрипт на страницу, в дальнейшем вы не можете отследить его судьбу. Если у Аякс-запроса есть специальные коллбеки для основных событий (начало, удачное завершение, таймаут, неудачное завершение), то у скрипта ничего такого нет. Загрузился ли он? Ответил ли сервер? Была ли ошибка? Никто не знает.

  
  

• Каковы проблемы JSONP?

  • Это вне стандартов.
  • Это небезопасно.
  • Если запрос провалился, то ничего мы никогда не узнаем, не обработаем ошибку правильно, не можем отследить судьбу запроса.
  • Мы работаем только с GET — никаких модных REST API.
  • И в общем, так делать не надо в 2017 году.
  • Приложениям на js нужен надежный способ забирать данные с серверов. Чтобы это была законно, а не по-воровски в обход протоколов и стандартов. Таким способом стал CORS – Cross-Origin Resource Sharing, кросс-доменные запросы.

  
  

• Ссылки

  • https://ru.wikipedia.org/wiki/JSONP
  • https://grishaev.me/cors/

  
  

JSONPP (Parameterized JSON with padding — параметризованный JSONP)

• Развитие идеи JSONP.
• Включает в себя:
  • URL источника,
  • имя функции, которая будет обрабатывать JSON данные,
  • строка для eval после получения данных
  • строка для eval после окончания обработки данных

CORS, кросс-доменные запросы

• Общее

  • Технология браузеров, позволяет предоставить веб-странице доступ к ресурсам другого домена.

  • Разрешаем кросс-доменный AJAX-запроса (если сервер согласен его принять).

  • Фактически CORS = расширение поверх AJAX.

  • Политика Cross-origin resource sharing — совместное использование ресурсов между разными источниками.

  • Слать обычные AJAX-запросы к серверам с другим доменом запрещено на уровне браузера.

  • Используются дополнительные HTTP-заголовки.

  • Даёт клиенту возможность доступа к выбранным ресурсам с сервера на источнике (домене), отличном от того, что сайт использует в данный момент. Т.е. когда источник текущего документа отличается от запрашиваемого ресурса доменом, протоколом или портом.

  • Ключевым понятием здесь является источник (origin) – комбинация домен/порт/протокол.

  • Запросы на другой источник – отправленные на другой домен (или даже поддомен), или протокол, или порт – требуют специальных заголовков от удалённой стороны.

  • Ссылки

    • Habr — CORS для чайников: история возникновения, как устроен и оптимальные методы работы (2021)

  
  

• Схема работы

  • клиент шлет AJAX-запрос к чужому серверу.
  • AJAX работает через XMLHttpRequest (XMLHTTP, XHR), т.е. через запросы HTTP/HTTPS. Можно через feetch
  • браузер добавляет в запрос особые заголовки с информацией о том, что запрос с другого домена.
  • на их основании сервер решает, как обрабатывать такой запрос, и добавляет особые заголовки в ответ
  • Браузер добавит заголовок Origin с адресом страницы, откуда инициирован запрос. Подделать заголовок скриптом не удастся
  • Т.е. по факту я в своём приложении создаю AJAX запрос с опр. набором параметров (заголовки и т.д.), и если сервер поддерживает CORS - он пришлёт ответ

  
  

• Простые и сложные CORS-запросы

  • Простые
    • может быть сделан через <form> или <script>, без каких-то специальных методов. Таким образом, даже очень старый сервер должен быть способен принять простой запрос.
    • Простой метод: GET, POST или HEAD
    • Простые заголовки – разрешены только:
      • Accept,
      • Accept-Language,
      • Content-Language,
      • Content-Type со значением application/x-www-form-urlencoded, multipart/form-data или text/plain.
  • Сложные
    • идут в два этапа: preflight запрос и собственно запрос.
    • Сначала браузер делает запрос по тому же урлу, но методом OPTIONS.
    • Сервер должен ответить: какими другими методами и дополнительными заголовками (помимо стандартных) можно обращаться к этому урлу.
    • Только получив разрешение, браузер сделает запрос на основной урл.
    • Запрашиваешь JSON - автоматически должен использовать сложный запрос
  • Технология CORS может быть использована как более современная и надёжная альтернатива JSONP, так как позволяет использовать все преимущества XMLHttpRequest, и не имеет риска инъекции, как JSONP. С другой стороны, технология CORS поддерживается только современными браузерами, а JSONP работает и в старых тоже.
  • Механизм CORS поддерживает кросс-доменные запросы и передачу данных между браузером и web-серверами по защищенному соединению.
  • Современные браузеры используют CORS в API-контейнерах, таких как XMLHttpRequest или Fetch, чтобы снизить риски, присущие запросам с других источников.

  
  

• Альтернативы AJAX

  • Java-апплеты, позднее технология JavaFX;
  • Технология Silverlight корпорации Microsoft;
  • Протокол WebSocket.

  
  

• Ссылки

  • Habr - CORS для чайников: история возникновения, как устроен и оптимальные методы работы (2021)
  • Гришаев - Руководство по кросс-доменным запросам CORS (2016)
  • Wikipedia - CORS
  • MDN - CORS
  • Habr - CORS для чайников: история возникновения, как устроен и оптимальные методы работы

  
  

COMET *

• Общее

  • Общий термин, описывающий различные техники получения данных по инициативе сервера.
  • Когда дело доходит до доставки данных с сервера клиенту, мы ограничены двумя основными подходами: client pull или server push. В качестве простого примера веб-приложения можно привести браузер. Когда сайт, открытый в браузере запрашивает с сервера данные, это называется client pull. Обратная технология, когда сервер активно перенаправляет обновления на сайт, называется server push.
  • Методика отправки данных по инициативе сервера, разработанная поверх AJAX.
  • Можно сказать, что AJAX – это «отправил запрос – получил результат», а COMET – это «непрерывный канал, по которому приходят данные».
  • COMET можно реализовать по протоколу JSONP. Можно и иначе.
  • COMET - методика отправки данных по инициативе сервера, разработанная поверх AJAX.

  
  

• Примеры COMET-приложений

  • Чат – человек сидит и смотрит, что пишут другие. Новые сообщения приходят «сами по себе», не надо жать кнопку для обновления окна.
  • Аукцион – человек смотрит на экран и видит, как обновляется текущая ставка за товар.
  • Интерфейс редактирования – когда один редактор начинает изменять документ, другие видят информацию об этом. Совместное редактирование.

  
  

• Какие API предоставляет браузер для взаимодействия COMET?

  • SSE API (server-side events) — события посылаемые сервером. Однонаправленное HTTP-подключение к серверу. Поддерживают короткие запросы, длинные запросы, потоковое подключение к серверу.
  • Web Sockets API — двунаправленное взаимодействие с сервером. Работает по собственному протоколу.
  • Страница не просто разово или циклично запрашивает контент с сервера, а создает с сервером постоянное HTTP-соединение и ждет от него передачи данных. Это позволяет пользователям веб-приложения более оперативно получать все возникающие на сервере события (пример - мгновенное уведомление о новом сообщении в социальных сетях).
  • В идеальном варианте для этого на сервере разворачивается специальное программное обеспечение, сам сервер особым образом конфигурируется, а на клиентской части используются специальные библиотеки для обмена данными. Это если рассматривать использование COMET в контексте больших и серьезных проектов. Для рядового сайта, размещенного на обычном хостинге с ограничением времени исполнения скрипта, можно сделать облегченный аналог COMET.

  
  

• Polling

  • Использование периодических запросов к серверу через AJAX. Например, скрипт из браузера каждые 5 секунд отправляет запрос на серверный скрипт и запрашивает количество новых непрочитанных сообщений.
    
  • Можно дополнительно снизить нагрузку на сервер путем снижения частоты отсылаемых запросов, но это опять же пойдет в ущерб актуальности данных и в разрез с условием задачи о мгновенном информировании пользователя о письме.

  
  

• Long polling

  • Вариант реализации COMET.
  • Есть несколько вариантов реализации, но, к сожалению, практически все они завязаны на конкретном браузере и ведут себя по-своему.
  • Единственным кроссбраузерным и гарантированно работающим решением является так называемая "очередь длинных запросов", или "long polling".
  • Сначала браузер отправляет AJAX-запрос на сервер и ожидает ответа. Соединение остается открытым до тех пор, пока на сервере не наступит ожидаемое событие (или, как в нашем случае, пока серверный скрипт не отвалится по таймауту). Сразу после наступления события данные отправляются в браузер и соединение закрывается. Браузер после получения данных сразу же открывает новое соединение и все повторяется.
  • Это очень похоже на предыдущий способ "polling", но данные с сервера передаются с максимально возможной актуальностью.
  • Если за время ожидания никаких событий на сервере не случилось, интервал между "долгими" запросами будет гораздо больше, чем при долбежке сервера периодическими опросами. Поэтому еще более минимизируются расходы на передачу заголовков запросов, тем самым еще больше снижается нагрузка на сервер.

  
  

WebSocket

• Общее

  • Новый протокол для пересылки любых данных, на любой домен, безопасно и почти без лишнего сетевого трафика. Замена AJAX.
  • Один из API браузера, который он предоставляет чтоб реализовать COMET.
  • Веб-сокеты — прямое соединения между сервером и клиентом, чтобы сервер мог сообщать когда он обновляется.
  • Протокол связи поверх TCP. Для обмена данными между браузером и сервером через постоянное соединение. Данные передаются по нему в обоих направлениях в виде «пакетов», без разрыва соединения и дополнительных HTTP-запросов. Должен поддерживаться клиентом (браузер) и сервером
  • В качестве единственной разрешенной кодировки выбрана UTF-8
  • Проверить поддержку браузером WebSocket можно, пройдя по ссылке: http://caniuse.com/#feat=websockets.
  • Альтернатива - SSE (server-side events) API.

  
  

• Прочее

  • WebSocket - протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером в режиме реального времени.
  • Предназначен для решения любых задач и снятия ограничений обмена данными между браузером и сервером.
  • независимый протокол, основанный на протоколе TCP
  • Не стоит использовать веб-сокеты в REST API, поскольку вам хватит таких HTTP-запросов, как GET, POST, DELETE и PUT.
  • В отличие от CORS работает вообще без AJAX, отдельный протокол, даже на HTTP
  • Протокол WebSocket работает над TCP также как и HTTP. Т.е. на том же уровне, что и HTTP, заменяет его, а не "поверх него"
  • AJAX работает на HTTP
  • Это означает, что при соединении браузер отправляет по HTTP специальные заголовки, спрашивая: «поддерживает ли сервер WebSocket?».
  • Если сервер в ответных заголовках отвечает «да, поддерживаю», то дальше HTTP прекращается и общение идёт на специальном протоколе WebSocket, который уже не имеет с HTTP ничего общего.
  • Соединение WebSocket можно открывать как WS:// или как WSS://. Протокол WSS представляет собой WebSocket над HTTPS.
  • Кроме большей безопасности, у WSS есть важное преимущество перед обычным WS – большая вероятность соединения.
  • Дело в том, что HTTPS шифрует трафик от клиента к серверу, а HTTP – нет.
  • Если между клиентом и сервером есть прокси, то в случае с HTTP все WebSocket-заголовки и данные передаются через него. Прокси имеет к ним доступ, ведь они никак не шифруются, и может расценить происходящее как нарушение протокола HTTP, обрезать заголовки или оборвать передачу.
  • А в случае с WSS весь трафик сразу кодируется и через прокси проходит уже в закодированном виде. Поэтому заголовки гарантированно пройдут, и общая вероятность соединения через WSS выше, чем через WS.
  • Это сдвиг парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать.
  • Как только ваша страница решила, что она хочет открыть веб сокет на сервер, она создает специальный javascript-объект WebSocket и навешивает на новый объект три колл-бека:
    • первый вызовется, когда соединение будет установлено:
    • второй - когда соединено закроется
    • третий - каждый раз, когда браузер получает какие-то данные через веб-сокет
  • Браузер подключается по протоколу TCP на 80 порт сервера и дает немного необычный GET-запрос
  • Если сервер поддерживает ВебСокеты, то он отвечает опр. образом
  • Если браузер это устраивает, то он просто оставляет TCP-соединение открытым. Все — «рукопожатие» совершено, канал обмена данными готов.
  • Как только одна сторона хочет передать другой какую-то информацию, она отправляет дата-фрей. Это просто строка текста — последовательность байт. Никаких заголовков, метаданных! Что именно отправлять, разработчики полностью оставили на ваше усмотрение: хотите XML, хотите JSON, да хоть стихи Пушкина.
  • Каждый раз, когда браузер будет получать такое сообщение, он будет «дергать» ваш колл-бек onmessage.
  • Легко понять, что КПД такого протокола стремится к 95%. Это не классический AJAX-запрос, где на каждую фитюльку приходится пересылать несколько килобайт заголовков. Разница будет особенно заметна если делать частый обмен небольшими блоками данных. Скорость обработки так же стремится к скорости чистого TCP-сокета — ведь все уже готово — соединение открыто — всего лишь байты переслать.
  • А картинку можно отправить? Да. С помощью WebSockets так же можно передавать и бинарные данные. Для них используется другой дата-фрейм опр. вида

  
  

• Скорость и эффективность

  • Высокую скорость и эффективность передачи обеспечивает малый размер передаваемых данных, который иногда даже будет помещаться в один TCP-пакет — здесь, конечно, же все зависит от вашей бизнес-логики.
  • Так же учтите, что соединение уже готово — не надо тратить время и трафик на его установление, хендшейки, переговоры.

  
  

• Стандартность

  • Самим своим выходом WebSockets отправит на свалку истории Comet и все приблуды накрученные поверх него — Bayuex, LongPolling, MultiPart и так далее. Это все полезные технологии, но по большей части, они работают на хаках, а не стандартах. Отсюда периодески возникают проблемы

  
  

• Время жизни канала

  • В отличие от HTTP веб-сокеты не имеют ограничений на время жизни в неактивном состоянии. Это значит, что больше не надо периодически рефрешить соединение, т.к. его не вправе «прихлопывать» всякие прокси. Значит, соединение может висеть в неактивном виде и не требовать ресурсов. Конечно, можно возразить, что на сервере будут забиваться TCP-сокеты. Для этого достаточно использовать хороший мультиплексор, и нормальный сервер легко потянет до миллиона открытых коннектов.

  
  

• Комплексные веб-приложения

  • Как известно в HTTP предусмотрено ограничение на число одновременных октрытых сессий к одному серверу. Из-за этого если у вас много различных асинхронных блоков на странице, то вам приходилось делать не только серверный, но и клиентский мультиплексор — именно отсюда идет Bayeux Protocol.
  • К счастью, это ограничение не распространяется на веб-сокеты. Открываете столько, сколько вам нужно. А сколько использовать — одно (и через него все мультиплексировать) или же наоборот — на каждый блок свое соединение — решать вам. Исходите из удобства разработки, нагрузки на сервер и клиент.

  
  

• Кросс-доменные приложения

  • Еще один «камень в ботинке» AJAX-разработчика — проблемы с кросс-доменными приложениями. Да, и для них тоже придумана масса хаков. Помашем им ручкой и смахнем скупую слезу. WebSockets не имеет таких ограничений. Ограничения вводятся не по принципу «из-того-же-источника», а из «разрешенного-источника», и определяются не на клиенте, а на сервере. Думаю, внимательные уже заметили новый заголовок Origin. Через него передается информация откуда хотят подключиться к вашему websocket-у. Если этот адрес вас не устраивает, то вы отказываете в соединение.

  
  

• WebSocket и SSE

  • Насколько я понимаю, сейчас WebSocket - не самая актуальная технология. При прочих равных лучше использовать HTTP/2+SSE.
  • Несмотря на чрезвычайно широкое распространение связки HTTP/2+SSE, технология WebSocket, совершенно определённо, не исчезнет, в основном из-за того, что она отлично освоена и из-за того, что в весьма специфических случаях у неё есть преимущества перед HTTP/2, так как она была создана для обеспечения двустороннего обмена данными с меньшей дополнительной нагрузкой на систему (например, это касается заголовков).
  • Предположим, вы хотите создать онлайн-игру, которая нуждается в передаче огромного количества сообщений между клиентами и сервером. В подобном случае WebSocket подойдёт гораздо лучше, чем комбинация HTTP/2 и SSE.
  • В целом, можно порекомендовать использование WebSocket для случаев, когда нужен по-настоящему низкий уровень задержек, приближающийся, при организации связи между клиентом и сервером, к обмену данными в реальном времени. Помните, что такой подход может потребовать переосмысления того, как строится серверная часть приложения, а также то, что тут может потребоваться обратить внимание на другие технологии, вроде очередей событий.
  • Если вам нужно, например, показывать пользователям в реальном времени новости или рыночные данные, или вы создаёте чат-приложение, использование связки HTTP/2+SSE даст вам эффективный двунаправленный канал связи, и, в то же время — преимущества работы с технологиями из мира HTTP. А именно, технология WebSocket нередко становится источником проблем, если рассматривать её с точки зрения совместимости с существующей веб-инфраструктурой, так как её использование предусматривает перевод HTTP-соединения на совершенно другой протокол, ничего общего с HTTP не имеющий. Кроме того, тут стоит учесть соображения масштабируемости и безопасности. Компоненты веб-систем (файрволы, средства обнаружения вторжений, балансировщики нагрузки) создают, настраивают и поддерживают с оглядкой на HTTP. В результате, если говорить об отказоустойчивости, безопасности и масштабируемости, для больших или очень важных приложений лучше подойдёт именно HTTP-среда.

  
  

• Протокол wss

  • Также существует протокол wss://, использующий шифрование. Это как HTTPS для веб-сокетов.

  
  

• Ссылки

  • Как работает JS: WebSocket и HTTP/2+SSE. Что выбрать?
  • Использование SSE вместо WebSockets для однонаправленного потока данных через HTTP / 2
  • Wikipedia
  • Learn js
  • WebSockets not Bound by SOP and CORS? Does this mean…

  
  

Хранение данных в браузере: Cookie, socalStorage, sessionStorage*

• Cookie

  • Куки (cookie) – небольшие строки данных (текстовые файлы), хранятся непосредственно в браузере.
  • Являются частью HTTP-протокола, определённого в спецификации RFC 6265.
  • Обычно устанавливаются веб-сервером при помощи заголовка Set-Cookie.
    
  • Затем браузер будет автоматически добавлять их в (почти) каждый запрос на тот же домен при помощи заголовка Cookie.
  • Браузер хранит как миниммум один отдельный куки-файл для каждого сервера с которым взаимодействовал.
  • При каждом обмене данными браузер отправляет куки-файл на сервер (с запросом), а сервер возвращает файл (с ответом).
  • Данные в куки-файле хранятся в формате ключ-значение.
  • Значение может быть зашифровано на стороне сервера. Т.е. хранится не в открытом виде, а в виде зашифрованного набора символов.
  • Куки разных сайтов не могу взаимодействовать между собой
  • Можно читать и писать в куки из JS-кода alert( document.cookie );, document.cookie = "user=John";
    
  • Общее количество куки на один домен ограничивается примерно 20+. Точное ограничение зависит от конкретного браузера.
  • Если куки не имеет спец. параметра - удаляются после закрытия браузера (сессионные куки).
  • Чтобы сохранить куки после закрытия браузера — используются опции expires или max-age.
  • Сторонние куки - размещены с домена, отличающегося от страницы, которую посещает пользователь.
  • в силу своей специфики обычно используются для целей отслеживания посещаемых пользователем страниц и показа рекламы.

  
  

• Аутентификация через cookies

  • При входе на сайт сервер отсылает в ответ HTTP-заголовок Set-Cookie для того, чтобы установить куки со специальным уникальным идентификатором сессии («session identifier»).
  • Во время следующего запроса к этому же домену браузер посылает на сервер HTTP-заголовок Cookie.
  • Таким образом, сервер понимает, кто сделал запрос.

  
  

• Объекты веб-хранилища «localStorage» и «sessionStorage»

  • Объекты веб-хранилища localStorage и sessionStorage позволяют хранить пары ключ/значение в браузере.
  • Отличия от cookies
    • Не отправляются на сервер при каждом запросе => можем хранить гораздо больше данных. Как минимум 5 мегабайтов данных.
    • Сервер не может манипулировать объектами хранилища через HTTP-заголовки. Всё делается при помощи JavaScript.
    • Хранилище привязано к источнику (домен/протокол/порт) — разные протоколы или поддомены определяют разные объекты хранилища, и они не могут получить доступ к данным друг друга.

  
  

• localStorage

  • Объект один на все вкладки и окна в рамках источника (один и тот же домен/протокол/порт).
  • Данные не имеют срока давности, по которому истекают и удаляются. Сохраняются после перезапуска браузера и даже ОС.

  
  

• sessionStorage

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

  
  

• Ссылки

  • learn.javascript.ru - Cookie
  • learn.javascript.ru - LocalStorage, sessionStorage
  • IT-Kamasutra - Ликбез из тачиллы. #3 Авторизация с помощью Cookie
  • IT-Kamasutra - Ликбез из тачиллы. #2 Cookie Куки - введение

  
  

SSE API (Server-Sent events)

• Ещё один вариант API, который предоставляет браузер для взаимодействия COMET.
• Механизм, который позволяет серверу асинхронно отправлять данные клиенту после установления клиент-серверного соединения.
• События посылаемые сервером, т.е. однонаправленное HTTP-подключение к серверу.
• Альтернатива WebSocket.
• Технология SSE основана на HTTP, т.е. нет необходимости вводить новый протокол (WebSocket) - а это важное преимущество (безопасность, простоат, настройка сервера)
  • Отлично работате с HTTP/2
  • Несмотря на чрезвычайно широкое распространение связки HTTP/2+SSE, технология WebSocket, совершенно определённо, не исчезнет, в основном из-за того, что она отлично освоена и из-за того, что в весьма специфических случаях у неё есть преимущества перед HTTP/2, так как она была создана для обеспечения двустороннего обмена данными с меньшей дополнительной нагрузкой на систему (например, это касается заголовков).
• Предположим, вы хотите создать онлайн-игру, которая нуждается в передаче огромного количества сообщений между клиентами и сервером. В подобном случае WebSocket подойдёт гораздо лучше, чем комбинация HTTP/2 и SSE.
• В целом, можно порекомендовать использование WebSocket для случаев, когда нужен по-настоящему низкий уровень задержек, приближающийся, при организации связи между клиентом и сервером, к обмену данными в реальном времени. Помните, что такой подход может потребовать переосмысления того, как строится серверная часть приложения, а также то, что тут может потребоваться обратить внимание на другие технологии, вроде очередей событий.
• Если вам нужно, например, показывать пользователям в реальном времени новости или рыночные данные, или вы создаёте чат-приложение, использование связки HTTP/2+SSE даст вам эффективный двунаправленный канал связи, и, в то же время — преимущества работы с технологиями из мира HTTP. А именно, технология WebSocket нередко становится источником проблем, если рассматривать её с точки зрения совместимости с существующей веб-инфраструктурой, так как её использование предусматривает перевод HTTP-соединения на совершенно другой протокол, ничего общего с HTTP не имеющий. Кроме того, тут стоит учесть соображения масштабируемости и безопасности. Компоненты веб-систем (файрволы, средства обнаружения вторжений, балансировщики нагрузки) создают, настраивают и поддерживают с оглядкой на HTTP. В результате, если говорить об отказоустойчивости, безопасности и масштабируемости, для больших или очень важных приложений лучше подойдёт именно HTTP-среда.
• Ссылки
  • Как работает JS: WebSocket и HTTP/2+SSE. Что выбрать?
  • Использование SSE вместо WebSockets для однонаправленного потока данных через HTTP / 2

XMLHttpRequest (XHR)

• Объект, который дает возможность браузеру из JavaScript делать HTTP-запросы к серверу без перезагрузки страницы.

  • Все современные браузеры (IE7+, Firefox, Chrome, Safari и Opera) имеют встроенный объект XMLHttpRequest.
  • Может работать с синхронными и асинхронными запросами
  • Как правило, XMLHttpRequest используют для загрузки данных.

• В современной веб-разработке XMLHttpRequest используется по трём причинам:

  • По историческим причинам: существует много кода, использующего XMLHttpRequest, который нужно поддерживать.
  • Необходимость поддерживать старые браузеры и нежелание использовать полифилы (например, чтобы уменьшить количество кода).
  • Потребность в функционале, который fetch пока что не может предоставить, к примеру, отслеживание прогресса отправки на сервер.

• XMLHttpRequest может осуществлять запросы на другие сайты, используя ту же политику CORS, что и fetch.

• Ссылки

  • https://learn.javascript.ru/xmlhttprequest
  • https://learn.javascript.ru/ajax-xmlhttprequest

Fetch

• Встроенный метод браузера для AJAX-запросов, замена XMLHttpRequest.

• Гораздо мощнее, чем httpGet.

• Использует промисы. Возвращает промис, который, когда получен ответ, выполняет коллбэки с объектом Response или с ошибкой, если запрос не удался.

• Ссылки

  • https://learn.javascript.ru/fetch

Документация API при помощи RAML

• Специализированный язык для описания REST API

• В частности, его используют для описания документации IT-Kamasutra

• Ссылки

  • Habr - Пишем документацию API при помощи RAML

Ссылки

• Сети в вопросах и ответах. HTTP-протокол. AJAX. JSONP. CORS.COMET
• Как работает JS: WebSocket и HTTP/2+SSE. Что выбрать?
• Как работает JS: сетевая подсистема браузеров, оптимизация её производительности и безопасности
• Основы TCP/IP для будущих дилетантов

Legmo, 2019-2023