Окно приема - это количество данных, которое получатель может получить сразу, не перегружаясь. Это управление потоком, наложенное приемником.
Окно перегрузки (примечание: это "окно перегрузки"; здесь нет "окна пересылки", поэтому ваш заголовок немного отклонен) - это объем данных, которые сеть (маршрутизаторы между отправителем и получателем) может принять одновременно без получить перегружены (то есть, не вызывая или усугубляя заторов). Окно перегрузки можно рассматривать как форму управления потоком, наложенную отправителем.
Прежде чем мы перейдем к окну перегрузки, давайте начнем с деталей окна получения.
Окно получения - это количество данных, которое получающий стек TCP готов получить и буферизировать для принимающего приложения, прежде чем получающее приложение считывает ожидающие данные из принимающего стека TCP и освобождает эти буферы ядра. Размер окна приема может быть ограничен деталями реализации. Например, Unix-подобное ядро может ограничивать размер окна приема тем, сколько буферов сообщений ядра (mbufs) ядро готово выделить для каждого TCP-соединения.
Предполагая, что вы не ограничены ресурсами получателя, вы можете рассчитать оптимальное окно приема для использования с данным TCP-соединением. По сути, окно приема должно быть как минимум «продуктом полосы пропускания * задержки» (TCP) соединения TCP. Итак, чтобы использовать типичный пример 802.11ac со скоростью 1300 Мбит / с, если у вас есть канал 1 300 000 000 бит в секунду (это ваша полоса пропускания) с 0,003 секундами в оба конца (RTT; подумайте "время пинга"; это ваша задержка), вы получите окно должно быть не менее 1 300 000 000 бит / с * 0,003 с = 3 900 000 бит, что составляет около 476 КБ. Изменение размера окна приема для BDP позволяет отправителю "заполнить канал", посылая в сеть столько данных, сколько может поддерживать сеть, пока не будет достаточно времени, чтобы вернуть Ack отправителю. Что-нибудь меньшее, чем это, и отправитель не сможет передавать непрерывно; вместо этого (как только медленный запуск TCP нарастает достаточно), он отправит пакет размером с принимающее окно, но это будет сделано путем внедрения этого пакета в сеть, прежде чем он получит подтверждение, сообщающее, что в окне приема больше места. Поэтому ему придется приостановить и дождаться подтверждения, прежде чем он узнает, что может отправлять больше, не перегружая стек TCP получателя. В это время он тратит паузу, ожидая, пока Ack потерял время, которое он мог бы потратить на передачу.
Вот что такое окно приема и как оно рассчитывается. Теперь давайте посмотрим на окно перегрузки.
Окно перегрузки - это одна из вещей, которую отправитель отслеживает, чтобы убедиться, что оно не вызывает перегрузку сети для перескоков сети (маршрутизаторы, соединения между маршрутизаторами) между отправителем и получателем. В конечном итоге инновации, такие как явное уведомление о перегрузке (ECN), будут широко распространены, что позволит маршрутизаторам уведомлять отправителей TCP о перегрузке. Но до этого отправители TCP должны пытаться обнаружить и избежать перегрузки другими способами, и большая часть этого происходит из-за медленной передачи пакетов, чтобы проверить сеть на предмет скорости, с которой она может идти без потери пакетов, интерпретируя потерю пакетов как признак перегрузки. , значительно снижая скорость передачи пакетов при потере, и постепенно снова увеличивая скорость.
В текущем стандарте RFC по контролю перегрузок TCP, RFC 5681, говорится, что окно перегрузок должно быть первоначально рассчитано как значение, в 2-4 раза превышающее максимальный размер сегмента TCP (MSS; как и эквивалент уровня MTU на уровне TCP); в частности, в 2-4 раза больше TCP MSS, который отслеживает отправитель . Это Отправитель MSS или SMSS. RFC также заявляет, что отправитель должен соблюдать, что ниже между окном перегрузки и окном приема. То есть, даже если сеть быстрая и не перегружена (и, следовательно, окно перегрузки стало больше, чем окно приема), нет смысла отправлять в сеть больше данных, чем может обработать получатель; это просто перегрузит получателя и заставит его отбрасывать пакеты после успешного прохождения через сеть.
Такова связь между окном перегрузки и окном приема. Одним из них является управление потоком на стороне приемника, чтобы приемник не перегружался, а другим - управление потоком на стороне отправителя, чтобы маршрутизаторы в сети не перегружались. При принятии решения о том, может ли он отправлять больше пакетов в полете, отправитель TCP должен смотреть как на окно перегрузки, так и на окно приема, и учитывать, какое значение меньше.
Окно перегрузки обычно начинается примерно с 3 SMSS (3 * 1448 байт = 4344 байт), а во время медленного старта TCP увеличивается до 1 SMSS (1448 байт) на Ack, при условии, что получено Acked как минимум 1 SMSS ранее непроверенных байтов , После медленного запуска включается алгоритм предотвращения перегрузки, и окно перегрузки увеличивается не более чем на 1 SMSS за RTT. Если отправитель обнаруживает потерю пакета, он интерпретирует это как перегрузку и сокращает окно перегрузки в основном пополам для легко восстанавливаемой потери (Быстрая ретрансляция / быстрое восстановление, вызванное "тройными дублирующими квитанциями") и сокращает ее до 1 SMSS. для более серьезных сценариев потерь (Acks не получено до истечения таймера повторной передачи).
Обратите внимание, что ваш вопрос содержит ошибку. Неправильно говорить, что окно перегрузки удваивается, когда отправитель получает подтверждение. Окно перегрузки обычно начинается с 3 SMSS и увеличивается не более чем на одну SMSS на каждую подтвержденную SMSS. Когда происходит потеря, окно скопления сокращается в основном в два раза или хуже. Фактически, политика изменения размера окна скопления часто описывается как «аддитивное увеличение, мультипликативное уменьшение».
