IPv4 (e IP en general), sin dudarlo.
Mira, la red se basa en una arquitectura en capas. Las capas, en la práctica, serían:
- La capa de aplicación (HTTP, POP, etc.)
- La capa de transporte (TCP, UDP), también conocida como capa 4
- La capa de red (IP), también conocida como capa 3
- La capa de enlace (Ethernet, 802.11a / b / g / n), también conocida como capa 2
Pero aquí está la cosa: solo hay un protocolo para la capa de red, lo que significa que todo tiene que pasar por ella. Generalmente tiene alguna opción para la capa de transporte (al menos entre TCP y UDP, puede crear su propio protocolo en principio), y para las otras capas, casi todo vale.
Este hecho generalmente se llama el “modelo de reloj de arena”, como se puede ver fácilmente aquí (la fila superior son aplicaciones específicas y no un protocolo en sí, la fila inferior es la capa física, que no mencioné porque generalmente es manejada por “personas de hardware” y no “personas de la red”):
De esa imagen queda claro que la IP es el centro de atención. Básicamente, todo lo que se encuentra arriba puede ser específico de la aplicación, mientras que todo lo que está debajo no está influenciado por el resto de Internet y no lo hace, por lo que puede hacer lo que sea.
IPv4 es tan importante que hasta ahora hemos progresado relativamente poco en cambiar a IPv6, a pesar de que corrige una falla terrible de IPv4, es decir, el número relativamente pequeño de direcciones que proporciona. De hecho, IPv6 se propuso en 1996 y, a partir de 2013, la gran mayoría de nosotros todavía usamos IPv4. En realidad, ha sido tan difícil para nosotros cambiar a IPv6 que se ha gastado mucho tiempo, dinero y energía en trucos para hacer que IPv4 sobreviva un poco más (NAT, CIDR …), en lugar de hacerlo realmente cambiar.
El siguiente protocolo más importante sería TCP. La gran mayoría de los flujos en Internet hoy en día son flujos TCP. Esto resulta tener consecuencias interesantes. ¿Recuerdas cuando dije que podrías crear tu propio protocolo de capa de transporte y usarlo fácilmente? Bueno, esto es algo cierto, pero no del todo. Vea, aunque se supone que TCP y UDP son protocolos “de extremo a extremo”, lo que significa que no se supone que los nodos intermedios los miren, en la práctica, muchos nodos intermedios los miran.
Hay varias razones para esto, una es que puede pasar por un proxy o un firewall que necesita analizar su tráfico, y si no reconocen sus paquetes, en realidad existe la posibilidad de que simplemente los descarten todos. Otra es que los NAT (que, si recuerdas, se crearon para solucionar problemas con IPv4) en realidad suponen que estás utilizando TCP o UDP. Así es, los NAT en realidad rompen el sistema de capas de una manera que en realidad hace que sea mucho más difícil crear nuevos protocolos de capa 4 (a menos que los hagas parecer TCP o UDP).
Otro problema con TCP es que si crea un nuevo protocolo de capa de transporte que controla la congestión (como TCP), se supone que debe preocuparse por algo llamado “compatibilidad con TCP”. La compatibilidad con TCP es la idea de que los flujos que utilizan su nuevo protocolo no deberían “vencer” los flujos de TCP. Dicho de otra manera, si su nuevo flujo de protocolo compite con un flujo TCP por recursos de red, debería converger a una situación en la que ambos flujos usan la misma cantidad de recursos [1].
Este es un problema porque significa que algunas técnicas que logran un control de congestión significativamente mejor que el TCP no se pueden usar en absoluto en Internet. Eso todavía deja margen para mejorar sobre TCP, pero limita el rango de estas mejoras.
En cualquier caso, lo que eso significa es que debe tener en cuenta TCP incluso cuando está haciendo algo que aparentemente no está relacionado con él, por lo que sería el segundo protocolo más importante en Internet.
Ahí tienes. Si tuviera que elegir un tercero, sería BGP o tal vez Ethernet, pero ya hice trampa dando dos respuestas, por lo que no iré más allá de esto.
[1] ACTUALIZACIÓN: esto es realmente incorrecto. Su nuevo protocolo puede ser más rápido (es decir, usar más recursos) que TCP. Sin embargo, si está compartiendo una ruta con otros flujos TCP, los otros flujos deberían tener la misma cantidad de acceso a los recursos que si fuera otro flujo TCP. Resulta que eso no significa que no pueda ser más rápido que TCP porque TCP no usa el 100% de la capacidad de una ruta, incluso cuando va a toda velocidad, pero limita seriamente lo que puede hacer.