Ir a la página principal Ir a "esquema OSI" Ir a "conceptos basicos de una red"
TCP/IP fue desarrollado por DARPA (Defense Advanced Research Projects Agency) y fue usado por primera vez en la red ARPANET precursora de INTERNET. Si bien TCP/IP es considerado un conjunto de protocolos y no un modelo en sí mismo, lo que tiene de común con OSI es que se trata de una estructura abierta y no propietaria. Para tener todo el conocimiento sobre TCP/Ip, aquellos que deseen profundizar pueden ir a:
http://www.rfc-es.org/rfc/rfc0793-es.txt
que contiene la traducción completa del documento RFC793 perteneciente a la IETF (Internet Engineering Task Force)
Una RFC (Request For Comments) es en realidad un conjunto de normas que definen recomendaciones y protocolos de Internet. El material no se agota en esta RFC sino que hay ampliaciones en la RFC1122 que corrige algunos errores anteriores y habla de la implementación. Para leer este material podemos ir a:
http://www.rfc-es.org/rfc/rfc1780-es.txt
También es conveniente leer la RFC3390 y aún así puede que haya cosas que no se entiendan para lo que existen buenos foros, pero todo esto solo en caso que se desee ampliar conceptos y que por supuesto escapan a la intención de este curso.
Pero vamos por partes, comencemos por TCP (Transmision Control Protocol) o Protocolo de Transmisión en castellano. Este protocolo no es nuevo y es el que permite que exista Internet. Data de 1973 y trabaja en conjunto con IP (Internet Protocol). Sirve para garantizar que los datos entregados han llegado a destino sin errores y contiene mecanismos que nos permiten evitar el congestionamiento
Puerto Origen |
Puerto Destino |
||
Número de Secuencia |
|||
Número de Acuse de recibo |
|||
Hlen |
Reservado |
Code Bits |
Ventana |
Suma de Verificación |
Puntero de Urgencia |
||
Opciones IP |
Relleno |
||
Datos |
|||
Datos |
|||
------ |
|||
Este encabezado muestra cómo se disponen todos los datos en TCP, ya algunas cosas podemos ir comprendiendo, veamos:
Los primeros campos son los de número de puerto de conexión, tanto de origen como de destino, luego vienen los números de secuencia de los datos que salen . Esto es importante ya que van a viajar diferentes tramas y si no hubiera número de secuencia no se sabría cómo volver a armarlos. Tomemos en cuenta que en la red las tramas no siempre llegan en orden. Es común que algunas tramas tomen un camino diferente y lleguen en diferente orden. El número de acuse de recibo de los datos ya recibidos nos permite saber si han sido recibidos todas las tramas o algunas se perdieron y deben volver a enviarse.
Un campo importante es el CODE BITS. En el que se activan o desactivan los flags del segmento TCP.
URG : Flag urgente.
SYN: Solicitud de sincronización.
RST: Reset. Final de conexión.
ACK: Acuse de recibo.
FIN: El emisor ha llegado al final de su flujo de octetos.
PSH: Empujar el paquete (priorizar).
Para saber si alguna trama (o todas) han llegado corruptos (tomemos en cuenta que el ruido puede producir problemas con las tramas), se utiliza el cheksum o suma de verificación. En una forma especial se produce una suma de todos los datos enviados que da un número único. Este número, debe ser el mismo que el enviado por TCP desde origen. Si fuera diferente, la trama en cuestión debe volver a enviarse porque seguramente está corrupta.
Tcp envía los datos en forma binaria en segmentos de octetos. Normalmente TCP toma la decisión de enviar los datos en el momento apropiado, salvo que se trate de un requerimiento llamado push en cuyo caso los envía inmediatamente y nada queda almacenado en bufer. ¿qué significa esto último? En condiciones normales loas tramas se guardan en una memoria intermedia (bufer) hasta recibir una confirmación de la recepción.
La memoria intermedia sirve también para ordenar paquetes que lleguen fuera de orden. Al mantenerlos en memoria puede ordenarlos y así reconstruir el mensaje original.Existe además un temporizador que da un tiempo a cada mensaje, vencido el mismo todos los paquetes son descartados y deben volver a enviarse. También es posible que por algún error una trama llegue duplicada, en cuyo caso TCP es capaz de desechar uno de los dos paquetes duplicados. Luego de haber recibido en forma correcta todas las tramas, Tcp de destino envía un Acuse de recibo (ACK) para indicar que todo llegó bien al origen del mensaje.
Para el control de Flujo se utilizan los ACK (Acknowledgement), y sirve para que el receptor "le diga" al emisor cuanta información puede enviar sin saturarle. O sea, que si por algún motivo, la placa de red o la computadora que recibe es lenta, la computadora de origen deberá frenar el envío de información de acuerdo con las posibilidades del receptor. Esto no es del todo así, ya que la memoria intermedia (bufer) que tienen las placas de red, pueden guardar info y de esta manera, en cierta forma independizar la velocidad, pero esto por supuesto es relativo y depende mucho del tamaño de la memoria intermedia.
Tcp puede establecer varias conexiones simultáneas con diferentes programas o con sesiones diferentes del mismo programa. Ejemplo: con nuestro navegador web pedimos a Internet una página de un sitio, pero mediante una nueva pestaña y al mismo tiempo pedimos otra página de otro sitio. En este caso estamos usando diferentes sesiones y TCP, mediante su multiplexado puede darnos esas páginas al mismo tiempo. Para poder hacer esto se utiliza, junto a la dirección IP un puerto para cada comunicación y por lo tanto diferente entre diferentes sesiones, o programas que se utilicen. Cuando hablamos del conjunto -dirección IP, puerto- hablamos de socket.
Una conexión TCP ha sido creada cuando un socket del equipo origen se conecta con un socket del equipo destino, este proceso contiene tres pasos y es conocido como three-way handshake, lo que sería algo así como "darse la mano de tres vias".
Lo de tres vias viene porque primero se envía desde el origen un ACK, luego un Syn+ACK y finalmente un nuevo ACK.
Si bien es posible comenzar la conexión entre receptor y emisor en el mismo momento es más común que al menos uno de los lados ya tenga un socket abierto y a la espera, en forma pasiva o a la escucha. Cuando del otro lado se requiere una apertura activa, se envía un paquete SYN inicial. Del lado servidor se comprueba que el puerto esté abierto y si no es así, se envía un paquete de respuesta con el bit RST activado para denegar el intento de conexión.
Por el contrario si la conexión es posible se envía un paquete SYN/ACK para validar la conexión. Luego del otro lado se vuelve a enviar un paquete ACK para completar la negociación y establecer en forma práctica la conexión. Existe un número de secuencia de cada lado y esto sirve para evitar establecer conexiones falsas (spoofing) como veremos más adelante.
Versión |
Len |
Tipo de Servicio |
Longitud total |
||
Identificación |
Flags (Banderas) |
Fragment Offset |
|||
TTL |
Protocolo |
Header checksum |
|||
Dirección IP de origen |
|||||
Dirección IP de destino |
|||||
Opciones |
Padding |
||||
Datos |
|||||
Datos |
|||||
--- |
|||||
| Versión |
4 bits |
Versión del protocolo. Aunque ya se usa la versión Ip v6, la mayoría de las redes funcionan todavía con IP v4. |
| Len |
4 bits |
Longitud de la cabecera del datagrama |
| Tipo de servicio |
8 bits |
Tipo de Servicio |
| Longitud total |
16 bits |
Longitud total del datagrama (max 65535 bytes) |
| Identificación |
16 bits |
Para identificación del mensaje en el destino |
| Flags |
3 bits |
Indica la fragmentación |
| Fragment offset |
13 bits |
Posición del fragmento dentro del datagrama original |
| TTL |
8 bits |
Tiempo de vida de cada paquete |
| Protocolo |
8 bits |
Indica el protocolo utilizado p.ej.TCP o UDP, etc. |
| Header checksum |
16 bits |
Suma de comprobación, para detección de errores en la cabecera del datagrama |
| Dirección IP origen |
32 bits |
Dirección IP de origen |
| Dirección IP destino |
32 bits |
Dirección IP de destino |
| Opciones |
16 bits |
Opciones para desarrollos futuros |
| Padding |
variable |
Campo de relleno para que el datagrama sea múltiplo de 32 bits |
Cuando un datagrama debe adaptarse a la tranmisión por un medio físico se subdivide en varios fragmentos. El MTU (Maximun Transmission Unit) o tamaño máximo de transmisión es calculado para determinar el tamaño de cada datagrama. Esto permite a la capa física tomar el tamaño adecuado para el mejor desempeño.
La primera etapa es la fragmentación, efectuada en el equipo emisor, partiendo los datagramas, mientras que la segunda etapa es el reensamble que toma lugar en el equipo receptor y significa que todos los datagramas fragmentados se vuelven a unir para dar lugar al datagrama original. Todos estos fragmentos se reensamblan a partir de un bufer o memoria intermedia que controla la no duplicación de los paquetes y cuenta con un TTL que determina el tiempo en el cual si los datagramas no llegaron deben volver a transmitirse.
La fragmentación utiliza los campos Identificación, un flag para indicar que se trata de un fragmento y finalmente el campo Fragment Object.
Un mensaje puede llegar a destino en forma directa (dentro de la misma red) o indirecta (cuando el destino está en otra red). La forma indirecta exige el uso de saltos intermedios. El origen entrega los datagramas a algún hardware intermedio, que a su vez lo direcciona a un nuevo salto, tantas veces como sea necesario hasta llegar al destino.