Лучшее описание, которое я когда-либо слышал, в котором содержался смысл встроенного в TCP метода регулирования, было из недавнего подкаста Security Now . Процитирую Стива Гибсона:
Таким образом, по всеобщему согласию, TCP является очень умным протоколом и делает так называемое «медленное начало». Обычно дается разрешение на отправку некоторого количества пакетов без подтверждения. Итак, идея в том, что давайте просто начнем действовать. И обычно это число два. И поэтому, когда TCP запускается, он может отправлять два пакета, один за другим. Без подтверждения первого он отправит второй. Но тогда это ждет. И затем правило для регулирования заключается в том, что мы разрешаем увеличивать количество неподтвержденных пакетов на один при каждом подтверждении, которое мы получаем.
Итак, давайте подумаем об этом. Мы разрешаем увеличивать количество неподтвержденных пакетов на один при каждом подтверждении, которое мы получаем. Поэтому мы сначала отправляем два пакета в качестве нашего согласованного начала. Они получают признание. Итак, у нас есть первое подтверждение. Мы позволяли себе отправить два. Теперь, получив это первое подтверждение, мы увеличиваем его на один-три. Теперь мы можем отправить еще три пакета без какого-либо подтверждения. Когда приходит подтверждение за то, что мы отправили раньше, мы увеличиваем это до четырех. Это называется «окном перегрузки». Это не окно, которое когда-либо отправлялось по линии, т. Е. Оно не похоже на окно приема, которое представляет собой 16 бит заголовка TCP, который сообщает нам, сколько данных мы можем отправить вперед. Это одно - это окно. Это'
Если мы будем продолжать увеличивать количество неподтвержденных пакетов, которые нам разрешено отправлять по одному каждый раз, когда мы получаем подтверждение, в какой-то момент мы достигнем предела. И прелесть этой системы в том, что, поскольку мы начинаем пытаться отправлять пакеты быстрее, чем самое слабое соединение, буквально соединение между маршрутизаторами, в какой-то момент мы находим точку, где разрывается самое слабое соединение. Он отбрасывает пакеты, которые мы пытаемся отправить, потому что мы пытаемся отправить их слишком быстро. Так что подтверждения с другого конца останавливаются, потому что данные больше не проходят.
И что делает TCP, если он не получил - и это зависит от стратегии. Со временем стратегия, фактическая стратегия предотвращения перегрузок сильно изменилась. Есть такие имена, как Тахо и Рено, и множество других, которые вы увидите, если будете заниматься поиском в Google и Wikipediaing, в которых конкретно указано поведение. Но идея заключается в том, что, когда отправитель понимает, что его данные больше не проходят, поскольку он пропускает подтверждения, он быстро сокращает скорость отправки. Как правило, он делит его пополам. Таким образом, он резко сокращает его, а затем возвращается к его увеличению.
По сути, это означает, что потеря пакетов является сигнальной функцией для «Мы не можем отправлять данные быстрее», и что отправители TCP на каждом конце соединения по всему Интернету всегда своего рода - они мы пытаемся двигаться быстрее, чем максимальная скорость, доступная между двумя конечными точками, то есть это самое слабое звено, где бы оно ни было, и они всегда доводят его до предела. Итак, учитывая, что где-то есть точка, которая слабее, чем их способность отправлять пакеты, они найдут ее, потому что они будут откачивать пакеты. Пока есть данные для отправки и соединение с высокой пропускной способностью, отправитель будет увеличивать скорость отправки, то есть количество ожидающих пакетов, пакетов, которым разрешено быть на лету в качестве подтверждений Вернись, агрессивно продолжает двигать это число вверх, пока оно не вытолкнет его слишком далеко. Затем он много отступает, а затем снова движется вперед.
Так вот, что на самом деле происходит между TCP-соединениями, которые, как, наверное, я не знаю, какой процент, но самый большой процент трафика в Интернете по сравнению с TCP-соединениями. Все наши операционные системы в ядре, в так называемом стеке TCP, имеют эти счетчики. И когда мы отправляем файл, когда мы загружаем большой файл или получаем веб-страницу, сервер на другом конце делает то же самое. На каждом отдельном соединении он выталкивает как можно больше пакетов, которые еще не были подтверждены, увеличивая скорость передачи до тех пор, пока не достигнет точки, где он начинает отказывать или заикаться. Затем он отступает, чтобы позволить чему-то восстановиться, а затем снова начинает работать.
И так, в конечном итоге это становится своего рода саморегулирующейся системой, которая, учитывая ограничения, я имею в виду, на самом деле кажется довольно прикольной и грубой ».