TCP - это транспортный протокол с установлением соединения. Это гарантирует, что данные будут доставлены без ошибок, без пропусков и в последовательности.
Он имеет следующие характеристики:
- Протокол, ориентированный на соединение. То есть приложения запрашивают соединение с местом назначения, а затем используют это соединение для доставки данных, гарантируя, что они будут доставлены без проблем, точка-точка. TCP-соединение имеет два конца: отправитель и получатель. TCP гарантирует, что переданные данные будут доставлены без потерь, дублирования или ошибок передачи Полный дуплекс. Конечные точки, участвующие в TCP-соединении, могут обмениваться данными одновременно в обоих направлениях Надежное начальное соединение. Использование трехстороннего рукопожатия обеспечивает надежное и синхронизированное начальное соединение между двумя концами соединения. TCP гарантирует доставку всех данных до завершения соединения.
TCP - это протокол уровня 4 (транспортный) на уровне OSI, поэтому ему необходимо использовать IP для отправки своих сегментов или сообщений. Таким образом, IP обрабатывает сообщение TCP как информацию, которую он должен доставить, и никогда не пытается интерпретировать его содержимое, как это обычно делается при передаче сообщения от одного нижнего уровня к другому. Вот почему маршрутизатор или любое устройство OSI уровня 3 может только наблюдать за заголовками IP для пересылки дейтаграмм. Ответственным за интерпретацию сообщений TCP после их получения с сетевого уровня является TCP машины назначения.
1.1. Функция TCP
TCP - это протокол значительного размера, который выполняет большое количество функций:
- Связывание портов с соединениями Устанавливайте соединения с использованием трехэтапного соглашения. Медленный запуск во избежание перегрузок. Разделение данных на сегменты для передачи. Число данных. Обработка повторяющихся входящих сегментов. Вычисление контрольных сумм. Регулирование потока. данные с помощью окон отправки и приема Упорядоченное завершение соединений Прерывание соединений Пометка срочных данных Положительное подтверждение повторной передачи Расчет времени повторной передачи Уменьшение трафика, когда сеть становится перегруженной Укажите сегменты, поступающие не по порядку.Проверьте, закрыты ли окна приема.
1.2. КОНЦЕПЦИИ
1.2.1. Входные и выходные потоки
Концептуальная модель соединения заключается в том, что одно приложение отправляет поток данных другому одноранговому приложению. В то же время он получает поток данных от другого. TCP предоставляет дуплексную службу, которая одновременно обрабатывает два потока данных.
1.2.2. Сегменты
TCP должен преобразовывать потоки исходящих данных приложения, чтобы их можно было доставлять в виде дейтаграмм. Приложение перемещает данные в TCP, а TCP помещает их в буфер отправки. Возьмите кусок данных, добавьте к нему заголовок, создав сегмент.
TCP преобразует сегмент в IP, чтобы доставить его как единую дейтаграмму. Упаковка данных в блоки подходящего размера позволяет более эффективно использовать потоковые службы, поэтому TCP следует дождаться сбора разумного количества данных перед созданием слайса.
1.2.3. От себя
Иногда клиентской программе требуется, чтобы TCP доставил данные в приложение удаленного сервера как можно скорее, для этого она использует функцию {push}. Представим, что клиентская программа начала интерактивный сеанс с удаленным сервером, а пользователь набрал команду и нажал возврат каретки. Клиентская программа будет использовать эту функцию, чтобы сообщить TCP доставить указанные данные как можно скорее.
1.2.4. Порты приложений
Интерфейс между TCP и локальным процессом называется портом. Чтобы приложение могло получить доступ к сети и отправлять данные через нее, оно должно делать это через порт. Приложение использует номер порта для отправки потока данных, а другой конец соединения получает его через другой номер порта.
Порты идентифицируются десятичным числом от 0 до 65 535 как в TCP, так и в UDP. Производители, реализующие TCP, имеют большую свободу в назначении номеров портов процессам, хотя Internet Assigned Numbers Authority (IANA) выделил диапазон от 0 до 1023 для ряда общих процессов (RFC 1700), такие как telnet, ftp, pop3, smtp и т. д.
Каждый раз, когда клиенту требуется соединение, он просит операционную систему назначить ему неиспользуемый номер порта без резервирования. По окончании соединения клиент возвращает порт системе и может использоваться другим клиентом.
Описание приложения порта
9 Discard Отменить все входящие данные
19 потоков символов Chargen Swap
20 FTP-Data Порт передачи данных для передачи файлов
21 FTP Диалоговый порт для передачи данных
23 Telnet Порт удаленного подключения с помощью Telnet
25 Порт SMTP Simple Mail Transfer Protocol
110 Служба поиска электронной почты POP3
119 Служба публикации новостей сети NNTP
Список стандартизованных портов TCP.
Чтобы полностью указать соединение, к номеру порта добавляется IP-адрес хоста. Эта комбинация называется розеткой. Следовательно, номер сокета уникален во всем Интернете. Соединение между двумя хостами полностью описывается сокетами, назначенными каждому Терминалу соединения. Соединение между двумя сокетами обеспечивает двунаправленный (полнодуплексный) канал связи между двумя процессами.
TCP использует два типа сокетов:
- Розетки. Используется с TCP для надежного, последовательного и двунаправленного обмена данными. Сокеты для дейтаграмм. Они используются с UDP для обеспечения двунаправленной и ненадежной передачи данных.
Сокеты - это интерфейс прикладных программ (API) между TCP, процессами и приложениями. Этот API позволяет разработчикам получать доступ к TCP для своих приложений.
TCP форматирует заголовок для каждого сегмента, передаваемого по IP. Когда IP создает дейтаграмму IP, заголовок TCP следует за заголовком IP.
IP-сегменты организованы в 16-битные слова. Если сегмент содержит нечетное количество октетов, он дополняется последним октетом, состоящим из всех нулей.
Поля заголовка TCP следующие:
- Исходный порт (16 бит). Задает порт исходного модуля TCP.Порт назначения (16 бит). Задает порт TCP-модуля назначения. Порядковый номер (32 бита). Задает последовательную позицию первого октета данных в сегменте. Когда сегмент открывает соединение (установлен бит SYN), порядковый номер представляет собой начальный порядковый номер (ISN), а первый октет поля данных - это номер ISN + 1 Номер подтверждения (32 бита). Задает следующий порядковый номер, ожидаемый отправителем сегмента. TCP указывает, что это поле активируется установкой бита ACK, который происходит всякий раз, когда устанавливается соединение Размер заголовка (4 бита). Задает количество 32-битных слов, составляющих заголовок TCP.Поле «Параметры» дополняется нулями для формирования полного 32-битного слова, если необходимо. Зарезервировано (6 бит). Он должен иметь нулевое значение. Зарезервировано для использования в будущем Управляющие биты (6 бит). 6:
oACK. Если он равен 1, это означает, что номер подтверждения поля имеет значение.
oURG. Если он равен 0, это означает, что его следует игнорировать. Если он равен 1, это означает, что данные срочные.
oPSH. Запускает функцию {push}. Указывает, должен ли TCP немедленно доставить данные в приложение.
oRST. Указывает на ошибку, также используется для прерывания сеанса.
oSYN. Синхронизирует счетчики последовательностей соединения. Этот бит будет установлен (1), когда сегмент запрашивает открытие соединения.
Или конец. Конец передачи и закрытие соединения. При успешном завершении устанавливается значение 1.
- Окно (16 бит). Определяет количество октетов, которое может принять получатель сегмента, начиная с октета, указанного в поле Подтверждение Контрольная сумма (16 бит). Контрольная сумма на основе полей заголовка и данных. Он не включает заполнение, используемое для сегмента, содержащего четное число октетов. Контрольная сумма также основана на 96-битном псевдозаголовке. Срочный указатель (16-битный). Определяет порядковый номер октета, следующего за срочными данными. Указатель срочности - это положительное смещение от порядкового номера сегмента. Опции (переменная). Опции могут выполнять несколько функций: конец списка опций, максимальный размер сегмента, необязательные данные максимального размера сегмента и т. Д. И т. Д. Заливка (переменная).Октеты с нулевым значением, которые добавляются к заголовку, чтобы округлить его длину до 32 бит.
12-октетный псевдозаголовок TCP включает в себя адрес источника и получателя, протокол и длину сегмента. Эта информация отправляется с сегментом в IP для защиты TCP от ошибочно маршрутизируемых сегментов. Значение поля длины включает заголовок и данные TCP, но не учитывает псевдозаголовок.
1.3.1 Параметры максимального размера сегмента
Параметр максимального размера сегмента (MSS) используется для указания размера самого большого фрагмента данных, который может быть получен (и повторно собран) из потока данных. Максимальный размер сегмента системы определяется как:
Размер самой большой датаграммы, которую можно получить - 40
Другими словами, MSS сообщает о самом большом размере полезной нагрузки данных получателя, когда заголовки IP и TCP составляют 20 байтов. Если есть любое количество вариантов заголовка, вычтите их размер. То есть, чтобы рассчитать размер данных, которые могут быть упакованы в сегмент, TCP необходимо вычислить:
Объявлено MSS + 40 - (размер заголовков IP и TCP)
Обычно конечные точки обмениваются своими соответствующими значениями MSS вместе с начальным сообщением {SYN} при установлении соединения. Если система не указывает размер своего сегмента, предполагается, что значение MSS по умолчанию составляет 536 байт, а максимальное значение - 65 535 байт.
MSS налагает ограничение на максимальный размер, который может отправлять TCP, получатель не может обрабатывать ничего большего. Но отправляющий TCP может отправлять меньшие сегменты из-за размера MTV пути подключения.
1.3.2. Заголовок в запросе на подключение
Первый сегмент, который отправляется для установления соединения, имеет флаг {SYN} на 1 и флаг {ACK} на 0. Начальный сегмент {SYN} - единственный сегмент, у которого поле {ACK} равно 0. Это делают межсетевые экраны. Они используются для управления входящими запросами для сеансов TCP.
Поле {порядковый номер} содержит начальный порядковый номер. Поле {Window} (Окно) содержит начальный размер окна приема.
Единственная опция, установленная в настоящее время в TCP, - это максимальный размер сегмента, который может получить TCP. Максимальный размер этого параметра составляет 32 бита, и, как правило, он включается в запрос соединения в поле {options} (если MSS не указан, значение по умолчанию - 536). Размер заголовка TCP {SYN}, содержащего параметр MSS, составляет 24 байта.
1.3.3. Заголовок в ответе на подключение
В ответе о принятии соединения два флага {SYN} и {ACK} устанавливаются в 1. Первоначальный порядковый номер респондента находится в поле {порядковый номер}, а номер принимающего окна - в этом поле. поле {Window}. Максимальный размер сегмента, который желает получить респондент, обычно включается в ответ о соединении в поле {options}. Размер может отличаться от размера того, кто инициирует соединение, они не обязательно должны быть одинаковыми.
Запрос на соединение можно отклонить, установив флаг {RST} в 1 в ответе.
1.3.4. Выбор начального порядкового номера
Во время установления соединения правило TCP указывает, что каждый конец соединения должен выбрать {начальный порядковый номер} из внутренних 32-битных часов. Зачем?. Представьте, что происходит, когда система перестает работать. Предположим, пользователь открыл соединение непосредственно перед тем, как оно перестало работать, и уже отправил небольшой объем данных. После восстановления система не запоминает ничего о том, что она делала до прекращения работы, включая установленные соединения и назначенные номера портов. Пользователи должны снова начать соединения. Номера портов начинают назначаться таким образом, что первым его запрашивает тот, кому он предоставляется, и некоторые из этих портов могли использоваться другими соединениями всего несколько секунд.В течение этого интервала система, находящаяся далеко от одного из подключений, могла не осознавать, что другой конец перестал работать и снова перестал работать, может возникнуть большая путаница, если старые данные, которым требуется время для достижения сети, будут смешаны с данными из новое соединение. Благодаря тому, что новые начинаются с определенного значения часов, эта проблема не возникает. Старые данные, вероятно, будут пронумерованы значениями за пределами нового диапазона {порядковый номер}Благодаря тому, что новые начинаются с определенного значения часов, эта проблема не возникает. Старые данные, вероятно, будут пронумерованы значениями за пределами нового диапазона {порядковый номер}Благодаря тому, что новые начинаются с определенного значения часов, эта проблема не возникает. Старые данные, вероятно, будут пронумерованы значениями за пределами нового диапазона {порядковый номер}
1.3.5. Общее использование полей
Чтобы подготовить передачу заголовка TCP, порядковый номер первого октета включается в поле {порядковый номер}.
Поле {номер подтверждения} заполняется номером следующего октета, ожидаемым с другого конца, а бит {ack} устанавливается в 1.
Поле {window} содержит текущий размер окна приема, то есть количество байтов, начиная с {номер подтверждения}, которые могут быть получены. Таким образом достигается очень точное управление потоком. Точное состояние окна приема сообщается на другой конец во время сеанса.
Если приложение отправляет {push} в TCP, флаг {push} устанавливается в 1. Предполагается, что принимающий TCP реагирует на флаг {push}, доставляя данные своему приложению с той скоростью, с которой приложение желает их получить., Если флаг {срочно} установлен в 1, это указывает, что есть ожидающие срочные данные, а указатель {срочно} указывает на последний октет срочных данных.
Флаг {reset} устанавливается в 1, чтобы прервать соединение. Его также можно отправить в ответ на сегмент, который не имеет смысла в текущем соединении, обрабатываемом TCP.
Флаг {end} устанавливается в 1 в сообщениях, используемых для закрытия соединения.
1.3.6. Контрольная сумма
Контрольная сумма IP применяется только к заголовку IP. Контрольная сумма TCP применяется ко всему сегменту, а также к псевдозаголовку, который состоит из информации, извлеченной из IP-заголовка.
Размер TCP рассчитывается путем сложения размера заголовка TCP и размера данных. Сумма TCP является обязательной, а не необязательной, как в UDP. Во входящем сегменте вычисляется контрольная сумма заголовка TCP. Если значения не совпадают, сегмент отбрасывается.
1.4. УСТАНОВКА СОЕДИНЕНИЯ
Перед тем как установить связь, каждая сторона вызывает подпрограмму, которая создает блок памяти для хранения параметров TCP и IP во время соединения, таких как адреса сокетов, текущие порядковые номера, начальное значение IP на время жизни и другие. Когда клиент хочет получить доступ к серверу, он запускает запрос на соединение, используя IP-адрес и порт сервера. Процедура подключения называется трехэтапным соглашением: SYN, SYN и ACK.
Во время установления соединения происходит обмен важной информацией. Каждая сторона уведомляет другую:
- Из пространства, доступного в его буфере для приема данных. Максимальный объем данных, который может нести сегмент. Начальный порядковый номер, который будет использоваться для нумерации выходных данных.
1,5. ПЕРЕДАЧА ДАННЫХ
Передача данных начинается после завершения установки в три этапа.
КЛИЕНТ
TCP
SERVER
TCP
Поток данных и его ACK.
В приведенном выше примере показан прямой обмен данными. Для облегчения нумерации используются сообщения размером 1000 байт.
Все заголовки сегментов TCP содержат поле ACK, которое идентифицирует порядковый номер следующего байта, ожидаемого с другого конца. Первый сегмент, который отправляет клиент, содержит байты с 1001 по 2000. Его поле ACK сообщает, что порядковый номер следующего байта, который он ожидает от сервера, равен 3001. Сервер отвечает сегментом, содержащим 1000 байтов данных, начиная с 3001. Поле ACK в заголовке TCP указывает, что байты с 1001 по 2000 были успешно получены, поэтому ожидаемый порядковый номер следующего байта от клиента - 2001. Затем клиент отправляет сегменты, которые начинаются с байты 2001, 3001 и 4001. Имейте в виду, что клиенту не нужно ждать прибытия ACK каждого сегмента.Вы можете отправлять данные на другой конец, если у вас есть неиспользуемое пространство в буфере. Таким образом, сервер экономит полосу пропускания, если один ACK используется, чтобы указать, что все сегменты были получены правильно.
1.6. УПРАВЛЕНИЕ ПОТОКОМ
TCP, который получает данные, обрабатывает поток входящих данных. Получатель решает, сколько данных он хочет принять, а отправитель должен действовать в этих пределах. Во время установления соединения каждая сторона выделяет пространство для буферов приема для этого соединения и передает его, {это количество байтов, которое они могут отправить мне}. Это число обычно является целым кратным максимальному размеру сегмента.
Поток данных достигает буфера приема и остается там до тех пор, пока его не перехватит приложение, связанное с этим TCP-портом.
Приложение собирает данные
Окно приема простирается от последнего зафиксированного байта до конца буфера. В предыдущем примере весь буфер свободен, поэтому имеется окно приема 4 КБ. Поступает 1 К данных, а окно приема уменьшается до 3 К. Поступают еще два сегмента по 1 К, что означает, что размер окна уменьшается до 1 КБ. Наконец, приложение забирает из буфера 3 КБ данных, в результате чего увеличивается свободное пространство для данных (вы можете увидеть, как окно перемещается вправо. В реальном сеансе размер окно приема варьируется в зависимости от потребностей приложения
1.6.1. Окно приема
Окно приема - это любое незанятое пространство в буфере приема. Данные остаются в приемном буфере до тех пор, пока их не соберет предполагаемое приложение.
Получатель {ACK} содержит обновление состояния окна приема. Поток данных от отправителя регулируется в соответствии с этими обновлениями окна.
В большинстве случаев буфер приема, который устанавливается во время установления соединения, поддерживается во время соединения, хотя он может увеличиваться или уменьшаться, пока получатель не {не возвращается} от того, что он предоставил отправителю.
1.6.2. Окно отправки
Передатчик данных контролирует две вещи; сколько данных было отправлено и уже подтверждено, а также текущий размер окна приема с другой стороны. Активное пространство для отправки начинается с первого октета без перехода к правой стороне текущего окна приема. Часть окна приема этого пространства указывает, сколько дополнительных данных может быть отправлено на другую сторону.
Начальный порядковый номер и начальный размер окна приема получаются на этапе установления соединения.
В приведенном выше примере:
1. Излучатель запускается с окном отправки 4K.
2. Отправитель передает 1К и хранит копию таких данных до прибытия расчетов, так как может потребоваться их повторная передача.
3. Приходит {ACK} для первых 1 КБ, а еще 2 КБ данных отправляются и хранят их копию.
4. Наконец, приходит {ACK}, указывающий, что все переданные байты получены. {ACK} также обновляет окно приемника до 4K.
Но необходимо выделить некоторые характеристики:
- Отправителю не нужно ждать {ACK} для каждого сегмента переданных данных. Единственное ограничение для передачи - это размер окна приема.Предположим, что отправителю необходимо повторно передать данные, которые были отправлены с использованием очень маленьких сегментов (например, 80 байтов). Данные можно переупаковывать более эффективно, например, в один сегмент.
1.7. ОБСЛУЖИВАНИЕ СЕССИИ
1.7.1. Windows зонд
Если есть активный отправитель и ленивый получатель, у вас может быть окно приема размером 0 байт. Это называется {закрытое окно}. Когда пробел открывается, отправляется {ACK}, который обновляет размер окна. Но что произойдет, если {ACK} будет потерян?, Поскольку оба конца могут ждать бесконечно. Чтобы этого не произошло, отправитель отправляет постоянные таймеры при закрытии окна приема. По истечении таймера на другой конец отправляется сегмент с именем {window probe}. В некоторых реализациях зонд включает данные. Зонд заставляет другой конец отправить обратно {ACK} с текущим состоянием окна. Если окно продолжает обнуляться, значение постоянного таймера удваивается.Этот процесс повторяется до тех пор, пока значение таймера не достигнет максимального значения 60 секунд. TCP будет продолжать посылать зонды бесконечно каждые 60 секунд или до тех пор, пока не откроется окно, или пока пользователь не прервет процесс, или пока не истечет таймер приложения.
1.7.2. Сессионное обслуживание
Что происходит с подключением, в котором ни у одной из сторон нет данных для отправки в течение длительного периода времени? В период бесплатного использования сеть может перестать работать или кабели могут быть отрезаны и повторно подключены. Достаточно того, что сетевая сеть находится в рабочем состоянии, когда две стороны возвращаются для обмена данными, сеанс не теряется. Конечно, проблема в том, что любое соединение занимает много памяти на компьютере, поэтому многие реализации TCP отправляют сообщения {keep-alive}, чтобы проверить, не находится ли соединение в режиме ожидания. TCP периодически отправляет это сообщение, чтобы убедиться, что соединение все еще существует. Это сообщение возвращает ответ {ACK}. Использование сообщений необязательно, и если они есть в системе,приложение может отключить его для своих собственных подключений (рекомендуемое время ожидания по умолчанию - два часа). Кроме того, приложения могут отправлять свои собственные таймеры уровня приложения на уровнях, которые имеют смысл для приложения, и что приложение может прерывать сеансы ожидания.
1,8. ПРЕКРАЩЕНИЕ СЕССИИ
Нормальное завершение соединения выполняется с использованием трехэтапного процесса, аналогичного процессу установления. Любая из сторон может запустить процесс завершения.
А. {Я закончил. У меня больше нет данных для отправки}
Б. {Хорошо} или {Но у меня есть данные…..}
- {Я тоже закончил} {ОК} НАЙТИ SEQ № 4001
ЗАЯВКА КЛИЕНТА
- Пользователь отказался
TCP
СЕРВЕРНОЕ ПРИЛОЖЕНИЕ
TCP
Закрытие соединения
ACK № 8001
2. SEQ № 8001
ACK № 4002
ЗАЯВКА КЛИЕНТА
TCP
Закрытие соединения
СЕРВЕРНОЕ ПРИЛОЖЕНИЕ
TCP
Закрытие соединения
3. ПОСЛАТЬ ПОСЛ. № 8001
ACK № 4002
4. SEQ № 4002
ACK № 8002
1. Серверное приложение сообщает TCP разорвать соединение.
2. TCP-сервер отправляет последний сегмент {FIN}, сообщая другой стороне, что он больше не будет отправлять данные.
3. TCP-клиент отправляет ACK сегмента {FIN}.
4. Клиент TCP уведомляет ваше приложение о том, что сервер хочет завершить работу.
5. Клиентское приложение дает команду TCP завершить работу.
6. TCP-клиент отправляет сообщение {FIN}
7. Сервер TCP получает {FIN} от клиента и отвечает {ACK} 8. Сервер TCP уведомляет ваше приложение о том, что соединение было разорвано.
Также может быть случай, когда возникает сбой сети и происходит внезапное завершение работы. Любая из сторон может вызвать внезапное завершение. Это можно сделать, если приложение хочет прервать соединение или если TCP обнаружил серьезную проблему связи, которую невозможно решить. Чтобы запросить внезапное завершение, на другой конец отправляется один или несколько {reset}. {Reset} обозначается флагом в заголовке TCP.
1.8.1. Крайний срок
Система на другом конце может быть не обслуживаемой, или путь к другому концу может быть отрезан или потерян из-за шлюза или соединения. Откуда TCP знает, что он не должен передавать данные вечно? Есть несколько механизмов.
После достижения первого порогового значения количества повторных передач TCP предупреждает IP, чтобы проверить, не является ли проблема отключенным маршрутизатором, и уведомляет приложение о наличии проблемы. TCP продолжает повторную передачу, пока не будет достигнут второй порог, после чего соединение разрывается.
Также может поступить сообщение ICMP о том, что пункт назначения не может быть достигнут по какой-либо причине. В некоторых реализациях TCP будет продолжать попытки достичь пункта назначения до тех пор, пока не завершатся крайние сроки, в конце концов, проблема может быть решена. Затем он передает статус {пункт назначения недоступен} приложению.
Приложение также может установить собственное ограничение на время доставки данных, а также действия, которые необходимо предпринять по истечении крайнего срока. Обычно действие заключается в разрыве соединения.
1,9. УПРАВЛЕНИЕ ОШИБКАМИ
TCP - это надежный протокол, ориентированный на установление соединения. Вот почему он использует различные методы для обеспечения надежной доставки данных. Эти методы позволяют TCP восстанавливаться после таких ошибок, как потеря пакетов, дублирование, задержки, разные скорости передачи между узлами и перегрузка.
- Потерянные пакеты. TCP использует положительное подтверждение с повторной передачей для обеспечения надежной доставки данных. Таким образом, получатель отправляет отправителю контрольные сообщения подтверждения {ACK}, чтобы проверить успешный прием информации. В свою очередь, отправитель инициализирует {таймер} при передаче информации. Если {таймер} истекает до получения подтверждения, отправитель должен повторно передать информацию, инициализировав новый таймер. Если получатель получает дублированный пакет, он не принимает его во внимание и отбрасывает его, поскольку он был принят и помечен как полученный. Если один пакет не получен, а следующий получен, получатель не перемещает скользящее окно, пока не будет получен отсутствующий сегмент.Таким образом, получатель, не получив {ACK}, пересылает потерянный или задержанный пакет.Разные скорости передачи. При установке TCP-соединения и отправитель, и получатель указывают свою промежуточную емкость хранения, чтобы согласовать скорость, с которой будет происходить передача. TCP реализует политику, в которой он поддерживает окно для измерения перегрузки, каждый раз, когда истекает таймер, это окно уменьшается. Для принятия решения об отправке данных отправитель принимает во внимание размер этого окна, чтобы создать размер скользящего окна данных.И отправитель, и получатель указывают свою промежуточную емкость хранения, чтобы согласовать скорость, с которой будет происходить передача. TCP реализует политику, в которой он поддерживает окно для измерения перегрузки, каждый раз, когда истекает таймер, это окно уменьшается. Для принятия решения об отправке данных отправитель принимает во внимание размер этого окна, чтобы создать размер скользящего окна данных.И отправитель, и получатель указывают свою промежуточную емкость хранения, чтобы согласовать скорость, с которой будет происходить передача. TCP реализует политику, в которой он поддерживает окно для измерения перегрузки, каждый раз, когда истекает таймер, это окно уменьшается. Для принятия решения об отправке данных отправитель принимает во внимание размер этого окна, чтобы создать размер скользящего окна данных.
Каждое приложение произвольно доставляет всю информацию в виде потока данных, затем TCP заботится о разделении этой информации на сегменты, размер каждого из которых не превышает размера IP-пакета. Поток, заданный приложением, нумеруется количеством переданных байтов, и каждый из этих сегментов содержит порядковый номер байтов информации. Таким образом, получатель отправляет сегмент с порядковым номером подтвержденной информации, а не сегменты. {ACK} являются кумулятивными, поэтому {ACK} может быть подтверждением нескольких сегментов.
Одна из причин потери пакетов - чрезмерный трафик. Но некоторые протоколы, такие как TCP, используют повторную передачу как механизм, гарантирующий поступление пакетов. Этот механизм - обоюдоострый механизм, поскольку чрезмерная повторная передача может способствовать перегрузке.
TCP интерпретирует потерю пакета как индикатор перегрузки. Механизм управления TCP используется отправляющим узлом для определения уровня перегрузки, и если он выше определенного порогового уровня, который считается максимально допустимым, повторная передача пакетов сокращается. Используемый механизм заключается в том, что хост отправляет пакет, и если подтверждение приходит без потерь, отправитель отправляет два пакета и начинает увеличивать окно в два раза. Когда TCP отправляет количество пакетов, равное половине размера окна, скорость увеличения уменьшается до тех пор, пока он не получит подтверждения отправленных пакетов.
1.10. ПРОИЗВОДИТЕЛЬНОСТЬ
На производительность влияет множество факторов. Основными являются такие ресурсы, как память и пропускная способность сети.
Пропускная способность и задержки базовой сети накладывают ограничения на производительность. Низкое качество передачи подразумевает большое количество отброшенных дейтаграмм. Отказ от триггеров вызывает повторные передачи, уменьшая эффективную полосу пропускания.
Приемник с большим входным буфером позволяет отправителю продолжать передачу без прерывания. Это особенно важно в сетях с большими задержками, где между отправкой и получением данных и обновлением окна проходит много времени. Чтобы обеспечить непрерывный поток данных от отправителя к получателю, место назначения должно иметь окно приема размером не менее:
Полоса пропускания X задержка
Например, если 10 000 байтов могут быть отправлены в секунду, а для получения {ACK} требуется 2 секунды, получатель должен иметь буфер размером не менее 20 000 байтов для поддержания непрерывного потока данных. С буфером, который может содержать только 10 000 байт, производительность снижается вдвое.
Другой фактор, влияющий на производительность, - это способность хоста реагировать на высокоприоритетные события и быстро выполнять {переключение контекста}, то есть прекращать делать одно дело и переходить к другому. Хост может обслуживать множество интерактивных локальных пользователей, фоновые процессы и десятки коммуникационных соединений. Реализация, объединяющая TCP / IP с ядром операционной системы, может значительно снизить накладные расходы на переключение контекста. Требуются достаточные ресурсы ЦП для быстрого выполнения шагов, необходимых для обработки заголовка TCP.
ЦП, который не может быстро вычислить значения контрольной суммы, может замедлить передачу данных.
Программное обеспечение также влияет на производительность: если вы пишете программы, которые не делают ненужной отправку и получение небольших файлов, и с таймерами, которые освобождают сетевые ресурсы, когда вы не выполняете какую-либо полезную работу, это также улучшит производительность.
Факторы производительности TCP.
заявка
Отправляйте и получайте данные эффективно.
Системный администратор
Установка параметра.
производитель
Эффективное и совместимое программное обеспечение TCP / IP.
Операционная система и оборудование
Доступность памяти, мощность процессора, переключение контекста.
Сеть
Пропускная способность, задержка, качество и емкость.
1.10.1. Медленный старт
{Медленный старт} предотвращает добавление в сеанс большого объема трафика в сеть, которая уже может быть перегружена. Представьте себе компанию с 500 сотрудниками, которые прибывают в 8:00 и одновременно начинают валидацию в сети. Идея {медленного запуска} заключается в том, что новое соединение запускается медленно, постепенно увеличивая скорость передачи в соответствии с условиями сети. Во время установления соединения другой конец указывает свое окно приема. Размер второго {окна перегрузки} рассчитывается с целью смягчения передачи в соответствии с условиями сети. Отправитель ограничен окном перегрузки, а не окном приема (большего размера).
Окно перегрузки начинается с сегмента. Для каждого сегмента, из которого он успешно получает {ACK}, окно перегрузки увеличивается на один сегмент, пока оно меньше, чем {окно приема}. Если сеть не перегружена, окно перегрузки скоро достигнет размера окна приема. В нормальном состоянии передачи размер окна перегрузки идентичен размеру окна приема.
Имейте в виду, что медленная загрузка на самом деле не медленная. После первого {ACK} окно перегрузки состоит из двух сегментов. Если {ACK} поступает для двух сегментов, окно увеличивается до четырех сегментов. Если они также подтверждаются правильно, окно увеличивается экспоненциально.
1.10.2. Синдром глупого окна
В ранних реализациях TCP / IP явление, называемое {синдромом глупого окна (SWS)}, происходило довольно часто. Пример:
1. Приложение быстро отправляет данные.
2. Принимающее приложение внимательно считывает побайтно данные из приемного буфера.
3. буфер заполнен
4. Принимающее приложение читает байт, и TCP отправляет {ACK}, в котором говорится {у меня есть место для байта данных}.
5. Посылающий TCP упаковывает байт и передает его.
6. Принимающий TCP отправляет {ACK}, в котором говорится: {спасибо, он у меня есть, и у меня больше нет места}.
7. Принимающее приложение считывает байт и отправляет {ACK}, повторяя процесс.
У медленно принимающего приложения уже есть много ожидающих данных, и поспешная вставка байтов в правую часть окна бесполезна, но добавляет ненужный сетевой трафик.
Эта ситуация не должна быть настолько экстремальной, чтобы вызывать проблемы. Это может происходить с быстрым отправителем, приложением, которое медленно принимает и читает фрагменты данных максимального размера сегмента, а буфер приема почти заполнен. Пример:
Решение простое. Когда окно уменьшается до размера меньше определенного, TCP начинает лгать. TCP не должен сообщать другому концу, что есть дополнительное пространство окна, когда принимающее приложение выполняет небольшое чтение. Вместо этого TCP должен держать в секрете дополнительные ресурсы до тех пор, пока не освободится целевой размер буферного пространства. Рекомендуемый размер - один сегмент, за исключением случая, когда только один сегмент помещается в полный буфер, и в этом случае подойдет половина сегмента. Целевой размер, который TCP снова сообщает правду:
Минимум (1/2 размера приемного буфера, максимальный размер сегмента)
TCP начинает лгать, когда размер окна меньше этого количества, и говорит правду, когда размер окна меньше этого количества. Имейте в виду, что в сохранении представленных материалов нет ничего плохого, поскольку принимающее приложение не собрало большую часть ожидаемых данных. Решение простое: предположим, что буфер приема может хранить несколько сегментов. Быстрый отправитель заполнит буфер приема, и отправителю будет указано, что свободного места нет, пока он не освободится, достаточно места для приема полного сегмента.
1.10.3. Задержка ACK
Задержка {ACK} - еще один механизм, который может улучшить производительность. Уменьшая количество отправленных {ACK}, вы экономите полосу пропускания, которую можно использовать для другого трафика. Если другой конец немного подождет перед отправкой {ACK}, есть вероятность, что:
- Вы можете подтвердить несколько сегментов с помощью одного сообщения {ACK}. Приложение на другом конце может собирать данные для отправки в течение периода таймера, и в этом случае {ACK} может быть в заголовке исходящего сообщения, и сообщение не потребуется разделены.
Чтобы избежать задержки целых сегментов, например, при передаче файла, {ACK} следует отправлять как минимум для каждого сегмента. Многие реализации используют ограничение по времени в 200 миллисекунд. Помните, что задержка {ACK} не замедляет передачу. Если прибывают небольшие сегменты, в буфере будет много места, и передатчик может продолжить отправку, даже если повторные передачи будут медленными. Если прибывают полные сегменты, каждый второй сегмент немедленно инициирует {ACK}.
1.10.4. Период ретрансляции
После отправки сегмента TCP запускает таймер и ожидает {ACK}. Если {ACK} не приходит в течение указанного времени, TCP повторно передает сегмент. Что это за период ожидания? Если время повторной передачи слишком короткое, отправитель загромождает сеть ненужными сегментами и загружает получателя дубликатами. Но если время выполнения заказа слишком велико, вы теряете возможность быстрого восстановления, когда фактически теряете сегмент и снижаете производительность. Как выбрать идеальный срок? Поскольку настройка, которая хорошо работает в высокоскоростной локальной сети (LAN), может оказаться катастрофической для соединения на большом расстоянии с большим количеством переходов, фиксированные временные рамки не могут быть решением. Вот почему существуют алгоритмы, подобные алгоритму Якобсона,Карна и Партриджа, которые позволяют TCP адаптироваться к изменяющимся условиям и, таким образом, иметь возможность выбирать правильное время повторной передачи.
1.10.5. Препятствия на пути к производительности
TCP оказался очень гибким, работая в сетях, передающих сотни или миллионы бит в секунду. Протокол хорошо зарекомендовал себя в локальных сетях Ethernet, Token-Ring или оптоволоконном распределенном интерфейсе данных (FDDI), а также в каналах с низкой пропускной способностью и каналах с большими задержками, таких как спутниковые каналы.
TCP настроен на реагирование на необычные условия, такие как перегрузка. Однако у него есть некоторые характеристики, которые ограничивают скорость TCP с использованием технологий, которые предлагают пропускную способность в сотни или тысячи мегабайт в секунду.
Предположим, вы выполняете передачу файлов между двумя системами и хотите отправлять данные с максимальной эффективностью. Представим:
- Максимальный размер сегмента - 4 КБ. Окно приема - 4 КБ. Пропускной способности достаточно, чтобы отправлять 2 сегмента в секунду. Принимающее приложение собирает данные сразу после их поступления. {ACK} приходит через две секунды.
Отправитель сможет отправить данные быстро, потому что, как только назначение окна завершено, приходит {ACK}, который позволяет отправить другой сегмент:
ОТГРУЗОЧНЫЙ СЕГМЕНТ 1.
ПОСТАВКА 2.
ПОСТАВКА 3.
ПОСТАВКА 4.
Прошло две секунды:
{ACK} СЕГМЕНТА 1 ПОЛУЧЕН, СЕГМЕНТ 5 МОЖЕТ БЫТЬ ОТПРАВЛЕН
СЕГМЕНТ 2 {ACK} ПОЛУЧЕН, СЕГМЕНТ 6 МОЖНО ОТПРАВИТЬ
{ACK} СЕГМЕНТА 3 ПОЛУЧЕН, СЕГМЕНТ 7 МОЖЕТ БЫТЬ ОТПРАВЛЕН
{ACK} СЕГМЕНТА 4 ПОЛУЧЕН, СЕГМЕНТ 8 МОЖЕТ БЫТЬ ОТПРАВЛЕН
Прошло еще две секунды:
{ACK} СЕГМЕНТА 5 ПОЛУЧЕН, СЕГМЕНТ 9 МОЖЕТ БЫТЬ ОТПРАВЛЕН
…………………………………….
Если бы окно приема было всего 2 КБ, отправитель был бы вынужден ждать одну секунду из двух, прежде чем он сможет отправить больше данных. Фактически, для поддержания непрерывного потока, окно приема должно иметь размер не менее:
Окно = пропускная способность X время приема-передачи
Хотя пример был преувеличен, он показывает, что небольшое окно может вызвать проблемы на спутниковых каналах с длительной задержкой. Другой пример - то, что происходит с соединениями с высокой пропускной способностью. Если полоса пропускания и скорость передачи составляют 10 миллионов бит в секунду, но время приема-передачи составляет 100 миллисекунд (1/10 секунды), окно приема для поддержания непрерывного потока должно поддерживать не менее 1000000 бит, то есть 125000 байт. Но наибольшее число, которое можно записать в поле окна приема заголовка TCP, составляет 65 536 байт.
1.11. СОСТОЯНИЯ TCP
TCP-соединение проходит через определенное количество состояний. Сначала соединение устанавливается посредством обмена сообщениями, затем передаются данные, а затем соединение закрывается посредством обмена сообщениями. Каждый шаг в процессе подключения соответствует состоянию подключения. Программное обеспечение TCP на каждом конце соединения постоянно отслеживает состояние своей стороны.
Состояние сервера Описание события
ЗАКРЫТО
Пассивное открытие серверным приложением. Фиктивное состояние перед подключением.
СЛУШАТЬ Сервер ожидает запроса на соединение от клиента.
Сервер TCP получает {SYN}, отправляет
{SYN / ACK} Сервер получил {SYN} и отправил {SYN / ACK}. Дождитесь {ACK}.
SYN-RECEIVED
Сервер TCP получает {ACK}
УСТАНОВЛЕН {ACK} получен, соединение открыто.
Переходы между состояниями сервера
Состояние сервера Описание события
ЗАКРЫТО
Клиент запрашивает соединение. Клиент TCP отправляет SYN. Фиктивное состояние перед подключением.
SYN-SEN Клиент TCP отправил серверу {SYN}.
УСТАНОВЛЕН TCP-сервер получает {SYN / ACK}, отправляет
{} ACK
Клиент получил {SYN / ACK} от сервера и отправил {ACK} обратно.
Вы можете начать передачу данных.
Переходы состояний клиента.
Состояние сервера Описание события
УСТАНОВЛЕНО Локальное приложение запрашивает закрытие. TCP отправляет {FIN / ACK}.
FIN-WAIT-1
TCP получает {ACK}. Тот, кто закрывает, ждет ответа от другого конца. Помните, что в этот момент данные все еще могут поступать с другого конца.
FIN-WAIT-2
TCP получает {FIN / ACK}. Отправьте {ACK}. Тот, кто закрывает, получил {ACK} с другого конца, но не {END}. Он ждет {END}, пока принимает данные, которые к нему поступают.
ВРЕМЯ-ОЖИДАНИЕ Соединение находится в подвешенном состоянии, чтобы позволить приходить дубликаты или {FIN} дубликаты данных, которые могут существовать в сети. Период ожидания в два раза превышает предполагаемый максимальный срок службы сегмента.
ЗАКРЫТО Вся информация о подключении удалена.
Кто закрывает переходы между состояниями.
Состояние сервера Описание события
ESTABLISHED TCP получает {FIN / ACK}.
ЗАКРЫТЬ-WAIT-1
TCP отправляет {ACK}. {FIN} прибывает
FIN-WAIT-2
Локальное приложение указывает на выключение.
TCP отправляет {FIN / ACK}. TCP ожидает, пока ваше приложение укажет на закрытие. При желании приложение может отправлять дополнительные данные.
LAST-ACK
TCP получает {ACK} TCP ожидает последнего {ACK}
ЗАКРЫТО Вся информация о подключении удалена.
Закрытые переходы конечных состояний.
Команду netstat –an можно использовать для проверки текущего состояния соединений. Этот инструмент предоставляет статистическую информацию о соединениях TCP / IP и активных протоколах.
Netstat предоставляет следующую информацию для каждого подключения:
- Прото. Прототип транспорта, используемый для установления соединения Локальный адрес. Имя или IP-адрес локального компьютера и номер порта, используемого этим соединением. Внешний адрес и номер или имя порта, связанного с подключением. Показывает статус подключения, только TCP
netstat имеет следующий синтаксис:
NetStat
Синтаксис Описание
-a Показывает все прослушивающие порты и соединения. (Обычно серверная часть подключений не отображается.)
-e Отображает статистику Ethernet. Его можно комбинировать с параметром -s.
-n Отображает адрес и номера портов в числовом формате.
-o Отображает идентификатор процесса, связанный с каждым подключением.
-p proto Показать соединения протокола, указанного в proto; который может быть TCP, UDP, TCPv6 или UDPv6. Если используется с параметром -s для отображения статистики по протоколам, proto может быть TCP, UDP, TCPv6 или UDPv6.
-r Отображает содержимое таблицы маршрутов.
-s Показать статистику по протоколу. По умолчанию они отображаются для IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP и UDPv; вы можете использовать опцию p, чтобы указать подмножество значений по умолчанию.
interval Повторно отображает выбранную статистику с паузой в указанном интервале секунд между каждой выборкой. Нажмите Ctrl + C, чтобы прекратить обновление статистики. Если не указано, netstat один раз распечатает информацию о конфигурации.
Netstat без аргументов предоставляет базовое состояние соединений.
C: \ netstat
Активные связи
Proto Локальный адрес Удаленный адрес Статус
TCP cia: 3012 baym-cs186.msgr.hotmail.com:1863 УСТАНОВЛЕН
TCP cia: 3032 194.224.100.71:http CLOSE_WAIT
TCP cia: 3048 a217-75-98-16.deploy.akamaitechnologies.com:http CLOSE_WAIT
С параметром –s отображается статистика для протоколов IP, ICMP, TCP и UDP.
C: \ netstat -s
Статистика IPv4
Получено пакетов = 5963
Получено ошибок заголовка = 0
Получено ошибок адреса = 6
Перенаправленные дейтаграммы = 0
Получены неизвестные протоколы = 0
Отброшенные полученные пакеты = 2395
Обработано полученных пакетов = 3568
Исходящие запросы = 3771
Сброс маршрута = 0
Исходящие пакеты отброшены = 0
Исходящие пакеты без пути = 0
Требуется повторная сборка = 0
Правильная сборка = 0
Плохая сборка = 0
Правильно фрагментированные дейтаграммы = 0
Сильно фрагментированные датаграммы = 0
Создано фрагментов = 0
Статистика ICMPv4
Получено Отправлено
Сообщения
Ошибки
Пункт назначения недоступен
Тайм-аут
Проблемы с параметрами
Пакеты управления потоком
Перенаправление
Echos
Эхо-ответы
Даты
Дата ответов
Статистика TCP для IPv4
Открытые активы = 221
Открытые обязательства = 0
Неудачные попытки подключения = 8
Подключения восстановлены = 78
Текущие соединения = 5
Получено сегментов = 2288
Отправлено сегментов = 2404
Сегментов передано повторно = 10
Статистика UDP для IPv4
Получено дейтаграмм = 1270
Нет порта = 2
Ошибки приема = 16
Отправлено дейтаграмм = 1353
С параметром –an отображаются адреса и статус всех подключений, а также их портов.
C: \ netstat -an
Активные связи
Proto Локальный адрес Удаленный адрес Статус
TCP 0.0.0.0:135 0.0.0.0:0 ПРОСЛУШИВАНИЕ TCP 0.0.0.0:445 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:1026 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3012 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3023 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3024 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3032 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3040 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3048 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3056 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3057 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3067 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3201 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3220 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3227 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3228 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3229 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3231 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3236 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:3237 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 0.0.0.0:5000 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 127.0.0.1:3001 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 127.0.0.1:3002 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 127.0.0.1:3003 0.0.0.0:0 ПРОСЛУШИВАНИЕ
TCP 213.102.64.17:3012 207.46.4.54:1863 УСТАНОВЛЕНО
TCP 213.102.64.17:3032 194.224.100.71:80 CLOSE_WAIT
TCP 213.102.64.17:3048 217.75.98.16:80 УСТАНОВЛЕНО
TCP 213.102.64.17:3187 216.12.215.207:80 TIME_WAIT
TCP 213.102.64.17:3201 217.75.98.7:80 УСТАНОВЛЕНО
TCP 213.102.64.17:3220 130.94.72.189:80 УСТАНОВЛЕНО
TCP 213.102.64.17:3227 217.75.98.7:80 УСТАНОВЛЕНО
TCP 213.102.64.17:3228 62.37.226.86:80 УСТАНОВЛЕНО
TCP 213.102.64.17:3229 62.37.226.86:80 УСТАНОВЛЕНО
TCP 213.102.64.17:3231 161.58.186.225:80 УСТАНОВЛЕНО
TCP 213.102.64.17:3236 62.37.236.78:80 УСТАНОВЛЕНО
TCP 213.102.64.17:3237 62.37.236.78:80 УСТАНОВЛЕНО
UDP 0.0.0.0:135 *: *
UDP 0.0.0.0:445 *: *
UDP 0.0.0.0:500 *: *
UDP 0.0.0.0:1025 *: *
UDP 0.0.0.0:3010 *: *
UDP 0.0.0.0:3022 *: *
UDP 0.0.0.0:3031 *: *
UDP 0.0.0.0:3064 *: *
UDP 0.0.0.0:3065 *: *
UDP 127.0.0.1:123 *: *
UDP 127.0.0.1:1900 *: * UDP 127.0.0.1:2234 *: *
Глава 2 Протокол дейтаграмм пользователя (UDP).
ВВЕДЕНИЕ
UDP - это транспортный протокол уровня 4 (OSI) без установления соединения. UDP - это протокол дейтаграмм, который не гарантирует доставку данных. Если приложение отправляет запрос в дейтаграмме UDP, а ответ не приходит в разумные сроки, ответственность за повторную передачу запроса лежит на приложении. UDP просто отправляет дейтаграмму, и ей все равно, придет она или нет. Не гарантируя доставку, он делает его намного более быстрым и легким протоколом, чем TCP, предлагая альтернативный транспорт для тех процессов, которые не требуют надежной доставки.
Многие приложения используют UDP для отправки сообщений друг другу или для выполнения быстрых запросов к базам данных или серверам DNS (системы доменных имен). UDP - идеальный компонент для создания функций мониторинга, отладки, управления и тестирования.
SERVER
КЛИЕНТ
Какой адрес
IP для….
Ответить
Связь с UDP.
Хотя в некоторых случаях UDP менее надежен, чем TCP, его рекомендуется использовать больше, чем TCP, поскольку он дает преимущества в определенных ситуациях:
- Сообщения между хостами носят спорадический характер. SNMP (простой протокол сетевого управления) снова является хорошим примером. Ваши сообщения отправляются нерегулярно. Рабочая нагрузка, необходимая для открытия и закрытия TCP-соединения для каждого сообщения, приведет к задержке передачи и снижению производительности.Сообщения, не требующие подтверждения. UDP помогает уменьшить сетевой трафик. Оповещения SNMP попадают в эту категорию. В большой сети создается большое количество предупреждений SNMP, когда устройства SNMP передают обновления своего статуса. Однако потеря сообщения SNMP обычно не критична, и сеть освобождается от значительной рабочей нагрузки за счет использования UDP для SNMP.Надежность реализуется на уровне процесса.Сетевая файловая система (NFS) является хорошим примером процесса, который реализует свою собственную функцию надежности и работает через UDP для повышения производительности сети. Его могут использовать приложения, которым необходимо отправлять широковещательные или многоадресные сообщения, например клиент BOOTP.
2.1. ПОРТЫ ПРИМЕНЕНИЯ
Интерфейс между UDP и локальным процессом называется шлюзом. Чтобы приложение могло получить доступ к сети и отправлять данные через нее, оно должно делать это через порт.
1. Пользователь запускает клиентскую программу, например nslookup.
2. Клиентский процесс выполняет системную процедуру, которая говорит: {Я хочу соединение по протоколу UDP. Дайте мне порт.}
3. Системная процедура назначает свободный 16-битный идентификатор, называемый {номер порта}.
Порты обозначаются десятичным числом от 0 до 65 535. Производители, реализующие UDP, имеют большую свободу при назначении номеров портов процессам, хотя Управление по распределению номеров Интернета (IANA) зарезервировало диапазон портов от 0 до 1023 для стандартных служб (ну, Известный), например DNS, SNMP или Netbios.
Описание приложения порта
7 Эхо Эхо датаграммы пользователя обратно отправителю.
9 Discard Отменить дейтаграмму пользователя.
13 DayTime Легко указывает время для пользователя.
17 Quote Возвращает {цитата дня}.
19 потоков символов Chargen Swap
53 Сервер доменных имен DNS.
67 Порт загрузочного сервера для загрузки информации о конфигурации.
68 Bootpc Клиентский порт для получения информации о конфигурации.
69 TFTP Порт простого протокола передачи файлов.
161 SNMP Используется для получения запросов на управление сетью.
162 SNMP-trap Используется для получения отчетов о сетевых проблемах.
Список некоторых общедоступных портов UDP.
Некоторые из этих служб предоставляют блоки для тестирования, отладки и измерения, например служба {echo} на порту 7, где она возвращает все отправленные ей дейтаграммы. Другой порт, например 9 (Discard), отбрасывает полученные датаграммы. Порт 19 - это генератор символов, который отвечает на любое сообщение датаграммой, содержащей от 0 до 512 байт. Номер выбирается случайным образом. Назначение дневной службы, которая прослушивает порт 17, отвечает на любую дейтаграмму, отправляя сообщение с исторической или популярной мудростью при закрытии сеанса или выполнении команды fortune. Порт 13 (DayTime) отвечает на любую дейтаграмму сообщением, содержащим текущую дату и время в читаемом формате ASCII. Сервер и клиент BOOTP используются для инициализации устройств без настройки (немые терминалы).Рабочая станция может определить свой IP-адрес, маску сети, расположение маршрутизатора по умолчанию, адреса важных серверов и даже имя и расположение файла загрузки программного обеспечения с сервера загрузки. Программное обеспечение рабочей станции загружается с использованием протокола Trivial File Transfer Protocol (TFTP; UDP 69).
Порты TCP и UDP не зависят друг от друга. Один процесс может отправлять сообщения через порт UDP 1700, а другой поддерживает сеанс через порт TCP 1700. Некоторым службам необходим доступ как к TCP, так и к UDP, поэтому IANA пытается назначить один и тот же номер порта службам, которым требуется UDP, как TCP, например DNS, который прослушивает порт 53 TCP и UDP.
Комбинация IP-адреса и адреса порта для связи называется {адрес сокета} или {сокет}. Сокет предоставляет всю информацию, необходимую клиенту или серверу для идентификации другого конца.
Заголовок UDP состоит из двух 32-битных слов и имеет следующие поля:
- Исходный порт (16 бит). Это поле является необязательным и указывает порт источника, когда необходимо разрешить получателю дейтаграммы отправлять ответ.Порт назначения (16 бит). Порт IP-хоста назначения Длина (16 бит). Длина дейтаграммы в октетах, включая заголовок и данные. Минимальное значение - 8, чтобы можно было использовать заголовок. Следовательно, максимальная длина дейтаграммы UDP составляет 65 535 октетов, из которых 65 527 октетов могут быть выделены для данных. Контрольная сумма UDP предназначена для проверки {содержимого} сообщения UDP. Контрольная сумма UDP вычисляется на основе комбинации специально созданного псевдозаголовка с определенной IP-информацией, заголовком UDP и данными сообщения.Использование контрольной суммы UDP в конкретном обмене данными необязательно. Если не используется, поле имеет значение 0. Если контрольная сумма была вычислена и ее значение достигает 0, она представляется полем единиц.
2,3. UDP ПЕРЕПОЛНЕНИЕ
Когда приложение получает порт от UDP, сетевое программное обеспечение резервирует несколько буферов для хранения очереди пользовательских дейтаграмм, поступающих на этот порт. Служба UDP не имеет возможности прогнозировать или контролировать, сколько дейтаграмм будет отправлено за один раз.
Если в службу засыпается больше дейтаграмм, чем она может обработать, этот избыток просто отбрасывается.
Пример:
> netstat -a
……………….
0 неполных заголовков
0 полей с неверной длиной данных
0 неверных контрольных сумм
17 розеток переливов
2,4. РАЗЛИЧИЯ МЕЖДУ TCP И UDP
Ключ к транспортному уровню заключается в том, что он позволяет разработчикам приложений выбирать надежность (TCP) или эффективность (UDP).
Большой интерес TCP заключается в его способности изолировать процессы верхнего уровня от сети. Процессам не требуется знать размер сообщений, поскольку TCP заботится об их фрагментации и повторной сборке. Более того, процессы не заботятся о надежности сети, поскольку TCP полностью гарантирует целостность передаваемых им сообщений.
Со стороны UDP это более беззаботный протокол при выполнении своей работы. В отличие от TCP, UDP не требует создания виртуальных каналов между хостами, это обеспечивает более гибкую и эффективную связь, поэтому UDP поддерживает широковещательные и многоадресные сообщения.
Загрузите исходный файл
