Технологія Direct Push використовує Exchange ActiveSync для синхронізації даних у пристрої під управлінням Windows Mobile з даними на сервері Microsoft Exchange Server. Використовувати SMS для повідомлень більше не потрібно.
Технологія Direct Push
Пристрій під керуванням Windows Mobile 6. Технологія ActiveSync в пристрої управляє зв'язком Direct Push з сервером Exchange Server. Вона встановлює підключення до сервера (по протоколу HTTP або HTTPS) на певний час, потім переходить в сплячий режим в очікуванні відповіді сервера. Сервер відповідає, що або отримані нові елементи, яких нових елементів немає. Після цього пристрій відправляє або запит на синхронізацію, або ще один запит Direct Push. Частота запитів динамічно змінюється на основі параметрів, зазначених виробником пристрою або оператором мобільного зв'язку, а також на основі граничного значення бездіяльності підключення HTTP або HTTPS в мережі оператора і в корпоративній мережі користувача.
При зміні даних на сервері зміни передаються на мобільний пристрій за допомогою підключення по протоколу HTTP або HTTPS, що використовується для Direct Push. Значення часу очікування оператора мобільної мережі визначає, наскільки довго можна зберігати підключення в режимі бездіяльності.
Щоб термін дії підключення виявилася закінчувався в очікуванні оновлень, пристрій передає запит у відповідях сервера. Ця періодична передача називається підтвердженням з'єднання. Завдяки підтвердження підключення до сервера для DirectPush зберігається; кожне підтвердження оповіщає сервер про те, що пристрій готовий до отримання даних.
Процес Direct Push
Процес DirectPush складається з наступних етапів.
Клієнт відправляє HTTP-повідомлення, відоме як запит перевірки зв'язку, на сервер Exchange Server, запитуючи у сервера відповідь про те, чи відбулися якісь зміни в поштовій скриньці сервера за певний час. У запиті перевірки зв'язку клієнт вказує папки, в яких потрібно відстежувати зміни. Зазвичай це папка вхідних повідомлень, календар, контакти та завдання.
Коли сервер Exchange Server отримує цей запит, він перевіряє зазначені папки до виникнення одного з наступних подій:
Закінчується строк очікування. Термін очікування визначається за часом найкоротшою затримки в мережевому шляху. У цьому випадку сервер Exchange Server передає клієнту відповідь «HTTP 200 OK».
Клієнт відповідає на відповідь сервера Exchange Server одним із таких способів:
При отриманні відповіді «HTTP 200 OK», що означає відсутність змін, повторно відправляється запит перевірки зв'язку.
При отриманні відповіді, відмінного від «HTTP 200 OK», клієнт відправляє запит на синхронізацію папки, яка змінилася. Після завершення синхронізації клієнт заново відправляє запит перевірки зв'язку.
Якщо протягом зазначеного часу клієнт не отримує відповідь від сервера Exchange Server, він зменшує інтервал часу в запиті перевірки зв'язку та заново відправляє цей запит.
Налаштування Direct Push
В процесі Direct Push пристрій очікує закінчення обміну запитами та відповідями перед спробою зміни часу, протягом якого потрібно підтримувати підключення до сервера. Час, протягом якого сервер очікує змін або прибуття нової пошти перед відправленням клієнту відповіді «OK», називається інтервалом підтвердження.
Тривалість інтервалу підтвердження визначається клієнтом і відправляється разом із запитом перевірки зв'язку. Спочатку використовується тривалість інтервалу підтвердження за замовчуванням. Потім алгоритм Direct Push на стороні клієнта динамічно змінює інтервал підтвердження таким чином, щоб час між підтвердженнями було найбільшим, але не перевищувало граничний час очікування. Зміна залежить від стану мережі і від допустимої тривалості недіючого підключення HTTP або HTTPS в мережі оператора мобільного зв'язку або в мережі компанії, а також залежить від деяких параметрів, що встановлюються оператором мобільного зв'язку.
Для визначення оптимального інтервалу підтвердження використовується журнал запитів перевірки зв'язку. Якщо на запит перевірки зв'язку приходить відповідь, інтервал підтвердження збільшується. Якщо в кінці інтервалу відповідь не надходить, це означає, що час очікування минув, і клієнт знижує тривалість інтервалу.
За допомогою цього алгоритму клієнт визначає найбільшу тривалість недіючого підключення, можливу в бездротової мережі з брандмауером підприємства.
На наступному малюнку показано зміна інтервалу підтверджень при типовому обміні даними Direct Push між клієнтом і сервером Exchange Server.
Буквою «Т» на малюнку позначений хід часу.
Обмін даними відбувається наступним чином. Числа відповідають числам на малюнку.
Клієнт пробуджується і відправляє HTTP-запит серверу Exchange Server через Інтернет, потім переходить до режиму сну.
У запиті вказується інтервал підтвердження, тобто час, протягом якого сервер очікує змін або прибуття нової пошти перед відправленням клієнту відповіді «OK». На цьому малюнку інтервал підтвердження дорівнює 15 хвилинам.
Оскільки за інтервал підтвердження не надійшло нових повідомлень, сервер повертає відповідь «HTTP 200 OK».
В даному прикладі відповідь загублений, оскільки або мережу оператора, або мережу підприємства не підтримує довгострокові HTTP-підключення; клієнт не отримує відповідь.
Клієнт пробуджується через час, рівне інтервалу підтвердження плюс одна хвилина (15 + 1 = всього 16 хвилин).
Пристрій чекає успішного отримання відповіді перед зміною інтервалу підтвердження. За допомогою засобу налаштування алгоритму можна змінити кількість часу, на яке буде змінюватися інтервал підтвердження за один раз.
Якщо при обміні сигналами відповіді від сервера не надійшла, клієнт відправляє запит з більш коротким інтервалом підтвердження (8 хвилин).
В даному прикладі інтервал підтвердження не було збільшено при останньому запиті перевірки зв'язку, тому використовується найменша тривалість інтервалу підтвердження (8 хвилин).
Оскільки за інтервал підтвердження не надійшло нових повідомлень, сервер повертає відповідь «HTTP 200 OK».
Відповідь сервера пробуджує клієнт. Оскільки час очікування підключення не минуло протягом інтервалу підтвердження, клієнт визначає, що мережа підтримує недіючі підключення протягом принаймні цього часу.
Якщо це був повторний обмін сигналами, клієнт визначає, що в наступному запиті інтервал підтвердження можна збільшити.
Вплив Direct Push на мережу і сервери Exchange Server
Алгоритм, який встановлює інтервал підтвердження, знижує обсяг трафіку і сприяє більш економного споживання електрики.
Використання стиснення даних дозволить зменшити розмір пакетів, що пересилаються між сервером Exchange Server (з роллю сервера клієнтського доступу) і клієнтом. Однак споживаний трафік і вплив на швидкість даних користувача в великій мірі залежить від наступних факторів:
Для яких об'єктів буде синхронізуватися (наприклад, не тільки папки за замовчуванням, але і додаткові папки).
Який обсяг даних був змінений в поштовій скриньці і мобільному пристрої.
Вплив зміни параметрів Direct Push
інтервал підтвердження
Інтервал підтвердження встановлюється в пристрої оператором мобільного зв'язку. Використання інтервалу, рівного 30 хвилинам, дозволяє знизити споживання електроенергії і заощадити трафік. Якщо допускаються тривалі сеанси Direct Push (наприклад довжиною 30 хвилин), то пересилається менше запитів і відповідей HTTP, знижується трафік, а пристрій споживає менше електрики.
Якщо вказати більш короткий проміжок часу підтвердження, користувач зможе частіше отримувати оновлення, але при цьому через постійні опитувань сервера будуть швидше витрачатися батареї мобільного пристрою.
Найменший інтервал підтвердження
Якщо інтервал підтвердження пристрою менше мінімального інтервалу, необхідного для підключення до сервера Exchange Server, то сервер записує в журнал подія для оповіщення адміністратора про те, що Direct Push не працює.
сеанс Exchange
Час очікування брандмауера
Час очікування недіючого підключення визначає, скільки часу може існувати підключення без трафіку після установки TCP-підключення.
Встановіть в брандмауері час очікування недіючого підключення.
Компанії повинні встановити у вхідних брандмауерах час очікування, що складає 30 хвилинам.
Веб-сервери, додатки мережевої безпеки і системні мережеві стеки мають кілька порогових значень часу, які служать для захисту від недостатньо добре протестованих або зловмисних клієнтів. Можна безпечно збільшити час очікування, не піддаючи мережу небезпеки.
Збільшення часу очікування підключення зазвичай не впливає на вразливість до атак. У наступній таблиці наведені приклади атак і описано, як зміна інших параметрів допомагає боротися з ними.
Атака типу «відмова в обслуговуванні» (DoS)
Усунення уразливості до атак
Атака типу «відмова в обслуговуванні» полягає в тому, що сторонні комп'ютери не виконують підтвердження, необхідне для створення TCP-підключення. Атакуючий намагається створити велику кількість частково відкритих TCP-підключень.
Збільшення часу простою підключення не допоможе відобразити такі атаки.
Час, протягом якого має бути виконано підтвердження TCP, є окремим значенням, яке встановлюється стеком TCP / IP Windows.
Атака типу «відмова в обслуговуванні» спрямовується проти IIS; при цьому відкривається велика кількість TCP-підключень, але ні по одному з них не передаються HTTP-запити.
Збільшення часу простою підключення не допоможе відобразити такі атаки.
Для боротьби з такими атаками IIS вимагає, щоб клієнт відправив повний HTTP-запит протягом певного часу, а якщо цього не відбувається, підключення розривається. Ім'я параметра часу очікування підключення в консолі управління IIS може бути невірно зрозуміле; TCP-підключення закриваються при перевищенні часу очікування підключення (за замовчуванням воно дорівнює 120 секундам).
Атакуючий встановлює велике число TCP-підключень, відправляє по всіх підключень HTTP-запити, але не приймає відповіді.
Збільшення часу простою підключення не допоможе відобразити такі атаки.
У цьому випадку використовується такий же спосіб захисту, як і в попередньому сценарії. Час очікування підключення в IIS визначає час, протягом якого клієнт повинен або відправити перший запит після установки TCP-підключення, який наступний запит в сценарії підтримки HTTP-підключення.
Застосовується тільки до прослуховування Exchange ActiveSync.