# Как измерить латентность Binance API со своего сервера > Латентность Binance — это география: матчинг-движок работает в регионе AWS Tokyo, поэтому полный круг занимает около 20–25 мс из Токио и порядка 270 мс из Европы. Разбираем, как узнать свою реальную цифру — ping вам соврёт. - Источник: https://papaproxy.net/ru/blog/binance-api-latency.php - Опубликовано: 2026-08-01 - Автор: Alex Young - Рубрика: Лимиты и производительность · Блог PapaProxy.net --- ## Ключевые выводы - Матчинг-движок живёт в AWS Tokyo (ap-northeast-1): закладывайте ~20–25 мс полного круга из Токио, ~70–100 мс из Сингапура и Сеула, ~120–180 мс из США, ~270 мс из Европы. - Не верьте ping: API фронтится CDN, и ICMP меряет дорогу до ближайшего края, а не до движка — хронометрируйте полные вызовы API. - Мерьте прогретой keep-alive-сессией, 200 сэмплов, персентилями: p50 — ваша география, разрыв p50–p99 — качество маршрута. - В нашем бенчмарке июля 2026-го японские адреса показали p50 = 22 мс до Spot API, немецкие — 268 мс, американские — 164 мс: точка выхода и есть латентность. - WebSocket API срезает накладные расходы на запрос, FIX срезает их ещё сильнее, но все транспорты едут по одному волокну: протоколы экономят миллисекунды, география — сотни. - Оцените свою латентность в деньгах пробным ордером: цена решения против цены исполнения на нескольких десятках маленьких ордеров — ваш личный налог проскальзывания. - За близостью гонитесь только на ордерном пути; путь данных — задача параллельности, а не расстояния. ## Где на самом деле находится матчинг-движок Любой вопрос о латентности Binance сводится к одному факту: матчинг-движок работает в токийском регионе Amazon, ap-northeast-1. Это не секрет — инженерный блог самого AWS называет Binance среди бирж, сконцентрированных в Токио, а когда в октябре 2025-го токийский регион пережил сбой, Binance лёг вместе с соседями. Вопрос о расположении серверов, таким образом, закрыт физикой: ваши запросы летают в Японию и обратно, и никакая оптимизация кода не укорачивает Тихий океан. Есть, правда, тонкость, которая ломает наивные замеры. Публичные хосты API фронтятся CDN, поэтому на ваш TCP-хендшейк отвечает ближайший краевой узел — возможно, в вашем же городе, — а реальная работа всё равно происходит в Токио. Именно поэтому `ping api.binance.com` из любой точки мира возвращает льстивые одно-двузначные числа: вы меряете дорогу до края, а не до движка. Любой замер, который что-то значит, должен хронометрировать полный вызов API — от запроса до ответа. ## Типичные значения из разных регионов Сначала честные цифры, потом — как получить свои. С сервера в Токио полный REST-круг до Spot API занимает около 20–25 мс. Из Сингапура и Сеула вы в полосе 70–100 мс. Из США — примерно 120–180 мс в зависимости от побережья. Из Европы закладывайте порядка 270 мс: Франкфурт—Токио и обратно — это просто четверть секунды оптоволокна, ещё до того, как биржа что-либо сделает. Наблюдаемое время полного круга почти целиком определяется этой географией; всё остальное — украшения ценой в единицы миллисекунд. Свой замер занимает дюжину строк — с тремя правилами, которые делают результат честным: используйте постоянную сессию, чтобы установка TLS не входила в каждый вызов; прогрейте соединение до начала замера; и считайте персентили вместо одной «типичной» цифры — задержка в миллисекундах есть распределение, и p95 — это то, что почувствует ваш самый неудачно отправленный ордер: PythonКопировать код ```python import time, statistics, requests s = requests.Session() URL = "https://api.binance.com/api/v3/time" s.get(URL) # прогрев: TLS + переиспользование соединения samples = [] for _ in range(200): t0 = time.perf_counter() s.get(URL) samples.append((time.perf_counter() - t0) * 1000) samples.sort() p = lambda q: samples[int(q * len(samples)) - 1] print(f"p50={statistics.median(samples):.0f} ms p95={p(0.95):.0f} ms p99={p(0.99):.0f} ms") ``` На что смотреть в выводе: p50 — это ваша география, а разрыв между p50 и p99 — качество маршрута: узкий разброс означает чистый путь, широкий — джиттер, который укусит ровно в момент движения рынка. Одна оговорка для торговых решений: публичные эндпоинты отвечают через CDN-слой, поэтому перед выбором локации сервера повторите проверку авторизованным вызовом с вашего реального ключа — именно этим путём пойдут ордера. Собственную статистику задержек мы держим свежей, гоняя ровно этот бенчмарк со своей сети (200 keep-alive-вызовов `/api/v3/time`, июль 2026): с наших японских адресов p50 составил 22 мс при p95 в 28 мс; с немецких — 268 мс; с американских — 164 мс. Разброс между регионами совпал с физикой почти точно — в этом и суть: ваша точка выхода *и есть* ваша латентность. ## Как мерить FIX- и WebSocket-подключения REST — самый медленный из честных способов говорить с Binance: каждый запрос может платить за установку соединения и полную HTTP-обвязку. Два более быстрых транспорта меняют сам смысл слова «латентность», поэтому и меряются иначе. История WebSocket API — про амортизацию: соединение устанавливается один раз, так что отдельные запросы целиком пропускают TCP- и TLS-сетап и летят по уже открытой трубе. Мерьте время «запрос—ответ» *внутри* прогретого соединения — с той же персентильной дисциплиной — и ожидайте цифры заметно ниже ваших REST-значений с той же машины, с более узким разбросом. А для маркет-данных стримы переворачивают вопрос: вы хронометрируете уже не свои запросы, а возраст данных к моменту их прихода. Латентность FIX API важна на самом остром конце спектра. Binance даёт FIX на споте для выставления ордеров и маркет-данных — сессии аутентифицируются ключами Ed25519, — а сообщения фиксированного формата срезают накладные расходы на парсинг и фрейминг, которые HTTP несёт по построению. Честная иерархия из одной локации: REST медленнее всех, WebSocket API ощутимо быстрее на запрос, FIX — быстрее и стабильнее всего. И столь же честная оговорка: все три едут по одному оптоволокну. Смена протокола из Европы переставляет несколько миллисекунд поверх географического счёта в 270 мс; переезд машины переставляет сам счёт. ## Как латентность превращается в проскальзывание Латентность стоит денег через один механизм: рынок продолжает двигаться, пока ваш ордер летит. Вы приняли решение по цене X — а к моменту, когда движок увидел ордер, спустя половину вашего круга, у стакана было 135 мс (из Европы), чтобы измениться. В спокойном рынке это обычно ничто. В волатильную минуту, когда цены ходят на десятые доли процента в секунду, 270 мс полёта надёжно превращаются в исполнение хуже той цены, по которой вы кликали, — эта разница и есть проскальзывание, и растёт она с вашим расстоянием до Токио. Свою цифру можно измерить, не веря чужим графикам: проведите тест проскальзывания на пробном ордере. Зафиксируйте лучшую цену, которую видите в момент решения, отправьте маленький лимитный ордер по рынку и сравните с ценой исполнения в ответе — поле `transactTime` даже скажет, когда движок сработал. Повторите несколько десятков раз в разных состояниях рынка — и у вас есть личный латентный налог в базисных пунктах, измеренный на ваших деньгах и из вашей локации. Именно эта цифра решает, стоит ли вам гнаться за низколатентным доступом к API. Если вы торгуете активно — маркет-мейкинг, охота за ликвидациями, арбитраж, — ответ обычно «да»: точка выхода рядом с ap-northeast-1 может существенно снизить этот налог. Если вы собираете данные, а не гоняетесь со стаканом, ответ обычно «нет»: как мы показывали в [статье о лимитах Binance API](/ru/blog/binance-api-rate-limits.php), пропускная способность решается параллельностью по адресам, а не близостью. Это географическое разделение прямо ложится на то, как используют наши [прокси для Binance](/target/binance-proxy-server/): японские адреса — для ордерного пути, где каждая миллисекунда круга оценена в проскальзывании, и пакеты по другим регионам — для пути данных, где бюджеты и параллельность важнее расстояния. В обоих случаях — выделенные IPv4, статичные на весь срок плана, с доступом по IP whitelisting.