Информация об изменениях

Сообщение Re[13]: TCP все... от 17.11.2018 10:37

Изменено 17.11.2018 10:45 Somescout

Re[13]: TCP все...
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Somescout, Вы писали:


C>>>Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ).

S>>А с чего вдруг это проблема?
C>Увеличивает число пакетов. Именно число пакетов в секунду нынче является узким горлышком в железе.

Разница минимальна, более того со всеми подобными проблемами куда лучше справляется IPv6. Но гугля не хочет его ждать у гугли чешется NIH.

C>При учёте пакетов не забываем отсутствие тройного рукопожатия, при 0-RTT сервер отправляет данные в первом же пакете.


Лол — QUIC показывает наилучшие результаты на broadband, а когда пугают "тремя рукопожатиями" используют примеры с таймингами чуть ли не из мобильной связи, где QUIC отсысывает. Это "три рукопожатия" на нормальном канале дадут 100-200 миллисекунд (в худшем случае!) на первом подключениии — хром будет дольше layout страницы делать.

S>>Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше).

C>ЩИТО?

"Маршрутизацией", посмотрите значение в словаре.

S>>ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты.

C>ЩИТО?

ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.
Re[13]: TCP все...
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Somescout, Вы писали:


C>>>Одной из проблем в Интернете является PMTU — поиск максимального размера пакета. Потому многие серверы тупо ставят что-то типа 1380 (Google) для гарантии того, что ответы пройдут через любые разумные тоннели ( https://jamesdobson.name/post/mtu/ ).

S>>А с чего вдруг это проблема?
C>Увеличивает число пакетов. Именно число пакетов в секунду нынче является узким горлышком в железе.

Разница минимальна, более того со всеми подобными проблемами куда лучше справляется IPv6. Но гугля не хочет его ждать у гугли чешется NIH.

C>При учёте пакетов не забываем отсутствие тройного рукопожатия, при 0-RTT сервер отправляет данные в первом же пакете.


Лол — QUIC показывает наилучшие результаты на broadband, а когда пугают "тремя рукопожатиями" используют примеры с таймингами чуть ли не из мобильной связи, где QUIC отсасывает. Это "три рукопожатия" на нормальном канале дадут 100-200 миллисекунд (в худшем случае!) на первом подключениии — хром будет дольше layout страницы делать.

S>>Максимум это немного (действительно ненамного) повышает нагрузку на оборудование провайдера (затраты на маршрутизацию пакетов, но визуально это заметно когда пакеты сильно меньше килобайта. Да и в любом случае геморроя с маршрутизацией UDP будет больше).

C>ЩИТО?

"Маршрутизацией", посмотрите значение в словаре.

S>>ЗЫ. Ютуб тупит на любом браузере далеко не из-за протокола, но лучше ведь в очередной раз поставить интернет раком, а не фиксить свои сайты.

C>ЩИТО?

ШИ ТО. Ютуб второй после твитча случай, когда программистам можно пересадить руки макаки и это не ухудшит результат. Гугль гонится за миллисекундами скорости, игнорируя что один из их основных сайтов тормозное ****.