Home

Page 30
Page 30
background image

o  Первый подход проще (используется в LLC2, HDLC, LAP-B), но менее гибок, второй 

подход сложнее, но более функционален, именно его использует TCP.  

o  В  случае  если  используется  нумерация  байтов  (а  не  пакетов)  при  необходимости 

повторной  передачи  данных  НЕ  обязательно  передавать  ТЕ  ЖЕ  САМЫЕ  пакеты, 
можно  провести  так  называемую  репакетизацию,  т.е.  передать  необходимые  байты, 
по другому сформировав из них пакеты (если, конечно, это выгодно в данном случае). 
Однако  в  этом  случае  необходимо,  чтобы  отправитель  снабжал  порцию  данных  не 
только  номером  первого  байта  пакета,  но  и  сведениями  о  длине  пакета,  для  того, 
чтобы  приемная  сторона  могла  правильно  понимать,  байт  с  каким  номером  следует 
ожидать.  Ясно,  что  одной  только  нумераций  передаваемых  данных  поставленной 
задачи не решить – это помогло бы в том случае, если бы сеть НЕ теряла пакетов, а 
лишь могла их дублировать или переносить с нарушением порядка следования.  

•  Так  как  пакеты  в  сети  могут  еще  и  теряться,  необходимо  снабжать  отправителя  пакетов 

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

•  Нумерации данных и квитирования так же недостаточно для решения поставленной задачи – 

от того, что и приемник и передатчик знают, что какие то данные потеряны эти данные не 
восстановятся. Поэтому применяется еще один метод – повторные передачи. В том случае, 
если  отправитель  данных  в  течение  некоторого  времени  не  получает  положительную 
квитанцию  на  отправленные  данные  или  в  случае  получения  отрицательной  квитанции,  он 
повторно посылает ранее отправленные данные и делает так до тех пор, пока эти данные не 
будут квитированы либор пока отправитель не решит, что получатель не функционирует и 
логическое соединение разорвано.  
 
Три  перечисленных  выше  метода:  нумерация  передаваемых  данных,  квитирование 

полученных  данных  и  повторные  передачи  и  есть  основной  фундамент,  на  котором  базируется 
любой протокол транспортного уровня. Теперь, когда все необходимые вступления сделаны, можно 
непосредственно  переходить  к  знакомству  с  протоколом TCP. Как  уже  говорилось,  мы  будем 
делать  это  методом  «последовательного  приближения  к  истине»,  поэтому  для  начала 
рассматриваем общие идеи решения поставленных задач, а затем начинаем усложнять. 

 
TCP – есть  протокол  для  передачи  байтовых  потоков  между  приложениями.  Это  означает, 

что данные, передаваемые одним приложением другому приложению, для TCP представляют собой 
неструктурированный  поток  байт  без  разделителей,  меток,  границ  и  т.д.  Задача TCP – передать 
ПОТОК байт, записываемый приложением отправителем в специальную область памяти на станции 
отправителе  (буфер  передачи)  в  соответствующую  область  памяти  (буфер  приема)  на  узле 
получателе с тем, чтобы приложение получатель могло получить доступ к этим данным в том виде, 
в котором их сгенерировало приложение отправитель. Приложение отправитель может записывать 
в  буфер  передачи  данные  произвольными  порциями,  например,  сначала 100 байт,  затем  еще 150 
байт, затем еще 200 байт, а может записать сразу 450 байт – в любом случае все эти 450 байт для 
TCP  являются  неструктурированным  потоком,  лишенным  разделителей,  который  должен  быть 
передан TCP получателя,  для  чего  разбивается  на  подходящие  с  точки  зрения TCP блоки  (т.е. 
сегментируется, поэтому блоки данных протокола TCP принято называть сегментами) и передается 
при помощи инкапсуляции TCP сегментов в IP пакеты.  

При этом приложение получатель так же может получать данные из буфера произвольными 

порциями (продолжая пример: приложение может сразу считать из приемного буфера все 450 байт, 
или  выполнить  две  операции  чтения 200 байт,  затем 250 байт  или  прочитать  данные  другим 
образом). Не имеет никакого значения, какими порциями данные записываются в буфер передачи 
или  изымаются  из  буфера  приема,  важно  понимать  одно:  тот  поток  байт,  который  отдает TCP 
приложение  отправитель,  должен  в  неизменном  виде  поступить  к  приложению  получателю,  то, 
какими порциями части этого потока кладутся в буфер/извлекаются из буфера, транспортируются в 
отдельных сегментах не играет никакой роли. 


Copyright © 2021 Файлообменник files.d-lan.dp.ua

Использование любых материалов сайта возможно только с разрешения автора.