SSH

📶 Почему рядом с роутером Wi‑Fi быстрый, а через две стены — уже нет?
Начинаем новую серию — «Как устроен Wi‑Fi».
Кажется, что Wi‑Fi либо «ловит», либо «не ловит». Но значок с тремя полосками ещё не означает, что соединение будет быстрым.
Радиосигнал постоянно теряет энергию.
На него влияют:
📏 расстояние до точки доступа
🧱 стены и перекрытия
🚪 двери и мебель
📡 соседние Wi‑Fi-сети
📱 другие радиоустройства
И даже материал стены имеет значение: гипсокартон и железобетон для радиосигнала — совсем не одно и то же.
Но есть ещё один важный фактор — частота.
Большинство домашних роутеров работают как минимум в двух диапазонах:
2,4 ГГц
и
5 ГГц
У каждого свои особенности.
📡 2,4 ГГц
Сигнал обычно распространяется дальше и лучше проходит через препятствия.
Но этот диапазон довольно тесный и часто перегруженный. Здесь работают не только соседние Wi‑Fi-сети, но и другие устройства, например Bluetooth. Помехи в диапазоне 2,4 ГГц могут создавать и некоторые бытовые устройства. Cisco Team Development
🚀 5 ГГц
Здесь доступно больше спектра и обычно проще получить высокую скорость с меньшим количеством помех.
Но распространение сигнала хуже, чем у 2,4 ГГц: расстояние и стены становятся заметнее. Cisco
Поэтому вполне нормальна ситуация:
рядом с роутером телефон подключён к 5 ГГц и показывает отличную скорость;
вы уходите через несколько стен — уровень сигнала падает, скорость уменьшается, а устройство может переключиться на 2,4 ГГц.
💡 И ещё интересный момент.
На 2,4 ГГц каналы расположены очень близко друг к другу и могут перекрываться.
Именно поэтому выбор канала имеет значение: соседние точки доступа способны мешать друг другу. Cisco
🔧 Мини-эксперимент
Запустите проверку скорости рядом с роутером.
Затем отойдите в самую дальнюю комнату и повторите тест.
А потом посмотрите, к какому диапазону подключено устройство: 2,4 или 5 ГГц.
Результат иногда очень наглядно показывает, что проблема «медленного интернета» находится вовсе не у провайдера.
Интернет до квартиры может приходить на полной скорости.
А потерять её можно уже на последних десяти метрах — между роутером и телефоном.
В следующем посте разберём каналы Wi‑Fi: почему вокруг может быть десяток сетей, каким образом они мешают друг другу и почему «поставить самый свободный канал» не всегда так просто. 📡

🌐 Как компьютер понимает, куда отправить пакет?

В прошлый раз мы разобрались, как DNS превращает имя сайта в IP-адрес.

Допустим, браузер уже знает:

example.com → 93.184.216.34

Но теперь возникает новый вопрос:

как компьютер физически отправит данные по нужному адресу?

Тут в игру вступают локальная сеть, MAC-адреса, ARP и шлюз.

1️⃣ Сначала компьютер сравнивает адрес назначения со своей сетью

Например, у компьютера адрес:

192.168.1.20

а маска сети:

255.255.255.0

Это означает, что устройства 192.168.1.x находятся в его локальной сети.

А адрес 93.184.216.34 находится где-то в интернете.

Значит, напрямую отправить пакет этому серверу компьютер не сможет.

2️⃣ Пакет нужно передать шлюзу

Шлюзом обычно является домашний роутер.

Например:

192.168.1.1

Именно ему компьютер передаст пакет, чтобы роутер отправил его дальше.

Но для передачи данных внутри Ethernet или Wi-Fi одного IP-адреса недостаточно.

Нужен ещё MAC-адрес устройства.

3️⃣ Как узнать MAC-адрес роутера?

Для этого в IPv4 используется протокол ARP.

Компьютер фактически спрашивает локальную сеть:

Кто имеет IP 192.168.1.1?

Роутер отвечает:

Это я. Вот мой MAC-адрес.

Например:

A4:5E:60:12:34:56

После этого компьютер может сформировать Ethernet-кадр и отправить его роутеру.

4️⃣ Что интересно: IP сервера не меняется

Внутри IP-пакета по-прежнему указано:

назначение → 93.184.216.34

Но Ethernet-кадр отправляется:

MAC назначения → MAC роутера

То есть:

IP говорит, куда пакет должен попасть в итоге.

А MAC помогает передать его следующему устройству внутри локального участка сети.

🔧 Можно посмотреть самому

В Windows:

arp -a

В Linux:

ip neigh

Вы увидите таблицу известных соседних устройств и соответствующие им MAC-адреса.

💡 Поэтому ваш компьютер совсем не обязан знать MAC-адрес удалённого сервера.

Ему достаточно знать MAC следующего узла — обычно домашнего роутера.

ользовал браузер.
Итак, мы уже прошли почти весь путь:
адрес сайта → DNS → IP → ARP → шлюз → TCP → TLS → 🔐
В следующей части наконец отправим сам HTTPS-запрос на сервер и посмотрим, как ответ возвращается обратно через интернет.

🌐 Как компьютер понимает, куда отправить пакет?
В прошлый раз мы разобрались, как DNS превращает имя сайта в IP-адрес.

Допустим, браузер уже знает:
example.com → 93.184.216.34

Но теперь возникает новый вопрос:
как компьютер физически отправит данные по нужному адресу?
Тут в игру вступают локальная сеть, MAC-адреса, ARP и шлюз.

1️⃣ Сначала компьютер сравнивает адрес назначения со своей сетью
Например, у компьютера адрес:
192.168.1.20
а маска сети:
255.255.255.0
Это означает, что устройства 192.168.1.x находятся в его локальной сети.
А адрес 93.184.216.34 находится где-то в интернете.
Значит, напрямую отправить пакет этому серверу компьютер не сможет.

2️⃣ Пакет нужно передать шлюзу
Шлюзом обычно является домашний роутер.
Например:
192.168.1.1
Именно ему компьютер передаст пакет, чтобы роутер отправил его дальше.
Но для передачи данных внутри Ethernet или Wi-Fi одного IP-адреса недостаточно.
Нужен ещё MAC-адрес устройства.

3️⃣ Как узнать MAC-адрес роутера?
Для этого в IPv4 используется протокол ARP.
Компьютер фактически спрашивает локальную сеть:
Кто имеет IP 192.168.1.1?
Роутер отвечает:
Это я. Вот мой MAC-адрес.
Например:
A4:5E:60:12:34:56
После этого компьютер может сформировать Ethernet-кадр и отправить его роутеру.

4️⃣ Что интересно: IP сервера не меняется
Внутри IP-пакета по-прежнему указано:
назначение → 93.184.216.34
Но Ethernet-кадр отправляется:
MAC назначения → MAC роутера
То есть:
IP говорит, куда пакет должен попасть в итоге.
А MAC помогает передать его следующему устройству внутри локального участка сети.

🔧 Можно посмотреть самому
В Windows:
arp -a
В Linux:
ip neigh
Вы увидите таблицу известных соседних устройств и соответствующие им MAC-адреса.

💡 Поэтому ваш компьютер совсем не обязан знать MAC-адрес удалённого сервера.
Ему достаточно знать MAC следующего узла — обычно домашнего роутера.
Это третья часть серии «Путь пакета».
Следующий этап — TCP и TLS: как компьютер устанавливает соединение с сервером и договаривается о шифровании ещё до передачи страницы. 🔐

🔐 TCP и TLS: как браузер договаривается с сервером?
В прошлой части мы дошли до домашнего роутера: компьютер знает IP сервера и понимает, куда отправлять пакеты.
Но HTTPS-запрос ещё не отправлен.

Сначала браузеру и серверу нужно установить соединение.

1️⃣ Начинаем с TCP
Для HTTP/1.1 и HTTP/2 обычно используется TCP.
Перед передачей данных происходит так называемое трёхэтапное рукопожатие:
Клиент → SYN → Сервер
Клиент ← SYN-ACK ← Сервер
Клиент → ACK → Сервер
SYN означает примерно:
«Хочу установить соединение».
SYN-ACK:
«Готов. Я тебя услышал».
ACK:
«Отлично. Начинаем».
После этого TCP-соединение установлено. MDN Web Docs
Но соединение пока ещё не означает, что оно защищено.
2️⃣ Теперь подключается TLS
Именно TLS превращает обычное соединение в защищённое.
Браузер отправляет ClientHello и сообщает серверу поддерживаемые параметры.
Сервер отвечает ServerHello, стороны согласуют криптографические параметры и создают общие ключи сеанса.
Сервер также может передать сертификат, с помощью которого браузер проверяет его подлинность. В TLS 1.3 после выработки необходимых ключей оставшаяся часть рукопожатия уже защищена. RFC Editor
3️⃣ И только теперь можно безопасно передавать данные
После завершения TLS браузер и сервер получили ключи, которыми защищается дальнейший обмен.
Теперь уже можно отправить HTTPS-запрос:
GET /
и получить страницу.
Если кто-то перехватит трафик между вами и сервером, он не должен получить содержимое HTTPS-соединения в открытом виде.
💡 А как же HTTP/3?
Здесь схема немного другая.
HTTP/3 не использует TCP. Вместо него применяется QUIC поверх UDP, причём TLS интегрирован непосредственно в установление QUIC-соединения. Это позволяет сократить задержки при его установке. MDN Web Docs
🔧 Можно посмотреть самому
Откройте любой HTTPS-сайт в браузере и нажмите F12.
В инструментах разработчика откройте вкладку Network и добавьте столбец Protocol.
Там можно встретить:
h2 — HTTP/2
h3 — HTTP/3
Так можно посмотреть, какой протокол реально исп

🌐 DNS: как имя сайта превращается в IP-адрес

В прошлом посте мы дошли до момента, когда браузеру понадобился IP-адрес сайта.

Но откуда он его берёт?

Допустим, мы открываем:

`example.com`

Компьютер не начинает сразу опрашивать весь интернет. Сначала он проверяет, не знает ли ответ уже сейчас.

1️⃣ Проверяется кэш

Браузер, операционная система и DNS-резолвер могут уже помнить IP-адрес сайта.

Если запись ещё актуальна — ответ получаем почти мгновенно.

2️⃣ Запрос уходит DNS-резолверу

Обычно его предоставляет интернет-провайдер, но можно использовать и публичные DNS-серверы, например:

`1.1.1.1`
`8.8.8.8`

Именно резолвер занимается поиском ответа за нас.

3️⃣ Если ответа нет — начинается поиск

Упрощённо цепочка выглядит так:

`Корневой DNS → DNS зоны .com → DNS example.com`

Корневой сервер не знает IP сайта, но знает, где искать информацию о зоне `.com`.

Сервер зоны `.com` знает, какие DNS-серверы отвечают за `example.com`.

А уже авторитетный DNS-сервер домена возвращает нужную запись.

Например:

`example.com → 93.184.216.34`

4️⃣ Ответ сохраняется в кэш

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

Сколько именно — определяет параметр TTL — Time To Live.

Поэтому после изменения DNS-записей новый адрес иногда начинает работать не у всех одновременно.

🔧 Попробуйте сами

В Windows:

`nslookup example.com`

Можно явно указать DNS-сервер:

`nslookup example.com 1.1.1.1`

А в Linux/macOS удобно использовать:

`dig example.com`

💡 И вот важный момент:

Интернет-соединение может работать прекрасно, но если возникли проблемы с DNS, сайты по именам открываться не будут.

Именно поэтому фраза «интернет есть, а сайты не открываются» очень часто приводит администратора к проверке DNS.

🌐 Что происходит после того, как вы ввели адрес сайта и нажали Enter?

Кажется, что браузер просто «открывает сайт».
На самом деле за доли секунды происходит целая цепочка сетевых событий.

Допустим, вы вводите:

example.com

Дальше примерно так:

1️⃣ Браузер выясняет IP-адрес сайта
Имя example.com удобно человеку, но сети нужен IP-адрес.
Для этого используется DNS — своего рода телефонная книга интернета.

2️⃣ Компьютер понимает, куда отправить пакет
Если сервер находится не в вашей локальной сети, данные уходят через шлюз — обычно это домашний роутер.

3️⃣ Роутер отправляет данные дальше
Пакеты проходят через сеть провайдера и несколько промежуточных маршрутизаторов.

4️⃣ Устанавливается защищённое соединение
Для HTTPS браузер договаривается с сервером о шифровании через TLS.

При HTTP/1.1 и HTTP/2 обычно используется TCP.
При HTTP/3 — QUIC поверх UDP.

5️⃣ Браузер отправляет HTTP-запрос
Например: «Пришли мне главную страницу».

6️⃣ Сервер отвечает
Возвращает HTML, а затем браузер начинает загружать CSS, JavaScript, картинки, шрифты и другие ресурсы.

И всё это часто происходит быстрее, чем мы успеваем моргнуть.

🔧 Мини-эксперимент

На компьютере попробуйте:

nslookup example.com

Команда покажет, какой IP-адрес DNS нашёл для сайта.

А дальше можно попробовать:

tracert example.com

в Windows

или

traceroute example.com

в Linux/macOS.

Так можно увидеть часть маршрута, по которому ваши пакеты идут через интернет.

Это первый пост небольшой серии «Путь пакета».

Завтра разберём DNS подробнее:
кто именно отвечает на вопрос «Какой IP у этого сайта?» и почему иногда DNS ломает весь интернет. 🌐