Web. TCP/IP

1.

Web

2.

TCP/IP

3.

Канальный уровень
Сеть представляет множество связанных между собой хостов.
Хостом является устройство, которое имеет интерфейс
Интерфейс - это устройство, через которое происходит соединение с сетью (прием и
отправка сообщений). Физический интерфейс принимает фреймы, а логический - IPпакеты
Физический интерфейс идентифицируется MAC адресом, а логический - IP адресом
Логический интерфейс не может передавать данные, для этого он использует
физический интерфейс
Ethernet, wi-fi и прочие протоколы являются протоколами канального уровня, которые
регламентируют физическую передачу данных

4.

Сетевой уровень
Каждый IP-адрес это 32 бита (есть и другие версии, например 6-байтовая)
Первые n бит несут информацию о том, к какой подсети принадлежит хост,
оставшиеся - уникальный адрес хоста в данной подсети
Адрес в подсети определяется маской подсети

5.

Транспортный уровень
TCP - требует надежной связи между хостами, отвечает за упорядочение пакетов при
отправке и восстановление утраченных пакетов, требует подтверждения доставки
UDP - обеспечивает передачу без подтверждения доставки, не гарантирует
упорядоченности и не восстанавливает утраченные пакеты
UDP используется там, где допускается потеря/дублирование данных, например при
передаче видео/аудио данных
TCP используется там, где нужна гарантия доставки

6.

Прикладной уровень - HTTP
HTTP - гипертекстовых протокол передачи данных, который передает данные в виде
простого текста
Протокол не сохраняет состояние между запросами. Сервер просто не понимает, от
одного клиента поступаю запросы, или от разных.
HTTPS - это тот же HTTP, только данные передаются в зашифрованном с помощью
SSL или TLS виде
Есть проблема с HTML, так как формы позволяют отправлять только GET и POST

7.

TCP/IP vs OSI
1. OSI - юридический стандарт, TCP/IP - фактический
2. OSI мало где используется, в основном для описания как работают различные сети,
например телефонная сигнализация, TCP/IP широко применяется, основа интернета

8.

Шифрование
1. Симметричное - у клиента и у сервера один и тот же ключ, с помощью которого они
шифруют и расшифровывают сообщения
2. Ассиметричное - у клиента и у сервера генерируются по 2 ключа - закрытый и открытый. С
помощью открытого мы можем зашифровывать информацию, с помощью закрытого расшифровывать. Открытые ключи передаются свободно, поскольку даже если его
перехватят, то расшифровать информацию с его помощью невозможно.

9.

10.

SOA
1. SOA - набор архитектурных принципов, не зависящих от технологий и продуктов, которые
можно свести к идеям:
a. Сочетаемость приложений, ориентированных на пользователей
b. Многократное использование бизнес-сервисов
c. Независимость от технологий
d. Автономность - независимая эволюция, масштабируемость и развертывание
сервисов.
2. Реализацией SOA являются ESB, веб-сервисы, микросервисы, очереди сообщений

11.

SOAP
1. SOAP (Simple Object Access Protocol) - протокол для обмена информацией на основе
XML.
2. В отличии от REST, является протоколом, следовательно, сервисы должны
выполнять набор строгих правил
3. Привязан к WSDL, который используется для описания сервисов.

12.

SOAP: Структура сообщения

13.

SOAP
Преимущества:
● платформонезависимый
● защищенный
● можно использовать, когда нужно сохранять состояние
● Поддерживает HTTP, SMTP, FTP и пр, в отличии от REST
Недостатки:
● Медленный, так как xml разрастается и, как следствие, требует время и ресурсов для
парсинга
● Жестко связан с WSDL
● Не может кэшировать вызовы
Используется:
● В компаниях, которым нужны более продвинутые функции безопасности корпоративного
уровня, так как в сам протокол встроена логика обработки ошибок.
● Там, где требуются более высокие стандарты безопасности, так как SOAP использует WSSecurity (протокол, который обеспечивает безопасность передачи данных на уровне
сообщений, а также поддерживающий ACID).
● В Банках для передачи чувствительных данных, например, пин-кодов

14.

REST
Является архитектурным стилем для построения веб-сервисов, ориентированных на HTTP в
качестве прикладного протокола. По-сути является набором рекомендаций, который позволяет
унифицировать взаимодействие клиентский и серверных приложений.
Особенности:
● простой
● быстрый
● гибкий
● масштабируемый

15.

Требования REST к использованию HTTP глаголов
POST - создание ресурса
GET - чтение
PUT - обновление с полным payload
PATCH - обновление с частичным payload
DELETE - удаление ресурса
Другие HTTP глаголы:
● HEAD - получение заголовков (как GET, только без тела ответа)
● CONNECT - запускает двустороннюю связь с ресурсом, можно использовать для создания
туннеля
● OPTIONS - используется для описания параметров соединения с ресурсом, например,
можно узнать какие методы поддерживает ресурс
● TRACE - для проверки обратной связи ресурса, по-сути, для тестирования

16.

Рекомендации по нэймингу урлов
ресурс всегда во множественном числе
○ GET /users
○ PUT /users/{id}
URI состоит из существительных, глаголы включаются только в крайнем случае, для
уникальных операций, которые не описать существительным
○ /books/{id}/clean
одно слово для действия
○ /getAllCars - плохо
○ /cars - хорошо
фильтрация
○ /books?color=red
сортировка
○ /books?sort=-year,+name
пагинация
○ /books?limit=5&offset=10

17.

Свойства HTTP методов
1. Безопасный метод - тот, который не меняет состояния сервера (GET, HEAD, OPTIONS)
2. Идемпотентный метод - тот метод, повторный вызов которого, один или несколько раз
подряд, имеет один и тот же эффект на сервер. Все безопасные методы являются
идемпотентными + PUT, DELETE. PATCH не является идемпотентным, так как, согласно
спецификации, может менять смежные ресурсы и создавать новые объекты, если не
найдет ресурс для обновления.
3. Кэшируемый метод - ответ которого кэшируется

18.

Принципы REST
1. Клиент-серверная архитектура - отделение клиента от сервера, клиент никак не
привязан к серверу, что дает нам гибкость и масштабируемость
2. Stateless - отсутствие сохранения состояния
3. Кэшируемость - может кэшировать запросы
4. Единообразие интерфейса - HATEOAS
5. Слоистая архитектура - между клиентом и сервером могут быть посредники (например
балансировщик или proxy-сервер). При правильном построении слоистой архитектуры
слои не будут влиять друг на друга, т.е., например, при изменении логики в proxy-сервере,
ни клиент, ни сервер об этом даже не узнают
6. Code on demand - клиент может получить от сервера код, который сам может исполнить
(например какой-нибудь js-скрипт, который выполняется на стороне клиента).
Единственное необязательное требование к RESTful сервису.

19.

Зрелость RESTful сервиса
0 уровень - один URI и один HTTP глагол,
т.е. игнорируются как уникальные
идентификаторы ресурсов (все идет через
один endpoint, так и глаголы HTTP)
1 уровень - глаголы игнорируются, но уже
несколько URI
2 уровень - используем уникальные URI и
правильно используем HTTP глаголы
3 уровень - используем HATEOAS

20.

Материалы
1. “Компьютерные сети” курс Андрея Созыкина
https://www.youtube.com/watch?v=OLFA0soYGhw&list=PLtPJ9lKvJ4oiNMvYbOzCmWy6cRzY
Ah9B1&ab_channel=AndreySozykin
2. Полезная статья по сетям и интернету https://habr.com/ru/companies/ruvds/articles/759988/
3. гайд по HTTP https://habr.com/ru/companies/avito/articles/710660/
4. SOA https://habr.com/ru/companies/vk/articles/342526/
5. SOAP https://appmaster.io/ru/blog/mylo-protiv-otdykha
6. REST https://habr.com/ru/articles/590679/
7. SOAP vs REST https://clck.ru/39zBCQ
8. HTTP глаголы https://developer.mozilla.org/ru/docs/Web/HTTP/Methods
9. Рекомендации нейминга урлов https://clck.ru/39zCm6
10. Список HTTP кодов https://clck.ru/39zCoQ
11. Краткое объяснение принципов TSL, SSL, HTTPS
https://www.youtube.com/watch?v=j9QmMEWmcfo&ab_channel=ByteByteGo