История стека tcp/ip
Transmission Control Protocol/Internet Protocol (TCP/IP) - это промышленный стандарт стека протоколов, разработанный для глобальных сетей.
Стандарты TCP/IP опубликованы в серии документов, названных Request for Comment (RFC). Документы RFC описывают внутреннюю работу сети Internet. Некоторые RFC описывают сетевые сервисы или протоколы и их реализацию, в то время как другие обобщают условия применения. Стандарты TCP/IP всегда публикуются в виде документов RFC, но не все RFC определяют стандарты.
Стек был разработан по инициативе Министерства обороны США (Department of Defence, DoD) более 20 лет назад для связи экспериментальной сети ARPAnet с другими сателлитными сетями как набор общих протоколов для разнородной вычислительной среды. Сеть ARPA поддерживала разработчиков и исследователей в военных областях. В сети ARPA связь между двумя компьютерами осуществлялась с использованием протокола Internet Protocol (IP), который и по сей день является одним из основных в стеке TCP/IP и фигурирует в названии стека.
Большой вклад в развитие стека TCP/IP внес университет Беркли, реализовав протоколы стека в своей версии ОС UNIX. Широкое распространение ОС UNIX привело и к широкому распространению протокола IP и других протоколов стека. На этом же стеке работает всемирная информационная сеть Internet, чье подразделение Internet Engineering Task Force (IETF) вносит основной вклад в совершенствование стандартов стека, публикуемых в форме спецификаций RFC.
Формат заголовка tcp
На рис. показана структура заголовка ТСР-сегмента. Каждый сегмент начинается с 20-байтового заголовка фиксированного формата. За фиксированным заголовком могут следовать дополнительные поля. После дополнительных полей может располагаться до 65 536 - 20 - 20 = 65 495 байт данных, где первые 20 байт означают IP-заголовок, а вторые - TCP-заголовок. Сегменты могут и не содержать данных. Такие сегменты часто применяются для передачи подтверждений и управляющих сообщений.
Рис. 6.19. TCP-заголовок
Рассмотрим TCP-заголовок поле за полем. Поля Порт получателя и Порт отправителя являются идентификаторами локальных конечных точек соединения. Каждый хост может сам решать, как назначать свои порты, начиная с 1024. Номер порта вместе с IP-адресом хоста образуют уникальный 48-битовый TSAP-адрес. Пара номеров сокетов получателя и отправителя служит идентификатором соединения.
Поля Порядковый номер и Номер подтверждения выполняют свою обычную функцию. Обратите внимание, что поле Номер подтверждения означает следующий ожидаемый байт, а не последний полученный байт. Оба 32-разрядные, так как в TCP-потоке нумеруется каждый байт данных.
Поле Длина TCP-заголовка означает размер TCP-заголовка в 32-разрядных словах. Эта информация нужна, так как поле Параметры может быть переменной длины, а вместе с ним и весь заголовок. Это поле можно рассматривать, как смещение от начала сегмента до начала данных в 32-битовых словах.
Следом идет неиспользуемое 6-битовое поле. Тот факт, что это поле выжило в течение десяти лет, является свидетельством того, насколько хорошо продуман дизайн TCP.
Затем следуют шесть 1-битовых флагов. Бит URG устанавливается в 1 в случае использования поля Указатель на срочные данные, содержащего смещение в байтах от текущего порядкового номера байта до места расположения срочных данных. Таким образом, в протоколе TCP реализуются прерывающие сообщения. Как уже упоминалось, содержимым срочных данных целиком занимается прикладной уровень. Протокол TCP лишь обеспечивает их доставку и не интересуется причиной прерывания.
Бит АСК, будучи установлен в 1, означает, что поле Номер подтверждения содержит осмысленные данные. В противном случае данный сегмент не содержит подтверждения и поле Номер подтверждения просто игнорируется.
Бит PSH является флагом PUSH, с помощью которого отправитель просит получателя доставить данные приложению сразу по получении пакета, а не хранить его в буфере, пока буфер не наполнится, что получатель может делать ради большей эффективности.
Бит RST используется для сброса состояния соединения, которое из-за сбоя хоста или по другой причине попало в тупиковую ситуацию. Кроме того, он используется для отказа от неверного сегмента или от попытки создать соединение. Если вы получили сегмент с установленным битом RST, это означает наличие какой-то проблемы.
Бит SYN применяется для установки соединения. У запроса соединения бит SYN = 1, а бит АСК = 0, это означает, что поле подтверждения не используется. В ответе на этот запрос содержится подтверждение, поэтому значения этих битов в нем равны: SYN = 1, АСК = 1. Таким образом, бит SYN используется для обозначения сегментов CONNECTION REQUEST и CONNECTION ACCEPTED, а бит АСК - чтобы отличать их друг от друга.
Бит FIN используется для разрыва соединения. Он указывает, что у отправителя больше нет данных для передачи. Однако, даже закрыв соединение, процесс может продолжать получать данные неопределенно долго. У сегментов с битами FIN и SYN есть порядковые номера, что гарантирует правильный порядок их выполнения.
Управление потоком в протоколе TCP осуществляется при помощи скользящего окна переменного размера. Поле Размер окна сообщает, сколько байтов может быть послано после получившего подтверждения байта. Значение поля Размер окна может быть равно нулю, это означает, что все байты вплоть до Номер подтверждения-1 получены, но у получателя в данный момент какие-то проблемы, и остальные байты он пока принять не может. Разрешение на дальнейшую передачу может быть выдано отправкой сегмента с таким же значением поля Номер подтверждения и ненулевым значением поля Размер окна.
Поле Контрольная сумма призвано повысить надежность. Оно содержит контрольную сумму заголовка, данных и псевдозаголовка, показанного на рис. 6.20. При выполнении вычислений поле Контрольная сумма устанавливается на ноль, а поле данных дополняется нулевым байтом, если его длина представляет собой нечетное число. Алгоритм вычисления контрольной суммы просто складывает все 16-разрядные слова в дополнительном до 1 коде, а затем вычисляет дополнение для всей суммы. В результате, когда получатель считает контрольную сумму всего сегмента, включая поле Контрольная сумма, результат должен быть равен 0.
Рис. 6.20. Псевдозаголовок, включаемый в контрольную сумму TCP
Псевдозаголовок содержит 32-разрядные IP-адреса отправителя и получателя, номер протокола для TCP (6) и счетчик байтов для ТСР-сегмента (включая заголовок). Включение псевдозаголовка в контрольную сумму TCP помогает обнаружить неверно доставленные пакеты, хотя это нарушает иерархию протоколов, так как IP-адреса в нем принадлежат IP-уровню, а не TCP-уровню.
Поле Параметры предоставляет дополнительные возможности, не покрываемые стандартным заголовком. Один из наиболее важных параметров позволяет каждому хосту указать максимальный размер поля полезной нагрузки, который он может принять. Использование сегментов большего размера является более эффективным, так как при этом снижается удельный вес накладных расходов в виде заголовка, однако не все хосты способны принимать очень большие сегменты. Хосты могут сообщить друг другу максимальный размер поля полезной нагрузки во время установки соединения. По умолчанию этот размер равен 536 байтам. Все хосты обязаны принимать ТСР-сегменты размером 536 + 20 = 556 байт. Для двух направлений могут быть установлены различные значения размера поля полезной нагрузки.
Для линий с большой скоростью передачи и большой задержкой окно размером в 64 Кбайт оказывается слишком маленьким. Так, для линии 73 (44,736 Мбит/с) полное окно может быть передано в линию всего за 12 мс. Если значение времени распространения сигнала в оба конца составляет 50 мс (типично для трансконтинентального оптического кабеля), 3/4 времени отправитель будет заниматься ожиданием подтверждения. При связи через спутник ситуация будет еще хуже. Больший размер окна мог бы улучшить эффективность, но 16-битовое поле Размер окна не позволяет указать больше 64 Кбайт. В RFC 1323 был предложен новый параметр Масштаб окна, о значении которого два хоста могли договориться при установке соединения. Это число позволяет сдвигать поле Размер окна до 14 разрядов влево, позволяя расширять размер окна до 230 байт (1 Гбайт). В настоящее время большинство реализации протокола TCP поддерживают эту возможность.
Еще одна возможность, предложенная в RFC 1106 и широко применяемая сейчас, состоит в использовании протокола выборочного повтора вместо возврата на п. Если адресат получает один плохой сегмент и следом за ним большое количество хороших, у нормального TCP-протокола, в конце концов, истечет время ожидания, и он передаст повторно все неподтвержденные сегменты, включая те, что были получены правильно. В документе RFC 1106 было предложено использовать отрицательные подтверждения (NAK), позволяющие получателю запрашивать отдельный сегмент или несколько сегментов. Получив его, принимающая сторона может подтвердить все хранящиеся в буфере данные, уменьшая таким образом количество повторно передаваемых данных.