СЕТИ ЭВМ И ТЕЛЕКОММУНИКАЦИИ. Министерствообразованияинаукироссийскойфедерации
 Скачать 4.29 Mb.
|
|
4.4.8.2. Транспортный протокол TCP Протокол TCP обеспечивает надежную передачу данных между прикладными процессами за счет установления логических соединений между взаимодействующими процессами. Логическое соединение между двумя прикладными процессами идентифицируется парой сокетов (IP-адрес, номер порта), каждый из которых описывает один из взаимодействующих процессов. Информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байтов и заносится в буфер. Для передачи на сетевой уровень из буфера вырезается сегмент, не превосходящий 64 Кбайт (максимального размера IP-пакета). На практике обычно длина сегмента ограничивается значением 1460 байтами, что позволяет поместить его в кадр Ethernet с заголовками TCP и IP. Соединение TCP ориентировано на полнодуплексную передачу. Управление потоком данных в протоколе ТСР осуществляется с использованием механизма скользящего окна переменного размера. При передаче сегмента узел-отправитель включает таймер и ожидает подтверждения. Отрицательные квитанции не посылаются, а используется механизм тайм-аута. Узел назначения, получивший сегмент формирует и посылает обратно сегмент (с данными, если они есть, или без данных) с номером подтверждения, равным следующему порядковому номеру ожидаемого байта. В отличие от многих других протоколов, протокол TCP подтверждает получение не пакетов, а байтов потока. Если время ожидания подтверждения истекает, отправитель посылает сегмент еще раз. Несмотря на кажущуюся простоту протокола, в нем имеется ряд нюансов, которые могут привести к некоторым проблемам. Во-первых, поскольку сегменты при передаче по сети могут фрагментироваться, возможна ситуация, при которой часть переданного сегмента будет принята, а остальная часть окажется потерянной. Раздел 4. Глобальные сети 321 Во-вторых, сегменты могут прибывать в узел назначения в произвольном порядке, что может привести к ситуации, при которой байты с 2345 по 3456 уже прибыли, но подтверждение для них не может быть выслано, так как байты с 1234 по 2344 еще не получены. В-третьих, сегменты могут задержаться в сети так долго, что у отправителя истечёт интервал ожидания, и он передаст их снова. Переданный повторно сегмент может пройти по другому маршруту и может быть иначе фрагментирован, или же сегмент может по дороге случайно попасть в перегруженную сеть. В результате для восстановления исходного сегмента потребуется достаточно сложная обработка На рис.4.63 представлен формат заголовка TCP-сегмента. Первые 20- байт заголовка имеют строго фиксированный формат, за которым могут находиться дополнительные поля. После дополнительных полей заголовка размещается поле данных, содержащее не более 65 495 байт, которое вместе с TCP- и IP-заголовками размером по 20 байт даст максимально допустимый размер IP-пакета в 65 535 байт. Не вдаваясь в детали, рассмотрим кратко назначение фиксированных полей заголовка ТСР-сегмента. Поля «Порт отправителя» (2 байта) и «Порт получателя» (2 байта) идентифицируют процессы, между которыми установлено логическое соединение. Поле «Порядковый номер» (4 байта) содержит номер первого байта данных в сегменте, который определяет смещение сегмента относительно потока передаваемых данных Поле «Номер подтверждения» (4 байта) содержит номер следующего ожидаемого байта, который используется в качестве квитанции, подтверждающей правильный приёма всех предыдущих байтов. Поле «Длина TCP-заголовка» (4 бита) задаёт длину заголовка ТСР- сегмента, измеренную в 32-битовых словах. Поле «Резерв» длиной 6 бит зарезервировано на будущее. 11 12 13 14 15 16 17 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 10 9 8 7 6 5 4 3 2 1 U R G A C K P S H R S T S Y N F I N Указатель на срочные данные Размер окна Порт получателя Параметры (0 или более 32-разрядных слов) Контрольная сумма Резерв Длина ТСР- загол. Номер подтверждения (следующий ожидаемый байт) Порядковый номер Порт отправителя 4.63 Раздел 4. Глобальные сети 322 Однобитовые флаги несут служебную информацию о типе сегмента и интерпретируются следующим образом: URG=1 указывает на наличие срочных данных, что означает использование поля «Указатель на срочные данные»; ACK=1 означает, что сегмент является квитанцией на принятый сегмент и поле «Номер подтверждения» содержит осмысленные данные. В противном случае данный сегмент не содержит подтверждения и поле «Номер подтверждения» просто игнорируется. PSH=1 (PUSH-флаг) означает запрос на отправку данных без ожидания заполнения буфера; RST=1 используется для сброса состояния соединения при обнаружении проблем, а также для отказа от неверного сегмента или от попытки создать соединение; SYN=1 используется для установки соединения, при этом если АСК=0, то это означает, что поле подтверждения не используется; FIN=1 используется для разрыва соединения. Поле «Размер окна» (2 байта) определяет, сколько байт может быть послано после байта, получившего подтверждение. Поле «Контрольная сумма» (2 байта) содержит контрольную сумму, которая охватывает заголовок, данные и псевдозаголовок. Алгоритм вычисления контрольной суммы выглядит следующим образом. Перед началом вычисления контрольной суммы значение этого поля устанавливается равным нулю. Если поле данных содержит нечётное число байтов, то оно дополняется нулевым байтом, который используется при подсчёте контрольной суммы, но не вставляется в сегмент для передачи в сети. Необходимость такого добавления обусловлена тем, что ТСР-сегмент, включающий заголовок, данные и псевдозаголовок, рассматривается как совокупность 16-разрядных двоичных чисел, которые складываются в дополнительном коде, а затем вычисляется дополнение для полученной суммы, которое заносится в поле «Контрольная сумма». Получатель сегмента аналогичным образом подсчитывает контрольную сумму для всего сегмента, включая поле «Контрольная сумма». Очевидно, что полученный таким образом результат должен быть равен 0. Отметим, что дополнительный нулевой байт Поле «Указатель на срочные данные» (2 байта) содержит смещение в байтах от текущего порядкового номера байта до места расположения срочных данных, которые необходимо срочно принять, несмотря на переполнение буфера. Таким образом, в протоколе TCP реализуются прерывающие сообщения. Содержимым срочных данных занимается прикладной уровень. Протокол TCP лишь обеспечивает их доставку и не интересуется причиной прерывания. Поле «Параметры» имеет переменную длину и может отсутствовать. Примерами приложений, использующих протокол TCP для передачи данных, являются FTP, TFTP, DNS, POP3, IMAP, TELNET. Раздел 4. Глобальные сети 323 4.4.8.3. Псевдозаголовок протоколов UDP и TCP Как сказано выше, при передаче данных от нижележащего межсетевого уровня на транспортный уровень в заголовки UDP- дейтаграмм и TCP-сегментов включается псевдозаголовок, который располагается перед основным заголовком транспортного уровня. Таким образом, блок данных транспортного уровня (UDP-дейтаграмма или TCP- сегмент) будет содержать (рис.4.64,а): • псевдозаголовок длиной 12 байт или 3 32-разрядных слова; • заголовок длиной 8 байт для UDP-дейтаграммы или 20 и более байт для ТСР-сегмента; • данные. Псевдозаголовок, формат которого показан на рис.4.64,б, содержит: • IP-адрес отправителя; • IP-адрес получателя; • нулевое поле, не используемое и заполненное нулями; • поле «Протокол», содержащее номер протокола транспортного уровня: 17 для протокола UDP и 6 для протокола ТСР; • длина UDP-дейтаграммы или ТСР-сегмента. Включение псевдозаголовка в контрольную сумму блока данных транспортного протокола помогает обнаружить неверно доставленные пакеты за счёт двойной проверки, выполняемой протоколом IP и протоколами транспортного уровня. Кроме того, передача IP-адресов транспортному уровню позволяет однозначно разрешить ситуацию, показанную на рис.4.62, когда две копии одного и того же приложения используют одинаковый номер порта. Узел-отправитель при формировании ТСР-сегмента рассчитывает контрольную сумму сегмента с учётом псевдозаголовка. Однако при 1 … 8 9 … 16 17 … 32 Псевдозаголовок (12 байт) Заголовок (8 байт UDP или 20 и более байт ТСР) Данные 1 … 8 9 … 16 17 … 32 IP-адрес получателя IP-адрес отправителя 0 0 0 0 0 0 0 0 Протокол Длина UDP/ТСР-сегмента 4.64 а) б) Раздел 4. Глобальные сети 324 передаче по сети псевдозаголовок не включается в сегмент, что позволяет уменьшить накладные расходы и, соответственно, повысить эффективную скорость передачи пользовательских данных. В узле-получателе протокол IP формирует псевдозаголовок и вставляет его в поступивший сегмент и передаёт транспортному уровню. 4.4.9. Управляющий протокол I СМ P Internet Control Message Protocol (ICMP) – протокол межсетевых управляющих сообщений предназначен для выявления и обработки нештатных событий (например, потеря пакета), заключающейся в определении типа ошибки, формировании сообщения о ней и передаче этого сообщения приложению, сформировавшему пакет. К основным функциям протокола ICMP относятся: • обмен тестовыми сообщениями для выяснения наличия и активности узлов сети; • анализ достижимости узла-получателя и сброс пакетов, направляемых к недостижимым узлам; • изменение маршрутов; • уничтожение пакетов с истекшим временем жизни; • синхронизация времени в узлах сети; • управление потоком путем регулирования частоты посылки пакетов узлами-источниками. Основные типы ICMP-сообщений: • «адресат недоступен» – пакет не может быть доставлен; • «время истекло» – время жизни пакета достигло нуля; • «проблема с параметром» – ошибка в поле заголовка; • «переадресовать» – научить маршрутизатор; • «запрос отклика» – запрос: жив ли компьютер?; • «отклик» – да, жив. Одной из наиболее интересных среди перечисленных функций является изменение маршрутов: если некоторый маршрутизатор определяет, что хост использует неоптимальный путь для доставки пакета, он при помощи протокола ICMP может скорректировать маршрутную таблицу хоста. Это один из механизмов автоматической оптимизации и адаптации сетей TCP/IP к изменениям топологии. ICMP-пакеты инкапсулируются в IP пакеты. ICMP является неотъемлемой частью IP, но при этом не делает протокол IP средством надёжной доставки сообщений. Для этих целей существует протокол TCP. 4.4.10. Протоколы канального уровня для выделенных линий Протоколы канального уровня для выделенных линий (рис.4.65) должны: • обеспечивать надежную передачу; Раздел 4. Глобальные сети 325 • предоставлять возможность управ- ления потоком кадров для предотвращения переполнения соседних узлов. Протоколы канального уровня: • SLIP; • протоколы семейства HDLC; • РРР. 4.4.10.1. Протокол SLIP SLIP (Serial Line IP) – первый стандарт для протоколов TCP/IP, который может использоваться как для коммутируемых, так и для выделенных каналов ввиду простоты. SLIP поддерживается только протоколом сетевого уровня IP. Основная и единственная функция протокола SLIP – распознавание начала и конца IP-пакета в потоке бит. Для этого в качестве границ IP-пакета используется специальный символ END (шестнадцатеричный код – С0 16 ). Если в IP-пакете встречается код С0 16 , то используется процедура байт- стаффинга (рис.4.66), заключающаяся в следующем. Код С0 16 заменяется на коды DB 16 и DC 16 , а код DB 16 заменяется на DB 16 и DD 16 К недостаткам протоколаSLIP относятся: • отсутствие возможности обмениваться адресной информацией; • использование только IP-пакетов в качестве содержимого SLIP- пакета; • отсутствие процедур обнаружения и коррекции ошибок. 4.4.10.2. Протоколы семейства HDLC HDLC (High-level Data Link Control Procedure) – высокоуровневый протокол управления каналом – стандарт ISO для выделенных линий. Представляет собой семейство протоколов LAP (Link Access Protocol), включающее следующие протоколы: • LAP-B – для сетей X.25 (B – Balanced); • LAP-D – для сетей ISDN (D – D-channel); • LAP-M – для модемов (M – Modem); IP-пакет С0 DB DB DC DB DD С0 С0 SLIP-пакет 4.66 У 1 У 2 маршрутизатор, коммутатор Выделенная линия 4.65 Раздел 4. Глобальные сети 326 • LAP-F – для сетей Frame Relay (F – Frame Relay). HDLC относится к бит-ориентированным протоколам и использует кадр, формат которого показан на рис.4.67. В качестве обрамления кадра, служащих границами между передаваемыми кадрами, используется специальная последовательность из 8 бит (байт): 01111110, называемая флагом. Благодаря наличию флагов нет необходимости указывать длину кадра. Для того, чтобы отличать последовательность бит 01111110, находящуюся в поле данных от флага применяется процедура бит-стаффинга. Поле Адрес имеет длину 1 или 2 байта и при наличии нескольких узлов-приёмников используется для идентификации конкретного узла, а в двухточечном соединении – для того, чтобы отличить команды от ответов, а также для указания направления передачи кадра по интерфейсу «пользователь – сеть». Поле Данные может быть любой длины и содержать пакеты протоколов вышележащих уровней. Это поле может отсутствовать в управляющих кадрах и некоторых ненумерованных кадрах. Поле КС (контрольная сумма) содержит остаток избыточной циклической суммы, вычисленной с помощью полиномов типа CRC. Поле У (управление) имеет длину 1 или 2 байта и содержит служебную информацию. Структура и содержимое этого поля зависят от типа передаваемого HDLC-кадра. Существуют 3 типа HDLC-кадров, различающиеся содержимым поля У (управление), показанного на рис.4.68: • информационные кадры длиной 1 или 2 байта (рис.4.68,а), предназначенные для передачи данных пользователя; • управляющие или супервизорные кадры длиной 1 или 2 байта (рис.4.68,б), предназначенные для передачи команд и ответов в процессе установленного логического соединения; • ненумерованные кадры длиной 1 байт (рис.4.68,в), предназначенные для установления и разрыва логического соединения, а также информирования об ошибках. Тип кадра определяется первыми битами поля управления: 0 – информационный кадр; 10 – управляющий кадр; 11 – ненумерованный кадр. Протокол HDLC для обеспечения надёжности передачи данных использует механизм скользящего окна, ширина которого составляет: • 7 кадров при длине поля управления в 1 байт; • 127 кадров при длине поля управления в 2 байта. 8 8/16 8/16 - 16 8 бит 4.67 0111111 0 Адрес У Данные КС 0111111 0 Раздел 4. Глобальные сети 327 Для реализации механизма скользящего окна в информационном кадре предусмотрено 2 поля: • поле N(S), содержащее порядковый номер передаваемого кадра; • поле N(R), содержащее номер очередного ожидаемого кадра. Наличие этих двух полей связано с реализацией дуплексной передачи данных, а их длина определяет ширину окна в 7 (при длине 3 бита) или 127 (при длине 7 бит) кадров. Бит P/F (Poll/Final – Опрос/Финал) используется для указания промежуточного (P) или последнего передаваемого (F) кадра. В некоторых случаях этот бит может использоваться для указания другому узлу о необходимости передать управляющий кадр, не ожидая попутного потока данных. Управляющие кадры могут быть 4-х типов, которые различаются значением поля Type: • Type=0 – подтверждение(RESEIVE READY – к приёму готов) – передаёт в поле N(R) номер следующего ожидаемого кадра и используется при отсутствии попутного потока данных для передачи подтверждения; • Type=1 – отрицательное подтверждение (REJECT – отказ) – передаёт в поле N(R) номер неверно полученного кадра, начиная с которого узел-отправитель должен повторить передачу кадров; • Type=2 – отказ (RESEIVE NOT READY – к приёму не готов) – означает, что в узле-получателе возникли проблемы, не позволяющие принимать кадры (например, переполнена буферная память) и, соответственно, узел-отправитель должен приостановить передачу кадров, при этом в поле N(R) указывается номер кадра, начиная с которого узел- отправитель в дальнейшем (после устранения причины приостановки приёма кадров) должен будет повторить передачу кадров; • Type=3 – выборочное подтверждение (SELECTIVE REJECT – выборочный отказ) – передаёт в поле N(R) номер только того кадра, передачу которого узел-отправитель должен повторить. Ненумерованные кадры применяются в основном для служебных целей, но могут переносить и данные, когда требуется ненадёжный не требующий соединения сервис. Поля |