Мой первый комент на ютуб за очень долгое время пользования этим сервисом) Андрей Владимирович, большое спасибо за проделанную Вами работу! Ваши лекции - ТОП! p.s. - если б хоть половина преподавателей так же качественно доносило свои студентам материал, как и Вы, то уровень и кол-во выпускаемых, реально подготовленых специалистов был бы гораздо выше!
Андрей, здравствуйте. Разве не удобнее и логичнее было бы вместо использования сигналов о перегрузке от маршрутизатора использовать icmp сообщения - сразу напрямую отправителю сообщать о перегрузке на маршрутизаторе, нежели использовать сложную схему уведомления отправителя через получателя с установкой флагов в сообщениях разных уровней? Почему пошли именно таким путем, а не путем межсетевых управляющих сообщений?
ICMP работает на сетевом уровне, а TCP на транспортном. Когда придет пакет ICMP с сообщением о перегрузке, какому процессу его отправить? Непонятно. А в сегменте TCP указан порт, по нему можно определить процесс.
@@AndreySozykin таким образом получается, что если на хосте запущено 2 браузера, каждый из которых шлет сегменты через один и тот же перегруженный маршрутизатор, то маршрутизатору, уведомив один браузер о перегрузке, придется уведомить отдельно второй браузер о перегрузке? Так как эти браузеры работают с разных портов, то несмотря на то, что они запущены на одном хосте, процедуры уведомления их о перегрузке по технологии ecn будут не связаны между собой как бы каждая сама по себе будут проходить, верно?
@@Азамат-ш4з задался таким же вопросом. да что там разные браузеры - бери разные вкладки в одном браузере с одним сайтом - та же история🤣 ты разобрался в этом моменте? или забил?😁
5:50 говорится, что флаг защищает от злонамеренного изменения флагов ECN. Но не совсем понятно как это происходит. Неужели злоумышленник не может изменить/убрать оба флага, чтобы получать данные с большей скоростью?
1 Спасибо за крутые лекции 2 Я так и не понял буфер где находится? на маршрутизаторе? или на хосте? из предыдущих лекций вроде бы между транспортной системой и приложением т.е. на хосте, но в этой лекции вы говорите, что буфер маршрутизатора заполнен. Или он есть и там и там?
Какой смысл в Random Early Detection, если при использовании этого метода сегменты все равно отбрасываются, пусть даже и до того, как произойдет переполнение буфера? Это ведь, по сути, то же самое, как если бы Random Early Detection не работал, а буфер маршрутизатора имел бы меньшую вместимость и о перегрузке становилось бы известно только уже после потери сегмента.
Подскажите пожалуйста, как работает механизм ограничения скорости Интернет-соединения провайдером? В нем используется искусственное ограничение размера окна? Или применяется какой-то другой механизм?
Есть разные механизмы. Провайдер просто отбрасывает пакеты выше определенной пропускной способности. Ещё один вариант - Traffic Shaping: пакеты складываются в буфер на маршрутизаторе и выходят оттуда с фиксированной максимальной пропускной способностью - linkmeup.gitbook.io/sdsm/15.-qos/7.-ogranichenie-skorosti/1-traffic-shaping
@@AndreySozykin и каков примерный размер буфера у бытовых маршрутизаторов (которые ставят в квартиры)? о каком диапазоне идет речь? сотни мегабайт? гигабайт будет?
Здравствуйте! Не совсем понял, как именно получатель интерпретирует заголовок IP, обнаруживает в нем флаг перегрузки, а затем устанавливает соответствующие флаги уже в заголовке TCP? Ведь протоколы разного уровня и, пока пакет на стороне получателя поднимется до транспортного уровня и затем до уровня прикладного, заголовка IP он будет лишен...
Не совсем так. На практике логика работы сетевого ПО может нарушать уровни. Ведь когда кадр записан из сети в буфер на компьютере, ничего не мешает анализировать его целиком, включая заголовки всех уровней. Обычно так не делают, чтобы действовать в логике сетевых моделей. Но явного запрета нет.
Здравствуйте, спасибо за очередную серию. Рад, что вы быстро выпускаете уроки в последнее время. А все эти технологии по противодействию перегрузке вообще реально используюются, зашиты в ОС? А то у меня почему-то создаётся впечатление, что эти механизмы остались как дань истории, когда каналы были уже, чем сейчас.
+Sergey Ufimtsev, как раз наоборот, технологии управления перегрузкой стали по настоящему актуальны только когда появились современные быстрые каналы связи. TCP рассчитан на медленные каналы с большим количеством ошибок, поэтому размер окна увеличивается медленно (аддитивное увеличение). По некоторым оценкам, чтобы занять полосу пропускания 1Гб/с TCP требуется 1 час. При этом ни один сегмент не должен быть потерян, в противном случае окно уменьшается и увеличиваться будет очень долго. Сейчас придумывают много разных вариантов, как сделать так, чтобы TCP быстро разгонялся, но при этом не происходила перегрузка сети и одно соединение не вытесняло все другие (справедливость). Например, Google предложили технологию "Proportional Rate Reduction for TCP", которая была принята как RFC 6937 в 2013 году, и используется в Linux (ядро 3.2). В разных ОС поддерживается, как правило, несколько разных вариантов. Примеры можно посмотреть по ссылкам: en.wikipedia.org/wiki/TCP_congestion-avoidance_algorithm en.wikipedia.org/wiki/Taxonomy_of_congestion_control
+Sergey Ufimtsev, действительно, сейчас я стараюсь записывать минимум одно новое видео в неделю, а если позволяет время, то два: лекцию и практику. Это последняя лекция по TCP, после этого я планирую вернуться к началу курса и записать несколько недостающих роликов по теории, стеку TCP/IP и физическому уровню. После этого перейду к протоколам прикладного уровня.
Честно говоря, прослушав Ваши лекции по TCP я не вполне разобрался - что просиходит со стороны сервера. Вот допустим идут запросы на 80й порт на вебсервер от разных клиентов. Как различаются TCP сессии приходящие на один порт? Создается ли под каждую TCP сессию свой демон со случайным портом или обработка идет все таки через порт 80? Заранее благодарю.
@@AndreySozykin Спасибо. Вы создали очень хороший курс - все выдержано четко на одном уровне. Ничего лишнего, но все самое главное. Остальное можно нагуглить. Очень большой и достойный труд. Огромное спасибо.
Здравствуйте. Возникли вопросы. Заранее, спасибо! 1) На сетевом уровне пакеты ведь могут идти разными маршрутами. Выходит, что если один из пакетов пошёл неудачным маршрутом, то снизится скорость отправки по всем маршрутам, а не только по перегруженному. Верно? 2) Маршрутизатор ведь не должен дискреминировать между ip-пакетами на основе их содержимого. Получается, что сигнал о перегрузке должен добавляться и в ip-пакеты, которые идут от получателя к отправителю (ACK). Верно? Добавляется ли сигнал о перегрузке для всех пакетов в принципе (arp, icmp, udp, tcp, etc.) или же маршрутизаторы всё-таки смотрят на содержимое и сигнал добавляется только для пакетов с определённым типом содержимого (например, tcp)? Если сигнал добавляется всем пакетам, то как он используется в других вариантах помимо рассмотренного в видео?
1. Да, пакеты могут идти разными путями, но на практике это бывает редко. Один пакет может снизить размер окна один раз, но после этого снова будет рост. 2. Управление перегрузкой есть только в TCP. В UDP и ICMP нет понятия соединения, размера окна и гарантии доставки. ARP вообще работает только внутри одной сети и не проходит через маршрутизаторы.
Чтобы знать, получил ли отправитель сообщение с флагом ECE и уменьшил ли окно перегрузки. В противном случае получатель может много раз отправить сообщение с флагом ECE, и отправителю придется каждый раз уменьшать размер окна.
+Nikita Andrich, да, конечно может. Вполне вероятно, что несколько компьютеров независимо друг от друга начнут одновременно передавать большое количество данных. Они вполне способны переполнить буфер маршрутизатора еще до того, как придут сообщения о перезагрузке. ECN помогает обнаружить перегрузку раньше, чем это можно сделать с помощью других средств, но не полностью защищает от перегрузки.
+Nikita Andrich, к сожалению, не смог придумать хороший рисунок. Только если делать в динамике, например, так: 1. Исходная ситуация: данные передают несколько компьютеров, у каждого есть размер окна. Данные передаются, размер окна увеличивается. 2. На маршрутизаторе возникает перегрузка. Половина компьютеров получает сигнал от маршрутизатора, другая половина его не поддерживает. 3. Компьютеры, которые получили сигнал ECN снижают размер окна, остальные компьютеры увеличивают. Если используется AIMD, размер окна у первой половины компьютеров уменьшится в два раза, а вторая половина увеличит окна на 1 сегмент. 4. Из-за уменьшения размеров окна первая половина компьютеров будет передавать меньше данных, поэтому нагрузка на сеть снизится и перегрузки на маршрутизаторе не будет. Несправедливость заключается в том, что более "умные" компьютеры (которые понимают ECN), будут передавать данных меньше, а следовательно, медленнее, чем более "глупые" (которые не понимают ECN). Понятнее ли такое объяснение?
+Andrey Sozykin, спасибо стало намного понятнее. Тоже самое касается компьютеров с механизмами оповещения задержкой сигнала и потерей сигнала? Компьютеры с задержкой узнают о перегрузке раньше и снижают размер окна (перегрузка не происходит), а те, кто с потерей сигнала так и продолжают увеличивать.
+Nikita Andrich, окно управления потоком задается получателем, оно зависит от того, сколько место есть в буфере получателя. Если места нет, то получатель сам скажет об этом. Хотя возможен вариант, что мы сразу отправили так много данных, что они не поместились в буфер получателя. Поэтому получатель примет столько, сколько поместится, а остальные отбросит. Но для таких сегментов вообще не придет подтверждение. Сегменты как правило задерживаются на сетевом уровне. Например, два сегмента могут пойти через разные маршрутизаторы. На одном есть перегрузка, на другом нет. Или в процессе передачи вдруг сменится маршрут на маршрутизаторе. Или если между отправителем и получателем есть медленный участок сети, через который все пакеты проходят медленно.
+Nikita Andrich да, как правило учитывает. Но во всех ситуациях это сделать сложно. Учитывая, что размер кадра Ethernet 1500 байт, а передавать данных мы можем много (например, качать фильм на несколько Гб), то пакетов будет большое количество и почти всегда что-нибудь пойдет не так.
К сожалению, я почти не разбираюсь в Carrier Ethernet, поэтому вряд ли смогу сделать хорошую лекцию. Кроме того, Carrier Ethernet - это технология для операторов связи, поэтому на практике с ней мало кто сталкивается. В том числе и я никогда не сталкивался.
ruclips.net/video/H6rMGYRKI2s/видео.html в этом моменте наверное вы оговорились и хотели сказать "Для того чтобы предупредить получателя", а сказали отправителя. Спасибо за уроки:)
Бесценные лекции! Максимально внятная подача материала. Вы экономите нам просто кучу времени! Спасибо вам огромное!
Спасибо за хороший отзыв! Рад, что понравилось!
Мой первый комент на ютуб за очень долгое время пользования этим сервисом)
Андрей Владимирович, большое спасибо за проделанную Вами работу! Ваши лекции - ТОП!
p.s. - если б хоть половина преподавателей так же качественно доносило свои студентам материал, как и Вы, то уровень и кол-во выпускаемых, реально подготовленых специалистов был бы гораздо выше!
Андрей, огромное спасибо за Вашу работу! Изучал по Вашим урокам компьютерные сети, прошёл собеседование!!!
Спасибо что делаете такие понятные лекции!
Спасибо.
Qilgan bu yaxshi amallariyezni ajrini bersin.
Спасибо вам, Андрей!
Пожалуйста!
Очень интересно. Благодарю за урок!
Спасибо!
очень многое узнал, чего не знал раньше, спасибо большое
+conquistador, пожалуйста. Рад, что оказалось полезным.
на 2:24 у Вас в презентации кажется ошибка, "Надежность ниже чем у задержки сигнала", а правильно, чем у потери сигнала.
+Nikita Andrich, спасибо, действительно, ошибка. Добавил аннотация с правильным текстом.
Андрей, здравствуйте. Разве не удобнее и логичнее было бы вместо использования сигналов о перегрузке от маршрутизатора использовать icmp сообщения - сразу напрямую отправителю сообщать о перегрузке на маршрутизаторе, нежели использовать сложную схему уведомления отправителя через получателя с установкой флагов в сообщениях разных уровней?
Почему пошли именно таким путем, а не путем межсетевых управляющих сообщений?
ICMP работает на сетевом уровне, а TCP на транспортном. Когда придет пакет ICMP с сообщением о перегрузке, какому процессу его отправить? Непонятно.
А в сегменте TCP указан порт, по нему можно определить процесс.
@@AndreySozykin таким образом получается, что если на хосте запущено 2 браузера, каждый из которых шлет сегменты через один и тот же перегруженный маршрутизатор, то маршрутизатору, уведомив один браузер о перегрузке, придется уведомить отдельно второй браузер о перегрузке?
Так как эти браузеры работают с разных портов, то несмотря на то, что они запущены на одном хосте, процедуры уведомления их о перегрузке по технологии ecn будут не связаны между собой как бы каждая сама по себе будут проходить, верно?
@@Азамат-ш4з
задался таким же вопросом.
да что там разные браузеры - бери разные вкладки в одном браузере с одним сайтом - та же история🤣
ты разобрался в этом моменте? или забил?😁
5:50 говорится, что флаг защищает от злонамеренного изменения флагов ECN. Но не совсем понятно как это происходит. Неужели злоумышленник не может изменить/убрать оба флага, чтобы получать данные с большей скоростью?
заимел ответ на этот вопрос?:)
1 Спасибо за крутые лекции
2 Я так и не понял буфер где находится? на маршрутизаторе? или на хосте? из предыдущих лекций вроде бы между транспортной системой и приложением т.е. на хосте, но в этой лекции вы говорите, что буфер маршрутизатора заполнен. Или он есть и там и там?
Буферы есть и на хостах, и на маршрутизаторах.
@@AndreySozykin Понял, спасибо большое! С наступившими вас))
Какой смысл в Random Early Detection, если при использовании этого метода сегменты все равно отбрасываются, пусть даже и до того, как произойдет переполнение буфера? Это ведь, по сути, то же самое, как если бы Random Early Detection не работал, а буфер маршрутизатора имел бы меньшую вместимость и о перегрузке становилось бы известно только уже после потери сегмента.
тоже не понял этот момент.
ты как, нашел ответ за 4 года?:)
Подскажите пожалуйста, как работает механизм ограничения скорости Интернет-соединения провайдером? В нем используется искусственное ограничение размера окна? Или применяется какой-то другой механизм?
Есть разные механизмы. Провайдер просто отбрасывает пакеты выше определенной пропускной способности. Ещё один вариант - Traffic Shaping: пакеты складываются в буфер на маршрутизаторе и выходят оттуда с фиксированной максимальной пропускной способностью - linkmeup.gitbook.io/sdsm/15.-qos/7.-ogranichenie-skorosti/1-traffic-shaping
@@AndreySozykin спасибо!
@@AndreySozykin
и каков примерный размер буфера у бытовых маршрутизаторов (которые ставят в квартиры)? о каком диапазоне идет речь? сотни мегабайт? гигабайт будет?
Здравствуйте! Не совсем понял, как именно получатель интерпретирует заголовок IP, обнаруживает в нем флаг перегрузки, а затем устанавливает соответствующие флаги уже в заголовке TCP? Ведь протоколы разного уровня и, пока пакет на стороне получателя поднимется до транспортного уровня и затем до уровня прикладного, заголовка IP он будет лишен...
Не совсем так. На практике логика работы сетевого ПО может нарушать уровни. Ведь когда кадр записан из сети в буфер на компьютере, ничего не мешает анализировать его целиком, включая заголовки всех уровней. Обычно так не делают, чтобы действовать в логике сетевых моделей. Но явного запрета нет.
@@AndreySozykin Спасибо за ответ
@@AndreySozykin
хитренько:))
Спасибо
Здравствуйте, спасибо за очередную серию. Рад, что вы быстро выпускаете уроки в последнее время. А все эти технологии по противодействию перегрузке вообще реально используюются, зашиты в ОС? А то у меня почему-то создаётся впечатление, что эти механизмы остались как дань истории, когда каналы были уже, чем сейчас.
+Sergey Ufimtsev, как раз наоборот, технологии управления перегрузкой стали по настоящему актуальны только когда появились современные быстрые каналы связи. TCP рассчитан на медленные каналы с большим количеством ошибок, поэтому размер окна увеличивается медленно (аддитивное увеличение). По некоторым оценкам, чтобы занять полосу пропускания 1Гб/с TCP требуется 1 час. При этом ни один сегмент не должен быть потерян, в противном случае окно уменьшается и увеличиваться будет очень долго.
Сейчас придумывают много разных вариантов, как сделать так, чтобы TCP быстро разгонялся, но при этом не происходила перегрузка сети и одно соединение не вытесняло все другие (справедливость). Например, Google предложили технологию "Proportional Rate Reduction for TCP", которая была принята как RFC 6937 в 2013 году, и используется в Linux (ядро 3.2). В разных ОС поддерживается, как правило, несколько разных вариантов. Примеры можно посмотреть по ссылкам:
en.wikipedia.org/wiki/TCP_congestion-avoidance_algorithm
en.wikipedia.org/wiki/Taxonomy_of_congestion_control
+Sergey Ufimtsev, действительно, сейчас я стараюсь записывать минимум одно новое видео в неделю, а если позволяет время, то два: лекцию и практику.
Это последняя лекция по TCP, после этого я планирую вернуться к началу курса и записать несколько недостающих роликов по теории, стеку TCP/IP и физическому уровню. После этого перейду к протоколам прикладного уровня.
+Andrey Sozykin благодарю за развёрнутые ответы, буду с нетерпением ждать новых выпусков.
А как информация о перегрузке попадает в транспортный уровень, если заголовок IP, содержащий флаги перегрузки, отбрасывается на сетевом уровне?
присоединяюсь к вопросу.
пс
Андрей ответил на этот вопрос в другом комментарии; видео это же.
Честно говоря, прослушав Ваши лекции по TCP я не вполне разобрался - что просиходит со стороны сервера. Вот допустим идут запросы на 80й порт на вебсервер от разных клиентов. Как различаются TCP сессии приходящие на один порт? Создается ли под каждую TCP сессию свой демон со случайным портом или обработка идет все таки через порт 80? Заранее благодарю.
Надо смотреть видео про сокеты - ruclips.net/video/_vAjHdh92YU/видео.html
@@AndreySozykin Спасибо. Вы создали очень хороший курс - все выдержано четко на одном уровне. Ничего лишнего, но все самое главное. Остальное можно нагуглить. Очень большой и достойный труд. Огромное спасибо.
Assalomu alaykum, rahmat katta sizga
Спасибо!
Tema ochen intresnaya i dlya menya Vabsheta chtota NOVAYA )))
Spasibo ishyo raz
Пожалуйста. Рад, что оказалось полезным!
Здравствуйте. Возникли вопросы. Заранее, спасибо! 1) На сетевом уровне пакеты ведь могут идти разными маршрутами. Выходит, что если один из пакетов пошёл неудачным маршрутом, то снизится скорость отправки по всем маршрутам, а не только по перегруженному. Верно? 2) Маршрутизатор ведь не должен дискреминировать между ip-пакетами на основе их содержимого. Получается, что сигнал о перегрузке должен добавляться и в ip-пакеты, которые идут от получателя к отправителю (ACK). Верно? Добавляется ли сигнал о перегрузке для всех пакетов в принципе (arp, icmp, udp, tcp, etc.) или же маршрутизаторы всё-таки смотрят на содержимое и сигнал добавляется только для пакетов с определённым типом содержимого (например, tcp)? Если сигнал добавляется всем пакетам, то как он используется в других вариантах помимо рассмотренного в видео?
1. Да, пакеты могут идти разными путями, но на практике это бывает редко. Один пакет может снизить размер окна один раз, но после этого снова будет рост.
2. Управление перегрузкой есть только в TCP. В UDP и ICMP нет понятия соединения, размера окна и гарантии доставки. ARP вообще работает только внутри одной сети и не проходит через маршрутизаторы.
@@AndreySozykin спасибо!
@@AndreySozykin
люблю секцию вопрос-ответ в комментариях!!! добавляет понимания не хуже видео урока☝🏼☝🏼
Спасибо!
А зачем отправитель ставит флаг CWR, зачем получателю это нужно?
Чтобы знать, получил ли отправитель сообщение с флагом ECE и уменьшил ли окно перегрузки. В противном случае получатель может много раз отправить сообщение с флагом ECE, и отправителю придется каждый раз уменьшать размер окна.
4:36 Может ли буфер маршрутизатора заполниться, еще до передачи подтверждения обратно отправителю?
+Nikita Andrich, да, конечно может. Вполне вероятно, что несколько компьютеров независимо друг от друга начнут одновременно передавать большое количество данных. Они вполне способны переполнить буфер маршрутизатора еще до того, как придут сообщения о перезагрузке.
ECN помогает обнаружить перегрузку раньше, чем это можно сделать с помощью других средств, но не полностью защищает от перегрузки.
+Andrey Sozykin значит еще есть куда развивать технологию оповещения о перегрузке?)
+Nikita Andrich да, конечно ;)
2:30 про "Несправедливость" я плохо понял. Мне кажется, что на схеме или на рисунке, этот процесс был бы понятней.
+Nikita Andrich, к сожалению, не смог придумать хороший рисунок. Только если делать в динамике, например, так:
1. Исходная ситуация: данные передают несколько компьютеров, у каждого есть размер окна. Данные передаются, размер окна увеличивается.
2. На маршрутизаторе возникает перегрузка. Половина компьютеров получает сигнал от маршрутизатора, другая половина его не поддерживает.
3. Компьютеры, которые получили сигнал ECN снижают размер окна, остальные компьютеры увеличивают. Если используется AIMD, размер окна у первой половины компьютеров уменьшится в два раза, а вторая половина увеличит окна на 1 сегмент.
4. Из-за уменьшения размеров окна первая половина компьютеров будет передавать меньше данных, поэтому нагрузка на сеть снизится и перегрузки на маршрутизаторе не будет.
Несправедливость заключается в том, что более "умные" компьютеры (которые понимают ECN), будут передавать данных меньше, а следовательно, медленнее, чем более "глупые" (которые не понимают ECN).
Понятнее ли такое объяснение?
+Andrey Sozykin, спасибо стало намного понятнее. Тоже самое касается компьютеров с механизмами оповещения задержкой сигнала и потерей сигнала? Компьютеры с задержкой узнают о перегрузке раньше и снижают размер окна (перегрузка не происходит), а те, кто с потерей сигнала так и продолжают увеличивать.
+Nikita Andrich, да для компьютеров, которые анализируют задержку сигнала это тоже относится.
А нет данных о высокочастотных линиях, передача по электрическим проводам -- интересная тема
+Sasha Gedz, к сожалению, у меня нет. В этом я не специалист.
Andrey Sozykin Самое интересное у нас на работе есть канал с такой связью и никто не знает как оно работает - эх. Как курс Ваш закончу в книги =)
@@shmulful ну что там, разобрался?
@@w1tcherj теперь да
@@shmulful расскажешь?
пасибо
Какими еще причинами может быть вызвана задержка сегмента? Перегрузкой окна управления потоком? Можете чуть подробней объяснить?
+Nikita Andrich, окно управления потоком задается получателем, оно зависит от того, сколько место есть в буфере получателя. Если места нет, то получатель сам скажет об этом.
Хотя возможен вариант, что мы сразу отправили так много данных, что они не поместились в буфер получателя. Поэтому получатель примет столько, сколько поместится, а остальные отбросит. Но для таких сегментов вообще не придет подтверждение.
Сегменты как правило задерживаются на сетевом уровне. Например, два сегмента могут пойти через разные маршрутизаторы. На одном есть перегрузка, на другом нет. Или в процессе передачи вдруг сменится маршрут на маршрутизаторе. Или если между отправителем и получателем есть медленный участок сети, через который все пакеты проходят медленно.
+Andrey Sozykin А механизм маршрутизации как правило же учитывает загрузку каналов связи и маршрутизаторов при отправке пакетов?
+Nikita Andrich да, как правило учитывает. Но во всех ситуациях это сделать сложно. Учитывая, что размер кадра Ethernet 1500 байт, а передавать данных мы можем много (например, качать фильм на несколько Гб), то пакетов будет большое количество и почти всегда что-нибудь пойдет не так.
Здравствуйте. А будут ли выпуски по поводу Carrier Ethernet?
К сожалению, я почти не разбираюсь в Carrier Ethernet, поэтому вряд ли смогу сделать хорошую лекцию. Кроме того, Carrier Ethernet - это технология для операторов связи, поэтому на практике с ней мало кто сталкивается. В том числе и я никогда не сталкивался.
Andrey Sozykin, Хорошо, спасибо за ответ
@@ruslanalpysbayev1209
привет. прошло 8 лет - нашел хорошее видео про Carrier Ethernet?🤔
сложно жесть :(
ruclips.net/video/H6rMGYRKI2s/видео.html в этом моменте наверное вы оговорились и хотели сказать "Для того чтобы предупредить получателя", а сказали отправителя. Спасибо за уроки:)
всё верно было, отправителя нужно предупредить, что бы меньше отправлял.
4:07
Спасибо!
Спасибо
Пожалуйста!