Доки Арута

Стек TCP IP

Стек TCP IP

Интернет везде

Есть две крайности в среде функционирования компьютерных сетей. Приложения (прикладной уровень) и среда передачи (канальный уровень), а между ними уровни стека TCP/IP.
Среди бывает разная: радио, провода, световоды (оптические провода).
При инкапсуляции каждый уровень, а именно технология каждого уровня упаковывает данные в условный конверт (который на каждом уровне по-разному называется) со своим заголовком.
Деление сетевого стека очень условно, о делениях, их количестве и т.п. спорят и спорят. В целом это всё абстракции. Рассматривать буду дефолтное деление этого стека на 4 уровня.

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

На этом уровне используются физические адреса для идентификации - MAC адреса (Media Access Control). Они обычно присваиваются производителями устройств. В таком случае производителям даются адреса, где первые 3 октета неизменны, а последние они вольны сами выбирать.

Межсетевой (Internet) уровень

В инете взаимодействуют сети с сетями, а не компы с компами. Здесь протоколы DHCP, ICMP (ping), ARP, RARP и т.д.
Здесь используются IP адреса (Internet Protocol), которых (уже) всего ~4млрд. Нехватка IPv4 адресов решается, например, построением локальных сетей. Подробнее:

В домашней локальной сети провайдер дает маршрутизатору внешний (белый, “из интернета”) IP адрес, а устройствам в локальной сети сервер DHCP (Dynamic Host Configuration Protocol) на шлюзе (маршрутизаторе) дает локальный (внутренний, серый) IP адрес для идентификации внутри локальной сети. Устройства в локальной сети выходят в инет через белый, выделенный провайдером, IP адрес. То есть внешний IP у всех local devices будет одинаковым.
Можно и купить белый IP у у провайдера, чтобы выходить в инет с него и/или чтобы к нему могли обращаться в инете другие юзеры (устройства, по сути).

Узел (устройство, хост) хочет отправить запрос другому узлу. У него два варианта:

  • Если при проверке выяснится, что target IP address находится в local сети, то узел обратиться к нему напрямую.
  • В другом же случае (при ненаходе IP среди local IP’s) узел обратится к своему шлюзу (DHCP при раздаче IP адресов (ок, присваивании) дает еще и IP шлюза для выхода в инет, чтобы узлы знали, куда обращаться) для отправки запроса и т.п. в другие сети. Шлюз - выделенное провайдером устройство, а точнее IP этому устройству для выхода в иные сети. И шлюз уже перекидывает запрос или другие данные провайдеру, а провайдер в DNS (Domain Name System) сервера и т.д. … Схема:

То есть, лично у нас-то нет никакого “инета”, есть только доступ к нему через технологии и устройства, описанные выше.

Трансляция IP в MAC и наоборот

Для трансляции IP в MAC есть два протокола ARP и RARP
(Address Resolution Protocol и Reverse ARP). Один преобразует IP в MAC, а другой MAC в IP.

Как могут общаться узлы?

  • UNICAST (узел2узел, host2host)
  • MULTICAST (host2group) сообщение увидят/услышат все IP в данной группе
  • BROADCAST (широковещательное сообщение) увидят/услышат все. 255.255.255.255 - адрес broadcast-а

Broadcast применяется чаще, чем думаешь. 👇

Применения Broadcast-а

ARP
Протокол ARP работает на шлюзах и отправляет broadcast запросы, чтобы найти ассоциации IP устройств в local сети с их MAC адресами. По типу:

Шлюз: Есть кто с 192.168.1.5?
Если да - какой у тебя MAC адрес?

И сохраняет это соответствие в ARP cache и в последующие разы не “спрашивает”, а пользуется этим ARP кэшем.
P.s. Если IP поменяется у устройства, то будет ошибка соответствия и ARP отправит еще один broadcast, чтобы найти новое соответствие и обновить ARP cache.

DHCP
При подключении к новой сети, например, к открытой сети “Вкусно - и точки” у узла нет IP адреса и он не может даже обратиться к шлюзу (чтобы получить IP), на котором стоит DHCP сервер, потому что не знает какой IP у шлюза. Он вообще почти ничего не может - у него нет IP.
Поэтому он посылает broadcast message всем в этой сети и узел, на котором стоит DHCP сервер (шлюз) дает ему конфигурацию (IP, маску подсети, IP адрес DNS сервера и другие почти произвольные данные). Всё, у узла есть IP адрес.

Транспортный уровень

Этот уровень предлагает правила передачи данных. Здесь работают протоколы TCP и UDP (в основном)
Данные в компьютерных сетях передаются кусками и есть два подхода:

UDP (User Datagram Protocol)
UDP обеспечивает простую передачу данных без контроля передачи, установления связи и получения данных. Естественно, не без потерь данных.
Но в случаях, когда потеря маленьких кусков не страшна, например, стриминг видео (youtube тоже стримит все свои видосы) или аудио, потеря одного кадра не критична (вряд ли даже заметишь), как и в случае с аудио. Мозг сам достроит то, что надо.

TCP (Transmission Control Protocol)
TCP обеспечивает передачу данных c контролем передачи и т.д. Перед передачей данных происходит трехстороннее рукопожатие:

Узел по протоколу TCP отправляет SYN пакет (запрос на передачу) на установление связи с другими узлом, а тот отвечает ему SYN ACK (подтверждение, типа готовность), и , наконец, первый узел кидает ACK (типа “кайф, let’s go”). Есть и другие флаги в заголовке TCP: URG, RST, FIN. При завершении соединения происходит двухстороннее рукопожатие: сторона, которая хочет завершить сеанс, отправляет пакет с заголовком FIN, вторая сторона отвечает ему ACK и когда будет готова завершить - тоже кидает FIN, чтобы первая сторона ответила ACK. Можно и RST кинуть, чтобы принудительно закрыть сеанс, но так, допусти, сервер не успеет правильно закрыть приложения, участвовавшие в сеансе передачи данных.

После этого трехстороннего рукопожатия происходит передача данных. При получении куска данных узел дает знать, что кусок данных получен и готов принять следующий. При потерях пакетов (кусков) они пересылаются и так данные доходят в исходном виде без потерь. Из-за этого TCP медленнее, чем UDP.

Прикладной уровень

Уровень приложений, взаимодействие с юзером. Здесь работают протоколы HTTP, FTP, POP3, SMTP, DNS, SSH, BitTorrent и т.д.

Про DNS
DNS - распределенная база данных соответствий IP адреса с доменным именем (грубо). При вводе в адресной строке браузера какого либо домена браузер (по логике) ищет в файле hosts соответствия. При ненаходе отправляет DNS запрос за сервера DNS. Там уже DNS сервера сами смотрят - у кого есть инфа, которая нужна, сами кидают запросы друг другу и в итоге один из тех серваков (который нашел у себя инфу) отправляет браузеру IP-шку, с помощью которого браузер сможет отправить запрос на веб сервер, чтобы получить нужный ему ресурс. И все это потом хранится в DNS cache, чтобы (утрируя) сайты быстрее открывались.

DNS использует UDP:

Я и не мог подумать, что DNS использует ненадежный UDP.
Но оказалось, что кроме очевидного преимущества в скорости, (хотя это очень важно, если учесть, какие нагрузки на DNS сервера были бы с TCP) у UDP есть и другие плюсы в таком случае. DNS-запросы хорошо помещаются в UDP-сегменты потому, что запросы сами по себе маленькие. И + на прикладном уровне ненадежность UDP компенсируют использованием повторной отправки UDP-пакетов (которые не достигли target-а) и коротким таймаутом (все DNS ответы должны быть получены клиентом в течение 10 секунд после отправки запроса - так снижается риск потери UDP пакетов).

DNS-записи (по сути, инфа о домене) бывают разных типов:
A-записи - для разрешения соответствия домена с IP (IPv4)
AAAA-записи - same, но IPv6
MX-записи - инфа об электронной почте
TXT-записи - справочная инфа
NS-записи - инфа о DNS серверах, обслуживающих этот домен
И т.д. Посмотреть их можно с помощью cli tool-а dig, либо на сервисе гугла (который использует тот же dig, но вывод нагляднее).

Кстати, у нагруженных серверов несколько IP для равномерного распределения запросов и нагрузки.

Про пОрты
Чтобы сообщения доставлялись куда надо, то есть, в нужную службу, приложение и т.д., нужен порт в списке передаваемых данных. Мы, понятно, что сами не прописываем порт, он сам ставится. И вот так данные и передающие их протоколы/службы знают куда конкретно доставлять инфу.

Серверные порты от 0 до 1023, а после 1024 (включительно) идут пользовательские. Есть и динамический диапазон портов для клиентских приложений: 49152-65535. Все эти деления условны. Посмотреть наглядно какие сервисы какие порты используют можно в /etc/services, в котором хранится список сетевых служб и порты, которые они используют.

Несколько примеров пОртов (ударение так ставлю) для наглядности мб:

СлужбаПорт
FTP21
SSH, SCP22
TELNET23
SMTP25, 587
DNS53
HTTP80
HTTP over SSL443
POP3110
Steam1725
OpenVPN1194
MySQL3306
BitTorrent6881, 6999
BGP179
DHCP67
LDAP389
MQTT1833
NTP/PTP123
SIP5060/5061
SNMP161/162
XMPP5222/5269/5280

Схема инкапсуляции и декапсуляции данных между уровнями

network

Graph View

Backlinks

  • No backlinks found