Psh ack что значит
Что такое TCP и как он работает?
Протокол управления передачей (TCP) является одним из самых важных протоколов пакета Internet Protocols. Это наиболее широко используемый протокол для передачи данных в сети связи, такой как Интернет.
Длина заголовка TCP составляет минимум 20 байтов и максимум 60 байт.
Адресация
Связь TCP между двумя удаленными хостами выполняется с помощью номеров портов (TSAP). Номера портов могут варьироваться от 0 до 65535, которые делятся как:
Управление подключениями
Связь TCP работает в модели Server / Client. Клиент инициирует соединение, и сервер либо принимает, либо отклоняет его. Для управления подключением используется трехстороннее связывание.
Установка соединения
Клиент инициирует соединение и отправляет сегмент с порядковым номером. Сервер подтверждает это со своим собственным порядковым номером и ACK сегмента клиента, который является еще одним номером последовательности клиентов. Клиент после получения ACK своего сегмента отправляет подтверждение ответа сервера.
Любой из серверов и клиентов может отправлять сегмент TCP с флагом FIN, установленным в 1. Когда принимающая сторона отвечает на это посредством ACKnowlinging FIN, это направление связи TCP закрывается и соединение освобождается.
Управление полосой пропускания
TCP использует концепцию размера окна, чтобы удовлетворить потребность в управлении пропускной способностью. Размер окна сообщает отправителю на удаленном конце, количество сегментов байтов данных, которое может получить приемник с этого конца. TCP использует медленную фазу запуска с использованием размера окна 1 и увеличивает размер окна по экспоненте после каждого успешного сообщения.
Например, клиент использует размер окна 2 и отправляет 2 байта данных. Когда подтверждение этого сегмента получено, размер окна удваивается до 4, а следующий отправленный сегмент отправляется длиной 4 байта данных. Когда получено подтверждение 4-байтового сегмента данных, клиент устанавливает размер окна 8 и т. Д.
Если упущено подтверждение, то есть данные, потерянные в транзитной сети или полученные NACK, размер окна уменьшается до половины, а медленная начальная фаза начинается снова.
Контроль ошибок и контроль потока
TCP использует номера портов, чтобы узнать, какой процесс приложения ему нужен для передачи сегмента данных. Наряду с этим он использует порядковые номера для синхронизации с удаленным хостом. Все сегменты данных отправляются и принимаются с порядковыми номерами. Отправитель знает, какой последний сегмент данных был принят Получателем, когда он получает ACK. Получатель знает о последнем сегменте, отправленном отправителем, ссылаясь на порядковый номер недавно полученного пакета.
Если порядковый номер недавно полученного сегмента не совпадает с порядковым номером, который ожидал приемник, он отбрасывается и NACK отправляется обратно. Если два сегмента поступают с одинаковым порядковым номером, значение временной метки TCP сравнивается для принятия решения.
Мультиплексирование
Способ объединения двух или более потоков данных в один сеанс называется мультиплексированием. Когда клиент TCP инициализирует соединение с сервером, он всегда ссылается на четко определенный номер порта, который указывает на процесс приложения. Сам клиент использует случайный номер порта из частных пулов номеров портов.
Используя TCP Multiplexing, клиент может взаимодействовать с несколькими различными процессами приложения за один сеанс. Например, клиент запрашивает веб-страницу, которая, в свою очередь, содержит различные типы данных (HTTP, SMTP, FTP и т. Д.), Тайм-аут сеанса TCP увеличивается, и сеанс остается открытым на более длительное время, так что накладные расходы на трехстороннюю рукопожатие могут избегать.
Это позволяет клиентской системе получать несколько соединений по одному виртуальному соединению. Эти виртуальные соединения не подходят для серверов, если тайм-аут слишком длинный.
Контроль перегрузок
Когда большое количество данных подается в систему, которая не способна обрабатывать ее, происходит перегрузка. TCP управляет перегрузкой с помощью механизма Window. TCP устанавливает размер окна, говорящий на другом конце, сколько сегмента данных нужно отправить. TCP может использовать три алгоритма управления перегрузкой:
Управление таймером
TCP использует различные типы таймеров для управления и управления различными задачами:
Таймер сохранения:
Таймер повторной передачи:
Постоянный таймер:
Timed-Wait:
Восстановление после аварий
TCP — очень надежный протокол. Он предоставляет порядковый номер для каждого байта, отправленного в сегменте. Он обеспечивает механизм обратной связи, т.е. когда хост получает пакет, он привязан к ACK, чтобы ожидал пакет, имеющий следующий порядковый номер (если он не является последним сегментом).
Когда TCP-сервер прерывает связь в середине и перезапускает его процесс, он отправляет трансляцию TPDU всем своим хостам. Затем хосты могут отправить последний сегмент данных, который никогда не был непризнан и продолжен.
Протокол TCP
TCP или Transmission Control Protocol, используется как надежный протокол, обеспечивающий взаимодействие через взаимосвязанную сеть компьютеров. TCP проверяет, что данные доставляются по назначению и правильно.
— это ориентированный на соединения протокол, предназначенный для обеспечения надежной передачи данных между процессами, выполняемыми или на одном и том же компьютере или на разных компьютерах. Термин «ориентированный на соединения» означает, что два процесса или приложения прежде чем обмениваться какими-либо данными должны установить TCP-соединение. В этом TCP отличается от протокола UDP, являющегося протоколом «без организации соединения», позволяющим выполнять широковещательную передачу данных неопределенному числу клиентов.
Когда приложение отправляет данные, используя TCP, они перемещаются вниз по стеку протоколов. Данные проходят по всем уровням и в конце концов передаются через сеть как поток битов. Каждый уровень в наборе протоколов TCP/IP добавляет к данным некоторую информацию в форме заголовков.
Когда пакет прибывает на конечный узел в сети, он снова проходит через все уровни снизу доверху. Каждый уровень проверяет данные, отделяя от пакета свою информацию в заголовке и наконец данные достигают серверного приложения в той же самой форме, в какой они покинули приложение-клиент:
Прежде чем рассматривать, как TCP устанавливает соединение с другим хостом TCP, приведем несколько терминов, которые необходимо определить:
Сегмент
Порция данных, которую TCP отправляет IP, называется сегментом TCP.
Дейтаграмма
Порция данных, которую IP отправляет уровню сетевого интерфейса, называется дейтаграммой IP.
Порядковый номер
Каждый сегмент TCP, отправленный через соединение, имеет назначенное ему число, которое называется «порядковым номером» (sequence number). Оно используется, чтобы гарантировать прибытие данных в правильном порядке.
Чтобы понять, как работает TCP, вкратце рассмотрим структуру заголовка TCP:
Порядковые номера и номера подтверждений используются TCP, чтобы гарантировать, что все данные прибывают в правильном порядке, а биты управления содержат разнообразные флаги, указывающие статус данных. Таких битов управления (обычно представляемых трехбуквенными сокращениями) всего шесть:
URG — указывает, что сегмент содержит срочные данные.
ACK — указывает, что сегмент содержит номер подтверждения.
PSH — указывает, что данные нужно протолкнуть к получающему пользователю.
RST — сбрасывает соединение.
SYN — используется для синхронизации порядковых номеров.
FIN — указывает конец данных.
Для установления соединения TCP использует процесс, называемый «трехфазным квитированием» (Three-Phase Handshake). Как следует из названия, этот процесс включает три шага:
Клиент инициирует взаимодействие с сервером, посылая сегмент с установленным битом SYN. Этот сегмент содержит начальный порядковый номер клиента.
Сервер отвечает отправкой сегмента с установленными битами SYN и ACK. Этот сегмент содержит начальный порядковый номер сервера (не связанный с порядковым номером клиента) и номер подтверждения, на единицу больший порядкового номера клиента (т.е. равный следующему порядковому номеру, ожидаемому от клиента).
Клиент должен подтвердить этот сегмент отправкой обратно сегмента с установленным битом ACK. Номер подтверждения будет на единицу больше порядкового номера сервера, а порядковый номер будет равен номеру подтверждения сервера (т. е. на единицу больше начального порядкового номера клиента).
Теперь, узнав в общих чертах, как TCP устанавливает соединения, рассмотрим немного подробнее несколько операций TCP, чтобы понять, как TCP передает данные.
TCP использует порядковые номера, чтобы гарантировать, что дублирующие данные получающему приложению переданы не будут и данные будут доставлены в правильном порядке. Заголовок TCP содержит контрольную сумму, чтобы гарантировать корректность данных при доставке. Если получен сегмент с неверной контрольной суммой, он просто отбрасывается, и подтверждение не отправляется. Это означает, что, когда значение тайм-аута истечет, отправитель повторит передачу сегмента.
TCP управляет объемом направляемых ему данных, возвращая с каждым подтверждением «размер окна». «Окно» — это объем данных, который может принять получатель. Между прикладной программой и потоком данных в сети располагается буфер данных. «Размер окна» фактически представляет собой разность между размером буфера и объемом сохраненных в нем данных. Это число отправляется в заголовке, чтобы информировать удаленный хост о текущем размере окна. Такой прием называется «скользящим окном» («Sliding Window»).
На рисунке ниже показан алгоритм Sliding Window, управляющий потоком данных, передаваемых в сети:
Полученные данные сохраняются в этом буфере, и приложение может обращаться к буферу и считывать из него данные со свойственной ему скоростью. По мере того как приложение считывает данные, буфер опустошается и может принимать следующие данные, поступающие из сети.
Если приложение считывает данные из буфера слишком медленно, размер окна падает до нуля, и удаленный хост получает команду прекратить передачу данных. Как только локальное приложение обработает данные в буфере, размер окна возрастает и поступление данных из сета возобновляется. Если размер окна больше размера пакета, отправитель знает, что получатель может хранить одновременно несколько пакетов, что повышает производительность.
TCP дает возможность нескольким процессам на одной машине одновременно использовать сокет TCP. Сокет TCP состоит из адреса хоста и уникального номера порта, а TCP-соединение включает два сокета на разных концах сети. Порт может использоваться для нескольких соединений одновременно — один сокет на одном конце может использоваться для нескольких соединений с разными сокетами на другом конце. Примером этой ситуации служит Web-cepвep, слушающий порт 80 и отвечающий на запросы от нескольких компьютеров.
Протокол TCP №1
Многим знакома аббревиатура TCP, гораздо меньшее количество людей знает, что это протокол передачи данных. Но практически никто не знает, как он устроен.
Для тех кто остался:
Спецификация протокола TCP описана в RFC793. Рекомендую тебе ознакомится с этим документом, потому как хоть я и постараюсь повести до тебя самое важное, снабдив это важное соответствующими комментариями, которых ты не найдешь в мануале, но все же из-за малого объема и практического угла зрения, могу и упустить некоторые тонкости.
Данные, передаются в виде пакетов. Такая организация передачи означает, что данные, какого размера они ни были, разбиваются на отдельные фрагменты, которые формируются в пакеты (формирование пакетов предполагает, что к данным прибавляется служебный заголовок), после чего в виде пакетов данные передаются по сети (причем порядок передачи пактов может нарушаться). Принимающая система «собирает» из пакетов исходный массив данных на основании заголовков пакетов. Это не очень понятно, но только до тех пор, пока не рассмотрим структуру пакетов.
Поясню только самые важные места:
Контрольные биты- 6 бит (на схеме между reversed и window). Значения битов:
URG: поле срочного указателя задействовано
ACK: поле подтверждения задействовано
PSH: функция проталкивания
RST: перезагрузка данного соединения
SYN: синхронизация номеров очереди
FIN: нет больше данных для передачи
Думаю, для начала это все, что нужно, чтобы понять принцип работы протокола. Более подробно о значении остальных полей ты можешь прочитать в в RFC793. Ну а мы лучше разберем как же все-таки это работает на практике.
Когда мы хотим установить соединение, мы отправляем удаленной системе пакет следующей структуры:
20 53 52 43 00 00 44 45 53 54 00 00 08 00 45 00 00 2C C3 00 40 00 20 06 10 0C CB 5E FD BA CB 5E F3 47 04 07 00 17 00 0D 12 CB 00 00 00 00 60 02 20 00 D9 70 00 00 02 04 05 B4 2D
Получив наш пакет, удаленная система отвечает, что получила и готова установить соединение. Данные пакет выглядит так:
Как видишь, удаленная система дает понять, что получила наш пакет. Для этого она посылает нам ACK с номером «наш SYN+1». В добавок к этому удаленная система посылает нам свой SYN (мы же тоже будем отвечать). А ответ наш будет такой:
Думаю тебе уже должно быть все понятно. Если кто не понял, то пакет означает следующее: ваш пакет с SYN (758684758) получен, соединение установлено, наш SYN равен 856780.
Далее у нас идет обмен данными, т.е. то, для чего соединение и устанавливалось. Причем надо заметить, что на всех стадиях обеспечение сохранности данных, передаваемых с использованием протокола TCP, осуществляется следующим образом: посланный пакет помещается в буфер и если за определенное время от удаленной системы не приходит пакет с подтверждением (ACK), то пакет посылается снова; если же подтверждение пришло, то пакет считается посланным успешно и удаляется из буфера.
Подводя небольшие итоги вышеизложенному, отметим в каких же случаях изменяются/не изменяются порядковые номера:
Передача одного FIN Пакета = +1
Передача одного SYN Пакета = +1
Передача одного ACK Пакета = 0
Передача одного SYN/ACK Пакета = +1
Передача одного FIN/ACK Пакета = +1
Изменение за 1 секунду = +128,000
Установление одного соединения = +64,000
Возможно, кто-то спросит: «А что будет, если машин получит пакет с таким ACK, которого не было?» (SYN=ACK-1, а пакет с таким SYN мы не посылали). Получив ответ непонятно на что, мы в свою очередь ответим удаленной системе NACK-пакетом (означает «не знаю о чем ты», никакого соединения не устанавливается), но, надеюсь, более подробно мы поговорим с тобой об этом в следующий раз.
Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1
Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.
IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.
Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:
TCP обеспечивает нужную абстракцию сетевых соединений, чтобы приложениям не пришлось решать различные связанные с этим задачи, такие как: повторная передача потерянных данных, доставка данных в определенном порядке, целостность данных и тому подобное. Когда вы работаете с потоком TCP, вы знаете, что отправленные байты будут идентичны полученным, и что они придут в одинаковом порядке. Можно сказать, что TCP больше «заточен» на корректность доставки данных, а не на скорость. Этот факт создает ряд проблем, когда дело доходит до оптимизации производительности сайтов.
Стандарт НТТР не требует использования именно TCP как транспортного протокола. Если мы захотим, мы можем передавать НТТР через датаграммный сокет (UDP – User Datagram Protocol) или через любой другой. Но на практике весь НТТР трафик передается через TCP, благодаря удобству последнего.
Поэтому необходимо понимать некоторые внутренние механизмы TCP, чтобы оптимизировать сайты. Скорее всего, вы не будете работать с сокетами TCP напрямую в своем приложении, но некоторые ваши решения в части проектирования приложения будут диктовать производительность TCP, через который будет работать ваше приложение.
Тройное рукопожатие
Все TCP-соединения начинаются с тройного рукопожатия (рис. 1). До того как клиент и сервер могут обменяться любыми данными приложения, они должны «договориться» о начальном числе последовательности пакетов, а также о ряде других переменных, связанных с этим соединением. Числа последовательностей выбираются случайно на обоих сторонах ради безопасности.
Клиент выбирает случайное число Х и отправляет SYN-пакет, который может также содержать дополнительные флаги TCP и значения опций.
SYN ACK
Сервер выбирает свое собственное случайное число Y, прибавляет 1 к значению Х, добавляет свои флаги и опции и отправляет ответ.
Клиент прибавляет 1 к значениям Х и Y и завершает хэндшейк, отправляя АСК-пакет.
Рис. 1. Тройное рукопожатие.
После того как хэндшейк совершен, может быть начат обмен данными. Клиент может отправить пакет данных сразу после АСК-пакета, сервер должен дождаться АСК-пакета, чтобы начать отправлять данные. Этот процесс происходит при каждом TCP-соединении и представляет серьезную сложность плане производительности сайтов. Ведь каждое новое соединение означает некоторую сетевую задержку.
Например, если клиент в Нью-Йорке, сервер – в Лондоне, и мы создаем новое TCP-соединение, это займет 56 миллисекунд. 28 миллисекунд, чтобы пакет прошел в одном направлении и столько же, чтобы вернуться в Нью-Йорк. Ширина канала не играет здесь никакой роли. Создание TCP-соединений оказывается «дорогим удовольствием», поэтому повторное использование соединений является важной возможностью оптимизации любых приложений, работающих по TCP.
TCP Fast Open (TFO)
Загрузка страницы может означать скачивание сотен ее составляющих с разных хостов. Это может потребовать создания браузером десятков новых TCP-соединений, каждое из которых будет давать задержку из-за хэндшейка. Стоит ли говорить, что это может ухудшить скорость загрузки такой страницы, особенно для мобильных пользователей.
TCP Fast Open (TFO) – это механизм, который позволяет снизить задержку за счет того, что позволяет отправку данных внутри SYN-пакета. Однако и у него есть свои ограничения: в частности, на максимальный размер данных внутри SYN-пакета. Кроме того, только некоторые типы HTTP-запросов могут использовать TFO, и это работает только для повторных соединений, поскольку использует cookie-файл.
Использование TFO требует явной поддержки этого механизма на клиенте, сервере и в приложении. Это работает на сервере с ядром Linux версии 3.7 и выше и с совместимым клиентом (Linux, iOS9 и выше, OSX 10.11 и выше), а также потребуется включить соответствующие флаги сокетов внутри приложения.
Специалисты компании Google определили, что TFO может снизить сетевую задержку при HTTP-запросах на 15%, ускорить загрузку страниц на 10% в среднем и в отдельных случаях – до 40%.
Контроль за перегрузкой
В начале 1984 года Джон Нейгл описал состояние сети, названное им как «коллапс перегрузки», которое может сформироваться в любой сети, где ширина каналов между узлами неодинакова.
Когда круговая задержка (время прохождения пакетов «туда-обратно») превосходит максимальный интервал повторной передачи, хосты начинают отправлять копии одних и тех же датаграмм в сеть. Это приведет к тому, что буферы будут забиты и пакеты будут теряться. В итоге хосты будут слать пакеты по нескольку раз, и спустя несколько попыток пакеты будут достигать цели. Это называется «коллапсом перегрузки».
Нейгл показал, что коллапс перегрузки не представлял в то время проблемы для ARPANETN, поскольку у узлов была одинаковая ширина каналов, а у бэкбона (высокоскоростной магистрали) была избыточная пропускная способность. Однако это уже давно не так в современном интернете. Еще в 1986 году, когда число узлов в сети превысило 5000, произошла серия коллапсов перегрузки. В некоторых случаях это привело к тому, что скорость работы сети падала в 1000 раз, что означало фактическую неработоспособность.
Чтобы справиться с этой проблемой, в TCP были применены несколько механизмов: контроль потока, контроль перегрузки, предотвращение перегрузки. Они определяли скорость, с которой данные могут передаваться в обоих направлениях.
Контроль потока
Контроль потока предотвращает отправку слишком большого количества данных получателю, которые он не сможет обработать. Чтобы этого не происходило, каждая сторона TCP-соединения сообщает размер доступного места в буфере для поступающих данных. Этот параметр — «окно приема» (receive window – rwnd).
Когда устанавливается соединение, обе стороны задают свои значения rwn на основании своих системных значений по умолчанию. Открытие типичной страницы в интернете будет означать отправку большого количества данных от сервера клиенту, таким образом, окно приема клиента будет главным ограничителем. Однако, если клиент отправляет много данных на сервер, например, загружая туда видео, тогда ограничивающим фактором будет окно приема сервера.
Если по каким-то причинам одна сторона не может справиться с поступающим потоком данных, она должна сообщить уменьшенное значение своего окна приема. Если окно приема достигает значения 0, это служит сигналом отправителю, что не нужно более отправлять данные, пока буфер получателя не будет очищен на уровне приложения. Эта последовательность повторяется постоянно в каждом TCP-соединении: каждый АСК-пакет несет в себе свежее значение rwnd для обеих сторон, позволяя им динамически корректировать скорость потока данных в соответствии с возможностями получателя и отправителя.
Рис. 2. Передача значения окна приема.
Масштабирование окна (RFC 1323)
Исходная спецификация TCP ограничивала 16-ю битами размер передаваемого значения окна приема. Это серьезно ограничило его сверху, поскольку окно приема не могло быть более 2^16 или 65 535 байт. Оказалось, что это зачастую недостаточно для оптимальной производительности, особенно в сетях с большим «произведением ширины канала на задержку» (BDP – bandwidth-delay product).
Чтобы справиться с этой проблемой в RFC 1323 была введена опция масштабирования TCP-окна, которая позволяла увеличить размер окна приема с 65 535 байт до 1 гигабайта. Параметр масштабирования окна передается при тройном рукопожатии и представляет количество бит для сдвига влево 16-битного размера окна приема в следующих АСК-пакетах.
Сегодня масштабирование окна приема включено по умолчанию на всех основных платформах. Однако промежуточные узлы, роутеры и сетевые экраны могут переписать или даже удалить этот параметр. Если ваше соединение не может полностью использовать весь канал, нужно начать с проверки значений окон приема. На платформе Linux опцию масштабирования окна можно проверить и установить так:
В следующей части мы разберемся, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.