Todo lo que un desarrollador de C++ debe saber sobre la programación de la red?

Question

Estoy haciendo una gran cantidad de programación en red de alto rendimiento usando Boost :: Asio (o solo Asio si lo desea), y tengo una comprensión bastante sólida de los fundamentos de los protocolos TCP y UDP. Sin embargo, me pregunto, porque todavía no me considero un experto en redes, a pesar de mi conocimiento, ¿cuál es una buena manera de enmarcar lo esencial de lo que los programadores de redes deberían saber, especialmente para aquellos que intentan impulsar el rendimiento de sus grandes redes basadas en redes? aplicaciones?

Hay un gran ensayo sobre los programadores y sobre lo que deberían saber sobre la memoria (ver a continuación), así que me pregunto si alguien ha creado algo similar para la creación de redes.

What every programmer should know about memory

Answer 1

Algunos puntos de la bala de la parte superior de la cabeza de cosas que debe saber:

• ¿Cómo y por qué funciona ... TCP de 3 vías apretones de manos, reconocimiento, ACK retrasado, nagling, protocolo de ventana deslizante. Hay una razón concreta para cada una de esas características ... y todas pueden destruir el rendimiento de su aplicación si se manejan de forma incorrecta.
• Multidifusión UDP ... incluso si nunca piensa que la usará, necesita saber por qué existe para que pueda tomar decisiones informadas al diseñar sistemas.
• La fragmentación de IP y el impacto de MTU.
• serialización binaria y ordenamiento de bytes de red (incluso si solo va a utilizar búfers de proto Google, es bueno entender por qué son eficientes).
• ASCII serialización y el encuadre del mensaje (lo que quiere decir \r\n\r\n en HTTP?)
• diferentes de E/S de modelos de despacho: preforking de estilo Apache, hilos de cada conexión, de un solo subproceso basada en eventos, eventos de base con el trabajador hilos, etc.
• El impacto de las vulnerabilidades de desbordamiento del búfer en una aplicación en red
• diseño basado en Protocolo, en contraposición a API- o basados ​​en biblioteca de diseño
• asíncrono vs protocolos síncronos. Muchos sistemas de alto rendimiento son asincrónicos. HTTP es sincrónico a menos que use pipelining, e incluso entonces, hay muchas restricciones sobre lo que es posible ... no hay respuestas fuera de orden, por ejemplo.

---

Actualización: ¿Qué significa el diseño basado en el protocolo?

Considere HTTP, el protocolo de la web. Apache, IIS, Lighttpd, Firefox, Opera, WebKit, etc. Todas estas piezas de software hablan HTTP. Es muy posible que ninguno de ellos esté compartiendo el código para hacerlo. La desventaja, por supuesto, es la mayor probabilidad de errores debido al volumen neto de código. Hay numerosos aspectos positivos:

• cualquier programa puede comunicarse a través de HTTP, independientemente del lenguaje de implementación
• ambientes ligeros/incrustado puede escoger y elegir un subconjunto del protocolo, en lugar de utilizar todo el asunto
• Es posible para optimizar un manejador de protocolo para situaciones particulares. No es posible optimizar una biblioteca sin sacrificar la generalidad.
• Una variedad de implementaciones diferentes obliga a los proveedores de bibliotecas a solucionar los errores (en lugar de solo eliminarlos porque, bueno, todos usan la misma biblioteca).
• No existe una carga organizativa o contractual en los usuarios de HTTP, no hay tarifas de licencia.

Al diseñar un protocolo de red, puede compilar varias API, cada una adaptada a casos de uso específicos. O puedes construir uno, depende de ti. Los componentes de software en red se pueden actualizar de forma independiente. Básicamente, todo lo que escuchas es bueno sobre las interfaces Java/C# y las clases abstractas de C++, pero se aplica en la capa de red en lugar de en la capa de lenguaje de programación.