Автор: Александр Коленко
Привет, дорогой читатель!
Зарегистрируйтесь и получите доступ к бесплатному контенту. А также будьте в курсе нового учебного контента. Ссылка на учебную платформу:
Если материал полезен, то есть способ отблагодарить меня. Любая сумма будет отличной наградой и стимулом писать полезный контент для Вас.
TCP/IP – это фундаментальный протокол, используемый современными сетями. В реальности TCP/IP это комбинация двух протоколов: протокола управления передачей (TCP) и интернет-протокола (IP). Оба они являются частью набора интернет-протоколов (IPS), концептуальной модели того, как сетевые протоколы отправляют сетевой трафик по сети. Таким образом, обмен данными можно разделить на четыре уровня, как показано на следующем рисунке.
В данном материале я не стану касаться моделей OSI и TCP/IP, так как есть упрощенная, более наглядная модель обмена данными
Далее, в коротком видео, я опишу сам алгоритм взаимодействия приложений на примере работы информационной системы "клиент-сервер"
Итак, на клиенте (инициаторе) соединения TCP/IP выделяет порт из диапазона 49152—65535. А на стороне сервера прослушивающие службы должны иметь статически определяемый порт из диапазона 0—1023 если речь идет о общеизвестных службах. В случае если мы используем самостоятельно разработанное приложение, использующее для своей работы TCP, то нам следует использовать порты из диапазона 1024—49151.
Резюмируя по портам:
Всего портов - 65536.
Все порты разделены на три диапазона:
— общеизвестные (или системные, 0—1023);
— зарегистрированные (или пользовательские, 1024—49151);
— динамические (или частные, 49152—65535).
Давайте подробнее остановимся на сокетах (sockets) :
В видео я говорил, что сокет - совокупность IP адреса и порта.
Если упростить, то IP адрес -это номер дома, а порт это номер конкретной квартиры (приложение). Вы можете встретить такое выражение как мультиплексирование сервисов. Именно сокеты и позволяют узлу мультиплексировать.
Теперь Вам должно быть предельно понятно следующее определение:
Транспортный уровень (уровень 3) – отвечает за соединения между клиентами и серверами, обеспечивая правильный порядок пакетов, повторную передачу в случае потери или искажения и предоставляя мультиплексирование сервисов. Мультиплексирование сервисов позволяет одному узлу поддерживать несколько различных сервисов, присваивая каждому сервису разные номера; этот номер называется портом. На этом уровне работают протоколы TCP и UDP.
С мультиплексированием на базе сокетов мы разобрались, но в определении есть еще ряд основных функций, отвечающих за надежность доставки трафика! Все верно - надежность - основная задача протокола TCP.
Особенности надежной службы доставки пакетов (функциональные средства устранения ошибок)
Начнем с того какими основными особенностями характеризуется интерфейс между приложением (прикладной уровень) и модулем TCP/IP (транспортный уровень):
1.Обработка потоков данных;
2.Подключение по виртуальному каналу;
3. Буферизованная передача;
4.Неструктурированные потоки;
5.Дуплексное соединение.
Подробно по данным характеристикам в следующем видео:
В данном видео я постарался рассказать как функционирует интерфейс между прикладным и транспортным уровнями. Но как сам TCP обеспечивает надежность. Если коротко, то с помощью механизма подтверждения приема с повторной передачей (positive acknowledgement with retramsmission). Суть в том, что приняв данные, получатель должен отправить отправителю подтверждение приема (ACK). Пока отправитель не получил ACK отправленные данные хранятся в буфере передачи так же как и те что готовы к отправке. Отправляя пакет отправитель запускает таймер (RTO) по истечении которого, если не поступило ACK, отправка (retransmit) осуществляется повторно. RTO (retransmition time out). При установлении соединения RTO устанавливается по умолчанию, но потом, в ходе реального обмена трафиком, RTO адаптируется исходя из среднего значения RTT (Round-Trip Time). В случае c TCP, RTT это время между передачей сегмента и приемом подтверждения о его доставки.
Нормальный обмен данными без потерь (простейший случай):
Обмен данными с потерей пакетов:
На последнем рисунке, после повторной передачи пакета, мы таки получили ACK до истечения таймера RTO. Но как TCP себя поведет если мы отправим повторно, а подтверждения нет? Ответ на следующем рисунке:
Из данного рисунка видно, что с каждой новой попыткой таймер удваивается и на 5-й попытке сессия разрывается хостом отправителя. Логично? Абсолютно! Данная ситуация свидетельствует от том, что на стороне хоста получателя или в сети что-то произошло и далее не имеет смысла пытаться передавать.
Интересный факт! Количество попыток осуществить retransmit зависит от реализаций TCP в операционных системах. Так к примеру хосты под управлением Windows делают 5 попыток, а под управлением Linux - до 15 таких попыток.
Вот пример повторных передач из реального дампа:
Если приглядится к временной шкале, то видно как время до очередной отправки удваивается.
С механизмом недопущения утери данных разобрались в простейшем случае разобрались. Дальше внимания требует механизм повышения эффективности и не допущения перегрузок, вызывающих сброс пакетов на транзитных участках в сети и непосредственно на стороне прикладных уровней. Этот механизм связан с таким понятием как движущиеся окна (sliding window).
Итак, вернемся к схеме нормального обмена данными:
Из схемы видно, что отправка пакета 2 будет осуществлена только после подтверждения получателем. Общая задержка при передаче по сети и обработке на приемной стороне (упорядочивание, сравнение контрольной суммы) достаточно существенна и не использовать виртуальный канал в этот период было бы расточительным.
Другими словами в простейшем случае использование технологи подтверждения приема с повторной передачей приводит к существенному снижению пропускной способности, поскольку отправка нового пакета откладывается до момента получения подтверждения о приеме предыдущего пакета.
Механизм движущихся окон является более сложным вариантом технологии подтверждения приема с повторной передачей. Он позволяет эффективно использовать полосу пропускания за счет того, что дает возможность отправлять сразу несколько пакетов, не дожидаясь подтверждения приема каждого пакета. Проще всего описать работу метода движущихся окон можно следующим рисунком:
При согласовании параметров сессии обе стороны определяют свой размер окна. К примеру принимающая сторона определила размер движущегося окна равным 8. И это означает, что передающая сторона может сразу последовательно передать 8 пакетов не дожидаясь получения подтверждения. До момента получения подтверждения по первому пакету модуль TCP отправителя переходит в режим ожидания. Получив подтверждение по первому пакету окно сдвигается и к отправке уже возможен 9-й пакет. По мере получения новых подтверждений окно все время сдвигается вправо. Производительность данного метода зависит от самого размера окна, от скорости пересылки пакетов, задержек (latency) как со стороны сети, так и со стороны приложения. Изначальный размер окна определяется модулем TCP на основании доступного буфера приема. Необходимо помнить, что такие параметры как размер окна и RTO динамически изменяются модулем TCP зависимости от ситуации на сети и на стороне приложений клиент-сервер. Далее я еще затрону логику изменения размера окна при заполнении буфера и потерях на транзитных участках в сети.
На следующем рисунке продемонстрирована ситуация при которой размер окна равен 3-м. Обратите внимание, что отправитель успевает послать все три пакета в сеть до того, как будет получено хотя бы одно сообщение о подтверждении их приема.
Если принять размер окна равным единице, то метод движущихся окон ничем не будет отличаться от простейшего (не оптимального) случая обмена данными без потерь.
При использовании метода движущихся окон правильный выбор размера окна позволяет полностью исключить простои в сети, достичь большей производительности
Пассивное и активное открытие соединений
В видео я описывал последовательность установления соединения в общем. Если верхнеуровнево, то сокеты на стороне клиента (инициатора сессии) и сервера (таргета сессии) замыкаются образуя виртуальный канал и дальше по нему передаются пакеты (сегменты). Но если капнуть чуть глубже, то на стороне клиента происходит активное открытие соединения (создания сокета) по запросу приложения, в то время как на стороне сервера сокет уже существует в пассивном (слушающем) состоянии.
Если необходимо записать данный процесс в динамике (на видео) пишите в комментариях.
Сегменты, потоки и порядковые номера
Уверен у вас возникла путаница в голове по поводу того где использовать понятие кадр (фрейм), пакет, сегмент, а где поток. Перед тем как я углублюсь в тему заголовка давайте проясним, что мы понимаем под этими терминами в сущности и где происходит подмена понятий для упрощения.
Итак, в сущности картина следующая:
Прикладной уровень: Когда мы говорим про трафик между приложениями, то мы говорим про поток. То есть данные поступающие от приложения к модулю TCP/IP это поток;
Транспортный уровень: Поток данных поступающих модулю TCP/IP дробится на байты и уже из этих байтов TCP формирует сегмент;
Сетевой уровень: Каждый сегмент оборачивается(инкапсулируются) в IP пакет и передается по сети в соответствии с правилами маршрутизации IP пакетов. Иногда можно встретить такое понятие как IP-дейтаграмма, это тоже самое что и пакет;
Канальный уровень: IP пакеты, попадая на канальный уровень инкапсулируются в кадры (фреймы).
А в реальности картина такова, что специалисты могу все обзывать пакетами считая, что из контекста понятно о чем конкретно идет речь.
Процесс инкапсуляции (матрешка) хорошо показан на следующем рисунке:
Продолжение в следующей статье "TCP/IP (Часть 2) просто о сложном"
Перечень использованной литературы:
1. Сети TCP/IP (Дуглас, Камер);
2.Анализ пакетов. Практическое руководство по использованию Wireshark (Крис Сандерс);
3.Атака сетей на уровне протоколов (Джеймс Форшой).