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


13

Sono interessato a sviluppare un sito Web rivolto agli utenti su larga scala scritto in Java.

Per quanto riguarda il design, sto pensando di sviluppare servizi modulari indipendenti che possano fungere da fornitori di dati per la 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 risorse via HTTP con un formato di messaggio come JSON ... oppure posso sfruttare una rete esistente framework come Netty ( http://netty.io/ ) e formato di serializzazione come Protobufs ( https://developers.google.com/protocol-buffers/docs/overview ) e sviluppo di un server TCP che invia avanti e indietro il protobuf serializzato carico utile.

Quando dovresti scegliere l'uno rispetto all'altro? Ci sarebbe qualche vantaggio nell'utilizzare un formato di serializzazione come Protobufs e nell'invio di stream di byte via cavo? Ci sarebbe un sovraccarico nell'usare JSON? Quanto sovraccarico c'è tra l'utilizzo di TCP / IP e l'utilizzo di HTTP? Quando dovresti usare Spring over Netty e viceversa per creare un servizio del genere?


Sembra che tu stia pensando più allo stack tecnologico che ai requisiti reali. Come può qualcuno di noi rispondere a questa domanda senza sapere che cosa è necessario fare ? Stai creando un gioco multiplayer che dovrebbe avere una latenza quasi zero? O un'applicazione di social bookmarking in cui la maggior parte dell'accesso avviene già tramite HTTP e potresti memorizzare nella cache i dati per ore alla volta e non ti interessa nemmeno la freschezza, per non parlare della latenza?
Aaronaught,

3
Non credo che OP ci stia chiedendo di fare una scelta per lui. Sta semplicemente ponendo una domanda di alto livello su come vengono fatte tali scelte e quali fattori vengono considerati. Non pensare che ci sia qualcosa di sbagliato nel fornire una risposta di alto livello a questo .... e l'ho fatto.
DXM,

In genere sono contrario all'utilizzo di formati binari a meno che non sia necessario. Nessun formato di file binario, nessuna serializzazione binaria, ecc. Ad esempio, in Java, le serializzazioni binarie causano incompatibilità tra le versioni Java e le versioni del proprio software, ma credo che XML non sia altrettanto. Penserei che il seguente TCP / IP> HTTP> XML Naturalmente, dipenderà da cosa stai facendo. Penso che JSON sia un'alternativa a XML. Non so molto su Spring o Netty, anche se leggo che le persone usano Spring.
Kaydell,

+1 DXM, sto ponendo domande di alto livello come spunti di riflessione quando penso di prendere una decisione del genere.
HiChews123

Risposte:


21

Ci sono sicuramente vantaggi / svantaggi nell'uso di JSON su REST rispetto al TCP / IP diretto con protocollo binario e penso che tu stia già sospettando che il protocollo binario sarà più veloce. Non posso dirti esattamente quanto più velocemente (e questo dipenderebbe da molti fattori), ma immagino che forse 1-2 ordini di differenza 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 esiste l'accesso al database / ai file sul lato server, ciò non sarà influenzato dalla scelta del livello di trasferimento. In alcuni casi, la velocità del livello di trasferimento potrebbe essere molto meno significativa.

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

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

Protobuf su TCP / IP:

  • sono più veloci

Se fosse stata una mia scelta, avrei preferito andare con HTTP REST e JSON. C'è una ragione per cui così tante altre aziende e siti web hanno intrapreso questa strada. Inoltre, tieni presente che in futuro potresti sempre supportare 2 punti finali. Se la progettazione è corretta, la scelta dell'endpoint deve essere completamente disaccoppiata dalla logica aziendale o dal database sul lato server. 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à decollare più rapidamente e ti farà avanzare.

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

Tuttavia, sospetto che la tua app non sia così speciale e potrebbe probabilmente 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 come si aspettano che tu faccia, il che significherebbe imparare di più su Spring prima di immergerti nel tuo prodotto. I telai in generale sono fantastici perché di nuovo ti fanno decollare più velocemente, ma il rovescio della medaglia è che devi adattarti al loro stampo invece di fare il tuo design e quindi aspettarti che la struttura 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 già usato Play framework prima che si basa su Netty) o Spring (ne ho solo letto). Quindi prendi quello che dico con un granello di sale.


1
+1, in particolare per "questa differenza di velocità è solo nel protocollo stesso. Se l'accesso al database / file è sul lato server, ciò non sarà influenzato dalla scelta del livello di trasferimento". Il 99% è esattamente come sarà e l'ottimizzazione prematura (nel posto sbagliato) non aiuterà affatto.
Drago Shivan,

Grazie per la lunga risposta e l'analisi approfondita sul confronto tra i due. Comprendo i vantaggi della creazione di un'applicazione RESTful perché è facilmente utilizzabile dai clienti pubblici. Nel caso, tuttavia, voglio mantenere tutto in casa e non voglio esporre il servizio (mi occupo della serializzazione / deserializzazione), non riesco a capire perché non utilizzare un protocollo binario personalizzato non sia la prima scelta. Sì, puoi decollare più velocemente con i framework esistenti, ma a spese di essere bloccato nelle loro API e controllo meno accurato.
HiChews123

REST è facile da consumare da TUTTI i clienti, non solo da quelli pubblici, ma sono sicuramente inclusi. La mia azienda ha un prodotto che costruiamo da circa un anno. Avevamo un protocollo "proprietario" che sembrava essere a riposo. L'abbiamo appena aperto ad altri. Una cosa che ti insegnano nella scuola di business è il "pensiero delle opzioni", prendi decisioni per lasciarti il ​​maggior numero di opzioni possibile in modo da poter prendere decisioni in un secondo momento. Quindi, dato che tutto è uguale, sceglierei REST non perché ho client JS o accesso API oggi, ma che ho la possibilità di averlo in futuro se ne avessi bisogno. Poi di nuovo, se ...
DXM,

... sei impostato usando il protocollo binario, provaci. Probabilità del 96% che la scelta del protocollo non abbia alcun effetto sull'applicazione finale, quindi non vorrei sudare troppo questa decisione. E come ho detto nella risposta, con un design decente, dovresti comunque essere in grado di scambiare i protocolli in un secondo momento. Un'altra cosa che mi piace fare è provare entrambi i casi, se sto prendendo una decisione, lancio una moneta e seleziono l'opzione A. La prossima volta che faccio un progetto simile seleziono l'opzione B solo così posso tornare indietro e confronta / confronta la mia esperienza. A volte, è l'unico modo in cui decidi tu stesso che è meglio
DXM,

@DXM, ottime risposte, bravo!
HiChews123,

0

Questa è una vera 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 totalmente diverse tra loro. (Vedi di più qui: http://en.wikipedia.org/wiki/Internet_protocol_suite )

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 consente di utilizzare http e protobuff è uguale a json, xml, html.

Tutto dipende da quali sono le tue esigenze e dal tipo di dati che dovrai trasportare. Hai bisogno di sessioni nel tuo protocollo, una stretta di mano può migliorare la configurazione del tuo protocollo, quanti dati invierai contemporaneamente, hai bisogno della 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à, dal supporto lingua / strumento, ecc.

Non puoi confrontare http con tcp.

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


5
Non c'è nulla nella sua domanda che suggerisce che non conosca la differenza tra i livelli dello stack di rete. Ha chiesto se dovesse usare HTTP (si presume che HTTP sia uno strato sopra TCP / IP) o usare TCP / IP con il suo protocollo personalizzato. Non c'è niente di sbagliato nella sua domanda.
Michael,

Non sono d'accordo ovviamente. Non è così che l'ho capito
iveqy

1
Sì, capisco che HTTP è a un livello superiore a TCP / IP, la mia domanda riguarda davvero l'idea di prendere una decisione in termini di compromessi: latenza, velocità di sviluppo, ecc. Grazie per avermi posto delle domande a cui pensare, però!
HiChews123

2
@ acspd7 Eviterei di creare il tuo protocollo, ci sono molti protocolli già provati là fuori e se il tuo protocollo non è qualcosa che ti darà un vantaggio sui tuoi concorrenti, probabilmente stai meglio con un protocollo standard. Ho implementato un protocollo personalizzato, è stato molto divertente! Tuttavia crittografia, perforazione, mantenimento della vita, handshaking (reti diverse richiedono framlature diverse) ecc. È molto lavoro per fare le cose bene. Per non parlare di tutta la documentazione di cui avrai bisogno. Pensa a ciò di cui hai veramente bisogno nelle funzionalità prima di fare qualcosa di personalizzato.
iveqy,

1
I GPB sono ben documentati, utilizzati da molti altri, quindi non riesco davvero a vedere alcun problema con l'utilizzo. Beeing più conciso di XML e JSON dovrebbe essere fantastico! (potresti non avere leggibilità umana, ma se questo non è un requisito ...). Tuttavia, non ti manca un livello? Di solito hai un livello tra tcp e xml, json, protobuff. Qualcosa come http, ssh, ecc.
iveqy
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.