Обзор транспортного уровня

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

UDP (протокол пользовательских дейтаграмм) Подробное объяснение

Особенности УДП

UDP добавляет лишь несколько функций на основе служб IP-дейтаграмм: мультиплексирование и демультиплексирование, а также обнаружение ошибок для всего сообщения.
UDP не требует подключения Нет необходимости устанавливать соединение перед обменом данными, и нет необходимости разрывать соединение после завершения обмена данными.
UDP ненадежен Это наилучшая доставка, и она не может гарантировать, что каждая дейтаграмма будет доставлена.
UDP ориентирован на пакеты Так называемый «ориентированный на сообщения» означает, что единицей передачи данных UDP является сообщение, и над данными не выполняются операции разделения и объединения. На стороне отправителя, какие данные приложение передает в UDP транспортного уровня, UDP не будет разделять данные, только добавит заголовок UDP и передаст его сетевому уровню. На принимающей стороне, после того как UDP получает дейтаграмму сетевого уровня, он удаляет заголовок дейтаграммы IP и передает его на прикладной уровень без какой-либо операции сплайсинга.
UDP не контролирует перегрузку UDP всегда отправляет данные с постоянной скоростью и не регулирует скорость отправки в зависимости от перегрузки сети. В этом подходе есть плюсы и минусы. Недостаток: некоторые пакеты могут быть потеряны, когда сеть перегружена, поэтому UDP ненадежен. Преимущества: некоторые сценарии использования допускают потерю пакетов, например, прямая трансляция и голосовые вызовы, но требования к реальному времени очень высоки.В настоящее время UDP все еще очень полезен.
UDP поддерживает связь «один к одному», «один ко многим», «многие ко многим» и «многие к одному». А TCP поддерживает только индивидуальную связь.
Заголовок UDP невелик, всего 8 байт. Заголовок TCP имеет размер не менее 20 байт, что намного эффективнее, чем TCP.

PS: В: Каковы конкретные аспекты ненадежности UDP? Дейтаграмма потеряна? Порядок дейтаграмм?

UDP-заголовок

исходный порт
порт назначения
длина: длина всей дейтаграммы
Контрольная сумма: контрольная сумма всей дейтаграммы.

Подробное объяснение TCP (протокола управления передачей)

Функции TCP

TCP ориентирован на соединение Соединение должно быть установлено до связи, а соединение должно быть разорвано после окончания связи.
TCP предоставляет надежные услуги доставки Так называемый «надежный» означает, что данные, отправляемые TCP, не имеют дублирования, потерь, ошибок и находятся в том же порядке, что и отправитель.
TCP ориентирован на байты Так называемый «байт-ориентированный поток» означает: TCP использует байты в качестве единицы измерения. Хотя в процессе передачи данные разделяются на дейтаграммы, это делается только для удобства передачи, и данные, окончательно полученные принимающей стороной, будут точно такими же, как данные на передающей стороне.
TCP обеспечивает полнодуплексную связь Так называемая «полнодуплексная связь» означает, что оба конца TCP могут использоваться как отправители и получатели.
На обоих концах TCP-соединения может быть только две конечные точки. TCP может обеспечивать только двухточечную связь, в то время как UDP может взаимодействовать любым способом.

TCP-соединения и сокеты

Что такое «TCP-соединение»? TCP-соединение — это абстрактное понятие, представляющее канал, по которому можно обмениваться данными. Каждое соединение TCP имеет одну и только две конечные точки, представляющие обе стороны соединения. А двойную передачу можно использовать как отправителя и получателя в любое время.
Что такое "розетка"? Два конца соединения TCP — это два сокета. socket=IP-адрес:номер порта. Итак, TCP-соединение = (сокет 1, сокет 2) = (IP1: номер порта 1, IP2: номер порта 2)

TCP-заголовок

Длина заголовка TCP имеет фиксированную часть 20 байт, а длина части опций является переменной, но не более 40 байт, поэтому заголовок TCP составляет от 20 до 60 байт.

исходный порт и порт назначения Важное различие между транспортным уровнем и сетевым уровнем заключается в том, что транспортный уровень определяет прикладной процесс, которому отправляется дейтаграмма, поэтому требуется идентификация номера порта.
серийный номер Порядковый номер первого байта части данных текущей дейтаграммы TCP. Мы знаем, что TCP ориентирован на байты, он нумерует каждый отправленный байт, а различные дейтаграммы нумеруются последовательно. Поскольку это поле 4 байта, можно пронумеровать [0,2^32-1] байт (около 4G), а серийный номер используется циклически, при отправке 2^32-1 байт серийный номер будет начинаться с 0 снова. Вообще говоря, когда отправляется 2^32-1 байт, предыдущие байты уже были отправлены успешно, поэтому порядковый номер можно использовать циклически.
Номер подтверждения Указывает номер следующего байта, который ожидается получить, когда текущий хост является получателем. Также указывает, что текущий хост имеетправильныйПоследний байтовый порядковый номер получил +1.
Смещение данных (длина пакета) Он указывает длину заголовка дейтаграммы.
зарезервированный текст
идентификатор TCP имеет 7 видов идентификаторов, которые используются для указания характера TCP-пакетов. Они могут быть только 0 или 1.

URG=1 Когда в поле URG установлено значение 1, это означает, что часть данных этой дейтаграммы содержит срочную информацию, и указатель срочности в это время действителен. Срочные данные должны располагаться в начале части данных текущего пакета данных, а указатель срочных данных указывает на конец срочных данных. Например, control+c: эта команда просит операционную систему немедленно остановить текущий процесс. В это время эта команда будет сохранена в начале части данных пакета данных, а позиция команды идентифицируется указателем срочности, а поле URG установлено на 1.
ПОДТВЕРЖДЕНИЕ=1 Поле номера подтверждения действительно только после того, как для ACK установлено значение 1. Кроме того, TCP указывает, что все сегменты, передаваемые после установления соединения, должны иметь значение ACK, равное 1.
ПШ=1 Когда получатель получает сообщение с PSH=1, он немедленно доставляет данные приложению, не дожидаясь заполнения буфера перед отправкой. Некоторым интерактивным приложениям требуется такая функциональность, что сокращает время отклика на команду.
РСТ=1 Когда значение равно 1, это означает, что с текущим TCP-соединением возникла серьезная проблема, и переподключение должно быть разорвано.
СИН=1 SYN используется при установлении соединения. Когда SYN=1, ACK=0, это означает, что текущий сегмент представляет собой сообщение с запросом на соединение. Когда SYN=1 и ACK=1, это означает, что текущий сегмент является ответным сообщением, которое соглашается установить соединение.
FIN=1 FIN=1 указывает, что этот сегмент является запросом на разрыв соединения.

получить размер окна Это поле используется для реализации управления потоком TCP. Указывает оставшуюся емкость окна приема текущего получателя.После получения этого значения отправитель настраивает окно отправки на размер этого значения. Размер окна отправки определяет скорость отправки, поэтому получатель может контролировать скорость отправки отправителя, устанавливая это значение. Отправитель корректирует текущее окно отправки каждый раз при получении дейтаграммы.
контрольная сумма Он используется принимающей стороной для проверки того, является ли весь пакет данных ошибочным во время передачи.
аварийный указатель Используется для идентификации хвоста срочных данных.
поле опций Вышеупомянутые поля обязательны для каждого заголовка TCP, а поле option является необязательным и имеет переменную длину до 40 байтов. Наиболее часто используемое поле опций — MMS: максимальная длина сообщения.

Трехстороннее рукопожатие TCP

PS: В протоколе TCP сторона, которая активно инициирует запрос, называется «клиентом», а сторона, которая пассивно подключена, называется «сервером». Будь то клиент или сервер, после установления TCP-соединения он может отправлять и получать данные.

Изначально и сервер, и клиент находятся в состоянии ЗАКРЫТ. Перед началом связи обе стороны должны создать свой собственный блок управления передачей (TCB). После того, как сервер создал TCB, он переходит в состояние LISTEN и готов принять запрос на соединение от клиента.

первое рукопожатиеКлиент отправляет сегмент запроса на соединение на сервер. В заголовке этого сегмента SYN=1, ACK=0 и seq=x. После отправки запроса клиент переходит в состояние SYN-SENT.

PS1: SYN=1, ACK=0 указывает, что сегмент представляет собой сообщение с запросом на соединение.
PS2: x — это начальный порядковый номер потока байтов этой связи TCP. TCP предусматривает, что сегмент с SYN=1 не может иметь часть данных, но должен использоваться порядковый номер.

второе рукопожатиеПосле того, как сервер получит сегмент запроса на подключение, если он согласен на подключение, он отправит ответ: SYN=1, ACK=1, seq=y, ack=x+1. Состояние SYN-RCVD вводится после отправки ответа.

PS1: SYN=1, ACK=1 указывает, что сегмент является ответным сообщением для согласия на соединение.
PS2: seq=y указывает начальный порядковый номер отправленного потока байтов, когда сервер действует как отправитель.
PS3: ack=x+1 указывает, что сервер хочет отправить следующую дейтаграмму на байт, порядковый номер которого начинается с x+1.

третье рукопожатиеКогда клиент получает ответ о согласии на подключение, он также отправляет на сервер сегмент подтверждения, указывающий, что ответ о согласии на подключение, отправленный сервером, был успешно получен. Заголовок этого сегмента: ACK=1, seq=x+1, ack=y+1. После того, как клиент отправляет этот сегмент, он переходит в состояние ESTABLISHED, в состояние ESTABLISHED входит и сервер после получения ответа На этом установление соединения завершено!

Почему для установления соединения требуется трехстороннее рукопожатие вместо двух?Предотвращает получение сервером недопустимых сегментов запроса на подключение, что приводит к ошибкам.

PS: Неверный запрос на подключение: если запрос на подключение, отправленный клиентом на сервер, потерян, клиент снова отправит запрос на подключение после ожидания ответа. В это время предыдущий запрос на подключение является «недействительным».

Если для установления соединения нужно всего два рукопожатия, клиент сильно не меняется, и ему по-прежнему нужно получить ответ от сервера перед переходом в состояние ESTABLISHED, а сервер переходит в состояние ESTABLISHED после получения запроса на соединение. В это время, если сеть перегружена и запрос на подключение, отправленный клиентом, слишком поздно поступает на сервер, клиент со временем повторно отправит запрос.Если сервер правильно получит и подтвердит ответ, связь будет прервана. start, и соединение будет разорвано после завершения связи. В этот момент, если на сервер поступает недопустимый запрос на соединение, поскольку есть только два рукопожатия, сервер перейдет в состояние ESTABLISHED после получения запроса, ожидая отправки данных или активно отправляя данные. Однако клиент в это время уже перешел в состояние ЗАКРЫТО, и сервер будет долго ждать, что тратит впустую ресурсы соединения сервера.

ПТС махнул четыре раза

Для освобождения соединения TCP требуется всего четыре шага, поэтому это называется «четыре волны». Мы знаем, что соединения TCP являются двунаправленными, поэтому в четырех ручных волнах первые две волны используются для отключения соединения в одном направлении, а последние две волны используются для разрыва соединения в другом направлении.

первая волнаЕсли A считает, что передача данных завершена, ему необходимо отправить запрос на освобождение соединения B. Запрос имеет только заголовок, и основные параметры, содержащиеся в заголовке: FIN=1, seq=u. В этот момент A перейдет в состояние FIN-WAIT-1.

PS1: FIN=1 указывает, что сегмент представляет собой запрос на освобождение соединения.
PS2: seq=u, u-1 — порядковый номер последнего байта, отправленного от A к B.

вторая волнаПосле того, как B получит запрос на освобождение соединения, он уведомит соответствующее приложение, сообщив ему, что соединение между A и B было разорвано. В это время B переходит в состояние CLOSE-WAIT и отправляет A ответ об освобождении соединения, а его заголовок содержит: ACK=1, seq=v, ack=u+1.

PS1: ACK=1: за исключением сегмента запроса TCP-соединения, ACK всех дейтаграмм в процессе связи TCP равен 1, что указывает на ответ.
PS2: seq=v, v-1 — порядковый номер последнего байта, отправленного B в A.
PS3: ack=u+1 указывает, что он хочет получить сегмент, начинающийся с u+1-го байта, и успешно получил первые u байтов.

A получает ответ, переходит в состояние FIN-WAIT-2 и ждет, пока B отправит запрос на освобождение соединения.

После завершения второй волны соединение от A к B было разорвано, B больше не будет получать данные, а A больше не будет отправлять данные. Но соединение от B к A все еще существует, и B может продолжать отправлять данные в A.

Третья волнаКогда B отправляет все данные в A, он отправляет запрос на освобождение соединения в A, заголовок запроса: FIN=1, ACK=1, seq=w, ack=u+1. B переходит в состояние LAST-ACK.

четвертая волнаПосле получения запроса на освобождение A отправляет ответ с подтверждением B, и в это время A переходит в состояние TIME-WAIT. Это состояние будет длиться в течение времени 2MSL.Если в течение этого периода времени от B не будет запроса на повторную передачу, он перейдет в состояние CLOSED и отменит TCB. Когда B получает подтверждающий ответ, он также переходит в состояние CLOSED и отзывает TCB.

Почему A сначала входит в состояние TIME-WAIT и ждет 2MSL, прежде чем войти в состояние CLOSED?Чтобы гарантировать, что B может получить подтверждающий ответ от A. Если A напрямую входит в состояние CLOSED после отправки ответа подтверждения, то, если ответ потерян, B повторно отправит запрос на освобождение соединения после ожидания тайм-аута, но в это время A был закрыт и не будет отвечать, поэтому B никогда не сможет нормально закрываться..

Реализация надежной передачи TCP

Надежность TCP проявляется в том, что данные, которые он передает на прикладной уровень, безошибочны, упорядочены и без потерь.Проще говоря, данные, которые TCP в конечном итоге доставляет на прикладной уровень, точно такие же, как данные, отправленные отправителем. . TCP использует такие технологии, как управление потоком, управление перегрузкой и непрерывный ARQ, чтобы обеспечить его надежность.

PS: Блок данных, передаваемый сетевым уровнем, представляет собой «датаграмму», а блок данных транспортного уровня — «сегмент», но для удобства их можно вместе именовать «пакетами».

Протокол остановки ожидания (протокол ARQ)

TCP использует более сложный протокол скользящего окна для обеспечения его надежности, но протокол остановки и ожидания является его упрощенной версией.Для удобства понимания протокол остановки и ожидания представлен здесь первым.

AQR-протокол

ARQ (Automatic Repeat request) автоматический повторный запрос. Как следует из названия, он автоматически повторяет передачу в случае сбоя запроса до тех пор, пока запрос не будет получен правильно. Этот механизм гарантирует, что каждый пакет будет принят правильно. Протокол остановки-ожидания представляет собой протокол ARQ.

Принцип протокола «стоп-ожидание».

безошибочная ситуация Каждый раз, когда A отправляет пакет B, он должен прекратить отправку и дождаться подтверждающего ответа от B; A может отправить следующий пакет только после получения подтверждающего ответа от B.
Потеря пакетов и ошибки У отправителя есть таймер ожидания. Каждый раз, когда отправляется пакет, запускается таймер тайм-аута, ожидающий ответа от B. Если в течение периода тайм-аута ответ не получен, A повторно отправит предыдущий пакет. Ошибка пакета: если B получает пакет, но обнаруживает, что пакет имеет ошибку при передаче, проверив поле суммы, он сразу отбрасывает пакет и не предпринимает никаких других действий. По истечении времени ожидания A он повторно отправляет пакет до тех пор, пока B не получит его правильно. Потеря пакета: если пакет потерян в пути, B не получит пакет, поэтому ответа не будет. По истечении времени ожидания A пакет также будет передаваться повторно до тех пор, пока ответ на пакет не будет получен правильно. Подводя итог: когда пакет потерян или возникает ошибка, A будет повторно передавать пакет с течением времени.
Случаи потери ответа и позднего ответа TCP присваивает каждому байту порядковый номер, чтобы определить, был ли получен пакет. Ответ потерян: если B получает пакет правильно и вернул ответ, но ответ потерян на обратном пути. В это время А также не может получить ответ, поэтому через какое-то время повторяет передачу. Сразу после этого B снова получил пакет. Получатель оценивает, был ли принят текущий пакет, в соответствии с порядковым номером. Поздний ответ: если A не может получить ответ, отправленный B из-за перегрузки сети, он будет повторно передавать через некоторое время. После того, как B получает пакет и обнаруживает, что он был получен, он отбрасывает пакет и добавляет подтверждение к A. После того, как A получает ответ, он продолжает посылать следующий пакет. Но по прошествии долгого времени недопустимый ответ, наконец, пришел к А. В это время А может судить о том, что пакет был получен по порядковому номеру, и просто отбросить его.

Примечания об остановке ожидания протоколов

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

Протокол скользящего окна (протокол непрерывного ARQ)

Непрерывный протокол ARQВ протоколе ARQ отправитель может отправлять только один пакет за раз и должен ждать, пока не придет ответ. Отправитель протокола непрерывного ARQ имеет окно отправки, и отправитель может непрерывно отправлять пакеты в этом окне, не получая подтверждения. Это сокращает время ожидания и повышает эффективность передачи.

Накопленное подтверждениеВ протоколе непрерывного ARQ получатель также имеет окно приема, и получателю не нужно возвращать ответ каждый раз, когда он получает пакет, но он может возвращать ответ после непрерывного приема пакетов. Это экономит трафик. Поле ack в заголовке TCP используется для накопления подтверждений, оно указывает порядковый номер подтвержденного байта + 1, а также указывает начальный номер байта следующего пакета, который отправитель должен отправить.

окно отправки

Размер окна отправки определяется оставшимся размером окна приема. Получатель запишет оставшийся размер текущего окна приема в заголовок ответного TCP-сегмента, а отправитель установит размер окна отправки в соответствии с этим значением и текущей загруженностью сети после получения ответа. Размер окна отправки постоянно меняется. Окно отправки состоит из трех указателей:

р1 p1 указывает на задний фронт окна передачи, а байты, следующие за ним, указывают, что оно было отправлено и получено подтверждение.
р2 p2 указывает на первый еще не отправленный байт. Байты между p1-p2 указывают, что сообщение было отправлено, но подтверждение не получено. Эту часть байтов еще нужно зарезервировать, потому что может быть тайм-аут для повторной передачи. Байты между p2-p3 представляют байты, которые могут быть отправлены, но еще не отправлены.
р3 p3 указывает на передний край окна отправки, предшествующие ему байты не были отправлены и не могут быть отправлены.

Каждый раз, когда отправитель получает подтверждение, задний фронт может двигаться вперед на указанное количество байтов. В это время, если размер окна все еще не изменился, передний фронт также может сместиться вперед на указанный байт. Когда p2 совпадает с передним фронтом, отправитель должен ждать подтверждения.

окно получения

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

Что следует отметить в отношении непрерывного ARQ

В то же время размер окна отправки не обязательно должен быть таким же большим, как окно приема. Хотя размер окна отправки устанавливается в соответствии с размером окна приема, есть время для передачи ответа в сети.Возможно, что размер окна приема в момент времени t1 равен m, но когда отправителю приходит подтверждающий ответ, изменился размер принимающего окна. Кроме того, на размер окна отправки также влияет перегрузка сети. Когда сеть перегружена, окно отправки будет уменьшено.
Стандарт TCP не указывает, что делать с байтами, поступающими не по порядку. Однако протокол TCP обычно буферизует эти байты и ожидает поступления недостающих байтов, прежде чем передать их на прикладной уровень для обработки. Это экономит полосу пропускания по сравнению с простым отбрасыванием байтов не по порядку.
Стандарт TCP предусматривает, что получатель должен иметь функцию кумулятивного подтверждения. Получатель может одновременно подтверждать несколько сегментов TCP, но он не может задерживаться слишком долго, как правило, в пределах 0,5 с. Кроме того, TCP позволяет получателю использовать подтверждения, когда есть данные для отправки. Однако такая ситуация, как правило, встречается редко, поскольку случаев, когда данные должны отправляться в обоих направлениях, обычно немного.

управление потоком

Что такое управление потоком?Если отправитель отправляет слишком быстро, а получатель не успевает принять, то произойдет потеря пакетов. Чтобы избежать потери пакетов, контролируйте скорость отправки отправителя, чтобы у получателя было время для приема, что является контролем потока.

Цель управления потоком?Фундаментальной целью управления потоком является предотвращение потери пакетов, что является одним из аспектов надежности TCP.

Как реализовать управление потоком?Реализуется протоколом скользящего окна (протокол непрерывного ARQ). Протокол скользящего окна не только обеспечивает безошибочный и упорядоченный прием пакетов, но и реализует управление потоком.

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

непрерывный таймерЧтобы избежать взаимоблокировок, вызванных управлением потоком, TCP использует постоянные таймеры. Этот таймер запускается каждый раз, когда отправитель получает ответ с нулевым окном. Когда время истекло, он будет активно отправлять сообщение, чтобы спросить размер окна получателя. Если получатель все равно возвращает нулевое окно, сбросить таймер и продолжить ожидание, если окно не 0, значит, ответное сообщение потеряно, а затем сбросить окно отправки и начать отправку, избежав таким образом возникновения взаимоблокировки.

контроль перегрузки

В чем разница между управлением перегрузкой и управлением потоком?

Контроль перегрузки: контроль перегрузки действует в сети, он предотвращает ввод слишком большого количества данных в сеть и предотвращает перегрузку сети;
Управление потоком: управление потоком воздействует на получателя, оно контролирует скорость отправки отправителя, чтобы у получателя было время для приема. PS: управление перегрузкой предназначено для сети, чтобы предотвратить запись слишком большого количества пакетов в сеть, что приводит к перегрузке сети; в то время как управление потоком предназначено для получателя, оно гарантируется путем контроля скорости отправки отправителя Получатель может получить его вовремя .

Цель контроля заторов?

Снизить нагрузку на сеть
Убедитесь, что группа прибыла вовремя

Алгоритм медленного запуска и алгоритм предотвращения перегрузки

Отправитель поддерживает окно отправки. Размер окна отправки зависит от загруженности сети и размера окна приема. Окно отправки изменяется динамически.
Отправитель также поддерживает порог медленного запуска
1. окно отправки
2. Окно отправки > Порог медленного запуска: используйте алгоритм предотвращения перегрузки
3. окно отправки = порог медленного запуска: использовать алгоритм медленного запуска или алгоритм предотвращения перегрузки
Конкретный процесс алгоритма:
1. Когда связь начинается, окно отправки отправителя устанавливается в 1, и отправляется первый пакет M1;
2. После того, как получатель получает М1, он возвращает ответ с подтверждением.В это время окно отправки отправителя удваивается, и отправляются М2 и М3; раз)
3. Если окно отправки больше порога медленного запуска, будет использоваться алгоритм предотвращения перегрузки, и окно отправки будет +1 каждый раз при получении подтверждения;
4. Если отправитель повторяет передачу через какое-то время, это указывает на то, что сеть перегружена. а) Порог медленного старта устанавливается равным половине текущего окна отправки; б) Окно отправки устанавливается равным 1; c) включить алгоритм предотвращения перегрузки; PS: При тайм-ауте отправки и повторной передаче окно отправки могло превысить порог медленного старта, а могло и не превысить; в это время, независимо от ситуации, будет включен алгоритм предотвращения перегрузки, и вышеуказанные три шага будет исполнено!
Роль алгоритма медленного старта: алгоритм медленного старта расширяет окно отправки с небольшого размера и расширяет его экспоненциально, чтобы избежать ввода слишком большого количества пакетов в сеть в начале и вызвать перегрузку; он также обнаруживает процесс медленно расширяя окно.В процессе перегрузки сети, когда обнаруживается перегрузка, скорость передачи будет уменьшаться во времени, тем самым уменьшая перегрузку сети.
Что делают алгоритмы предотвращения перегрузки: Алгоритмы предотвращения перегрузки заставляют окно отправки увеличиваться линейно, а не экспоненциально, что делает сеть менее подверженной перегрузке.
Алгоритм AIMD (аддитивный алгоритм увеличения умножения и уменьшения) Алгоритм медленного запуска и алгоритм предотвращения перегрузки также имеют название, называемое «алгоритм аддитивного увеличения умножения уменьшения».
- Аддитивное увеличение: относится к алгоритму предотвращения перегрузки, который заставляет окно отправки увеличиваться линейно;
- Мультипликативное сокращение: означает, что независимо от того, используется ли в настоящее время алгоритм медленного запуска или алгоритм предотвращения перегрузки, пока происходит перегрузка, порог медленного запуска станет половиной текущего окна.

Алгоритм быстрой повторной передачи и алгоритм быстрого восстановления

Вышеупомянутый алгоритм медленного запуска и алгоритм предотвращения перегрузки могут обеспечить соответствующую обработку, когда сеть перегружена, а быстрая повторная передача и быстрое восстановление являются методом предотвращения перегрузки.В это время сеть может не быть перегружена, но уже есть признаки перегрузки, так что некоторые меры предосторожности должны быть приняты.
Принцип быстрой повторной передачи: поскольку TCP имеет возможность накапливать подтверждения, получатель не будет отправлять ответ сразу же после получения пакета, и ему может потребоваться дождаться получения нескольких пакетов, прежде чем одновременно выдавать кумулятивное подтверждение. Однако алгоритм быстрой повторной передачи требует, чтобы, если получатель получает неупорядоченный пакет, он должен был немедленно отправить подтверждение предыдущего правильного пакета, чтобы отправитель мог как можно скорее узнать, что пакет может быть потерян.
Принцип быстрого восстановления: когда отправитель получает три подтверждения для одного и того же пакета, он может в основном определить, что пакет был потерян; в это время нет необходимости ждать тайм-аута и напрямую выполнять «увеличение уменьшения умножения»:
1. Уменьшите вдвое порог медленного пуска;
2. Уменьшить вдвое окно отправки (не установлено на 1);
3. Используйте алгоритмы предотвращения перегрузок;