Очевидно, необходимо как-то дополнительно контролировать передачу пакетов по сети, т.е. 

выявлять  все  вышеперечисленные  проблемы  и  устранять  их.  Вам  уже  известны  методы, 
применяемые для этого (рассматривались при изучении модели 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. 

Еще раз подчеркнем ключевые задачи, решаемые данным уровнем – установка соединений между 
приложениями и гарантирование доставки при обмене данными между приложениями.  

Для начала обсудим, все ли приложения НУЖДАЮТСЯ в том, чтобы стек гарантировал для 

них доставку данных. Предположим, что приложение работает следующим образом: некий сервер 
хранит  некоторую  информацию  в  простом  формате  (например,  сведения  о  текущем  времени),  а 
клиентское  приложение  передает  серверу  по  сети  запрос  (одним  пакетом),  суть  этого  запроса 
проста – клиент спрашивает текущее время. Сервер, получив пакет с запросом, генерирует пакет с 
ответом,  сообщая  клиенту  текущее  время,  очевидно,  что  и  этот  ответ  без  труда уместится  в  один 
пакет. Спрашивается: необходимо ли в данном случае устанавливать соединение между клиентом и 
сервером и гарантировать доставку этих двух пакетов силами специального протокола-посредника? 
Очевидно,  НЕТ!  Действительно,  клиент,  отправив  пакет-запрос,  ожидает  пакет  с  ответом,