Capítulo 1. Introducción a las redes

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

"Culpable hasta que se demuestre su inocencia". Ése es el mantra de las redes y de los ingenieros que las supervisan. En este capítulo inicial, nos adentraremos en el desarrollo de las tecnologías y normas de redes, daremos una breve visión general de la teoría dominante de las redes, y presentaremos nuestro servidor web Golang que será la base de los ejemplos de redes en Kubernetes y la nube a lo largo del libro.

Empecemos... por el principio.

Historia de las redes

La Internet que conocemos hoy es inmensa, con cables que atraviesan océanos y montañas y conectan ciudades con una latencia menor que nunca. El "Mapa de Internet" de Barrett Lyon, que se muestra en la Figura 1-1, muestra lo enorme que es realmente. Esa imagen ilustra todas las conexiones entre las redes de redes que componen Internet. El propósito de una red es intercambiar información de un sistema a otro sistema. Se trata de una enorme demanda de un sistema global distribuido, pero internet no siempre fue global; empezó como un modelo conceptual y se fue construyendo lentamente con el tiempo, hasta convertirse en el behemoth de la obra de arte visualmente impresionante de Lyon. Hay muchos factores a tener en cuenta cuando se aprende sobre redes, como la última milla, la conectividad entre el domicilio de un cliente y la red de su proveedor de servicios de Internet, hasta llegar al panorama geopolítico de Internet. Internet está integrado en el tejido de nuestra sociedad. En este libro, analizaremos cómo funcionan las redes y cómo Kubernetes las abstrae para nosotros.

La Tabla 1-1 resume brevemente la historia de las redes antes de que nos sumerjamos en algunos de los detalles importantes de .

Tabla 1-1. Breve historia de las redes
Año	Evento
1969	Primera prueba de conexión de ARPANET
1969	Telnet 1969 Solicitud de Comentarios (RFC) 15 redactada
1971	FTP RFC 114 redactado
1973	FTP RFC 354 redactado
1974	TCP RFC 675 redactado por Vint Cerf, Yogen Dalal y Carl Sunshine
1980	Comienza el desarrollo del modelo de Interconexión de Sistemas Abiertos
1981	IP RFC 760 redactado
1982	NORSAR y el University College de Londres abandonaron ARPANET y empezaron a utilizar TCP/IP sobre SATNET
1984	Se publica el modelo ISO 7498 de Interconexión de Sistemas Abiertos (OSI)
1991	Aprobada la Ley de Infraestructura Nacional de la Información (NII) con la ayuda de Al Gore
1991	Lanzamiento de la primera versión de Linux
2015	Lanzamiento de la primera versión de Kubernetes

En sus primeras formas, la creación de redes estaba dirigida o patrocinada por el gobierno; en Estados Unidos, el Departamento de Defensa (DOD) patrocinó la Red de la Agencia de Proyectos de Investigación Avanzada (ARPANET), mucho antes de la época de Al Gore en la política, que será relevante dentro de un momento. En 1969, ARPANET se implementó en la Universidad de California-Los Ángeles, el Centro de Investigación de Aumento del Instituto de Investigación de Stanford, la Universidad de California-Santa Bárbara y la Escuela de Informática de la Universidad de Utah. La comunicación entre estos nodos no se completó hasta 1970, cuando empezaron a utilizar el Protocolo de Control de Red (NCP). El NCP condujo al desarrollo y uso de los primeros protocolos de ordenador a ordenador, como Telnet y el Protocolo de Transferencia de Archivos (FTP).

El éxito de ARPANET y de NCP, el primer protocolo que impulsó ARPANET, provocó la caída de NCP. No podía seguir el ritmo de las exigencias de la red y de la variedad de redes conectadas. En 1974, Vint Cerf, Yogen Dalal y Carl Sunshine empezaron a redactar en el RFC 675 para el Protocolo de Control de Transmisión (TCP). (Dentro de unos párrafos aprenderás más sobre los RFC.) TCP se convertiría en el estándar para la conectividad de redes. TCP permitía intercambiar paquetes a través de distintos tipos de redes. En 1981, el Protocolo de Internet (IP), definido en el RFC 791, ayudó a separar las responsabilidades de TCP en un protocolo independiente, aumentando la modularidad de la red. En los años siguientes, muchas organizaciones, incluido el Departamento de Defensa, adoptaron el TCP como estándar. En enero de 1983, TCP/IP se había convertido en el único protocolo aprobado en ARPANET, sustituyendo al anterior NCP por su versatilidad y modularidad.

Una organización de normalización competidora, la Organización Internacional de Normalización (ISO), desarrolló y publicó la ISO 7498, "Modelo de referencia de interconexión de sistemas abiertos", que detallaba el modelo OSI. Con su publicación también llegaron los protocolos para soportarlo. Desgraciadamente, los protocolos del modelo OSI nunca ganaron tracción y perdieron ante la popularidad del TCP/IP. Sin embargo, el modelo OSI sigue siendo una excelente herramienta de aprendizaje para comprender el enfoque por capas de las redes.

En 1991, Al Gore inventó Internet (bueno, en realidad ayudó a aprobar la Ley de Infraestructura Nacional de la Información [NII]), lo que contribuyó a la creación de la Internet Engineering Task Force (IETF). Hoy en día normas para internet están bajo la gestión de la IETF, un consorcio abierto de expertos y empresas líderes en el campo de las redes, como Cisco y Juniper. Las RFC son publicadas por la Internet Society y la Internet Engineering Task Force. Las RFC son autorías destacadas de personas o grupos de ingenieros e informáticos, y detallan sus procesos, operaciones y aplicaciones para el funcionamiento de internet.

Una RFC del IETF tiene dos estados:

Norma propuesta: Una especificación de protocolo ha alcanzado el suficiente apoyo comunitario para ser considerada una norma. Los diseños son estables y se comprenden bien. Una norma propuesta puede desplegarse, implementarse y probarse. Sin embargo, puede retirarse para seguir considerándola.
Norma de Internet: Según el RFC 2026: "En general, un estándar de Internet es una especificación estable y bien comprendida, técnicamente competente, que tiene múltiples implementaciones independientes e interoperables con una experiencia operativa sustancial, que goza de un apoyo público significativo y que es reconociblemente útil en algunas partes de Internet."

Nota

El proyecto de norma es una tercera clasificación que se dejó de aplicar en 2011.

Hay miles de normas de Internet que definen cómo implantar protocolos para todas las facetas de las redes, incluidas las inalámbricas, la encriptación y los formatos de datos, entre otras. Cada una de ellas es implementada por colaboradores de proyectos de código abierto y de forma privada por grandes organizaciones como Cisco.

Han pasado muchas cosas en los casi 50 años transcurridos desde aquellas primeras pruebas de conectividad. Las redes han crecido en complejidad y en abstracciones , así que empecemos por el modelo OSI.

Modelo OSI

El modelo OSI es un marco conceptual para describir cómo se comunican dos sistemas a través de una red. El modelo OSI divide en capas la responsabilidad de enviar datos a través de las redes. Esto funciona bien con fines educativos para describir las relaciones entre la responsabilidad de cada capa y cómo se envían los datos a través de las redes. Curiosamente, estaba destinado a ser un conjunto de protocolos para alimentar las redes, pero se perdió en favor del TCP/IP.

Aquí tienes las normas ISO que describen el modelo OSI y sus protocolos:

ISO/IEC 7498-1, "El modelo básico".
ISO/IEC 7498-2, "Arquitectura de seguridad".
ISO/IEC 7498-3, "Nomenclatura y direccionamiento".
ISO/IEC 7498-4, "Marco de gestión".

La norma ISO/IEC 7498-1 describe lo que intenta transmitir el modelo OSI:

5.2.2.1 La técnica básica de estructuración del Modelo de Referencia de Interconexión de Sistemas Abiertos es la estratificación. Según esta técnica, cada sistema abierto se considera lógicamente compuesto por un conjunto ordenado de (N)-subsistemas... Los (N)-subsistemas adyacentes se comunican a través de su frontera común. Los (N)-subsistemas del mismo rango (N) forman colectivamente la (N)-capa del Modelo de Referencia de Interconexión de Sistemas Abiertos. Hay uno y sólo un (N)-subsistema en un sistema abierto para la capa N. Un (N)-subsistema consta de una o varias (N)-entidades. Existen entidades en cada capa (N). Las entidades de la misma capa (N) se denominan entidades pares (N). Ten en cuenta que la capa superior no tiene ninguna (N+l)-capa por encima, y que la capa inferior no tiene ninguna (N-1)-capa por debajo.

La descripción del modelo OSI es una forma compleja y exacta de decir que las redes tienen capas, como los pasteles o las cebollas. El modelo OSI divide las responsabilidades de la red en siete capas distintas, cada una con funciones diferentes para ayudar a transmitir información de un sistema a otro, como se muestra en la Figura 1-2. Las capas encapsulan información de la capa inferior; estas capas son Aplicación, Presentación, Sesión, Transporte, Red, Enlace de datos y Física. En las próximas páginas repasaremos la funcionalidad de cada capa y cómo envía datos entre dos sistemas.

Cada capa toma los datos de la capa anterior y los encapsula en para formar su Unidad de Datos de Protocolo (PDU). La PDU se utiliza para describir los datos en cada capa. Las PDU también forman parte de TCP/IP. Las aplicaciones de la capa Sesión se consideran "datos" para la PDU, preparando la información de la aplicación para la comunicación. El transporte utiliza puertos para distinguir qué proceso del sistema local es responsable de los datos. La PDU de la capaRed es el paquete. Los paquetes son distintas piezas de datos que se encaminan entre redes. La capa de Enlace de Datos es la trama o segmento. Cada paquete se divide en tramas, se comprueba si hay errores y se envía a la red local. La capa Física transmite la trama en bits a través del medio. A continuación describiremos cada capa en detalle:

Aplicación: La capa de Aplicación es la capa superior del modelo OSI y es con la que el usuario final interactúa cada día. Esta capa no es donde viven las aplicaciones reales, pero proporciona la interfaz para las aplicaciones que la utilizan, como un navegador web u Office 365. La interfaz más importante es HTTP; probablemente estés leyendo este libro en una página web alojada en un servidor web de O'Reilly. Otros ejemplos de la capa de Aplicación que utilizamos a diario son DNS, SSH y SMTP. Estas aplicaciones se encargan de mostrar y organizar los datos solicitados y enviados a través de la red.
Presentación: Esta capa proporciona independencia de la representación de los datos al traducir entre formatos de aplicación y de red. Puede denominarse capa de sintaxis. Esta capa permite que dos sistemas utilicen codificaciones diferentes para los datos y aún así pasen datos entre ellos. El cifrado también se realiza en esta capa, pero esa es una historia más complicada que reservaremos para "TLS".
Sesión: La capa Sesión es responsable del dúplex de la conexión, es decir, de si se envían y reciben datos al mismo tiempo. También establece los procedimientos para realizar el checkpoint, suspender, reiniciar y terminar una sesión. Construye, gestiona y termina las conexiones entre las aplicaciones local y remota.
Transporte: La capa de Transporte transfiere datos entre aplicaciones, proporcionando servicios fiables de transferencia de datos a las capas superiores. La capa de Transporte controla la fiabilidad de una determinada conexión mediante el control de flujo, la segmentación y desagregación, y el control de errores. Algunos protocolos están orientados al estado y a la conexión. Esta capa realiza un seguimiento de los segmentos y retransmite los que fallan. También proporciona el acuse de recibo de la transmisión correcta de datos y envía los siguientes datos si no se ha producido ningún error . TCP/IP tiene dos protocolos en esta capa: TCP yel Protocolo de Datagramas de Usuario (UDP).
Red: La capa de Red implementa un medio para transferir flujos de datos de longitud variable desde un host de una red a otro host de otra red, manteniendo lacalidad del servicio. La capa de Red realiza funciones de enrutamiento y también puede realizar la fragmentación y el reensamblaje, a la vez que informa de los errores de entrega. Los routers operan en esta capa, enviando datos a través de las redes vecinas. Varios protocolos de gestión pertenecen a la capa de Red, como los protocolos de encaminamiento, la gestión de grupos multidifusión, la información de la capa de red, la gestión de errores y la asignación de direcciones de la capa de red, que trataremos más adelante en"TCP/IP".
Enlace de datos: Esta capa es responsable de las transferencias de host a host en la misma red. Define los protocolos para crear y terminar las conexiones entre dos dispositivos. La capa de Enlace de Datos transfiere datos entre hosts de red y proporciona los medios para detectar y posiblemente corregir errores de la capa Física. Las tramas de Enlace de Datos, la PDU de la capa 2, no traspasan los límites de una red local.
Físico: La capa Física se representa visualmente mediante un cable Ethernet enchufado a un conmutador. Esta capa convierte los datos en forma de bits digitales en señales eléctricas, de radio u ópticas. Piensa en esta capa como en los dispositivos físicos, como cables, conmutadores y puntos de acceso inalámbricos. Los protocolos de señalización por cable también se definen en esta capa.

Nota

Hay muchos mnemotécnicos para recordar las capas del modelo OSI; nuestro favorito es Todas las personas parecen necesitar procesamiento de datos.

La Tabla 1-2 resume las capas OSI.

Tabla 1-2. Detalles de la capa OSI
Número de capa	Nombre de la capa	Unidad de datos del protocolo	Resumen de funciones
7	Aplicación	Datos	API de alto nivel y protocolos de aplicación como HTTP, DNS y SSH.
6	Presentación	Datos	Codificación de caracteres, compresión de datos y encriptación/desencriptación.
5	Sesión	Datos	Aquí se gestionan los intercambios continuos de datos entre nodos: cuántos datos enviar, cuándo enviar más.
4	Transporte	Segmento, datagrama	Transmisión de segmentos de datos entre puntos finales de una red, incluyendo la segmentación, el acuse de recibo y la multiplexación.
3	Red	Paquete	Estructurar y gestionar el direccionamiento, el encaminamiento y el control del tráfico para todos los puntos finales de la red.
2	Enlace de datos	Marco	Transmisión de tramas de datos entre dos nodos conectados por una capa física.
1	Físico	Bit	Envío y recepción de flujos de bits a través del medio.

El modelo OSI desglosa todas las funciones necesarias para enviar un paquete de datos a través de una red entre dos hosts. A finales de los 80 y principios de los 90, perdió frente al TCP/IP como norma adoptada por el Departamento de Defensa y todos los demás actores importantes de las redes. La norma definida en ISO 7498 ofrece una breve visión de los detalles de implementación que la mayoría consideraba entonces complicados, ineficaces y, hasta cierto punto, inaplicables. El modelo OSI a alto nivel sigue permitiendo a los que están aprendiendo a trabajar en red comprender los conceptos básicos y los retos de las redes. Además, estos términos y funciones se utilizan en el modelo TCP/IP que se trata en la siguiente sección y, en última instancia, en las abstracciones de Kubernetes. Los servicios de Kubernetes desglosan cada función dependiendo de la capa en la que opere, por ejemplo, una dirección IP de capa 3 o un puerto de capa 4; aprenderás más sobre esto en el Capítulo 4. A continuación, profundizaremos en el conjunto TCP/IP con un ejemplo de recorrido.

TCP/IP

TCP/IP crea una red heterogénea con protocolos abiertos que son independientes del sistema operativo y de las diferencias arquitectónicas. Tanto si los hosts ejecutan Windows, Linux u otro sistema operativo, TCP/IP les permite comunicarse; a TCP/IP no le importa si estás ejecutando Apache o Nginx para tu servidor web en la capa de Aplicación. La separación de responsabilidades similar al modelo OSI lo hace posible. En la Figura 1-3, comparamos el modelo OSI con TCP/IP.

Aquí ampliamos las diferencias entre el modelo OSI y el TCP/IP:

Aplicación

En TCP/IP, la capa de Aplicación comprende los protocolos de comunicación utilizados en las comunicaciones de proceso a proceso a través de una red IP. La capa de Aplicación estandariza la comunicación y depende de los protocolos subyacentes de la capa de Transporte para establecer la transferencia de datos de host a host. La capa inferior de Transporte también gestiona el intercambio de datos en las comunicaciones de red. Las aplicaciones en esta capa se definen en RFCs; en este libro, seguiremos utilizando HTTP, RFC 7231 como nuestro ejemplo para la capa de Aplicación.

Transporte

TCP y UDP son los protocolos principales de la capa de Transporte que proporcionan servicios de comunicación de host a host para las aplicaciones. Los protocolos de transporte son responsables de la comunicación orientada a la conexión, la fiabilidad, el control de flujo y la multiplexación. En TCP, el tamaño de la ventana gestiona el control de flujo, mientras que UDP no gestiona el flujo de congestión y se considera poco fiable; aprenderás más sobre ello en "UDP". Cada puerto identifica el proceso anfitrión responsable de procesar la información de la comunicación de red. HTTP utiliza el conocido puerto 80 para la comunicación no segura y el 443 para la comunicación segura. Cada puerto del servidor identifica su tráfico, y el remitente genera localmente un puerto aleatorio para identificarse. El organismo rector de que gestiona la asignación de números de puerto es la Autoridad de Asignación de Números de Internet (IANA); hay 65.535 puertos.

Internet

La capa Internet, o Red , se encarga de transmitir datos entre redes. Para un paquete saliente, selecciona el host de siguiente salto y lo transmite a ese host pasándolo a la capa de enlace adecuada. Una vez que el paquete es recibido por el destino, la capa de Internet pasará la carga útil del paquete al protocolo apropiado de la capa de Transporte.

IP proporciona la fragmentación o desfragmentación de paquetes en función de la unidad máxima de transmisión (UTM); éste es el tamaño máximo del paquete IP. IP no ofrece garantías sobre la correcta llegada de los paquetes. Dado que la entrega de paquetes a través de redes diversas es intrínsecamente poco fiable y propensa a fallos, esa carga recae en los puntos finales de una ruta de comunicación, y no en la red. La función de proporcionar fiabilidad al servicio está en la capa de Transporte. Una suma de comprobación garantiza que la información de un paquete recibido es exacta, pero esta capa no valida la integridad de los datos. La dirección IP identifica los paquetes en la red.

Enlace

La capa Enlace del modelo TCP/IP comprende protocolos de red que sólo funcionan en la red local a la que se conecta un host. Los paquetes no se enrutan a redes no locales; ése es el papel de la capa de Internet. Ethernet es el protocolo dominante en esta capa, y los anfitriones se identifican por la dirección de la capa de enlace o, comúnmente, por sus direcciones de Control de Acceso al Medio en sus tarjetas de interfaz de red. Una vez determinada por el host mediante el Protocolo de Resolución de Direcciones 9 (ARP), los datos enviados fuera de la red local son procesados por la capa de Internet. Esta capa también incluye protocolos para mover paquetes entre dos hosts de la capa de Internet.

Capa física

La capa Física define los componentes del hardware a utilizar para la red. Por ejemplo, la capa Física de la red estipula las características físicas de los medios de comunicación. La capa Física de TCP/IP detalla los estándares de hardware como IEEE 802.3, la especificación para los medios de red Ethernet. Varias interpretaciones de la RFC 1122 para la capa Física se incluyen con las otras capas; lo hemos añadido para completar la información.

A lo largo de este libro, utilizaremos el servidor web Golang mínimo (también llamado Go) del Ejemplo 1-1 para mostrar varios niveles de componentes de red de tcpdump, una syscall de Linux, para mostrar cómo Kubernetes abstrae las syscalls. Esta sección la utilizará para demostrar lo que ocurre en las capas de Aplicación, Transporte, Red y Enlace de Datos.

Aplicación

Como ya hemos dicho, Aplicación es la capa más alta de la pila TCP/IP; es donde el usuario interactúa con los datos antes de que se envíen por la red. En nuestro ejemplo, vamos a utilizar el Protocolo de Transferencia de Hipertexto (HTTP) y una transacción HTTP sencilla para demostrar lo que ocurre en cada capa de la pila TCP/IP.

HTTP

HTTP es responsable de enviar y recibir documentos de Lenguaje de Marcado de Hipertexto (HTML), ya sabes, una página web. Una gran mayoría de lo que vemos y hacemos en Internet es a través de HTTP: las compras en Amazon, las publicaciones en Reddit y los tweets utilizan HTTP. Un cliente hará una solicitud HTTP a nuestro servidor web Golang mínimo del Ejemplo 1-1, y éste enviará una respuesta HTTP con el texto "Hola". El servidor web se ejecuta localmente en una máquina virtual Ubuntu para probar la pila TCP/IP completa.

Nota

Consulta el repositorio de código de ejemplo para ver las instrucciones completas.

Ejemplo 1-1. Servidor web mínimo en Go

package main

import (
	"fmt"
	"net/http"
)

func hello(w http.ResponseWriter, _ *http.Request) {
	fmt.Fprintf(w, "Hello")
}

func main() {
	http.HandleFunc("/", hello)
	http.ListenAndServe("0.0.0.0:8080", nil)
}

En nuestra máquina virtual Ubuntu necesitamos iniciar nuestro servidor web mínimo, o si tienes Golang instalado localmente, puedes simplemente ejecutar esto:

go run web-server.go

Vamos a desglosar la solicitud para cada capa de la pila TPC/IP.

cURL es el cliente solicitante de para nuestro ejemplo de solicitud HTTP. Generalmente, para una página web, el cliente sería un navegador web, pero estamos utilizando cURL para simplificar y mostrar la línea de comandos.

Nota

cURL está pensado para cargar y descargar datos especificados con una URL. Es un programa del lado del cliente (el c) para solicitar datos de una URL y devolver la respuesta.

En el Ejemplo 1-2, podemos ver cada parte de la petición HTTP que realiza el cliente cURL y la respuesta. Repasemos qué son todas esas opciones y salidas.

Ejemplo 1-2. Solicitud del cliente

○ → curl localhost:8080 -vvv 
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 
> GET / HTTP/1.1 
> Host: localhost:8080 
> User-Agent: curl/7.64.1 
> Accept: */* 
>
< HTTP/1.1 200 OK 
< Date: Sat, 25 Jul 2020 14:57:46 GMT 
< Content-Length: 5 
< Content-Type: text/plain; charset=utf-8 
<
* Connection #0 to host localhost left intact
Hello* Closing connection 0

: curl localhost:8080 -vvv: Este es el comando curl que abre una conexión con el servidor web que se ejecuta localmente, localhost en el puerto TCP 8080. -vvv establece la verbosidad de la salida para que podamos ver todo lo que ocurre con la petición. Además, TCP_NODELAY indica a la conexión TCP que envíe los datos sin retraso, una de las muchas opciones que el cliente puede configurar.
: Connected to localhost (::1) port 8080 Funcionó! cURL se conectó al servidor web en localhost y a través del puerto 8080.
: Get / HTTP/1.1 HTTP tiene varios métodos para recuperar o actualizar información. En nuestra solicitud, estamos realizando un GET HTTP para recuperar nuestra respuesta "Hola". La barra diagonal es la siguiente parte, un Localizador Uniforme de Recursos (URL), que indica dónde estamos enviando la petición del cliente al servidor. La última sección de esta cabecera es la versión de HTTP que está utilizando el servidor, 1.1.
: Host: localhost:8080 HTTP tiene varias opciones para enviar información sobre la solicitud. En nuestra solicitud, el proceso cURL ha establecido la cabecera HTTP Host. El cliente y el servidor pueden transmitir información con una solicitud HTTP o una respuesta. Una cabecera HTTP contiene su nombre seguido de dos puntos (:) y a continuación su valor.
: User-Agent: cURL/7.64.1: El agente de usuario es una cadena que indica el programa informático que realiza la solicitud HTTP en nombre del usuario final; en nuestro contexto es cURL. Esta cadena suele identificar el navegador, su número de versión y su sistema operativo anfitrión.
: Accept: */*: Esta cabecera indica al servidor web qué tipos de contenido entiende el cliente. La Tabla 1-3 muestra ejemplos de tipos de contenido comunes que se pueden enviar.
: HTTP/1.1 200 OK: Ésta es la respuesta del servidor a nuestra petición. El servidor responde con la versión HTTP y el código de estado de la respuesta. Hay varias respuestas posibles del servidor. Un código de estado 200 indica que la respuesta ha sido correcta. 1XX significa informativo, 2XX significa correcto, 3XX significa redirecciones, 4XX respuestas indican que hay problemas con las peticiones, y 5XX generalmente se refiere a problemas del servidor.
: Date: Sat, July 25, 2020, 14:57:46 GMT: El campo de cabecera Date representa la fecha y hora en que se originó el mensaje. El remitente genera el valor como la fecha y hora aproximadas de generación del mensaje.
: Content-Length: 5: La cabecera Content-Length indica el tamaño del cuerpo del mensaje, en bytes, enviado al destinatario; en nuestro caso, el mensaje es de 5 bytes.
: Content-Type: text/plain; charset=utf-8: La cabecera de entidad Content-Type se utiliza para indicar el tipo de medio del recurso. Nuestra respuesta está indicando que devuelve un archivo de texto plano codificado en UTF-8.
: Hello* Closing connection 0: Esto imprime la respuesta de nuestro servidor web y cierra la conexión HTTP .

Tabla 1-3. Tipos de contenido habituales para datos HTTP
Tipo	Descripción
solicitud	Cualquier tipo de dato binario que no entre explícitamente en uno de los otros tipos. Algunos ejemplos comunes son application/json, application/pdf, application/pkcs8 y application/zip.
audio	Datos de audio o música. Algunos ejemplos son audio/mpeg y audio/vorbis.
fuente	Datos de fuente/tipo de letra. Algunos ejemplos comunes son font/woff, font/ttf y font/otf.
imagen	Imagen o datos gráficos que incluyen tanto mapas de bits como vectores, como GIF animado o APNG. Ejemplos comunes son image/jpg, image/png e image/svg+xml.
modelo	Datos del modelo de un objeto o escena 3D. Algunos ejemplos son model/3mf y model/vrml.
texto	Datos sólo de texto que incluyen contenido legible por humanos, código fuente o datos de texto. Algunos ejemplos son text/plain, text/csv y text/html.
vídeo	Datos o archivos de vídeo, como vídeo/mp4.

Esta es una visión simplista de que ocurre con cada solicitud HTTP. Hoy en día, una sola página web realiza un número exorbitante de peticiones con una sola carga de página, ¡y en cuestión de segundos! Éste es un breve ejemplo para los administradores de clusters de cómo funciona HTTP (y, para el caso, las aplicaciones de las otras siete capas). Seguiremos ampliando nuestros conocimientos sobre cómo se completa esta solicitud en cada capa de la pila TCP/IP y, a continuación, sobre cómo Kubernetes completa esas mismas solicitudes. Todos estos datos se formatean y las opciones se establecen en la capa 7, pero el verdadero trabajo pesado de se realiza en las capas inferiores de la pila TCP/IP, que repasaremos en las próximas secciones.

Transporte

Los protocolos de la capa de Transporte se encargan de la comunicación orientada a la conexión, la fiabilidad, el control de flujo y la multiplexación; esto ocurre sobre todo con el TCP. Describiremos las diferencias en las secciones siguientes. Nuestro servidor web Golang es una aplicación de capa 7 que utiliza HTTP; la capa de Transporte en la que se basa HTTP es TCP.

TCP

Como ya se ha mencionado, TCP es un protocolo fiable orientado a la conexión, y proporciona control de flujo y multiplexación. TCP se considera orientado a la conexión porque gestiona el estado de la conexión a lo largo de su ciclo de vida. En TCP, el tamaño de la ventana gestiona el control de flujo, a diferencia de UDP, que no gestiona el flujo de congestión. Además, UDP no es fiable, y los datos pueden llegar fuera de secuencia. Cada puerto identifica el proceso anfitrión responsable de procesar la información de la comunicación de red. TCP es conocido como un protocolo de capa de host a host. Para identificar el proceso del host responsable de la conexión, TCP identifica los segmentos con un número de puerto de 16 bits. Los servidores HTTP utilizan el conocido puerto 80 para la comunicación no segura y el 443 para la comunicación segura mediante Transport Layer Security (TLS). Los clientes que solicitan una nueva conexión crean un puerto de origen local en el rango de 0-65534.

Para entender cómo TCP realiza la multiplexación, revisemos una simple recuperación de una página HTML:

En un navegador web, escribe la dirección de una página web.
El navegador abre una conexión para transferir la página.
El navegador abre conexiones para cada imagen de la página.
El navegador abre otra conexión para el CSS externo.
Cada una de estas conexiones utiliza un conjunto diferente de puertos virtuales.
Todos los activos de la página se descargan simultáneamente.
El navegador reconstruye la página.

Veamos cómo gestiona el TCP la multiplexación con la información proporcionada en las cabeceras de segmento TCP:

Source port (16 bits): Identifica el puerto de envío.
Destination port (16 bits): Identifica el puerto receptor.
Sequence number (32 bits): Si la bandera SYN es , éste es el número de secuencia inicial. El número de secuencia del primer byte de datos y el número reconocido en el ACK correspondiente es este número de secuencia más 1. También se utiliza para reensamblar los datos si llegan desordenados.

Acknowledgment number (32 bits)

Si está activada la bandera ACK , el valor de este campo es el siguiente número de secuencia del ACK que espera el remitente. Esto acusa recibo de todos los bytes precedentes (si los hay). El primer ACK de cada extremo acusa recibo del propio número de secuencia inicial del otro extremo, pero no se ha enviado ningún dato.

Data offset (4 bits)

Especifica en el tamaño de la cabecera TCP en palabras de 32 bits.

Reserved (3 bits)

Esto es para uso futuro y debe ponerse a cero.

Flags (9 bits)

Hay nueve campos de 1 bit definidos para la cabecera TCP:

NS-ECN-nonce: Protección de ocultación.
CWR: Ventana de congestión reducida; el remitente redujo su velocidad de envío.
ECE: Eco ECN; el remitente recibió una notificación de congestión anterior.
URG: Urgente; el campo Puntero Urgente es válido, pero rara vez se utiliza.
ACK: Acuse de recibo; el campo Número de acuse de recibo es válido y siempre está activado después de establecer una conexión.
PSH: Push; el receptor debe pasar estos datos a la aplicación lo antes posible.
RST: Restablecer la conexión o abortar la conexión, normalmente debido a un error.
SYN: Sincroniza los números de secuencia para iniciar una conexión.
FIN: El emisor del segmento ha terminado de enviar datos a su par.

Nota

El campo de bits NS es y se explica con más detalle en el RFC 3540, "Señalización robusta de Notificación Explícita de Congestión (ECN) con Nonces". Esta especificación describe una adición opcional a ECN que mejora la robustez frente a la ocultación maliciosa o accidental de paquetes marcados.

Window size (16 bits)

Es el tamaño de la ventana de recepción.

Checksum (16 bits)

El campo suma de comprobación se utiliza para la comprobación de errores de la cabecera TCP.

Urgent pointer (16 bits): Es un desplazamiento del número de secuencia que indica el último byte de datos urgentes.
Options: Variable 0-320 bits, en unidades de 32 bits.
Padding: El relleno de la cabecera TCP se utiliza para garantizar que la cabecera TCP termina y los datos comienzan en un límite de 32 bits.
Data: Este es el fragmento de los datos de la aplicación que se envían en este segmento.

En la Figura 1-4, podemos ver todas las cabeceras de segmento TCP que proporcionan metadatos sobre los flujos TCP.

Estos campos ayudan a gestionar el flujo de datos entre dos sistemas. La Figura 1-5 muestra cómo cada paso de la pila TCP/IP envía datos desde una aplicación en un host, a través de una red que se comunica en las capas 1 y 2, para hacerlos llegar al host de destino.

En la siguiente sección , mostraremos cómo TCP utiliza estos campos para iniciar una conexión a través del handshake de tres vías.

Apretón de manos TCP

TCP utiliza un apretón de manos a tres bandas , representado en la Figura 1-6, para crear una conexión intercambiando información a lo largo del camino con varias opciones y banderas:

El nodo solicitante envía una petición de conexión mediante un paquete SYN para que se inicie la transmisión.
Si el nodo receptor está escuchando en el puerto que solicita el remitente, el nodo receptor responde con un SYN-ACK, reconociendo que ha escuchado al nodo solicitante.
El nodo solicitante devuelve un paquete ACK, intercambiando información y haciéndoles saber que los nodos están en condiciones de enviarse información.

Ahora la conexión está establecida. Los datos pueden transmitirse a través del medio físico, enrutados entre redes, para encontrar su camino hacia el destino local, pero ¿cómo sabe el punto final cómo manejar la información? En los hosts local y remoto, se crea un socket para seguir esta conexión. Un socket no es más que un punto final lógico para la comunicación. Enel Capítulo 2, veremos cómo manejan los sockets un cliente y un servidor Linux.

TCP es un protocolo con estado, que rastrea el estado de la conexión a lo largo de su ciclo de vida. El estado de la conexión depende de que tanto el emisor como el receptor estén de acuerdo en qué punto del flujo de conexión se encuentran. El estado de la conexión se refiere a quién envía y recibe datos en el flujo TCP. TCP tiene una transición de estado compleja para explicar cuándo y dónde está la conexión, utilizando las banderas TCP de 9 bits en la cabecera del segmento TCP, como puedes ver en la Figura 1-7.

Los estados de la conexión TCP son:

LISTEN (servidor): Representa la espera de una solicitud de conexión de cualquier TCP remoto y puerto
SYN-SENT (cliente): Representa la espera de una solicitud de conexión coincidente después de enviar una solicitud de conexión
SYN-RECEIVED (servidor): Representa la espera de un acuse de recibo de confirmación de solicitud de conexión después de haber recibido y enviado una solicitud de conexión
ESTABLISHED (tanto servidor como cliente): Representa una conexión abierta; los datos recibidos pueden ser entregados al usuario -el estado intermedio para la fase de transferencia de datos de la conexión
FIN-WAIT-1 (tanto servidor como cliente): Representa la espera de una solicitud de finalización de conexión del host remoto
FIN-WAIT-2 (tanto servidor como cliente): Representa la espera de una solicitud de finalización de conexión del TCP remoto
CLOSE-WAIT (tanto servidor como cliente): Representa la espera de una solicitud de finalización de conexión de un usuario local
CLOSING (tanto servidor como cliente): Representa la espera de un acuse de recibo de solicitud de finalización de conexión del TCP remoto
LAST-ACK (tanto servidor como cliente): Representa la espera de un acuse de recibo de la solicitud de finalización de conexión enviada previamente al host remoto
TIME-WAIT (servidor o cliente): Representa esperar a que pase el tiempo suficiente para asegurarse de que el host remoto ha recibido el acuse de recibo de su solicitud de finalización de conexión
CLOSED (tanto servidor como cliente): No representa ningún estado de la conexión

El Ejemplo 1-3 es una muestra de las conexiones TCP de un Mac, su estado y las direcciones de ambos extremos de la conexión.

Ejemplo 1-3. Estados de la conexión TCP

○ → netstat -ap TCP
Active internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp6       0      0  2607:fcc8:a205:c.53606 g2600-1407-2800-.https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53603 g2600-1408-5c00-.https ESTABLISHED
tcp4       0      0  192.168.0.17.53602     ec2-3-22-64-157..https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53600 g2600-1408-5c00-.https ESTABLISHED
tcp4       0      0  192.168.0.17.53598     164.196.102.34.b.https ESTABLISHED
tcp4       0      0  192.168.0.17.53597     server-99-84-217.https ESTABLISHED
tcp4       0      0  192.168.0.17.53596     151.101.194.137.https  ESTABLISHED
tcp4       0      0  192.168.0.17.53587     ec2-52-27-83-248.https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53586 iad23s61-in-x04..https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53542 iad23s61-in-x04..https ESTABLISHED
tcp4       0      0  192.168.0.17.53536     ec2-52-10-162-14.https ESTABLISHED
tcp4       0      0  192.168.0.17.53530     server-99-84-178.https ESTABLISHED
tcp4       0      0  192.168.0.17.53525     ec2-52-70-63-25..https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53480 upload-lb.eqiad..https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53477 text-lb.eqiad.wi.https ESTABLISHED
tcp4       0      0  192.168.0.17.53466     151.101.1.132.https    ESTABLISHED
tcp4       0      0  192.168.0.17.53420     ec2-52-0-84-183..https ESTABLISHED
tcp4       0      0  192.168.0.17.53410     192.168.0.18.8060      CLOSE_WAIT
tcp6       0      0  2607:fcc8:a205:c.53408 2600:1901:1:c36:.https ESTABLISHED
tcp4       0      0  192.168.0.17.53067     ec2-52-40-198-7..https ESTABLISHED
tcp4       0      0  192.168.0.17.53066     ec2-52-40-198-7..https ESTABLISHED
tcp4       0      0  192.168.0.17.53055     ec2-54-186-46-24.https ESTABLISHED
tcp4       0      0  localhost.16587        localhost.53029        ESTABLISHED
tcp4       0      0  localhost.53029        localhost.16587        ESTABLISHED
tcp46      0      0  *.16587                *.*                    LISTEN
tcp6      56      0  2607:fcc8:a205:c.56210 ord38s08-in-x0a..https CLOSE_WAIT
tcp6       0      0  2607:fcc8:a205:c.51699 2606:4700::6810:.https ESTABLISHED
tcp4       0      0  192.168.0.17.64407     do-77.lastpass.c.https ESTABLISHED
tcp4       0      0  192.168.0.17.64396     ec2-54-70-97-159.https ESTABLISHED
tcp4       0      0  192.168.0.17.60612     ac88393aca5853df.https ESTABLISHED
tcp4       0      0  192.168.0.17.58193     47.224.186.35.bc.https ESTABLISHED
tcp4       0      0  localhost.63342        *.*                    LISTEN
tcp4       0      0  localhost.6942         *.*                    LISTEN
tcp4       0      0  192.168.0.17.55273     ec2-50-16-251-20.https ESTABLISHED

Ahora que sabemos más sobre cómo TCP construye y rastrea las conexiones , vamos a revisar la solicitud HTTP para nuestro servidor web en la capa de Transporte utilizando TCP. Para ello, utilizaremos una herramienta de línea de comandos llamada tcpdump.

tcpdump

tcpdump imprime una descripción del contenido de los paquetes de una interfaz de red que coincida con la expresión booleana.

tcpdump página man

tcpdump permite a los administradores y usuarios visualizar todos los paquetes procesados en el sistema y filtrarlos en función de muchos detalles de la cabecera del segmento TCP. En la solicitud, filtramos todos los paquetes con el puerto de destino 8080 en la interfaz de red etiquetada como lo0; ésta es la interfaz loopback local del Mac. Nuestro servidor web se ejecuta en 0.0.0.0:8080. La Figura 1-8 muestra donde tcpdump está recopilando datos en referencia a la pila TCP/IP completa, entre el controlador de la tarjeta de interfaz de red (NIC) y la capa 2.

Nota

Una interfaz loopback es una interfaz lógica y virtual de un dispositivo. Una interfaz loopback no es una interfaz física como la interfaz Ethernet. Las interfaces de bucle de retorno están siempre activas y disponibles, aunque otras interfaces estén desactivadas en el host.

El formato general de una salida de tcpdump contendrá los siguientes campos: tos,TTL, id, offset, flags, proto, length, y options. Vamos a repasarlos:

tos: El tipo de campo de servicio.
TTL: El tiempo de vida; no se informa si es cero.
id: El campo de identificación IP .
offset: El campo de desplazamiento del fragmento ; se imprime tanto si forma parte de un datagrama fragmentado como si no.
flags: La bandera DF, Don't Fragment, que indica que el paquete no puede fragmentarse para su transmisión. Cuando está desactivada, indica que el paquete puede fragmentarse. La bandera MF, Más Fragmentos, indica que hay paquetes que contienen más fragmentos y cuando se desestablece, indica que no quedan más fragmentos.
proto: El campo ID del protocolo .
length: El campo de longitud total de .
options: Las opciones de IP .

Los sistemas que admiten la descarga de sumas de comprobación y las sumas de comprobación IP, TCP y UDP se calculan en la NIC antes de transmitirse por el cable. Como estamos ejecutando una captura de paquetes tcpdump antes de la NIC, en la salida del Ejemplo 1-4 aparecen errores como cksum 0xfe34 (incorrect -> 0xb4c1).

Para producir la salida del Ejemplo 1-4, abre otro terminal e inicia un rastreo tcpdump en el loopback sólo para TCP y el puerto 8080; de lo contrario, verás muchos otros paquetes no relevantes para nuestro ejemplo. Necesitarás usar privilegios escalados para rastrear paquetes, así que eso significa usar sudo en este caso.

Ejemplo 1-4. `tcpdump`

○ → sudo tcpdump -i lo0 tcp port 8080 -vvv  

tcpdump: listening on lo0, link-type NULL (BSD loopback),
capture size 262144 bytes  

08:13:55.009899 localhost.50399 > localhost.http-alt: Flags [S],
cksum 0x0034 (incorrect -> 0x1bd9), seq 2784345138,
win 65535, options [mss 16324,nop,wscale 6,nop,nop,TS val 587364215 ecr 0,
sackOK,eol], length 0 

08:13:55.009997 localhost.http-alt > localhost.50399: Flags [S.],
cksum 0x0034 (incorrect -> 0xbe5a), seq 195606347,
ack 2784345139, win 65535, options [mss 16324,nop,wscale 6,nop,nop,
TS val 587364215 ecr 587364215,sackOK,eol], length 0  

08:13:55.010012 localhost.50399 > localhost.http-alt: Flags [.],
cksum 0x0028 (incorrect -> 0x1f58), seq 1, ack 1,
win 6371, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

v 08:13:55.010021 localhost.http-alt > localhost.50399: Flags [.],
cksum 0x0028 (incorrect -> 0x1f58), seq 1, ack
1, win 6371, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010079 localhost.50399 > localhost.http-alt: Flags [P.],
cksum 0x0076 (incorrect -> 0x78b2), seq 1:79,
ack 1, win 6371, options [nop,nop,TS val 587364215 ecr 587364215],
length 78: HTTP, length: 78  
GET / HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.64.1
Accept: */*
08:13:55.010102 localhost.http-alt > localhost.50399: Flags [.],
cksum 0x0028 (incorrect -> 0x1f0b), seq 1,
ack 79, win 6370, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010198 localhost.http-alt > localhost.50399: Flags [P.],
cksum 0x00a1 (incorrect -> 0x05d7), seq 1:122,
ack 79, win 6370, options [nop,nop,TS val 587364215 ecr 587364215],
length 121: HTTP, length: 121  
HTTP/1.1 200 OK
Date: Wed, 19 Aug 2020 12:13:55 GMT
Content-Length: 5
Content-Type: text/plain; charset=utf-8
Hello[!http]

08:13:55.010219 localhost.50399 > localhost.http-alt: Flags [.], cksum 0x0028
(incorrect -> 0x1e93), seq 79,
ack 122, win 6369, options [nop,nop,TS val 587364215 ecr 587364215], length 0  

08:13:55.010324 localhost.50399 > localhost.http-alt: Flags [F.],
cksum 0x0028 (incorrect -> 0x1e92), seq 79,
ack 122, win 6369, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010343 localhost.http-alt > localhost.50399: Flags [.],
cksum 0x0028 (incorrect -> 0x1e91), seq 122,
\ack 80, win 6370, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010379 localhost.http-alt > localhost.50399: Flags [F.],
cksum 0x0028 (incorrect -> 0x1e90), seq 122,
ack 80, win 6370, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010403 localhost.50399 > localhost.http-alt: Flags [.],
cksum 0x0028 (incorrect -> 0x1e91), seq 80, ack
123, win 6369, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

 12 packets captured, 12062 packets received by filter
 0 packets dropped by kernel.

: Este es el inicio de la colección tcpdump con su comando y todas sus opciones. El paquete sudo captura los privilegios escalados necesarios. tcpdump es el binario tcpdump. -i lo0 es la interfaz desde la que queremos capturar paquetes. dst port 8080 es la expresión de coincidencia de la que hablaba la página de manual; aquí estamos coincidiendo en todos los paquetes destinados al puerto TCP 8080, que es el puerto en el que el servicio web está escuchando las peticiones. -v es la opción verbose, que nos permite ver más detalles de la captura tcpdump.
: Comentarios de tcpdump sobre el funcionamiento del filtro tcpdump.
: Éste es el primer paquete del apretón de manos TCP. Podemos decir que es el SYN porque el bit flags está establecido con [S], y el número de secuencia está establecido con 2784345138 por cURL, siendo el número de proceso localhost 50399.
: El paquete SYN-ACK es el filtrado por tcpdump desde el proceso localhost.http-alt, el servidor web Golang. La bandera es a [S.], por lo que es un SYN-ACK. El paquete envía 195606347 como siguiente número de secuencia, y se establece ACK 2784345139 para confirmar el paquete anterior.
: El paquete de reconocimiento de cURL se envía ahora de vuelta al servidor con la bandera ACK activada, [.], con los números ACK y SYN a 1, lo que indica que está preparado para enviar datos.
: El número de acuse de recibo se pone a 1 para indicar la recepción de la bandera SYN del cliente en el push de datos de apertura.
: La conexión TCP está establecida; tanto el cliente como el servidor están listos para la transmisión de datos. Los siguientes paquetes son nuestras transmisiones de datos de la solicitud HTTP con la bandera ajustada a un push de datos y ACK, [P.]. Los paquetes anteriores tenían una longitud de cero, pero la solicitud HTTP tiene una longitud de 78 bytes, con un número de secuencia de 1:79.
: El servidor acusa recibo de la transmisión de datos, con la bandera ACK activada, [.], enviando el número de acuse de recibo 79.
: Este paquete es la respuesta del servidor HTTP a la solicitud cURL. La bandera de envío de datos está activada, [P.], y reconoce el paquete anterior con un número ACK de 79. Se establece un nuevo número de secuencia con la transmisión de datos, 122, y la longitud de los datos es de 121 bytes.
: El cliente cURL acusa recibo del paquete con la bandera ACK activada, establece el número de acuse de recibo en 122 y establece el número de secuencia en 79.
: Inicio del cierre de la conexión TCP, con el envío por parte del cliente del paquete FIN-ACK, el [F.], acusando recibo del paquete anterior, el número 122, y un nuevo número de secuencia a 80.
: El servidor incrementa el número de acuse de recibo a 80 y activa la bandera ACK.
: TCP requiere que tanto el emisor como el receptor establezcan el paquete FIN para cerrar la conexión. Éste es el paquete en el que se establecen las banderas FIN y ACK.
: Éste es el último ACK del cliente, con el número de acuse de recibo 123. La conexión se cierra ahora.
: tcpdump al salir nos permite saber el número de paquetes de esta captura, el número total de paquetes capturados durante la tcpdump, y cuántos paquetes fueron descartados por el sistema operativo.

tcpdump es una excelente aplicación de solución de problemas tanto para ingenieros de redes como para administradores de clústeres. Poder verificar la conectividad en muchos niveles del clúster y de la red son habilidades muy valiosas. En el Capítulo 6 verás lo útil que puede ser tcpdump.

Nuestro ejemplo era una simple aplicación HTTP que utilizaba TCP. Todos estos datos se enviaron a través de la red en texto plano. Aunque este ejemplo era un simple "Hola Mundo", otras solicitudes como nuestros inicios de sesión en el banco necesitan tener cierta seguridad. La capa de Transporte no ofrece ninguna protección de seguridad para los datos que transitan por la red . TLS añade seguridad adicional a TCP. Vamos a profundizar en ello en la siguiente sección.

TLS

TLS añade encriptación a TCP. TLS es un complemento del conjunto TCP/IP y no se considera parte del funcionamiento base de TCP. Las transacciones HTTP pueden completarse sin TLS, pero no son seguras frente a los fisgones en el cable. TLS es una combinación de protocolos utilizados para garantizar la visibilidad del tráfico entre el remitente y el destinatario. TLS, al igual que TCP, utiliza un apretón de manos para establecer las capacidades de cifrado e intercambiar claves para el cifrado. En los pasos siguientes se detalla el handshake TLS entre el cliente y el servidor, que también puede verse en la Figura 1-9:

ClientHello: Contiene los conjuntos de cifrado admitidos por el cliente y un número aleatorio.
ServerHello: Este mensaje contiene el cifrado que admite y un número aleatorio.
CertificadoServidor: Contiene el certificado del servidor y su clave pública.
ServerHelloHecho: Es el final del ServerHello. Si el cliente recibe una solicitud de su certificado, envía un mensaje ClientCertificate.
IntercambioClaveCliente: Basándose en el número aleatorio del servidor, nuestro cliente genera un secreto premaster aleatorio, lo cifra con el certificado de clave pública del servidor y lo envía al servidor.
Generación de claves: El cliente y el servidor generan un secreto maestro a partir del secreto premaestro e intercambian valores aleatorios.
ChangeCipherSpec: Ahora el cliente y el servidor intercambian su ChangeCipherSpec para empezar a utilizar las nuevas claves para la encriptación.
Cliente finalizado: El cliente envía el mensaje finalizado para confirmar que el intercambio de claves y la autenticación se han realizado correctamente.
Servidor finalizado: Ahora, el servidor envía el mensaje finalizado al cliente para terminar el apretón de manos.

Las aplicaciones y componentes de Kubernetes gestionarán TLS para los desarrolladores, por lo que se requiere una introducción básica; el Capítulo 5 repasa más sobre TLS y Kubernetes.

Como se ha demostrado con nuestro servidor web, cURL, y tcpdump, TCP es un protocolo con estado y fiable para enviar datos entre hosts. Su uso de banderas, combinado con el baile de números de secuencia y acuse de recibo que realiza, permite enviar miles de mensajes a través de redes poco fiables de todo el mundo. Sin embargo, esa fiabilidad tiene un coste. De los 12 paquetes que establecimos, sólo dos eran transferencias de datos reales. Para las aplicaciones que no necesitan fiabilidad, como la voz, la sobrecarga que conlleva UDP ofrece una alternativa. Ahora que entendemos cómo funciona TCP como protocolo fiable orientado a la conexión , repasemos en qué se diferencia UDP de TCP.

UDP

UDP ofrece una alternativa a las aplicaciones que no necesitan la fiabilidad que proporciona TCP. UDP es una opción excelente para aplicaciones que pueden soportar la pérdida de paquetes, como la voz y el DNS. UDP ofrece poca sobrecarga desde el punto de vista de la red, ya que sólo tiene cuatro campos y no hay acuse de recibo de datos, a diferencia de su verborreico hermano TCP.

Está orientado a las transacciones, adecuado para protocolos sencillos de consulta y respuesta como el Sistema de Nombres de Dominio (DNS) y el Protocolo Simple de Gestión de Redes (SNMP). UDP trocea una petición en datagramas, lo que lo hace apto para su uso con otros protocolos de tunelización como una red privada virtual (VPN). Es ligero y sencillo, lo que lo hace ideal para arrancar datos de aplicaciones en el caso del DHCP. La naturaleza sin estado de la transferencia de datos hace que el UDP sea perfecto para aplicaciones, como la voz, que pueden soportar la pérdida de paquetes -¿has oído eso? La falta de retransmisión de UDP también lo convierte en una opción adecuada para la transmisión de vídeo.

Veamos en el reducido número de cabeceras que requiere un datagrama UDP (ver Figura 1-10):

Source port number (2 bytes): Identifica el puerto del remitente de . El host de origen es el cliente; el número de puerto es efímero. Los puertos UDP tienen números bien conocidos, como DNS en 53 o DHCP 67/68.
Destination port number (2 bytes): Identifica el puerto del receptor y es obligatorio.
Length (2 bytes): Especifica la longitud en bytes de la cabecera UDP y de los datos UDP. La longitud mínima es de 8 bytes, la longitud de la cabecera.
Checksum (2 bytes): Se utiliza para la comprobación de errores de la cabecera y los datos. Es opcional en IPv4, pero obligatorio en IPv6, y es todo ceros si no se utiliza.

UDP y TCP son protocolos generales de transporte que ayudan a enviar y recibir datos entre hosts. Kubernetes admite ambos protocolos en la red, y los servicios permiten a los usuarios equilibrar la carga de muchos pods utilizando servicios. También es importante tener en cuenta que, en cada servicio, los desarrolladores deben definir el protocolo de transporte; si no lo hacen, TCP es el que se utiliza por defecto en .

La siguiente capa de la pila TCP/IP es la capa de Internetworking: son paquetes que pueden enviarse a través del globo en las vastas redes que forman Internet. Repasemos cómo se completa.

Red

Todos los datos TCP y UDP se transmiten como paquetes IP en TCP/IP en la capa de Red. La capa de Internet o de Red se encarga de transferir datos entre redes. Los paquetes salientes seleccionan el host del siguiente salto y envían los datos a ese host pasándole los detalles apropiados de la capa de Enlace; los paquetes son recibidos por un host, desencapsulados y enviados al protocolo apropiado de la capa de Transporte. En IPv4, tanto en transmisión como en recepción, IP proporciona fragmentación o desfragmentación de paquetes en función de la MTU; éste es el tamaño máximo del paquete IP.

IP no ofrece ninguna garantía sobre la correcta llegada de los paquetes; dado que la entrega de paquetes a través de redes diversas es intrínsecamente poco fiable y propensa a fallos, esa carga recae en los puntos finales de una ruta de comunicación, y no en la red. Como se ha comentado en el apartado anterior, proporcionar fiabilidad al servicio es una función de la capa de Transporte. Cada paquete tiene una suma de comprobación para garantizar que la información del paquete recibido es exacta, pero esta capa no valida la integridad de los datos. Las direcciones IP de origen y destino identifican los paquetes en la red, de lo que nos ocuparemos a continuación.

Protocolo de Internet

Este paquete todopoderoso se define en el RFC 791 y se utiliza para enviar datos a través de las redes. La Figura 1-11 muestra el formato de la cabecera IPv4.

Veamos los campos de cabecera con más detalle:

Version

El primer campo de cabecera del paquete IP es el campo de versión de cuatro bits. Para IPv4, siempre es igual a cuatro.

Internet Header Length (DIH)

La cabecera IPv4 tiene un tamaño variable debido a la opción del campo 14 opcional.

Type of Service

Originalmente definido como tipo de servicio (ToS) , ahora Punto de Código de Servicios Diferenciados (DSCP), este campo especifica los servicios diferenciados. El DSCP permite que los routers y las redes tomen decisiones sobre la prioridad de los paquetes en momentos de congestión. Tecnologías como la Voz sobre IP utilizan DSCP para garantizar que las llamadas tengan prioridad sobre el resto del tráfico.

Total Length

Es el tamaño total del paquete en bytes.

Identification

Es el campo de identificación y se utiliza para identificar de forma única el grupo de fragmentos de un mismo datagrama IP.

Flags

Se trata de utilizado para controlar o identificar fragmentos. En orden de más significativo a menos:

bit 0: Reservado, puesto a cero
bit 1: No Fragmentar
bit 2: Más fragmentos

Fragment Offset

Especifica el desplazamiento de un fragmento distinto respecto al primer paquete IP no fragmentado. El primer fragmento siempre tiene un desplazamiento de cero.

Time To Live (TTL)

Un campo de 8 bits time to live ayuda a evitar que los datagramas vayan en círculos por la red.

Protocol

Se utiliza en la sección de datos del paquete IP. IANA tiene una lista de números de protocolo IP en el RFC 790; algunos protocolos bien conocidos también se detallan en la Tabla 1-4.

Tabla 1-4. Números de protocolo IP
Número de protocolo	Nombre del protocolo	Abreviatura
1	Protocolo de Mensajes de Control de Internet	ICMP
2	Protocolo de Gestión de Grupos de Internet	IGMP
6	Protocolo de Control de Transmisión	TCP
17	Protocolo de Datagramas de Usuario	UDP
41	Encapsulación IPv6	ENCAP
89	Abrir primero el camino más corto	OSPF
132	Protocolo de transmisión de control de flujo	SCTP

Header Checksum (16 bits)

El campo de suma de comprobación de la cabecera IPv4 se utiliza para comprobar errores. Cuando llega un paquete, un router calcula la suma de comprobación de la cabecera; el router desecha el paquete si los dos valores no coinciden. El protocolo encapsulado debe gestionar los errores en el campo de datos. Tanto UDP como TCP tienen campos de suma de comprobación.

Nota

Cuando el router recibe un paquete, reduce en uno el campo TTL. Como consecuencia, el router debe calcular una nuevasuma de comprobación.

Source address

Es la dirección IPv4 del remitente del paquete.

Nota

La dirección de origen puede ser modificada en tránsito por un dispositivo de traducción de direcciones de red; la NAT se tratará más adelante en este capítulo y ampliamente en el Capítulo 3.

Destination address

Es la dirección IPv4 del receptor del paquete. Al igual que ocurre con la dirección de origen, un dispositivo NAT puede cambiar la dirección IP de destino.

Options

Las posibles opciones de en la cabecera son Copia, Clase de opción, Número de opción, Longitud de opción y Datos de opción.

El componente crucial aquí es la dirección; así es como se identifican las redes. Identifican simultáneamente al host en la red y a toda la red en sí (más sobre esto en "Moverse por la red"). Entender cómo se identifica una dirección IP es fundamental para un ingeniero. Primero repasaremos IPv4 y luego comprenderemos los drásticos cambios de IPv6.

Las direcciones IPv4 están en notación decimal con puntos para nosotros los humanos; los ordenadores las leen como cadenas binarias. La Figura 1-12detalla la notación decimal con puntos y la binaria. Cada sección tiene 8 bits de longitud, con cuatro secciones, lo que hace que la longitud completa sea de 32 bits. Las direcciones IPv4 tienen dos secciones: la primera parte es la red, y la segunda es el identificador único del host en la red.

En el Ejemplo 1-5, tenemos la salida de la dirección IP de un ordenador para su tarjeta de interfaz de red y podemos ver que su dirección IPv4 es 192.168.1.2. La dirección IP también tiene asociada una máscara de subred o máscara de red para saber qué red tiene asignada. La subred del ejemplo es netmask 0xffffff00 en decimal con puntos, que es 255.255.255.0.

Ejemplo 1-5. Dirección IP

○ → ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=400<CHANNEL_IO>
	ether 38:f9:d3:bc:8a:51
	inet6 fe80::8f4:bb53:e500:9557%en0 prefixlen 64 secured scopeid 0x6
	inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active

La subred trae a colación la idea de direccionamiento por clases de . Al principio, cuando se asignaba un rango de direcciones IP, se consideraba que un rango era la combinación de un prefijo de red de 8, 16 o 24 bits junto con un identificador de host de 24, 16 u 8 bits, respectivamente. La Clase A tenía 8 bits para el host, la Clase B 16 y la Clase C 24. A continuación, la Clase A tenía 2 a la potencia de 16 hosts disponibles, 16.777.216; la Clase B, 65.536; y la Clase C, 256. Cada clase tenía una dirección de host, la primera en su límite, y la última se designaba como dirección de difusión. La Figura 1-13 nos lo demuestra.

Nota

Hay otras dos clases, pero no se suelen utilizar en el direccionamiento IP. Las direcciones de clase D se utilizan para la multidifusión IP, y las de clase E se reservan para uso experimental.

El direccionamiento por clases no era escalable en Internet, así que para ayudar a aliviar ese problema de escala, empezamos a rompiendo los límites de las clases mediante rangos de Enrutamiento entre dominios sin clases (CIDR). En lugar de tener las más de 16 millones de direcciones completas en un rango de direcciones de clase, una entidad de internet sólo da una subsección de ese rango. Esto permite efectivamente a los ingenieros de red mover el límite de la subred a cualquier lugar dentro del rango de clase, dándoles más flexibilidad con los rangos CIDR, y ayudando a escalar los rangos de direcciones IP.

En la Figura 1-14, podemos ver el desglose de la dirección IPv4 208.130.29.33 y la jerarquía que crea. El rango CIDR 208.128.0.0/11 se asigna a ARIN desde IANA. Además, ARIN desglosa la subred en subredes cada vez más pequeñas para sus fines, hasta llegar al host único de la red 208.130.29.33/32.

Nota

La coordinación global de la raíz del DNS, el direccionamiento IP y otros recursos del protocolo de Internet corre a cargo de la IANA.

Con el tiempo, sin embargo, incluso esta práctica de de utilizar CIDR para ampliar el alcance de una dirección IPv4 llevó al agotamiento de los espacios de direcciones que podían repartirse, lo que llevó a los ingenieros de redes y al IETF a desarrollar el estándar IPv6.

En la Figura 1-15, podemos ver que IPv6, a diferencia de IPv4, utiliza el hexadecimal para acortar las direcciones con fines de escritura. Tiene características similares a IPv4 en que tiene un prefijo de host y de red.

La diferencia más significativa entre IPv4 e IPv6 es el tamaño del espacio de direcciones. IPv4 tiene 32 bits, mientras que IPv6 tiene 128 bits para producir sus direcciones. Para poner en perspectiva esa diferencia de tamaño, he aquí esas cifras:

IPv4 tiene 4.294.967.296.

IPv6 has 340,282,366,920,938,463,463,374,607,431,768,211,456.

Ahora que entendemos cómo se identifica un host individual en la red y a qué red pertenece, exploraremos cómo esas redes intercambian información entre sí utilizando protocolos de encaminamiento.

Moverse por la red

Los paquetes están direccionados y los datos listos para ser enviados, pero ¿cómo llegan los paquetes desde nuestro host en nuestra red hasta el destinatario alojado en otra red al otro lado del mundo? Ese es el trabajo del encaminamiento. Existen varios protocolos de enrutamiento, pero la Internet de se basa en el Protocolo de Pasarela Fronteriza (BGP), un protocolo de enrutamiento dinámico que se utiliza para gestionar cómo se enrutan los paquetes entre los enrutadores de perímetro de Internet. Es relevante para nosotros porque algunas implementaciones de red de Kubernetes utilizan BGP para enrutar el tráfico de red del clúster entre los nodos. Entre cada nodo de redes separadas hay una serie de routers.

Si nos remitimos al mapa de internet de la Figura 1-1, a cada red de internet se le asigna un número de sistema autónomo (ASN) BGP para designar una única entidad administrativa o corporación que representa una política de enrutamiento común y claramente definida en internet. BGP y los ASN permiten a los administradores de red mantener el control del enrutamiento de su red interna a la vez que anuncian y resumen sus rutas en internet. La Tabla 1-5 enumera los ASN disponibles gestionados por IANA y otras entidades regionales.¹

Tabla 1-5. ASN disponibles
Número	Bits	Descripción	Referencia
0	16	Reservado	RFC 1930, RFC 7607
1-23455	16	ASN públicos
23456	16	Reservado para AS Pool Transición	RFC 6793
23457-64495	16	ASN públicos
64496-64511	16	Reservado para uso en documentación/código de ejemplo	RFC 5398
64512-65534	16	Reservado para uso privado	RFC 1930, RFC 6996
65535	16	Reservado	RFC 7300
65536-65551	32	Reservado para uso en documentación y código de muestra	RFC 4893, RFC 5398
65552-131071	32	Reservado
131072-4199999999	32	ASN públicos de 32 bits
4200000000–4294967294	32	Reservado para uso privado	RFC 6996
4294967295	32	Reservado	RFC 7300

En la Figura 1-16 tenemos cinco ASN, 100-500. Un host en 130.10.1.200 quiere llegar a un host destinado en 150.10.2.300. Una vez que el router local o pasarela por defecto para el host 130.10.1.200 recibe el paquete, buscará la interfaz y la ruta para 150.10.2.300 que BGP ha determinado para esa ruta.

Según la tabla de enrutamiento de la Figura 1-17, el router para el AS 100 determinó que el paquete pertenece al AS 300, y la ruta preferida es la interfaz de salida 140.10.1.1. Y así sucesivamente en AS 200 hasta que el router local para 150.10.2.300 en AS 300 reciba el paquete. El flujo aquí se describe en la Figura 1-6, que muestra el flujo de datos TCP/IP entre redes. Es necesario un conocimiento básico de BGP porque algunos proyectos de redes de contenedores, como Calico, lo utilizan para el enrutamiento entre nodos ; aprenderás más sobre esto en el Capítulo 3.

La Figura 1-17 muestra una tabla de rutas locales . En la tabla de rutas, podemos ver que la interfaz por la que se enviará un paquete se basa en la dirección IP de destino. Por ejemplo, un paquete destinado a 192.168.1.153 se enviará por la pasarela link#11, que es local a la red, y no necesita enrutamiento. 192.168.1.254 es el enrutador de la red conectado a nuestra conexión a Internet. Si la red de destino es desconocida, se envía por la ruta por defecto.

Nota

Como en todos los SO Linux y BSD, puedes encontrar más información sobre en la página man de netstat(man netstat). El netstat de Apple deriva de la versión BSD. Puedes encontrar más información en el Manual de FreeBSD.

Los routers se comunican continuamente en Internet, intercambiando información de rutas e informándose mutuamente de los cambios en sus respectivas redes. BGP se encarga de gran parte de ese intercambio de datos , pero los ingenieros de redes y los administradores de sistemas pueden utilizar el protocolo ICMP y las herramientas de línea de comandos ping para comprobar la conectividad entre hosts y routers.

ICMP

ping es una utilidad de red que utiliza ICMP para probar la conectividad entre hosts de la red. En el Ejemplo 1-6, vemos una prueba exitosa de ping a 192.168.1.2, con cinco paquetes que devuelven todos una respuesta eco ICMP.

Ejemplo 1-6. Petición eco ICMP

○ → ping 192.168.1.2 -c 5
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.052 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.089 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.142 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.050 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.050 ms
--- 192.168.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.050/0.077/0.142/0.036 ms

El Ejemplo 1-7 muestra un intento fallido de ping que agota el tiempo intentando llegar al host 1.2.3.4. Los routers y los administradores utilizarán ping para probar las conexiones, y también es útil para probar la conectividad de los contenedores. Aprenderás más sobre esto en los Capítulos 2 y 3, cuando implementemos nuestro servidor web Golang mínimo en un contenedor y un pod.

Ejemplo 1-7. Fallo en la solicitud eco ICMP

○ → ping 1.2.3.4 -c 4
PING 1.2.3.4 (1.2.3.4): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- 1.2.3.4 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

Al igual que con TCP y UDP, en los paquetes ICMP hay cabeceras, datos y opciones ; se repasan aquí y se muestran en laFigura 1-18:

Type: Tipo ICMP.
Code: Subtipo ICMP.
Checksum: Suma de comprobación de Internet para la comprobación de errores, calculada a partir de la cabecera ICMP y los datos con valor 0 sustituyen a este campo.
Rest of Header (campo de 4 bytes): El contenido varía en función del tipo y código ICMP.
Data: Los mensajes de error ICMP contienen una sección de datos que incluye una copia de toda la cabecera IPv4.

Nota

Algunos consideran que ICMP es un protocolo de la capa de Transporte, ya que no utiliza TCP ni UDP. Según el RFC 792, define ICMP, que proporciona funciones de enrutamiento, diagnóstico y error para IP. Aunque los mensajes ICMP se encapsulan dentro de datagramas IP, el procesamiento de ICMP se considera y suele implementarse como parte de la capa IP. ICMP es el protocolo IP 1, mientras que TCP es el 6 y UDP es el 17.

El valor identifica los mensajes de control en el campo Type. El campo code proporciona información adicional sobre el contexto del mensaje. Puedes encontrar algunos números de tipo ICMP estándar en la Tabla 1-6.

Tabla 1-6. Números comunes de tipo ICMP
Número	Nombre	Referencia
0	Eco respuesta	RFC 792
3	Destino inalcanzable	RFC 792
5	Redirige	RFC 792
8	Eco	RFC 792

Ahora que nuestros paquetes saben de qué redes proceden y a cuáles van destinados, es el momento de empezar a enviar físicamente esta solicitud de datos a través de la red; esto es responsabilidad de la capa de Enlace.

Capa de enlace

La solicitud HTTP se ha dividido en segmentos, se ha direccionado para su enrutamiento a través de Internet, y ahora sólo queda enviar los datos a través del cable. La capa de Enlace de la pila TCP/IP comprende dos subcapas: la subcapa de Control de Acceso al Medio (MAC) y la subcapa de Control de Enlace Lógico (LLC) . Juntas, desempeñan las capas OSI 1 y 2, Enlace de datos y Física. La capa de Enlace es responsable de la conectividad con la red local. La primera subcapa, MAC, es responsable del acceso al medio físico. La capa LLC tiene el privilegio de gestionar el control de flujo y los protocolos de multiplexación sobre la capa MAC para transmitir y de demultiplexación al recibir, como se muestra en la Figura 1-19. La norma 802.3 del IEEE, Ethernet, define los protocolos de envío y recepción de tramas para encapsular paquetes IP. IEEE 802 es la norma general para LLC (802.2), inalámbrica (802.11) y Ethernet/MAC (802.3).

Como las demás PDU, Ethernet tiene una cabecera y unos pies de página, como se muestra en la Figura 1-20.

Repasémoslos en detalle:

Preamble (8 bytes): Una cadena alternada de unos y ceros indica al host receptor que está entrando una trama.
Destination MAC Address (6 bytes): Dirección MAC de destino; el destinatario de la trama Ethernet.
Source MAC Address (6 bytes): Dirección MAC de origen; el origen de la trama Ethernet.
VLAN tag (4 bytes): Etiqueta 802.1Q opcional para diferenciar el tráfico en los segmentos de red.
Ether-type (2 bytes): Indica qué protocolo está encapsulado en la carga útil de la trama.
Payload (longitud variable): El paquete IP encapsulado.
Frame Check Sequence (FCS) o Cycle Redundancy Check (CRC) (4 bytes): La secuencia de comprobación de tramas (FCS) es una comprobación de redundancia cíclica (CRC) de cuatro octetos que permite detectar datos corruptos dentro de la trama completa tal y como se reciben en el lado receptor. El CRC forma parte del pie de la trama Ethernet.

La Figura 1-21 muestra que Las direcciones MAC se asignan al hardware de interfaz de red en el momento de su fabricación. Las direcciones MAC tienen dos partes: el identificador de unidad de organización (OUI) y las partes específicas de la NIC.

La trama indica al destinatario de la capa de Red el tipo de paquete. La Tabla 1-7 detalla los protocolos comunes manejados. En Kubernetes, nos interesan sobre todo los paquetes IPv4 y ARP. Recientemente se ha introducido IPv6 en Kubernetes en la versión 1.19.

Tabla 1-7. Protocolos comunes EtherType
Tipo de éter	Protocolo
0x0800	Protocolo de Internet versión 4 (IPv4)
0x0806	Protocolo de Resolución de Direcciones (ARP)
0x8035	Protocolo de Resolución Inversa de Direcciones (RARP)
0x86DD	Protocolo de Internet versión 6 (IPv6)
0x88E5	Seguridad MAC (IEEE 802.1AE)
0x9100	trama etiquetada VLAN (IEEE 802.1Q) con doble etiquetado

Cuando un paquete IP llega a su red de destino, la dirección IP de destino se resuelve con el Protocolo de Resolución de Direcciones para IPv4 (Protocolo de Descubrimiento de Vecinos en el caso de IPv6) en la dirección MAC del host de destino. El Protocolo de Resolución de Direcciones debe gestionar la traducción de direcciones de direcciones de Internet a direcciones de capa de enlace en redes Ethernet. La tabla ARP sirve para realizar búsquedas rápidas de los hosts conocidos, de modo que no tenga que enviar una solicitud ARP por cada trama que el host quiera enviar. El Ejemplo 1-8 muestra la salida de una tabla ARP local. Todos los dispositivos de la red mantienen una caché de direcciones ARP con este fin.

Ejemplo 1-8. Tabla ARP

○ → arp -a
? (192.168.0.1) at bc:a5:11:f1:5d:be on en0 ifscope [ethernet]
? (192.168.0.17) at 38:f9:d3:bc:8a:51 on en0 ifscope permanent [ethernet]
? (192.168.0.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]

La Figura 1-22 muestra el intercambio entre hosts de la red local. El navegador realiza una solicitud HTTP de un sitio web alojado en el servidor de destino. A través del DNS, determina que el servidor tiene la dirección IP 10.0.0.1. Para seguir enviando la petición HTTP, también necesita la dirección MAC del servidor. En primer lugar, el ordenador solicitante consulta una tabla ARP en caché para buscar en 10.0.0.1 cualquier registro existente de la dirección MAC del servidor. Si encuentra la dirección MAC, envía al enlace una trama Ethernet con la dirección de destino de la dirección MAC del servidor, que contiene el paquete IP dirigido a 10.0.0.1. Si la caché no ha encontrado 10.0.0.2, el ordenador solicitante debe enviar un mensaje de solicitud ARP de difusión con la dirección MAC de destino FF:FF:FF:FF:FF:FF, que es aceptado por todas las máquinas de la red local, solicitando una respuesta para 10.0.0.1. El servidor responde con un mensaje de respuesta ARP que contiene su dirección MAC e IP. Como parte de la respuesta a la solicitud, el servidor puede insertar una entrada para solicitar la dirección MAC del ordenador en su tabla ARP para su uso futuro. El ordenador solicitante recibe y almacena en caché la información de respuesta en su tabla ARP y ya puede enviar los paquetes HTTP.

Esto también trae a colación un concepto crucial de en las redes locales, los dominios de difusión. Todos los paquetes en el dominio de difusión reciben todos los mensajes ARP de los hosts. Además, todas las tramas se envían a todos los nodos de la difusión, y el anfitrión compara la dirección MAC de destino con la suya propia. Descartará las tramas no destinadas a sí mismo. A medida que crecen los hosts en la red, también lo hace el tráfico de difusión.

Podemos utilizar tcpdump para ver todas las peticiones ARP que se producen en la red local, como en elEjemplo 1-9. La captura de paquetes detalla los paquetes ARP; el tipo de Ethernet utilizado, Ethernet (len 6); y el protocolo de nivel superior, IPv4. También incluye quién solicita la dirección MAC de la dirección IP , Request who-has 192.168.0.1 tell 192.168.0.12.

Ejemplo 1-9. ARP `tcpdump`

○ → sudo tcpdump -i en0 arp -vvv
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:26:25.906401 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:27.954867 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:29.797714 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:31.845838 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:33.897299 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:35.942221 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:37.785585 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:39.628958 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.13, length 28
17:26:39.833697 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:41.881322 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:43.929320 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:45.977691 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:47.820597 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
^C
13 packets captured
233 packets received by filter
0 packets dropped by kernel

Para segmentar aún más la red de capa 2, los ingenieros de red pueden utilizar el etiquetado de red de área local virtual (VLAN) . Dentro de la cabecera de la trama Ethernet hay una etiqueta VLAN opcional que diferencia el tráfico en la LAN. Resulta útil utilizar las VLAN para dividir las LAN y gestionar las redes en el mismo conmutador o en distintos conmutadores del campus de la red. Los routers entre VLAN filtran el tráfico de difusión, permiten la seguridad de la red y alivian su congestión. Son útiles para el administrador de red para esos fines, pero los administradores de red de Kubernetes pueden utilizar la versión extendida de la tecnología VLAN conocida como LAN extensible virtual (VXLAN).

La Figura 1-23 muestra cómo una VXLAN es una extensión de una VLAN que permite a los ingenieros de redes encapsular tramas de capa 2 en paquetes UDP de capa 4. Una VXLAN aumenta la escalabilidad de hasta 16 millones de redes lógicas y permite la adyacencia de capa 2 a través de redes IP. Esta tecnología se utiliza en las redes Kubernetes para producir redes superpuestas, sobre las que aprenderás más en capítulos posteriores.

Ethernet también detalla las especificaciones del medio por el que se transmiten las tramas, como el par trenzado, el cable coaxial, la fibra óptica, la conexión inalámbrica u otros medios de transmisión aún por inventar, como la red de rayos gamma que alimenta el Comunicador Instantáneo Philotic Parallax.² Ethernet define incluso los protocolos de codificación y señalización utilizados en el cable; esto queda fuera del alcance de lo que proponemos.

La capa de Enlace tiene otros muchos protocolos implicados desde la perspectiva de la red. Al igual que las capas tratadas anteriormente, sólo hemos tocado la superficie de la capa Enlace. Hemos limitado este libro a los detalles necesarios para una comprensión básica de la capa Enlace para el modelo de red Kubernetes .

Revisando nuestro servidor web

Nuestro viaje a través de todas las capas de TCP/IP ha concluido. La Figura 1-24 esboza todas las cabeceras y pies de página que cada capa del modelo TCP/IP produce para enviar datos a través de Internet.

Repasemos el recorrido de y recordemos de nuevo lo que ocurre ahora que entendemos cada capa en detalle.El Ejemplo 1-10 muestra de nuevo nuestro servidor web, y el Ejemplo 1-11 muestra la solicitud cURL para él de antes en el capítulo.

Ejemplo 1-10. Servidor web mínimo en Go

package main

import (
	"fmt"
	"net/http"
)

func hello(w http.ResponseWriter, _ *http.Request) {
	fmt.Fprintf(w, "Hello")
}

func main() {
	http.HandleFunc("/", hello)
	http.ListenAndServe("0.0.0.0:8080", nil)
}

Ejemplo 1-11. Solicitud del cliente

○ → curl localhost:8080 -vvv
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sat, 25 Jul 2020 14:57:46 GMT
< Content-Length: 5
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact
Hello* Closing connection 0

Comenzamos con el servidor web esperando una conexión en el Ejemplo 1-10. cURL solicita a el servidor HTTP en 0.0.0.0 en el puerto 8080. cURL determina la dirección IP y el número de puerto a partir de la URL y procede a establecer una conexión TCP con el servidor. Una vez establecida la conexión, mediante un apretón de manos TCP, cURL envía la solicitud HTTP. Cuando se inicia el servidor web, se crea un socket de 8080 en el servidor HTTP, que coincide con el puerto TCP 8080; lo mismo se hace en el lado del cliente cURL con un número de puerto aleatorio. A continuación, esta información se envía a la capa de red , donde las direcciones IP de origen y destino se adjuntan a la cabecera IP del paquete. En la capa de Enlace de Datos del cliente , la dirección MAC de origen de la NIC se añade a la trama Ethernet. Si la dirección MAC de destino es desconocida, se realiza una petición ARP para encontrarla. A continuación, la NIC se utiliza para transmitir las tramas Ethernet al servidor web.

Cuando el servidor web recibe la solicitud, crea paquetes de datos que contienen la respuesta HTTP. Los paquetes se envían de vuelta al proceso cURL enrutándolos a través de Internet utilizando la dirección IP de origen del paquete de solicitud. Una vez recibido por el proceso cURL, el paquete se envía desde el dispositivo a los controladores. En la capa de Enlace de Datos, se elimina la dirección MAC. En la capa de Protocolo de Red , se verifica la dirección IP y luego se elimina del paquete. Por esta razón, si una aplicación necesita acceder a la IP del cliente, es necesario almacenarla en la capa de Aplicación; el mejor ejemplo en este caso son las solicitudes HTTP y la cabecera X-Forwarded-For. Ahora se determina el socket a partir de los datos TCP y se elimina. A continuación, el paquete se reenvía a la aplicación cliente que crea ese socket. El cliente lo lee y procesa los datos de respuesta. En este caso, el ID del socket era aleatorio, correspondiente al proceso cURL. Todos los paquetes se envían a cURL y se juntan en una respuesta HTTP. Si hubiéramos utilizado la opción de salida -O, se habría guardado en un archivo; de lo contrario, cURL envía la respuesta a la salida estándar del terminal.

Uf, qué bocado, ¡50 páginas y 50 años de redes condensados en dos párrafos! Los conceptos básicos de redes que hemos revisado son sólo el principio, pero son conocimientos necesarios si quieres ejecutar clústeres y redes Kubernetes a escala.

Conclusión

Las transacciones HTTP modeladas en este capítulo ocurren cada milisegundo, globalmente, todo el día en la red de Internet y del centro de datos. Este es el tipo de escala que las API de las redes Kubernetes ayudan a los desarrolladores a abstraer en un simple YAML. Comprender la escala del problema es nuestro primer paso para dominar la gestión de una red Kubernetes. Tomando nuestro sencillo ejemplo del servidor web Golang y aprendiendo los primeros principios de las redes, puedes empezar a gestionar los paquetes que entran y salen de tus clústeres.

Hasta ahora, hemos cubierto lo siguiente:

Historia del trabajo en red
Modelo OSI
TCP/IP

A lo largo de este capítulo, hemos tratado muchas cosas relacionadas con las redes , pero sólo las necesarias para aprender a utilizar las abstracciones de Kubernetes. Hay varios libros de O'Reilly sobre TCP/IP; TCP/IP Network Administration de Craig Hunt (O'Reilly) es una gran lectura en profundidad sobre todos los aspectos de TCP.

Hemos hablado de cómo evolucionaron las redes, hemos recorrido el modelo OSI, lo hemos trasladado a la pila TCP/IP y, con esa pila, hemos completado un ejemplo de solicitud HTTP. En el próximo capítulo, veremos cómo se implementa esto para el cliente y el servidor con la red Linux.

¹ "Números de Sistema Autónomo (AS)". IANA.org. 2018-12-07. Consultado el 2018-12-31.

² En la película El Juego de Ender, utilizan la red Ansible para comunicarse a través de la galaxia de forma instantánea. Comunicador Instantáneo Parallax Filótico es el nombre oficial de la red Ansible.

Get Redes y Kubernetes now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Capítulo 1. Introducción a las redes

Historia de las redes

Figura 1-1. Barrett Lyon, "Cartografía de Internet", 2003

Nota

Modelo OSI

Figura 1-2. Capas del modelo OSI

Nota

TCP/IP

Figura 1-3. Modelo OSI comparado con TCP/IP

Aplicación

HTTP

Nota

Ejemplo 1-1. Servidor web mínimo en Go

Nota

Ejemplo 1-2. Solicitud del cliente

Transporte

TCP

Nota

Figura 1-4. Cabecera de segmento TCP

Figura 1-5. Flujo de datos tcp/ip

Apretón de manos TCP

Figura 1-6. Intercambio TCP a tres bandas

Figura 1-7. Diagrama de transición de estados TCP

Ejemplo 1-3. Estados de la conexión TCP

tcpdump

Figura 1-8. Captura de paquetestcpdump

Nota

Ejemplo 1-4. tcpdump

TLS

Figura 1-9. Intercambio TLS

UDP

Figura 1-10. Cabecera UDP

Red

Protocolo de Internet

Figura 1-11. Formato de la cabecera IPv4

Nota

Nota

Figura 1-12. Dirección IPv4

Ejemplo 1-5. Dirección IP

Nota

Figura 1-13. Clase IP

Figura 1-14. Ejemplo de CIDR

Nota

Figura 1-15. Dirección IPv6

Moverse por la red

Figura 1-16. Ejemplo de enrutamiento BGP

Figura 1-17. Tabla de enrutamiento local

Nota

ICMP

Ejemplo 1-6. Petición eco ICMP

Ejemplo 1-7. Fallo en la solicitud eco ICMP

Figura 1-18. Cabecera ICMP

Nota

Capa de enlace

Figura 1-19. Ejemplo de demultiplexación Ethernet

Figura 1-20. Encabezado y pie de página de Ethernet

Figura 1-21. Dirección MAC

Ejemplo 1-8. Tabla ARP

Figura 1-22. Petición ARP

Ejemplo 1-9. ARP tcpdump

Figura 1-23. Paquete VXLAN

Revisando nuestro servidor web

Figura 1-24. Vista completa de la PDU TCP/IP

Ejemplo 1-10. Servidor web mínimo en Go

Ejemplo 1-11. Solicitud del cliente

Conclusión

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly

Figura 1-8. Captura de paquetes`tcpdump`

Ejemplo 1-4. `tcpdump`

Ejemplo 1-9. ARP `tcpdump`