|
2.2, Аноним (2), 09:42, 04/11/2019 [^] [^^] [^^^] [ответить]
| +12 +/– |
Второй сейчас во всех cdn. Реально сокращает трафик и задержки раза в 2.
| |
|
|
4.23, Аноним (2), 12:38, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Если это подкол на тему маркетинговых брошурок, то я могу сказать, что реально видел очень значительную разницу. Ну, в консольке, и по результатам работы паучков сравнивал.
| |
|
5.35, Аноним (35), 14:20, 04/11/2019 [^] [^^] [^^^] [ответить]
| –2 +/– |
Были неоднократно и обратные ситуации когда http2 просили отключить, так верхний контент страницы грузился одновременно с нижним и время до полной отрисовки падало
| |
|
6.66, xl32 (ok), 17:44, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Там вообще-то приоритеты есть и ими не запрещают пользоваться. Но если вам, как и в случае с SELinux, проще не разбираться, а просто отключить, это тоже не запрещено. Просто не говорите про ненужность для всех. Только для неосиляторов.
| |
|
7.73, Аноним (73), 18:57, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ну так просвети меня как в nginx приоритеты настроить, конфиг что ли скинь.
Судя по https://github.com/andydavies/http2-prioritization-issues год назад большая часть мира приоритеты не осилила и подозреваю что сейчас картина не лучше.
От того что приоритеты описаны в стандарте и поддерживаются в единственном(?) веб-сервере, мир лучше не становится и приходится жить с тем что есть.
| |
|
8.75, xl32 (ok), 19:15, 04/11/2019 [^] [^^] [^^^] [ответить] | +1 +/– | Nginx прекрасно поддерживает приоритеты, запрошенные клиентом Конфигов ему ника... текст свёрнут, показать | |
|
|
|
|
4.47, BlackRot (ok), 15:20, 04/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Выползи из окопа, всё уже давно проверено и подтверждено.
На всех своих сайтах использую http2, разница заметная даже слепому. Старенький сервер ещё поживёт.
| |
|
5.93, j3t (?), 01:45, 05/11/2019 [^] [^^] [^^^] [ответить]
| –5 +/– |
на всех своих сайтах? лол што? на своем твиттере или гугле? какие у тебя сайты шо узкое место в них имеено в http 1.1? сейчас даже в деревнях уже лет как пять есть 3g, не говоря о покрытие городов, какая разница? сколько 3 или 4 миллисекунды? разница в скорости отрисовки зависит от браузера, если он тормоз страница долго грузит(яркий пример IE 6,7), хоть у тебя 5G и ты стоишь под базовой станцией, какие же вы школьники блджад
| |
|
6.101, пох. (?), 12:44, 05/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
вам же сказали - главное - свято верить.
Гугель швятой, любая его поделка - совершенна, два лишних соединения единственного за день посетителя с васян-сайтом можно заметить без наносекундных измеризмов.
P.S. разница зависит, разумеется, не только от браузера, еще и от необходимости создания двух десятков разных (!) tls сессий с cdn для ресракта, для jquery (альтернативно-одаренный разработчик не уместился в апи ресракта и насопливил отдельно), cdn для шрифтиков (пяти разных), cdn для онлайн-чятика и т п - вполне видна невооруженным глазом, никакой 0rtt в этом случае, разумеется, не работает, поэтому волшебные протоколы панацеей, внезапно, не являются (если ты не гугль).
С остальными проблемами неплохо справляется протокол http версий старше 0.9
| |
|
7.113, j3t (?), 02:58, 08/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вангую HTTP/4 на базе гипертекстового фидонета, чтобы совсем уж...
| |
7.114, j3t (?), 03:13, 08/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
В 99% случаев таки от браузера, точнее от скорости парсинга HTML/CSS(потуги Mozilla запилить многопоточный парсер DOM и CSS), ну и конечно же производительности двигла JavaScript-а(V8 же! для сравнения с spidermonkey), не отломанное аппаратное ускорение после свистоперделок CSS3 и адских высеров в виде Angular/React/Vue.js просто мастхев(хромой со скоростью конкорда летает на винде и так же тормозит под линухом), многопроцессорный режим вообще тормоз по сравнению с потоками(OnlyOffice выполняющийся как -no sandbox летает, VS Code тормозит), блокировщики реклам типа AdBlock и uBlock заставляют браузер подтупливать, ну и тысячи их... причин
| |
|
8.120, пох. (?), 11:37, 09/11/2019 [^] [^^] [^^^] [ответить] | +/– | дружище, у меня в качестве основного интернето-киоска - atom D2700 и совершенно ... текст свёрнут, показать | |
|
|
|
|
|
3.85, хотел спросить (?), 21:16, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
у меня ничего не поменялось с введение HTTP/2, старый добрый bundling никто не отменял
проверял через network tools время загрузки не меняется (в пределах погрешности)
| |
|
4.115, j3t (?), 03:17, 08/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
от сжатия gzip-ом в 100500 раз больше ускорения было, чем от этой бинарщины
| |
|
5.121, пох. (?), 11:45, 09/11/2019 [^] [^^] [^^^] [ответить] | +/– | вы им что такое сжимаете-то У меня вот от сжатия gzip ом ускорение только на ка... большой текст свёрнут, показать | |
|
|
3.90, хотел спросить (?), 22:27, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
я даже больше скажу
на тестовом сервере под CentOS 7 + nginx
клиент FF 71 (dev edition)
1.1 требует 2.9s до полной загрузки сайт, а 2 в среднем 3.2s (уже разгретое приложение, но холодный кеш браузера)
возможно имеет смысл что backend под nginx на 1.1, ну так и должно быть - это же localhost
| |
|
2.17, Ilya Indigo (ok), 11:54, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
На lighttp никогда и не увидите.
На nginx уже сейчас через клодфлеерский костыль HTTP/3 есть, а в течение года нативно реализуют
| |
2.37, Кек (?), 14:30, 04/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
я вообще не понимаю, что за хрень они выдумывают. Не проще заняться оптимизацией кода и сделать браузер человеческим? а не 2ГБ на вкладку? За что им там платят деньги?
| |
|
|
4.74, Аноним (73), 18:58, 04/11/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Если не он лично, то его друзья и родственники слили гуглу столько ценной информации, что на несколько браузеров хватит.
| |
|
|
6.102, гугель (?), 12:46, 05/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
почему не делимся? Делимся. Вы на халяву пользуетесь нашим ютрупом, нашей почтой, нашим поиском и много чем еще о чем даже не догадываетесь, что они наши.
Взамен мы получаем - вас, разумеется. Со всеми потрохами. Ну так вам же и не жалко, вы ж уже лет десять живете в домике со стеклянными стенами?
| |
|
|
|
|
2.92, pda (?), 00:35, 05/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> Что-то я ещё вживую второй не видел, а они уже третий пихаютъ...
Мы что, нашли человека ни разу не заходившего в последнее время на google?
https://www.google.com/
Host: www.google.com
<...>
GET: HTTP/2.0 200 OK
<...>
| |
|
3.103, Аноним (1), 12:55, 05/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> ни разу не заходившего в последнее время на google?
Есть такое, предпочитаю ddg.gg
| |
|
|
|
2.5, Аноним (7), 10:26, 04/11/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
А кто кроме Мозиллы реализацию на расте напишет? Всё правильно сделали.
| |
|
|
|
5.77, Ordu (ok), 19:20, 04/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Это не фрагментация, это множественные реализации протокола. Крайне сложно или даже невозможно отделить тесты протокола от тестов реализации протокола, если у тебя нету нескольких реализаций.
| |
|
4.67, xl32 (ok), 17:46, 04/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Cloudflare модуль интеграции nginx с либой написали, если что.
| |
|
|
|
3.80, Аноним (79), 19:53, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Ну это нормально. У них. У нас некоторые бюджетники тоже столько получают. И умудряются жить. На радость государству.
| |
|
|
|
|
3.58, Аноним (35), 16:55, 04/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Только cdn он не от доса, даже клаудфлар это знает и у него для этого отдельная услуга
| |
|
|
1.8, Аноним (8), 10:38, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Хром на моем тестовом сервере работает, но как то через раз может с h3 перейти на h2 при рефреше, но если добавить флаг --origin-to-force-quic-on=domain:443 но всегда будет на h3, но фокс вообще не грузит сайт если включить http3.
| |
1.9, Аноним (9), 11:09, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
> ...тестовых сайтов, большая часть из которых ... не открывается в Firefox
Ясно, понятно. Про что новость?
| |
1.10, Sw00p aka Jerom (?), 11:23, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
>0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения)
Это усиленная версия Syn флуда? Теперь и канал можно забивать.
| |
|
2.13, мурзилла (?), 11:43, 04/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
это udp флуд. Теперь ты не можешь использовать ни tcp cookies, ни хотя бы отфильтровать китайские сети - все пакеты придут с фейковых адресов твоих реальных посетителей.
Полагаю, и канал забивать не придется, сайт ляжет от сравнительно небольшого числа этих "0rtt".
Ну, гуглю ведь пофиг на твои страдания. А нормальный http-протокол скоро запретят. Ишь чего выдумали, каждый васян может поднять свой веб-сервер! Веб -серверы должны быть только у достойных людей, способных заплатить за ненужные ресурсы и ненужные сервисы типа клаудфлери.
А попутно подарить инфу о своих пользователях всем подряд, конечно же.
| |
|
3.22, suffix (ok), 12:32, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
У меня не http/3 конечно, но включил в nginx TLS 1.3 0-RTT и TCP Fast Open. Включил в настройках Firefox TCP Fast Open (0-RTT включено по умолчанию). Протестировал в wireshark - реально для повторных соединений на две транзакции меньше !
Так что плюс от всего этого добра есть, минусов же никаких не вижу.
| |
|
4.27, Аноним (2), 13:33, 04/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да, это всё отлично работает. Но вроде rtt и fast open рекомендуют отключать в целях безопасности. У меня вообще венда и лтс фф в юзерагенте оказывается (в венде fastopen и не было, как сейчас не знаю, но она ворует успешные идеи).
Security by obscurity всегда хорошо работает, если кто-то захочет использовать информацию во вред, можно его обломать немножко. Чем больше уровней обломов, тем дороже и не выгодней взлом. Тем более, что у фф песочница всегда проблемная была. Её регулярно ломают, у хрома с этим получше.
А для сервера это видимо возможность лечь под небольшой нагрузкой. Кажется я ложил случайно некторые, но это не точно. Приходилось себя ограничивать, чтобы не создавать проблем.
| |
|
5.30, suffix (ok), 13:52, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> в венде fastopen и не было, как сейчас
> не знаю, но она ворует успешные идеи.
Давно уже в Edge есть - правда было по умолчанию а сейчас включать в настройках надо.
| |
|
|
5.31, suffix (ok), 13:52, 04/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Еще htcp включи и буфера увеличь, вообще летать будет.
Не смог осилить вашу фразу - извините.
| |
|
6.32, Аноним (2), 13:59, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Про буферы, может быть это про то, чем занимался fasterfox? Как там более поздний вариант назывался, fasterfox lite кажется? Всё равно на сервера, главное, чтобы быстро грузилось.
| |
6.36, Аноним (36), 14:29, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Через сисцтл/прокфс увеличиваются буфера, рмем вмем ипр, там же выставляется tcp congestion control htcp или hybla вместо дефолтного кубика, перед этим нужно модули в ядро подгрузить. Подробности для копипасты в гугле есть.
| |
|
7.41, suffix (ok), 14:38, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> там же выставляется tcp congestion control htcp или hybla
С пониманием этой части вопросов и не было
А вот
>рмем вмем ипр
Слишком загадочно для меня :)
Ибо везде пишут что менять там что либо стоит на высокозагруженных проектах только. У меня при максимальной загрузке LA около 0 всегда и free -h свободными 50GB памяти показывает.
Не вижу смысла теребить эти настройки.
| |
|
8.42, Аноним (2), 14:47, 04/11/2019 [^] [^^] [^^^] [ответить] | +1 +/– | Он про это https wiki archlinux org index php Sysctl Increase_the_memory_dedi... текст свёрнут, показать | |
|
9.43, suffix (ok), 14:50, 04/11/2019 [^] [^^] [^^^] [ответить] | +/– | Спасибо - это понятно, но в моём случае не понимаю зачем их трогать - выше в пос... текст свёрнут, показать | |
|
8.45, Аноним (36), 15:06, 04/11/2019 [^] [^^] [^^^] [ответить] | +1 +/– | Это не для того чтобы у тебя проц не жрало а для того чтобы раздавало быстрее ... текст свёрнут, показать | |
|
9.60, suffix (ok), 17:03, 04/11/2019 [^] [^^] [^^^] [ответить] | +/– | Ну добавил net ipv4 tcp_slow_start_after_idle 0 net core rmem_max 16777216 ne... текст свёрнут, показать | |
|
|
|
|
|
|
3.33, Аноним (33), 14:06, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> все пакеты придут с фейковых адресов твоих реальных посетителей.
Эти 0rtt адреса еще заполучить надо, для тысяч сервисов и сайтов. К тому же, полагаю, они будут тут же выброшены из списка 0rtt, если продолжение обмена далее не последует.
| |
|
4.53, пох. (?), 16:33, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
зачем? Подделывай сотнями тысяч, это ж udp, твоих затрат ноль. В кого-нибудь да попадешь.
> К тому же, полагаю, они будут тут же выброшены из списка 0rtt, если продолжение обмена далее
> не последует.
это несказанно порадует легитимного пользователя. И ничуть не снизит нагрузку на твой сайт, ибо весь смысл 0rtt в том что никакого "обмена" толком и нет.
| |
|
5.76, Аноним (76), 19:18, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> это ж udp, твоих затрат ноль
Сможешь хотя бы опеннет задудосить?
| |
5.83, Аноним (33), 21:10, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> В кого-нибудь да попадешь.
Вся суть в усилении трафика сервисами. Вероятность попасть околонулевая.
| |
|
|
|
|
1.28, Аноним (29), 13:45, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Пропаганда а не техническая публикация. Все это было на швабре на неделе.
Пока не будет вменяемых тестов, инсирументов отладки (парсеры в тцпдумп и ваиршарке) и нормальных реализаций в виде сишных либ - это все так и будет бесполезным хламом от гугля ради гугля.
| |
|
2.38, Аноним (35), 14:30, 04/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Проблема в том что гугль продвинет это во все браузеры раньше чем спецификации установится.
Если ничего глобального не всплывет, то орды мамкохостеров и маркетологов подхватят этот http3 и вознесут его на свой золотой унитаз.
Дальше уже тулзам придётся подстраиваться, ведь "сейчас все используют http3".
В общем в этом никчемном мире все нередко делается наоборот.
| |
2.44, h31 (ok), 14:58, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> парсеры в тцпдумп и ваиршарке
Удачи в парсинге зашифрованного трафика. Да, я в курсе про флаги для отладочного дампа ключей, но это всё очень неудобно и неуниверсально, так что пригождается только в качестве крайней меры.
| |
|
3.57, Аноним (35), 16:52, 04/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ты же своё приложение шифруешь на своей машине и на своей же принимаешь.
У тебя в любом случае есть ключи для расшифровки вопрос только как их достать удобнее.
| |
|
|
1.34, Аноним (34), 14:09, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Чем он вообще от http2 отличается окромя 0-RTT?
В нем же уже есть мультиплексирование вродь, нет блокировок если использовать эти самые потоки, что еще нужно?
| |
|
|
3.46, Аноним (34), 15:10, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Вот оно что. А 3 он потому что решили не использовать минорные версии, как я полагаю.
| |
3.95, KonstantinB (ok), 07:21, 05/11/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
О каких костылях TCP речь?
QUIC (который по сути и есть userspace-реализация TCP) больше похож на костыли (хотя и необходимые в условиях нестабильной мобильной связи).
| |
|
2.54, Аноним (35), 16:34, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Не знаю как сейчас, а раньше было так:
К ip назначается id, якобы чтобы не (разрывать) создавать новое соединение при смене вафли на lte (не уверен).
Выполняется в пространстве пользователя (а значит медленнее и энергозатратнее, то же относится и к
) (в теории могут исправить, но гугл "не хочет ждать пока обновятся ос")
Нет защиты от флуда (syn Кук)
Хуже работает если пакеты приходят не в том порядке (это относительно частая ситуация)
Закрыт файрволами во многих (корпоративных) сетях
В общем это как и http2 протокол от гугла и для специфичных гуглу юзкейсов, но и в них есть гигантские проблемы. Если внедрят чую будет очень много боли.
| |
|
1.48, mumu (ok), 16:02, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
В каждой новости про HTTP/3 стоит дописывать, что при потере пакетов уже в 2% HTTP/3 становится медленее, чем HTTP/2.
| |
|
2.50, Аноним (7), 16:06, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Нафиг он тогда нужен? Его же ради работы при потере пакетов в беспроводных сетях и делали.
| |
|
3.55, пох. (?), 16:34, 04/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
не хотел бы тебя расстраивать, но его делал гугль - у которого сети вполне себе проводные, и неограниченной пропускной способности. И решать он собирался свои проблемы, а вовсе не твои.
Причем - за твой счет.
| |
|
4.61, Аноним (7), 17:24, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
у гугла - проводные, а вот у пользователей ютьюба - как раз беспроводные.
| |
|
5.68, гугель (?), 17:50, 04/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
ты правда думаешь что нас колебут проблемы пользователей?
Нас колебет чтобы снизить нагрузку на наши серверы. А что от этого у них начнет глючить и лагать все что тянется параллельно ютубу, вырастет в разы нагрузка на инфраструктуру оператора и так далее - нам совершенно, вопиюще похрен.
| |
|
6.87, Аноним (33), 21:21, 04/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну вот, еще оператора влепили. Проблемы операторов никого не волнуют. Передача трафика - это их прямая работа.
Повышение нагрузки от UDP в контексте клиентов незначительно. Вы выдумываете проблему на ровном месте.
| |
|
|
4.86, Аноним (33), 21:16, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> у которого сети вполне себе проводные, и неограниченной пропускной способности
Что-то не замечал проводного соединения между моим мобильным и гуглом...
> И решать он собирался свои проблемы, а вовсе не твои.
Это не так. А даже если и так, одно другому не мешает. Уменьшая частоту повторной буферизации, гугл имеет снижение трафика и нагрузки. А пользователь имеет более качественную услугу.
| |
|
5.117, Аноним (117), 00:44, 09/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Откуда вы все лезете? Ещё в прошлой теме прожевали несколько презентаций этого квига с цифрами. И снова как в первый раз про более качественные услуги.
| |
|
|
|
2.78, Аноним (78), 19:42, 04/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Принеси пруф.
Я видел это утверждение в контексте HTTP/2 применительно к HTTP/1.1 – но не к HTTP/3
https://http3-explained.haxx.se/en/why-tcphol.html
> It becomes a TCP-based head of line block!
> As the packet loss rate increases, HTTP/2 performs less and less well. At 2% packet loss (which is a terrible network quality, mind you), tests have proven that HTTP/1 users are usually better off - because they typically have up to six TCP connections to distribute lost packets over. This means for every lost packet the other connections can still continue.
> Fixing this issue is not easy, if at all possible, with TCP. | |
|
3.99, mumu (ok), 08:38, 05/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Действительно так. Я был не прав. Спасибо за исправление!
| |
|
|
3.97, Ivan_83 (ok), 07:30, 05/11/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
Только вот ЭТУ проблему сами и создали в http/2 - не нужно одно соединение было делать, и сравнивать квик надо не с отстойным 2 а с 1.1 на 5-10 конектах, и более чем уверен что квик тут мало чем сможет похвастатся для сайтов где много картинок, особенно тяжёлых.
| |
|
4.118, Аноним (33), 01:35, 09/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Несколько коннектов накладно для сети и сервера, и в принципе является не решением проблемы, а только лишь костылем, позволяющем снизить ее негативное влияние.
| |
|
|
2.98, mumu (ok), 08:37, 05/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Прошу прощения за неточность. Про потери действительно относилось к HTTP/2 vs 1.1. В голове перемешалось :-(
| |
|
1.51, Аноним (51), 16:13, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
> решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных
Слабо верится что это действительно такая проблема что бы городить всё это, кажется что причина в чём то другом.
| |
|
2.88, Аноним (33), 21:24, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
> кажется что причина в чём то другом.
Правильно кажется. Но это не достаточный повод прочитать статью целиком, верно?
| |
2.91, Аноним (91), 00:30, 05/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Это чтобы куки встроить. Достаточно послать кривой пакет, чтобы получить данные. TCP даже не ответит, а тут - вот то самое вчерашнее наконец-то. И не отключишь как пинги. Чтобы сократить на 30% повторы трафика достаточно не удалять данные во время просмотра и отдавать в буфер на 30% меньше данных, а не создавать целый новый протокол поверх протокола.
| |
|
|
2.62, Аноним (7), 17:26, 04/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
нет. А вот поддержка ipv6 как раз будет. Каждому устройству по персональному адресу для отслеживания.
| |
|
1.59, Аноним (59), 16:56, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Через пять лет:
"В CloudFlare Firefox 735 появилась поддержка GoogleHTTP/27."
| |
|
2.64, Аноним (7), 17:27, 04/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
firefox не протянет эти 5 лет, если мозилла не перестанет дурью маяться.
| |
|
3.81, Аноним (79), 19:59, 04/11/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если она уже ступила на этот путь, и сделала по нему немало шагов, улучшений ждать не приходится. Былую функциональность уже не вернуть. Эра тинейджеров-домохозяек уже здесь.
| |
|
|
|
2.89, Аноним (33), 21:28, 04/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Зависит от того, какой протокол используется. Логично предположить, что было бы глупо использовать HTTP там, где критичны задержки.
| |
|
|
2.100, xl32 (ok), 11:17, 05/11/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
> В nginx когда завезут?
Официально — обещают в течение 6-12 месяцев.
Неофициально — Cloudflare уже модуль и патчи сделали для линковки с либой на расте.
| |
|
1.106, Аноним (79), 16:48, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Хм... неужели сейчас мазила так хороша, что приходиться выбирать ее из всех известных браузеров (под Винду, имеется в виду)?!
Или здесь уже вступает другое правило - она наименее дерьмовая из всего остального шлака, что сейчас есть?
| |
|