
Очевидно, необходимо как-то дополнительно контролировать передачу пакетов по сети, т.е.
выявлять все вышеперечисленные проблемы и устранять их. Вам уже известны методы,
применяемые для этого (рассматривались при изучении модели OSI, протоколов LLC, HDLC, LAP-
B), однако имеет смысл кратко вспомнить эти методы. Вспоминаем, что единственным способом
контроля того, что все пакеты, посланные отправителем, достигли получателя, является
квитирование, т.е. отправка пакетов с подтверждениями в ответ на пакеты с данными. При этом
необходимо нумеровать отправленные пакеты, а в квитанциях указывать номер пакета, который
подтверждает данная квитанция. В случае же если отправитель в течение некоторого времени не
получает квитанции на пакет с данными или получает отрицательную квитанцию, он должен
повторить отправку пакета с данным номером. Задачи нумерации пакетов, генерации квитанций,
учета принятых и отправленных пакетов, повторной отправки данных может реализовать САМО
приложение. Однако это означает, что каждое сетевое приложение, нуждающееся в
гарантированной передаче данных, должно содержать в себе реализацию достаточно сложных
механизмов, что, безусловно, усложнит приложения и замедлит время разработки приложений.
Естественно было бы реализовать данный набор функций ОДИН раз в рамках данной реализации
стека протоколов и предложить пользовательским приложениям интерфейс, с помощью которого
приложения бы передавали данные НЕ непосредственно протоколу IP (или другому
дейтаграммному протоколу сетевого уровня), а некоторому посреднику, расположенному между
приложением и сетью. В таком случае приложения бы просто передавали необходимые данные
этому посреднику, не заботясь о гарантиях доставки этих данных, а посредник снабжал бы пакеты
данных порядковыми номерами, генерировал бы квитанции, анализировал бы полученные
квитанции и осуществлял бы повторную передачу данных при необходимости. Как Вам уже
известно, функции такого посредника описываются в рамках транспортного уровня модели OSI.
Так же вспомним, что если два приложения собираются передавать нумерованные и
подтверждаемые данные в рамках сетевого взаимодействия, то обычно удобно (хотя и
необязательно) перед тем как начать передавать данные с гарантией доставки, сначала оговорить
некоторые вопросы между взаимодействующими сторонами. Такими параметрами могут быть
номера, используемые сторонами при нумерации пакетов с данными, некоторые другие параметры,
которые будут детально рассмотрены в дальнейшем. Такие функции в терминологии модели OSI
выполняет сеансовый уровень. Рассмотрим теперь модель TCP/IP – отмечаем, что в модели TCP/IP
вместо транспортного и сеансового уровня используется одни уровень – Host-to-host, который
можно спроецировать на оба этих уровня модели OSI. Объяснение этому можно привести вполне
очевидное – модель OSI – формальная модель, которая выделяет основные аспекты сетевого
взаимодействия и отделяет функции установки соединения от функций гарантирования доставки
данных в рамках этого соединения, стек TCP/IP же создавался как функциональный продукт, а не
как абстрактная модель, и вполне логично, что две сильно связанные функции, установка
соединений и гарантирование доставки в рамках соединений реализованы в одном уровне и как
следствие в одном протоколе, т.е. в стеке TCP/IP нет в чистом виде транспортного и сеансового
протоколов – есть протокол, выполняющий ОБЕ функции, мы будем его детально изучать. Так же
отметим, что в модели TCP/IP, в отличие от модели OSI, нет отдельно представительского и
прикладного уровней, вместо этого есть один, прикладной уровень, функции которого в модели
TCP/IP сопоставимы с функциями представительского и прикладного уровней модели OSI.
Темой данного курса будет изучение прикладных протоколов стека TCP/IP, однако, перед
тем как изучать сами прикладные протоколы необходимо изучить средства host-to-host уровня
модели TCP/IP в рамках нашей стратегии изучения «снизу-вверх по стеку протоколов».
Итак, начинаем первую тему данного курса – средства host-to-host уровня модели TCP/IP.
Еще раз подчеркнем ключевые задачи, решаемые данным уровнем – установка соединений между
приложениями и гарантирование доставки при обмене данными между приложениями.
Для начала обсудим, все ли приложения НУЖДАЮТСЯ в том, чтобы стек гарантировал для
них доставку данных. Предположим, что приложение работает следующим образом: некий сервер
хранит некоторую информацию в простом формате (например, сведения о текущем времени), а
клиентское приложение передает серверу по сети запрос (одним пакетом), суть этого запроса
проста – клиент спрашивает текущее время. Сервер, получив пакет с запросом, генерирует пакет с
ответом, сообщая клиенту текущее время, очевидно, что и этот ответ без труда уместится в один
пакет. Спрашивается: необходимо ли в данном случае устанавливать соединение между клиентом и
сервером и гарантировать доставку этих двух пакетов силами специального протокола-посредника?
Очевидно, НЕТ! Действительно, клиент, отправив пакет-запрос, ожидает пакет с ответом,