forum.opennet.ru - "Google намерен использовать в Chrome по умолчанию сетевой пр..." (85)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Google намерен использовать в Chrome по умолчанию сетевой пр..."

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

"Google намерен использовать в Chrome по умолчанию сетевой пр..."	+1 +/–
Сообщение от opennews (??) on 18-Апр-15, 19:59
Компания Google представила (http://blog.chromium.org/2015/04/a-quic-update-on-googles-ex...) планы продвижения сетевого протокола QUIC (https://www.chromium.org/quic/playing-with-quic) (Quick UDP Internet Connections), который уже около двух лет развивается в качестве альтернативы связки TCP+TLS для Web, решающей проблемы с достаточным большим временем установки и согласования соединений и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC уже не только интегрирован в серверную инфраструктуру Google и включён (https://src.chromium.org/viewvc/chrome/trunk/src/net/quic/) в состав Chrome, но и последние три месяца применяется для обслуживания примерно половины всех запросов к серверам Google из браузера Chrome. В дальнейшем планируется перевести QUIC в разряд используемого по умолчанию транспортного протокола для Chrome и мобильных приложений Google. Кроме того, Google собирается начать процесс продвижения QUIC в качестве интернет-стандарта, после проведения модернизации эталонной реализации и формата протокола. Из планов отмечается замена схемы SPDY-поверх-QUIC на HTTP2-поверх-QUIC, сокращение накладных расходов на согласование соединения, улучшение системы упреждающей коррекции ошибок, улучшение методов контроля перегрузки и добавление поддержки multipath-соединений (доставка пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам). QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования эквивалентные TLS/SSL. Главным преимуществом протокола QUIC, особенно актуальным для мобильных систем, является возможность мгновенно установить соединение и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time). Организация работы поверх UDP, без внедрения нового первичного протокола, позволяет использовать QUIC на существующих системах без необходимости модификации сетевого стека. Проведённая в реальных условиях оценка производительности, показала, что QUIC обеспечивает реальный прирост производительности, по сравнению с TCP. Например, реализованная в QUIC возможность отправки данных до согласования соединения позволила добиться ускорения в 75% случаев. Даже для таких оптимизированных сайтов как Google Search, в которых применяется техника упреждающей установки соединения, при использовании QUIC время загрузки сократилось на 3%. Для 1% соединений, для которых использованы плохие каналы связи, ускорение составило более секунды. Подобный эффект достигается благодаря отсутствию задержек при потере пакетов - QUIC не использует при повторной передаче пакета тот же номер в последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%. <center><a href="https://lh3.googleusercontent.com/o62Ohn1Ppxna6zz0NtavqRyetj... src="http://www.opennet.me/opennews/pics_base/0_1429374296.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center> Основные особенности (https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...) QUIC: - Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP); - Почти мгновенная установка соединения (часто 0-RTT, т.е. данные можно передавать сразу после отправки пакета установки соединения), похожая на комбинацию TLS Snapstart (http://tools.ietf.org/html/draft-agl-tls-snapstart-00) и TCP Fast Open (http://en.wikipedia.org/wiki/TCP_Fast_Open); - Контроль за целостностью потока, предотвращающий потерю пакетов; - Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета. Криптографические границы блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов; - Отсутствие проблем с блокировкой очереди TCP; - Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках; - Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов; - Возможность подключения расширенных механизмов контроля перегрузки соединения; - Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов. URL: http://blog.chromium.org/2015/04/a-quic-update-on-googles-ex... Новость: http://www.opennet.me/opennews/art.shtml?num=42063
Ответить \| Правка \| Cообщить модератору

Оглавление

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 19:59 , 18-Апр-15, (1) –3

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 07:46 , 19-Апр-15, (48) +7

Google намерен использовать в Chrome по умолчанию сетевой пр..., A.Stahl, 20:36 , 18-Апр-15, (4) –10

Google намерен использовать в Chrome по умолчанию сетевой пр..., Вася ты не прав, 21:06 , 18-Апр-15, (7) +12

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 21:10 , 18-Апр-15, (9) –2

Google намерен использовать в Chrome по умолчанию сетевой пр..., A.Stahl, 21:18 , 18-Апр-15, (10)
Google намерен использовать в Chrome по умолчанию сетевой пр..., Омоним, 23:51 , 18-Апр-15, (26) +4

Google намерен использовать в Chrome по умолчанию сетевой пр..., И ты чушь пишешь, 22:30 , 18-Апр-15, (20) –13

Google намерен использовать в Chrome по умолчанию сетевой пр..., Вася ты не прав, 02:18 , 19-Апр-15, (30) +5
Google намерен использовать в Chrome по умолчанию сетевой пр..., Тююю, 12:38 , 20-Апр-15, (100) +2

Google намерен использовать в Chrome по умолчанию сетевой пр..., Раб прогресса, 21:18 , 18-Апр-15, (11) +1

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 11:29 , 19-Апр-15, (72) –3

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 15:40 , 19-Апр-15, (79) +1

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 07:28 , 19-Апр-15, (45) +3

Google намерен использовать в Chrome по умолчанию сетевой пр..., Ктото гдето, 07:29 , 20-Апр-15, (88)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 08:14 , 20-Апр-15, (89) +1

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 21:20 , 18-Апр-15, (12) +9

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 22:24 , 18-Апр-15, (18) –2

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 23:16 , 18-Апр-15, (25) +5

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 04:07 , 19-Апр-15, (37)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 07:33 , 19-Апр-15, (46)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Xasd, 15:08 , 19-Апр-15, (78)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 16:59 , 19-Апр-15, (81)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Xasd, 17:12 , 19-Апр-15, (82)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 08:21 , 20-Апр-15, (90) +1

Google намерен использовать в Chrome по умолчанию сетевой пр..., Какаянахренразница, 22:06 , 18-Апр-15, (17) +4

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 07:26 , 19-Апр-15, (44) +4

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 22:24 , 18-Апр-15, (19) +2

Google намерен использовать в Chrome по умолчанию сетевой пр..., _KUL, 04:18 , 19-Апр-15, (39) +3

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 07:56 , 19-Апр-15, (50)
Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 08:05 , 19-Апр-15, (54)

Google намерен использовать в Chrome по умолчанию сетевой пр..., all_glory_to_the_hypnotoad, 15:01 , 19-Апр-15, (77)
Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 17:35 , 20-Апр-15, (110)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 22:32 , 18-Апр-15, (21) +2

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 18:43 , 19-Апр-15, (83) +1

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 23:49 , 19-Апр-15, (85)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 12:08 , 20-Апр-15, (99)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Андрей, 22:45 , 18-Апр-15, (22) +9
Google намерен использовать сетевой протокол QUIC в браузере..., th3m3, 00:10 , 19-Апр-15, (27) +2

Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 04:12 , 19-Апр-15, (38)

Google намерен использовать сетевой протокол QUIC в браузере..., th3m3, 03:29 , 19-Апр-15, (33)

Google намерен использовать сетевой протокол QUIC в браузере..., Crazy Alex, 11:53 , 19-Апр-15, (74)

Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 03:33 , 19-Апр-15, (34)

Google намерен использовать сетевой протокол QUIC в браузере..., Фтщт, 13:28 , 19-Апр-15, (75)

Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 03:42 , 19-Апр-15, (35)
Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 03:54 , 19-Апр-15, (36)
Google намерен использовать сетевой протокол QUIC в..., arisu, 06:53 , 19-Апр-15, (42)

Google намерен использовать сетевой протокол QUIC в..., Аноним, 08:08 , 19-Апр-15, (56)

Google намерен использовать сетевой протокол QUIC в..., arisu, 08:14 , 19-Апр-15, (59)

Google намерен использовать сетевой протокол QUIC в..., Аноним, 09:41 , 19-Апр-15, (68) +4

Google намерен использовать сетевой протокол QUIC в..., Аноним, 09:42 , 19-Апр-15, (69) +2

Google намерен использовать сетевой протокол QUIC в..., Аноним, 10:48 , 19-Апр-15, (71)

Google намерен использовать сетевой протокол QUIC в..., Аноним, 10:42 , 19-Апр-15, (70) +1

Google намерен использовать сетевой протокол QUIC в..., Crazy Alex, 11:52 , 19-Апр-15, (73) –1

Google намерен использовать сетевой протокол QUIC в..., arisu, 21:55 , 19-Апр-15, (84) +1

Google намерен использовать сетевой протокол QUIC в..., Crazy Alex, 01:59 , 20-Апр-15, (86)

Google намерен использовать сетевой протокол QUIC в..., arisu, 02:07 , 20-Апр-15, (87) –1

Google намерен использовать сетевой протокол QUIC в..., Crazy Alex, 15:38 , 20-Апр-15, (105)

Google намерен использовать сетевой протокол QUIC в..., arisu, 15:43 , 20-Апр-15, (107) –1

Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 07:04 , 19-Апр-15, (43) –1
Google намерен использовать сетевой протокол QUIC в браузере..., none7, 07:37 , 19-Апр-15, (47) +1

Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 08:34 , 19-Апр-15, (65)

Google намерен использовать в Chrome по умолчанию сетевой пр..., InventoRs, 14:15 , 19-Апр-15, (76)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Sw00p aka Jerom, 15:47 , 19-Апр-15, (80)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 14:40 , 20-Апр-15, (104) +1

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 08:24 , 20-Апр-15, (91) +3

Google намерен использовать в Chrome по умолчанию сетевой пр..., Аноним, 08:50 , 20-Апр-15, (92)

Google намерен использовать в Chrome по умолчанию сетевой пр..., Нанобот, 08:52 , 20-Апр-15, (93)

Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 09:35 , 20-Апр-15, (94)

Google намерен использовать сетевой протокол QUIC в..., arisu, 09:40 , 20-Апр-15, (95)
Google намерен использовать сетевой протокол QUIC в браузере..., Нанобот, 11:10 , 20-Апр-15, (98)
Google намерен использовать сетевой протокол QUIC в браузере..., Crazy Alex, 15:41 , 20-Апр-15, (106) –1

Google намерен использовать сетевой протокол QUIC в браузере..., XDA, 10:27 , 20-Апр-15, (96) +1

Google намерен использовать сетевой протокол QUIC в браузере..., Нанобот, 11:07 , 20-Апр-15, (97) +1
Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 14:38 , 20-Апр-15, (103)

Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 16:16 , 20-Апр-15, (108)

Google намерен использовать сетевой протокол QUIC в браузере..., EuPhobos, 13:03 , 22-Апр-15, (116)

Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 13:43 , 20-Апр-15, (101)
Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 14:36 , 20-Апр-15, (102)
Firewall rules, Аноним, 17:32 , 20-Апр-15, (109)

Firewall rules, Andrew Kolchoogin, 20:12 , 20-Апр-15, (112) +1

Google намерен использовать сетевой протокол QUIC в браузере..., Аноним, 19:12 , 20-Апр-15, (111)

Google намерен использовать сетевой протокол QUIC в браузере..., Andrew Kolchoogin, 20:15 , 20-Апр-15, (113)

Google намерен использовать сетевой протокол QUIC в браузере..., pavel_simple, 07:14 , 21-Апр-15, (115)

Google намерен использовать сетевой протокол QUIC в браузере..., Анонимец, 06:38 , 21-Апр-15, (114)

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

1. "Google намерен использовать в Chrome по умолчанию сетевой пр..." –3 +/–

Сообщение от Аноним (??) on 18-Апр-15, 19:59

http://www.youtube.com/watch?v=fwcl17Q0bpk
анб тут нипричём, да

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +7 +/–

Сообщение от Аноним (??) on 19-Апр-15, 07:46

Его бы, этот QUIC, в тормозной Tor определить...

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Google намерен использовать в Chrome по умолчанию сетевой пр..." –10 +/–

Сообщение от A.Stahl (ok) on 18-Апр-15, 20:36

Ого, теперь типичный ВЕБ3.0(Или сколько там нынче) будет загружаться не 10-15 секунд, а всего лишь 9,95 - 14,95 секунд.
Вот только пакеты будут теряться, но ребята из Гугла всё продумали и "находиться" они будут быстро.
>системы упреждающей коррекции ошибок
Ого! Это ещё что за зверь?
Модуль: -- Эй, 35й пакет можешь не отсылать, там всё равно ошибка произойдёт...
Короче -- кто-то открыл клетки и гугловые маркетологи разбежались по городу. Теперь придётся их отстреливать. Ещё гринписовцы ныть начнут...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +12 +/–

Сообщение от Вася ты не прав on 18-Апр-15, 21:06

Про упреждающую коррекцию на пальцах:
Допустим ты хочешь отправить 100 пакетов по реально плохому каналу, и ожидаешь, что один может потеряться. Лаг допустим 100мс.
Без коррекции: ты шлёшь 100 пакетов. Через какое-то время (100мс + 100мс + таймаут) тебе приходит ответ "бро, я прождал почаса и не дождался 21-й пакет, вышли ещё раз, у меня тут весь канал стоит и ждёт!", ты в панике отправляешь его ещё раз, и через ещё 100 мс на той стороне собирают поток в кучу. Вау, круто.
С коррекцией: ты отправляешь 101 пакет, кодированные так, что если выкинуть любой из них, по 100 оставшимся можно собрать поток. Пофиг, если любой из них потеряется (что-то похожее ты можешь увидеть в RAID5 - не важно, какой диск сдохнет, ты всё равно можешь восстановить все данные). Да, ты отправил на 1% больше данных, но зато на той стороне получили весь поток в 10 раз быстрее.
В деталях всё происходит не так, но суть ты надеюсь уловил.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Google намерен использовать в Chrome по умолчанию сетевой пр..." –2 +/–

Сообщение от Аноним (??) on 18-Апр-15, 21:10

> (что-то похожее ты можешь увидеть в RAID5 - не важно, какой диск сдохнет, ты всё равно можешь восстановить все данные)
RAID6 - если надо восстановить быстро.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от A.Stahl (ok) on 18-Апр-15, 21:18

Ок, идея ясна.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

26. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +4 +/–

Сообщение от Омоним on 18-Апр-15, 23:51

Вездесущие коды Рида-Соломона ;-)

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

20. "Google намерен использовать в Chrome по умолчанию сетевой пр..." –13 +/–

Сообщение от И ты чушь пишешь on 18-Апр-15, 22:30

Причём тут вообще RAID? Тут 100% избыточность или 200%, как понять, что и где потеряется? Как канал связи проверить, пингами (ICMP)? В тестовых условия всё действительно будет супер..., вот плохой канал, а вот хороший...
Весь этот протокол и не протокол, а очередной костыль от гугла, или паразита, уже даже и не понятно как их назвать...
Я детально не знаю чего они там изобрели, но судя по схеме, это больше похоже на 1-е апреля.
Для начала, что за безопасность, если без согласования/получения сертификата(открытого ключа) сразу посылка данных идёт. А всё правильно, это же гугле с хромом, там уже всё решили за всех.
В плане остальных моментов разработчики стека TCP/IP после такого в полном шоке наверное, вот и думают, чего же они мучились, всё ведь просто... А нет, ведь в умных книжках так и написано TCP для гарантированной доставки, хотите лучше, делайте надстройки над UDP...
Вот и вопрос, нужно для веба, что-то лучше TCP в БРАУЗЕРАХ, то как заметили ниже, почему не использовать SCTP?, да всё просто, празит обычно моногамен, и хочет жить только сам, даже ценой уничтожения того кто его кормит, главное чтобы сейчас в тепле быть...

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

30. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +5 +/–

Сообщение от Вася ты не прав on 19-Апр-15, 02:18

> Причём тут вообще RAID? Тут 100% избыточность или 200%, как понять, что
> и где потеряется? Как канал связи проверить, пингами (ICMP)? В тестовых
> условия всё действительно будет супер..., вот плохой канал, а вот хороший...
Почитай про UDP. Там чексуммы на каждом пакете. С точки зрения того, кто сидит поверх UDP, любой пакет либо "дошел целиком", либо "не дошел вообще" (на практике 16 бит чексуммы бывает мало, поэтому можно прикрутить дополнительный контроль целостности данных сверху).
Теперь про избыточность и твои проценты.
Ну представь себе, что у тебя пакеты P1...P100. Сто штук, как в примере.
Можно было бы отправить дополнительно P101 = P1 ^ P2 ^ ... ^ P100. (где ^ - это XOR)
Разумеется речь идёт про полезный payload, а сбоку лежат служебные метаданные (поэтому ты знаешь, какой пакет какой).
Теперь вспоминаем про UDP. С точки зрения получателя дошли все пакеты, кроме, допустим, 45-го (и не важно, побились там данные, или он потерялся где-то). Как его восстановить? Очень просто.
P45 = P1 ^ P2 ^ ... ^ P44 ^ P46 ^ P47 ... P101.
Это базовая идея. Разумеется, на практике используются другие, более интересные способы кодирования. В общем случае ты можешь балансировать оверхед (в моём примере - 1%) и процент потерь, которые ты можешь прежить без проблем. И лэтенси восстановления на практике куда ниже (не нужно ждать 100 пакетов, чтобы восстановить один потерянный)
За материалами про помехоустойчивое кодирование отправляют тебя в вики и в гугл.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

100. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +2 +/–

Сообщение от Тююю on 20-Апр-15, 12:38

Гуглить FEC

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

11. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +1 +/–

Сообщение от Раб прогресса on 18-Апр-15, 21:18

> Ого! Это ещё что за зверь?
Заранее посылают процент избыточных данных, не? И правильно делают: пропускная способность сейчас в достатке. Если надо, можно ещё парочку кабелей через Атлантику или там ещё спутник-другой запустить. Дорого, но можно. А вот скорость света повысить пока ни у кого не получалось.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

72. "Google намерен использовать в Chrome по умолчанию сетевой пр..." –3 +/–

Сообщение от Аноним (??) on 19-Апр-15, 11:29

>А вот скорость света повысить пока ни у кого не получалось.
Ты не поверишь. Короче, иди погугли.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

79. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +1 +/–

Сообщение от Аноним (??) on 19-Апр-15, 15:40

> Ты не поверишь.
Что только не придумают, лишь бы не выбрасывать легаси!

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

45. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +3 +/–

Сообщение от Аноним (??) on 19-Апр-15, 07:28

> а всего лишь 9,95 - 14,95 секунд.
А ты попробуй TCP погонять по Wi-Fi, который еле ловится, так что 10% пакетов выпадает. Не забудь рассказать сколько времени заняла загрузка сайта. Догадываешься что хотят сказать TCP юзери с планшеткой у которых пакеты выпадают? Дело в том что congestion control в TCP думает что сеть перегружена и снижает скорость. Но реально сеть не перегружена, просто ненадежная среда передачи.
В Linux TCP еще можно немного вправить мозг. Но в маздае - понятно чего.
>>системы упреждающей коррекции ошибок
> Ого! Это ещё что за зверь?
Это то самое: FEC, Forward Error Correction. В общем случае посылается немного больше данных чем задумано, при выпадении части пакетов можно реконструировать недостающее без перезапросов к серверу.
В результате упомянутые 10% выпадений пакетов могут превратиться из "вот ж...а" в "а, ерунда".

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

88. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Ктото гдето on 20-Апр-15, 07:29

Зависит от алгоритма согласования.
Меня всегда забавляло что даже во всех роутерах при детальном рассмотрении стоит кубик О_о

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

89. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +1 +/–

Сообщение от Аноним (??) on 20-Апр-15, 08:14

> Зависит от алгоритма согласования.
Зависит, только не согласования а congestion control. В Linux для этого есть ряд дельных рукояток, но это костыли к легаси, рассчитанному на провода. И поэтому хотя лучше становится, результат и близко не стоял к тому что можно выжать, используя протоколы типа сабжа. А в какой-нибудь винде вообще - жесть, ад и сталинград.
> Меня всегда забавляло что даже во всех роутерах при детальном рассмотрении стоит кубик О_о
Роутеры редко оперируют TCP соединениями, так что это довольно пофигу (на форвард пакетов поведение TCP не распостраняется). Ну может самый край - вебморда роутера при настройке оной через вайфай через две стены - будет медленновато работать. Но поскольку это делается 1 раз и на сто лет - это еще можно пережить. А вот тормозливую загрузку вообще всех сайтов, с эффективной скоростью в 5% доступного бандвиза воспринимать иначе чем издевательство не получается.

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

12. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +9 +/–

Сообщение от Аноним (??) on 18-Апр-15, 21:20

>QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений
>добавление поддержки multipath-соединений (доставка пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам)
И что только Google не придумает, лишь бы не использовать SCTP.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Google намерен использовать в Chrome по умолчанию сетевой пр..." –2 +/–

Сообщение от Аноним (??) on 18-Апр-15, 22:24

А как же Windows?

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

25. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +5 +/–

Сообщение от Аноним (??) on 18-Апр-15, 23:16

А если на него и дальше оглядываться, то Мелкософт так и не подтянется.
Вот, к примеру, как LO начал кое-где на хвост наступать, так они и поддержку ODF у себя запилили.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

37. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 04:07

> что только Google не придумает, лишь бы не использовать SCTP
В SCTP был выявлен Фатальный Недостаток, поэтому пришлось запилить сабж.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

46. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 07:33

> В SCTP был выявлен Фатальный Недостаток, поэтому пришлось запилить сабж.
SCTP требует о себе особых знаний со стороны сетевого оборудования и прочая и изначально ориентирован на иные цели.
UDP - для того чтобы с хромом даже в винде работало, и фаеры не очень дурели.
FEC - владельцы планшеток и смартов с беспроводкой будут рады.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

78. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Xasd (ok) on 19-Апр-15, 15:08

> SCTP требует о себе особых знаний со стороны сетевого оборудования
там используются обычные ip-пакеты.
ни чего особенного, такая же маршрутизация, как и у других ip-пакетов.
> и изначально ориентирован на иные цели
SCTP -- ориентирован на те же самые цели что и TCPIP .. просто SCTP лучше чем TCPIP , вот и вся разница.
но TCPIP протокол тоже на месте не стоит и изредка пополняется новыми фишками. (возможно когда-нибудь TCPIP -- просто-навсего догонит SCTP )

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

81. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 16:59

шо за протокол TCPIP, который вместо SCTP? не гуглится ничо

Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

82. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Xasd (ok) on 19-Апр-15, 17:12

секретный
# ты знаешь о чём я . не придуривайся

Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

90. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +1 +/–

Сообщение от Аноним (??) on 20-Апр-15, 08:21

> там используются обычные ip-пакеты.
В TCP тоже используются обычные IP пакеты. И в udp. Вот только SCTP - stateful протокол, при том не TCP. По поводу чего первый же нат и stateful фаер или знает его явно, или рубит на корню, просто потому что не знает как трекать state довольно сложного протокола.
> ни чего особенного, такая же маршрутизация, как и у других ip-пакетов.
...пока мы не натыкаемся на stateful фаер или нат.
> SCTP -- ориентирован на те же самые цели что и TCPIP ..
> просто SCTP лучше чем TCPIP , вот и вся разница.
А гуглопротокол ориентирован на более другие цели - низкую латенси + учитывает некоторые особенности беспроводных линков. Как то - совершенно штатное выпадение части пакетов, не являющееся индикатором перегрузки сети (помехи в эфире регулярно выбивают некий процент пакетов). Ни в TCP, ни в SCTP это не было сделано.
> но TCPIP протокол тоже на месте не стоит и изредка пополняется новыми
> фишками. (возможно когда-нибудь TCPIP -- просто-навсего догонит SCTP )
А FEC ни у того ни у другого нет. А гонять TCP через канал с потерями пакетов - удовольствие ниже среднего, скажу я вам. Даже с злостным твиканием congestion control результат не поражает воображение. А без всего этого - вобще ночной кошмар диалапера.

Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

17. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +4 +/–

Сообщение от Какаянахренразница (ok) on 18-Апр-15, 22:06

Какие веб-сервера, кроме нативных гугловских, это умеют?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

44. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +4 +/–

Сообщение от Аноним (??) on 19-Апр-15, 07:26

NEEQUAQIJE

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +2 +/–

Сообщение от Аноним (??) on 18-Апр-15, 22:24

То есть от UDP flood теперь недостаточно на аплнике до веб-сервера зарезать UDP как тип, нужно будет подпускать ближе?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +3 +/–

Сообщение от _KUL (ok) on 19-Апр-15, 04:18

Вот вот! Да и вообще, udp сделан для трафика не критичного к потерям, для видео, аудио. Зачем самолет учить плавать, если его придумывали для полетов? С udp будет на много больше интересных проблем/атак, чем с tcp.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

50. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 07:56

> Вот вот! Да и вообще, udp сделан для трафика не критичного к потерям, для видео, аудио. Зачем самолет учить плавать, если его придумывали для полетов? С udp будет на много больше интересных проблем/атак, чем с tcp.
Ухахаха (вспоминая DoS.pl)

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

54. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 08:05

> Зачем самолет учить плавать, если его придумывали для полетов?
Есть такая фигня - гидросамолет. Садится на воду, чем и интересен. Ну и плавает там, разумеется.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

77. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от all_glory_to_the_hypnotoad (ok) on 19-Апр-15, 15:01

> . Ну и плавает там, разумеется
пока не накроет.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

110. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Аноним (??) on 20-Апр-15, 17:35

>> Зачем самолет учить плавать, если его придумывали для полетов?
>Есть такая фигня - гидросамолет.
Угу - плохая лодка + плохой самолёт.
Как _спец_ средство вменяем. Как универсальное решение ... :)

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

21. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +2 +/–

Сообщение от Аноним (??) on 18-Апр-15, 22:32

"QUIC уже не только интегрирован в серверную инфраструктуру Google и включён в состав Chrome, но и последние три месяца применяется для обслуживания примерно половины всех запросов к серверам Google, выполненных из браузера Chrome."
То-то хром такой ужасающе "быстрый" последние месяцы, теперь всё понятно. Тормозит даже на сервисных страницах, начиная с 36го.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

83. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +1 +/–

Сообщение от Аноним (??) on 19-Апр-15, 18:43

> Тормозит даже на сервисных страницах, начиная с 36го.
Вы сами виноваты - клаву не так держите и вообще, рабочий стол небось совсем не по феншую!1

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

85. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 23:49

Ага, притом особенно, что минуту назад в 35м все те же вкладки летали на ура. Это гугл сломал своё и без того ущербное детище.

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

99. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Аноним (??) on 20-Апр-15, 12:08

> что минуту назад в 35м все те же вкладки
35 -- это же почти современник отходов жизнедеятельности мамонта!
Небось и железо - то же самое, под которым когда-то запускали только вышедшую 35-ю версию?
Т.е. наверняка доисторическая железка с аскетично-жалкими 32 гигами рамы?
Я же говорю - сами виноваты! Так что запускайте и дальше древнюю версию хрома на вашем древнющем железе!

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

22. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +9 +/–

Сообщение от Андрей (??) on 18-Апр-15, 22:45

>Поддержка идентификатора соединения, позволяющего сократить время...
Отслеживание пользователей, встроенное в протокол?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Google намерен использовать сетевой протокол QUIC в браузере..." +2 +/–

Сообщение от th3m3 (ok) on 19-Апр-15, 00:10

В общем, гугл хочет очередной зонд вынести в стандарт.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

38. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 04:12

> гугл хочет очередной зонд вынести в стандарт
HTTP2, основанный на гугловском же SPDY, распространиться толком не успел, как Гугл новую поделку с претензией на стандарт выкатил.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

Часть нити удалена модератором

33. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от th3m3 (ok) on 19-Апр-15, 03:29

Движок Firefox так-то тоже много где используется. Взять ту же Jolla с Sailfish OS - там встроенный браузер на движке Gecko. Множество форков Firefox. Firefox OS и т.д.

Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

74. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Crazy Alex (ok) on 19-Апр-15, 11:53

Так это разного уровня протоколы. Сказали же - HTTP2/SPDY поверх QUIC.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

34. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 03:33

походу что то здравое предлагают, к торентам этот протокол приделать можно будет,
ИИ думает нечеловеческое уже.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

75. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Фтщт on 19-Апр-15, 13:28

В торрентах уже мютипи есть.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

35. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 03:42

Дмитрий Смирнов приди, расскажи как ты мечтаешь об уменьшении времени согласовании ssl сессии ))

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 03:54

SCTP решает проблемы с двух сторон, и мог бы улучшить ситуацию с оборудованием на поддержку этого протокола.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Google намерен использовать сетевой протокол QUIC в..." +/–

Сообщение от arisu (ok) on 19-Апр-15, 06:53

нормальной реализации на си, натурально, как не было, так и нет. в помойку.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

56. "Google намерен использовать сетевой протокол QUIC в..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 08:08

> нормальной реализации на си, натурально, как не было, так и нет.
Не все сразу.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

59. "Google намерен использовать сетевой протокол QUIC в..." +/–

Сообщение от arisu (ok) on 19-Апр-15, 08:14

> Не все сразу.
а всё и не надо. надо нормальную реализацию на си, в виде легко подключаемой библиотеки с внятным API. но гугелю наплевать, потому что всё, что интересует гугель — чтобы гугелесайты быстрее грузились. не то, чтобы в этом их желании было что‐то плохое — но пусть идут в задницу с пиаром своих игрушек.
tl;dr: отсутствие легко подключаемой библиотеки на си говорит о том, что это внутренняя игрушка гугеля, и на «распространение» гугелю на самом деле наплевать. поэтому есть смысл в свою очередь наплевать на гуглоигрушку.

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

68. "Google намерен использовать сетевой протокол QUIC в..." +4 +/–

Сообщение от Аноним (??) on 19-Апр-15, 09:41

Среди этих потоков ненависти иногда и у тебя проскакивают ошметки здравого смысла.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

69. "Google намерен использовать сетевой протокол QUIC в..." +2 +/–

Сообщение от Аноним (??) on 19-Апр-15, 09:42

Но очень не часто...

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

71. "Google намерен использовать сетевой протокол QUIC в..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 10:48

> Но очень не часто...
Сказать идиoту что он идиoт - это не ненависть, это констатация факта. А поскольку 95% населения ..., то математическое ожидание положительной классификации не превышает 5% aka "очень не часто".

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

70. "Google намерен использовать сетевой протокол QUIC в..." +1 +/–

Сообщение от Аноним (??) on 19-Апр-15, 10:42

> Среди этих потоков ненависти иногда и у тебя проскакивают ошметки здравого смысла.
На самом деле, арису всего лишь капитанит. А поскольку он неглупый субъект, капитанит он весьма качественно. Так что если он кого назвал непочетным термином - это повод призадуматься о том как вы выглядите для окружающих. Я понимаю что самокопания для глупых личностей не характерны. Ну вот он и объясняет в доступном формате, под уровень оппонента.

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

73. "Google намерен использовать сетевой протокол QUIC в..." –1 +/–

Сообщение от Crazy Alex (ok) on 19-Апр-15, 11:52

Да и плевать, как к этому относится сам гугл. Если потащат в стандарт и/или окажется реально полезным (а идеи здравые вроде видны) - то уж либу кто-нибудь напишет. А пока - ну пусть хорошенько оттестируют на миллионах хомяков, не привлекая больше ничьи ресурсы - тем лучше же. Пиар - он утихнет, а результат (если есть) - останется.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

84. "Google намерен использовать сетевой протокол QUIC в..." +1 +/–

Сообщение от arisu (ok) on 19-Апр-15, 21:55

> Да и плевать, как к этому относится сам гугл.
не плевать. гугель славится своей любовью забрасывать игрушки, когда на горизонте новая блестяшка замаячила.
в этом плане standalone C library — какая‐никакая, но заявка на то, что это не просто очередная игрушка. и потому другим тоже есть смысл повертеть, пощупать. попробовать у себя на небольших проектах, например — что несложно, потому что есть библиотека на си, которую можно привинтить практически к чему угодно.
в теперешнем же виде (в котором оно пребывает далеко не первый месяц, и даже не год, в принципе) никакого желания заниматься попытками это внедрить куда‐либо нет. потратишь кучу времени, выковыривая код и пытаясь его внедрить, только‐только сделаешь, а гугель скажет: «йоу, парни! у нас вот квики2, квики1 уже неактуален, все на квики2!» и сидишь, обтекаешь.
я, заметь, ничего не говорил про технические идеи нового протокола — они, вполне возможно, весьма хорошие: в гугеле, чай, не сплошь дураки сидят.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

86. "Google намерен использовать сетевой протокол QUIC в..." +/–

Сообщение от Crazy Alex (ok) on 20-Апр-15, 01:59

Так никто, вроде, не заставляет прямо сейчас внедрять. У них модель такая (довольно здравая, я бы сказал) - обкатывать на массах. А вот когда проведут "модернизацию" и протолкнут RFC - думаю, никаких претензий к стабильности не будет. С другой стороны - если оно таки даёт то, что обещает (а что такое тормоза на потерях пакетов я знаю хорошо) - то, честное слово, можно немного и погоняться за гугловскими версиями, уж больно результат вкусный.

Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

87. "Google намерен использовать сетевой протокол QUIC в..." –1 +/–

Сообщение от arisu (ok) on 20-Апр-15, 02:07

претензий, конечно, не будет. особых внедрений, впрочем, тоже, потому что они успешно сигнализируют желающим попробовать, что это просто очередная игрушка. мало, что ли, rfc-шек, которые никто не рвётся внедрять? ну, будет ещё одна, подумаешь.

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

105. "Google намерен использовать сетевой протокол QUIC в..." +/–

Сообщение от Crazy Alex (ok) on 20-Апр-15, 15:38

Не думаю. Польза очевидна, а альтернатив, тем более уже установленных у половины посетителей сайта - не видно. Те rfc, о который хты говоришь - они, как правило, дохла по причине полной бесполезности или необходимости поддержки сразу всеми и вся (как тот же SCTP).

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

107. "Google намерен использовать сетевой протокол QUIC в..." –1 +/–

Сообщение от arisu (ok) on 20-Апр-15, 15:43

польза нифига не очевидна, потому что независимое тестирование отсутствует. потому что кто‐то не сделал нужной библиотеки.

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

43. "Google намерен использовать сетевой протокол QUIC в браузере..." –1 +/–

Сообщение от Аноним (??) on 19-Апр-15, 07:04

я правильно понял, что гуглу будет удобнее следить за пользователями на своем формае сетевого взаимодействия, а не на чужом?

это можно обофти в айтупи, например, этотновый петушиный сетефой формат?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

47. "Google намерен использовать сетевой протокол QUIC в браузере..." +1 +/–

Сообщение от none7 (ok) on 19-Апр-15, 07:37

Интересно, а как они планируют определять MTU пути? Ведь ОС не предоставляют средств определения наличия фрагментации пакетов. Для TCP в каждом роутере стоит фиксатор разрешённой длины пакета, да и при запрете фрагментации принято слать ICMP пакетик который естественно не достанется QUIC приложению.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

65. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 19-Апр-15, 08:34

ботнет в каждый дом

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

76. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от InventoRs (ok) on 19-Апр-15, 14:15

А кто-то может прояснить, какие порты UDP используются?
У меня тут трабла такая, что DDOS в 20-60Г влитает на 80й порт по UDP, пока это фаером кроется, но вот есть чувство что из-за этого модного протокола фаер прийдется перекручивать.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

80. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Sw00p aka Jerom on 19-Апр-15, 15:47

придётся ещё и DPI прикручивать, чтоб паразитный траф резать )))

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

104. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +1 +/–

Сообщение от Аноним (??) on 20-Апр-15, 14:40

> придётся ещё и DPI прикручивать, чтоб паразитный траф резать )))
и/или учиться конфигурить файрвол, чтобы блэкхолил бяку.
или готовый IPS юзать, с темплейтами и блэекджеком. для начала - и snort и форки - сойдут, впрчоем.

Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

91. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +3 +/–

Сообщение от Аноним (??) on 20-Апр-15, 08:24

> порт по UDP, пока это фаером кроется,
Так это... от того что ты фаером убил пакеты, они не перестали в проводе место занимать :)

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

92. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Аноним (??) on 20-Апр-15, 08:50

+++

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

93. "Google намерен использовать в Chrome по умолчанию сетевой пр..." +/–

Сообщение от Нанобот (ok) on 20-Апр-15, 08:52

Как самое простое решение - на время атаки переключаться на http-only (или вообще не использовать quic)

Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

94. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 20-Апр-15, 09:35

Как же теперь проксировать то этот протокол? Сквид ничего не знает про QUIC.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

95. "Google намерен использовать сетевой протокол QUIC в..." +/–

Сообщение от arisu (ok) on 20-Апр-15, 09:40

> Как же теперь проксировать то этот протокол? Сквид ничего не знает про
> QUIC.
ну, значит, взять libquic, и… ой. а нет никакой libquic. ergo — забить.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

98. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Нанобот (ok) on 20-Апр-15, 11:10

> Как же теперь проксировать то этот протокол? Сквид ничего не знает про
> QUIC.
для тех ~0.1% пользователей, которые работают через прокси, можно оставить всё без изменений (использовать http/https), в масштабах интернета никто не заметит потери

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

106. "Google намерен использовать сетевой протокол QUIC в браузере..." –1 +/–

Сообщение от Crazy Alex (ok) on 20-Апр-15, 15:41

Никак. Не говоря о том, что принудительное проксирование давно пора отправить на свалку - браузер, не пробившись по QUIC, тихо-мирно переключится на TCP/IP и просто будет тупить как и прежде.

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

96. "Google намерен использовать сетевой протокол QUIC в браузере..." +1 +/–

Сообщение от XDA (ok) on 20-Апр-15, 10:27

А что. вон торренты уже разработали свой протокол поверх юдп. Рад положили интернет, два. а магистральщики тем временем в шоке меняют оборудование из-за в разы возросшего PPS.

потом, правда, научились. причём в лабораторных условиях работало. но как только вылезло бесконтрольно на просторы инета - случился п(дец).

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

97. "Google намерен использовать сетевой протокол QUIC в браузере..." +1 +/–

Сообщение от Нанобот (ok) on 20-Апр-15, 11:07

а оно так всегда. любая новая технология потенциально может давать побочные эффекты в смежных областях. такой риск есть всегда, но это не повод отказываться от новых технологий

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

103. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 20-Апр-15, 14:38

это не "торренты" а наш соотечественник разработал в свое время uDP, права на который у него затем оные купили.
он сейчас Open Garden развивает. mesh-сети, mesh/ad-hoc роутинг, ad-hoc менеджмент итд итп.
классная штука, не слабее Бэтмэна или гипербореи, рекомендую почитать или инвестировать в:)

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

108. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 20-Апр-15, 16:16

как зовут? ссылки?

Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

116. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от EuPhobos (ok) on 22-Апр-15, 13:03

Прям с языка снял..

Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

101. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 20-Апр-15, 13:43

Почему было не использовать DTLS вместо сабжа?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

102. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 20-Апр-15, 14:36

что только не делают, чтобы веб-сокеты осваивать и с серверной и с клиентской стороны(в теории - хром держит уже n версия, а практически ... увы).

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

109. "Firewall rules" +/–

Сообщение от Аноним (??) on 20-Апр-15, 17:32

Как это повлияет на работу NAT/Statefull firewall? У UDP протокола нет состояния, а у вышележащего QUIC - есть...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

112. "Firewall rules" +1 +/–

Сообщение от Andrew Kolchoogin (ok) on 20-Апр-15, 20:12

> У UDP протокола нет состояния, а у вышележащего QUIC - есть...
У IP протокола нет состояния, а у вышележащего TCP - есть...
И как это влияет на работу NAT/stateful firewall?

Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

111. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Аноним (??) on 20-Апр-15, 19:12

Нифига не понял, они просто тупо предлагают использовать udp вместо tcp? А подтверждение, что клиент получил пакет, теперь не нужно? :) Офигеть инновации...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

113. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Andrew Kolchoogin (ok) on 20-Апр-15, 20:15

> Нифига не понял, они просто тупо предлагают использовать udp вместо tcp? А
> подтверждение, что клиент получил пакет, теперь не нужно? :) Офигеть инновации...
Да оно и изначально было не особенно-то нужно.
Вообще, TCP -- это костыль. Потому что была масса приложений, которые хорошо умели работать с файлами (ну, pipes как частный случай). А переписывать их под сеть ломало. Вот и придумали протокол, с помощью которого можно было сделать файловый дескриптор абстракцией сетевого соединения.

Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

115. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от pavel_simple (ok) on 21-Апр-15, 07:14

>> Нифига не понял, они просто тупо предлагают использовать udp вместо tcp? А
>> подтверждение, что клиент получил пакет, теперь не нужно? :) Офигеть инновации...
> Да оно и изначально было не особенно-то нужно.
> Вообще, TCP -- это костыль. Потому что была масса приложений, которые хорошо
> умели работать с файлами (ну, pipes как частный случай). А переписывать
> их под сеть ломало. Вот и придумали протокол, с помощью которого
> можно было сделать файловый дескриптор абстракцией сетевого соединения.
ты чё несёшь? типа для udp используется какая-то другая абстракция.

Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

114. "Google намерен использовать сетевой протокол QUIC в браузере..." +/–

Сообщение от Анонимец on 21-Апр-15, 06:38

Вся эта лабутня с увеличением потоков в протоколе... предвещает +100500 мегабайт увелечение жратвы трафика?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	–3 +/–
Сообщение от Аноним (??) on 18-Апр-15, 19:59
http://www.youtube.com/watch?v=fwcl17Q0bpk анб тут нипричём, да
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	48. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+7 +/–
	Сообщение от Аноним (??) on 19-Апр-15, 07:46
	Его бы, этот QUIC, в тормозной Tor определить...
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

4. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	–10 +/–
Сообщение от A.Stahl (ok) on 18-Апр-15, 20:36
Ого, теперь типичный ВЕБ3.0(Или сколько там нынче) будет загружаться не 10-15 секунд, а всего лишь 9,95 - 14,95 секунд. Вот только пакеты будут теряться, но ребята из Гугла всё продумали и "находиться" они будут быстро. >системы упреждающей коррекции ошибок Ого! Это ещё что за зверь? Модуль: -- Эй, 35й пакет можешь не отсылать, там всё равно ошибка произойдёт... Короче -- кто-то открыл клетки и гугловые маркетологи разбежались по городу. Теперь придётся их отстреливать. Ещё гринписовцы ныть начнут...
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	7. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+12 +/–
	Сообщение от Вася ты не прав on 18-Апр-15, 21:06
	Про упреждающую коррекцию на пальцах: Допустим ты хочешь отправить 100 пакетов по реально плохому каналу, и ожидаешь, что один может потеряться. Лаг допустим 100мс. Без коррекции: ты шлёшь 100 пакетов. Через какое-то время (100мс + 100мс + таймаут) тебе приходит ответ "бро, я прождал почаса и не дождался 21-й пакет, вышли ещё раз, у меня тут весь канал стоит и ждёт!", ты в панике отправляешь его ещё раз, и через ещё 100 мс на той стороне собирают поток в кучу. Вау, круто. С коррекцией: ты отправляешь 101 пакет, кодированные так, что если выкинуть любой из них, по 100 оставшимся можно собрать поток. Пофиг, если любой из них потеряется (что-то похожее ты можешь увидеть в RAID5 - не важно, какой диск сдохнет, ты всё равно можешь восстановить все данные). Да, ты отправил на 1% больше данных, но зато на той стороне получили весь поток в 10 раз быстрее. В деталях всё происходит не так, но суть ты надеюсь уловил.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	9. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	–2 +/–
	Сообщение от Аноним (??) on 18-Апр-15, 21:10
	> (что-то похожее ты можешь увидеть в RAID5 - не важно, какой диск сдохнет, ты всё равно можешь восстановить все данные) RAID6 - если надо восстановить быстро.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	10. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+/–
	Сообщение от A.Stahl (ok) on 18-Апр-15, 21:18
	Ок, идея ясна.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	26. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+4 +/–
	Сообщение от Омоним on 18-Апр-15, 23:51
	Вездесущие коды Рида-Соломона ;-)
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	20. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	–13 +/–
	Сообщение от И ты чушь пишешь on 18-Апр-15, 22:30
	Причём тут вообще RAID? Тут 100% избыточность или 200%, как понять, что и где потеряется? Как канал связи проверить, пингами (ICMP)? В тестовых условия всё действительно будет супер..., вот плохой канал, а вот хороший... Весь этот протокол и не протокол, а очередной костыль от гугла, или паразита, уже даже и не понятно как их назвать... Я детально не знаю чего они там изобрели, но судя по схеме, это больше похоже на 1-е апреля. Для начала, что за безопасность, если без согласования/получения сертификата(открытого ключа) сразу посылка данных идёт. А всё правильно, это же гугле с хромом, там уже всё решили за всех. В плане остальных моментов разработчики стека TCP/IP после такого в полном шоке наверное, вот и думают, чего же они мучились, всё ведь просто... А нет, ведь в умных книжках так и написано TCP для гарантированной доставки, хотите лучше, делайте надстройки над UDP... Вот и вопрос, нужно для веба, что-то лучше TCP в БРАУЗЕРАХ, то как заметили ниже, почему не использовать SCTP?, да всё просто, празит обычно моногамен, и хочет жить только сам, даже ценой уничтожения того кто его кормит, главное чтобы сейчас в тепле быть...
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	30. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+5 +/–
	Сообщение от Вася ты не прав on 19-Апр-15, 02:18
	> Причём тут вообще RAID? Тут 100% избыточность или 200%, как понять, что > и где потеряется? Как канал связи проверить, пингами (ICMP)? В тестовых > условия всё действительно будет супер..., вот плохой канал, а вот хороший... Почитай про UDP. Там чексуммы на каждом пакете. С точки зрения того, кто сидит поверх UDP, любой пакет либо "дошел целиком", либо "не дошел вообще" (на практике 16 бит чексуммы бывает мало, поэтому можно прикрутить дополнительный контроль целостности данных сверху). Теперь про избыточность и твои проценты. Ну представь себе, что у тебя пакеты P1...P100. Сто штук, как в примере. Можно было бы отправить дополнительно P101 = P1 ^ P2 ^ ... ^ P100. (где ^ - это XOR) Разумеется речь идёт про полезный payload, а сбоку лежат служебные метаданные (поэтому ты знаешь, какой пакет какой). Теперь вспоминаем про UDP. С точки зрения получателя дошли все пакеты, кроме, допустим, 45-го (и не важно, побились там данные, или он потерялся где-то). Как его восстановить? Очень просто. P45 = P1 ^ P2 ^ ... ^ P44 ^ P46 ^ P47 ... P101. Это базовая идея. Разумеется, на практике используются другие, более интересные способы кодирования. В общем случае ты можешь балансировать оверхед (в моём примере - 1%) и процент потерь, которые ты можешь прежить без проблем. И лэтенси восстановления на практике куда ниже (не нужно ждать 100 пакетов, чтобы восстановить один потерянный) За материалами про помехоустойчивое кодирование отправляют тебя в вики и в гугл.
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	100. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+2 +/–
	Сообщение от Тююю on 20-Апр-15, 12:38
	Гуглить FEC
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	11. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+1 +/–
	Сообщение от Раб прогресса on 18-Апр-15, 21:18
	> Ого! Это ещё что за зверь? Заранее посылают процент избыточных данных, не? И правильно делают: пропускная способность сейчас в достатке. Если надо, можно ещё парочку кабелей через Атлантику или там ещё спутник-другой запустить. Дорого, но можно. А вот скорость света повысить пока ни у кого не получалось.
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	72. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	–3 +/–
	Сообщение от Аноним (??) on 19-Апр-15, 11:29
	>А вот скорость света повысить пока ни у кого не получалось. Ты не поверишь. Короче, иди погугли.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	79. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+1 +/–
	Сообщение от Аноним (??) on 19-Апр-15, 15:40
	> Ты не поверишь. Что только не придумают, лишь бы не выбрасывать легаси!
	Ответить \| Правка \| ^ к родителю #72 \| Наверх \| Cообщить модератору


	45. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+3 +/–
	Сообщение от Аноним (??) on 19-Апр-15, 07:28
	> а всего лишь 9,95 - 14,95 секунд. А ты попробуй TCP погонять по Wi-Fi, который еле ловится, так что 10% пакетов выпадает. Не забудь рассказать сколько времени заняла загрузка сайта. Догадываешься что хотят сказать TCP юзери с планшеткой у которых пакеты выпадают? Дело в том что congestion control в TCP думает что сеть перегружена и снижает скорость. Но реально сеть не перегружена, просто ненадежная среда передачи. В Linux TCP еще можно немного вправить мозг. Но в маздае - понятно чего. >>системы упреждающей коррекции ошибок > Ого! Это ещё что за зверь? Это то самое: FEC, Forward Error Correction. В общем случае посылается немного больше данных чем задумано, при выпадении части пакетов можно реконструировать недостающее без перезапросов к серверу. В результате упомянутые 10% выпадений пакетов могут превратиться из "вот ж...а" в "а, ерунда".
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	88. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+/–
	Сообщение от Ктото гдето on 20-Апр-15, 07:29
	Зависит от алгоритма согласования. Меня всегда забавляло что даже во всех роутерах при детальном рассмотрении стоит кубик О_о
	Ответить \| Правка \| ^ к родителю #45 \| Наверх \| Cообщить модератору


	89. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+1 +/–
	Сообщение от Аноним (??) on 20-Апр-15, 08:14
	> Зависит от алгоритма согласования. Зависит, только не согласования а congestion control. В Linux для этого есть ряд дельных рукояток, но это костыли к легаси, рассчитанному на провода. И поэтому хотя лучше становится, результат и близко не стоял к тому что можно выжать, используя протоколы типа сабжа. А в какой-нибудь винде вообще - жесть, ад и сталинград. > Меня всегда забавляло что даже во всех роутерах при детальном рассмотрении стоит кубик О_о Роутеры редко оперируют TCP соединениями, так что это довольно пофигу (на форвард пакетов поведение TCP не распостраняется). Ну может самый край - вебморда роутера при настройке оной через вайфай через две стены - будет медленновато работать. Но поскольку это делается 1 раз и на сто лет - это еще можно пережить. А вот тормозливую загрузку вообще всех сайтов, с эффективной скоростью в 5% доступного бандвиза воспринимать иначе чем издевательство не получается.
	Ответить \| Правка \| ^ к родителю #88 \| Наверх \| Cообщить модератору

12. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+9 +/–
Сообщение от Аноним (??) on 18-Апр-15, 21:20
>QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений >добавление поддержки multipath-соединений (доставка пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам) И что только Google не придумает, лишь бы не использовать SCTP.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	18. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	–2 +/–
	Сообщение от Аноним (??) on 18-Апр-15, 22:24
	А как же Windows?
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	25. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+5 +/–
	Сообщение от Аноним (??) on 18-Апр-15, 23:16
	А если на него и дальше оглядываться, то Мелкософт так и не подтянется. Вот, к примеру, как LO начал кое-где на хвост наступать, так они и поддержку ODF у себя запилили.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	37. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+/–
	Сообщение от Аноним (??) on 19-Апр-15, 04:07
	> что только Google не придумает, лишь бы не использовать SCTP В SCTP был выявлен Фатальный Недостаток, поэтому пришлось запилить сабж.
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	46. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+/–
	Сообщение от Аноним (??) on 19-Апр-15, 07:33
	> В SCTP был выявлен Фатальный Недостаток, поэтому пришлось запилить сабж. SCTP требует о себе особых знаний со стороны сетевого оборудования и прочая и изначально ориентирован на иные цели. UDP - для того чтобы с хромом даже в винде работало, и фаеры не очень дурели. FEC - владельцы планшеток и смартов с беспроводкой будут рады.
	Ответить \| Правка \| ^ к родителю #37 \| Наверх \| Cообщить модератору


	78. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+/–
	Сообщение от Xasd (ok) on 19-Апр-15, 15:08
	> SCTP требует о себе особых знаний со стороны сетевого оборудования там используются обычные ip-пакеты. ни чего особенного, такая же маршрутизация, как и у других ip-пакетов. > и изначально ориентирован на иные цели SCTP -- ориентирован на те же самые цели что и TCPIP .. просто SCTP лучше чем TCPIP , вот и вся разница. но TCPIP протокол тоже на месте не стоит и изредка пополняется новыми фишками. (возможно когда-нибудь TCPIP -- просто-навсего догонит SCTP )
	Ответить \| Правка \| ^ к родителю #46 \| Наверх \| Cообщить модератору


	81. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+/–
	Сообщение от Аноним (??) on 19-Апр-15, 16:59
	шо за протокол TCPIP, который вместо SCTP? не гуглится ничо
	Ответить \| Правка \| ^ к родителю #78 \| Наверх \| Cообщить модератору


	82. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+/–
	Сообщение от Xasd (ok) on 19-Апр-15, 17:12
	секретный # ты знаешь о чём я . не придуривайся
	Ответить \| Правка \| ^ к родителю #81 \| Наверх \| Cообщить модератору


	90. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+1 +/–
	Сообщение от Аноним (??) on 20-Апр-15, 08:21
	> там используются обычные ip-пакеты. В TCP тоже используются обычные IP пакеты. И в udp. Вот только SCTP - stateful протокол, при том не TCP. По поводу чего первый же нат и stateful фаер или знает его явно, или рубит на корню, просто потому что не знает как трекать state довольно сложного протокола. > ни чего особенного, такая же маршрутизация, как и у других ip-пакетов. ...пока мы не натыкаемся на stateful фаер или нат. > SCTP -- ориентирован на те же самые цели что и TCPIP .. > просто SCTP лучше чем TCPIP , вот и вся разница. А гуглопротокол ориентирован на более другие цели - низкую латенси + учитывает некоторые особенности беспроводных линков. Как то - совершенно штатное выпадение части пакетов, не являющееся индикатором перегрузки сети (помехи в эфире регулярно выбивают некий процент пакетов). Ни в TCP, ни в SCTP это не было сделано. > но TCPIP протокол тоже на месте не стоит и изредка пополняется новыми > фишками. (возможно когда-нибудь TCPIP -- просто-навсего догонит SCTP ) А FEC ни у того ни у другого нет. А гонять TCP через канал с потерями пакетов - удовольствие ниже среднего, скажу я вам. Даже с злостным твиканием congestion control результат не поражает воображение. А без всего этого - вобще ночной кошмар диалапера.
	Ответить \| Правка \| ^ к родителю #78 \| Наверх \| Cообщить модератору

17. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+4 +/–
Сообщение от Какаянахренразница (ok) on 18-Апр-15, 22:06
Какие веб-сервера, кроме нативных гугловских, это умеют?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	44. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+4 +/–
	Сообщение от Аноним (??) on 19-Апр-15, 07:26
	NEEQUAQIJE
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору

19. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+2 +/–
Сообщение от Аноним (??) on 18-Апр-15, 22:24
То есть от UDP flood теперь недостаточно на аплнике до веб-сервера зарезать UDP как тип, нужно будет подпускать ближе?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	39. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+3 +/–
	Сообщение от _KUL (ok) on 19-Апр-15, 04:18
	Вот вот! Да и вообще, udp сделан для трафика не критичного к потерям, для видео, аудио. Зачем самолет учить плавать, если его придумывали для полетов? С udp будет на много больше интересных проблем/атак, чем с tcp.
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	50. "Google намерен использовать в Chrome по умолчанию сетевой пр..."	+/–
	Сообщение от Аноним (??) on 19-Апр-15, 07:56
	> Вот вот! Да и вообще, udp сделан для трафика не критичного к потерям, для видео, аудио. Зачем самолет учить плавать, если его придумывали для полетов? С udp будет на много больше интересных проблем/атак, чем с tcp. Ухахаха (вспоминая DoS.pl)
	Ответить \| Правка \| ^ к родителю #39 \| Наверх \| Cообщить модератору