Post #529

А написать я хотел про синхронные и асинхронные взаимодействия, по следам предыдущего (теперь уже пред-предыдущего) поста. Андрей Бураков справедливо заметил, что WebSockets-то асинхронный, а я его в синхронные записал, вот позор. Но логика у меня в этот момент была вот какая: если нам нужен быстрый отклик — мы берем паттерн "запрос-ответ", то есть RPC и REST. Но если нам нужен ещё более быстрый отклик — мы берём WebSockets, где взаимодействие асинхронное. Ну или используем Long Polling, WebHooks или MQTT — все они асинхронные, и все применяются, когда нам нужно очень быстро отреагировать на событие. Следующий шаг в этом же направлении, но на другом уровне, сделал Google со своим протоколом QUIC, заменяющим TCP. Потому что установка соединения TCP — слишком дорогая и долгая операция, а делать её приходится почти при каждом запросе (да, есть keep-alive, тогда соединения будут держаться дольше, но у этого есть и обратная сторона — именно это соединение нужно использовать, пока оно живо. Иначе у вас будет много живых соединений и, соответственно, много занятых портов). Протокол QUIC в основном ориентирован на веб-браузеры, а веб-браузеры имеют обыкновение запрашивать много разных ресурсов одновременно. Хотя каждый запрос сам по себе синхронный, выполняются они в java script'е асинхронно, через промисы и async/await, и про это есть много шуток у фронтендеров — очень больная тема, сложно понять. Хуже того, ваш компьютер внутри тоже весь работает асинхронно — через механизм прерываний. Любое действие — нажатие на кнопку на клавиатуре, движение мышью, поступление нового пакета на сетевой адаптер — на самом деле останавливает выполняемую программу и вызывает специальный обработчик. И очереди, очереди везде! Ну и как только нам не нужна мгновенная реакция, мы тоже используем очереди. Асинхрон, когда нам нужно быстро отреагировать, асинхрон, когда нам не нужно быстро реагировать. Получается, в этом в целом асинхронном мире есть довольно узкая прослойка — место для условно синхронных коммуникаций, где-то в районе от 100 миллисекунд до секунды, где они могут работать. Именно здесь работают все пользовательские интерфейсы, и именно в этом временном промежутке вырос весь Web на базе REST API. По случайному совпадению, этот диапазон как раз соответствует человеческому восприятию "мгновенной реакции". Она как раз примерно от 100-120 мс у гонщиков F1, пилотов истребителей и топовых кибер-спортсменов, до 250-300 мс — у обычных людей. Можете проверить себя: https://humanbenchmark.com/tests/reactiontime , у меня как раз 253 получилось в среднем. Хорошее пятничное развлечение :) Так случайно совпало, что типичные http-запросы выполняются как раз примерно за 300-900 мс (передача данных через websocket — 200 мс). Действий быстрее 13 мс человек вообще не воспринимает (скорость обмена в 5G-сетях — 15 мс, это быстро). Аукцион рекламодателей за рекламное место на веб-странице — RTB — занимает 100-200 мс. В высокочастотном трейдинге решение о сделке принимается за микросекунды. На таких скоростях важным становится расстояние между серверами, поэтому их ставят прямо в датацентре биржи или вообще втыкают прямо в PCI-шину биржевого сервера. Вызов обработчика прерываний вообще в тактах процессора считается — это наносекунды для современных компьютеров. Такие скорости у нас. И в некоторых случаях становится принципиально, что действие происходит не мгновенно, а за конкретное не нулевое время.