Tutto ciò che uno sviluppatore C++ dovrebbe conoscere sulla programmazione di rete?

Question

Quindi sto facendo un sacco di programmazione di rete ad alte prestazioni usando Boost :: Asio (o solo Asio se lo farai), e ho una buona conoscenza degli elementi essenziali dei protocolli TCP e UDP. Mi chiedo però, perché non mi considero ancora un esperto di networking nonostante la mia conoscenza, che cosa è un buon modo per inquadrare gli elementi essenziali di ciò che i programmatori di rete dovrebbero sapere, specialmente per coloro che cercano di spingere le prestazioni delle loro grandi reti basate applicazioni?

C'è un grande saggio sui programmatori e cosa dovrebbero sapere sulla memoria (vedi sotto), quindi mi chiedo se qualcuno ha messo insieme qualcosa di simile per il networking.

What every programmer should know about memory

Answer 1

Alcuni punti elenco al largo della parte superiore della mia testa di cose che dovreste sapere:

• Come e perché TCP funziona ... strette di mano a 3 vie, il riconoscimento, ACK ritardati, nagling, protocollo per finestre scorrevoli. C'è una ragione concreta per ognuna di queste funzionalità ... e possono distruggere tutte le prestazioni della tua applicazione se gestite in modo improprio.
• UDP multicast ... anche se non pensate di usarlo, è necessario sapere perché esiste in modo da poter prendere decisioni istruite durante la progettazione dei sistemi.
• frammentazione IP e l'impatto di MTU.
• Serializzazione binaria e ordinamento dei byte di rete (anche se si stanno solo utilizzando i proto buffer di Google, è bello capire perché sono efficienti).
• Ascii serializzazione e il messaggio inquadratura (cosa vuol \r\n\r\n significa in HTTP?)
• Diversi modelli di spedizione I/O: in stile Apache preforking, filo-per-collegamento, evento a base di single-threaded, evento-based con l'operaio fili, ecc
• L'impatto della vulnerabilità di buffer overflow in un'applicazione di rete
• disegno protocollo basato, al contrario di API- o basato sulla libreria disegno
• asincrono vs protocolli sincroni. Molti sistemi ad alte prestazioni sono asincroni. HTTP è sincrono a meno che non si usi il pipelining e, anche in questo caso, ci sono molte restrizioni su ciò che è possibile ... nessuna risposta out-of-order, per esempio.

---

Aggiornamento: Che cosa significa la progettazione basata sul protocollo?

Considerare HTTP, il protocollo del web. Apache, IIS, Lighttpd, Firefox, Opera, WebKit, ecc. Tutti questi software parlano di HTTP. È possibile che nessuno di loro stia condividendo il codice per farlo. Lo svantaggio, ovviamente, è la maggiore probabilità di errori dovuti al volume netto di codice. Ci sono numerosi aspetti positivi:

• Ogni programma può comunicare tramite HTTP, a prescindere dal linguaggio di implementazione
• ambienti leggeri/embedded possono scegliere un sottoinsieme del protocollo, piuttosto che utilizzare l'intera faccenda
• E 'possibile ottimizzare un gestore di protocollo per situazioni particolari. Non è possibile ottimizzare una libreria senza sacrificare la generalità.
• Una varietà di diverse implementazioni obbliga i provider di librerie a risolvere i bug (piuttosto che a farli fuoriuscire perché, beh, tutti usano la stessa libreria).
• Non vi è alcun onere organizzativo o contrattuale per gli utenti di HTTP, nessun costo di licenza.

Quando si progetta un protocollo di rete, è possibile creare diverse API, ciascuna adatta a casi d'uso specifici. Oppure puoi costruirne uno, tocca a te. I componenti software collegati in rete possono essere aggiornati indipendentemente l'uno dall'altro. Fondamentalmente, tutto ciò che si sente va bene per le interfacce Java/C# e le classi astratte C++, ma applicate al livello di rete piuttosto che al livello del linguaggio di programmazione.