Говорят, что протокол TCP осуществляет передачу с установлением логического соединения, поскольку перед началом обмена данными два процесса осуществляют «рукопожатие» - процедуру, заключающуюся в передаче друг другу специальных сегментов, предназначенных для определения параметров обмена данными. Частью процедуры установления TCP-соединения является инициализация переменных состояния (многие из которых будут рассмотрены в этом разделе и разделе «Контроль перегрузок в ТСР»), связанных с ТСР-соединением.

TCP-соединение не является «соединением» в том смысле, в каком этот термин употребляется в коммутируемых сетях. Оно также не является виртуальным каналом (см. главу 1), поскольку наблюдение за его состоянием ведется обеими сторонами. Поскольку протокол TCP выполняется на оконечных системах и не выполняется на промежуточных сетевых устройствах (маршрутизаторах и мостах), последние не отслеживают состояния TCP-соединения. Более того, маршрутизаторы не «знают» о существовании TCP-соединения: их работа выполняется на уровне дейтаграмм.

TCP-соединение обеспечивает дуплексную передачу данных. Если на двух хостах выполняются соответственно процессы А и В, то данные могут одновременно передаваться как от процесса А к процессу В, так и от процесса В к процессу А. ТСР-соединение также называют соединением точка-точка, то есть соединением между единственным приемником и единственным передатчиком. Групповая рассылка, описанная в главе 4, позволяет передавать данные сразу множеству адресатов с помощью одной операции, однако такая рассылка не поддерживается протоколом TCP.

Теперь давайте подробнее рассмотрим процесс установления ТСР-соединения. Предположим, что процесс, выполняющийся на одном хосте, желает установить соединение с процессом, выполняющимся на другом хосте. Вспомним о том, что процесс, инициирующий соединение, мы договорились называть клиентским, а процесс, с которым устанавливается соединение, - серверным. Сначала клиентский процесс сообщает транспортному уровню своего хоста о том, что необходимо установить соединение с серверным процессом. Обратившись к разделу «Программирование ТСР-сокетов» в главе 2, можно увидеть, что программа-клиент на языке Java делает это при помощи следующей команды:

Socket clientSocket = new Socket(«hostname», portNumber);

Здесь hostname - имя сервера, a portNumber - номер порта, идентифицирующий процесс внутри сервера. Затем транспортный уровень клиента начинает установление TCP-соединения с транспортным уровнем сервера. Эту процедуру мы детально рассмотрим в конце этого раздела, а пока нам достаточно знать, что клиент сначала посылает серверу специальный TCP-сегмент, сервер отвечает клиенту другим специальным сегментом, и, наконец, клиент посылает серверу третий специальный сегмент. Первые два сегмента не содержат данных прикладного уровня; третий сегмент может содержать их. Поскольку обмен сегментами входит в процедуру установления соединения, последнюю часто называют тройным рукопожатием.

После того как TCP-соединение установлено, прикладные процессы могут начинать обмен данными. Передача данных от клиента к серверу происходит следующим образом: клиент направляет поток своих данных в сокет («дверь» процесса), как описано в разделе «Программирование ТСР-сокетов» главы 2. Через сокет данные попадают в протокол TCP, выполняющийся на стороне клиента. Как показано на рис. 3.25, TCP направляет эти данные в буфер передачи - один из буферов, создаваемых при выполнении тройного рукопожатия. Время от времени TCP извлекает данные из буфера передачи. Интересной особенностью спецификации TCP (RFC 793) является свобода в выборе моментов отправки данных, находящихся в буфере. Согласно спецификации, протокол TCP должен «передать эти данные в виде сегментов в любой подходящий для этого момент времени». Максимальный объем данных, который может быть извлечен из буфера и помещен в сегмент, ограничивается максимальным размером сегмента (Maximum Segment Size, MSS). Максимальный размер сегмента зависит от реализации протокола TCP (определяется операционной системой) и может быть сконфигурирован; наиболее часто используются значения 1500,536 и 512 байт (размер сегмента часто устанавливается так, чтобы избежать IP-фрагментации, которая будет рассмотрена позже в этой главе). Обратите внимание на то, что максимальный размер относится к данным приложения, содержащимся в сегменте, а не к сегменту вместе с заголовком (такая терминология является несколько запутанной, однако мы вынуждены придерживаться этой терминологии ввиду ее распространенности).

Протокол TCP добавляет заголовок к каждому фрагменту данных, формируя TCP-сегменты. Сегменты передаются сетевому уровню, где заключаются в IP-дейтаграммы. Дейтаграммы пересылаются по сети и принимаются получателем. Когда сегмент оказывается на транспортном уровне, протокол TCP помещает данные сегмента в приемный буфер, как и показано на рисунке. Затем приложение считывает поток данных из буфера. Приемный и передающий буферы имеются на обеих сторонах соединения (мы рекомендуем читателю обратиться к апплету, который находится на нашем сайте _http://www.awl.com/kurose-ross и позволяет просмотреть анимацию, иллюстрирующую работу приемного и передающего буферов).
Итак, TCP-соединение состоит из буферов и переменных на передающей и принимающей сторонах, а также сокетного соединения между сторонами. При этом для соединения не выделяется никаких буферов или переменных на промежуточных сетевых устройствах (маршрутизаторах, мостах и повторителях).

ИСТОРИЧЕСКАЯ СПРАВКА —
В начале 1970-х годов стали получать распространение сети с коммутацией пакетов. Сеть APRAnet, предок Интернета, была одной из таких сетей. В каждой сети использовался собственный протокол. Двое исследователей, Уинтон Серф и Роберт Канн, понимая важность взаимодействия компьютерных сетей между собой, разработали межсетевой протокол TCP/IP (Transmission Control Protocol/Internet Protocol - протокол управления передачей/Интернет-протокол). Несмотря на то что изначально TCP/IP представлял собой единую сущность, позже он был разделен на две части, TCP и IR каждая из которых функционировала независимо. В мае 1974 года Серфом и Канном были выпущены публикации в IEEE Transaction on Communication Technology.

Протокол TCP/IP, составляющий основу современного Интернета, был разработан до появления персональных компьютеров и рабочих станций, технологий локальных сетей (Ethernet и др.), web, потокового аудио и чатов. Серф и Канн осознали необходимость в создании сетевого протокола, который бы обеспечивал, с одной стороны, мощную поддержку будущих сетевых приложений и, с другой стороны, взаимодействие протоколов более низких и более высоких уровней.

Протокол TCP/IP впервые был создан в начале 1970-х годов и использовался для создания сети ARPANET. Технология разрабатывалась в рамках исследовательского проекта, который был нацелен на изучение потенциальной возможности объединения компьютеров в рамках одной локальной или виртуальной сети internetwork.

Установка соединения в TCP осуществляется при помощи специальной программы-клиента, например браузера, почтовой программы или клиента для обмена сообщениями.

Структура TCP

Структура TCP/IP позволяет формировать доступ к удаленным компьютерам, а также объединять отдельные устройства для создания локальных сетей, работающих отдельно от общих. TCP является надежным протоколом передачи данных. Таким образом, вся информация, которая будет отправлена в сети, гарантировано будет получена адресатом, т.е. пользователем, которому данные предоставлялись.

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

Отправка данных по TCP

После установки соединения TCP отправляет данные по созданным маршрутам в соответствии с IP-адресами отправителя и получателя информации. IP-адрес является уникальным идентификатором каждого сетевого устройства в интернете, а потому отправленный по созданному туннелю пакет не может быть потерян или ошибочно послан другому пользователю.

На физическом уровне передачи данных информация имеет вид частот, амплитуд и других форм сигнала, которые уже обрабатываются сетевой картой адресата.

За обработку информации компьютером и ее передачу другим составляющим отвечают канальные протоколы, среди которых можно упомянуть Ethernet, ATM, SLIP, IEEE 802.11. Данные каналы обеспечивают не только передачу данных, но и форму доставки адресату. Так, в сетях IEEE 802.11 передача информации осуществляется при помощи беспроводного радиосигнала. При этом сигнал подается с сетевой карты компьютера, также имеющей собственный код MAC. В случае с Ethernet вся передача данных осуществляется при помощи кабельного соединения.

Видео по теме

В современных условиях деятельность общества и цивилизации невозможна без применения средств быстрого обмена информацией. Данную проблему призваны решать глобальные компьютерные сети.

Глобальная сеть (ГКС) - это сеть, которая состоит из компьютеров, охватывающих огромные территории при неограниченном количестве включенных в данную сеть компьютерных систем. Главным условием функционирования подобных сетей является моментальная передача информации по сети независимо от удаленности передающего и принимающего компьютера.

Глобальная сеть отличается от локальной, во-первых, более низкими скоростями передачи данных. Работают глобальные сети через протоколы TCP/IP, MPLS, ATM и некоторые других. Наиболее известным из указанных является протокол TCP/IP, который включает в себя подпротоколы разных уровней: прикладной, транспортный, сетевой, физический и канальный.

На прикладном уровне работает большинство программ, обладающих собственными протоколами, которые широко известны обычным пользователям ПК (HTTP, WWW, FTP и т.д.). Данные протоколы обеспечивают визуализацию и отображение необходимой пользователю информации.

Транспортный протокол ответственен за доставку данных именно тому приложению, которое способно их обработать. Он носит название TCP.

Сетевой уровень является, фактически, принимающим при передаче информации и отправляющей запросы на более низкие уровни для получения всей информации. Носит название протокола IP.

Физический и канальный уровни ответственны за определение условий и методов передачи информации.

Наиболее известной глобальной сетью является WWW (World Wide Web), которая представляет из себя совокупность серверов, где хранится необходимая для пользователей информация, и компьютеров, которые могут как принимать с серверов информацию, так и загружать ее на них. WWW отличается удобством и простотой использования, а также низкими требованиями к скорости передачи данных. Это позволило развиться данной сети за период чуть больший, чем десятилетие.

Видео по теме

Принято именовать символьное обозначение, заменяющее числовую адресацию, основанную на IP-адресах, в сети интернет. Числовая адресация, применяемая при обработке таблиц маршрутов, идеально подходит для компьютерного использования, но представляет значительные трудности при запоминании пользователем. На помощь приходят мнемонически осмысленные доменные имена.

Установка соединений в сети интернет происходит по числовым группам в 4 значения, разделенных символом «.» и именуемым IP-адресами. Символьные имена комплекса доменных имен представляют собой службу, призванную облегчить нахождение необходимого IP-адреса в сети.Техническим показателем доменного имени выступает символ «.» в электронном адресе пользователя. Так, в адресе google.com доменным именем будет com.Само доменное имя не способно предоставить доступ к требуемому интернет-ресурсу. Процедура использования мнемонического имени состоит из двух этапов:- IP-адреса по имени в файле hosts, содержащем таблицы соответствия IP-адреса и имени компьютера;- установка соединения с удаленным веб-ресурсом по определенному IP-адресу.Главной задачей сервиса DNS является получение IP-адреса для установки соединения, что делает эту службу вспомогательной по отношению к протоколу TCP/IP.Символ "." является разделителем составляющих доменного имени, хотя для практических целей обычно принимается в качестве обозначения корневого домена, не имеющего собственного обозначения. Корень - все множество хостов интернета - подразделяется на:- первого уровня - gov, edu, com,net;- национальные домены - uk, jp, ch и т.д.;- региональные домены - msk;- корпоративные домены - домены организаций.Сохранение привычной древовидной структуры доменных имен обусловило использование устоявшейся терминологии - корень, узлы дерева, лист. Термин «хост» в данной иерархии присвоен листу, не имеющему под собой ни одного узла. Полным именем хоста становится последовательное перечисление всех промежуточных узлов между корнем и листом, разделяемых символом "." слева направо:ivan.net.abcd.ru, где ru - корень дерева, abcd - название организации, ivan - лист дерева (хост).

Видео по теме

Источники:

• Система доменных имен Internet в 2018

Стёком протоколов, или в просторечье TCP/IP называют сетевую архитектуру современных устройств, разработаных для пользования сетью. Stack - это стенка, в которой каждый составляющий кирпичик лежит поверх другого, зависит от него. Называть стек протоколов "стёком TCP/IP" начали благодаря двум основным протоколам, которые были реализованы - непосредственно IP, и TCP на его основе. Однако, они лишь основные и наиболее распостраненные. Если не сотни, то десятки других используются по сей день в разных целях.

Привычный нам веб (world wide web) основан на протоколе HTTP (hyper-text transfer protocol), который в своб очередь работает на основе TCP. Это классический пример использования стека протоколов. Есть еще протоколы электронной почты IMAP/POP и SMTP, протоколы удаленной оболочки SSH, удаленного рабочего стола RDP, баз данных MySQL, SSL/TLS, и тысячи других приложений со своими протоколами (..)

Чем же отличаются все эти протоколы? Все довольно просто. Помимо различных задач, поставленных при разработке (например, скорость, безопасность, устойчивость и прочие критерии), протоколы созданы с целью разграничения. Например, существуют протоколы прикладного уровня, разные у разных приложений: IRC, Skype, ICQ, Telegram и Jabber - несовместимы друг с другом. Они разработаны для выполнения конкретной задачи, и в данном случае возможность звонить по WhatsApp в ICQ просто не определена технически, так как приложения используют различный протокол. Но их протоколы основываются на одном и том же протоколе IP.

Протоколом можно называть запланированную, штатную последовательность действий в процессе, в котором существует несколько субъектов, в сети они называются пирами (напарниками), реже - клиент и сервер, подчеркивая особенности конкретного протокола. Простейший пример протокола для непонимающего до сих пор - рукопожатие при встрече. Оба знают как и когда, но вопрос зачем - это уже вопрос разработчиков, а не пользователей протокола. Кстати, рукопожатие (handshake) есть почти по всех протоколах, например, для обеспечения разграничения протоколов и защиты от "полетов не на том самолете".

Вот что такое TCP/IP на примере самых популярных протоколов. Здесь показана иерархия зависимости. Надо сказать что приложения лишь пользуются указанными протоколами, которые могут быть а могут и не быть реализованы внутри ОС.

Если уж совсем-совсем простым языком, это почтовая служба.

У каждого участника IP-совместимой сети есть свой собственный адрес, который выглядит примерно так: 162.123.058.209. Всего таких адресов для протокола IPv4 - 4,22 миллиарда.

Предположим, что один компьютер хочет связаться с другим и отправить ему посылку - "пакет". Он обратится к "почтовой службе" TCP/IP и отдаст ей свою посылку, указав адрес, по которому ее необходимо доставить. В отличие от адресов в реальном мире, одни и те же IP-адреса часто присваиваются разным компьютерам по очереди, а значит, "почтальон" не знает, где физически находится нужный компьютер, поэтому он отправляет посылку в ближайшее "почтовое отделение" - на сетевую плату компьютера. Возможно, там есть информация о том, где находится нужный компьютер, а возможно, такой информации там нет. Если ее нет, на все ближайшие "почтовые отделения" (коммутаторы) расылается запрос адреса. Этот шаг повторяется всеми "почтовыми отделениями", пока они не обнаружат нужный адрес, при этом они запоминают, сколько "почтовых отделений" до них прошел этот запрос и если он пройдет определенное (достаточно болшое) их количество, то его вернут назад с пометкой "адрес не найден". Первое "почтовое отделение" вскоре получит кучу ответов от других "отделений" с вариантами путей до адресата. Если ни одного достаточно короткого пути не найдется (обычно 64 пересылки, но не более 255), посылка вернется отправителю. Если найдется один или несколько путей, посылка будет передана по самому короткому из них, при этом "почтовые отделения" на некоторое время запомнят этот путь, позволяя быстро передавать последующие посылки, не спрашивая ни у кого адрес. После доставки, "почтальон" в обязательном порядке заставит получателя подписать "квитанцию" о том, что он получил посылку и отдаст эту "квитанцию" отправителю, как свидетельство о том, что посылка доставлена в целости - проверка доставки в TCP обязательна. Если отправитель не получит такую квитанцию через определенный промежуток времени или в квитанции будет написано, что посылка повредилась или потерялась при отправке, тогда он попытается снова отправить посылку.

TCP/IP - это набор протоколов.

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

Что за TCP/IP (сейчас будет совсем просто, пусть коллег не бомбит):

Информация до вашего компа идет по проводам (радио или что еще - не суть важно). Если по проводам пустили ток - значит 1. Выключили - значит 0. Получается 10101010110000 и так далее. 8 ноликов и единиц (битов) это байт. Например 00001111. Это можно представить как число в двоичном виде. В десятичном виде байт - это число от 0 до 255. Эти числа сопоставляет с буквами. Например 0 это А, 1 это Б. (Это называется кодировка).

Ну так вот. Чтобы два компьютера могли эффективно передавать информацию по проводам - они должны подавать ток по каким то правилам - протоколам. Например, они должны условиться как часто можно менять ток, чтобы можно было отличить 0 от второго 0.

Это первый протокол.

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

Вот у нас еще один протокол, с его помощью можно передавать сообщения (компьютерные).

Компьютеров много, чтобы они могли понять кому надо отправить сообщение используют уникальные адреса компьютеров и протокол, позволяющий понять кому это сообщение адресовано. Например первые 8 бит будут означать адрес получателя, следующие 8 - длину сообщения. И потом сообщение. Мы только что засунули один протокол в другой. IP протокол отвечает за адресацию.

Связь не всегда надежная. Для надежной доставки сообщений (компьютерных) используют TCP. При выполнении протокола TCP компьютеры будут переспрашивает друг друга - правильное ли они сообщение получили. Есть еще UDP - это когда компы не переспрашивают то ли они получили. Зачем надо? Вот вы слушаете интернет радио. Если пару байт придет с ошибками - вы услышите например "пш" и дальше снова музыку. Не смертельно, да и не особо важно - для этого используют UDP. А вот если пару байт испортятся при загрузку сайта - вы получите хрень на мониторе и ничего не поймёте. Для сайтом используют TCP.

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

Еще есть http протокол. Первая строчка - адрес сайта, последующие строчки - текст который вы шлете на сайт. Все строчки http - это текст. Который засовывают в TCP сообщение, которое адресуют с помощью IP и так далее.

Взаимодействие между компьютерами в интернете осуществляется посредством сетевых протоколов, представляющих собой согласованный набор определенных правил, в соответствии с которыми разные устройства передачи данных обмениваются информацией. Существуют протоколы для форматов для контроля ошибок и другие виды протоколов. В глобальном межсетевом взаимодействии чаще всего используется протокол TCP-IP.

Что же это за технология? Название TCP-IP произошло от двух сетевых протоколов: TCP и IP. Конечно, этими двумя протоколами построение сетей не ограничивается, но они являются базовыми в том, что касается именно организации передачи данных. Фактически, TCP-IP есть набор протоколов, позволяющих индивидуальным сетям объединяться для образования

Протокол TCP-IP, описание которого невозможно обозначить только определениями IP и TCP, включает в себя также протоколы UDP, SMTP, ICMP, FTP, telnet, и не только. Эти и другие протоколы TCP-IP обеспечивают наиболее полноценную работу сети Интернет.

Ниже приведем развернутую характеристику каждому протоколу, входящему в общее понятие TCP-IP.

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

Однако использования одного лишь IP-протокола может быть недостаточно для корректной передачи данных, так как объем большей части пересылаемой информации более 1500 символов, что уже не вписывается в один пакет, а некоторые пакеты могут быть потеряны в процессе передачи или присланы не в том порядке, что требуется.

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

Управление организацией передачи данных в больших объемах может осуществляться с помощью ряда протоколов, имеющих специальное функциональное назначение. В частности, существуют следующие виды TCP-протоколов.

1. FTP (File Transfer Protocol) организует перенос файлов и используется для передачи информации между двумя узлами Internet с использованием TCP-соединений в виде бинарного или же простого текстового файла, как поименованной области в памяти компьютера. При этом не имеет никакого значения, где данные узлы расположены и как соединяются между собой.

2. Протокол пользовательских дейтаграмм , или User Datagram Protocol, не зависит от подключений, он передает данные пакетами, которые называют UDP-дейтаграммами. Однако этот протокол не так надежен, как TCP, потому что отравитель не получает данных о том, был ли принят пакет в действительности.

3. ICMP (Internet Control Message Protocol) существует для того, чтобы передавать сообщения об ошибках, возникающих в процессе обмена данными в сети Internet. Однако при этом ICMP-протокол только лишь сообщает об ошибках, но не устраняет причины, которые привели к возникновению этих ошибок.

4. Telnet - который используется для реализации текстового интерфейса в сети с помощью транспорта TCP.

5. SMTP (Simple Mail Transfer Protocol) - это специальный электронными сообщениями, определяющий формат сообщений, которые пересылаются с одного компьютера, называемого SMTP-клиентом, на другой компьютер, на котором запущен SMTP-сервер. При этом данная пересылка может быть отложена на некоторое время до тех пор, пока не активируется работа как клиента, так и сервера.

Схема передачи данных по протоколу TCP-IP

1. Протокол TCP разбивает весь объем данных на пакеты и нумерует их, упаковывая в TCP-конверты, что позволяет восстановить порядок получения частей информации. При помещении данных в такой конверт происходит вычисление контрольной суммы, которая записывается потом в TCP-заголовок.

3. Затем с помощью протокола TCP происходит проверка того, все ли пакеты получены. Если во время приема вычисленная заново не совпадает с указанной на конверте, это свидетельствует о том, что часть информации была утеряна или искажена при передаче, протокол TCP-IP заново запрашивает пересылку этого пакета. Также требуется подтверждение прихода данных от получателя.

4. После подтверждения получения всех пакетов протокол TCP упорядочивает их соответствующим образом и собирает заново в единое целое.

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

Тем самым протокол TCP-IP снимает необходимость использования повторных передач и ожиданий для прикладных процессов (таких, как Telnet и FTP).

Установка TCP-соединения

В протоколе TCP-соединения устанавливаются с помощью «тройного рукопожатия», описанного в разделе «Установка соединения». Чтобы установить соединение, одна сторона (например, сервер) пассивно ожидает входящего соединения, выполняя примитивы LISTEN и ACCEPT, либо указывая конкретный источник, либо не указывая его.

Другая сторона (например, клиент) выполняет примитив CONNECT, указывая IP-адрес и порт, с которым он хочет установить соединение, максимальный размер TCP-сегмента и, по желанию, некоторые данные пользователя (например, пароль). Примитив CONNECT посылает TCP-сегмент с установленным битом SYN и сброшенным битом АСК и ждет ответа.

Когда этот сегмент прибывает в пункт назначения, TCP-сущность проверяет, выполнил ли какой-нибудь процесс примитив LISTEN, указав в качестве параметра тот же порт, который содержится в поле Порт получателя. Если такого процесса нет, она отвечает отправкой сегмента с установленным битом RST для отказа от соединения.

Если какой-либо процесс прослушивает какой-либо порт, то входящий ТСР-сегмент передается этому процессу. Последний может принять соединение или отказаться от него. Если процесс принимает соединение, он отсылает в ответ подтверждение. Последовательность TCP-сегментов, посылаемых в нормальном случае, (рис. а) Обратите внимание на то, что сегмент с установленным битом SYN занимает 1 байт пространства порядковых номеров, что позволяет избежать неоднозначности в их подтверждениях.

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

Начальное значение порядкового номера соединения не равно нулю по обсуждавшимся выше причинам. Используется схема, основанная на таймере, изменяющем свое состояние каждые 4 мкс. Для большей надежности хосту после сбоя запрещается перезагружаться ранее чем по прошествии максимального времени жизни пакета. Это позволяет гарантировать, что ни один пакет от прежних соединений не бродит где-нибудь в Интернете.

Разрыв соединения TCP

Хотя TCP-соединения являются полнодуплексными, чтобы понять, как происходит их разъединение, лучше считать их парами симплексных соединений. Каждое симплексное соединение разрывается независимо от своего напарника. Чтобы разорвать соединение, любая из сторон может послать TCP-сегмент с установленным в единицу битом FIN, что означает, что у него больше нет данных для передачи. Когда этот TCP-сегмент получает подтверждение, это направление передачи закрывается. Тем не менее, данные могут продолжать передаваться неопределенно долго в противоположном направлении. Соединение разрывается, когда оба направления закрываются. Обычно для разрыва соединения требуются четыре TCP-сегмента: по одному с битом FIN и по одному с битом АСК в каждом направлении. Первый бит АСК и второй бит FIN могут также содержаться в одном ТСР-сегменте, что уменьшит количество сегментов до трех.

Как при телефонном разговоре, когда оба участника могут одновременно попрощаться и повесить трубки, оба конца TCP-соединения могут послать FIN-cerменты в одно и то же время. Они оба получают обычные подтверждения, и соединение закрывается. По сути, между одновременным и последовательным разъединениями нет никакой разницы.

Чтобы избежать проблемы двух армий, используются таймеры. Если ответ на посланный FIN-сегмент не приходит в течение двух максимальных интервалов времени жизни пакета, отправитель разрывает соединение. Другая сторона в конце концов заметит, что ей никто не отвечает, и также разорвет соединение. Хотя такое решение и не идеально, но, учитывая недостижимость идеала, приходится пользоваться тем, что есть. На практике проблемы возникают довольно редко.

Управление передачей в TCP

Как уже было сказано ранее, управление окном в TCP не привязано напрямую к подтверждениям, как это сделано в большинстве протоколов передачи данных. Например, предположим, что у получателя есть 4096-байтовый буфер. Если отправитель передает 2048-байтовый сегмент, который успешно принимается получателем, то получатель подтверждает его получение. Однако при этом у получателя остается всего лишь 2048 байт свободного буферного пространства (пока приложение не заберет сколько-нибудь данных из буфера), о чем он и сообщает отправителю, указывая соответствующий размер окна (2048) и номер следующего ожидаемого байта.

После этого отправитель посылает еще 2048 байт, получение которых подтверждается, но размер окна объявляется равным 0. Отправитель должен прекратить передачу до тех пор, пока получающий хост не освободит место в буфере и не увеличит размер окна.

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

Отправители не обязаны передавать данные сразу, как только они приходят от приложения. Также никто не требует от получателей посылать подтвержде­ния как можно скорее. Например TCP-сущность, получив от прило­жения первые 2 Кбайт данных и зная, что доступный размер окна равен 4 Кбайт, была бы совершенно права, если бы просто сохранила полученные данные в буфере до тех пор, пока не прибудут еще 2 Кбайт данных, чтобы передать сразу сегмент с 4 Кбайт полезной нагрузки. Эта свобода действий может использоваться для улучшения производительности.

Рассмотрим TELNET-соединение с интерактивным редактором, реагирующим на каждое нажатие клавиши. В худшем случае, когда символ прибывает к передающей TCP-сущности, она создает 21-байтовый TCP-сегмент и передает его IP-уровню, который, в свою очередь, посылает 41-байтовую IP-дейтаграмму.

На принимающей стороне TCP-сущность немедленно отвечает 40-байтовым подтверждением (20 байт TCP-заголовка и 20 байт IP-заголовка). Затем, когда редактор прочитает этот байт из буфера, TCP-сущность пошлет обновленную информацию о размере буфера, передвинув окно на 1 байт вправо. Размер этого пакета также составляет 40 байт. Наконец, когда редактор обработает этот символ, он отправляет обратно эхо, передаваемое 41-байтовым пакетом. Итого для каждого введенного с клавиатуры символа пересылается четыре пакета общим размером 162 байта. В условиях дефицита пропускной способности линий этот метод работы нежелателен.

Для улучшения ситуации многие реализации TCP используют задержку подтверждений и обновлений размера окна на 500 мс в надежде получить дополни­тельные данные, вместе с которыми можно будет отправить подтверждение од­ним пакетом. Если редактор успеет выдать эхо в течение 500 мс, удаленному пользователю нужно будет выслать только один 41-байтовый пакет, таким образом, нагрузка на сеть снизится вдвое.

Хотя такой метод задержки и снижает нагрузку на сеть, тем не менее, эффективность использования сети отправителем продолжает оставаться невысокой, так как каждый байт пересылается в отдельном 41-байтовом пакете. Метод, позволяющий повысить эффективность, известен как алгоритм Нагля (Nagle, 1984). Предложение Нагля звучит довольно просто: если данные поступают отправителю по одному байту, отправитель просто передает первый байт, а остальные помещает в буфер, пока не будет получено подтверждение приема первого байта. После этого можно переслать все накопленные в буфере символы в виде одного TCP-сегмента и снова начать буферизацию до получения подтверждения отосланных символов. Если пользователь вводит символы быстро, а сеть медленная, то в каждом сегменте будет передаваться значительное количество символов, таким образом, нагрузка на сеть будет существенно снижена. Кроме того, этот алгоритм позволяет посылать новый пакет, даже если число символов в буфере превышает половину размера окна или максимальный размер сегмента.

Алгоритм Нагля широко применяется различными реализациями протокола TCP, однако иногда бывают ситуации, в которых его лучше отключить. В частности, при работе приложения X-Windows в Интернете информация о перемещениях мыши пересылается на удаленный компьютер. (X-Window - это система управления окнами в большинстве ОС типа UNIX). Если буферизировать эти данные для пакетной пересылки, курсор будет перемещаться рывками с большими паузами, в результате чего пользоваться программой будет очень сложно, почти невозможно.

Еще одна проблема, способная значительно снизить производительность протокола TCP, известна под именем синдрома глупого окна (Clark, 1982). Суть проблемы состоит в том, что данные пересылаются TCP-сущностью крупными блоками, но принимающая сторона интерактивного приложения считывает их посимвольно.

Рассмотрим на примере - начальное состояние таково: TCP-буфер приемной стороны полон, и отправителю это известно (то есть размер его окна равен 0). Затем интерактивное приложение читает один символ из TCP-потока. Принимающая TCP-сущность радостно сообщает отправителю, что размер окна увеличился, и что он теперь может послать 1 байт. Отправитель повинуется и посылает 1 байт. Буфер снова оказывается полон, о чем получатель и извещает, посылая подтверждение для 1-байтового сегмента с нулевым размером окна. И так может продолжаться вечно.

Дэвид Кларк (David Clark) предложил запретить принимающей стороне отправлять информацию об однобайтовом размере окна. Вместо этого получатель должен подождать, пока в буфере не накопится значительное количество сво­бодного места. В частности, получатель не должен отправлять сведения о новом размере окна до тех пор, пока он не сможет принять сегмент максимального размера, который он объявлял при установке соединения, или его буфер не освободился хотя бы наполовину.

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

В задаче избавления от синдрома глупого окна алгоритм Нагля и решение Кларка дополняют друг друга. Нагль пытался решить проблему приложения, предоставляющего данные TCP-сущности посимвольно. Кларк старался разрешить проблему приложения, посимвольно получающего данные у TCP. Оба решения хороши и могут работать одновременно. Суть их состоит в том, чтобы не посылать и не просить передавать данные слишком малыми порциями.

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

Еще одна проблема получателя состоит в сегментах, полученных в неправильном порядке. Они могут храниться или отвергаться по усмотрению получателя. Разумеется, подтверждение может быть выслано, только если все данные вплоть до подтверждаемого байта получены. Если до получателя доходят сегменты О, 1, 2, 4, 5, 6 и 7, он может подтвердить получение данных вплоть до последнего байта сегмента 2. Когда у отправителя истечет время ожидания, он передаст сегмент 3 еще раз. Если к моменту прибытия сегмента 3 получатель сохранит в буфере сегменты с 4-го по 7-й, он сможет подтвердить получение всех байтов, вплоть до последнего байта сегмента 7.

- 1