До всіх статей

Чому «липкі» сесії інколи рвуться: handover у мобільній мережі

2026-02-08
Чому «липкі» сесії інколи рвуться: handover у мобільній мережі

Розбираємо, що таке handover між базовими станціями та чому sticky‑IP/«липка» сесія в мобільній мережі може обірватися без зміни IP.

Коротко про проблему: IP той самий, а сесія «падає»

У мобільних проксі та в мобільному інтернеті часто плутають два різні явища: незмінність IP‑адреси і безперервність з’єднання. Sticky‑IP зазвичай означає, що оператор певний час тримає для вашого пристрою ту саму публічну IP‑адресу (або той самий вихідний NAT‑пул), але це не гарантує, що TCP/QUIC‑з’єднання буде «вічним». У реальних мережах 4G/5G з’єднання може обірватися навіть тоді, коли IP на стороні клієнта/проксі не змінився.

Найчастіша причина — handover (передача абонента між базовими станціями/сотами) та супутні процеси в радіомережі й ядру. Під час handover змінюється радіоканал, ресурси, маршрутизація в user‑plane, інколи — точки термінації тунелів. Це може викликати коротку паузу, втрату пакетів або навіть повний розрив з повторним встановленням радіо/датасесії.

Що таке handover у 4G/5G простими словами

Handover — це процедура, коли телефон/модем переходить з однієї комірки мережі в іншу, щоб зв’язок залишався стабільним під час руху або зміни радіоумов. У LTE (4G) базовою станцією є eNodeB, у 5G — gNodeB. Перехід може бути:

  • внутрішньою зміною всередині одного вузла (наприклад, сектор/частота),
  • між базовими станціями (inter‑eNB / inter‑gNB),
  • між технологіями (4G↔5G, Wi‑Fi↔LTE у голосових сервісах тощо).

У LTE часто згадують X2‑handover та S1‑handover (канали сигналізації/взаємодії між eNodeB та ядром). Суть для користувача одна: мережа переносить ваші радіо‑ресурси та потоки даних у «нову соту». При цьому IP‑адреса часто залишається тією самою, бо IP прив’язаний до PDN‑з’єднання/шлюза в ядрі, а не до конкретної базової станції.

У 5G SA (Standalone) питання «безперервності» ще більше формалізоване: 3GPP описує режими Session and Service Continuity (SSC), які визначають, чи зберігаються параметри прив’язки (зокрема IP) під час мобільності/релокації.

Чому під час handover може «рвати» sticky‑сесію без зміни IP

Коли ви бачите «IP той самий, але з’єднання обірвалося», зазвичай відбувається одне або кілька з наступного:

1) Є пауза/втрата пакетів, а ваш протокол не витримує

Під час handover в LTE/5G можливий короткий user‑plane interruption: поки мережа переносить контекст і перемикає маршрути/тунелі, частина пакетів губиться або приходить із затримкою. Для веб‑браузингу це часто непомітно, а для довгих «липких» підключень (API‑стріми, WebSocket, RDP, нестійкі TCP‑сесії) — критично. Навіть 100–300 мс втрати можуть збігтися з тайм‑аутами, ретрансмітами або політикою балансера на стороні сервера/проксі.

Особливо чутливі сценарії, де поверх TCP працює ще один «клей» (наприклад, TLS‑сесія, HTTP/2‑стріми, довгі keep‑alive з’єднання). Якщо стек вирішує, що з’єднання «мертве», він закриває сокет, хоча IP‑адреса не змінювалася.

2) Змінюється шлях даних у ядрі (path switch), а NAT/тунелі «перекроюються»

У LTE при міжбазовому handover виконується path switch: ядро мережі (MME/SGW/PGW залежно від сценарію) перенаправляє user‑plane у нову eNodeB. Якщо на якомусь етапі виникає затримка, черги або не спрацьовує буферизація/форвардинг, ваш потік може «просісти» настільки, що клієнт/сервер розірве з’єднання.

У мобільних проксі додається ще один шар — ваш проксі‑сервер і його власні тайм‑аути та правила «stickiness». Наприклад, проксі може прив’язувати сесію до пари IP:порт або до TCP‑конекта. Якщо під час handover з боку оператора зміниться NAT‑відображення (порт/таблиця), сервіс може трактувати це як нову сесію навіть при тій самій IP.

3) Відбувається RLF або handover failure і з’єднання відновлюється «з нуля»

Не кожен handover успішний. Якщо сигнал погіршився, з’явилися перешкоди, або абонент швидко «скаче» між двома сотами (ping‑pong), мережа може отримати handover failure або radio link failure (RLF). Тоді пристрій робить відновлення з’єднання через повторну RRC‑процедуру/переустановку контексту. Для ваших застосунків це виглядає як повний розрив — навіть якщо зовнішня IP потім залишилася тією самою.

4) 4G↔5G (NSA/SA) та Dual Connectivity додають «точок зламу»

У 5G NSA (Non‑Standalone) 5G радіо часто «підвішене» до LTE як до опорної мережі, тому деякі мобільні сценарії включають одразу дві зміни: LTE‑handover + зміна NR‑контексту. Це може збільшувати interruption time. У 5G SA мобільність простіша в частині радіо‑змін, але залишається питання SSC‑режимів та релокації user‑plane.

5) «Липка сесія» в проксі прив’язана не до IP, а до конекта/часу

У багатьох проксі sticky‑логіка реалізована як «тримати один вихідний маршрут/модем для користувача» або «не міняти upstream‑IP N хвилин». Але якщо TCP‑конект обірвався, проксі може створити новий upstream‑конект, і правила stickiness можуть застосуватися інакше (інший порт, інша внутрішня маршрутизація, інший балансер). Тому правильніше мислити так:

  • sticky‑IP — про адресацію/прив’язку в ядрі та NAT,
  • sticky‑session — про безперервність конкретного транспорту/потоку.

Як зрозуміти, що розрив викликаний саме handover

Ознаки, що «винен» handover, а не примусова зміна IP або перезапуск модема:

  • IP до/після розриву однакова, але в логах бачите timeout, RST або повторні reconnect.
  • Короткий «провал» ping/packet loss (1–3 секунди) саме в момент розриву.
  • Зміна параметрів радіо: Cell ID / PCI / eNB ID / TAC, зміна частотного діапазону, стрибок RSRP/RSRQ/SINR.
  • Відсутність повного «діалапа» заново (немає довгої паузи 10–30 с), але конекти перериваються.

Практичний тест: паралельно тримайте довгий TCP‑конект (наприклад, WebSocket) і простий ICMP ping на стабільну адресу. Якщо ping має короткий провал саме в момент розриву конекта — це типова картина interruption під час handover.

Що робити провайдеру мобільних проксі, щоб sticky працював на практиці

1) Налаштувати «живучість» з’єднань

  • Увімкнути TCP keepalive на проксі‑сервері й у клієнтів (коротший інтервал, але без фанатизму).
  • Планувати, що під час handover можливий короткий packet loss, і збільшити тайм‑аути на рівні балансера/проксі (idle timeout, upstream timeout).
  • Для WebSocket/HTTP‑стрімів — додати heartbeat/ping‑фрейми, щоб NAT‑таблиці не «засинали».

2) Не прив’язувати stickiness лише до TCP‑конекта

Якщо sticky‑сесія критично важлива, краще прив’язувати користувача до конкретного модема/каналу на рівні маршрутизації, а не лише до TCP‑конекта. Тоді при розриві клієнт перепідключиться й отримає той самий upstream‑маршрут, навіть якщо старий сокет помер.

3) Зробити reconnect «безболісним» для клієнта

  • Підтримати «липкість» через токени/логін, а не через адресу/порт.
  • Для HTTP — закладати повтори запитів з ідемпотентністю (GET/PUT з ключем) і коректною обробкою 502/504.
  • Для парсерів — писати клієнтську логіку так, щоб короткий розрив не ламав процес (ретраї з backoff, збереження прогресу).

4) Моніторити мобільність та RLF на рівні модемів

У провайдера є перевага: він бачить телеметрію модемів (RSSI/RSRP/RSRQ/SINR, Cell ID, частоти, CA). Корисно зберігати ці дані разом з логами розривів, щоб відрізняти:

  • handover interruption,
  • RLF/handover failure,
  • реальний detach/attach або перереєстрацію,
  • зміну NAT‑пулу / CGNAT‑подію.

Що може зробити користувач (арбітаж/парсинг/QA), щоб «липкість» була стабільнішою

  • Якщо потрібні довгі сесії — використовуйте протоколи та клієнти з нормальними ретраями (і не ставте агресивні тайм‑аути 1–2 с).
  • Плануйте, що «мобільний інтернет — це радіо»: короткі розриви нормальні навіть без зміни IP.
  • Тримайте keep‑alive (наприклад, легкі запити раз на 20–40 с), щоб NAT‑таблиці не закривалися на простої.
  • Для критичних сценаріїв (довгі стріми, RDP) розгляньте тунель (VPN/WireGuard) з автоматичним відновленням — він не скасує handover, але зробить reconnect прозорішим.

Висновок

Sticky‑IP у мобільній мережі не рівний «вічній» сесії. Handover між базовими станціями може давати короткі переривання, втрату пакетів, зміну маршрутів у ядрі або навіть RLF/невдалий handover — і цього достатньо, щоб TCP/QUIC‑конект обірвався без зміни IP. Рішення — не «шукати магічного оператора», а будувати sticky‑логіку та клієнтське перепідключення так, щоб короткі розриви не ламали роботу.

Міф №1: «Якщо IP не змінився — значить мережа нічого не перемикала»

У стільникових мережах IP‑адреса — це лише «верхівка айсберга». У 4G/5G ваш трафік зазвичай проходить у вигляді інкапсульованих тунелів (user‑plane) між радіодоступом і ядром. Під час мобільності мережа може змінювати, де саме ці тунелі термінуються, як перенаправляються пакети, які буфери/черги використовуються, і як швидко відновлюється передача після перемикання. Саме тому сесія може обірватися «логічно», хоча IP «на виході» лишився тим самим.

Що саме відбувається під час LTE handover (спрощено)

Якщо не занурюватися у весь сигналінг, то типова картина така:

  • Пристрій вимірює сусідні комірки й звітує мережі про якість.
  • Мережа вирішує, що пора переходити, і готує ресурси в «цільовій» соті.
  • Частина контексту переноситься, а пакети можуть тимчасово буферизуватися або форвардитися.
  • Після переходу ядро перемикає маршрут даних (path switch), і трафік іде вже через нову базову станцію.

Навіть коли все спрацювало «як по книжці», на практиці завжди є шанс на коротку паузу: радіо — спільне середовище, де перешкоди, завантаження, швидкість руху та щільність малих сот впливають на стабільність.

Чому sticky‑IP зберігається під час переміщення між сотами

У LTE/5G IP‑адреса зазвичай прив’язана до сесії доступу в ядрі (PDN/PDU session) та до шлюзів/функцій user‑plane. Поки ця сесія не розірвана і не створена заново, мережа може підтримувати ту саму IP‑адресу, навіть якщо ви фізично «переїхали» через багато базових станцій. Тому handover сам по собі не зобов’язаний змінювати IP.

Але збереження IP не означає, що збережеться стан усіх проміжних вузлів: CGNAT‑таблиці, stateful‑фаєрволи, балансери, проксі, серверні ліміти — усі вони мають таймери та правила, які можуть «зірвати» довгий конект при короткому провалі трафіку.

Типові «технічні тригери» розривів при handover

  • TCP RTO/ретрансміти: кілька втрат підряд → експоненційний backoff → застосунок вирішує, що «зависло».
  • Idle timeout у NAT/CGNAT: якщо з’єднання довго мовчить, таблиця може закритися; після handover пакет приходить, але state вже немає.
  • Stateful‑балансери: деякі LB/anti‑bot системи тримають стан по 5‑tuple (src/dst IP/port + протокол). Зміна src‑порту в NAT або реконект → новий стан → інша «сесія».
  • QUIC/HTTP/3: QUIC стійкіший до втрат, але деякі реалізації/середовища (особливо за суворих правил фаєрволів) реагують на зміни шляху та тимчасовий loss специфічно; інколи простіше передбачати реконект.

Чому у мобільних проксі це проявляється частіше, ніж у «звичайного» користувача

У звичайному смартфоні типова активність — короткі HTTP‑запити, де реконект майже непомітний. У мобільних проксі та в задачах арбітражу/парсингу часто є:

  • довгі сесії з антибот‑системами (потрібні стабільні cookie/токени),
  • високочастотні запити з низькими тайм‑аутами,
  • паралельні потоки (20–200 конектів), які під час короткого handover «падають пачкою»,
  • контроль stickiness на рівні проксі (прив’язка до upstream‑каналу), який складно синхронізувати з NAT подіями оператора.

Практичний чек‑лист діагностики (для провайдера і клієнта)

  • 1) Фіксуйте IP та час події. Запишіть публічний IP до/після, а також точний timestamp.
  • 2) Зніміть телеметрію радіо. Cell ID/PCI, RSRP/RSRQ/SINR, бенди, CA/EN‑DC статус.
  • 3) Подивіться на шаблон втрат. Одноразовий короткий loss → схоже на handover; довга «діра» 10–60 с → схоже на detach/attach або збій модема.
  • 4) Перевірте порти. Якщо можете — порівняйте src‑порт до/після (NAT може змінити порт навіть без зміни IP).
  • 5) Визначте точку обриву. Це клієнт закрив сокет? Проксі? Сервер? LB? Логи з обох сторін часто дають відповідь.

Налаштування тайм‑аутів, які найчастіше «рятують» sticky‑сесії

Нижче — не універсальні «магічні числа», а типові напрямки тюнінгу. Конкретні значення залежать від вашої інфраструктури й задачі.

  • TCP keepalive: ввімкнути; інтервал підбирати так, щоб підтримувати NAT state (часто 20–60 с), але не створювати зайве навантаження.
  • Idle timeout у проксі: збільшити для довгих конектів (WebSocket, API‑stream), якщо це безпечно.
  • Upstream connect/read timeout: уникати надто агресивних 1–2 секунд у мобільних сценаріях; handover може «з’їсти» частину цього бюджету.
  • Retry policy: 2–3 швидкі ретраї з backoff часто дають кращий результат, ніж «один шанс».

Коли розрив «без зміни IP» все ж не про handover

Іноді handover — лише збіг у часі. Ось альтернативні причини, які дають таку саму симптоматику:

  • Перезапуск стека даних у модемі (прошивка, перегрів, USB‑живлення, нестабільний хаб).
  • Політики оператора: скидання довгих idle‑сесій, керування перевантаженням, «розумний» CGNAT.
  • Внутрішні правила вашого проксі: ротація процесів, рестарт сервісу, ліміти конектів, health‑checks.
  • Сторонній сервіс: антибот/сервер може закривати довгі підключення за власними правилами.

Міні‑FAQ

Чи можна зробити sticky‑IP «як у дротового провайдера»?
Можна наблизитися, якщо сесія в ядрі тримається довго, але радіомережа все одно буде давати мікро‑перерви. Тому на практиці «стабільність» досягається поєднанням: нормальної якості сигналу + правильних тайм‑аутів + грамотного reconnect.

Чи допомагає фіксація бенду/комірки?
Іноді так: якщо модем постійно «стрибає» між 2–3 сотами або бендами, стабілізація може зменшити кількість handover. Але це компроміс із покриттям і швидкістю, і не завжди доступно/доцільно.

Чому «липка сесія проксі» рветься саме на піках навантаження?
На піках у мережі більше затримок і втрат, а у проксі/серверів — більше черг і жорсткіші ліміти. Коротка пауза, яка вночі непомітна, вдень може вистрілити тайм‑аутом.