WebpushEdit

La proposta Webpush della Internet Engineering Task Force è un semplice protocollo che utilizza HTTP versione 2 per fornire eventi in tempo reale, come chiamate o messaggi in arrivo, che possono essere consegnati (o “spinti”) in modo tempestivo. Il protocollo consolida tutti gli eventi in tempo reale in un’unica sessione che garantisce un uso più efficiente delle risorse di rete e radio. Un singolo servizio consolida tutti gli eventi, distribuendo tali eventi alle applicazioni non appena arrivano. Ciò richiede solo una sessione, evitando costi generali duplicati.,

Le notifiche Web fanno parte dello standard W3C e definiscono un’API per le notifiche degli utenti finali. Una notifica consente di avvisare l’utente al di fuori del contesto di una pagina Web di un evento, come la consegna di e-mail. Come parte di questa API Push standard definita da W3C, è ora in fase di implementazione da Chrome, Firefox, Edge e Safari.

HTTP server pushEdit

HTTP server push (noto anche come HTTP streaming) è un meccanismo per l’invio di dati non richiesti (asincroni) da un server Web a un browser Web. HTTP server push può essere raggiunto attraverso uno qualsiasi dei diversi meccanismi.,

Come parte di HTML5 l’API WebSocket consente a un server Web e client di comunicare tramite una connessione TCP full-duplex.

Generalmente il server Web non termina una connessione dopo che i dati di risposta sono stati inviati a un client. Il server Web lascia aperta la connessione in modo che se si verifica un evento (ad esempio, una modifica dei dati interni che deve essere segnalata a uno o più client), possa essere inviato immediatamente; in caso contrario, l’evento dovrebbe essere messo in coda fino a quando non viene ricevuta la richiesta successiva del client. La maggior parte dei server web offre questa funzionalità tramite CGI (ad es.,, Script di intestazioni non analizzate sul server HTTP Apache). Il meccanismo sottostante per questo approccio è la codifica di trasferimento chunked.

Un altro meccanismo è legato ad un tipo MIME speciale chiamato multipart/x-mixed-replace, che è stato introdotto da Netscape nel 1995. I browser Web lo interpretano come un documento che cambia ogni volta che il server invia una nuova versione al client. È ancora supportato da Firefox, Opera e Safari oggi, ma viene ignorato da Internet Explorer ed è solo parzialmente supportato da Google Chrome., Può essere applicato a documenti HTML e anche per lo streaming di immagini in applicazioni webcam.

La proposta WHATWG Web Applications 1.0 include un meccanismo per inviare contenuti al client. Il 1º settembre 2006, il browser web Opera implementò questo nuovo sistema sperimentale in una funzionalità chiamata “Server-Sent Events”. Ora è in fase di standardizzazione come parte di HTML5.

PushletEdit

In questa tecnica, il server sfrutta le connessioni HTTP persistenti, lasciando la risposta perennemente “aperta” (cioè,, il server non termina mai la risposta), ingannando efficacemente il browser per rimanere in modalità “caricamento” dopo che il caricamento iniziale della pagina potrebbe essere considerato completo. Il server invia quindi periodicamente frammenti di JavaScript per aggiornare il contenuto della pagina, ottenendo così la capacità di push. Utilizzando questa tecnica, il client non ha bisogno di applet Java o altri plug-in per mantenere una connessione aperta al server; il client viene automaticamente notificato sui nuovi eventi, spinto dal server., Un grave inconveniente di questo metodo, tuttavia, è la mancanza di controllo del server sul timeout del browser; un aggiornamento della pagina è sempre necessario se si verifica un timeout alla fine del browser.

Long polling

Il long polling non è di per sé un vero push; il long polling è una variante della tecnica di polling tradizionale, ma consente di emulare un meccanismo push in circostanze in cui non è possibile un vero push, come i siti con policy di sicurezza che richiedono il rifiuto delle richieste HTTP / S in arrivo.,

Con il polling lungo, il client richiede informazioni dal server esattamente come nel normale polling, ma con l’aspettativa il server potrebbe non rispondere immediatamente. Se il server non ha nuove informazioni per il client quando viene ricevuto il sondaggio, invece di inviare una risposta vuota, il server tiene aperta la richiesta e attende che le informazioni sulla risposta diventino disponibili. Una volta che ha nuove informazioni, il server invia immediatamente una risposta HTTP/S al client, completando la richiesta HTTP/S aperta., Al ricevimento della risposta del server, il client spesso emette immediatamente un’altra richiesta del server. In questo modo viene eliminata la latenza di risposta usuale (il tempo che intercorre tra quando le informazioni diventano disponibili per la prima volta alla successiva richiesta del client) altrimenti associata ai client di polling.

Ad esempio, BOSH è una tecnica HTTP popolare e longeva utilizzata come alternativa di polling lungo a una connessione TCP continua quando tale connessione è difficile o impossibile da utilizzare direttamente (ad esempio,, in un browser web); è anche una tecnologia sottostante nel XMPP, che Apple utilizza per il suo supporto push iCloud.

Flash XMLSocket relaysEdit

Questa tecnica, utilizzata dalle applicazioni di chat, fa uso dell’oggetto XMLSocket in un filmato Adobe Flash a pixel singolo. Sotto il controllo di JavaScript, il client stabilisce una connessione TCP a un relè unidirezionale sul server. Il server relay non legge nulla da questo socket; invece invia immediatamente al client un identificatore univoco. Successivamente, il client effettua una richiesta HTTP al server Web, incluso con esso questo identificatore., L’applicazione Web può quindi inviare messaggi indirizzati al client a un’interfaccia locale del server relay, che li inoltra sul socket Flash. Il vantaggio di questo approccio è che apprezza la naturale asimmetria lettura-scrittura tipica di molte applicazioni web, inclusa la chat, e di conseguenza offre un’elevata efficienza. Poiché non accetta dati sui socket in uscita, il server relay non ha bisogno di eseguire il polling delle connessioni TCP in uscita, rendendo possibile tenere aperte decine di migliaia di connessioni simultanee., In questo modello, il limite alla scala è lo stack TCP del sistema operativo server sottostante.

Affidabile Group Data Delivery (RGDD)Modifica

In servizi come il Cloud Computing, per aumentare l’affidabilità e la disponibilità dei dati, di solito è spinto (replicato) a più macchine. Ad esempio, Hadoop Distributed File System (HDFS) crea 2 copie aggiuntive di qualsiasi oggetto memorizzato. RGDD si concentra sul lancio efficiente di un oggetto da una posizione a molti, risparmiando la larghezza di banda inviando un numero minimo di copie (solo una nel migliore dei casi) dell’oggetto su qualsiasi collegamento attraverso la rete., Ad esempio, Datacast è uno schema per la consegna a molti nodi all’interno di datacenter che si basa su topologie regolari e strutturate e DCCast è un approccio simile per la consegna tra datacenter.

Push notificationEdit

Una notifica push è un messaggio che viene “spinto” dal server backend o dall’applicazione all’interfaccia utente, ad esempio (ma non limitato a) applicazioni mobili e applicazioni desktop. Le notifiche push sono stati introdotti da Apple nel 2009.In 2010 Google ha rilasciato il proprio servizio, Google Cloud to Device Messaging., (Da allora è stato sostituito da Google Cloud Messaging e poi Firebase Cloud Messaging.) Novembre 2015, Microsoft ha annunciato che il servizio di notifica di Windows sarebbe stato ampliato per utilizzare l’architettura della piattaforma Windows universale, consentendo l’invio di dati push a Windows 10, Windows 10 Mobile, Xbox e altre piattaforme supportate utilizzando chiamate API universali e richieste POST.

Le notifiche push sono principalmente suddivise in 2 approcci, notifiche locali e notifiche remote., Per le notifiche locali, l’applicazione pianifica la notifica con il sistema operativo del dispositivo locale o, in alternativa, imposta come timer nell’applicazione stessa se è in grado di eseguire continuamente in background. Quando viene raggiunta l’ora pianificata dell’evento o viene soddisfatta la condizione programmata dell’evento, il messaggio viene visualizzato nell’interfaccia utente dell’applicazione.

Le notifiche remote sono gestite da un server remoto. In questo scenario, l’applicazione client deve essere registrata sul server con una chiave univoca (ad esempio, un UUID)., Il server quindi attiva il messaggio contro la chiave univoca per consegnare il messaggio all’applicazione client tramite un protocollo client/server concordato come HTTP o XMPP e il client visualizza il messaggio ricevuto. Quando arriva la notifica push, può trasmettere brevi notifiche e messaggi, impostare badge sulle icone delle applicazioni, lampeggiare o accendere continuamente il LED di notifica o riprodurre suoni di avviso per attirare l’attenzione dell’utente. Le notifiche push vengono solitamente utilizzate dalle applicazioni per portare informazioni all’attenzione degli utenti., Il contenuto dei messaggi può essere classificato nelle seguenti categorie di esempio:

  • Messaggi di chat, ad esempio: messaggi da Facebook messenger inviati da altri utenti.
  • Offerte speciali del fornitore, ad esempio: un fornitore potrebbe voler pubblicizzare le proprie offerte social ai clienti.
  • Promemoria eventi, ad esempio: Alcune applicazioni possono consentire al cliente di creare promemoria o avviso per un tempo specifico.
  • Argomenti sottoscritti modifiche, ad esempio: Gli utenti potrebbero voler ottenere aggiornamenti per quanto riguarda il tempo nella loro posizione, o monitorare una pagina web per tenere traccia dei cambiamenti, per esempio.,

Le notifiche push in tempo reale possono sollevare problemi di privacy poiché possono essere utilizzate per associare identità virtuali di pseudonimi di social network alle identità reali dei proprietari di smartphone.