ITED
bootcamp
Лекция 5.2 - Основы компьютерных сетей
Синтез по материалам уроков 1-5
Эта лекция не повторяет уроки буквально, а связывает их в одну логическую историю. Мы начнем с вопроса "что такое сеть", затем шаг за шагом перейдем к моделям уровней, оборудованию, анализу трафика и прикладным протоколам.
Компьютерная сеть - это набор узлов и каналов связи, по которым передаются данные. Интернет является частным случаем: это крупнейшая сеть сетей, где независимые сегменты объединены общими протоколами.
Рис.: разные сегменты сети на разных технологиях
Большинство сервисов в интернете работает по модели клиент-сервер. Клиент инициирует запрос, сервер возвращает ответ. Эта схема лежит в основе веба, почты, облаков и API.
Рис.: схема "запрос - ответ" между клиентом и сервером
Чтобы понять ограничения сети, важно различать не только протоколы, но и архитектуру приложения. Клиент-сервер удобен для централизованного управления, P2P лучше распределяет нагрузку между узлами.
Когда сеть становится большой, возникают системные вопросы: что делать при потерях пакетов, как делить канал между пользователями, как защитить данные и как сохранить качество для разных приложений.
В реальной сети данные редко идут по идеальному прямому пути. При отказах и перегрузках сеть перестраивает маршрут, а транспортный уровень компенсирует потери и восстанавливает порядок данных.
Рис.: несколько альтернативных путей в составной сети
QoS (Quality of Service, "качество обслуживания") - это подход к управлению сетевыми ресурсами, чтобы разные классы трафика получали нужный уровень сервиса. Под телеком-сетями здесь понимаются сети операторов связи (телефонные, мобильные, магистральные), где исторически критично гарантировать качество голоса и видео. Позже те же принципы перенесли в IP-сети и стандартизовали через IETF (в том числе DiffServ, RFC 2475, 1998).
Смысл QoS в контексте нашего списка прост: приложения предъявляют разные требования, поэтому сеть не может одинаково обслуживать голос, видео и передачу файлов.
После тем надежности и QoS логично перейти к защите: даже идеально доставленные данные бесполезны, если их может прочитать или подменить злоумышленник.
Этот слайд задает мост к прикладному уровню: позже мы увидим, как безопасность проявляется в HTTP/HTTPS и инструментах анализа трафика.
Чтобы управлять сложностью, сеть разделяют на уровни. Каждый уровень решает ограниченный набор задач и предоставляет сервис уровню выше. Это делает систему масштабируемой и заменяемой по частям.
Модель OSI (Open Systems Interconnection) состоит из 7 уровней и используется как универсальная карта сетевых функций. Она особенно полезна в обучении, проектировании и анализе проблем.
Рис.: модель OSI и взаимодействие одноименных уровней
TCP/IP исторически сформировался в ARPANET и стал рабочей моделью интернета. В отличие от OSI, здесь 4 уровня - структура проще и ближе к реальной реализации в сетевом стеке ОС.
Здесь важно не "зубрить таблицу", а понимать эквивалент функций: OSI дает больше детализации, TCP/IP объединяет часть функций в более крупные уровни.
Рис.: сопоставление уровней OSI и TCP/IP
Когда приложение отправляет данные, каждый нижележащий уровень добавляет собственный заголовок. На принимающей стороне этот процесс идет в обратном порядке - заголовки снимаются последовательно.
Рис.: уровни и протоколы в стеке TCP/IP
Без общих стандартов оборудование и ПО разных производителей не смогли бы полноценно взаимодействовать. Стандарты создают общий "язык" для протоколов, форматов и оборудования.
На этом слайде мы связываем названия организаций с практикой: где находится центр, как расшифровывается аббревиатура и какой блок технологий они регулируют.
Документы RFC (Request for Comments, "запрос на комментарии") публикуются через IETF и задают детальную семантику протоколов: поля заголовков, состояния, алгоритмы обработки ошибок.
Практический вывод: при споре "как должен работать протокол" инженеры идут в RFC.
Этот слайд систематизирует оборудование, чтобы не было ощущения "набор устройств без логики". Мы связываем функцию, уровень TCP/IP, типичную стоимость и рабочую цель, а на следующем слайде разбираем различия на практических кейсах.
| Устройство | Уровень TCP/IP | Назначение | Типичный диапазон стоимости |
|---|---|---|---|
| Коммутатор (Switch) | Сетевой доступ | Коммутация кадров в одном сегменте | Низкий - средний |
| Точка доступа Wi-Fi | Сетевой доступ | Подключение беспроводных клиентов | Низкий - средний |
| Маршрутизатор (Router) | Интернет | Маршрутизация между подсетями | Средний - высокий |
| Домашний роутер | Интернет + сетевой доступ | Комбинирует AP, switch, NAT, DHCP | Низкий - средний |
Рис.: пример совмещенной домашней инфраструктуры
Коммутатор (switch) нужен для объединения проводных устройств в один локальный сегмент (офис, аудитория, серверная). Он пересылает кадры по MAC-адресам и не маршрутизирует между подсетями.
Точка доступа Wi-Fi (AP) нужна для подключения беспроводных клиентов к локальной сети. В классическом сценарии AP расширяет существующую LAN и передает трафик дальше в коммутатор/роутер.
Домашний роутер отличается тем, что совмещает несколько ролей сразу: маршрутизатор, небольшой коммутатор и точку доступа, плюс сетевые сервисы (NAT/DHCP/firewall).
Домашний роутер часто воспринимают как "коробку с Wi-Fi", но с инженерной точки зрения это несколько устройств в одном корпусе.
Именно поэтому один бытовой роутер реализует сразу несколько функций разных уровней TCP/IP.
MAC-адрес (Media Access Control) - это уникальный идентификатор сетевого интерфейса (сетевой карты) на канальном уровне, по которому устройство распознается внутри локальной сети. Его называют "аппаратным", потому что базовое значение обычно записывается производителем на заводе.
Связь с предыдущим слайдом: коммутатор и точка доступа принимают решения о доставке именно по MAC.
В отличие от MAC, IP адрес обеспечивает межсетевую адресацию и маршрутизацию. Именно IP позволяет пакету пройти через цепочку разных сетей от клиента до удаленного сервера.
IP адрес определяет хост, а порт определяет процесс на этом хосте. В паре они формируют сокет - конечную точку сетевого соединения для конкретного приложения.
Рис.: разные клиентские процессы работают через разные порты
Порты помогают быстро понять назначение трафика даже без полного анализа payload. Это не случайный набор чисел: well-known порты закрепляются и публикуются IANA (Internet Assigned Numbers Authority), а правила их регистрации и применения описаны в RFC (например, RFC 6335).
Теперь все предыдущие термины складываются в единый процесс. Браузер не может отправить HTTP-запрос, пока не узнает IP адрес по доменному имени.
Wireshark показывает "сырой" сетевой обмен и делает его читаемым. Это позволяет доказательно отвечать на вопрос: где именно проблема - у клиента, в сети или на сервере.
Рис.: три базовые панели Wireshark
Практический прием: выберите конкретное поле в дереве и смотрите, какие байты подсветились в дампе. Так лучше понимается структура заголовков.
Здесь многие путаются, поэтому формулируем четко:
Пример пары: capture - tcp port 80, display - http или tcp.port == 80.
http.request - только HTTP-запросыhttp.response - только HTTP-ответыdns - DNS обменip.addr == 192.168.1.1 - трафик конкретного хостаtcp.port == 443 - HTTPS сессии по портуРазбираем пакет по уровням: сначала Ethernet/Wi-Fi, затем IP, потом TCP/UDP и только после этого прикладной протокол. Для цельного просмотра диалога используем Follow TCP Stream.
Фоновый трафик - нормальное состояние сети: ОС, сервисы и оборудование постоянно обмениваются служебными данными.
Вывод: сначала фильтруем трафик, потом делаем выводы.
Прикладной уровень связывает сетевую инфраструктуру с задачами пользователя и бизнеса. Именно здесь появляются смысловые операции: открыть страницу, отправить письмо, запросить API.
API (Application Programming Interface) в веб-контексте - это интерфейс взаимодействия программ по протоколу HTTP. Клиент отправляет запросы к endpoint, сервер возвращает структурированные данные (обычно JSON).
REST-подход связывает операции CRUD с методами HTTP. Это не "магия", а согласованная инженерная практика для предсказуемого API.
Код ответа - это быстрая классификация результата. Правильная диагностика строится на связке: статус + заголовки + тело ответа.
Postman удобен для ручной проверки и визуальной работы, curl - для терминала, автоматизации и скриптов. Инженер должен уметь и то, и другое.
Рис.: ручное тестирование endpoint в Postman
Финальная практическая мысль лекции: диагностика должна быть последовательной. Не начинаем с предположений, начинаем с наблюдаемых фактов и проверяем уровни по очереди.
Мы прошли путь от базового понятия сети к прикладной инженерной практике. Ключевая связка: модель уровней объясняет архитектуру, адресация и оборудование обеспечивают доставку, анализатор трафика дает наблюдаемость, а API связывает сеть с задачами приложения.
Теперь можно обсуждать не отдельные термины, а инженерные сценарии целиком: где возникает ошибка, какой уровень за это отвечает, как это проверить и каким инструментом подтвердить.