Hola lectores, sin mas que decir continuamos con el tema.
Una vez definido el direccionamiento de redes y ordenadores en Internet,
mencionaremos la existencia de los servicios de DNS (Domain Name Server).
Debido a que es más fácil recordar un nombre (Centro de cálculo de la Universidad
Autónoma de Barcelona, cc.uab.es) que una dirección numérica (158.109.0.4), se
crearon los servidores de nombres (DNS), que son las máquinas encargadas de
transformar un nombre en su dirección correspondiente.
1.2 El protocolo IP versión 4
El protocolo IP (Internet Protocol) es la pieza fundamental en la que se sustenta el sistema TCP/IP y por tanto todo el funcionamiento de Internet. Su especificación está recogida en [RFC791].
La unidad de datos del protocolo IP es el datagrama (ver figura 1-4), cuyo tamaño máximo es de 65535 bytes (64K).
El protocolo IP facilita un sistema sin conexión (connectionless) y no fiable (unreliable) de entrega de datagramas entre dos ordenadores cualesquiera conectados a Internet.
IP da un servicio de entrega basado en el mejor intento (best effort). Esto implica que cuando hay algún funcionamiento anómalo de Internet, como podría ser un router colapsado, se contempla un sistema muy simple de tratamiento de errores. Este mecanismo de control de errores viene regulado por el protocolo ICMP (Internet Control Message Protocol).
En nuestro caso, el router colapsado descartaría el datagrama y enviaría un mensaje de error ICMP al ordenador de origen sin encargarse de la retransmisión del datagrama, lo que no implica fiabilidad.
Además, no mantiene ningún tipo de información referente al estado de las conexiones. Cada datagrama es encaminado de forma independiente, lo que le convierte en un protocolo sin conexión.
Debido a estas particulares características, puede pasar que se pierdan datagramas y/o que estos no lleguen en orden. De esta manera, cualquier fiabilidad que se necesite,deberá ser realizada por las capas superiores (TCP...).
La estructura de un datagrama IP está dividida en bloques de 32 bits (4 bytes). El datagrama IP se transmite enviando primero el bit 0, luego el bit 1, 2, 3... y así sucesivamente hasta finalizar el datagrama.
Este orden se denomina network byte order. Es muy importante conocer este orden de transmisión de la información, puesto que los diferentes ordenadores tienen diferentes sistemas de almacenamiento de bits en memoria.
El formato little endian, consiste en almacenar los bits en orden inverso al network byte order (usando por ejemplo en los procesadores Intel), mientras que la otra posibilidad se denomina big endian (usado por ejemplo en los procesadores Motorola).
La versión (4 bits), sirve para identificar a que versión específica (RFC) hace
referencia el formato del datagrama. Esta información sólo es utilizada por los routers y
capa IP de origen y final del datagrama. Esto permite la coexistencia de diferentes
versiones del protocolo IP de una forma transparente al usuario. La versión actual es la
4 (conocida también cómo IPv4).
El tamaño de la cabecera (Header Length), son 4 bits (2^4 = 16 posiciones, 0...15) que indican el número de palabras de 32 bits que ocupa la cabecera. Estos 4 bits de tamaño máximo nos limitan a un tamaño de cabecera máximo de 60 bytes (15 * 32 bits = 60 bytes). No obstante, el valor usual de este campo es 5 (5 * 32 bits = 20 bytes).
El campo del tipo de servicio (Type Of Service), se compone de 8 bits. Los primeros 3 bits tienen una función obsoleta y no se contemplan actualmente. Los 4 bits siguientes definen el tipo de servicio (ver figura 2-12) y el último bit no se utiliza actualmente y debe tener valor 0. Solo 1 de los 4 bits del tipo de servicio puede estar activo a la vez. El tipo de servicio determina la política a seguir en el envío del datagrama por Internet. Las opciones posibles son:
La longitud del datagrama (Total Length), es un número de 16 bits (2^16 = 65536,0...65535) que indica la longitud total del datagrama. Este valor es muy importante, ya que nos permite saber que tamaño de memoria debemos reservar para la recepción del datagrama. Además, nos indica el número de bytes a leer, lo que nos permite un simple control de error. De esta forma, si el valor es incorrecto, el número de bytes leídos será como máximo de 65535, acotando el error. Además nos limita el número de bytes a enviar en un datagrama (Maximum Transfer Unit, MTU) a 65535 – 20 (tamaño típico de la cabecera) = 65515 bytes.
Si el tamaño del datagrama, es mayor que el tamaño máximo del paquete de red (Ej. Datagrama de 32000 bytes enviado sobre una Ethernet, que tiene un tamaño máximo de paquete de 1500 bytes), éste se fragmenta en N trozos.
El número de identificación del datagrama (Identificartion Field), es un número de 16 bits que en caso de fragmentación de un datagrama nos indica su posición en el datagrama original. Esto nos permite recomponer el datagrama original en la máquina de destino. Este valor nos indica que un datagrama puede ser fragmentado en un máximo de 65535 fragmentos.
Las banderas (Flags) son 3 bits. El primero permiten señalar si el datagrama recibido es un fragmento de un datagrama mayor, bit M (More) activado. El segundo especifica si el datagrama no debe fragmentarse, bit DF (Don’t fragment) activado y el tercero no se utiliza actualmente, asignándole el valor 0 [San99].
El número de byte en el datagrama (Fragmentation Offset), nos indica la posición en bytes que ocupan los datos en el datagrama original. Sólo tiene sentido si el datagrama forma parte de uno mayor que ha sido fragmentado. Este campo tiene un máximo de 13bits (2^13 = 8192, como nos indica el desplazamiento en bytes 8192 * 8 bits = 65536).
De esta forma, siempre podemos reconstruir el datagrama original con los fragmentos.
El tiempo de vida (Time To Live), es un campo de 8 bits que indica el tiempo máximo que el datagrama será válido y podrá ser transmitido por la red. Esto permite un mecanismo de control para evitar datagramas que circulen eternamente por la red (por ejemplo en el caso de bucles).
Este campo se inicializa en el ordenador de origen a un valor (máximo 2^8 = 256) y se va decrementando en una unidad cada vez que atraviesa un router. De esta forma, si se produce un bucle y/o no alcanza su destino en un máximo de 255 “saltos”, es descartado. En este caso se envía un datagrama ICMP de error al ordenador de origen para avisar de su pérdida.
El tipo de protocolo (Protocol), es un valor que indica a que protocolo pertenece el datagrama (TCP, UDP, ICMP...). Es necesario debido a que todos los servicios de Internet utilizan IP como transporte, lo cual hace necesario un mecanismo de discriminación entre los diferentes protocolos.
El checksum de la cabecera del datagrama (Header Checksum), es una suma de comprobación que afecta sólo a la cabecera del datagrama IP. El resto de protocolos TCP, UDP, IGMP... tienen su propia cabecera y checksum. Su función es simplemente la de un mecanismo de control de errores. De esta forma, si se encuentra un error en el checksum de un datagrama IP, este es simplemente descartado y no se genera ningún mensaje de error. Esto implica que es deber de las capas superiores el control del flujo de los datagramas para asegurarse que estos lleguen correctamente al destino, ya sea utilizando un protocolo fiable (TCP) o implementando internamente algún tipo de control.
Tanto la dirección IP de origen como la de destino (IP address), están formadas por dos números de 32 bits. Estas direcciones se corresponden a una distribución según la figura 1-3.
Creditos: Gabriel Verdejo Alvarez
Click aqui para ir a la parte 1.
Una vez definido el direccionamiento de redes y ordenadores en Internet,
mencionaremos la existencia de los servicios de DNS (Domain Name Server).
Debido a que es más fácil recordar un nombre (Centro de cálculo de la Universidad
Autónoma de Barcelona, cc.uab.es) que una dirección numérica (158.109.0.4), se
crearon los servidores de nombres (DNS), que son las máquinas encargadas de
transformar un nombre en su dirección correspondiente.
1.2 El protocolo IP versión 4
El protocolo IP (Internet Protocol) es la pieza fundamental en la que se sustenta el sistema TCP/IP y por tanto todo el funcionamiento de Internet. Su especificación está recogida en [RFC791].
La unidad de datos del protocolo IP es el datagrama (ver figura 1-4), cuyo tamaño máximo es de 65535 bytes (64K).
El protocolo IP facilita un sistema sin conexión (connectionless) y no fiable (unreliable) de entrega de datagramas entre dos ordenadores cualesquiera conectados a Internet.
IP da un servicio de entrega basado en el mejor intento (best effort). Esto implica que cuando hay algún funcionamiento anómalo de Internet, como podría ser un router colapsado, se contempla un sistema muy simple de tratamiento de errores. Este mecanismo de control de errores viene regulado por el protocolo ICMP (Internet Control Message Protocol).
En nuestro caso, el router colapsado descartaría el datagrama y enviaría un mensaje de error ICMP al ordenador de origen sin encargarse de la retransmisión del datagrama, lo que no implica fiabilidad.
Además, no mantiene ningún tipo de información referente al estado de las conexiones. Cada datagrama es encaminado de forma independiente, lo que le convierte en un protocolo sin conexión.
Debido a estas particulares características, puede pasar que se pierdan datagramas y/o que estos no lleguen en orden. De esta manera, cualquier fiabilidad que se necesite,deberá ser realizada por las capas superiores (TCP...).
La estructura de un datagrama IP está dividida en bloques de 32 bits (4 bytes). El datagrama IP se transmite enviando primero el bit 0, luego el bit 1, 2, 3... y así sucesivamente hasta finalizar el datagrama.
Este orden se denomina network byte order. Es muy importante conocer este orden de transmisión de la información, puesto que los diferentes ordenadores tienen diferentes sistemas de almacenamiento de bits en memoria.
El formato little endian, consiste en almacenar los bits en orden inverso al network byte order (usando por ejemplo en los procesadores Intel), mientras que la otra posibilidad se denomina big endian (usado por ejemplo en los procesadores Motorola).
El tamaño de la cabecera (Header Length), son 4 bits (2^4 = 16 posiciones, 0...15) que indican el número de palabras de 32 bits que ocupa la cabecera. Estos 4 bits de tamaño máximo nos limitan a un tamaño de cabecera máximo de 60 bytes (15 * 32 bits = 60 bytes). No obstante, el valor usual de este campo es 5 (5 * 32 bits = 20 bytes).
El campo del tipo de servicio (Type Of Service), se compone de 8 bits. Los primeros 3 bits tienen una función obsoleta y no se contemplan actualmente. Los 4 bits siguientes definen el tipo de servicio (ver figura 2-12) y el último bit no se utiliza actualmente y debe tener valor 0. Solo 1 de los 4 bits del tipo de servicio puede estar activo a la vez. El tipo de servicio determina la política a seguir en el envío del datagrama por Internet. Las opciones posibles son:
- minimizar el retraso (minimize delay)
- maximizar el rendimiento (maximize throughput)
- maximizar la fiabilidad del transporte (maximize reliability)
- minimizar el coste económico del transporte (minimize monetary cost).
Si el tamaño del datagrama, es mayor que el tamaño máximo del paquete de red (Ej. Datagrama de 32000 bytes enviado sobre una Ethernet, que tiene un tamaño máximo de paquete de 1500 bytes), éste se fragmenta en N trozos.
El número de identificación del datagrama (Identificartion Field), es un número de 16 bits que en caso de fragmentación de un datagrama nos indica su posición en el datagrama original. Esto nos permite recomponer el datagrama original en la máquina de destino. Este valor nos indica que un datagrama puede ser fragmentado en un máximo de 65535 fragmentos.
Las banderas (Flags) son 3 bits. El primero permiten señalar si el datagrama recibido es un fragmento de un datagrama mayor, bit M (More) activado. El segundo especifica si el datagrama no debe fragmentarse, bit DF (Don’t fragment) activado y el tercero no se utiliza actualmente, asignándole el valor 0 [San99].
El número de byte en el datagrama (Fragmentation Offset), nos indica la posición en bytes que ocupan los datos en el datagrama original. Sólo tiene sentido si el datagrama forma parte de uno mayor que ha sido fragmentado. Este campo tiene un máximo de 13bits (2^13 = 8192, como nos indica el desplazamiento en bytes 8192 * 8 bits = 65536).
De esta forma, siempre podemos reconstruir el datagrama original con los fragmentos.
El tiempo de vida (Time To Live), es un campo de 8 bits que indica el tiempo máximo que el datagrama será válido y podrá ser transmitido por la red. Esto permite un mecanismo de control para evitar datagramas que circulen eternamente por la red (por ejemplo en el caso de bucles).
Este campo se inicializa en el ordenador de origen a un valor (máximo 2^8 = 256) y se va decrementando en una unidad cada vez que atraviesa un router. De esta forma, si se produce un bucle y/o no alcanza su destino en un máximo de 255 “saltos”, es descartado. En este caso se envía un datagrama ICMP de error al ordenador de origen para avisar de su pérdida.
El tipo de protocolo (Protocol), es un valor que indica a que protocolo pertenece el datagrama (TCP, UDP, ICMP...). Es necesario debido a que todos los servicios de Internet utilizan IP como transporte, lo cual hace necesario un mecanismo de discriminación entre los diferentes protocolos.
El checksum de la cabecera del datagrama (Header Checksum), es una suma de comprobación que afecta sólo a la cabecera del datagrama IP. El resto de protocolos TCP, UDP, IGMP... tienen su propia cabecera y checksum. Su función es simplemente la de un mecanismo de control de errores. De esta forma, si se encuentra un error en el checksum de un datagrama IP, este es simplemente descartado y no se genera ningún mensaje de error. Esto implica que es deber de las capas superiores el control del flujo de los datagramas para asegurarse que estos lleguen correctamente al destino, ya sea utilizando un protocolo fiable (TCP) o implementando internamente algún tipo de control.
Tanto la dirección IP de origen como la de destino (IP address), están formadas por dos números de 32 bits. Estas direcciones se corresponden a una distribución según la figura 1-3.
Creditos: Gabriel Verdejo Alvarez
Click aqui para ir a la parte 1.
Comentarios
Publicar un comentario