Q&A по Мережах (networks)

IP (Internet Protocol) – протокол мережевого рівня стека TCP/IP.

Основним завданням протоколу є доставка датаграм між хостами мереж TCP/IP через довільне число проміжних вузлів (маршрутизаторів).

Функції, що реалізуються IP:

• Основа передачі даних.
• Адресація.
• Маршрутизація.
• Фрагментація датаграм.

Протокол IP не гарантує надійної доставки пакета: пакети можуть прийти в неправильному порядку, пакет може бути втрачений, пакет може продублюватися або виявитися пошкодженим. За надійність доставки пакетів відповідають протоколи транспортного рівня.

На даний момент найбільш поширена четверта версія протоколу (IPv4), однак ведуться активні роботи по впровадженню більш досконалого IPv6.

2^(32-N)-2, де

• N маска: /24, /23, /19;
• 32 біт в масці;
• -2 зарезервованих адреси: 1 адреса мережі і 1 broadcast.

Отже:

мережа | математика | відповідь

—————–|—————|————-

192.168.5.0/24 | 2^(32-24)-2 | = 254 хостів

192.168.5.0/23 | 2^(32-23)-2 | = 510 хостів

192.168.5.0/19 | 2^(32-19)-2 | = 8190 хостів

127.0.0.1 адреса або localhost доменне ім’я, а також зарезервована мережа 127.0.0.1/8 приватних IP адрес призначені для тестування програми на тій же фізичній машині, де вона запускається.

Використання адреси 127.0.0.1 дозволяє встановлювати з’єднання і передавати інформацію для програм-серверів, що працюють на тому ж комп’ютері, що і програма-клієнт, незалежно від конфігурації апаратних мережевих засобів комп’ютера (не потрібна мережева карта, модем, і інше комунікаційне обладнання, інтерфейс реалізується за допомогою драйвера псевдопристрою в ядрі операційної системи)

Так само адреса 127.0.0.1 встановлюється для заборони доступу до сервісу з зовнішньої мережі. Наприклад:

docker run -d -p 127.0.0.1:3306:3306 mysql


Будь-який URL містить наступну структуру <протокол>/<хост>/шлях, наприклад https://yandex.ru/pogoda/samara. Також URL може містити дані для відображення сторінки.

• При введенні URL браузер дивиться на протокол запиту. Якщо протокол в URL не вказаний, то браузер дивиться на список HSTS (HTTP Strict Transport Security – механізм, примусово активуючий захищене з’єднання через протокол HTTPS), якщо хост є в даному списку, то браузер відправить запит по протоколу HTTPS, якщо ні, то по HTTP.
• Для того, щоб встановити з’єднання з сервером, необхідна його IP адреса. Так як ми використовуємо домен, то необхідно встановити відповідність домену і IP адреси сервера, де розміщується ресурс. При запиті ми звертаємося до DNS. Спочатку перевіряється кеш DNS. Пріоритет опитування DNS кешу наступний:
• Кеш браузера,
• Перевіряється hosts файл ,
• Кеш ОС,
• Кеш роутера,
• Кеш інтернет-провайдера

Якщо даних про даний запитуваний хост в кеші немає, то:

• DNS інтернет провайдера відправляє запит до кореневого сервера DNS (.),
• Якщо кореневий сервер не знає запитуваного домену, то він відправляє запит серверу відповідальному за зону (.ru), до якого прив’язаний домен,
• Якщо DNS сервер зони не знає запитуваного домену, то запит відправляється до NS сервера домену.

IP адреса хоста, при його наявності у DNS сервера, повертається назад по ланцюжку

• Після того, як IP адресу хоста отримали, необхідно сформувати на прикладному рівні запит до сервера. До запиту додаються наступні заголовки:
• Прикладний рівень: протокол запиту (HTTP/S, FTP і т.д),
• Транспортний (TCP/UDP): порт, по якому звертаємося до сервера.
• Мережевий рівень: IP адреса пакета
• Канальний рівень: визначає чи є така адреса в мережі. Якщо ні, то пакет передається шлюзу. Пристрій шлюзу перевіряє свою таблицю маршрутизації і направляє пакет в потрібному напрямку.
• Далі виконується наступний алгоритм дій встановлення з’єднання:
• Після того, як запит досяг сервера, клієнт відправляє клієнту запит (client hello) і свою версію протоколу TLS на захищене з’єднання.
• Сервер відповідає клієнту (server hello) з інформацією про вибрану версію TLS, методом шифрування, методом компресії і публічний сертифікат сервера, підписаний центром сертифікації. Сертифікат містить публічний ключ, який буде використаний клієнтом для шифрування даних.
• Клієнт підтверджує сертифікат сервера за допомогою свого списку центрів сертифікації. Якщо сертифікат підписаний центром зі списку, то серверу можна довіряти.
• Клієнт шифрує дані публічним ключем і відправляє серверу зашифроване повідомлення.
• Сервер розшифровує повідомлення за допомогою свого приватного ключа і генерує симетричний мастер-ключ і відправляє його клієнту.
• Клієнт відправляє серверу повідомлення про фініш, шифруючи хеш передачі за допомогою симетричного ключа.
• Сервер генерує власний хеш, а потім розшифровує отриманий від клієнта хеш, щоб перевірити чи збігається хеш клієнта з хешем сервера. Якщо збіг виявлено, то сервер відправляє клієнту повідомлення про фініш.

Після цього захищене з’єднання з сервером встановлено.

• Далі необхідно сформувати запит серверу:
• Клієнт формує запит HTTP, в якому бере участь метод (наприклад GET), URL і версію протоколу. Наприклад GET /pogoda/samara HTTP/2.
• Наступний заголовок клієнта HOST, в якому вказується до якого хоста необхідно звернутися. Наприклад HOST: yandex.ru. По заголовку HOST сервер може визначити до якого сайту на сервері необхідно звернутися.
• Запит може також містити і інші заголовки. Необхідно тільки, щоб сервер зміг зрозуміти ці заголовки.

TCP – транспортний протокол передачі даних в мережах TCP/IP, призначений для управління передачею даних інтернету. Пакети в TCP називаються сегментами.

Орієнтований на з’єднання, використовується для передачі даних (електронна пошта, файли, повідомлення). При визначенні втрати пакетів буде виконаний перезапит втрачених пакетів.

UDP – транспортний протокол, що передає повідомлення-датаграми без необхідності встановлення з’єднання в IP-мережі. Не орієнтований на встановлення з’єднання, використовується в потоковій передачі даних (IPTV, VoIP). При втраті пакетів перезапиту втрачених пакетів не відбувається.

Не можна сказати, що TCP краще UDP, т.к. дані транспортні протоколи використовуються для різних типів передачі трафіку.

!TCP_Handshake

• Клієнт, який має намір встановити з’єднання, посилає серверу сегмент з номером послідовності і прапором SYN.

Подальший алгоритм:

Сервер отримує сегмент, запам’ятовує номер послідовності і намагається створити сокет (буфери і керуючі структури пам’яті) для обслуговування нового клієнта;

В разі успіху сервер посилає клієнту сегмент з номером послідовності і прапорами SYN і ACK, і переходить в стан SYN-RECEIVED;

​В разі невдачі сервер посилає клієнту сегмент з прапором RST.

• Якщо клієнт отримує сегмент з прапором SYN, то він запам’ятовує номер послідовності і посилає сегмент з прапором ACK.

Подальший алгоритм:

Якщо він одночасно отримує і прапор ACK (що зазвичай і відбувається), то він переходить в стан ESTABLISHED;

Якщо клієнт отримує сегмент з прапором RST, то він припиняє спроби з’єднатися;

Якщо клієнт не отримує відповіді протягом 10 секунд, то він повторює процес з’єднання заново.

• Якщо сервер в стані SYN-RECEIVED отримує сегмент з прапором ACK, то він переходить в стан ESTABLISHED.

В іншому випадку після тайм-ауту він закриває сокет і переходить в стан CLOSED.

Процес називається «триетапним рукостисканням» (англ. three way handshake), так як незважаючи на те що можливий процес встановлення з’єднання з використанням чотирьох сегментів (SYN в сторону сервера, ACK в сторону клієнта, SYN в сторону клієнта, ACK в сторону сервера), на практиці для економії часу використовується три сегменти.

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

!https-process

• 1XX — інформаційні коди. Вони відповідають за процес передачі даних. Це тимчасові коди, вони інформують про те, що запит прийнятий і обробка буде продовжуватися.
• 2XX — успішна обробка. Запит був отриманий і успішно оброблений сервером.
• 3XX — перенаправлення (редирект). Ці відповіді сервера говорять, що потрібно вжити подальших дій для виконання запиту. Наприклад, зробити запит по іншій адресі.
• 4XX — помилка користувача. Це значить, що запит не може бути виконаний по його вині.
• 5XX — помилка сервера. Ці коди виникають через помилки на стороні сервера. В даному випадку користувач все зробив правильно, але сервер не може виконати запит. Для кодів цього класу сервер обов’язково показує повідомлення, що не може обробити запит і по якій причині.

Два найбільш часто використовуваних види HTTP запитів це: GET та POST.

GET – запитує дані з певного ресурсу (сайту).

POST – відправляє дані на сервер для подальшої їх обробки.

Особливості GET запиту:

• Може бути закешований
• Залишається в історії браузера
• Може бути закладкою в браузері
• Не повинен використовуватися при роботі з вкрай важливими даними
• Має обмежену довжину
• Повинен застосовуватися тільки для отримання даних

Особливості POST запиту:

• Не кешується
• Не може бути закладкою в браузері
• Не залишається в історії браузера
• Немає обмежень по довжині запиту

| Заголовок | Опис |

|———–|———————————————————————————————|

| HEAD | Те ж саме що GET, однак повертає тільки HTTP заголовки і не повертає тіло документа. |

| DELETE | Видаляє певний ресурс. |

| PUT | Завантажує представлення певного URI. |

| OPTIONS | Повертає список видів запитів, що підтримуються веб-сервером. |

| CONNECT | Створює прозорий TCP/IP тунель для передачі запитів. |

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

Всі реалізації DNS серверів повинні підтримувати використання обох протоколів транспортного рівня (TCP і UDP). Більшість DNS-запитів буде оброблятися з використанням протоколу UDP, виняток складають трансфер зони (Query type AXFR) і відповіді сервера, що перевищують 512 байт на одне повідомлення. На питання “навіщо?” відповідь простий — щоб не використовувалися для DDoS.

Основні DNS записи:

| Тип | Розшифровка | Опис |

|-|-|-|

| A | Address | Адресний запис, відповідність між іменем і IP-адресою. |

| AAAA | Address v6 | Аналог A запису для IPv6 адрес. |

| CNAME | Canonical Name | Канонічне ім’я для псевдоніма (однорівнева переадресація) |

| MX | Mail Exchanger | Адреса поштового шлюзу для домену. Складається з двох частин — пріоритету (чим число більше, тим нижче пріоритет), і адреси вузла. |

| NS | Authoritative name server | Адреса вузла, що відповідає за доменну зону. Критично важлива для функціонування самої системи доменних імен. |

| PTR | Pointer | Відповідність адреси імені — зворотна відповідність для A і AAAA. |

| SOA | Start of authority | Вказівка на авторитетність інформації, використовується для вказівки на нову зону. |

| TXT | Text string | Запис довільних двійкових даних, до 255 байт в розмірі. |

| SPF | Sender Policy Framework | Вказує сервери, які можуть відправляти пошту з даного домену. |

DomainKeys Identified Mail (DKIM) — метод E-mail аутентифікації, розроблений для виявлення підробки повідомлень, що пересилаються по email. Метод дає можливість отримувачу перевірити, що лист дійсно був відправлений з заявленого домену. DKIM спрощує боротьбу з підробленими адресами відправників, які часто використовуються в фішингових листах і в поштовому спамі.

Domain-based Message Authentication, Reporting and Conformance (ідентифікація повідомлень, створення звітів і визначення відповідності по доменному імені) або DMARC — це технічна специфікація, створена групою організацій, призначена для зниження кількості спамових і фішингових електронних листів, заснована на ідентифікації поштових доменів відправника на підставі правил і ознак, заданих на поштовому сервері отримувача.

Інформація про DKIM і DMARC встановлюється в TXT записи домену.

Round-robin – алгоритм розподілу навантаження розподіленої обчислювальної системи методом перебору і впорядкування її елементів по круговому циклу.

Round-robin DNS працює, відповідаючи на запити не тільки одним IP-адресою, а списком з декількох адрес серверів, що надають ідентичний сервіс. Порядок, в якому повертаються IP-адреси зі списку, заснований на алгоритмі Round-robin. Тобто на практиці на доменне ім’я призначаються декілька IP адрес серверів, які відповідають на запити.