🌐 Как компьютер понимает, куда отправить пакет?
В прошлый раз мы разобрались, как 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-адрес.
Допустим, браузер уже знает:
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
Так можно посмотреть, какой протокол реально исп
Просмотры: 2