Огромнейшее спасибо за ваши лекции! Особенно по TCP, скользящее окно, управление потоком и перегрузкой. Благодаря этим видео успешно сдал экзамен по сетям! ) И впервые за столько лет пользования Ютубом решил оставить комментарий к видео )
Спасибо за видео! Интересное использование в связке медленного старта и аддитивного увеличения/мультипликативного уменьшения для получения приемуществ оптимизации скользящего окна обоими методами
В итоге окна три: скользящее на стороне отправителя, управления потоком на стороне получателя и перегрузки на стороне отправителя? Скользящее и перегрузки не одно и то же? Как я понял, окно перегрузки - это механизм управления размером скользящего окна?
Я понял так, поправьте если не прав) скользящее окно находится и на стороне отправителя и получателя - это размер окна в сегменте с данными и размер окна в сегменте подтверждения. Управление перегрузкой регулируется отправителем, а потоком - получателем. Получатель говорит сколько может принять, а отправитель сколько может отправить (и этот размер меньше или равен возможности принятия). И получатель должен отослать подтверждение после того как получит количество данных указанных отправителем.
Здравствуйте, Андрей. Спасибо большое за видео, регулярно возвращаюсь к ним чтобы освежить память. У меня вопрос по медленному старту, т.к. я слегка запутался. Вы говорите, что во время действия алгоритма медленного старта, окно отправителя увеличивается экспоненциально, т.е. получил подтверждение 2х сегментов - отправил 4. Такую же информацию я вижу на разных сайтах. Но при обращении к первоисточнику (rfc 5681) оказывается, что окно должно увеличиваться на 1 сегмент после получения очередного ACK. (During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges new data.) Как в этом разобраться? Спасибо за внимание!
А почему при медленном старте на каждый сегмент приходит подтверждение? Насколько я понял, суть скользящего окна - на несколько сегментов - одно общее подтверждение. получается А отправляет пакет - В подтверждает - А высылает 2 пакета - В их подтверждает 1 раз - А на это подтверждение снова высылает 2 пакета. Где экспоненциальный рост?
Спасибо за отличную лекцию, в этот фрагменте у меня был пробел Только я правильно понимаю, что в congestion window хранит не количество сегментов, а количество байтов? А количество сегментов зависит от величины сегмента tcp, который по идее должен быть (по умолчанию) 536 байтов? и доп вопрос: а как tcp пиры договариваются между собой о величине сегмента? при этом надо учитывать, что между ними еще могут быть роутеры, на которых также ложится задача фрагментации спасибо еще раз
+conquistador, да TCP везде использует количество байтов, а не сегментов. О размере сегмента договариваются при установке соединения. Транспортный уровень является сетенезависимым. Промежуточные маршрутизаторы и фрагментация на них скрыты от него. Логически сегмент выходит от отправителя и сразу же появляется на получателе.
Андрей, спасибо за лекцию. У меня вопрос: если после того, как размер окна преодолел порог медленного старта и какое то время был механизм аддитивного увеличения но после перезагрузки размер окна упал ниже порога медленного старта, будет работать все равно AIMD либо ниже порога начнет работу механизм медленного старта снова?
Андрей, я может что-то не понял. Но исходя из предыдущих лекций получается, что подтверждение приходит не на каждый сегмент, а на диапазон сегментов (группу сегментов) - одно подтверждение, верно? В таком случае как можно одновременно отправить два сегмента (получается в одной группе , если я все правильно понял) и получить с них два подтверждения? Получается должно быть получено одно подтверждение на группу из сегментов... разве не так?
А каким образом происходит контроль перегрузки, это уже на аппаратном уровне зашито в маршрутизаторы , или самолично проводится настройка с расчетами, в зависимости от структуры сети?
Да, об управлении перегрузкой в TCP редко рассказывают во вводных курсах по сетям. Но без этого нельзя понять, зачем нужно постоянное соединение в HTTP (кроме очевидной вещи, что не нужно каждый раз проходить процедуру трехкратного рукопожатия в TCP).
@@AndreySozykin касательно медленного старта. Андрей, так в tcp/ip по умолчанию же работает кумулятивное подтверждение сегментов☝🏼 пришло 4 сегмента - 1 подтверждение. медленный старт видит это одно подтверждение и согласно вашей презентации отправитель отправляет 2 сегмента☝🏼 2 сегмента вместо 4 на предыдущем шаге. на эти 2 сегмента так же от получателя будет одно кумулятивное подтверждение и отправитель снова отправит 2 сегмента. тогда выше двух сегментов отправление и не вырастет. Прокомментируйте, плз.
То есть, я правильно понял, поле Размер окна получателем используется для информации отправителя о свободном буфере, а отправителем используется никак?
@@AndreySozykin ненене, вопрос немного в другом был. Получатель отправляет подтверждение с указанием количества свободного места в буфере в разделе "Размер окна" А отправитель что пишет в это поле когда отправляет новый сегмент данных?
Анздрей здравстуйте, огромное спасибо за Ваш курс! Каким образом провайдер интернет регулирует скорость у клиентов? Он задает условное значение сотфверно и затем это значение регулируется управлением перегрузки?
Правильно ли я понимаю, что если 1 участок сети всего маршрута от отправителя к получателю, будет перегружен, то это приведет к уменьшению размера окна на всем маршруте? Или эти расчеты ведутся от каждого маршрутизатора?
Андрей, скажите, пожалуйста, а процесс управления перегрузкой начинается каждый раз при новом соединении по TCP протоколу? Я имею ввиду, в HTTP можно указать, чтобы не закрывалось TCP соединение после запрос/ответа. Это имеет отношение к TCP перегрузке же? Иначе, если мы закрываем каждый раз соединение, то приходится устанавливать окно перегрузки каждый раз сначала?
Да, процесс управления перегрузкой начинается при каждом новом соединении TCP. В HTTP, действительно, можно указать, чтобы соединение TCP осталось открытым, чтобы можно было отправить еще один запрос. В этом случае скорость работы будет выше.
@@AndreySozykin Благодарю за ответ! И вы уже действительно на него ответили в видео про Прикладной уровень, про разницу HTTP/1.0 и HTTP/1.1. Но на момент написания вопроса я просто его еще не видел.
подгоняется под возможности канального уровня. для Ethernet это 1460 байт (1460 + 20 на заголовок TCP + 20 на заголовок IP = 1500, что и есть максимальным размером Ethernet-пакета), для WiFi, как я понимаю, 2264 байта (2264 + 20 + 20 = 2304, т.е. макс. размер WiFi-пакета). Есть ещё Gigabit Ethernet, где поддерживаются Jumbo-кадры до 9000 байт, т.е. там сегмент будет 9000 - 20 - 20 = 8960 байт
о боже теперь ясно почему скорость скачивания торрента в начале постепенно увеличивается, пока не выйдет на свой максимум. Или это не TCP, а что-то на прикладном уровне?
Огромнейшее спасибо за ваши лекции!
Особенно по TCP, скользящее окно, управление потоком и перегрузкой.
Благодаря этим видео успешно сдал экзамен по сетям! )
И впервые за столько лет пользования Ютубом решил оставить комментарий к видео )
Отличные новости про экзамен. Какой университет, если не секрет?
у тебя сам Андрей спросил какой университет!!!☝🏼 А ты наплевал на этот вопрос.
Думал, как бы улучшить курс и тут придумал. Если бы больше терминов дублировали на английском. ! Тогда практичность курса увеличивалась бы в разы.
+Vlad Stetsenko, спасибо за предложение, буду дублировать.
Согласен.
думал и придумал
да ты талант))
Как всегда, все доступно и понятно. Так полезно и мало времени тратится на усвоение материала. Спасибо
большое.
Пожалуйста!
Был в институте курс по сетям, но большую часть информации слышу впервые.
Пример который Вы приводите тут 06:30 он скорее подходит к формуле - с каждым подтверждением умножаем количество сегментов в окне на 2.
Спасибо за вашу работу! Очень и очень здорово рассказываете
+Михаил Шпаков пожалуйста! Рад, что нравится.
Андрей, огромное спасибо за Вашу работу! Изучал по Вашим урокам компьютерные сети, прошёл собеседование!!!
Данный курс отличное дополнение к "сетям для самых маленьких", лучше всего смотреть и читать эти материалы параллельно.
Спасибо!
спасибо за рекомендацию
@@alanextar
мне не понравились "СдСМ"🤷♂️ детские какие-то. не смог смотреть их. а эти - норм.
Спасибо вам, Андрей!
Пожалуйста!
Спасибо! Как всегда все отлично.
+Дмитрий Ларионов, пожалуйста!
Спасибо, что смотрите!
Спасибо, Вам! отличные лекции!
Пожалуйста!
Интересная технология. Можно и в своих разработках использовать
Спасибо за видео!
Интересное использование в связке медленного старта и аддитивного увеличения/мультипликативного уменьшения для получения приемуществ оптимизации скользящего окна обоими методами
Спасибо за лекцию, продолжайте снимать пожалуйста.
Я рекомендую Ваш канал своим знакомым.
+Nikita Andrich, спасибо за рекомендацию! Записывать новые лекции обязательно буду!
Отличный урок!
Спасибо!
Получатель: "Могу принять больше"
Отправитель: "Нельзя, в сети наблюдается адский разгон!"
:-)
Хорошее объяснение!
Спасибо.
Qilgan bu yaxshi amallariyezni ajrini bersin.
хватит писать тут на своём тарабарском.
Очень информативно, спасибо
Пожалуйста!
Прямо курс для "Маленьких и тупых". Все разобрано до мелочей. Во всяком случае до понятных объектов.
Я бы сказал, что не для тупых, а для начинающих 😉
Спасибо, Андрей!
Полезные видео. Очень.
Спасибо!
Спасибо большое, Все доходчиво объяснили!
+Серега Гуляев, рад, что нравится!
Спасибо, что смотрите!
В итоге окна три: скользящее на стороне отправителя, управления потоком на стороне получателя и перегрузки на стороне отправителя? Скользящее и перегрузки не одно и то же? Как я понял, окно перегрузки - это механизм управления размером скользящего окна?
Я понял так, поправьте если не прав)
скользящее окно находится и на стороне отправителя и получателя - это размер окна в сегменте с данными и размер окна в сегменте подтверждения. Управление перегрузкой регулируется отправителем, а потоком - получателем. Получатель говорит сколько может принять, а отправитель сколько может отправить (и этот размер меньше или равен возможности принятия). И получатель должен отослать подтверждение после того как получит количество данных указанных отправителем.
Здравствуйте, Андрей. Спасибо большое за видео, регулярно возвращаюсь к ним чтобы освежить память. У меня вопрос по медленному старту, т.к. я слегка запутался. Вы говорите, что во время действия алгоритма медленного старта, окно отправителя увеличивается экспоненциально, т.е. получил подтверждение 2х сегментов - отправил 4. Такую же информацию я вижу на разных сайтах. Но при обращении к первоисточнику (rfc 5681) оказывается, что окно должно увеличиваться на 1 сегмент после получения очередного ACK. (During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges new data.) Как в этом разобраться? Спасибо за внимание!
А почему при медленном старте на каждый сегмент приходит подтверждение? Насколько я понял, суть скользящего окна - на несколько сегментов - одно общее подтверждение. получается А отправляет пакет - В подтверждает - А высылает 2 пакета - В их подтверждает 1 раз - А на это подтверждение снова высылает 2 пакета. Где экспоненциальный рост?
Спасибо
Пожалуйста!
Добрый день! Андрей теория это очень хорошо, у меня просьба можно ли это увидеть на практике? То есть сьимитировать ситуацию и показать в Вайршарке
Именно про управление перегрузкой сложно сделать.
*некро-ответ, но вдруг кому-то интересно будет*
в торренте, если посмотреть на график загрузки, то часто можно увидеть именно эту картинку: 7:24
@@albanec4702
👍🏼
Спасибо!
Пожалуйста!
спасибо!!!
Пожалуйста!
Спасибо за отличную лекцию, в этот фрагменте у меня был пробел
Только я правильно понимаю, что в congestion window хранит не количество сегментов, а количество байтов?
А количество сегментов зависит от величины сегмента tcp, который по идее должен быть (по умолчанию) 536 байтов?
и доп вопрос: а как tcp пиры договариваются между собой о величине сегмента? при этом надо учитывать, что между ними еще могут быть роутеры, на которых также ложится задача фрагментации
спасибо еще раз
+conquistador, да TCP везде использует количество байтов, а не сегментов.
О размере сегмента договариваются при установке соединения.
Транспортный уровень является сетенезависимым. Промежуточные маршрутизаторы и фрагментация на них скрыты от него. Логически сегмент выходит от отправителя и сразу же появляется на получателе.
Спасибо Андрей! Все неделю смотрю Ваш курс. Очень интересно было узнать про TCP. А Вы в университете преподаете?
Преподаю в Уральском федеральном университете в Екатеринбурге.
Андрей, спасибо за лекцию. У меня вопрос: если после того, как размер окна преодолел порог медленного старта и какое то время был механизм аддитивного увеличения но после перезагрузки размер окна упал ниже порога медленного старта, будет работать все равно AIMD либо ниже порога начнет работу механизм медленного старта снова?
+rostl, будет работать AIMD. Алгоритм медленного старта работает только в начале, потому и называется "старт".
Андрей, я может что-то не понял. Но исходя из предыдущих лекций получается, что подтверждение приходит не на каждый сегмент, а на диапазон сегментов (группу сегментов) - одно подтверждение, верно?
В таком случае как можно одновременно отправить два сегмента (получается в одной группе , если я все правильно понял) и получить с них два подтверждения? Получается должно быть получено одно подтверждение на группу из сегментов... разве не так?
задал ему этот же вопрос. но он нынче не отвечает:((
А каким образом происходит контроль перегрузки, это уже на аппаратном уровне зашито в маршрутизаторы , или самолично проводится настройка с расчетами, в зависимости от структуры сети?
На аппаратном уровне в маршрутизаторах. Вручную нереально сделать.
ETO VABSHE uje chtota Novoe Dlya menya )))
perviy raz Slishol ab etom )
Spasibo
Да, об управлении перегрузкой в TCP редко рассказывают во вводных курсах по сетям. Но без этого нельзя понять, зачем нужно постоянное соединение в HTTP (кроме очевидной вещи, что не нужно каждый раз проходить процедуру трехкратного рукопожатия в TCP).
Da pravilno skazali
@@AndreySozykin да,не рассказывают , сложно слишком
Spasibo
Пожалуйста!
@@AndreySozykin
касательно медленного старта.
Андрей, так в tcp/ip по умолчанию же работает кумулятивное подтверждение сегментов☝🏼 пришло 4 сегмента - 1 подтверждение. медленный старт видит это одно подтверждение и согласно вашей презентации отправитель отправляет 2 сегмента☝🏼 2 сегмента вместо 4 на предыдущем шаге. на эти 2 сегмента так же от получателя будет одно кумулятивное подтверждение и отправитель снова отправит 2 сегмента. тогда выше двух сегментов отправление и не вырастет. Прокомментируйте, плз.
спс
Пожалуйста!
То есть, я правильно понял, поле Размер окна получателем используется для информации отправителя о свободном буфере, а отправителем используется никак?
Отправитель, если он работает правильно, не будет передавать больше данных, чем размер окна. Иначе получатель их не сможет принять.
@@AndreySozykin ненене, вопрос немного в другом был. Получатель отправляет подтверждение с указанием количества свободного места в буфере в разделе "Размер окна" А отправитель что пишет в это поле когда отправляет новый сегмент данных?
Отправитель в поле "Размер окна" ничего не пишет.
@@w1tcherj
красава: отстоял свой вопросик:)
Анздрей здравстуйте, огромное спасибо за Ваш курс! Каким образом провайдер интернет регулирует скорость у клиентов? Он задает условное значение сотфверно и затем это значение регулируется управлением перегрузки?
Правильно ли я понимаю, что если 1 участок сети всего маршрута от отправителя к получателю, будет перегружен, то это приведет к уменьшению размера окна на всем маршруте? Или эти расчеты ведутся от каждого маршрутизатора?
Размер окна задается на транспортном уровне, один на весь маршрут.
Андрей, скажите, пожалуйста, а процесс управления перегрузкой начинается каждый раз при новом соединении по TCP протоколу?
Я имею ввиду, в HTTP можно указать, чтобы не закрывалось TCP соединение после запрос/ответа. Это имеет отношение к TCP перегрузке же? Иначе, если мы закрываем каждый раз соединение, то приходится устанавливать окно перегрузки каждый раз сначала?
Да, процесс управления перегрузкой начинается при каждом новом соединении TCP. В HTTP, действительно, можно указать, чтобы соединение TCP осталось открытым, чтобы можно было отправить еще один запрос. В этом случае скорость работы будет выше.
@@AndreySozykin Благодарю за ответ! И вы уже действительно на него ответили в видео про Прикладной уровень, про разницу HTTP/1.0 и HTTP/1.1. Но на момент написания вопроса я просто его еще не видел.
А есть ли официальное название комбинации медленного старта и AIMD?
И спасибо за лекции, очень помогли)
Название такой комбинации я не знаю. За хороший отзыв спасибо!
Андрей спасибо вам за лекцию!
На 4,20 передаём данные, получаем подтверждение, размер окна увеличивается. Это когда уже установлено соединение?
безграмотный, тайминг научись сначала ставить, а потом сети изучай. деревня🤦♂️
как размер окна прописан в WireShark ? Win или WS(Window Scale) ?? и что тогда значит второй параметр ?
интересно Вам ответели?
Как на английском называется Медленный старт?) Спасибо
+Vlad Stetsenko, Slow start.
В аддитивном увеличении не понял, увеличивается на один сегмент всего?
+Vlad Stetsenko, на самом деле это зависит от настроек и реализации TCP, которых сейчас очень много. Обычно увеличение на 1 или 4 сегмента.
Подскажите, пожалуйста, какой размер одного сегмента TCP?
подгоняется под возможности канального уровня. для Ethernet это 1460 байт (1460 + 20 на заголовок TCP + 20 на заголовок IP = 1500, что и есть максимальным размером Ethernet-пакета), для WiFi, как я понимаю, 2264 байта (2264 + 20 + 20 = 2304, т.е. макс. размер WiFi-пакета). Есть ещё Gigabit Ethernet, где поддерживаются Jumbo-кадры до 9000 байт, т.е. там сегмент будет 9000 - 20 - 20 = 8960 байт
@@andreykelip5631
👍🏼
о боже теперь ясно почему скорость скачивания торрента в начале постепенно увеличивается, пока не выйдет на свой максимум. Или это не TCP, а что-то на прикладном уровне?
Скучно и не понятно
имбецил, тогда зачем смотришь и пишешь под каждым видео свою хрень?
Спасибо!