TCP

1. Introducción.

El protocolo Transmission Control Protocol o Protocolo de Transporte (TCP) se encuenta en la capa 4, sobre la capa de red o capa 3.

• Existe SOLO en los extremos de una comunicación.
• TCP se utiliza para la comunicación entre aplicaciones.
• TCP tiene dos tipos Unidad de Datos : UDP Y TCP, son similares, pero UDP menos fiable que TCP.
• Es un protocolo que funciona mediante la conexión mutua entre cliente y servidor o sea que es ORIENTADO A LA CONEXIÓN.
• Toma los Datagramas de IP y los Ordena para entregar a las aplicaciones.
• Monitorea el flujo de los datos y permite evitar la saturación de la red.
• Entrega los datos al protocolo IP en forma de segmentos de longitud variable.
• Permite circular de forma simultánea a la información proveniente de diferentes fuentes.
• Capa Transporte ofrece servicios a las aplicaciones y toma servicios de capa de red.

2. UDP User Datagram Protocol

UDP es un protocolo estándar con STD número 6.

UDP se describe en RFC 768: Protocolo de datagramas de usuario.

Su estado es estándar y casi todos las aplicaciones destinadas a la transferencia de pequeñas unidades de datos o aquellas que pueden permitirse perder una pequeña cantidad de datos (como la transmisión multimedia) incluirá UDP.

UDP es básicamente una interfaz de aplicación para IP. No agrega confiabilidad, control de flujo, o recuperación de errores a IP.

Simplemente sirve como multiplexor/demultiplexor para enviar y recibir datagramas, usando puertos para dirigir los datagramas.

obtenido de: https://www.redbooks.ibm.com/redbooks/pdfs/gg243376.pdf

UDP proporciona un mecanismo para que una aplicación envíe un datagrama a otra. La capa UDP puede considerarse extremadamente delgada y, en consecuencia, muy eficiente, pero requiere que la aplicación asuma la responsabilidad por el error recuperación y así sucesivamente.
Las aplicaciones que envían datagramas a un host necesitan identificar un objetivo que sea más específico que la dirección IP, porque los datagramas normalmente se dirigen a ciertos procesos y no al sistema como un todo. UDP proporciona esto mediante el uso de puertos.

Se puede observar:

1. Es un header muy sencillo.
2. El checksum se calcula SOBRE el header NO sobre los Datos.
3. Tiene información del puerto de destino y de origen.
4. NO tiene ID o Numeración.

3. TCP Transmission Control Protocol

• TCP es un protocolo estándar con STD número 7.
  

TCP se describe en RFC 793 como Protocolo de Control de Transmisión. Específicamente incluye

• recuperación de errores
• control de flujo y confiabilidad.

TCP es un protocolo orientado a la conexión, a diferencia de UDP, que no tiene conexión.

La mayoría de los protocolos de aplicación de usuario, utilizan TCP. Los dos procesos a comunicarse entre sí a través de una conexión TCP (InterProcess Comunicación, o IPC), como se muestra en la Figura

En la figura, los procesos 1 y 2 se comunican a través de una conexión TCP transportada por datagramas IP. 

Como se señaló anteriormente, el propósito principal de TCP es proporcionar un circuito lógico confiable ( Virtual ) o servicio de conexión entre pares de procesos.

No asume confiabilidad de los protocolos de nivel inferior (como IP), por lo que TCP debe garantizar esto por sí mismo.

TCP se puede caracterizar por las siguientes facilidades que proporciona para las aplicaciones que lo utilizan:

Transmisión de transferencia de datos

Desde el punto de vista de la aplicación, TCP transfiere una flujo contiguo de bytes a través de la red. La aplicación no tiene  que molestarse en cortar los datos en bloques básicos o datagramas. TCP hace esto agrupando los bytes en segmentos TCP, que se pasan a la Capa IP para la transmisión al destino. Además, el propio TCP decide cómo segmentar los datos, y puede reenviarlos a su propia conveniencia.

Confiabilidad

TCP asigna un número de secuencia a cada byte transmitido, y espera un  reconocimiento positivo (ACK) de la capa TCP receptora. Si el ACK no se recibe dentro de un intervalo de tiempo de espera, los datos se retransmiten.
Debido a que los datos se transmiten en bloques (segmentos TCP), solo la secuencia del número del primer byte de datos en el segmento se envía al host de destino.

El TCP receptor usa los números de secuencia para reorganizar los segmentos cuando llegan fuera de orden, y para eliminar segmentos duplicados.

Control de flujo

El TCP receptor, al enviar un ACK al remitente, también indica al remitente el número de bytes que puede recibir (más allá del último segmento TCP recibido) sin causar overrun y overflow en su buffers de memoria internos. Se envía un ACK en forma indica el nro. secuencia más alta puede recibir sin problemas, sin llenar su buffer. Este mecanismo también se conoce como un mecanismo de ventana deslizante (visto en control de flujo).

Multiplexación

Se logra mediante el uso de puertos, al igual que con UDP.

Conexiones lógicas

la confiabilidad y los mecanismos de control de flujo descritos aquí requieren que TCP inicialice y mantenga cierta información de estado para cada flujo de datos. La combinación de este estado, incluidos los sockets, números de secuencia y tamaños de ventana, se denomina conexión lógica. Cada conexión se identifica de forma única por el sockets utilizados para  el envío y recepción.

Full duplex

TCP provee un vínculo en ambas direcciones para el flujo de datos.

3.1. Control de Flujo (informativo)

El mecanismo de Ventana Deslizante es el usado en TCP, con una pequeña variante, primero recordaremos el control de flujo por ventana deslizante y luego vermemos la modificación que usa TCP.

En Ventana Deslizante se envía un conjunto de paquetes respetando las siguientes reglas:

• El remitente puede enviar todos los paquetes dentro de número de paquetes indicados en el ancho de la ventana sin recibir un ACK, pero debe iniciar un temporizador de tiempo de espera para cada uno de ellos.
• El receptor debe acusar recibo de cada paquete recibido, indicando el número de secuencia del último paquete bien recibido.
• El remitente desliza la ventana en cada ACK recibido.

3.2. TCP Header (informativo)

Puerto de origen: El número de puerto de origen de 16 bits, utilizado por el receptor para respuesta.
Puerto de destino:  El número de puerto de destino de 16 bits.
Número de secuencia: El número de secuencia del primer byte de datos en este
segmento. Si se establece el bit de control SYN, la secuencia número es el número de secuencia inicial (n) y el primero el byte de datos es n+1.
Número de acuse de recibo: Si el bit de control ACK está establecido, este campo contiene el valor de el siguiente número de secuencia que el receptor está esperando
para recibir.
Data Offset:  El número de palabras de 32 bits del  Header de  TCP. Eso permite saber donde comienzan los datos.
Reservado:  Seis bits reservados para uso futuro; deben ser cero.
URG: Este bit indica que este segmento es significativo.
ACK:  Indica que el campo de reconocimiento es significativo en
este segmento.
PUSH : Función de empuje PSH.
RST: Resetea la conexión

SYN : Sincroniza los números de secuencia.
END: No hay mas datos para enviar.

Window size: Tamaño de ventana, Se utiliza en segmentos ACK. Especifica el número de datos EN BYTES, empezando por el indicado en el campo de número de acuse de recibo que el receptor (el remitente de este segmento) está dispuesto a aceptar.

Checksum : El complemento a uno de 16 bits del complemento a uno suma de todas las palabras de 16 bits en un pseudoencabezado, el encabezado TCP  y los datos TCP. Mientras se computa el checksum, el propio campo de checksum se considera cero. El pseudoencabezado es el mismo que usa UDP para calcular la suma de control. Es un pseudo-encabezado IP como el que se muestra en la figura, solo utilizado para el cálculo de la suma de comprobación.

Urgent Pointer: Apunta al primer octeto de datos que sigue a los datos urgentes.
Solo significativo cuando el bit de control URG está establecido.

Options:  Al igual que en el caso de las opciones de datagrama IP, las opciones pueden ser:
– Un solo byte que contiene el número de opción
– Una opción de longitud variable en el siguiente formato como se muestra en la Figura siguiente.

Maximum segment size option: Este campo se puede observar en las capturas de paquetes que hacemos con Wireshark. Esta opción sólo se utiliza durante el establecimiento de la conexión (bit de control SYN establecido) y se envía desde
el lado que va a recibir datos para indicar el longitud máxima del segmento que puede manejar. Si esta opción no se utiliza, se permite cualquier tamaño de segmento.

Existen varias opciones mas que no serán vistas en este curso. Para mas detalles se puede leer en:

https://www.redbooks.ibm.com/redbooks/pdfs/gg243376.pdf   a partir  de pagina 157

3.3. Establecimiento de Sesión TCP (informativo)

Como sabemos TCP es orientado a la conexión, por lo tanto ANTES de trasmitir DEBE establecer una Sesión, algo parecido a lo que sucede al usar un Teléfono, solo que en este caso  se debe establecer una conexión entre dos procesos.

Uno de los procesos (generalmente el servidor) emite un pasivo llamada OPEN, la otra una llamada OPEN activa.

La llamada OPEN pasiva permanece inactivo hasta que otro proceso intente conectarse a él mediante un OPEN activo.

Todo este proceso se conoce como un HANDSHAKE (apretón de manos) de tres vías. Tenga en cuenta que los segmentos TCP intercambiados incluyen los números de secuencia iniciales de ambos lados, para ser utilizado en transferencias de datos posteriores.
El cierre de la conexión se hace implícitamente enviando un segmento TCP con el FIN
bit (sin más datos) establecido.

Debido a que la conexión es full-duplex (es decir, hay dos flujos de datos independientes, uno en cada dirección), el segmento FIN solo cierra la transferencia de datos en una dirección.

El otro proceso enviará ahora los datos restantes que aún tiene que transmitir y también termina con un segmento TCP donde el bit FIN está establecido.

La conexión se elimina (información de estado en ambos lados) después de que el flujo de datos se cierra en ambas direcciones.

Veamos otro ejemplo gráfico:

3.4. Finalización de la Sesión TCP (informativo)

Para cerrar la conexión se debe establecer el señalador de control FIN (Finalizar) en el encabezado del segmento.

Para finalizar todas las sesiones TCP de una vía, se utiliza un enlace de dos vías, que consta de un segmento FIN y un segmento ACK.

Por lo tanto, para terminar una conversación simple admitida por TCP, se requieren cuatro intercambios para finalizar ambas sesiones.

Nota: En esta explicación, los términos cliente y servidor se utilizan como referencia por facilidad, pero el proceso de finalización lo pueden iniciar dos hosts cualquiera que completen la sesión:

1. Cuando el cliente no tiene más datos para enviar en el stream, envía un segmento con el señalador FIN establecido.

2. El servidor envía un ACK para acusar de recibo el FIN para terminar la sesión de cliente a servidor.

3. El servidor envía un FIN al cliente para terminar la sesión de servidor a cliente.

4. El cliente responde con un ACK para dar acuse de recibo del FIN desde el servidor.

Cuando el cliente que finaliza la sesión no tiene más datos que transferir, establece el señalador FIN en el encabezado de un segmento. Luego, el servidor finaliza la conexión y envía un segmento normal que contiene datos con el señalizador ACK establecido utilizando el número de acuse de recibo, confirmando así que se han recibido todos los bytes de datos. Cuando se dio acuse de recibo de todos los segmentos, la sesión se cierra.

La sesión en la otra dirección se cierra con el mismo proceso. El receptor indica que no existen más datos para enviar estableciendo el señalizador FIN en el encabezado del segmento enviado al origen. Un acuse de recibo devuelto confirma que todos los bytes de datos se recibieron y que la sesión, a su vez, finalizó.

Half-Close.

Cuando un proceso llama a shutdown con un segundo argumento de 1, se llama medio cierre. TCP envía un FIN pero permite que el proceso continúe recibiendo en el socket.

3.5. TCP Timers (Informativo)

TCP, mantiene 7 (siete ) Timers o temporizadores por cada conexión.

1) Un temporizador de establecimiento de conexión se inicia cuando se envía un SYN para establecer una nueva conexión. Si no se recibe una respuesta en 75 segundos, se cancela el establecimiento de la conexión.

2) Se establece un temporizador de retransmisión cuando TCP envía datos. Si los datos no son reconocidos por el otro extremo cuando expira este temporizador, TCP retransmite los datos. El valor de este temporizador (es decir, el cantidad de tiempo que TCP espera un acuse de recibo) se calcula dinámicamente, en función del tiempo de ida y vuelta medido por TCP para esta conexión, y basado en la cantidad de veces que esto segmento de datos ha sido retransmitido. El temporizador de retransmisión está limitado por TCP para ser entre 1 y 64 segundos.

3) Se establece un temporizador de ACK retrasado cuando TCP recibe datos que deben ser reconocidos, pero no es necesario ser reconocido inmediatamente. En cambio, TCP espera hasta 200 ms antes de enviar el ACK. Si, durante este período de tiempo de 200 ms, TCP tiene datos para enviar en esta conexión, el pendiente el acuse de recibo se envía junto con los datos (llamado piggybacking).

4) Se establece un temporizador persistente cuando el otro extremo de una conexión anuncia una ventana de 0, deteniendo TCP del envío de datos. Dado que los anuncios de ventana del otro extremo no se envían de manera confiable (es decir, no se reconocen los ACK, solo se reconocen los datos), existe la posibilidad de que la actualización futura de la ventana, que permite que TCP envíe algunos datos, se puede perder. Por lo tanto, si TCP tiene datos para enviar y el otro extremo anuncia una ventana de 0, el temporizador de persistencia se establece y cuando caduca, se envía 1 byte de datos para ver si la ventana se ha abierto. Como el temporizador de retransmisión, el valor del temporizador persistente se calcula dinámicamente, en función del tiempo de ida y vuelta. El valor de esto está limitado por TCP entre 5 y 60 segundos.

5) El proceso puede configurar un temporizador de actividad mediante la opción de socket SO_KEEPALIVE. Si la conexión está inactiva durante 2 horas, el temporizador de actividad expira y se envía un segmento especial a el otro extremo, obligándolo a responder. Si se recibe la respuesta esperada, TCP sabe que el otro host todavía está activo y TCP no volverá a sondearlo hasta que la conexión esté inactiva durante otras 2 horas. Otras respuestas a la sonda keepalive le dicen a TCP que el otro host se bloqueó y reiniciado Si no se recibe respuesta a un número fijo de sondeos de actividad, TCP asume que el otro extremo se ha estrellado, aunque no puede distinguir si el otro extremo está caído (es decir, se bloqueó y aún no se ha reiniciado) y una falta temporal de conectividad con el otro extremo (es decir, un enrutador intermedio o una línea telefónica está caído).

El Keep Alive Timer es un temporizador que se utiliza para evitar conexiones ociosas durante demasiado tiempo. Una vez pasa este temporizador se envían cada 75 segundos sondas, si no se responde a 10 sondas se asume que el otro lado está caído finaliza la conexión.

6) Un temporizador FIN_WAIT_2. Cuando una conexión pasa del estado FIN_WAIT_1 al estado Estado FIN_WAIT_2 (Figura 24.15) y la conexión no puede recibir más datos

(lo que implica el proceso llamado cierre, en lugar de aprovechar el medio cierre de TCP con apagado), este temporizador está configurado en 10 minutos. Cuando este temporizador expira, se restablece a 75 segundos, y cuando caduca por segunda vez, se interrumpe la conexión. El propósito de esto temporizador es para evitar dejar una conexión en el estado FIN_WAIT_2 para siempre, si el otro extremo nunca envía un FIN. 

7) Un temporizador TIME_WAIT, a menudo llamado temporizador 2MSL. El término 2MSL significa el doble del MSL, el vida útil máxima del segmento definida en la Sección 24.8. Se establece cuando una conexión entra en el Estado TIME_WAIT (Figura 24.15), es decir, cuando la conexión está cerrada activamente. El temporizador está configurado para 1 minuto,cuando la conexión ingresa a TIME_WAIT estado y cuando caduca, el bloque de control TCP y PCB de Internet se eliminan, lo que permite que
par de sockwets sean reutilizables.

Aparte de estos temporizadores , tiene 2(dos) funciones de Timers.

• una se llama cada 200 ms (el temporizador rápido)
• la otra cada 500 ms (el temporizador lento).

El temporizador ACK retrasado es diferente de los otros seis: cuando el tiempo ACK retrasado, está configurado para una conexión, significa que se debe enviar un ACK retrasado la próxima vez que el temporizador de 200 ms expira (es decir, el tiempo transcurrido está entre 0 y 200 ms). Los otros seis temporizadores se disminuyen cada 500 ms, y solo cuando el contador llega a 0 tiene lugar la acción correspondiente.

¿Sería capaz de contar cuantos temporizadores tiene en su equipo TCP en este momento?

Consejo

 Linux puede usar el comando netstat -nt  , o netstat -at

• -n: no se resolverán nombres
• -t : protocolo tcp
• a: Show both listening and non-listening sockets

Problemas: Timeout y RTT.

• retraso de propagación (mas importante en WAN)
• retraso de procesamiento
• retraso de cola
• retraso de codificación.

3.6. Arranque lento y Evitar Congestión (informativo)

Slow Start and Congestion Avoidance

Las implementaciones antiguas de TCP inician una conexión con el remitente inyectando múltiples segmentos en la red, hasta el tamaño de ventana anunciado por el receptor.
Aunque esto está bien cuando los dos hosts están en la misma LAN, si hay enrutadores
y enlaces más lentos entre el emisor y el receptor, pueden surgir problemas.

Si  los enrutadores intermedios no pueden manejarlo, los paquetes se descartan y la retransmisión los resultados y el rendimiento se degradan.
El algoritmo para evitar esto se llama SLOW START.

Este trabaja observando la velocidad a la que se deben inyectar nuevos paquetes en la red es la velocidad a la que se reciben los acuses de recibos por el otro extremo.

Slow start agrega otra ventana al TCP del remitente: la ventana de congestión, llamada cwnd.

Cuando una nueva conexión se establece con un host en otra red, la ventana de congestión se inicializa a un segmento (por ejemplo, el tamaño del segmento anunciado por el otro extremo, o el predeterminado, normalmente 536 o 512).

Cada vez que se recibe un ACK, la ventana de congestión aumenta en un segmento. El emisor puede transmitir el valor más bajo de la ventana de congestión o la ventana anunciada. La ventana de congestión es el control de flujo impuesto por el emisor, mientras que la ventana anunciada es un control de flujo impuesto por el receptor.

El  primero se basa en la evaluación del remitente de la congestión de red percibida;
el último está relacionado con la cantidad de espacio de búfer disponible en el receptor para esta conexión.

El remitente comienza transmitiendo un segmento y esperando su ACK. Cuando
que se recibe ACK, la ventana de congestión se incrementa de uno a dos, y
se pueden enviar dos segmentos. Cuando se reconoce cada uno de esos dos segmentos, la ventana de congestión se incrementa a cuatro. Esto proporciona un crecimiento exponencial,aunque no es exactamente exponencial, porque el receptor puede retrasar sus ACK, normalmente envía un ACK por cada dos segmentos que recibe.
En algún momento, la capacidad de la red IP (por ejemplo, enlaces WAN más lentos)
se puede alcanzar, y un enrutador intermedio comenzará a descartar paquetes. Este
le dice al remitente que su ventana de congestión se ha vuelto demasiado grande.

En este punto se dispara el mencanismo de Evitar Congestión.

Congestion avoidance

La suposición del algoritmo es que la pérdida de paquetes causada por daños es muy
pequeño (mucho menos del 1%). Por lo tanto, la pérdida de un paquete indica congestión en algún lugar de la red entre el origen y el destino.

La  pérdida de paquetes se puede producir:

• Se produce un tiempo de espera.
• Se reciben ACK duplicados.

La prevención de congestión y el slow start son algoritmos independientes con  diferentes objetivos, pero cuando ocurre una congestión, TCP debe ralentizar su tasa de transmisión de paquetes en la red e invocar un inicio lento para que las cosas vuelvan a funcionar.
En la práctica, se implementan juntos y desde el protocolo se requieren que se mantengan dos variables para cada conexión:

• Una ventana de congestión, cwnd
• Un tamaño de umbral de inicio lento, ssthresh

Estos trabajan de la siguiente manera ( LO QUE SIGUE ES A MODO INFORMATIVO)

1. La inicialización de una conexión determinada establece cwnd =1 en un segmento y ssthresh= 65535 bytes.
2. La rutina de salida TCP nunca envía más que el valor más bajo de cwnd o el
ventana anunciada del receptor.
3. Cuando se produce una congestión (tiempo de espera o ACK duplicado), la mitad del actual el tamaño de la ventana se guarda en ssthresh. Además, si la congestión se indica por un tiempo de espera, cwnd se establece en uno en el  segmento.
4. Cuando el otro extremo reconozca nuevos datos, aumenta cwnd, pero
la forma en que aumenta depende de si TCP está realizando un slow start o
Congestion avoidance. Si cwnd es menor o igual que ssthresh, TCP está en
comienzo lento; de lo contrario, TCP está evitando la congestión.

Esto permite que se usen mecanismos para evitar la congestión en distintas situaciones de una misma conexión.

3.7. Silly window avoidance y Nagle (informativo)

Silly window

Problema (1982)
Si el receptor publica pequeños incrementos en la ventana el transmisor pierde tiempo enviando segmentos pequeños.

Solución
El receptor no debe publicar pequeños incrementos de la ventana
Incrementar la ventana en min(MSS,RecvBuffer/2)

En LAN:

En WAN:

El síndrome de ventana tonta (SWS) es un problema en las redes informáticas causado por un control de flujo TCP mal implementado.

Puede surgir un problema grave en la operación de ventana deslizante cuando el programa de aplicación de envío crea datos lentamente, el programa de aplicación de recepción consume datos lentamente, o ambos.

Si un servidor con este problema no puede procesar todos los datos entrantes, solicita que sus clientes reduzcan la cantidad de datos que envían a la vez (la configuración de la ventana en un paquete TCP).

Si el servidor sigue sin poder procesar todos los datos entrantes, la ventana se vuelve cada vez más pequeña, a veces hasta el punto de que los datos transmitidos son más pequeños que el encabezado del paquete, lo que hace que la transmisión de datos sea extremadamente ineficiente. El nombre de este problema se debe a que el tamaño de la ventana se reduce a un valor "tonto".

Dado que hay una cierta cantidad de sobrecarga asociada con el procesamiento de cada paquete, el aumento en el número de paquetes significa una mayor sobrecarga para procesar una cantidad de datos decreciente. El resultado final es una  caida de la conexión.

Un método heurístico en el que el TCP debe permitir que la aplicación de envío realice llamadas de "escritura" y recopile los datos transferidos en cada llamada antes de transmitirlos a un segmento grande. El TCP de envío retrasa el envío de segmentos pequeños hasta que pueda acumular cantidades razonables de datos, lo que se conoce como agrupamiento.

Algoritmo de Nagle

4. Puertos y Sockets

Esta sección presenta los conceptos de puerto y socket, que son necesarios para determinar qué proceso local en un host determinado se comunica realmente con qué proceso, en qué host remoto, usando qué protocolo.

Si esto suena confuso, considere los siguientes puntos:
A un proceso de solicitud se le asigna un número de identificador de proceso (ID de proceso), que es probable que sea diferente cada vez que se inicie ese proceso. Los ID de proceso difieren entre las plataformas del sistema operativo, por lo que no son uniforme.
Un proceso de servidor puede tener múltiples conexiones a múltiples clientes a la vez, por lo tanto, los identificadores de conexión simples no son únicos.

Un socket define un vínculo unívoco entre dos procesos.

El concepto de puertos y sockets proporciona una manera de identificar de manera uniforme y única las conexiones y el programas y anfitriones que participan en ellos, independientemente del proceso específico
identificaciones.

Socket <=> Circuito Virtual

4.1. Puertos

Registrado

4.2. Socket

El socket es una de varias interfaces de programación de aplicaciones para protocolos de comunicación 

Diseñado para ser una interfaz de programación de comunicación genérica.

Las API de socket se introdujeron por primera vez en 4.2 Berkeley Software Distribution (BSD).
Aunque no se ha estandarizado, la API de socket de Berkeley se ha convertido en un Abstracción estándar de la industria facto para la implementación de socket TCP/IP de red.

• Un socket es un tipo especial de identificador de archivo, que utiliza un proceso para solicitar servicios de red del sistema operativo.
• Una dirección de socket son tres datos : <protocolo, dirección local, puerto local>
  Por ejemplo, en la suite TCP/IP (versión 4): <tcp, 192.168.14.234, 8080>
• Permite una comunicación o intercambio, es el vínculo de comunicación entre dos procesos. Locales o Distantes.
• Una asociación es la tupla de 5 que especifica completamente los dos procesos que
  comprenden una conexión: <protocolo, dirección local, puerto local, dirección extranjera, puerto extranjero>
  • En la suite TCP/IP (versión 4), la siguiente podría ser una asociación válida:
    <tcp, 192.168.14.234, 1500, 192.168.44, 22>.
• Una media asociación es una de las siguientes, cada una de las cuales especifica la mitad de una
  conexión:
  <protocolo, dirección-local, proceso-local>
  O:
  <protocolo, dirección extranjera, proceso extranjero>.
• La media asociación también se denomina socket o dirección de transporte. Eso es un socket es un punto final para la comunicación que se puede nombrar y direccionar en una red.

5. TCP vs. UDP

TCP vs. UDP

6. Tcpdump

Tcpdump (y su port a Windows, Windump) son programas cuya utilidad principal es analizar el tráfico que circula por la red.

Se apoya en la librería de captura pcap, la cual presenta una interfaz uniforme y que esconde las   peculiaridades de cada sistema operativo a la hora de capturar tramas de red. Para seguir el manual es necesario unos conocimientos basicos del protocolo TCP/IP, remitiéndome al TCP/IP Illustrated, Volumen 1 de Stevens, para quien esté interesado.

Aunque viene incluido con la mayoría de las distribuciones de Linux, sus fuentes pueden encontrarse en www.tcpdump.org

El port completo para Windows, tanto de las librerias como del tcpdump puede encontrarse en la web de la Politécnica de Torino. Es un simple binario, que necesita tener instalado el port de las pcap para windows para funcionar.

Lo primero que debemos averiguar cuando estamos usando el tcpdump, es las interfaces que queremos escuchar. Por defecto cuando se ejecuta sin parámetros, en los Linux se pone a escuchar en la eth0, mientras que en Windows hay que especificarla la interfaz donde quiere escuchar.

Para averiguar la interfaces en cualquier Unix recurrimos al comando ifconfig -a el cual nos da una lista de las interfaces que tenemos, así como sus parametros de configuración.

Podemos ver que existen numerosos parámetros para el comando tcpdump (la imagen es un printscreen de un Linux).

Si tomamos wlp1s0 para capturar, con el  argumento -i de interface y ejecutamos como superusuario veremos algo como:

Con el argumento -i any, capturamos de TODAS las interfaces.

Cuando capturamos tráfico de red con tcpdump, es posible que no nos interese resolver los nombres de los hosts, sino que directamente nos muestre las direcciones IP. Para hacer esto, podemos poner:

Si queremos guardar la captura en un archivo, para posteriormente abrirlo con un analizador de paquetes como WireShark, o para su posterior análisis, debemos poner la siguiente orden:

Este archivo se puede abrir con el Wireshark y se vería como :

Si quisieramos captura el tráfico de una subred 192.168.25.0/24 de la interface wlp1s0 :

También podemos capturar por origen de IP

o por destino de IP.

https://kripkit.com/tcpdump/

https://www.marindelafuente.com.ar/tutorial-de-tcpdump/

7. Whois

Es un protocolo TCP basado en petición/respuesta para efectuar consultas en una base de datos que permite determinar el propietario de un nombre de dominio o una dirección IP en Internet. 

El servicio WHOIS es un sistema distribuido de consultas de información sobre recursos de Internet.

El servicio WHOIS que proporciona LACNIC permite realizar consultas de información sobre los números de sistemas autónomos (ASN) y bloques de direcciones IP asignados por LACNIC. Adicionalmente, permite obtener información asociada a estos recursos de Internet, como los datos de las organizaciones y de sus puntos de contacto.

¿Cómo realizar la consulta?

Las consultas WHOIS se pueden realizar bien a través de una utilidad para línea de comandos (whois) , o bien a través de una multitud de páginas web públicas que permiten realizar estas consultas ( http://whois.lacnic.net y otras) . Estas páginas siguen dependiendo internamente del protocolo WHOIS para conectar a un servidor WHOIS y hacer las peticiones. 

Vamos a ver primero desde la línea de comandos.

¿Por que si busco fio.unam.edu.ar, no aparece en los registros?

Introducción

El sistema WHOIS fue originalmente descrito por la RFC 812, más tarde sustituida por la RFC 3912 WHOIS Protocol Specification. Como fue descrito en esos documentos, fue especificado como una herramienta para la consulta de los puntos de contacto de las organizaciones conectadas en aquella época a ARPANET. El sistema no incluye la especificación de un formato a utilizar en las respuestas a esas consultas. Por esta razón, los diferentes sistemas WHOIS presentan la información en diferentes formatos.

La información proporcionada por el WHOIS de LACNIC está organizada en un conjunto de atributos y valores separados por ":"

Al realizar una consulta de recursos, ya sea ASN o bloque IP, se obtienen en la respuesta el siguiente conjunto de atributos:

    "owner:" Nombre de la organización que tiene asignado el recurso;
    "ownerid:" Código de la organización en la base de datos de LACNIC;
    "responsable:" Nombre de la persona de contacto o grupo responsable en la organización;
    "address:" Dirección postal de la organización;
    "country:" Código del país de la organización;
    "phone:" Número del teléfono de la organización;
    "owner-c:" Código del punto de contacto de la organización;
    "tech-c:" Código del punto de contacto técnico para el bloque IP;
    "routing-c:" Código del punto de contacto técnico para el ASN;
    "abuse-c:" Código del punto de contacto para cuestiones de abuso;
    "created:" Fecha de asignación del recurso de Internet;
    "changed:" Fecha de la última modificación de la información del recurso Internet.

Posteriormente, se presenta la información del punto de contacto asociado a ese recurso de Internet. Los atributos presentados son los siguientes:

    "nic-hdl:" Código del punto de contacto;
    "person:" Nombre de la persona o grupo que representa ese punto de contacto;
    "e-mail:" Dirección de correo electrónico para ese punto de contacto;
    "address:" Dirección postal del punto de contacto;
    "country:" Código de país del punto de contacto;
    "phone:" Número de teléfono del punto de contacto;
    "created:" Fecha de creación de esa información en la base de datos;
    "changed:" Fecha de la última modificación de la información de ese punto de contacto.

Cuando la consulta es acerca de un bloque IP, además de la mencionada, es posible que haya información acerca de la delegación DNS, cuyos atributos son los siguientes:

    "inetrev:" Indica el bloque total o parcial que fue delegado;
    "nserver:" Nombre del servidor DNS;
    "nsstat:" Estado de ese servidor DNS;
    "nslastaa:" Fecha más reciente en la que se verificó un estado "ok" para ese servidor.

Veamos algunos ejemplos. En sitios Webs.

IPv6 Unam:  https://iplocation.io/ip-whois-lookup/2803:70e0:101:4000:: 

8. Netstat (network statistics)

A su vez, esta herramienta crea una lista con todos los puertos TCP y UDP que están abiertos en el ordenador.

El comando "netstat" también permite a su vez obtener estadísticas de numerosos protocolos (Ethernet, IPv4, TCP, UDP, ICMP y IPv6).

usage: netstat [-vWeenNcCF] [<Af>] -r         netstat {-V|--version|-h|--help}
       netstat [-vWnNcaeol] [<Socket> ...]
       netstat { [-vWeenNac] -i | [-cnNe] -M | -s [-6tuw] }

        -r, --route              muestra la tabla de ruteado
        -i, --interfaces         muestra la tabla de interfaz
        -g, --groups             muestra la pertenencia a grupos multicast
        -s, --statistics         muestra las estadísticas de la red (como SNMP)
        -M, --masquerade         muestra las conexiones enmascaradas

        -v, --verbose descripción amplia
        -W, --wide               don't truncate IP addresses
        -n, --numeric no se resolverán nombres
        --numeric-hosts          no resuelve nombres de anfitrión
        --numeric-ports          no resuelve por nombres de puerto
        --numeric-users          no resuelve por nombres de usuario
        -N, --symbolic           resuelve nombres hardware
        -e, --extend             muestra otra/más información
        -p, --programs           muestra el nombre PID/Programa para los sockets
        -o, --timers             muestra temporizadores
        -c, --continuous         listado continuo

        -l, --listening         muestra los sockets a la escucha de servidores
        -a, --all                display all sockets (default: connected)
        -F, --fib                muestra la base de información hacia adelante (predeterminado)
        -C, --cache              display routing cache instead of FIB
        -Z, --context            display SELinux security context for sockets

  <Socket>={-t|--tcp} {-u|--udp} {-U|--udplite} {-S|--sctp} {-w|--raw}
           {-x|--unix} --ax25 --ipx --netrom
  <AF>=Use '-6|-4' o '-A <af>' o '--<af>'; por defecto: inet
 

Veamos algúnos ejemplos.

9. Links

En material que se presenta se obtuvo de los siguientes sitios:

https://ayudaleyprotecciondatos.es/2021/07/29/protocolo-tcp/

https://www.redbooks.ibm.com/redbooks/pdfs/gg243376.pdf

https://www.science.smith.edu/~jcardell/Courses/EGR328/Readings/TCPIPTutorial.pdf

https://neo.lcc.uma.es/evirtual/cdd/tutorial/transporte/udp.html

https://neo.lcc.uma.es/evirtual/cdd/tutorial/transporte/tcp.html

10. Puertos TCP

• Puerto 0: TCP en realidad no usa el puerto 0 para la comunicación de red, pero este puerto es bien conocido por los programadores de redes. Los programas de socket TCP usan el puerto 0 por convención para solicitar que el sistema operativo elija y asigne un puerto disponible. Esto evita que un programador tenga que elegir («codificar») un número de puerto que podría no funcionar bien para la situación.
• Puerto 21: El puerto 21 por norma general se usa para las conexiones a servidores FTP en su canal de control, siempre que no hayamos cambiado el puerto de escucha de nuestro servidor FTP o FTPES.
• Puerto 22: Por normal general este puerto se usa para conexiones seguras SSH y SFTP, siempre que no hayamos cambiado el puerto de escucha de nuestro servidor SSH.
• Puerto 23: Telnet, sirve para establecer conexión remotamente con otro equipo por la línea de comandos y controlarlo. Es un protocolo no seguro ya que la autenticación y todo el tráfico de datos se envía sin cifrar.
• Puerto 25:  El puerto 25 es usado por el protocolo SMTP para él envió de correos electrónicos, también el mismo protocolo puede usar los puertos 26 y 2525.
• Puerto 53: Es usado por el servicio de DNS, Domain Name System.
• Puerto 80: Este puerto es el que se usa para la navegación web de forma no segura HTTP.
• Puerto 101: Este puerto es usado por el servicio Hostname y sirve para identificar el nombre de los equipos.
• Puerto 110: Este puerto lo usan los gestores de correo electrónico para establecer conexión con el protocolo POP3.
• Puerto 123: Es un puerto utilizado por el NTP o Protocolo de tiempo en red, es uno de los protocolos más importantes a nivel de redes, ya que se utiliza para mantener los dispositivos sincronizados en Internet. Podemos incluso considerarlo vital, ya que, debido a la precisión de los relojes, facilitan mucho la interrelación de problemas de un dispositivo a otro.
• Puertos 137, 138 y 139: Estos puertos son utilizados por el Protocolo NetBIOS o NBT, lo habréis escuchado mucho si trabajáis en redes en Windows, ya que ha sido durante mucho tiempo el protocolo TCP principal para interconectar los equipos que están bajo este sistema operativo, lógicamente se utiliza en la mayoría de las veces en combinación con el IP utilizando así la famosa combinación TCP/IP que todos conocemos en este mundillo.
• Puerto 143: El puerto 143 lo usa el protocolo IMAP que es también usado por los gestores de correo electrónico.
• Puerto 179: Es el puerto utilizado por el Protocolo de puerta de enlace fronteriza o BGP por sus siglas en inglés, es otro protocolo muy importante a nivel de redes, ya que, en su mayoría, es utilizado por los proveedores de servicio para ayudar a mantener las enormes tablas de enrutamiento que existen hoy en día. También es utilizado para procesar las inmensas cantidades de tráfico en las redes, por lo que es uno de los protocolos más utilizados en las redes públicas.
• Puerto 194: Aunque herramientas como aplicaciones de mensajería para teléfonos inteligentes y servicios como Slack y Microsoft Teams han reducido el uso de Internet Relay Chat, IRC sigue siendo popular entre personas de todo el mundo. Por defecto, IRC usa el puerto 194.
• Puerto 443: Este puerto es también para la navegación web, pero en este caso usa el protocolo HTTPS que es seguro y utiliza el protocolo TLS por debajo.
• Puerto 445: Este puerto es compartido por varios servicios, entre el más importante es el Active Directory.
• Puerto 587: Este puerto lo usa el protocolo SMTP SSL y, al igual que el puerto anterior sirve para el envío de correos electrónicos, pero en este caso de forma segura.
• Puerto 591: Es usado por Filemaker en alternativa al puerto 80 HTTP.
• Puerto 853: Es utilizado por DNS over TLS.
• Puerto 990: Si utilizamos FTPS (FTP Implícito) utilizaremos el puerto por defecto 990, aunque se puede cambiar.
• Puerto 993: El puerto 993 lo usa el protocolo IMAP SSL que es también usado por los gestores de correo electrónico para establecer la conexión de forma segura.
• Puerto 995: Al igual que el anterior puerto, sirve para que los gestores de correo electrónico establezcan conexión segura con el protocolo POP3 SSL.
• Puerto 1194: Este puerto está tanto en TCP como en UDP, es utilizado por el popular protocolo OpenVPN para las redes privadas virtuales.
• Puerto 1723: Es usado por el protocolo de VPN PPTP.
• Puerto 1812: se utiliza tanto con TCP como con UDP, y sirve para autenticar clientes en un servidor RADIUS.
• Puerto 1813: se utiliza tanto con TCP como con UDP, y sirve para el accounting en un servidor RADIUS.
• Puerto 2049: es utilizado por el protocolo NFS para el intercambio de ficheros en red local o en Internet.
• Puertos 2082 y 2083: es utilizado por el popular CMS cPanel para la gestión de servidores y servicios, dependiendo de si se usa HTTP o HTTPS, se utiliza uno u otro.
• Puerto 3074: Lo usa el servicio online de videojuegos de Microsoft Xbox Live.
• Puerto 3306: Puerto usado por las bases de datos MySQL.
• Puerto 3389: Es el puerto que usa el escritorio remoto de Windows, muy recomendable cambiarlo.
• Puerto 4662 TCP y 4672 UDP: Estos puertos los usa el mítico programa eMule, que es un programa para descargar todo tipo de archivos.
• Puerto 4899: Este puerto lo usa Radmin, que es un programa para controlar remotamente equipos.
• Puerto 5000: es el puerto de control del popular protocolo UPnP, y que por defecto, siempre deberíamos desactivarlo en el router para no tener ningún problema de seguridad.
• Puertos 5400, 5500, 5600, 5700, 5800 y 5900: Son usados por el programa VNC, que también sirve para controlar equipos remotamente.
• Puertos 6881 y 6969: Son usados por el programa BitTorrent, que sirve para e intercambio de ficheros.
• Puerto 8080: es el puerto alternativo al puerto 80 TCP para servidores web, normalmente se utiliza este puerto en pruebas.
• Puertos 51400: Es el puerto utilizado de manera predeterminada por el programa Transmission para descargar archivos a través de la red BitTorrent.
• Puerto 25565: Puerto usado por el famoso videojuego Minecraft.

11. Puertos UDP

• Puerto 23: Este puerto es usado en dispositivos Apple para su servicio de Facetime.
• Puerto 53: Es utilizado para servicios DNS, este protocolo permite utilizar tanto TCP como UDP para la comunicación con los servidores DNS.
• Puerto 67: Los servidores del Protocolo de configuración dinámica de host usan el puerto UDP 67 para escuchar las solicitudes.
• Puerto 68: Por su parte los clientes DHCP se comunican en el puerto UDP 68.
• Puerto 69: Este puerto es utilizado sobre todo por el Protocolo trivial de transferencia de archivos o TFTP, dicho protocolo es el que nos ofrece un método para transferir nuestros archivos, pero sin tantos requisitos para el establecimiento de sesiones como podría por ejemplo utilizar el FTP. Cabe destacar que al utilizar UDP en lugar de TCP, este protocolo no puede garantizar de ninguna forma que nuestros archivos hayan sido transferidos de manera correcta, por lo que el dispositivo al que lo estamos enviando, debe tener la capacidad de verificar que dicha transferencia se ha realizado adecuadamente.
• Puerto 88: El servicio de juegos en red de Xbox utiliza varios números de puerto diferentes, incluido el puerto UDP 88.
• Puerto 161: De manera predeterminada, el Protocolo simple de administración de redes usa el puerto UDP 161 para enviar y recibir solicitudes en la red que se administra.
• Puerto 162: Se utiliza el puerto UDP 162 como predeterminado para recibir capturas SNMP desde dispositivos administrados.
• Puerto 500: este puerto es utilizado por el protocolo de VPN IPsec, concretamente se usa por ISAKMP para la fase 1 del establecimiento de la conexión con IPsec.
• Puerto 514: Es usado por Syslog, el log del sistema operativo.
• Puerto 1194: este puerto es el predeterminado del protocolo OpenVPN, aunque también se puede utilizar el protocolo TCP. Lo más normal es usar UDP 1194 porque es más rápido a la hora de conectarnos y también de transferencia, obtendremos más ancho de banda.
• Puerto 1701: Es usado por el protocolo de VPN L2TP.
• Puerto 1812: se utiliza tanto con TCP como con UDP, y sirve para autenticar clientes en un servidor RADIUS.
• Puerto 1813: se utiliza tanto con TCP como con UDP, y sirve para el accounting en un servidor RADIUS.
• Puerto 4500: este puerto también es utilizado por el protocolo de VPN IPsec, se utiliza este puerto para que el funcionamiento de la NAT sea perfecto. Este puerto se utiliza en la fase 2 del establecimiento IPsec, pero también tenemos que tener abierto el puerto UDP 500.
• Puerto 51871: es utilizado por el protocolo de VPN Wireguard de manera predeterminada.