Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Включение поддержки HTTP/3 в Firefox намечено на конец мая, opennews (?), 17-Апр-21, (0) [смотреть все] Скрыто модератором, iPony129412 (?), 08:46 , 17-Апр-21, (1) –11 // Скрыто модератором, Леголас (ok), 08:50 , 17-Апр-21, (2) // Скрыто модератором, pisyandrik (ok), 09:03 , 17-Апр-21, (7) +4 // Скрыто модератором, Леголас (ok), 09:13 , 17-Апр-21, (8) Скрыто модератором, Аноним (22), 10:10 , 17-Апр-21, (22) +3 Скрыто модератором, КО (?), 09:31 , 17-Апр-21, (12) Скрыто модератором, Аноним (-), 23:44 , 17-Апр-21, (51) Скрыто модератором, Аноним (3), 08:51 , 17-Апр-21, (3) Скрыто модератором, Аноним (14), 09:33 , 17-Апр-21, (14) +2 // Скрыто модератором, Аноним (14), 18:52 , 22-Апр-21, (107) Скрыто модератором, kravich (ok), 10:05 , 17-Апр-21, (20) –1 // Скрыто модератором, РУСТофил (?), 10:08 , 17-Апр-21, (21) –1 // Скрыто модератором, rinat85 (ok), 11:03 , 17-Апр-21, (27) +3 Скрыто модератором, Аноним (26), 10:56 , 17-Апр-21, (26) +4 Интересно как Кто в курсе дайте ссылку на алгоритмы Если использовать просто д, Аноним (5), 08:59 , 17-Апр-21, (5) +1   // Например вот так https www opennet ru docs RUS inet_book 2 28 corec_28 htmlЧто, Аноним (9), 09:16 , 17-Апр-21, (9) +2   // Процент битых пакетов в сети - один на миллион Несоизмеримо чаще ситуация, когд, Урри (ok), 11:23 , 17-Апр-21, (29) +1   // Согласен, это определенный оверхед, однако при всём при этом сервер может поправ, Аноним (9), 12:23 , 17-Апр-21, (34)   Угу, теперь попробуй это по вафле с соседом качающим торент или мобильному линку, Аноним (-), 23:47 , 17-Апр-21, (52) +1   Можно добавлять один пакет с ECC на 100 пакетов допустим Который позволит восста, Онаним (?), 20:18 , 19-Апр-21, (77)   Ищите по QUIC-FEC, но мне кажется это сих пор находится в зачаточном состоянии , Аноним (23), 10:20 , 17-Апр-21, (23) +1   // Да, это в планах Additionally, the protocol can be extended with forward error, Аноним (23), 10:29 , 17-Апр-21, (24) +1   Только в каких-то синтетических тестах такое может произойти, из за мизерного тр, Аноним (43), 18:48 , 17-Апр-21, (43) +2   // Физический уровень видите ли затратно переделывать - никто не будет резко менять, Аноним (-), 23:52 , 17-Апр-21, (53)   Если коррекция ошибок способна восстановить 10 пакетов из 100 - она способна вос, Онаним (?), 20:20 , 19-Апр-21, (78)   // Но ценой увеличения трафика на 10 , чудес не бывает Повторная же передача увели, Аноним (43), 04:21 , 20-Апр-21, (86)   На последних метрах если это не копеечные Ethernet свитчи, а какой-нибудь VDSL , Онаним (?), 09:46 , 20-Апр-21, (87)   А беспроводных линков в вашей картине мира вообще не существует Там конечно FEC, Аноним (-), 05:40 , 21-Апр-21, (94)   На пользовательских беспроводных линках единичные потери как раз частый случай, Онаним (?), 09:56 , 21-Апр-21, (103)   1 Обычно даже больше чем на 10 2 На хороших линках можно понизить градус ил, Аноним (-), 05:33 , 21-Апр-21, (93)   Странно, что никто до сих пор по поводу Rust не оскорбился как же так Где ва, Аноним (10), 09:29 , 17-Апр-21, (10) +1 // Фрактала ждём , YetAnotherOnanym (ok), 09:38 , 17-Апр-21, (15) +3 А чего оскорбляться-то Тут умные люди, и даже те, кому он чем-то не нравится ч, Аноним (35), 13:27 , 17-Апр-21, (35) –2 // Но ведь явно назрела необходимость в альтернативе, в которой краб, говорящий хел, Ыноним (?), 22:30 , 18-Апр-21, (66) Да пофиг всем на раст И в новости про фф заходят только поржать , Аноним (45), 19:11 , 17-Апр-21, (45) –1 Хз, сколько раз включал по приколу в FF всяческие QUIC, HTTP 2, HTTP 3, столько , dalco (ok), 09:42 , 17-Апр-21, (17) –1 // Потому что сначала пробуется новое , не работает - откатывается на старое На п, Total Anonimus (?), 09:49 , 17-Апр-21, (19) –2 // Ох уж это поколение смузи Сначала надо подумать , проработать архитектуру, п, Урри (ok), 11:26 , 17-Апр-21, (30) –4 // Так в теории и на сайтах поддерживающих - всё в шоколаде Только в реальности, Total Anonimus (?), 12:03 , 17-Апр-21, (33) +1 Мне вот даже стало интересно А нельзя ли было изменить URL на http3s example , Аноним (43), 19:07 , 17-Апр-21, (44) Именно поэтому А они ещё и аппаратные бывают , Аноним (45), 19:14 , 17-Апр-21, (46) Ну, как, протокол который будет застревать на всех фаерах и натах использовать м, Аноним (-), 23:56 , 17-Апр-21, (54) На этапе реализации стандарта QUIC HTTP 3 уже подумали и посчитали Только реа, kai3341 (ok), 17:07 , 17-Апр-21, (40) +2 Исправьте хоть что-нибудь за конечное время в сетевом стеке виндов Это уже явно , Аноним (-), 23:58 , 17-Апр-21, (55) –1 Любой инженер скажет тебе что для любой достаточно большой системы этот мир дост, Аноним (-), 05:47 , 21-Апр-21, (95) я тестил на сайте заказчика, включение HTTP 2 замедляло загрузку на несколько пр, kissmyass (?), 11:14 , 17-Апр-21, (28) –3 // Ну вот кстати факт HTTP 2 убирает затраты на дополнительные соединения, но по ср, Онаним (?), 20:24 , 19-Апр-21, (79) // контент собран, в приложении все активно бандлится, js, css и т д , львииный объ, kissmyass (?), 21:41 , 19-Апр-21, (81) А вот делали бы как нынешние конфетковерстальщики - 100500 css, 100500 ajax ов т, Онаним (?), 00:21 , 20-Апр-21, (85) ЧСХ и засияет Как и HTTP 3 , Аноним (-), 05:48 , 21-Апр-21, (96) http 2 работает стабильно , Аноним (71), 08:32 , 19-Апр-21, (71) Ну положим HTTP2 уже давно не тестовый, и внедряется уже весьма широко , Kuromi (ok), 23:01 , 20-Апр-21, (90) // Так это не сейчас, а лет сколько-то назад, когда вышла такая же новость в соста, dalco (ok), 04:05 , 21-Апр-21, (92) // А сейчас он уже много лет как включен у всех по дефолту - и просто работает А о, Аноним (-), 05:50 , 21-Апр-21, (97) Очень даже может быть На самом деле мой пост был вовсе не о том, что новые пр, dalco (ok), 05:59 , 21-Апр-21, (99) Что , Аноним (25), 10:43 , 17-Апр-21, (25) // А что Летим вперёд со всё большей и большей скоростью , quicist (?), 11:31 , 17-Апр-21, (31) // Летим Жопой вперёд , Аноним (42), 18:37 , 17-Апр-21, (42) +3 // Это же гаргулья из первых Heroes of Might and Magic Там еще и ручка W хвост ест, Аноним (-), 00:59 , 19-Апр-21, (67) +1 Хттп1 1 всем хватит Ишь чо удумоле еще на 2 не перешел никто а уже 3 добавляют , msgod (ok), 11:33 , 17-Апр-21, (32) +1 // Ютуб перешёл, например , Номномом (?), 16:29 , 17-Апр-21, (38) // На самом деле много кто перешел Позырьте нетконсольку в процессе браузинга А х, Аноним (-), 01:00 , 19-Апр-21, (68) // Необязательно смотреть в консоль Пока Proton еще не включили можно использовать, Kuromi (ok), 23:04 , 20-Апр-21, (91) Я не знаю что там за протоны и электроны у вебмакак сейчас, но по вон той метрик, Аноним (-), 05:52 , 21-Апр-21, (98) 2 нужен только сайтам с огромной кучей очень мелких файлов из за которых клиенты, Аноним (43), 19:32 , 17-Апр-21, (47) +2 // А также двум легионам всяких мобильных неу дачников и прочих желающих пользоват, Аноним (-), 00:04 , 18-Апр-21, (56) +1 // В этом случае http3 не поможет Он ничего не сможет сделать, если Вы потеряли 90, Аноним (43), 04:04 , 18-Апр-21, (57) Еще как поможет - вместо сношений с идиотией встроенных в ОС congestion control , Аноним (-), 01:07 , 19-Апр-21, (69) В этом случае должны спасать кеши, в которые предварительно накачиваются следующ, rvs2016 (ok), 11:13 , 19-Апр-21, (73) 1 С лагами TCP по цать секунд он иногда проигрывает теорвер настолько, что при , Аноним (-), 06:05 , 21-Апр-21, (100) https w3techs com technologies details ce-http2, Аноним (60), 10:48 , 18-Апр-21, (60) Хорошая опция, обязательно её выключу , Аноним (37), 16:22 , 17-Апр-21, (37) –1 // я вообще фокса поставлю в бан на оюнову иногда фтпшки использую можно конечно , анонимуслинус (?), 22:18 , 18-Апр-21, (65) Враньё про производительность Какой то мир вранья сплошной потепление, кетайска, Ivan_83 (ok), 17:00 , 17-Апр-21, (39) +5 Активировал Ютуб - пока особо не заметил разницы А вот FB, вроде по шустрее ст, th3m3 (ok), 18:11 , 17-Апр-21, (41) // Там сейчас весь код выглядит так Если http 3 То оптимизированный_код Иначе , Аноним (48), 19:51 , 17-Апр-21, (48) +1 Объясните в чём прикол однопоточности http2 3 Разве чем больше потоков как в h, Начальника (?), 05:18 , 18-Апр-21, (58) +1 // Отнопоточные они только с виду Внутри прячутся собственные потоки с более низки, Аноним (43), 07:20 , 18-Апр-21, (59) –1 // Дак гугл недавно как раз рассказывал, что это оказалось тормозом и забитием кана, Аноним (48), 11:39 , 18-Апр-21, (61) Нормальные браузеры уже давно так делают, чем дальше картинка от амбразуры просм, Аноним (48), 11:40 , 18-Апр-21, (62) // P S Тем более, что браузеры запоминают ещё и позицию скрола на странице, и когд, Аноним (48), 11:43 , 18-Апр-21, (63) Браузеры это делают через приостановку приёма данных через сокет, но во первых б, Аноним (43), 11:52 , 18-Апр-21, (64) –1 LiteSpeed тоже поддерживает http3 но только в платной версии , Аноним (71), 08:30 , 19-Апр-21, (70) // С учетом наличия толпы халявных реализаций творческих им узбеков , Аноним (-), 06:09 , 21-Апр-21, (101) +1 Ну и как этот хттп3 реально применять не только гуглам да фейсбукам, но ещё и на, rvs2016 (ok), 11:35 , 19-Апр-21, (74) Ну и как это работает 129300 Похоже, что вообще никак - в about networking вс, Аноним (111), 18:04 , 31-Окт-21, (111) 5,10,17,25,32,37,39,41,58,70,74,111

Сообщения

[Сортировка по времени | RSS]

5. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+1 +/–
Сообщение от Аноним (5), 17-Апр-21, 08:59
> Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета. Интересно как? Кто в курсе дайте ссылку на алгоритмы. Если использовать просто дубляж данных, то общий трафик вырастет, а в протоколе выше заявлено уменьшение трафика по сравнению с TCP с классическим методом коррекции ошибок - запросом некоректного пакета.
Ответить | Правка | Наверх | Cообщить модератору

	9. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+2 +/–
	Сообщение от Аноним (9), 17-Апр-21, 09:16
	Например вот так https://www.opennet.ru/docs/RUS/inet_book/2/28/corec_28.html Что конкретно используется в HTTP/3 не знаю
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+1 +/–
	Сообщение от Урри (ok), 17-Апр-21, 11:23
	Процент битых пакетов в сети - один на миллион. Несоизмеримо чаще ситуация, когда они просто не приходят. Поэтому добавлять поверх существующей чексумы еще и какие-нибудь коды грея, это совершенно лишняя трата трафика.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+/–
	Сообщение от Аноним (9), 17-Апр-21, 12:23
	Согласен, это определенный оверхед, однако при всём при этом сервер может поправить битый пакет сам, не запрашивая его вновь, а какой там процент битых, 1/1е6 или 1/100, уж лучше скажут профессионалы с какой-либо статистикой на руках, не нам об этом судить. Напоминаю, что о конкретном алгоритме коррекции в HTTP/3 не знаю ничего, лучше почитать драфт стандарта
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+1 +/–
	Сообщение от Аноним (-), 17-Апр-21, 23:47
	> Процент битых пакетов в сети - один на миллион Угу, теперь попробуй это по вафле с соседом качающим торент или мобильному линку на грани приема. А то что ты там можешь в датацентре напрямую в сервак патчкордом воткнуться - здорово, конечно, но патчкорд у тебя все же фуфельный.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	77. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+/–
	Сообщение от Онаним (?), 19-Апр-21, 20:18
	Можно добавлять один пакет с ECC на 100 пакетов допустим. Который позволит восстановить любой из 100 пакетов при потере. Правда ресурс проца это пожрёт слегка.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	23. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+1 +/–
	Сообщение от Аноним (23), 17-Апр-21, 10:20
	Ищите по QUIC-FEC, но мне кажется это сих пор находится в зачаточном состоянии.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	24. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+1 +/–
	Сообщение от Аноним (23), 17-Апр-21, 10:29
	Да, это в планах. "Additionally, the protocol can be extended with forward error correction (FEC) to further improve performance when errors are expected, and this is seen as the next step in the protocol's evolution."
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+2 +/–
	Сообщение от Аноним (43), 17-Апр-21, 18:48
	>а в протоколе выше заявлено уменьшение трафика по сравнению с TCP >с классическим методом коррекции ошибок - запросом некоректного пакета. Только в каких-то синтетических тестах такое может произойти, из за мизерного трафика от самих запросов повторной отправки и заголовков IP пакета вместе с TCP, но только если коррекция ошибок настроена на 10% потерь и в канале как раз ровно 10% потерь. Такую коррекцию ошибок плохих каналов лучше делать на физическом уровне, а не на уровне приложения. Профит состоит только в том, что YouTube начнёт открываться быстрее на очень плохих каналах за счёт отказа от буферизации. Зачем это делать на уровне приложения? Ну Google не Cisco, где могут, там и внедряют свои хотелки.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	53. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+/–
	Сообщение от Аноним (-), 17-Апр-21, 23:52
	Физический уровень видите ли затратно переделывать - никто не будет резко менять все wifi роутеры и соты только потому что вам кажется что это круто. Более того - вон то не поможет если какой-то дурной линк или роутер по пути 10% пакетов теряет. Так что на самом деле _адаптивный_ механизм, когда FEC запрашивается/усиливается если линк не ахти, и не делается/делается минимально если линк ОК. А в чем проблема? TCP погано работает на беспроводных линках, как только условия приема отличаются от идеала, TCP выпадает в совершенно чебурашью скорость и невменяемый RTT. А пытаться сделать идеальный линк из беспроводки дохлый номер. Ну вот едет юзер между сотами, прием то есть, то нет. Для TCP это "переруз канала", айда с ним бороться. Юзер уже пару сот проеахл с отличным линком, а крап из эпохи диалапа ...цатисекундный таймаут во имя богов congestion'а отсчитывает. Извиние, но так работать нельзя.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+/–
	Сообщение от Онаним (?), 19-Апр-21, 20:20
	Если коррекция ошибок способна восстановить 10 пакетов из 100 - она способна восстановить и 9, и 8, и 7, и 1. Т.е. будет работать на любых каналах с <= 10/100 потерь (не усреднять до 10%).
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	86. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+/–
	Сообщение от Аноним (43), 20-Апр-21, 04:21
	Но ценой увеличения трафика на 10%, чудес не бывает. Повторная же передача увеличивает трафик исключительно по необходимости. Конечно избыточность можно регулировать вплоть до нуля, но при превышении процента потерь всё равно потребуются повторные передачи. Поэтому я и считаю, что проблему последних метров, нужно решать на последних метрах. К тому же всё ещё остаётся вопрос: как регулировать скорость канала, если нам неизвестна причина потерь? Ведь если все начнут реагировать на перегрузку канала, увеличением избыточности, то потерь будет становиться всё больше и больше и больше.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+/–
	Сообщение от Онаним (?), 20-Апр-21, 09:46
	На последних метрах (если это не копеечные Ethernet свитчи, а какой-нибудь VDSL/GPON) - они как раз таки и решаются FEC/ECC. Увеличение избыточности может привести к дополнительным потерям, но в случае этих самых дополнительных потерь начинает срабатывать стандартная перепосылка, поэтому в этом плане ничего не теряется - некоторый уровень избыточности + перепосылка при фейлах такового. Сейчас ситуация достаточно проста: пропускные способности каналов наращиваются. А вот с задержками не сделать банально ничего, и при переотправке задержки начинают играть существенную роль. FEC - это трейдофф между некоторым избыточным использованием полосы и собственно влиянием дополнительных задержек на переотправку, которых FEC позволяет избежать. Поэтому оно оправдано.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+/–
	Сообщение от Аноним (-), 21-Апр-21, 05:40
	> На последних метрах (если это не копеечные Ethernet свитчи, а какой-нибудь VDSL/GPON) > - они как раз таки и решаются FEC/ECC. А беспроводных линков в вашей картине мира вообще не существует? Там конечно FEC тоже бывает. Но таки в специфичном виде и никакой FEC канального уровня ничего не сделает с тем фактом что вы вообще выпали из зоны действия соты на 10 секунд. Он на такое тупо не расчитан. А TCP за это время решит что перегруз и начнет тупить как слизняк. > Увеличение избыточности может привести к дополнительным потерям, но в случае этих самых > дополнительных потерь начинает срабатывать стандартная перепосылка, поэтому в этом плане > ничего не теряется - некоторый уровень избыточности + перепосылка при фейлах такового. Данные с FEC можно до известного предела не перепосылать совсем. DVB-T вон вообще наглухо односторонний. И он либо полностью декодабелен, либо вот вам черный экран. Последнее кстати частично подбешивает юзерей, так что для 2-сторонних линков есть интересные эксперименты с graceful degradation подобного потока когда разрешение/FPS/качество кодирования снижают. Ессно это не для обычных применений а для видео юзают. > Сейчас ситуация достаточно проста: пропускные способности каналов наращиваются. А вот > с задержками не сделать банально ничего, и при переотправке задержки начинают > играть существенную роль. Более того - то что TCP вытворяет при каком-нибудь выпадении соты на 10 секунд "потому что юзер едет в транспортте" не лезет ни в какие ворота. Чо-чо, максимальный таймаут 60 секунд, чтоли, чтобы не забить какой там T1 ссаный на котором при диалапе висел целый легион? А ща у хомячков даже спутниковые линки другие велечины имеют, Элонмаск подтвердит. > FEC - это трейдофф между некоторым избыточным использованием полосы и собственно > влиянием дополнительных задержек на переотправку, которых FEC позволяет избежать. > Поэтому оно оправдано. В ряде случаев похоже таки да. Особенно когда девы TCP/IP демонстрируют полную творческую импотенцию, доказывая что экспериенс уровня диалапа на многомегабитном беспроводном линке так и задуман.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+/–
	Сообщение от Онаним (?), 21-Апр-21, 09:56
	> А беспроводных линков в вашей картине мира вообще не существует? На "пользовательских" беспроводных линках единичные потери как раз частый случай, кстати. Просто из-за шума в среде, с которым линейный ECC самого линка не справляется.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Включение поддержки HTTP/3 в Firefox намечено на конец мая"	+/–
	Сообщение от Аноним (-), 21-Апр-21, 05:33
	> Но ценой увеличения трафика на 10%, чудес не бывает. 1) Обычно даже больше чем на 10%. 2) На хороших линках можно "понизить градус" или вообще не пользоваться этим. > Повторная же передача увеличивает трафик исключительно по необходимости. С другой стороны, она дает penalty величиной в RTT канала сама по себе. В это время канал попросту бездействует. Просто потому что ремота еще не знает что пакеты вообще надо послать. А тот миндфак который в TCP сделали к тому же восходит к временам диалапа и проч и умеет коллапсировать в совершенно идиотские величины задержек между повторными попытками. И когда толпа гранд-комитет-нечто и ветеран-чтототам не может справиться с очевидными сетевыми проблемами, демонстрируя "designed by committee" в хучшем вид, корпы таки решат проблему и без их участия, сделав так чтобы для их юзерей все просто работало, а канали и оборудование не простаивали. Обратное ставит их на бабки. > Конечно избыточность можно регулировать вплоть до нуля, но при превышении > процента потерь всё равно потребуются повторные передачи. FEC можно задизайнить под почти произвольный процент потерь. Просто процент оверхеда будет невкусный, но это может работать даже на односторонних линках. DVB-T и космические линки так и делают. В DVB видите ли зомбоящики передавать не умеют, а в космических линках - ну вон до марса пинг в 1 сторону 2 часа, чтоли по поводу чего перезапрос это минимум 4 часа канала вхолостую. Простой пример: если слать по 10 одинаковых пакетов, потери 20% не такая уж и проблема. В среднем будет выпадать лишь 2 из 10 и в целом будет декодабельно. С очень редкими выпадениями. Это правда неэффективно, есть сильно более удачные идеи. Кстати можно гонять FEC поверх FEC (interleaving) так что невозможность декода приведет не к недекодабельности вон того пакета, а к тому что после de-interleave декодированы все пакеты но в них в каждом побит допустим 10-й байт. С чем прекрасно справится "внутренний" FEC. CD-ROM так делает, по поводу чего кой-как живет даже с царапинами и довольно серьезным BER чтения. > Поэтому я и считаю, что проблему последних метров, нужно решать на последних метрах. Удачи в этом направлении для радиолинков всех мастей и направлений. Представляете, юзеры ща не хотят в кафушке к эзернету стыковаться. И едучи в поезде мувик посмотреть тоже так то мало кто отказался бы. > К тому же всё ещё остаётся вопрос: как регулировать скорость канала, если нам > неизвестна причина потерь? У настоящего congestion есть сопутствующие атрибуты - например рост RTT. Это можно пытаться детектить. Но вообще-то если где-то есть congestion, вот к нему и надо применить вон ту логику - как то устранить эту проблему, а не пытаться с ним сюсюкаться на уровне протоколов факапя десятки других юзкейсов. > Ведь если все начнут реагировать на перегрузку канала, увеличением избыточности, > то потерь будет становиться всё больше и больше и больше. Возможно, это вообще сойдет за фичу - ленивые админы и жадные провы наконец снимутся с ручника. Или потеряют кастомеров на своих бельевых веревках, и проблема решится другим методом.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема