Direct Push utilizează Exchange ActiveSync pentru sincronizarea datelor pe un dispozitiv Windows Mobile cu date pe un server Microsoft Exchange. Utilizarea SMS-ului pentru notificări nu mai este necesară.
Tehnologie Direct Push
Dispozitivul rulează Windows Mobile 6. Tehnologia ActiveSync din dispozitiv gestionează comunicarea Direct Push cu serverul Exchange. Acesta stabilește o conexiune la server (prin intermediul protocolului HTTP sau HTTPS) pentru o anumită perioadă de timp, apoi intră în hibernare, așteptând ca serverul să răspundă. Serverul răspunde că sunt primite elemente noi sau nu există elemente noi. După aceasta, dispozitivul trimite fie o solicitare de sincronizare, fie o altă solicitare Direct Push. Frecvența cererilor este modificată dinamic în funcție de parametrii specificați de producătorul dispozitivului sau de operatorul de telefonie mobilă și, de asemenea, pe baza valorii limită a inactivității conexiunii HTTP sau HTTPS în rețeaua operatorului și în rețeaua corporativă a utilizatorului.
Când modificați datele de pe server, modificările sunt transferate pe dispozitivul mobil printr-o conexiune HTTP sau HTTPS utilizată pentru Direct Push. Valoarea de expirare a operatorului de rețea mobil determină cât timp puteți păstra conexiunea în modul inactiv.
Pentru a vă asigura că conexiunea nu expiră în așteptarea actualizărilor, dispozitivul trimite o solicitare atunci când serverul răspunde. Acest transfer periodic se numește o confirmare a conexiunii. Datorită confirmării, conexiunea la server pentru DirectPush este păstrată; fiecare confirmare notifică serverului că dispozitivul este pregătit să primească date.
Procesul Direct Push
Procesul DirectPush constă în următorii pași.
Clientul trimite un mesaj HTTP, cunoscut ca o solicitare de testare a conexiunii, la serverul Exchange, solicitând un răspuns de la server dacă au existat modificări la cutia poștală a serverului într-o anumită perioadă de timp. În cererea de validare a conexiunii, clientul specifică dosarele în care doriți să urmăriți modificările. De obicei, acesta este dosarul mesajelor, calendarului, contactelor și sarcinilor primite.
Când serverul Exchange primește această solicitare, verifică dosarele specificate înainte de apariția unuia dintre următoarele evenimente:
Termenul expiră. Timpul de așteptare este determinat de momentul celei mai scurte întârzieri în calea rețelei. În acest caz, serverul Exchange trimite clientului un răspuns "HTTP 200 OK".
Clientul răspunde la răspunsul Exchange Server într-unul din următoarele moduri:
Când se recepționează un răspuns "HTTP 200 OK", ceea ce înseamnă că nu există modificări, este trimis din nou o solicitare de verificare a conexiunii.
Dacă primiți un alt răspuns decât "HTTP 200 OK", clientul trimite o solicitare de sincronizare a dosarului care sa schimbat. Când sincronizarea este completă, clientul trimite din nou cererea de verificare a conexiunii.
Dacă clientul nu primește un răspuns de la serverul Exchange în intervalul de timp specificat, acesta scade intervalul de timp din solicitarea de verificare a comunicării și trimite din nou solicitarea.
Configurarea Direct Push
În procesul Direct Push, dispozitivul așteaptă ca schimbul de cereri și răspunsuri să fie finalizat înainte de a încerca să schimbe timpul în care trebuie să mențină o conexiune la server. Timpul în care serverul așteaptă modificări sau sosirea unui mesaj nou înainte de trimiterea răspunsului OK clientului se numește intervalul de confirmare.
Lungimea intervalului de confirmare este determinată de client și trimisă împreună cu cererea de verificare a comunicării. Mai întâi, se utilizează intervalul de confirmare implicit. Apoi, algoritmul Direct Push pe partea clientului modifică în mod dinamic intervalul de confirmare, astfel încât timpul dintre confirmări este cel mai mare, dar nu depășește timpul de așteptare pentru latență. Schimbarea depinde de starea rețelei și de durata permisă a conexiunii HTTP sau HTTPS latente în rețeaua operatorului de telefonie mobilă sau în rețeaua companiei și, de asemenea, depinde de anumiți parametri stabiliți de operatorul de telefonie mobilă.
Pentru a determina intervalul de validare optim, se utilizează jurnalul de solicitare a verificării comunicației. Dacă apare un răspuns la solicitarea de verificare a conexiunii, intervalul de confirmare este mărit. Dacă nu există un răspuns la sfârșitul intervalului, aceasta înseamnă că perioada de expirare a expirat, iar clientul reduce durata intervalului.
Cu acest algoritm, clientul determină durata maximă a conexiunii latente posibilă în rețeaua fără fir cu firewall-ul întreprinderii.
Figura următoare arată schimbarea intervalului de confirmare pentru o comunicație tipică Push între client și serverul Exchange.
Litera "T" din figură indică cursul timpului.
Schimbul de date are loc după cum urmează. Numerele corespund numerelor din imagine.
Clientul se trezește și trimite o cerere HTTP către serverul Exchange prin Internet, apoi trece în modul de repaus.
Cererea specifică intervalul de confirmare, adică momentul în care serverul așteaptă modificări sau sosirea unui mesaj nou înainte de a trimite un răspuns "OK" la client. În această figură, intervalul de confirmare este de 15 minute.
Deoarece nu au fost primite mesaje noi în intervalul de confirmare, serverul returnează răspunsul "HTTP 200 OK".
În acest exemplu, răspunsul este pierdut, deoarece fie rețeaua operatorului, fie rețeaua întreprinderii nu acceptă conexiuni HTTP pe termen lung; clientul nu primește un răspuns.
Clientul se trezește la o perioadă egală cu intervalul de confirmare plus un minut (15 + 1 = 16 minute în total).
Aparatul așteaptă să primească un răspuns cu succes înainte de a schimba intervalul de confirmare. Utilizând instrumentul de configurare a algoritmilor, puteți schimba intervalul de timp în care se va schimba intervalul de confirmare la un moment dat.
Dacă serverul nu răspunde, clientul trimite o solicitare cu un interval de confirmare mai scurt (8 minute).
În acest exemplu, intervalul de confirmare nu a fost majorat la ultima solicitare de verificare a comunicării, astfel încât este utilizată cea mai scurtă perioadă de confirmare (8 minute).
Deoarece nu au fost primite mesaje noi în intervalul de confirmare, serverul returnează răspunsul "HTTP 200 OK".
Răspunsul serverului este trezit de client. Deoarece timpul de conectare nu a expirat în timpul intervalului de confirmare, clientul determină că rețeaua acceptă conexiuni în așteptare cel puțin pentru acest moment.
Dacă acesta a fost un schimb de semnale repetat, clientul determină că în următoarea solicitare intervalul de confirmare poate fi mărit.
Impactul aplicării directe pe serverele de rețea și de schimb
Algoritmul care stabilește intervalul de confirmare, reduce cantitatea de trafic și contribuie la un consum mai economic de energie electrică.
Folosirea compresiei de date va reduce dimensiunea pachetelor care sunt trimise între serverul Exchange (cu rolul serverului Access Client) și clientul. Cu toate acestea, traficul consumat și impactul asupra vitezei datelor de utilizator depind într-o mare măsură de următorii factori:
Ce obiecte sunt sincronizate (de exemplu, nu numai folderele implicite, ci și folderele suplimentare).
Cât de mult s-au schimbat datele în cutia poștală și dispozitivul mobil.
Efectul modificărilor parametrilor Direct Push
Interval de confirmare
Intervalul de confirmare este setat în dispozitiv de către operatorul de telefonie mobilă. Folosind un interval egal cu 30 de minute, vă permite să reduceți consumul de energie și să economisiți trafic. Dacă sunt permise sesiuni lungi de împingere directă (de exemplu, 30 de minute), sunt trimise mai puține cereri și răspunsuri HTTP, traficul este redus și aparatul consumă mai puțină energie electrică.
Dacă specificați un interval de confirmare mai scurt, utilizatorul va putea să primească mai des actualizări, dar din cauza sondajelor constante ale serverului, bateriile dispozitivelor mobile vor fi consumate mai repede.
Interval minim de confirmare
Dacă intervalul de confirmare a dispozitivului este mai mic decât intervalul minim necesar pentru conectarea la serverul Exchange, serverul înregistrează un eveniment pentru a anunța administratorul că Direct Push nu funcționează.
Schimb de sesiune
Firewall timeout
Timpul de conectare în așteptare determină durata unei conexiuni fără trafic, după stabilirea conexiunii TCP.
Setați timpul de expirare a conexiunii latente din paravanul de protecție.
Companiile trebuie să instaleze un interval de timp de 30 de minute în firewall-urile primite.
Serverele web, aplicațiile de securitate a rețelei și stivele de rețea din sistem au mai multe praguri de timp care servesc la protejarea împotriva clienților care nu sunt supuși testării sau a celor rău-intenționați. Puteți spori în siguranță timpul de așteptare fără a expune rețeaua la pericol.
Creșterea timpului de conectare de obicei nu afectează vulnerabilitatea la atacuri. Următorul tabel prezintă exemple de atacuri și descrie modul în care schimbarea altor parametri ajută la combaterea acestora.
Deniul-of-serviciu (DoS)
Eliminarea vulnerabilității la atacuri
Atacul de refuz al serviciului este că computerele terță parte nu efectuează confirmarea necesară pentru a crea o conexiune TCP. Atacatorul încearcă să creeze un număr mare de conexiuni TCP parțial deschise.
Cresterea timpului de conectare nu va ajuta sa respinga astfel de atacuri.
Timpul în care trebuie efectuată o confirmare TCP este o valoare separată stabilită de stiva Windows TCP / IP.
Un atac de refuz al serviciului este îndreptat împotriva IIS; Aceasta deschide un număr mare de conexiuni TCP, dar niciunul nu trimite solicitări HTTP.
Cresterea timpului de conectare nu va ajuta sa respinga astfel de atacuri.
Pentru a combate astfel de atacuri, IIS cere ca clientul să trimită o solicitare completă HTTP într-un anumit timp și, dacă acest lucru nu se întâmplă, conexiunea este terminată. Numele opțiunii de expirare a conexiunii din Consola de administrare IIS poate fi greșit înțeles; Conexiunile TCP sunt închise la depășirea timpului de conectare (implicit este de 120 de secunde).
Atacatorul stabilește un număr mare de conexiuni TCP, trimite solicitări HTTP peste toate conexiunile, dar nu acceptă răspunsuri.
Cresterea timpului de conectare nu va ajuta sa respinga astfel de atacuri.
În acest caz, se folosește aceeași protecție, ca în scenariul precedent. Termenul de conectare în IIS specifică momentul în care clientul trebuie fie să trimită prima solicitare după stabilirea conexiunii TCP, fie o solicitare ulterioară în scriptul de suport pentru conexiunea HTTP.
Se aplică numai la ascultarea Exchange ActiveSync.
Articole similare
Trimiteți-le prietenilor: