Передача данных

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

• Номер порта. Клиенту уже известен номер порта сервера, который относится к хорошо известным портам и необходим для инициа­ лизации соединения. В поле Source Port сообщений клиента, ад­ ресованных серверу, передается временный номер порта, который будет подставляться в ответы сервера.

• Номер в последовательности. В поле Acknowledgment Number сво­ их сообщений каждая система подставляет номера в последова­ тельности, предоставленные другой системой.

• MSS. По значению дополнительного параметра MSS системы зна­ ют, насколько большими могут быть сегменты каждой последова­ тельности.

Очередность передачи данных зависит от типа приложения. Тран­закция между браузером и Web-сервером обычно начинается с того,что клиент отправляет серверу URL запрашиваемой Web-страницы. В других случаях начинать транзакцию может и сервер.

Подтверждение доставки

Поля Sequence Number и Acknowledgment Number играют ключевую роль в механизмах TCP подтверждения приема и коррекции ошибок. Во время рукопожатия сервер отвечает на сообщение SYN клиента соб­ственным сообщением SYN/ACK, в поле Sequence Number которого содержится ISN сервера, а в поле Acknowledgment Number — значение ISN клиента, увеличенное на 1. С помощью поля Acknowledgment Number сервер информирует клиента, какое значение Sequence Number он ожидает увидеть в следующем клиентском сообщении. Например, если ISN клиента равен 1000000, в поле Acknowledgment Number сооб­щения SYN/ACK сервера содержится значение 1000001. Именно оно должно содержаться в поле Sequence Number первого клиентского со­общения с данными.

Примечание Заметьте: номер 1000001 присваивается именно перво­му сообщению клиента с данными, а не подтверждению приема, кото­рое он посылает в ответ на сообщение сервера ACK/SYN. Дело в том, что сообщения АСК, единственная функция которых — подтвержде­ние приема, на значение счетчика номеров в последовательности не влияют. А вот сообщение SYN/ACK сервера увеличивает счетчик на 1, так как в нем установлен не только флаг АСК, но и флаг SYN.

Во время обмена данными значение счетчика Sequence Number уве­личивается на 1 с каждым переданным байтом. Когда браузер посыла­ет Web-серверу запрос с URL, значение в поле Sequence Number этого сообщения равно значению ISN клиента, увеличенному на 1 (1000001). Допустим, что размер передаваемого клиентом URL равен 50 байтам (без учета заголовков IP или TCP). Сервер отвечает на запрос сообще­нием АСК, в поле Acknowledgment Number которого содержится зна­чение 1000051. Оно означает, что сервер успешно принял 50 байтов и ожидает, что номер Sequence Number следующего пакета с данными клиента будет равен 1000051. Поскольку клиент передал серверу 50 байтов, он увеличивает свое значение Sequence Number на 50 и номер следующего сообщения в последовательности действительно будет ра­вен 1000051 (при условии, что передача прошла без ошибок).

Такая же нумерация сообщений происходит и в другом направле­нии. После передачи сервером сообщения SYN/ACK его номер Sequence Number увеличивается на 1 по сравнению с ISN. Именно это увеличен­ное значение стоит в поле Sequence Number сообщения АСК, кото­рое генерируется клиентом в ходе рукопожатия. На запрос клиента с URL сервер отвечает сообщением АСК, которое не содержит данных и потому не приводит к увеличению номера в последовательности. Наконец, когда сервер начинает передавать запрошенную Web-стра­ницу, увеличенное на 1 значение ISN будет подставлено в поле Se­quence Number первого сообщения с данными (рис. 7.3).

Рис. 7.3. Браузер передает серверу сообщение с URL; сервер

посылает в ответ сообщение АСК, подтверждающее прием, а затем начинает передачу запрашиваемой Web-страницы

В описанном здесь случае клиент передает серверу адрес URL, который, вероятно, невелик по объему и потому уместится в одном сообщении TCP. А вот запрашиваемую Web-страницу (т. е. передава­емую последовательность) серверу, скорее всего, придется разбивать на несколько сегментов, размер которых определяется величиной MSS клиента. Передавая сегменты, сервер увеличивает значение Se­quence Number в соответствии с объемом данных в каждом сообще­нии. Если начальный номер в последовательности сервера равен 20000, то поле Sequence Number первого сообщения с данными будет содержать число 20001. Допустим, что максимальный размер сегмента для клиента равен 1000 байтов. Тогда у второго сообщения с данными номер Sequence Number будет равен 21001, у третьего — 22001 и т. д.

Клиент должен подтверждать получение переданных сервером данных. В TCP для этого используется механизм отложенного под­тверждения (delayed acknowledgment): система посылает подтвержде­ние приема не после каждого полученного сообщения с данными, а через некоторые интервалы, определенные в конкретной реализации TCP. В каждом сообщении с подтверждением приема, конечно, уста­новлен флаг АСК, а значение поля Acknowledgment Number отражает число байтов в последовательности, которое клиент успешно принял.

Если полученное клиентом сообщение не проходит проверки кода CRC или в последовательности оказались пропуски, клиент инфор­мирует об этом сервер, используя поле Acknowledgment Number со­общений АСК. Как уже говорилось, величина Acknowledgment Num­ber отражает количество байтов от начала последовательности, кото­рые система назначения приняла корректно. Если последователь­ность, например, содержит десять сегментов, и все они, за исключением седьмого, приняты правильно, величина Acknowledgment Num­ber в сообщении с подтверждением приема будет содержать число байтов только в первых шести сегментах. Хотя сегменты с восьмого по десятый и были приняты правильно, они будут проигнорированы, и следом за седьмым сегментом их нужно будет передать снова. Такая система называется положительным подтверждением с повторной пе­редачей (positive acknowledgment with retransmission): целевая система подтверждает получение только тех сообщений, которые были при­няты правильно. Возможно и отрицательное подтверждение, когда система-получатель извещает отправителя только о тех сообщениях, при передаче которых произошли ошибки.

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

Когда сервер передал все сегменты Web-страницы, а клиент под­твердил их успешное получение, система разрывает соединение (про­цедура разрыва подробно описана ниже). Если сегменты поступили в целевую систему в неправильном порядке, она переставляет их, ру­ководствуясь значениями Sequence Number. Затем клиентская систе­ма обрабатывает принятые данные и отображает Web-страницу. Ско­рее всего, страница будет содержать ссылки на изображения или дру­гие элементы. Для их получения клиенту придется инициировать до­полнительные соединения с сервером. Так производится обмен дан­ными в Web. Приложения других типов могут создавать единствен­ное соединение TCP и поддерживать его в течение длительного пери­ода времени, неоднократно выполняя передачу данных и служебных сообщений в обоих направлениях.

Обнаружение ошибок

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

Когда сообщение прибывает по месту назначения, принимающая система проверяет его целостность, вычисляя контрольную сумму и сравнивая результат со значением в поле Checksum, которое было рассчитано и подставлено туда отправителем. Если два значения не совпадают, сообщение отбрасывается. Это очень важный момент TCP-транзакции: только на этом этапе (и ни на каком другом) срав­ниваются «сквозные» контрольные суммы прикладных данных, вы­численные в начале и в конце передачи пакета. Протоколом IP тоже вычисляются сквозные контрольные суммы, но только для заголовка IP. Протоколы канального уровня, подобные Ethernet и Token Ring, вычисляют контрольные суммы для пакета целиком, но не сквозные, а только для одного перехода. Если пакетам на пути встретился пере­ход без вычисления контрольной суммы, например, канал РРР, есть вероятность появления на нем ошибок, которые ни на канальном, ни на сетевом уровне зарегистрированы не будут.

Контрольная сумма, вычисляемая TCP, не совсем обычна: она охватывает не только весь заголовок TCP и прикладные данные, но также и псевдозаголовок (pseudo-header), состоящий из полей IP-заго­ловка Source IP Address, Destination IP Address, Protocol и Length, a также 1 байта заполнения, чтобы довести полное число байтов до 12 (рис. 7.4). Включение в контрольную сумму псевдозаголовка позво­ляет убедиться, что дейтаграмма доставлена на нужный компьютер и нужному протоколу транспортного уровня.

Управление потоком

Управление потоком (flow control) заключается в том, что целевая си­стема TCP-соединения передает системе-источнику сведения, кото­рые позволяют регулировать скорость передачи данных. В каждой системе предусмотрено некое ограниченное буферное пространство для хранения принимаемой информации. Данные остаются в буфе­ре, пока система не отправит сообщение с подтверждением их при­ема. Если система-источник передает данные слишком быстро, бу­феры приемника переполняются, и информация начинает теряться. Во избежание этого принимающая система с помощью поля Window сообщений АСК информирует отправителя о том, сколько буферно­го пространства доступно в данный момент времени. Передающая система с помощью величин из полей Window и Acknowledgment Number определяет, какие данные последовательности ей можно пе­редавать. Например, если в поле Acknowledgment Number сообщения АСК содержится число 150000, а значение поля Window равно 500, передающая система понимает, что данные последовательности до 150000 байта приняты успешно, и теперь можно передавать байты с 15001 до 150500. Если к моменту окончания передачи этих 500 бай­тов дополнительные подтверждения приема все еще не получены, передачу нужно приостановить до тех пор, пока они не придут.

Такой способ управления потоком называется методом скользяще­го окна (sliding window). Предложенное окно (offered window), показан­ное на рис. 7.7, представляет собой набор байтов, передачу которых разрешила принимающая система. По мере того как принимающая система подтверждает прием байтов, левая граница окна сдвигается вправо. Одновременно байты, прием которых подтвержден, переда­ются принимающей системой тому процессу прикладного уровня, номер порта которого указан в поле Destination Port. При этом пра­вый край окна также сдвигается вправо. Таким образом, окно сколь­зит вдоль потока входящих байтов слева направо.

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

Закончив обмен данными, системы, участвующие в ТСР-соединении, разрывают его с помощью управляющих сообщений, подобных тем, что использовались в трехшаговом рукопожатии. Которая из систем инициирует процесс разрыва, зависит от конкретного приложения. В случае обмена данными между клиентом и Web-сервером, который рассматривался выше, разрыв инициируется сервером, который в последнем сообщении с данными устанавливает флаг FIN в поле Control Bits. В других случаях система, инициирующая разрыв, не может совмещать установленный флаг FIN с отправкой данных и дол­жна посылать для него отдельное сообщение.

Система, принявшая флаг FIN, передает подтверждение его при­ема и генерирует собственное сообщение с установленным флагом FIN, на которое вторая система также откликается сообщением АСК (рис. 7.6). Выше уже говорилось, что соединение работает в обоих направлениях, и потому разорвать соединение должны обе системы. Комбинировать флаги АСК и FIN в одном и том же сообщении нельзя. Иногда соединение разрывается только в одном направлении. Такое соединение называется полузакрытым (half close).

Протокол UDP

Протокол UDP определен в RFC 768. В отличие от TCP, он не ориен­тирован на соединение и не обеспечивает подтверждение приема, управление потоком, сегментацию и гарантированную доставку. В результате UDP намного проще TCP и создает гораздо меньше на­грузки на сеть. Это связано не только с тем, что заголовок UDP коро­че заголовка TCP (8 байтов против не менее 20). В UDP нет специ­альных управляющих сообщений, например, сообщений для установ­ки или разрыва соединения. Транзакция UDP состоит всего из двух сообщений — запроса и ответа, причем последний служит также не­явным подтверждением приема. По этим причинам, приложения, использующие UDP, могут передавать лишь небольшие порции дан­ных, которые могут уместиться в единственное сообщение. В основ­ном сообщения UDP применяются протоколами прикладного уров­ня DNS и DHCP. В определенных ситуациях UDP можно использо­вать и для передачи больших объемов данных, например, в аудио- и видеопотоках. В данном случае использование UDP допустимо, по­скольку периодическая потеря пакетов важной роли не сыграет.

Формат сообщения UDP показан на рис. 7.7.

Функции полей сообщения UDP таковы.

• Source Port (2 байта) — идентификатор процесса в передающей системе, который сгенерировал информацию в поле данных.

• Destination Port (2 байта) — идентификатор процесса в принимаю­ щей системе, которому предназначается информация в поле данных.

• Length (2 байта) — длина заголовка и данных UDP в байтах.

• Checksum (2 байта) — код CRC, вычисленный передающей систе­ мой. Целевая система использует его для обнаружения ошибок в заголовке UDP, данных и частях заголовка IP.

• Data (переменной длины) — данные, сгенерированные процессом прикладного уровня, номер которого указан в поле Source Port.

Поля Source Port и Destination Port в заголовке UDP выполняют те же функции, что и в заголовке TCP. В поле Length указано количе­ство данных, включенных в сообщение UDP. Как и в TCP, конт­рольная сумма вычисляется для заголовка сообщения, данных и псев­дозаголовка IP. В стандарте UDP использование контрольной суммы не является обязательным. Если она не используется, передающая система заполняет поле Checksum нулями. По поводу включения кон­трольной суммы в сообщения UDP было много споров. В документе RFC 768 указано, что во все системы UDP должна включаться воз­можность проверки контрольной суммы, и этот метод обнаружения ошибок действительно используется в большинстве реализаций про­токола U DP.

Краткое содержание занятия

• TCP — протокол, ориентированный на соединение. Он обеспечи­ вает подтверждение приема пакетов, управление потоком, обна­ ружение и исправление ошибок, сегментацию и другие услуги.

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

• Чтобы передать по TCP-соединению большое количество данных, система разбивает поток данных на сегменты, каждый из которых передается в отдельном сообщении.

• Система, принимающая сегменты, время от времени подтвержда­ ет их получение с помощью специальных сообщений. Сообщения, прием которых не подтвержден, передаются повторно.

• Сообщения с подтверждением приема информируют другую сис­ тему, какое количество данных она может передавать далее. В этом состоит управление потоком.

• В сообщении TCP содержится контрольная сумма, по которой принимающая система обнаруживает ошибки передачи.

• При закрытии TCP-соединения системы обмениваются сообще­ ниями о его разрыве (FIN) и подтверждениями приема.

• UDP — протокол, не ориентированный на соединение. Из всех услуг, поддерживаемых в TCP, он обеспечивает только обнаруже­ ние ошибок.

SPX и NCP

Как и TCP/IP, набор протоколов IPX (Internetwork Packet Exchange) фирмы NetWare включает несколько протоколов транспортного уров­ня, предоставляющих различные услуги. Интересно, что протокол транспортного уровня SPX (Sequenced Packet Exchange), чаще всего ассоциируемый с IPX, в действительности используется гораздо реже, чем NCP (NetWare Core Protocol).