Confronto tra applicazioni TCP / IP e applicazioni HTTP [chiuso]

12

Sono interessato allo sviluppo di un sito Web su larga scala per utenti che sia scritto in Java.

Per quanto riguarda il design, sto pensando di sviluppare servizi indipendenti e modulari che possano fungere da fornitori di dati alla mia applicazione web principale.

Per quanto riguarda la scrittura di questi servizi modulari (fornitori di dati), posso sfruttare un framework esistente come Spring e sviluppare questi servizi seguendo il modello di progettazione RESTful ed esporre le risorse via HTTP con un formato di messaggio come JSON ... o posso sfruttare un framework di rete esistente come Netty ( link ) e un formato di serializzazione come Protobufs ( link ) e sviluppare un server TCP che manda avanti e indietro il payload protobuf serializzato.

Quando dovresti sceglierne uno rispetto all'altro? Ci sarebbe qualche vantaggio nell'usare un formato di serializzazione come Protobufs e l'invio di stream di byte sul filo? Ci sarebbe un sovraccarico nell'uso di JSON? Quanto overhead c'è tra l'utilizzo di TCP / IP e l'utilizzo di HTTP? Quando dovresti usare Spring su Netty e viceversa per costruire un servizio simile?

    
posta HiChews123 12.10.2013 - 13:26
fonte

2 risposte

21

Ci sono sicuramente pro / contro sull'uso di JSON su REST rispetto a quello su TCP / IP con protocollo binario e penso che tu stia già sospettando che il protocollo binario sarà più veloce. Non posso dirvi esattamente quanto più veloce (e questo dipenderebbe da molti fattori), ma suppongo che forse 1-2 ordini di grandezza.

A prima vista se qualcosa è 10-100 volte più lento di qualcos'altro, potresti avere una reazione istintiva e andare per "cosa veloce". Tuttavia, questa differenza di velocità è solo nel protocollo stesso. Se c'è accesso al database / file sul lato server, questo non sarà influenzato dalla scelta del livello di trasferimento. In alcuni casi, potrebbe rendere la tua velocità di trasferimento molto meno significativa.

HTTP REST e JSON sono validi per una serie di motivi:

  • sono facilmente consumabili da chiunque. Puoi scrivere la tua app Web, quindi tornare indietro e pubblicare la tua API per il resto del mondo da utilizzare. Ora chiunque può raggiungere gli stessi end-point e accedere ai tuoi servizi
  • sono facilmente debuggabili, è possibile aprire uno sniffer di pacchetti o semplicemente scaricare le richieste in arrivo in file di testo e vedere cosa sta succedendo. Non puoi farlo con i protocolli binari
  • sono facilmente estensibili. Puoi aggiungere più attributi e dati in un secondo momento e non rompere la compatibilità con i vecchi client.
  • consumabile dai client javascript (non sono sicuro che abbiano ancora un parser JS protobuf, non credo che ce ne sia uno)

Protobuf su TCP / IP:

  • sono più veloci

Se fosse la mia scelta, mi piacerebbe andare giù con HTTP REST e JSON. C'è una ragione per cui così tante altre società e siti web hanno seguito questa strada. Inoltre, tieni presente che in futuro potresti sempre supportare 2 punti finali. Se il progetto è corretto, la scelta del punto finale dovrebbe essere completamente disaccoppiata dalla logica aziendale sul server o dal database. Quindi se ti rendi conto in seguito che hai bisogno di più velocità per tutte / alcune richieste, dovresti essere in grado di aggiungere protobufs con il minimo sforzo. Tuttavia, REST / JSON ti farà partire più velocemente e ti spingerà oltre.

Per quanto riguarda Netty vs Spring. Non ho usato Netty direttamente, ma credo che sia solo un server web leggero dove Spring è un framework che fornisce molto di più per te rispetto a quello. Ha livelli di accesso ai dati, pianificazione dei lavori in background e (penso) un modello MVC, quindi è molto più pesante. Quale scegliere? Se hai deciso di andare via HTTP, la prossima domanda è probabilmente come è standard la tua app? Se stai per scrivere una logica pazza personalizzata che non si adatta allo stampo standard e tutto ciò di cui hai bisogno è solo un livello server HTTP, vai con Netty.

Tuttavia, sospetto che l'app non sia così speciale e che probabilmente potrebbe beneficiare di molte cose che Spring ha da offrire. Ciò significa che dovresti strutturare la tua app intorno al framework di Spring e fare le cose nel modo in cui si aspettano che tu faccia, il che significherebbe imparare di più su Spring prima di immergerti nel tuo prodotto. I framework in generale sono grandiosi perché di nuovo ti fanno decollare più velocemente, ma il rovescio della medaglia è che devi inserirli nello stampo invece di fare il tuo design e quindi aspettarti che il framework funzioni.

(*) - in passato è stato sottolineato che i miei post non riflettono le opinioni di tutto il mondo, quindi vado sul disco e aggiungo solo che ho un'esperienza limitata con Netty (ho usato Play framework prima di cui è basato su Netty) o Spring (ne ho solo letto). Quindi prendi quello che dico con un pizzico di sale.

    
risposta data 12.10.2013 - 17:26
fonte
0

Questa è effettivamente una non domanda. Secondo la suite di protocolli Internet tcp è un protocollo nel livello di trasporto e http è un protocollo nel livello dell'applicazione. Stai confrontando cose completamente diverse tra loro. (Vedi di più qui: link )

In effetti, la maggior parte degli http è su tcp / ip. Quindi per rispondere alla tua domanda, sì, dovresti usare tcp / ip. Quindi si desidera aggiungere un protocollo a livello di applicazione (come http) e quindi un formato dati (come json, xml, html). Netty ti permette di usare http e protobuff è uguale a json, xml, html.

Tutto dipende da quali sono i tuoi requisiti e da quale tipo di dati dovrai trasportare. Avete bisogno di sessioni nel vostro protocoll, una stretta di mano può migliorare la configurazione del protocollo, quanti dati verranno inviati in una volta, avete bisogno di crittografia? Queste sono le domande a cui devi rispondere quando scegli un protocollo applicativo.

Per scegliere un formato di rappresentazione dei dati (json, xml, html, protobuff, ecc.) dipende dalla larghezza di banda, dalla leggibilità, dalla lingua / supporto degli strumenti ecc.

Non puoi confrontare http a tcp.

Ricorda che la velocità non è tutto. La velocità è inutile se non riesci ad esprimerti in modo sensato.

    
risposta data 12.10.2013 - 16:29
fonte

Leggi altre domande sui tag