когда tcp window маленький, то печаль-беда

я не просто уверен, я это неоднократно видел

получается в HTTP/2 это не учли?

ну и да, на long fat network да с потерями запросто получишь невозможность утилизировать всю полосу

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

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

полоса у тебя может быть хоть 10гбит, но если latency там 2с секунды, тебе понадобится огромное окно

так и лейтенси сегодня все хорошо

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

и ты смотришь как оптимист, не глядя на реалии

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

+ У меня давно ощущение, что сети по умолчанию можно считать быстрыми, но ненадёжными

жаэе на мобилке rtt единицы миллисекунд

и ты смотришь как оптимист, не глядя на реалии

да ладно :) я же делал мобильную рекламу

Смотря докуда, смотря вообще какой кейс

+ У меня давно ощущение, что сети по умолчанию можно считать быстрыми, но ненадёжными

тут вопрос был в том, надёжнее ли HTTP/1.1 со своими 6-8 параллельными TCP/IP соединениями без мултиплекса, или HTTP/2 со своим 1 TCP/IP соединением но с мультиплексом

а вот тут прячется ответ

Проверочное задание - понять, почему openvpn / tcp работает в разы медленнее udp

6-8 параллельных ssl это дорого для сервера

жаэе на мобилке rtt единицы миллисекунд

Да ну?

и именно эту проблему решает гугл. для себя!

6-8 параллельных ssl это дорого для сервера

да вот и я о чём

Проверочное задание - понять, почему openvpn / tcp работает в разы медленнее udp

+много. Особенно интересует вариант с пакетлосс

это, кстати, не всегда так

6-8 параллельных ssl это дорого для сервера

Это почему?

потому, что RSA

плюс 6х - 8х прирост голода на память

сегодня мы в проц упираемся - у нас тупо rsa пары медленно генерятся

потому, что RSA

Один раз

это как?

в 6х - 8х больше file-descriptor'ов на котоых select'ить (хотя я не уверен насколько это дороже для современных kqueue, epoll)

жаэе на мобилке rtt единицы миллисекунд

50ms, вот только проверил - 65ms до ya.ru

в 6х - 8х больше file-descriptor'ов на котоых select'ить (хотя я не уверен насколько это дороже для современных kqueue, epoll)

O(1)

50ms, вот только проверил - 65ms до ya.ru

и не факт что долетит

O(1)

в любом не может быть 6-8 соединений настолько же дёшево как 1

50ms, вот только проверил - 65ms до ya.ru

у меня - 30. видимо, что-то изменилось

и не факт что долетит

Да, на радио не такое бывает

у меня - 30. видимо, что-то изменилось

Сильно зависит от соты, ее загруженности и ещё кучи факторов

угум

но даже 30 - это очень мало

т.е. я правильно понимаю что HTTP/2 хуже себя поведёт в случае высокого packet-loss?

так же он себя поведет

просто ретрансмиты будут все соединения тормозить, а не одно

так же он себя поведет

я просто предполагал что @pragus имеет ввиду, что при наличии нескольких TCP/IP соединений, когда например соединение 1 делает запрос но валится - он естественно откатывается на sleep чтоб предотвратить загрузку и без того загруженной сети а следующий запрос будет осуществлять соединением 2, и тут например сеть будет менее насыщеной и поэтому потери пакетов не будет и запрос выполнится ещё до того, как соединение 1 перепошлёт свой первый запрос так? т.е. если у нас несколько соединений, то timeout wait на каждое соединение индивидуально и вероятность восстановления сети до timeout'а выше, следственно throughput чуток выше но latency инициализации соединений будет больше чем с 1 и памяти больше будет жрать, и если в сети потерь мало, то всё это - напрасно

эммм

если мы не уперлись в полосу - а мы не уперлись - мы уперлись в rtt

rtt у нас одинаковый, что мы один пакет шлем, что 10

latency будет одинкавая, соответсвенно, хоть 1 соединение устанавливай, хоть 10

но если соединение одно с мультиплексированием - на один пакет, в среднем, больше информации приходится, и потеря его, соответственно, больнее отзывается

rtt у нас одинаковый, что мы один пакет шлем, что 10

мм, я думаю я не про round-trip-time, a про retransmit delay

если мне не отказывает память, то TCP/IP старается беречь сеть нагружая её меньше обнаружив packet loss

latency будет одинкавая, соответсвенно, хоть 1 соединение устанавливай, хоть 10

А сколько алгоритмов congestion control у нас будет исполняться в случай 1 и 10 соединений?

т.е. от первого retransmit до второго может вырасти delay

А сколько алгоритмов congestion control у нас будет исполняться в случай 1 и 10 соединений?

по одному на соединение, понятное дело

А сколько алгоритмов congestion control у нас будет исполняться в случай 1 и 10 соединений?

короче если я тебя правильно понял, то в сетях с большой потерей - несколько соединений выгоднее потому-что congestion control откатывает на более высокий delay индивидуально на каждое соединение (однако непредсказуемо, насколько это выгодно, зависит от сети, как повезёт) а в случае сетей с низким уровнем потерь или вообще их отситствием - несколько соединений лишь сжирают лишнюю память и CPU

Сетей без потерь не бывает, или бывают, но на некоторое время, и при некотором объеме траффика

вопрос в сочетании количества потерь и latency.

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

Сетей без потерь не бывает, или бывают, но на некоторое время, и при некотором объеме траффика

суть я думаю в том, что networtk congestion чаще возникает не из-за interference'а беспровоной сети, а переполнения буферов роутеров. В таком случае, если packet loss происходит в результате router buffer excess - ни 2, ни 8, ни 100 паралелльных TCP/IP соединений в теории не спасут и не будут агировать лучше одного единственного

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

для серверов

короче если я тебя правильно понял, то в сетях с большой потерей - несколько соединений выгоднее потому-что congestion control откатывает на более высокий delay индивидуально на каждое соединение (однако непредсказуемо, насколько это выгодно, зависит от сети, как повезёт) а в случае сетей с низким уровнем потерь или вообще их отситствием - несколько соединений лишь сжирают лишнюю память и CPU

Да, объем передаваемых данных один и тот же Ну за счёт того что они размазаны по нескольким соединениям tcp не настолько пессимистичен

суть я думаю в том, что networtk congestion чаще возникает не из-за interference'а беспровоной сети, а переполнения буферов роутеров. В таком случае, если packet loss происходит в результате router buffer excess - ни 2, ни 8, ни 100 паралелльных TCP/IP соединений в теории не спасут и не будут агировать лучше одного единственного

Там вообще все сразу

Да, объем передаваемых данных один и тот же Ну за счёт того что они размазаны по нескольким соединениям tcp не настолько пессимистичен

интересная мысль однако. Нужно подумать как реализовать поддержку нескольких underlying TCP/IP с round-robin в webwire-go, для конкретно таких случаев спасибо за мысль!

интересная мысль однако. Нужно подумать как реализовать поддержку нескольких underlying TCP/IP с round-robin в webwire-go, для конкретно таких случаев спасибо за мысль!

По этой причине, например, syncthing на длинных дистанциях не может делегировать всю полосу

По этой причине, например, syncthing на длинных дистанциях не может делегировать всю полосу

да уж, это хреново. в любом случае нужно тестировать, создать виртуальную сеть с симуляцией больших потерь и опробовать на ней webwire 2.0, попробовать добавить поддержку нескольких underlying соединений в 2.1 и сравнить throughput & latency

в идеале webwire должен сам понять, какое колво соединений в каком случае лучше использовать учитывая какое макс. колво разверешает сервер... но это уже звучит сложнее..

да уж, это хреново. в любом случае нужно тестировать, создать виртуальную сеть с симуляцией больших потерь и опробовать на ней webwire 2.0, попробовать добавить поддержку нескольких underlying соединений в 2.1 и сравнить throughput & latency

tc-netem в помощь ;)

tc-netem в помощь ;)

??

На стороне сервера ты вынимаешь значение из query, а надо десереализовать тело запроса

ERROR: S client not available

На стороне сервера ты вынимаешь значение из query, а надо десереализовать тело запроса

извините, я новичок, как это сделать?

извините, я новичок, как это сделать?

Вот, но с помощью не родного роутера, а с посредством gin (вообще, рекомендую) https://medium.com/go-to-golang/создания-api-restful-сервера-с-golang-и-mysql-3085133bab91

извините, я новичок, как это сделать?

И вот неплохая статья https://pragmacoders.com/building-a-json-api-in-golang/

извините, я новичок, как это сделать?

Ещё советую посмотреть сюда https://golang.org/pkg/net/http/#pkg-examples

спасибо, теперь знаю что буду делать весь вечер и ночь)

извините, я новичок, как это сделать?

И конечно сюда https://golang.org/pkg/net/http/#ResponseWriter

в которой из двух про сваггер?

спасибо, теперь знаю что буду делать весь вечер и ночь)

Не волнуйся, освоишься довольно быстро

если ни в одной - не надо их читать :)

в которой из двух про сваггер?

Ему хотя бы основы понять, потом можно и сваггер лепить

что посоветуете для RPC, а точнее микросервисной архитектуры? нужно реализовать сервисы наблюдения за событиями, которые будут создавать и назначать необходимые "таски" go-kit?

извините, я новичок, как это сделать?

Ну и да, @onokonem правильно говорит, как разберёшься с основами — посмотри на swagger, он кучу геморроя уберёт

есть уже пара выделенных сервисов, которые через nginx-проксирование распределяются, но нужно добавлять функционал такого вида

что посоветуете для RPC, а точнее микросервисной архитектуры? нужно реализовать сервисы наблюдения за событиями, которые будут создавать и назначать необходимые "таски" go-kit?

как-то даже не знаю, зависит от конкретных обстоятельств: как события приходят, что с ними надо делать, какие протоколы скорее всего ничего не посоветовать >_>

юзкейс описан так себе? :) или просто хз? ))

стандарта на это, даже defacto, нет

никто просто не знает, что лучше-хуже

да вот же, и я тем же вопросом получается задаюсь)

юзкейс описан так себе? :) или просто хз? ))

и то и то нет каких-то общих решений, чаще всего удобнее написать с нуля и посмотреть куда пойдёт дело

и то и то нет каких-то общих решений, чаще всего удобнее написать с нуля и посмотреть куда пойдёт дело

справедливо, похоже придется пробовать пару вариантов и смотреть по производительности и "прожору" памяти

коллега

вы json собрались маршалить-анмаршалить

справедливо, похоже придется пробовать пару вариантов и смотреть по производительности и "прожору" памяти

я бы лучше посмотрел по удобству написания и надёжности ) иногда такой трындец в библиотеках, что хочется самому половину завелосипедить

вам на все остальное строго пофиг

в смысле производительности и памяти

не течет - и ладно

кек, есть смысл в этих словах, однако стараюсь заботиться о ресурсах

забейте

потом попрофилируете и решите проблемы, если будут

сборщик мусора разогнали до микросекунд, можно и забить)

понятно, будет чем поделится - поделюсь)

тут у нас только @pragus с задачей, в которой имеет смысл такты считать :)