Skip to content

HTTP

HTTP⚑

Що відбувається, коли ви вводите URL-адресу в браузері та натискаєте Enter? [💡10/100]⚑

Коли ви вводите URL-адресу в браузері та натискаєте Enter, відбувається наступна послідовність дій

  • DNS-резолвінг
    • DNS (Domain Name System) — це система, яка перекладає доменні імена (наприклад, example.com) у відповідні IP-адреси (наприклад, 93.184.216.34).
    • Браузер запитує DNS-сервер, щоб отримати IP-адресу, яка відповідає введеному доменному імені. Якщо адреса є в кеші (браузера або операційної системи), запит до DNS-сервера може не виконуватися.
      • Якщо адреса не знайдена в кеші, запит передається рекурсивному DNS-серверу (зазвичай це сервер провайдера або публічний DNS, як-от Google DNS).
      • Рекурсивний сервер звертається до кореневих серверів, які вказують на авторитетні сервери для домену верхнього рівня (наприклад, .com).
      • Рекурсивний сервер далі запитує авторитетний сервер для конкретного домену (example.com) і отримує IP-адресу.
    • URL (Uniform Resource Locator) веб-сайту - адреса файлу або ресурсу, який потрібен браузеру для відображення веб-сторінки.
    • Повна URL-адреса зазвичай має таку структуру
      • http:// повідомляє браузеру, що доступ до сторінки має відбуватись за допомогою Hyper Text Transfer Protocol (HTTP). Це протокол, який використовується браузерами для взаємодії з веб-сторінками. Інші протоколи мають інші цілі, наприклад, ftp:// (File Transfer Protocol) — це протокол, який використовується для передачі файлів через Інтернет. https:// - захищена версія http://.
      • dou.ua - це доменне ім’я; воно представляє сервер, на якому знаходяться всі дані для dou.ua.
      • /index.html — шлях до файлу, який буде відображено браузером.
  • Встановлення з’єднання
    • Коли браузер отримує IP-адресу, відбувається встановлення мережевого з’єднання.
    • Використовується протокол TCP або UDP. Для HTTPS з’єднання створюється безпечний канал через TLS/SSL.
    • TCP Handshake — це триетапний процес встановлення надійного з’єднання
      • SYN: Клієнт відправляє серверу запит на встановлення з’єднання.
      • SYN-ACK: Сервер підтверджує отримання запиту клієнта та надсилає відповідь.
      • ACK: Клієнт підтверджує отримання відповіді сервера, і з’єднання встановлено.
    • Якщо використовується HTTPS, після TCP Handshake починається шифрування даних за допомогою TLS (Transport Layer Security)
      • Браузер запитує цифровий сертифікат сервера.
      • Сертифікат перевіряється на дійсність через центр сертифікації (CA).
      • Відбувається обмін ключами для встановлення безпечного каналу.
    • TCP/IP (Transmission Control Protocol/Internet Protocol) — це набір протоколів, які лежать в основі роботи Інтернету та локальних мереж. TCP/IP забезпечує комунікацію між комп'ютерами, їхню адресацію та передачу даних у мережі.
    • TCP забезпечує доставку всіх пакетів у правильному порядку.
      • Дані розбиваються на сегменти й відправляються.
      • Сервер надсилає підтвердження (ACK) для кожного отриманого сегмента.
    • IP протокол маршрутизує пакети через мережу до сервера й назад.
      • Кожен пристрій має унікальну IP-адресу.
      • Данні розбиваються на пакети, які маршрутизуються через мережу до місця призначення.
      • Пакети можуть слідувати різними маршрутами, але збираються в правильному порядку на боці отримувача.
  • Відправлення HTTP-запиту
    • Після успішного встановлення TCP/TLS браузер відправляє перший HTTP-запит до сервера.
    • Браузер формує HTTP або HTTPS-запит до сервера, вказуючи тип методу (GET, POST тощо), заголовки та параметри.
  • Обробка запиту сервером
    • Сервер отримує запит і обробляє його, звертаючись до внутрішніх сервісів, баз даних або кешу, щоб сформувати відповідь.
    • Перед сервером може стояти балансувальник навантажень, який вирішує, на який сервер перенаправити запит. Зазвичай для визначення використовують алгоритм Round Robin: якщо є 3 сервери (A, B і C), перший запит надходить до A, другий — до B, третій — до C, четвертий — до A і т.д. Використання балансувальника навантаження допомагає підтримувати працездатність програми, не перекладаючи все навантаження трафіку на один сервер.
  • Відправлення HTTP-відповіді
    • Сервер повертає відповідь із кодом стану (200 OK, 404 Not Found тощо), заголовками та основним вмістом (HTML, JSON, зображення тощо).
  • Рендеринг сторінки
    • Браузер обробляє отриманий HTML, завантажує додаткові ресурси (CSS, JavaScript, зображення) і виконує JavaScript-код.
  • Створення DOM
    • HTML-документ перетворюється на дерево DOM, яке браузер використовує для побудови графічного інтерфейсу.
  • Підключення додаткових ресурсів
    • Завантаження шрифтів, медіа-файлів, API-запитів для динамічного контенту.
  • Інтерактивність
    • Виконуються події та скрипти, що додають інтерактивність до сторінки.

Links

Що таке протокол передачі даних? Які існують протоколи передачі даних [💡19/100]⚑

Summary

Протокол передачі даних - це набір правил та стандартів, які визначають спосіб, які визначають як дані між комп'ютерами чи пристроями в мережі будуть передаватись. Він описує формат даних, порядок їх передачі, засоби ідентифікації та аутентифікації, а також способи управління та вирішення конфліктів під час передачі. Протоколи передачі даних визначають правила взаємодії, які дозволяють різним системам ефективно та надійно спілкуватися у мережі.

Деякі з популярних протоколів

  • HTTP (Гіпертекстовий протокол): Використовується для передачі веб-сторінок та ресурсів в Інтернеті.
  • HTTPS (Захищений гіпертекстовий протокол): Безпечна версія HTTP, яка використовує шифрування для захисту даних.
  • FTP (Протокол передачі файлів): Дозволяє передавати файли між комп'ютерами.
  • SMTP (Протокол передачі пошти): Використовується для відправки електронної пошти.
  • POP3 (Протокол отримання пошти, версія 3): Використовується для отримання електронної пошти з сервера.
  • IMAP (Протокол доступу до пошти в Інтернеті): Дозволяє управляти електронною поштою на сервері.
  • TCP/IP (Протоколи передачі керованих даних/Інтернет-протокол): Основні протоколи Інтернету для передачі та маршрутизації даних.
  • DNS (Система доменних імен): Використовується для перетворення доменних імен на IP-адреси.

TCP/IP [💡11/100]⚑

TCP/IP (Transmission Control Protocol/Internet Protocol) - це набір протоколів, які працюють разом для забезпечення передачі даних між комп'ютерами в мережі.

Cкладається з двох основних протоколів

  • IP - відповідає за адресацію і маршрутизацію пакетів даних за допомогою IP-адрес. Між двома хостами (машинами) створюється тунель передачі даних. Дані передаються пакетами. Пакети можуть проходити через кілька проміжних вузлів, перш ніж досягти кінцевого призначення. Але проблема в тому, що пакети можуть загубитись по дорозі, пошкодитись, дублюватись, можуть прийти в неправильному порядку.
  • TCP - транспортний протокол, який забезпечує надійну передачу даних. Гарантує, що дані будуть доставлені в правильному порядку і без помилок. TCP розбиває дані на сегменти, які відправляються по мережі, а потім збирає їх назад на стороні отримувача. Якщо якихось пакетів не вистачає, він робить повторний запит. Якщо прийшли дублі - він забирає ці дублі. Використовує порти для адресації.

IP-адреса - це унікальний ідентифікатор, який використовується для ідентифікації пристроїв у мережі.

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

Порти діляться на три основні категорії

  • Зарезервовані порти (0-1023): Використовуються для добре відомих сервісів, таких як HTTP (порт 80), HTTPS (порт 443) або FTP (порт 21).
  • Реєстровані порти (1024-49151): Призначені для використання додатками, які потребують реєстрації.
  • Динамічні або приватні порти (49152-65535): Призначені для тимчасового використання користувацькими процесами.

Сокети⚑

Summary

Сокет - кінцева точка двостороннього мережевого зв'язку й водночас об'єкт операційної системи (файловий дескриптор). З'єднання однозначно визначає п'ятірка (протокол, локальний IP, локальний порт, віддалений IP, віддалений порт), тому на одному порту сервера співіснують тисячі одночасних з'єднань. Тип сокета задає протокол: SOCK_STREAM - TCP (надійний потік байтів), SOCK_DGRAM - UDP (датаграми без гарантій).

Сокет як дескриптор. Сокет - такий самий файловий дескриптор, як відкритий файл чи pipe, тож над ним працюють read/write і, головне, механізми мультиплексування (select/epoll). Саме тому один потік у epoll_wait обслуговує десятки тисяч сокетів - це основа C10k і event loop.

Сімейство адрес і тип. Сокет створюють із сімейством адрес і типом:

  • AF_INET / AF_INET6 - IPv4 / IPv6; AF_UNIX - локальний сокет (файл у ФС, без мережі).
  • SOCK_STREAM (TCP) - надійний упорядкований потік байтів; SOCK_DGRAM (UDP) - окремі датаграми без встановлення з'єднання.

Життєвий цикл (TCP). Сервер і клієнт проходять різні послідовності викликів:

Сервер Клієнт
socket() - створити socket() - створити
bind() - прив'язати до (IP, порт)
listen() - відкрити чергу з'єднань
accept() - зняти з'єднання з черги connect() - встановити з'єднання
recv() / send() send() / recv()
close() close()

Ключовий нюанс: accept() повертає новий сокет на кожне з'єднання - саме через нього йде обмін з конкретним клієнтом; слухаючий сокет лише приймає нові з'єднання й сам даних не передає.

import socket

# Minimal TCP echo server
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)  # reuse a port stuck in TIME_WAIT
server.bind(("127.0.0.1", 8000))
server.listen()
conn, addr = server.accept()    # blocks until a client connects; conn is a NEW socket
with conn:
    data = conn.recv(1024)      # blocks until bytes arrive (b"" on clean close)
    conn.sendall(data)          # echo back

# Client
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client.connect(("127.0.0.1", 8000))
client.sendall(b"ping")
print(client.recv(1024))        # b"ping"
client.close()

Блокуючий проти неблокуючого. За замовчуванням сокет блокуючий: recv()/accept() паркують потік у ядрі, поки не з'являться дані чи з'єднання. sock.setblocking(False) робить виклики такими, що одразу повертають керування (або кидають помилку, якщо даних ще нема) - це і дозволяє одному потоку через epoll стежити за багатьма сокетами одночасно (деталі - блокуюче проти неблокуючого I/O).

Практичні нюанси.

  • recv(n) повертає до n байтів, не рівно n: TCP - це потік без меж повідомлень, тож великі дані дочитують у циклі, а межі повідомлень визначають самостійно (префікс-довжина чи роздільник). Порожній b"" означає, що інша сторона коректно закрила з'єднання.
  • sendall() гарантує відправку всіх байтів, тоді як send() може відправити лише частину й повернути їх кількість.
  • SO_REUSEADDR дозволяє знову прив'язатися до порту, що висить у стані TIME_WAIT після попереднього закриття; інакше рестарт сервера падає з Address already in use.

Links

TCP vs UDP [💡12/100]⚑

Summary

Обидва - транспортні протоколи поверх IP. TCP - connection-oriented, з гарантією доставки, упорядкованості та контролю перевантаження; за рахунок handshake і retransmission - повільніший. UDP - connectionless, "fire-and-forget", без гарантій; мінімальні накладні витрати → швидший. Вибір диктується тим, що болючіше для застосунку: втрата пакета чи затримка.

TCP (Transmission Control Protocol)

  • Connection-oriented: 3-way handshake (SYN → SYN-ACK → ACK) перед передачею даних. Закриття - 4-way (FIN/ACK).
  • Reliable delivery: кожен сегмент має sequence number, отримувач підтверджує ACK. Невідправлений пакет - retransmission.
  • In-order delivery: пакети, що прийшли не за порядком, буферизуються до відновлення послідовності.
  • Flow control: вікно RWND - отримувач сигналізує, скільки байтів готовий прийняти. Запобігає переповненню буфера.
  • Congestion control: алгоритми типу Reno, CUBIC, BBR - адаптивно зменшують швидкість при втратах.

Використання: HTTP/1.1, HTTP/2, FTP, SSH, SMTP, IMAP, PostgreSQL wire protocol.

UDP (User Datagram Protocol)

  • Connectionless: жодного handshake'у. Просто відправити datagram з IP+port і сподіватися, що дійде.
  • No delivery guarantee: пакет може загубитися, дублюватися, прийти не за порядком. Застосунок сам вирішує, що з цим робити.
  • No flow / congestion control: відправник шле зі швидкістю, з якою може. Може перевантажити мережу.
  • Мінімальний заголовок (8 байтів) проти TCP (20+ байтів).

Використання: DNS-запити (один-пакет-запит, один-пакет-відповідь), NTP, DHCP, VoIP/RTP, гри в реальному часі, відеостримінг, QUIC (основа HTTP/3), WireGuard.

Порівняння

Властивість TCP UDP
З'єднання 3-way handshake Без з'єднання
Доставка Гарантована Best-effort
Порядок Гарантований Не гарантований
Retransmission Так Ні
Flow control Так Ні
Congestion control Так Ні
Розмір заголовка 20+ байтів 8 байтів
Латентність Вища (handshake, ACK) Нижча
Типовий протокол HTTP/1.1, HTTP/2 DNS, VoIP, HTTP/3 (через QUIC)

DNS на UDP, HTTP на TCP - мотивація вибору

DNS - короткий запит-відповідь (~100 байтів), пріоритет - латентність. TCP handshake додав би 1 RTT - неприйнятно, коли DNS викликається на старті кожного HTTP-запиту. У DNS втрачений пакет легко повторити з резолверу.

HTTP - довільна довжина відповіді, пріоритет - надійність. Втратити шматок JSON-відповіді посеред потоку - неприйнятно, retransmission має робитися на рівні транспорту, а не на рівні застосунку.

Перехід HTTP/3 з TCP на QUIC (UDP)

TCP має head-of-line blocking на рівні пакетів: один втрачений пакет тримає всі stream'и HTTP/2 на цьому з'єднанні. QUIC реалізує надійність на рівні streams окремо: втрата пакета впливає лише на стрім, до якого він належав. Деталі - у розділі Версії HTTP.

Яка різниця різниця між IPv4 та IPv6?⚑

Система IP-адрес в інтернеті - це спосіб ідентифікації пристроїв, підключених до Інтернету. Кожен пристрій, підключений до Інтернету, має унікальну IP-адресу, яка складається з набору чисел, розділених крапками. Ця адреса використовується для маршрутизації пакетів даних між пристроями в мережі.

IPv4 та IPv6 - це два різні протоколи для призначення та використання IP-адрес в Інтернеті.

  • IPv4 - це стандартний протокол, який використовується для призначення IP-адрес в Інтернеті. Він використовує 4-байтові адреси, які записуються у вигляді чотирьох десяткових чисел значенням від 0 до 255 (еквіваленти чотирьох восьмибітних чисел), розділених крапками (наприклад, 192.168.0.1). IPv4 може призначити до 4,3 мільярдів унікальних IP-адрес, що є недостатнім для сучасних потреб Інтернету.

  • IPv6 - це новий протокол, який був створений для заміни IPv4. Він використовує 128-бітні адреси, які записуються у вигляді восьми груп з чотирьох шістнадцяткових цифр, розділених двокрапками (наприклад, 2001:0db8:85a3:0000:0000:8a2e:0370:7334). IPv6 може призначити до 340 секстильйонів унікальних IP-адрес, що дозволяє підключати до Інтернету велику кількість пристроїв та забезпечує додаткові функції безпеки та покращену продуктивність.

Основна різниця між IPv4 та IPv6

  • Кількість доступних IP-адрес: IPv6 надає значно більше адрес, ніж IPv4.
  • Формат запису адрес: IPv6 використовує довші адреси та різний формат запису.

IPv6 також забезпечує додаткові функції безпеки та покращену продуктивність, але вимагає оновлення мережевого обладнання та програмного забезпечення для підтримки нового протоколу.

DNS [💡19/100]⚑

DNS (Domain Name System) - це система, яка перетворює доменні імена в IP-адреси і забезпечує зв'язок між серверами і клієнтами в Інтернеті. Він є ключовим елементом у роботі Інтернету, оскільки дозволяє користувачам використовувати зручні і запам'ятовувані доменні імена замість IP-адрес при доступі до веб-сайтів та інших ресурсів.

Процес перетворення доменного імені в IP-адресу включає такі кроки

  • Клієнт відправляє запит на перетворення доменного імені на DNS-сервер.
  • DNS-сервер перевіряє свій кеш для пошуку доменного імені і пов'язаної з ним IP-адреси. Якщо запис вже є в кеші, DNS-сервер повертає IP-адресу клієнту.
  • Якщо доменне ім'я не знайдено в кеші DNS-сервера, він відправляє запит на перетворення імені домена на інший DNS-сервер, який може мати запис для запрошеного доменного імені.
  • Якщо DNS-сервер знаходить запис для запитаного доменного імені, він повертає IP-адресу клієнту.
  • Якщо DNS-сервер не може знайти запис для запитаного доменного імені, він повертає помилку клієнту.
  • Клієнт використовує отриману IP-адресу для встановлення з'єднання з сервером, пов'язаним із запитаним доменним іменем.

DNS-сервери можуть бути налаштовані на різних рівнях, включаючи локальні мережі, провайдерів інтернет-послуг і кореневі сервери. Кешування DNS-записів дозволяє прискорити процес перетворення доменного імені в IP-адресу, оскільки DNS-сервери можуть зберігати записи про раніше запитані доменні імена і пов'язані з ними IP-адреси.

Якщо у нас є кілька серверів, розташовані в різних географічних локаціях, DNS може нам допомогти правильно розподілити навантаження та зменшити час відповіді, оскільки він буде віддавати адресу найближчого серверу. Але з цим пов'язана небезпека, оскільки якщо сервер чи дата-центр вийде з ладу, до оновлення DNS-кешу може зайняти кілька годин, під час яких наш сервіс буде недоступний.

HTTP⚑

HTTP (HyperText Transfer Protocol) — це протокол прикладного рівня, який використовується для передачі гіпертекстових документів, таких як HTML, через мережу. Основна мета HTTP — забезпечити обмін інформацією між клієнтом (зазвичай веб-браузером) та сервером. На даний момент саме завдяки протоколу HTTP забезпечується робота Всесвітньої павутини.

HTTP базується на моделі клієнт-сервер. Клієнт відправляє запит, а сервер повертає відповідь. Кожен запит і відповідь незалежні один від одного. Для збереження стану часто використовуються механізми, такі як cookies, session або tokens.

HTTP використовує стандартний порт 80 для небезпечних з'єднань та порт 443 для захищених (HTTPS, де додано шифрування через SSL/TLS).

У HTTP визначено кілька методів запиту, найпоширеніші з яких

  • GET: використовується для отримання даних із сервера.
  • POST: використовується для відправки даних на сервер.
  • PUT: для оновлення існуючих даних.
  • DELETE: для видалення ресурсів.
  • PATCH: для часткового оновлення ресурсів.

Також HTTP підтримує заголовки (headers), які дозволяють передавати метаінформацію, наприклад, тип контенту, інформацію про авторизацію, мову, кешування тощо.

У сучасних додатках HTTP часто використовується в поєднанні з REST API або GraphQL для побудови клієнт-серверних систем.

Також HTTP часто використовується як протокол передачі інформації для інших протоколів прикладного рівня, таких як SOAP, XML-RPC. У такому випадку говорять, що протокол HTTP використовується як "транспорт".

Links

Версії HTTP: 1.0, 1.1, 2, 3⚑

Summary

HTTP/1.0 - окреме TCP-з'єднання на запит. HTTP/1.1 - keep-alive, текстовий протокол, host-based virtual hosting. HTTP/2 - бінарний протокол з мультиплексуванням запитів у межах одного TCP-з'єднання та стисненням заголовків (HPACK). HTTP/3 - той самий мультиплексинг поверх QUIC (UDP) замість TCP, що усуває head-of-line blocking на транспортному рівні.

HTTP/1.0 (1996, RFC 1945)

Окреме TCP-з'єднання на кожен запит. Connection: keep-alive - опційне розширення. Без Host-заголовка віртуальний хостинг неможливий - один IP = один сайт.

HTTP/1.1 (1997, RFC 2616 → 7230-7235)

  • Keep-alive увімкнено за замовчуванням.
  • Обов'язковий заголовок Host → virtual hosting.
  • Chunked transfer encoding (Transfer-Encoding: chunked) - відповідь без заздалегідь відомої довжини.
  • Pipelining дозволений специфікацією, але майже не використовується у браузерах - складність обробки head-of-line blocking на сервері.
  • Текстовий протокол: заголовки і стартовий рядок передаються як ASCII-рядки.

Обмеження: head-of-line blocking на рівні HTTP. Якщо один запит у каналі повільний, наступні чекають. Браузери обходять це паралельними TCP-з'єднаннями (~6 на хост).

HTTP/2 (2015, RFC 7540 → 9113)

  • Бінарний фреймовий протокол. Замість рядків - frames (HEADERS, DATA, SETTINGS, PING, GOAWAY, ...). Парсинг швидший і менш помилковий.
  • Мультиплексування streams на одному TCP-з'єднанні: десятки одночасних запитів без head-of-line blocking на рівні HTTP. На рівні TCP - блокування лишається (один втрачений пакет тримає всі stream'и).
  • HPACK - стиснення заголовків. У звичайному API кожен запит має майже однаковий набір заголовків (Authorization, User-Agent, Accept); HPACK стискає їх до посилань на статичну/динамічну таблицю.
  • Server push - сервер міг ініціативно надіслати ресурси, які клієнт ще не запитав. На практиці використовується мало - Chrome вимкнув підтримку у версії 106 (2022).
  • ALPN-узгодження: h2 через TLS. Браузери підтримують HTTP/2 тільки поверх HTTPS; cleartext HTTP/2 (h2c) - для server-to-server, рідко у браузерах.

HTTP/3 (2022, RFC 9114)

  • Транспорт - QUIC (RFC 9000) поверх UDP, не TCP.
  • Той самий мультиплексинг streams, що в HTTP/2, але без TCP head-of-line blocking: втрата пакета впливає лише на свій stream.
  • Швидший handshake: 1-RTT для першого підключення, 0-RTT для повторних (TLS-stata кешується клієнтом).
  • Connection migration: з'єднання переживає зміну IP клієнта (Wi-Fi → 4G).
  • Шифрування QUIC включене у транспортний рівень - неможливо обійти TLS.

Підсумкове порівняння

Версія Транспорт Формат Мультиплекс Стиснення заг. Server push Handshake
HTTP/1.0 TCP Текст - - - TCP 3-way
HTTP/1.1 TCP Текст Pipelining (де-факто не) - - TCP 3-way
HTTP/2 TCP+TLS Бінарний Streams HPACK Так (deprecated) TCP + TLS 1.2/1.3
HTTP/3 UDP+QUIC Бінарний Streams QPACK Так 1-RTT, 0-RTT повторно

Links

HTTP запит і відповідь⚑

HTTP - текстовий протокол, що працює поверх TCP/IP. HTTP складається з запиту та відповіді. Їх структури схожі: стартовий рядок, заголовки та тіло відповіді.

Стартовий рядок запиту складається з методу, шляху та версії протоколу

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0

Стартовий рядок відповіді містить версію протоколу, код відповіді та текстову розшифровку відповіді.

HTTP/1.1 200 OK

Заголовки - це набір пар ключ-значення, наприклад, User-Agent, Content-Type. У заголовках передають метадані запиту: мову користувача, авторизацію, перенаправлення. Заголовок Host повинен бути у запиті завжди.

Тіло відповіді може бути порожнім або містити пари змінних, файли, бінарні дані. Тіло відокремлюється від заголовків порожнім рядком.

Методи HTTP [🔥35/100]⚑

Методи HTTP поділяються на кілька основних груп, включаючи ідемпотентні та неідемпотентні методи.

Ідемпотентність — це властивість операцій, яка означає, що багаторазове виконання однієї і тієї ж операції призведе до того самого результату, що і перше її виконання. Незалежно від того, скільки разів операція буде викликана, результат залишатиметься незмінним.

У контексті HTTP ідемпотентність важлива для забезпечення надійності запитів. Наприклад, якщо під час виконання операції мережа зазнала тимчасової проблеми, клієнт може безпечно повторити запит, не ризикуючи створити додаткові або небажані зміни на сервері.

Ідемпотентні методи HTTP

  • GET - використовується для отримання інформації з сервера та не має побічних ефектів на дані на сервері.
  • HEAD - подібний до GET, але повертає тільки заголовки без тіла відповіді.
  • OPTIONS - використовується для запиту інформації про можливості сервера або ресурсу. Він дозволяє клієнту дізнатися, які HTTP-методи, заголовки та інші можливості підтримуються сервером для конкретного ресурсу без виконання реального запиту, що зменшує навантаження на сервер.
  • PUT- використовується для зміни або оновлення існуючих ресурсів на сервері.
  • DELETE - використовується для видалення ресурсів на сервері. Повторні виклики DELETE для того ж ресурсу не мають ефекту.

Неідемпотентні методи HTTP

  • POST - використовується для відправки даних на сервер для створення нового ресурсу або виконання операцій, які можуть призвести до зміни стану сервера кожного разу, коли він викликається. POST не є ідемпотентним, оскільки два однакових POST-запити можуть мати різні наслідки.
  • PATCH - використовується для зміни або оновлення частини ресурсу на сервері, але не завжди є ідемпотентним. Результат може залежати від попереднього стану ресурсу.

Чим відрізняються HTTP і HTTPS [💡15/100]⚑

HTTP (Hypertext Transfer Protocol) - прикладний протокол передачі даних, для передачі даних між веб-сервером і веб-клієнтом. HTTPS (Hypertext Transfer Protocol Secure) - розширення протоколу HTTP, яке підтримує шифрування за протоколами SSL і TLS.

Основна різниця між HTTP і HTTPS полягає в тому, що HTTPS використовує шифрування для захисту переданих даних. Коли використовується HTTPS для доступу до веб-сайту, всі дані, які надсилаються та отримуються, зашифровані, що робить їх невразливими до перехоплення і читання третіми особами. На відміну від цього, HTTP не використовує шифрування, що робить передані дані вразливими до перехоплення.

Переваги використання HTTPS

  • Безпека та конфіденційність: HTTPS забезпечує захист переданих даних, що робить його більш безпечним, ніж HTTP.
  • SEO: Використання HTTPS може покращити позицію веб-сайту в результатах пошуку.

Для налаштування HTTPS на веб-сайті необхідно виконати наступні кроки

  • Отримати TLS-сертифікат.
  • Встановити TLS-сертифікат на веб-сервері.
  • Змінити налаштування веб-сервера, щоб використовувати HTTPS замість HTTP.
  • Змінити посилання на вашому веб-сайті, щоб вони використовували HTTPS замість HTTP.
  • Перевірити, що всі сторінки веб-сайту використовують HTTPS.

Як працює HTTPS⚑

Для шифрування HTTPS використовує SSL або TLS для шифрування всіх даних, які передаються між клієнтом і сервером. Навіть якщо зловмисник перехопить трафік, він не зможе розшифрувати дані. Під час встановлення з’єднання клієнт і сервер обмінюються сертифікатами для перевірки автентичності та встановлення шифрованого каналу.

TLS — це "нова і покращена" версія SSL (Secure Sockets Layer). Основні дві речі, які забезпечує протокол безпеки транспортного рівня - це автентифікація та шифрування.

  • Автентифікація: забезпечення того, що клієнт дійсно є тим, за кого себе видає, а сервер дійсно є тим, за кого себе видає. Аутентифікація потрібна, тому що деякі зловмисники обманюють клієнтів, видаючи себе за сервер, до якого вони намагаються дістатися.
  • Шифрування: використання криптографічних алгоритмів для перемішування повідомлень під час передачі між клієнтом і сервером, щоб їх не міг зрозуміти ніхто, крім двох сторін.

SSL і TLS використовують асиметричний алгоритм шифрування, який встановлює два різні ключі для кожної сторони: один для шифрування, інший для розшифрування. Спочатку повідомлення шифрується одним ключем, а потім розшифровується іншим. Ці ключі, відомі як публічні та приватні ключі, математично пов'язані між собою, тому повідомлення, надіслані на публічний ключ А, можуть бути розшифровані лише за допомогою приватного ключа А.

HTTPS забезпечує аутентифікацію сервера, що дозволяє клієнту впевнитись у тому, що він спілкується саме з тим сервером, до якого звертався, і не є жертвою атак типу "людина посередині" (Man-in-the-Middle).

Основні компоненти HTTPS

  • SSL/TLS сертифікат
    • Для встановлення HTTPS-з’єднання сервер повинен мати SSL/TLS сертифікат, виданий довіреним центром сертифікації (CA).
    • Сертифікат містить публічний ключ сервера та інші дані, які підтверджують його автентичність.
  • Рукостискання (Handshake)
    • Під час першого з’єднання між клієнтом і сервером відбувається процес "рукостискання", де клієнт перевіряє сертифікат сервера, а сервер і клієнт узгоджують параметри шифрування для сесії.
    • Після цього встановлюється безпечне шифроване з’єднання.
  • Шифрування даних
    • Після встановлення з’єднання всі дані передаються у зашифрованому вигляді. Навіть якщо зловмисник зможе перехопити трафік, він не зможе розшифрувати дані без приватного ключа сервера.

Заголовки (Headers) HTTP [💡11/100]⚑

Заголовки HTTP (HTTP headers) відіграють важливу роль в обміні даними між клієнтом і сервером. Вони містять інформацію про запит або відповідь, яка не відноситься до тіла запиту чи відповіді, але є важливою для його обробки. Заголовки HTTP можуть містити інформацію про кешування, кодування, тип вмісту, автентифікацію та інші аспекти обміну даними між клієнтом і сервером.

Приклади найчастіше використовуваних заголовків HTTP

  • User-Agent: містить інформацію про браузер або інший клієнтський застосунок, який надсилає запит на сервер.
  • Content-Type: визначає тип вмісту, передаваного в запиті або відповіді. Наприклад, це може бути текст, HTML, JSON або XML.
  • Accept: визначає типи вмісту, які клієнт готовий прийняти від сервера.
  • Authorization: використовується для передачі облікових даних для автентифікації користувача на сервері.
  • Cache-Control: визначає, як кешувати вміст на клієнті або на сервері.
  • Cookie: містить інформацію про збережені на клієнті файли cookie.
  • Location: використовується для перенаправлення клієнта на іншу сторінку або ресурс.
  • Referer: містить URL сторінки, з якої було здійснено запит на сервер.
  • Server: містить інформацію про сервер, який обробляє запит.
  • User-Agent: містить інформацію про браузер або інший клієнтський застосунок, який надсилає запит на сервер.

Які є статус коди? [💡17/100]⚑

Коди відповіді HTTP повідомляють про результат виконання запиту.

  • 1xx - інформаційні
    • 100 Continue — клієнт може продовжувати відправку запиту, оскільки сервер отримав початкову частину без помилок.
    • 101 Switching Protocols — сервер погодився на перехід до іншого протоколу, зазначеного клієнтом у запиті.
    • 102 Processing — сервер обробляє запит, але поки не може надати відповідь.
    • 103 Early Hints — сервер повертає ранні заголовки для оптимізації (наприклад, для передзавантаження ресурсів).
  • 2xx - успіх - запит пройшов успішно (дані отримані або створені)
    • 200 OK — запит успішно виконаний, і сервер повернув очікувані дані.
    • 201 Created — запит виконаний, і в результаті був створений новий ресурс.
    • 202 Accepted — запит прийнятий, але ще не оброблений (обробка виконується асинхронно).
    • 203 Non-Authoritative Information — запит виконаний, але інформація, що повертається, отримана від стороннього джерела.
    • 204 No Content — запит виконаний успішно, але у відповіді немає вмісту.
  • 3xx - перенаправлення на інший ресурс
    • 300 Multiple Choices — запитаний ресурс має кілька можливих варіантів, з яких клієнт може обирати.
    • 301 Moved Permanently — запитаний ресурс був переміщений на нову постійну URL-адресу.
    • 302 Found — запитаний ресурс тимчасово переміщений на іншу URL-адресу.
    • 303 See Other — клієнт повинен використовувати інше URL для отримання ресурсу.
    • 304 Not Modified — запитаний ресурс не змінився з часу останнього доступу.
  • 4xx - помилки клієнта - помилка через користувача (немає такої сторінки, немає прав на доступ)
    • 400 Bad Request — сервер не може обробити запит через помилку на стороні клієнта (некоректний синтаксис).
    • 401 Unauthorized — для доступу до ресурсу потрібна аутентифікація.
    • 402 Payment Required —для платних послуг.
    • 403 Forbidden — сервер відмовляє у виконанні запиту через відсутність прав доступу.
    • 404 Not Found — сервер не може знайти запитуваний ресурс.
    • 405 Method Not Allowed — метод запиту не дозволений для цього ресурсу.
    • 406 Not Acceptable — сервер не може повернути дані у форматі, прийнятному для клієнта.
    • 408 Request Timeout — сервер чекав на запит клієнта занадто довго і припинив очікування.
    • 409 Conflict — конфлікт в обробці запиту, наприклад, при одночасній зміні ресурсу.
    • 415 Unsupported Media Type — сервер не підтримує тип даних, переданих у запиті.
    • 429 Too Many Requests — клієнт надіслав занадто багато запитів за короткий час (обмеження швидкості).
  • 5xx - помилки сервера - помилка через сервер (помилка в коді, мережі, конфігурації)
    • 500 Internal Server Error — загальна помилка сервера, яка не може бути деталізована.
    • 501 Not Implemented — сервер не підтримує метод або функцію, необхідну для обробки запиту.
    • 502 Bad Gateway — сервер отримав неправильну відповідь від іншого сервера.
    • 503 Service Unavailable — сервер тимчасово недоступний через перевантаження або технічне обслуговування.
    • 504 Gateway Timeout — сервер не отримав відповідь від іншого сервера вчасно.

Що потрібно відправити браузеру, щоб перенаправити на іншу сторінку [💡17/100]⚑

Мінімальна відповідь повинна мати статус 301 або 302. Заголовок Location вказує адресу ресурсу, на який слід перейти.

У тілі відповіді можна розмістити HTML з посиланням на новий ресурс. Таким чином, користувачі старих браузерів можуть перейти вручну.

Як керувати кешуванням в HTTP⚑

Існує кілька способів кешувати дані на рівні протоколу.

  • Заголовки Cache та Cache-Control регулюють одразу кілька критеріїв кешу: час життя, політику оновлення, поведінку проксі-сервера, тип даних (публічні, приватні).
  • Заголовки Last-Modified та If-Modified-Since задають кешування в залежності від дати оновлення документа.
  • Заголовок Etag кешує документ за його унікальним хешем.

Як файли кешуються на рівні протоколу⚑

Коли Nginx передає статичний файл, він додає заголовок Etag. У Nginx це не хеш вмісту (наприклад, MD5), а комбінація часу останньої зміни файлу й його розміру у форматі "hex(mtime)-hex(content_length)". Клієнт запам'ятовує цей Etag. Наступного разу при запиті файлу клієнт відправляє його (у заголовку If-None-Match). Сервер порівнює значення. Якщо воно не співпадає (файл оновили), сервер відповідає з кодом 200 та завантажує актуальний файл з новим хешем. Якщо хеші рівні, сервер відповідає з кодом 304 Not Modified з пустим тілом. У цьому випадку браузер вставляє локальну копію файлу.

Аутентифікація та авторизація [💡20/100]⚑

Summary

Ідентифікація - визначення, ХТО користувач (логін, токен). Автентифікація - перевірка, що користувач не обманює щодо своєї особи (пароль, підпис токена). Авторизація - перевірка, чи дозволено йому виконати дію. З погляду архітектури: ідентифікація й автентифікація - на адаптерах/зовнішній підсистемі, авторизація - у бізнес-логіці, її не можна виносити у слой представлення.

Аутентифікація - це процес перевірки автентичності користувача, щоб переконатися, що він є тим, за кого себе видає. В процесі аутентифікації користувач зазвичай надає облікові дані, такі як ім'я користувача та пароль. Якщо ці дані вірні, то користувач вважається успішно аутентифікованим.

Авторизація - це процес визначення прав доступу користувача до певних ресурсів або дій на веб-сайті. Після успішної аутентифікації користувач може отримати доступ до різних функцій та ресурсів на веб-сайті, залежно від його ролі та прав доступу. Наприклад адміністратор має ширший набір дозволів ніж рядовий юзер.

Інколи ще виділяють ідентифікацію.

Ідентифікація - присвоєння суб'єктам та об'єктам ідентифікатора та / або порівняння ідентифікатора з переліком присвоєних ідентифікаторів. Наприклад, представлення людини за ім'ям та по-батькові - це ідентифікація.

Усі три процедури взаємопов'язані

  • Спочатку визначають ім'я (логін або номер) - ідентифікація.
  • Потім перевіряють пароль - аутентифікація.
  • І на кінцевому етапі надають доступ - авторизація.

Приклади методів та інструментів для реалізації аутентифікації

  • Форма входу: користувач вводить свій логін і пароль у форму на веб-сайті.
  • OAuth: стандартний протокол, який дозволяє користувачам аутентифікуватися на веб-сайті, використовуючи облікові дані соціальних мереж.
  • OpenID: стандартний протокол, який дозволяє користувачам аутентифікуватися на веб-сайті, використовуючи облікові дані з інших веб-сайтів.

Приклади методів та інструментів для реалізації авторизації

  • Рольова модель: визначення ролей користувачів та їхніх прав доступу до різних функцій та ресурсів на веб-сайті.
  • Access Control Lists (ACL): список прав доступу, який визначає, які користувачі мають доступ до певних ресурсів на веб-сайті.
  • JSON Web Tokens (JWT): стандартний формат, який дозволяє передавати інформацію про аутентифікацію та авторизацію між клієнтом і сервером у зашифрованому вигляді.

З погляду архітектури застосунку. Три процедури належать різним шарам:

  • Ідентифікація виконується для потреб бізнес-логіки або логування; адаптери лише допомагають її реалізувати.
  • Автентифікація не є частиною основної бізнес-логіки - її виконують адаптери або окрема підсистема (інколи реверс-проксі чи зовнішній сервіс на кшталт Keycloak). Її актуальність залежить від каналу: повідомленню від telegram можна довіряти (бо довіряємо серверам telegram), а HTTP-запит потребує захисту від підробки особи.
  • Авторизація виконується лише бізнес-логікою; її не можна коректно винести у шар представлення, хоча можна відділити від основної логіки інтерактора.

Моделі авторизації. Перевірку прав будують за різними моделями:

  • RBAC (Role-Based Access Control) - доступ за роллю користувача (admin, user).
  • ReBAC (Relationship-Based) - за відношенням користувача й об'єкта (власник може редагувати свій запис).
  • ABAC (Attribute-Based) - за атрибутами того, з якими даними об'єкта працює користувач.

Вибір моделі визначається вимогами системи.

Складність авторизації: три осі (за Oso). Авторизація рідко буває "готова з коробки" - її складність розкладається на три незалежні осі (прості випадки розв'язуються таблицею ролей, але система майже завжди дорощує складність):

Enforcement - застосування рішення. Перевірку доступу доводиться вставляти в багатьох місцях: контролери, маппери БД, роутери, UI. Що вище по стеку - то грубіша гранулярність; що нижче - то тонша, але більше зусиль. Resource-level перевірка (authorize(user, action, resource)) гнучка, але її треба розставляти всюди - марудно й легко пропустити; винесення в generic middleware ризикує продублювати логіку доступу до даних. Окремо складні: фільтрація списків (як отримати всі записи, доступні користувачу, не завантажуючи й не перевіряючи кожен) і показ прав у UI (фронтенду потрібні дані про дозволи без дублювання бекенд-логіки).

Decision architecture - логіка плюс дані. Рішення = логіка (правила: "admin може редагувати") + дані. Дані бувають авторизаційні (ролі, дозволи) і дані застосунку (хто автор запису, до якого проєкту він належить) - і відокремити їх чисто не виходить, бо логіка рішення часто потребує саме даних застосунку. У моноліті логіка просто читає свою БД; щойно з'являються кілька сервісів чи окремий authz-сервіс - постає питання, як дати логіці доступ до потрібних даних і тримати їх синхронними. Підхід Google Zanzibar (централізована модель відношень) дає все для рішення в одному місці, але вимагає міграції/синхронізації майже всіх даних і ставить authz-сервіс на критичний шлях кожного запиту (латентність, SLA доступності).

Modeling - як виразити правила. Моделі RBAC/ReBAC/ABAC (описані вище) відрізняються виразністю. Майже всі починають з простих глобальних ролей, але моделі неминуче ускладнюються (ролі на рівні ресурсу, ієрархія ролей, групи, атрибути) - команди переписують модель авторизації по 4-5 разів. Прості бібліотеки ролей швидко стартують, але впираються в стелю (часто без ієрархії ролей чи ролей на ресурс). Policy-движки (OPA, OPAL) гнучкі, але мають криву навчання й не направляють до типових патернів. Звідси постійне напруження: просте й обмежене проти потужного, але складного.

Links

Популярні методи авторизації [💡13/100]⚑

Авторизація забезпечує контроль доступу до ресурсів системи, перевіряючи права користувача.

  • Basic Auth
    • Користувач передає логін та пароль у заголовках кожного запиту. Простий у реалізації, але небезпечний без HTTPS через передачу даних у відкритому вигляді.
  • Token-Based Authentication
    • Після успішної автентифікації сервер генерує токен, який клієнт передає у заголовках запитів.
    • JSON Web Token (JWT): один із популярних форматів токенів, який містить інформацію про користувача в зашифрованому вигляді.
    • Access/Refresh Tokens: часто використовуються разом із OAuth2 для коротко- та довгострокових сесій.
  • OAuth 2.0
    • Протокол, який дозволяє користувачам надавати доступ до своїх ресурсів стороннім додаткам без передачі пароля.
    • Використовується для інтеграції з платформами (Google, Facebook).
    • Підтримує токени доступу (access tokens) для обмеженого доступу.
  • Session-Based Authentication
    • Сервер зберігає інформацію про сесію користувача у базі даних, а клієнт отримує cookie з ідентифікатором сесії. Підходить для додатків із серверним рендерингом сторінок.
  • Multi-Factor Authentication (MFA)
    • Додатковий рівень безпеки, де разом із паролем запитується другий фактор (наприклад, SMS-код або код з додатку).
  • Biometric Authentication
    • Використання відбитків пальців, розпізнавання обличчя або голосу для підтвердження особи. Застосовується у мобільних додатках або пристроях.
  • API Keys
    • Спеціальні ключі, які передаються у запитах для доступу до API. Використовуються для інтеграції з сервісами.

OAuth 2.0: ролі та authorization code flow⚑

Summary

OAuth 2.0 - протокол делегованої авторизації: він дозволяє сторонньому додатку отримати обмежений доступ до ресурсів користувача без передавання пароля. Це авторизація, а не автентифікація - щоб дізнатися, ХТО користувач, поверх OAuth використовують OpenID Connect (OIDC).

Чотири ролі

  • Resource Owner - користувач, якому належать дані.
  • Client - додаток, що хоче доступ до даних від імені користувача.
  • Authorization Server - видає токени (наприклад, accounts.google.com).
  • Resource Server - API, що зберігає ресурси й приймає access token.

Authorization Code Flow (основний для веб-додатків з бекендом):

  1. Client перенаправляє користувача на Authorization Server із client_id, redirect_uri, scope і state.
  2. Користувач автентифікується й підтверджує доступ (consent).
  3. Authorization Server редіректить назад на redirect_uri з одноразовим authorization code.
  4. Client на бекенді обмінює code разом із client_secret на access token (і часто refresh token). Цей крок server-to-server, тож code не лишається в браузері.
  5. Client звертається до Resource Server, передаючи Authorization: Bearer <access token>.
Browser  -- auth request -->        Authorization Server
Browser  <-- redirect with code --  Authorization Server
Backend  -- code + client_secret -->Authorization Server
Backend  <-- access/refresh token --Authorization Server
Backend  -- Bearer access token --> Resource Server

state - випадкове значення, яке клієнт звіряє після редіректу, щоб захиститися від CSRF на самому flow. Для публічних клієнтів без секрету (SPA, мобільні застосунки) замість client_secret використовують розширення PKCE (code_verifier / code_challenge).

Інші grant types

  • Client Credentials - сервіс-до-сервісу, без користувача (machine-to-machine).
  • Refresh Token - отримати новий access token замість протермінованого, без повторного входу.
  • Implicit та Resource Owner Password Credentials - застарілі, не рекомендовані.

OAuth vs OIDC. OAuth 2.0 відповідає на питання "що цьому додатку дозволено робити" (авторизація). Щоб встановити особу користувача, поверх нього працює OpenID Connect: він додає id_token (JWT) з даними про користувача - це вже автентифікація.

Чому не можна передавати секрети в query-параметрах⚑

Summary

Токени, паролі й персональні дані не місце в query-рядку URL - він осідає в логах серверів і проксі, в історії браузера та в заголовку Referer. Такі дані передають у тілі запиту або в заголовках.

URL разом із query string вважається не-секретним каналом, бо потрапляє в багато місць:

  • Логи. Веб-сервери, проксі та балансувальники за замовчуванням пишуть повний URL в access-логи, тож токен у ?token=... опиниться в незахищеному лозі.
  • Історія браузера та закладки. Query зберігається на клієнті.
  • Заголовок Referer. Переходячи за зовнішнім посиланням, браузер надсилає поточний URL (з параметрами) на сторонній сайт.
  • Кеш проксі та CDN. Можуть кешувати за повним URL як ключем.

Тому:

  • Секрети (паролі, API-ключі, токени) і чутливі дані передають у тілі запиту (POST/PUT) або в заголовку (Authorization: Bearer ...), а не в query.
  • Query-параметри доречні для неконфіденційних даних: фільтри, пагінація, сортування, пошукові запити.
  • Якщо чутливий ідентифікатор усе ж мусить бути в URL, його роблять одноразовим і короткоживучим (наприклад, токен скидання пароля).

Що таке куки? [💡12/100]⚑

Куки (cookies) - це інформація у вигляді невеликих текстових файлів, яка зберігається на комп'ютері веб-сайтом. Вони використовуються для збереження інформації про користувача та його взаємодію з веб-сайтом. Куки часто зберігають налаштування для веб-сайту, такі як обрана мова чи місце. При поверненні на сайт, браузер надсилає назад куки, які належать цьому сайту. Це дозволяє сайту пам'ятати інформацію з попередніх відвідувань.

Куки зберігаються у браузері.

Куки можна встановлювати та читати з серверної сторони (через HTTP-заголовки) або ж з клієнтської сторони за допомогою JavaScript.

Отримавши HTTP-запит, разом із відповіддю сервер може відправити заголовок Set-Cookie. Куки запам'ятовуються браузером і надсилаються в HTTP-заголовку Cookie з кожним новим запитом на один і той же сервер. Можна задати термін дії куків та інші параметри.

Чи може сервер змінити (додати, видалити) куки?⚑

Так. Значення куки може бути змінено сервером шляхом відправки нових заголовків Set-Cookie: name=newvalue. Після цього браузер замінює старий куки з тим самим ім'ям на новий рядок.

Як захистити куки від крадіжки та підробки⚑

Це залежить від того, наскільки строгі вимоги до безпеки на сайті. Якщо куки містять допоміжні дані, такі як індекс останнього вибраного елемента у випадаючому списку, то можна ігнорувати наступні правила.

Для платіжних систем та сайтів з приватними даними наведені правила є обов'язковими.

  • Потрібно встановлювати кукам прапорець httponly. Браузер не дозволить читати та змінювати такі куки на клієнті через JavaScript.
  • Потрібно використовувати прапорець secure. Куки будуть передаватися лише через захищене з'єднання (HTTPS).
  • Потрібно встановлювати короткий термін життя куки.
  • Потрібно встановлювати короткий термін сесії на сервері.
  • Потрібно додавати у ключ сесії заголовок User-Agent. Таким чином, якщо крадуть куки і встановлюють на іншому пристрої, ключ сесії буде іншим.
  • Аналогічно до попереднього пункту, але додавати IP користувача.
  • Підписувати куки секретним ключем. Додавати поле sig, яке дорівнює HMAC-SHA1(cookie-body, secret_key). На сервері перевіряйте, що підпис збігається.

Що таке сесія? [💡10/100]⚑

Сесії в контексті роботи з веб-додатками - це механізм, який дозволяє зберігати стан користувача між запитами до веб-сервера. Коли користувач входить у систему, йому призначається унікальний ідентифікатор сесії, який зберігається на сервері. Цей ідентифікатор використовується для зв'язку даних користувача з його сеансом, поки він знаходиться на сайті. Коли користувач залишає сайт, сесія закривається, і дані видаляються.

Що швидше перевірити при авторизації - JWT чи сесію, і чому? [💡12/100]⚑

Summary

JWT швидший на перевірку: уся інформація про користувача вже всередині токена, серверу достатньо звірити підпис у пам'яті. Сесія повільніша - для кожного запиту треба сходити до сховища (Redis/БД/файл) і дістати дані по session_id.

JWT:

  • Клієнт надсилає токен у заголовку Authorization: Bearer ....
  • Сервер бере публічний/секретний ключ і перевіряє підпис - це чисто CPU-операція в RAM.
  • user_id, roles, exp уже в payload - лізти в БД не треба.
  • Накладні витрати - лише крипто (HS256 ~ мікросекунди, RS256 повільніший).

Session:

  • Клієнт надсилає session_id у Cookie.
  • Сервер робить запит до сховища (Redis, БД, файл): GET session:<id> → отримує дані.
  • Це додатковий round-trip, навіть якщо до Redis в тій же мережі - 0.5–2 мс.
  • При мережевих проблемах із сховищем - деградує вся авторизація.

Тому JWT швидший для гарячого шляху перевірки. Але "швидший" не означає "кращий":

  • JWT не можна відкликати миттєво (треба blacklist або короткі TTL + refresh).
  • Сесії легко інвалідувати - просто видалити запис у сховищі.
  • Сесії компактніші у запиті (тільки session_id); JWT - десятки/сотні байт у кожному запиті.
  • Застарілі claims. Дані в JWT незмінні до exp: після зміни ролей, пароля чи блокування акаунта старий токен ще валідний - користувач зберігає доступ, якого вже не повинен мати. У сесії зміни застосовуються миттєво (стан на сервері).

Вибір залежить від моделі загроз і вимог до відкликання, а не лише від швидкості. Практичне правило: для монолітного веб-застосунку надійніші cookie-сесії з Redis (миттєве відкликання, компактність, HttpOnly); JWT природніший як засіб авторизації між сервісами (сервіс локально перевіряє підпис без звернення до сховища), а не як механізм користувацьких сесій. Будь-яка спроба зробити JWT відкликуваним повертає серверний стан - тобто скасовує його головну перевагу "stateless".

Що таке WebSocket і де може використовуватися? [💡19/100]⚑

Summary

WebSocket - мережевий протокол поверх TCP, що тримає постійне двостороннє з'єднання між клієнтом і сервером. На відміну від HTTP "запит-відповідь", сервер може сам надсилати дані клієнту в будь-який момент, без опитування.

Принцип роботи

  • З'єднання починається зі звичайного HTTP-запиту з заголовком Upgrade: websocket.
  • Сервер відповідає 101 Switching Protocols - і далі поверх того ж TCP-сокета тече двосторонній бінарний потік фреймів.
  • З'єднання тримається відкритим, поки одна зі сторін не закриє його.

Застосування

  • Чати та месенджери - миттєва доставка повідомлень.
  • Онлайн-ігри - синхронізація дій гравців.
  • Браузерні нотифікації - без постійного polling сервера.
  • Торгові платформи - котирування, угоди в реальному часі.
  • Спільне редагування - Google Docs, Figma, спільні дошки.
  • Моніторинг і логи в реальному часі - стрім подій без затримки.

В Python для WebSocket - бібліотеки websockets, aiohttp (вбудована підтримка), FastAPI (через Starlette). На фронті - нативний WebSocket API в браузері.

Масштабування

WebSocket - stateful-протокол: встановлене з'єднання прив'язане до конкретної репліки, яка тримає його стан у пам'яті. При горизонтальному масштабуванні всі повідомлення одного клієнта мають потрапляти на ту саму репліку - інакше з'єднання розривається. Балансувальник з round-robin тут не підходить; застосовують sticky sessions (прив'язку з'єднання до репліки), щоб увесь трафік клієнта йшов на той самий інстанс.

Велику кількість одночасних з'єднань ефективніше обслуговує асинхронний сервер: один потік з event loop мультиплексує тисячі сокетів, що здебільшого простоюють, перемикаючись між ними під час очікування I/O. Синхронна модель з окремим потоком на з'єднання витрачає потік або процес на кожен сокет і тому досягає лімітів пам'яті та кількості потоків набагато раніше.

Чим краще відправляти форму - GET чи POST?⚑

Форму можна відправляти обома способами. У першому випадку змінні додаються до рядка запиту після знаку питання. У другому - передаються в тілі запиту.

Технічне обмеження методу GET полягає в тому, що ним неможливо передати файл, на відміну від POST.

Рекомендується відправляти форму методом POST з наступних причин

  • GET-запити можуть бути закешовані.
  • GET-запити залишаються в журналах постачальника, сервера та історії браузера. Пароль та логін можуть потрапити в багато місць.
  • Деякі віруси відстежують зміст адресного рядка та передають його третім особам.

Які є види токенів?⚑

Токени — це інструменти, які використовуються для забезпечення авторизації та автентифікації у додатках.

Основні види токенів

  • Access Token
    • Використовується для отримання доступу до ресурсів. Зазвичай має короткий термін дії, щоб мінімізувати ризики компрометації.
    • Приклад: токен у форматі JWT для REST API.
  • Refresh Token
    • Використовується для отримання нового Access Token після його закінчення. Має довший термін дії та зазвичай зберігається у більш безпечному місці (наприклад, у HTTP-only cookie).
    • Для захисту Refresh Token від витоку використовується ротація токенів. Коли ми віддаємо новий Access Token, то відразу віддаємо і новий Refresh Token.
  • ID Token
    • Використовується для передачі інформації про автентифікованого користувача. Застосовується в протоколах, таких як OpenID Connect.
    • Зазвичай містить інформацію про користувача у вигляді закодованого JSON-об'єкта.
  • API Key
    • Простий токен, що використовується для автентифікації та відстеження доступу до API. Він несе у собі лише ідентифікатор і не є зашифрованим.
  • Bearer Token
    • Тип токена, який клієнт передає у заголовках запитів для доступу до захищених ресурсів. У HTTP-запиті це зазвичай виглядає так: Authorization: Bearer <token>.
  • CSRF Token
    • Використовується для захисту від атак типу Cross-Site Request Forgery. Генерується сервером і передається клієнту для підтвердження легітимності запиту.
  • One-Time Token
    • Одноразові токени, які дійсні лише для одного запиту або дії. Часто використовуються для підтвердження електронної пошти або скидання пароля.

Що таке JWT (JSON Web Token) [💡27/100]⚑

JSON Web Token (JWT) - ("джот") - це стандартизований, у деяких випадках підписаний і/або зашифрований формат для передачі інформації між сторонами у вигляді JSON-об'єкта. Він широко використовується для автентифікації та авторизації в сучасних веб-додатках.

JWT складається з трьох частин, розділених крапками: Header, Payload, Signature.

  • Header: містить тип токена (JWT) та алгоритм підпису (наприклад, HS256 - це алгоритм підпису, а не шифрування).
  • Payload: містить інформацію про користувача або сесію (claims). Може включати стандартні claims (наприклад, sub, exp) і кастомні.
  • Signature: забезпечує цілісність токена, підписуючи header і payload за допомогою секретного ключа.

JWT не шифрується, а кодується у форматі Base64. Тому інформація у payload доступна будь-кому, хто має токен, якщо не використовується додаткове шифрування.

JWT може використовуватись як токен авторизації (Access Token) або для передачі інформації, що не потребує додаткового запиту до сервера. Токен має обмежений термін дії, вказаний у claim exp. Після його закінчення необхідно оновити токен за допомогою механізмів, таких як Refresh Token.

Переваги JWT

  • Самодостатність: містить всю необхідну інформацію.
  • Незалежність від стану: не потребує збереження на сервері (на відміну від сесій).
  • Компактність: легко передається у HTTP-заголовках.

Приклад створення та перевірки JWT

import jwt
from datetime import datetime, timedelta

SECRET_KEY = "your_secret_key"  # Secret key for signing the token

def create_jwt(user_id):  # Function to create a JWT
    payload = {
        "user_id": user_id,
        "exp": datetime.utcnow() + timedelta(minutes=30),  # Token valid for 30 minutes
        "iat": datetime.utcnow()  # Issued at time
    }
    token = jwt.encode(payload, SECRET_KEY, algorithm="HS256")
    return token

def verify_jwt(token):  # Function to decode and verify JWT
    try:
        decoded = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
        return decoded
    except jwt.ExpiredSignatureError:
        return "Token has expired"
    except jwt.InvalidTokenError:
        return "Invalid token"

jwt_token = create_jwt(123)
print("Generated JWT:", jwt_token)
decoded_data = verify_jwt(jwt_token)
print("Decoded JWT:", decoded_data)

Відкликання токена (logout from all devices)

JWT самодостатній і не зберігається на сервері, тому видалити його до закінчення exp просто так не можна - вихід, бан, зміна пароля чи "вийти з усіх пристроїв" потребують відкликання (revocation). Для цього вводять серверний стан (частково жертвуючи stateless-моделлю): у payload кладуть унікальний jti (id токена), а сервер тримає список відкликаних/активних jti.

  • Blocklist (denylist). За замовчуванням токен дійсний; у сховище кладуть jti саме відкликаних токенів і перевіряють кожен запит. Простіше, запис лише при відкликанні.
  • Allowlist. У сховищі - jti усіх виданих активних токенів; відкликання = видалити запис. Токен дійсний, лише якщо присутній. Дає повний контроль, але запис на кожну видачу.
  • Сховище - Redis із TTL, рівним залишку життя токена: записи самоочищаються, не треба окремої таблиці й cron-задачі на чистку. Головне - щоб TTL у Redis збігався з exp токена, інакше можлива розбіжність "у сховищі вже немає, а токен ще валідний".
  • Практичний компроміс: короткоживучий access-токен (1-5 хв, не перевіряють у сховищі)
  • revocable refresh-токен (перевіряють). Так на кожен запит немає звернення до сховища, але відкликання все одно працює - максимум через час життя access-токена.
  • Logout from all devices: відкликати всі jti користувача (зберігати user_id → jti) або тримати в payload версію/epoch користувача, яку звіряють і піднімають при виході з усіх пристроїв - тоді старі токени стають недійсними без поіменного списку.

Refresh-токен зберігають у HttpOnly/Secure-кукі, а не в localStorage (захист від XSS).

Підпис проти шифрування (JWT проти JWE)

Стандартний JWT підписується, а не шифрується. Payload закодований лише Base64URL, тож будь-хто з токеном може його прочитати - конфіденційні дані туди класти не можна. Захист дає не таємність, а цілісність: сервер перераховує підпис над header+payload своїм ключем і звіряє з полем Signature.

Тому атака "декодувати → змінити user_id → закодувати назад" не проходить, навіть якщо підставлений user_id реально існує в БД: підпис, перерахований з новим payload, не збігається з ключем сервера, і токен відхиляється (InvalidSignatureError). Зловмисник не може підробити валідний підпис, не знаючи секрет (HS*) чи приватний ключ (RS*/ES*).

Якщо payload потрібно ще й приховати, застосовують JWE (JSON Web Encryption) - той самий токен, але додатково зашифрований: вміст недоступний для читання. Ціна - витрати CPU на шифрування/розшифрування при кожній перевірці.

Де зберігати токен у браузерному клієнті. Поширене питання для SPA. Ключова теза: localStorage, sessionStorage, не-HttpOnly cookie та IndexedDB однаково вразливі - усе, що читає код розробника, читає й код зловмисника при XSS. Тому "localStorage чи cookie" - хибна дилема; різниця між ними тут несуттєва. Стратегії зниження ризику:

  • Не тримати токен у JS взагалі. Stateful-сесія в HttpOnly/Secure/SameSite-кукі (+ захист від CSRF, бо кукі шлеться автоматично). Найпростіше; ціна - відмова від переваг stateless-токенів.
  • BFF (Backend-for-Frontend) як token-proxy. Тонкий бекенд - confidential client: він тримає access-токен у себе, а клієнту видає лише HttpOnly-сесійну кукі й проксує запити до API, підставляючи реальний токен. Токен ніколи не потрапляє в JS. Нині це рекомендований патерн автентифікації SPA (потребує захисту від CSRF). Відрізняється від BFF-агрегації відповідей (див. ../architecture/microservices.md) лише призначенням.
  • Service worker як проксі. SW працює в окремому контексті без доступу до DOM/JS-сторінки; токен ізольований у ньому. Має зареєструватися до будь-якого auth-flow, інакше XSS встигне ініціювати свій flow в обхід. Імунний і до XSS-крадіжки, і до CSRF.
  • Тільки в пам'яті (closure-змінна). Токен у замиканні token-manager'а, не персиститься. Втрачається при перезавантаженні, і зловмисник усе одно може перехопити запит через monkey-patching fetch. Частковий захист.
  • Розщеплення токена. Половину тримають у HttpOnly-кукі: напр. підпис JWT - у кукі, header+payload - на клієнті (Two-Cookie JWT); або в payload кладуть хеш випадкового рядка, сам рядок - у HttpOnly-кукі. Сам по собі викрадений токен стає недостатнім.

PKCE тут не допомагає: воно захищає обмін authorization code на токен, а не сам токен у сховищі - поширена плутанина. Викрадення токена ≠ єдиний наслідок XSS: маючи XSS, зловмисник усе одно може слати легітимні запити з браузера жертви, тож захист сховища - лише частина.

Links

Що таке CSRF-token?⚑

CSRF (Cross-Site Request Forgery) - Міжсайтова підробка запиту - тип вебатаки, що призводить до виконання певних дій від імені користувача на вебсторінці де останній аутентифікований. Головною метою CSRF-атаки є підробка запитів, а не викрадення даних, тому що зазвичай зловмисник не має змоги побачити відповідь на підроблений запит.

Приклад атаки CSRF

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

Наприклад, користувач вже увійшов на банківський сайт, і у нього збережена сесія через кукі. Зловмисник надсилає користувачу посилання на шкідливий сайт, який таємно виконує POST-запит до банку на переведення коштів

<form action="https://bank.com/transfer" method="POST">
    <input type="hidden" name="toAccount" value="hacker_account">
    <input type="hidden" name="amount" value="10000">
    <input type="submit">
</form>

Як тільки користувач відвідує шкідливий сайт або посилання викликається через JavaScript, відправляється запит, і банк виконує дію, оскільки користувач уже автентифікований.

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

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

Отже, основні ознаки токена CSRF включають в себе

  • унікальність для кожного запиту
  • обмежений термін життя
  • непередбачуваність і стійкість до вгадування

Що таке XSS. Приклади. Як захистити додаток⚑

Cross-Site Scripting (XSS) — це тип вразливості безпеки веб-додатків, який дозволяє зловмисникам вставляти шкідливі скрипти на вебсторінки, що можуть виконуватися на стороні клієнта (у браузері). Зазвичай це відбувається, коли дані, введені користувачем або отримані з іншого джерела, не фільтруються належним чином перед відображенням у браузері.

XSS - міжсайтові запити. Сторінка, яка має уразливість, змушує користувача здійснити запит до іншої сторінки або виконати небажаний js-код.

Знаючи, що сторінка виконує js-код, хакер може підгрузити на сторінку контекстну рекламу, банери, змусити браузер перейти на будь-яку сторінку, викрасти куки.

Вразливість усувається екрануванням небезпечних символів, очищенням (санацією) HTML-тегів.

<p>User name: <script>alert('XSS')</script></p>  # before
<p>User name: &lt;script&gt;alert('XSS')&lt;/script&gt;</p>  # after

Види XSS

  • Stored XSS (Збережений XSS)
    • Шкідливий скрипт зберігається на сервері в базі даних або іншому сховищі. Коли інший користувач відвідує сторінку, скрипт завантажується та виконується у його браузері.
<script>alert('foo');</script>

Движок сайту не фільтрує текст коментаря, тому тег <script> стає частиною сторінки і виконується браузером. Кожен, хто зайде на сторінку з небезпечним коментарем, побачить спливаюче вікно з текстом foo.

  • Reflected XSS (Відображений XSS)
    • Шкідливий скрипт передається у URL або параметрах запиту і негайно відображається в відповіді сервера без збереження на сервері.
/search?q=<script>alert('foo');</script>

Сторінка пошуку приймає пошуковий термін q. В заголовку фраза "Результат пошуку за запитом" + текст параметра. Якщо не екранувати параметр, то запит приведе до аналогічного результату.

Що таке CORS?⚑

CORS (Cross-Origin Resource Sharing) - це механізм безпеки, який дозволяє веб-сторінкам запитувати ресурси з інших джерел у браузері. Основна проблема, яку CORS допомагає вирішити, це обмеження безпеки браузера, яке забороняє веб-сторінкам запитувати ресурси з інших доменів. Без CORS веб-сторінки не можуть отримати доступ до ресурсів з інших доменів, що може призвести до обмеження функціональності веб-додатків.

Щоб налаштувати і керувати CORS на сервері, необхідно додати заголовки CORS у відповіді сервера на запити від веб-сторінок. Заголовки CORS визначають, які домени можуть отримувати доступ до ресурсів на сервері. Для цього можна використовувати спеціальні бібліотеки або налаштувати сервер вручну.

Можливі заголовки

  • Access-Control-Allow-Origin. Вказує, з яких доменів дозволено доступ до ресурсу.
  • Access-Control-Allow-Methods. Вказує, які HTTP-методи дозволено для крос-доменного доступу.
  • Access-Control-Allow-Headers. Вказує, які заголовки можуть бути надіслані під час крос-доменного запиту.

Приклад

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT

OWASP Top 10⚑

Summary

OWASP (Open Worldwide Application Security Project) - некомерційна спільнота, що публікує матеріали з безпеки застосунків. Найвідоміший - OWASP Top 10: рейтинг десяти найкритичніших ризиків вебзастосунків, який періодично оновлюють за реальними даними інцидентів. Це стандартний чеклист для співбесід і рев'ю безпеки.

Редакція 2025 (категорії за спаданням ризику):

  1. A01 Broken Access Control - доступ до чужих даних чи дій: обхід авторизації, IDOR. Лишається №1.
  2. A02 Security Misconfiguration - стандартні паролі, відкриті порти, надлишкові дозволи, увімкнене налагодження (debug) на продакшні.
  3. A03 Software Supply Chain Failures - вразливі/скомпрометовані залежності, збірки, CI/CD (розширення колишнього "Vulnerable and Outdated Components").
  4. A04 Cryptographic Failures - слабке або відсутнє шифрування, передача чи зберігання секретів у відкритому вигляді.
  5. A05 Injection - SQL/NoSQL/command/LDAP-ін'єкції, а також XSS. Захист - параметризовані запити, екранування, валідація вводу.
  6. A06 Insecure Design - відсутність моделювання загроз і безпечних патернів на рівні дизайну, а не лише реалізації.
  7. A07 Authentication Failures - слабкі паролі, відсутність rate-limit/MFA, погане керування сесіями й токенами.
  8. A08 Software or Data Integrity Failures - довіра до неперевірених оновлень, небезпечна десеріалізація недовірених даних.
  9. A09 Security Logging and Alerting Failures - брак логів і сповіщень, через що атаки лишаються непоміченими.
  10. A10 Mishandling of Exceptional Conditions - небезпечна поведінка при неочікуваному вводі, таймаутах чи нестачі ресурсів (нова категорія 2025).

Порівняно з редакцією 2021: Injection опустився з №3 на №5, додалися Software Supply Chain Failures і Mishandling of Exceptional Conditions. Окремі ризики детальніше розкриті у розділах "XSS", "CSRF-token" і "CORS".

OWASP API Security Top 10 (2023) - окремий рейтинг саме для API (не вебсторінок): ризики API мають свою специфіку, тож список відрізняється від основного. Десятка:

  1. API1 Broken Object Level Authorization (BOLA) - доступ до чужого об'єкта за його id без перевірки власника (≈ IDOR); найпоширеніша API-вразливість.
  2. API2 Broken Authentication - слабка автентифікація чи керування токенами, brute-force без rate-limit.
  3. API3 Broken Object Property Level Authorization (BOPLA) - доступ або зміна окремих полів об'єкта без перевірки прав (mass assignment + надмірна видача даних).
  4. API4 Unrestricted Resource Consumption - брак лімітів (rate, size, pagination) -> DoS і перевитрати.
  5. API5 Broken Function Level Authorization (BFLA) - виклик адмін-ендпоінтів звичайним користувачем.
  6. API6 Unrestricted Access to Sensitive Business Flows - автоматизоване зловживання легітимним сценарієм (скупка квитків ботами).
  7. API7 Server-Side Request Forgery (SSRF) - сервер за URL від клієнта ходить у внутрішню мережу.
  8. API8 Security Misconfiguration - дефолтні налаштування, відкритий CORS, відсутні security-заголовки.
  9. API9 Improper Inventory Management - забуті чи недокументовані версії й ендпоінти (shadow/zombie API).
  10. API10 Unsafe Consumption of APIs - сліпа довіра до даних від сторонніх API.

Links

Що таке CGI. Переваги, недоліки⚑

CGI (Common Gateway Interface) - це стандарт, який визначає, як веб-сервер взаємодіє з програмою, написаною на деякій мові. Веб-сервер запускає програму як виконуваний файл. Параметри запиту, такі як метод, шлях, заголовки тощо, передаються через змінні середовища.

Програма повинна прочитати ці змінні і записати в стандартний потік виводу відповідь HTTP.

Переваги

  • Протокол не накладає обмеження на мову, на якій написана програма. Це може бути як сценарій, так і виконуваний файл.
  • Протокол дуже простий.
  • Програма не зберігає стан, що спрощує відладку.

Недоліки

  • Запуск процесу ОС на кожен запит працює дуже повільно.
  • Передача даних через stdout повільніше, ніж через Unix-сокети.

Що таке API [💡16/100]⚑

API - це скорочення від "Application Programming Interface" (прикладний програмний інтерфейс). Це набір правил і протоколів, які дозволяють різним програмам взаємодіяти одна з одною. API визначає, які функції та можливості надаються програмою для використання іншими програмами. Це як контракт між програмами: одна програма обіцяє надавати певні функції, а інша може з ними взаємодіяти.

В об'єктно-орієнтованому проектуванні код представлений у вигляді сукупності об'єктів. У додатку таких об'єктів, що взаємодіють між собою, можуть бути сотні. У кожного з них є свій API-набір публічних властивостей і методів для взаємодії з іншими об'єктами в додатку. Об'єкти можуть також мати приватну, внутрішню логіку, яка прихована від оточення і не є API.

Асинхронність у API⚑

API за своєю природою підтримує синхронну модель комунікації, де клієнт відправляє запит і отримує відповідь у межах одного з’єднання. Проте існують різні підходи, які дозволяють реалізувати асинхронну комунікацію в REST API, щоб обробляти довготривалі операції або отримувати дані без постійного опитування сервера.

Polling (Опитування)

Polling — це метод, при якому клієнт періодично надсилає запити на сервер, щоб дізнатися про статус операції або отримати нові дані. Це може бути корисно, коли обробка запиту займає певний час, і клієнт періодично опитує сервер на предмет змін.

  • Приклад. Клієнт може надіслати запит на створення ресурсу і отримати відповідь з кодом 202 Accepted. Потім він періодично надсилає запити на статус ресурсу через певні інтервали часу.
  • Недолік. Постійне опитування збільшує навантаження на сервер і може бути неефективним.

Long Polling (Довге опитування)

Long Polling працює подібно до звичайного опитування, але сервер тримає з’єднання відкритим, поки не з’являться нові дані або зміни. Це дозволяє знизити частоту запитів, оскільки сервер відповідає тільки тоді, коли є нові дані.

  • Приклад. Клієнт робить запит до сервера, і сервер затримує відповідь до моменту появи необхідних даних (наприклад, завершення операції).

Webhooks

Webhooks дозволяють серверу надсилати дані безпосередньо клієнту, коли подія відбувається. Це ефективний спосіб для асинхронної комунікації між сервісами або для оновлення статусу клієнта без необхідності постійного опитування.

  • Приклад. Клієнт реєструє URL для webhook, і коли сервер завершує обробку завдання, він надсилає HTTP POST-запит на цей URL з результатами. Це типово використовується для сервер-до-сервер інтеграцій.
  • Недоліки. Webhooks можуть бути ненадійними, якщо клієнтський сервер недоступний у момент надсилання запиту.

Потрібно завантажити відео з сайту. Як перевірити чи вистачить місця на диску?⚑

  • HEAD-запит - щоб отримати інформацію про розмір файлу на сервері без фактичного завантаження файлу. Зазвичай, сервер надсилає заголовок "Content-Length" у відповіді, який вказує на розмір файлу.
  • Перевірка вільного місця на диску - за допомогою стандартних засобів мови Python, таких як модуль os (os.statvfs() або інших методів).

Альтернатива окремому HEAD - частковий GET із заголовком Range: bytes=0-0: сервер повертає лише запитаний діапазон і заголовок Content-Range, що містить повний розмір файлу. Цей варіант працює тільки якщо сервер підтримує діапазонні запити, про що свідчить заголовок Accept-Ranges: bytes у відповіді.

Діапазонні запити лежать в основі відновлюваного (resumable) та паралельного завантаження: відповідь зі статусом 206 Partial Content містить лише вказаний фрагмент, тому перерване завантаження можна продовжити з потрібного байта, а не завантажувати файл наново.