предисловие

От небольших до сетевых разработок на уровне приложений, от больших до вездесущей сети в жизни. Пока мы наслаждаемся этим удобством, никого не волнует, как строится такой прочный базовый фундамент. Очень важной частью этих краеугольных камней является протокол TCP. Глядя на «Три рукопожатия» и «Четыре волны», я подумал, что это TCP, но это не так. Это решает только проблему подключения и закрытия, проблема передачи является более важной, сложной и сложной проблемой протокола tcp. Оглядываясь назад на принцип протокола tcp, мы обнаружим, что для того, чтобы обещать «надежность» передачи данных верхнего уровня, я не знаю, сколько сложных и изменчивых ситуаций в сети приходится иметь дело. Если говорить просто и прямо:

• Как убедиться, что данные достоверны? --- Соединение подтверждено! Закрыть для подтверждения! Получено подтверждение данных! Различные подтверждения! !
• Что делать, если другая сторона не может получить данные из-за сетевых или других причин? --Повторить попытку после тайм-аута
• Ситуация в сети постоянно меняется, как определить время ожидания? --Динамический расчет на основе RTT
• Что делать, если сеть перегружена из-за повторяющихся и неустанных повторных попыток? --- Медленный старт, предотвращение перегрузки, быстрая повторная передача, быстрое восстановление
• Что делать, если скорость отправки и скорость получения не совпадают? --Раздвижное окно
• В процессе сдвига окна он все твердил мне, что я не справлюсь, и что мне делать, если я не разрешаю передачу данных? --ЗВП
• В процессе скольжения скользящего окна его обработка происходит медленно, и само собой разумеется, что я каждый раз отправляю небольшой объем данных, что приводит к низкому использованию сети.Что мне делать? --- Нэгл

Любая из этих маленьких ссылок объединяет бесчисленное множество алгоритмов.У нас нет возможности понять реализацию каждого алгоритма, но нам нужно понять процесс мышления разработчиков tcp.

Разобрав весь контент, вы, вероятно, сможете узнать:

Какие механизмы обеспечивает tcp для обеспечения надежности передачи данных?

Что представляет собой процесс «трехстороннего рукопожатия» и закрытой «четырехсторонней волны» tcp-соединения?

Как меняется состояние при подключении и закрытии tcp?

Что такое поля в заголовке tcp и для чего они используются?

Что такое протокол скользящего окна TCP?

Каков механизм повторной передачи тайм-аута?

Как избежать перегруженности передачи?

I. Обзор

1. Характеристики tcp соединения

• Обеспечьте ориентированную на соединение надежную службу потока байтов
• Предоставлять услуги для верхнего прикладного уровня, не заботясь о том, что представляет собой конкретный передаваемый контент, и не зная, является ли это двоичным потоком или символами ascii.

2. Как обеспечить надежность tcp

• Передача по частям: данные делятся наСамый подходящийБлок данных (длина дейтаграммы UDP не меняется)
• Ожидание подтверждения: подождите, пока получатель отправит запрос подтверждения через таймер, и повторите отправку, если подтверждение не получено.
• Ответ с подтверждением: отправка ответа с подтверждением при получении подтверждения (не сразу, обычно с задержкой на доли секунды).
• Проверка данных: сохраните контрольную сумму заголовка и данных и определите, есть ли какие-либо изменения в процессе передачи данных.
• Сортировка вне порядка: получатель может изменить порядок данных и доставить их приложению в правильном порядке.
• Повторяющееся удаление: получатель может отбрасывать повторяющиеся пакеты.
• Буфер трафика: на обоих концах есть буферы фиксированного размера (скользящие окна) для предотвращения потери данных из-за несоответствия скорости.

3. Формат заголовка tcp

3.1 Позиция макроса

• С уровня приложения -> транспортный уровень -> сетевой уровень -> канальный уровень соответствующий заголовок будет добавляться к сообщению каждый раз, когда оно передается.Обратитесь к предыдущей статье http протокол
• Данные TCP инкапсулируются в дейтаграммы IP.

3.2 Формат заголовка

• Данные заголовка tcp обычно содержат 20 байт (исключая необязательные поля).
• Два байта 1-2: номер исходного порта
• Два байта 3-4: номер порта назначения

  Номер порта источника + IP-адрес источника в заголовке ip + номер порта назначения + IP-адрес назначения в заголовке ip однозначно определяют TCP-соединение. Сокет, соответствующий уровню кодирования.

• Четыре байта 5-8: 32-битный порядковый номер. tcp обеспечивает полнодуплексный сервис, и оба конца имеют свои собственные серийные номера.No.: Решить проблему с неупорядоченными сетевыми пакетами

  Как сгенерировать серийный номер: он не может быть исправлен и мертв, иначе повторное использование серийного номера будет испорчено при отключении и повторном подключении сети. tcp генерирует порядковый номер на основе часов, который увеличивается на единицу каждые 4 микросекунды и начинается с 0, когда достигает 2^32-1.

• Четыре байта 9-12: 32-битный серийный номер подтверждения. Порядковый номер последнего успешно полученного байта данных плюс 1, подтверждение равно 1, чтобы быть действительным.Номер подтверждения: решить проблему потери пакетов
• 13-й байт: длина заголовка. Поскольку необязательное поле имеет переменную длину
• Задний 6 прикус: зарезервировано
• Затем 6bite: идентификационный бит.контролировать различные состояния
• Два байта 15-16: размер окна. Количество байтов, которое ожидает получить получатель.Решить проблему управления потоком
• Два байта 17-18: контрольная сумма. Рассчитывается и сохраняется отправителем и проверяется получателем.Устранение проблем с правильностью данных
• Два байта 19-20: аварийный указатель

3.3 Описание идентификационного бита

• URG: когда он равен 1, это означает, что аварийный указатель действителен.
• ACK: Идентификатор подтверждения, всегда 1 после успешного установления соединения. Когда он равен 1, номер подтверждения действителен.
• PSH: получатель должен как можно скорее передать это сообщение прикладному уровню.
• RST: сбросить флаг, переподключиться
• SYN: Когда устанавливается новое соединение, этот бит равен 0.
• FIN: закрыть идентификатор соединения

3.4 формат опций tcp

• Каждая опция начинается с 1-байтового поля вида, указывающего тип опции.
• Опции вида 0 и 1 занимают только один байт
• После другого вида стоит байт len, указывающий общую длину опции (включая тип и длину).
• вид 11, 12, 13 означает транзакцию tcp

3.5 Максимальный размер пакета MSS

• Наиболее распространенные необязательные поля
• MSS может появиться только во время SYN (первое рукопожатие и второе рукопожатие)
• Указывает максимальную длину сегмента, который может получить локальный конец.
• При установлении соединения обе стороны отправляют MSS
• Если не отправлено, по умолчанию 536 байт.

2. Установление и разъединение соединения

1. «Трехстороннее рукопожатие» для установления соединения

1.1 Процесс трехстороннего рукопожатия

• Клиент отправляет SYN, чтобы указать, что соединение с сервером должно быть установлено. Также укажите серийный номер ISN
• Сервер возвращает ACK (порядковый номер равен порядковому номеру клиента + 1) в качестве подтверждения. При этом в качестве ответа отправляется SYN (серийный номер SYN — это уникальный серийный номер сервера)
• Клиент отправляет ACK, чтобы подтвердить получение ответа (серийный номер — это серийный номер сервера + 1).

1.2 Почему трехстороннее рукопожатие

• Соединения TCP являются полнодуплексными, и данные могут передаваться в обоих направлениях одновременно.
• так чтоУбедитесь, что обе стороны могут отправлять и получать данные одновременно
• Первое рукопожатие: доказывает, что отправитель может отправлять данные
• Второе рукопожатие: ack гарантирует, что получатель может получать данные, а syn гарантирует, что получатель может отправлять данные.
• Третье рукопожатие: гарантирует, что отправитель может получить данные
• По сути, это четырехмерный обмен информацией, но два промежуточных шага сливаются в рукопожатие.
• Четыре рукопожатия расточительны, а два рукопожатия не могут гарантировать, что «обе стороны имеют функцию отправки и получения одновременно».

2. «Четыре волны» закрытия связи

2.1 Зачем махать четыре раза

• Поскольку соединения tcp являются полнодуплексными, данные могут передаваться в обоих направлениях одновременно.
• В то же время tcp поддерживает полузакрытие (функция, при которой отправитель все еще может получить данные после завершения отправки).
• Следовательно, каждое направление должно быть закрыто отдельно, а для получения уведомления об отношениях необходимо отправить ответ с подтверждением.

2.2 Зачем поддерживать полузакрытие

• Клиент должен уведомить сервер о том, что его данные были переданы
• Пока все еще получаю данные с сервера
• Использование полузакрытого одиночного соединения более эффективно, чем использование двух tcp-соединений.

2.3 Процесс четырехстороннего рукопожатия

• Сторона, которая активно закрылась, отправляет FIN, указывая на то, что она хочет в одностороннем порядке закрыть передачу данных.
• После того, как сервер получает FIN, он отправляет ACK в качестве подтверждения (серийный номер равен полученному серийному номеру + 1).
• Когда передача данных сервера завершена, также отправляется флаг FIN, указывающий, что передача данных в этом направлении закрыта.
• Клиент отвечает ACK, чтобы подтвердить ответ

3. Подключить и закрыть соответствующее состояние

3.1 Описание состояния

• Когда сервер ожидает подключения клиента, он находится в состоянии прослушивания Listen.
• Клиент активно открывает запрос и находится в состоянии отправки SYN_SENT при отправке SYN.
• Когда клиент получает синхронизацию и подтверждение и отвечает подтверждением, он находится в состоянии «Установлено» и ожидает отправки сообщения.
• После того, как сервер получает подтверждение подтверждения, он также находится в состоянии «Установлено» и ожидает отправки сообщения.
• После того, как клиент отправляет fin, он находится в состоянии fin_wait_1.
• Когда сервер получает fin и отправляет ack, он находится в состоянии close_wait.
• После того, как клиент получает подтверждение подтверждения, он находится в состоянии fin_wait_2.
• После того, как сервер отправляет fin, он находится в состоянии last_ack
• Клиент отправляет подтверждение после получения fin и находится в состоянии time_wait.
• После того, как сервер получил акк, он находится в закрытом состоянии

3.2 статус time_wait

• Также известное как состояние ожидания 2MSL, MSL = Максимальное время жизни сегмента, максимальное время жизни сегмента, которое устанавливается само по себе в соответствии с различными реализациями tcp. Распространенные значения: 30 с, 1 мин, 2 мин. Линукс вообще 30-ки.
• Состояние, в котором активно закрывающаяся сторона отправила последний акк
• Это состояние должно поддерживаться в течение времени ожидания 2MSL.

3.2.1 Зачем это нужно?

• Представьте себе сценарий, когда в итоге акк теряется, а получатель его не получает
• В это время получатель повторно отправит плавник отправителю.
• Это время ожидания должно предотвратить это и позволить отправителю повторно отправить подтверждение.
• Резюме: зарезервируйте достаточно времени, чтобы получатель получил подтверждение. В то же время убедитесь, что это соединение не будет мешать последующим соединениям (некоторые маршрутизаторы кэшируют пакеты).

3.2.2 Каковы последствия этого?

• В течение этого времени ожидания 2MSL соединение (сокет, ip+порт) не будет использоваться.
• Много раз Linux сообщает о слишком большом количестве открытых файлов, говоря, что портов не хватает, поэтому необходимо проверить, не создается ли в некоторых кодах большое количество сокетных соединений, и эти сокетные соединения не освобождаются сразу после закрытия.
• Когда клиент подключается к серверу, порт клиента обычно не указывается. Поскольку клиент закрывается, а затем сразу же запускается, теоретически он выдаст сообщение о том, что порт занят. Точно так же активное выключение сервера и его немедленный запуск в течение 2MSL сообщит об ошибке, что порт занят
• В случае нескольких одновременных коротких подключений появится большое количество состояний Time_wait. Эти два параметра могут решить проблему, но это нарушает протокол tcp и является рискованным. Параметры: tcp_tw_reuse и tcp_tw_recycle.
• Если это разработка на стороне сервера, вы можете установить keep-alive, чтобы позволить клиенту активно закрывать соединение для решения этой проблемы.

4. Сбросить сегмент

Сегмент отправляется с адреса источника на адрес назначения. Если есть ошибка, будет отправлен сегмент сброса. RST поля заголовка используется для «сброса». К этим ошибкам относятся следующие

• Порт не слушает
• Прервать: прервать соединение, отправив RST вместо fin

5. Открыть одновременно

• Два приложения выполняют активное открытие одновременно, что называется «одновременным открытием».
• Это редко случается
• Оба конца отправляют SYN одновременно и одновременно входят в состояние SYN_SENT.
• Откройте одно соединение вместо двух
• Чтобы выполнить процесс обмена четырьмя сообщениями, «четырехстороннее рукопожатие»

6. Одновременное отключение

• Обе стороны выполняют активное отключение одновременно
• Выполните четыре обмена сообщениями
• Статус отличается от обычного завершения работы

7. Сервер обрабатывает параллельные запросы

• Конец, ожидающий подключения, имеет очередь фиксированной длины (длина называется «значением отставания», которое в большинстве случаев равно 5).
• Соединение в очереди: трехстороннее рукопожатие было завершено, но оно не было получено прикладным уровнем (прикладному уровню необходимо дождаться получения последнего подтверждения, прежде чем узнать об этом соединении)
• Прикладной уровень получает запрошенное соединение и будет удален из очереди.
• Когда поступает новый запрос, сначала оцените ситуацию в очереди, чтобы решить, принимать ли соединение.
• Значение значения отставания: максимальное значение, которое конечные точки, прослушивающие tcp, получили по tcp, но ожидают получения прикладным уровнем. Независимо от максимального количества подключений, разрешенных системой, максимальное количество параллелизма, полученное сервером

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

1. Классификация данных TCP-передачи

• Передача данных заблокирована: большой объем, сегменты часто переполнены
• Интерактивная передача данных: небольшой объем, сегменты пакетов представляют собой крошечные пакеты, большое количество крошечных пакетов, передача в глобальной сети увеличит возникновение перегрузок
• TCP обрабатывает два типа данных, которые имеют разные характеристики и требуют разных технологий передачи.

2. Технология передачи данных взаимодействия

2.1 Задержка подтверждения

• Концепция: когда tcp получает данные, он не отправляет подтверждение подтверждения немедленно, а отправляет его позже.
• Цель: отправить подтверждение с данными, которые необходимо отправить в этом направлении, чтобы уменьшить накладные расходы.
• Особенности: Получателю не нужно подтверждать каждый полученный пакет, Ack является кумулятивным, что означает, что получатель правильно принял все байты до порядкового номера подтверждения -1
• Время задержки: большинство из них составляет 200 мс. не может превышать 500 мс

2.2 Алгоритм Нэгла

• Какую проблему решить: крошечные пакеты вызывают проблемы с перегрузкой в ​​глобальной сети
• Ядро: уменьшено количество небольших пакетов, передаваемых по глобальной сети.
• Принцип: требуется, чтобы в tcp-соединении мог быть только один неподтвержденный неполный пакет, и никакие другие пакеты не могли быть отправлены, пока не придет подтверждение пакета. tcp собирает эти пакеты и отправляет их как пакет до того, как придет подтверждение
• Плюсы: адаптивный. Чем быстрее приходит подтверждение, тем быстрее отправляются данные. Подтверждения медленные, отправка меньшего количества групп.
• Примечание по использованию. Этот алгоритм редко используется в локальных сетях. И в некоторых особых сценариях нужно отключать алгоритм

3. Передача фрагментированных данных

• В основном с использованием протокола скользящего окна

4. Протокол скользящего окна

1 Обзор

• Какая проблема решается: при несовпадении скоростей отправителя и получателя, проблема обеспечения надежной передачи и неупорядоченных пакетов
• Механизм: В соответствии с текущим размером буфера получатель уведомляет отправителя о текущем максимальном значении, которое может быть получено. Отправитель отправляет данные в соответствии с возможностями обработки получателя. Благодаря этому механизму координации получатель не может справиться с этим.
• Размер окна: значение, отправляемое получателем отправителю, называется размером окна.

2. Структура данных tcp-буфера

• Приемный конец:
  • LastByteRead: позиция, в которую был прочитан буфер.
  • NextByteExpected: последняя позиция полученного последовательного пакета.
  • LastByteRcvd: последняя позиция полученного пакета.
  • Средняя пустая область: данные не поступили
• отправитель:
  • LastByteAcked: позиция подтверждения, полученного принимающей стороной, что указывает на то, что подтверждение было успешно отправлено.
  • LastByteSent: отправлено, но не получено подтверждения об успешном подтверждении
  • LastByteWritten: куда пишет верхнее приложение

3. Принципиальная схема раздвижного окна

3.1 Исходная принципиальная схема

• Черные ящики представляют собой скользящие окна.
• #1 указывает, что данные, подтвержденные ack, получены
• #2 указывает на то, что данные подтверждения не были получены
• #3 означает, что сообщение не было отправлено в окне (у получателя еще есть место)
• #4 Данные за окном (в приемнике нет места)

3.2 Принципиальная схема процесса скольжения

• Получил подтверждение 36 и отправил байты 46-51

4. Окно перегрузки

• Какая проблема решена: Отправитель отправляет слишком быстро, вызывая перегрузку на транзитном маршрутизаторе
• Механизм: отправитель добавляет окно перегрузки (cwnd), и каждый раз, когда он получает подтверждение, значение окна увеличивается на 1. При отправке возьмите окно перегрузки и размер окна, отправленного получателем, чтобы взять минимальное значение для отправки.
• Играет роль управления потоком отправителя

5. Проблемы, вызванные раздвижными окнами

5.1 Нулевое окно

• Как это происходит: получатель медленно обрабатывает, а отправитель быстро отправляет. Размер окна медленно регулируется до 0
• Как исправить: технология ZWP. Отправьте пакет zwp получателю и позвольте получателю подтвердить свой размер окна.

5.2 Синдром запутанного окна

• Как это происходит: получатель слишком занят, чтобы получить все данные, в результате чего отправитель становится все меньше и меньше. Наконец, пусть отправитель передает только несколько байтов данных.
• Недостатки: данные намного меньше, чем заголовки tcp и ip, а использование сети слишком низкое.
• Как исправить: не реагируйте на маленькие размеры окон.
  • Отправитель: упомянутый выше алгоритм Нэгла.
  • Получатель: если размер окна меньше определенного значения, подтвердите (0) напрямую, чтобы предотвратить отправку данных. Репост после увеличения окна.

5. Тайм-аут и повторная передача

1 Обзор

• tcp обеспечивает надежный транспортный уровень, используемый метод является механизмом подтверждения.
• Но и данные, и подтверждения могут быть потеряны
• tcp решает эту проблему, устанавливая таймер при отправке
• Когда таймер истекает, а подтверждение не получено, данные будут переданы повторно

2. Типы таймеров, управляемые tcp

• Таймер повторной передачи: дождитесь подтверждения
• Persistence Timer: поддерживает поток информации о размере окна
• Keep-alive timer: обнаруживает сбои или перезапуски бездействующего соединения
• Таймер 2MSL: определение статуса time_wait

3. Механизм повторной передачи тайм-аута

3.1 Предыстория

• Подтверждение подтверждения от получателя к отправителю подтвердит только последний последовательный пакет
• Например, при отправке 1, 2, 3, 4 и 5 всего пяти фрагментов данных принимающая сторона получает 1, 2, поэтому возвращает ack3, а затем получает 4 (3 не было получено), в этот момент время, tcp не будет пропускать 3 и напрямую подтвердит 4, иначе отправитель думает, что 3 также было получено. Что вы можете придумать в этот момент? Как обрабатывается tcp?

3.1 Стратегия повторной передачи пассивного тайм-аута ожидания

• Интуитивный метод таков: получатель ничего не делает, ждет, пока отправитель истечет, а затем повторяет передачу.
  • Недостаток: отправитель не знает, отправить ли повторно 3 или повторно отправить 3,4,5
• Если отправитель отправляет только 3: сохранить ширину, но медленно
• Если отправитель отправляет 3,4,5: быстро, но тратит пропускную способность
• Короче говоря, они пассивно ждут тайм-аута, который может быть очень долгим. Так что tcp не использует этот метод

3.2 Активный механизм быстрой повторной передачи

3.2.1 Обзор

• Название: Быстрая повторная передача
• Не фактическая управляемая, а управляемая данными повторная передача

3.2.2 Принцип реализации

• Если пакет не доставлен, он всегда будет подтверждать последний пакет, который может быть потерян.
• Если отправитель получит 3 одинаковых подтверждения подряд, он повторит передачу. Не ждите таймаута

  

• 1,2,3,4,5 данные встречаются на рисунке
• Приходят данные 1, происходит ack2
• Данные 2 не были доставлены по какой-то причине
• Когда впоследствии получено 3, получатель не получает ни ack4, ни ожидания. но активен ack2
• Получил 4,5 по той же причине всегда проявляю инициативу на ack2
• Клиент получает три ACK2, возвращая 2
• 2 После получения, 3, 4, 5, полученные непосредственно перед, непосредственно ACK6

3.2.3 Плюсы и минусы быстрой ретрансляции

• Решена проблема пассивного ожидания тайм-аута
• Не удалось исправить предыдущую или все проблемы с повторной передачей.
• В приведенном выше примере нужно ли повторно передать 2 или повторно передать 2,3,4,5. Потому что непонятно, кто отправил ack2 обратно

3.3 Метод SACK

3.3.1 Обзор

• Чтобы устранить недостаток быстрой повторной передачи, предлагается лучшая стратегия повторной передачи SACK.
• На основе быстрой повторной передачи с одновременным добавлением SACK в заголовок tcp
• Какая проблема решена: вопрос о том, какие пакеты таймаута должен отправлять клиент

3.3.2 Принцип реализации

• SACK записывает диапазон значений, указывающих, какие данные были получены
• После linux2.4 эта функция включена по умолчанию, в предыдущих версиях необходимо настроить параметр tcp-sack.
• SACK — это только вспомогательный способ, отправитель не может полностью полагаться на SACK. В основном зависит от ACK и таймаута

3.3.3 Duplicate SACK(D-SACK)

• Используя диапазон идентификатора SACK, вы также можете сообщить отправителю, какие данные были получены повторно.
• Он может сообщить отправителю: потерян ли исходящий пакет или возвращенный пакет подтверждения.

4. Определение тайм-аута

4.1 Предыстория

• Маршрутизаторы и сетевой трафик различаются
• Таким образом, тайм-аут не должен быть установлен на фиксированное значение
• Длительный тайм-аут: медленная повторная передача, низкая эффективность, низкая производительность.
• Короткий тайм-аут: повторная передача без потерь, вызывающая перегрузку сети, что приводит к большему количеству тайм-аутов и повторных передач.
• tcp будет отслеживать эти изменения и соответствующим образом динамически изменять время ожидания (RTO).

4.2 Как измениться динамически

• Временной интервал каждой повторной передачи удваивается по сравнению с последней, пока максимальный интервал не составит 64 с, что называется «экспоненциальным отставанием».
• Интервал времени от первой повторной передачи до последней повторной передачи обычно составляет 9 минут.
• Расчеты, основанные на прошлых расчетах времени приема-передачи (RTT)

4.3 Расчет времени приема-передачи (RTT)

• Это не просто разница между временем подтверждения и временем отправки. Потому что существуют различные факторы, такие как повторная передача, перегрузка сети и так далее.
• Вместо этого путем многократной выборки значения и последующей оценки
• Методы, используемые tcp:
  • Сглаженный оценщик RTT
  • Оценщик сглаженного среднего отклонения

4.4 Конкретный расчет времени ретрансляции

• Рассчитать время прохождения туда и обратно (RTT), сохранить измерения
• Поддерживать сглаженную оценку RTT и сглаженную оценку среднего отклонения от измерений
• Рассчитайте время следующей повторной передачи на основе этих двух оценок.

5. Проблемы, вызванные повторной передачей тайм-аута - перегрузка

5.1 Почему ретрансляция вызывает перегрузку

• tcp повторно передает данные, когда сетевая задержка внезапно увеличивается
• Однако слишком много повторных передач увеличит нагрузку на сеть, что приведет к большей задержке и потере пакетов и попадет в порочный круг.
• То есть проблема перегрузки tcp

5.2 Алгоритмы решения управления перегрузкой-перегрузкой

• Медленный старт: снижает скорость, с которой пакеты входят в сеть.
• Предотвращение перегрузки: алгоритмы обработки потерянных пакетов
• быстрая ретрансляция
• быстрое восстановление

6. Другие таймеры

1. Придерживайтесь таймера

1.1 Настаивайте на значении существования таймера

• Когда размер окна равен 0, получатель отправит подтверждение без данных и только с размером окна.
• Но что произойдет, если этот акк будет потерян? Обе стороны могут разорвать соединение из-за ожидания
• Таймер сохраняемости периодически спрашивает получателя, было ли увеличено окно. Эти исходящие сегменты называются оконными зондами.

1.2 Соблюдайте время запуска таймера

• Отправитель уведомляется о том, что размер окна получателя равен 0

1.3 То же самое и отличие от повторной передачи по тайм-ауту

• То же: тот же интервал повторной передачи
• Различие: оконные зонды никогда не прекращают отправку до тех пор, пока окно не будет открыто или процесс не будет закрыт. И ретрансляция откажется через определенный промежуток времени.

2. Таймер поддержания активности

2.1 Значение существования таймера проверки активности

• Как сервер определяет, жив ли клиент, когда нет передачи данных по tcp

Ссылаться на

• «Подробности tcp / ip, том 1: протокол»
• классная оболочка.cai/articles/11…
• классная оболочка.cai/articles/11…