Esnifando tráfico de red con tcpdump. Capturando tráfico

Instalo tcpdump

apt-get install tcpdump

Descargamos los ficheros de la práctica y comprobamos los mismos con file:

file em0.lpc sf1.lpc

Instalamos libpcap y tcpdump -sino lo está ya-

apt-get install tcpdump

O nivel de aplicación

Artículo copiado da páxina do IES S. Clemente de Santiago.

Contenido     1 Introdución 2 Arquitecturas de aplicacións en rede 2.1 Arquitectura cliente/servidor 2.2 Arquitectura P2P pura 2.3 Arquitecturas híbridas C/S e P2P 3 Comunicación de procesos 4 Protocolos do nivel de aplicación 4.1 O HTTP 4.1.1 Un pouco de historia 4.1.2 Conceptos previos 4.1.3 Características 4.1.4 Tipos de conexións 4.1.5 Mensaxes 4.1.5.1 Solicitudes 4.1.5.2 Respostas 4.1.6 As cookies 4.1.7 Servidores Proxy 4.1.8 Instalación e configuración do Apache 4.2 O File Transfer Protocol 4.3 O DNS 4.4 O correo electrónico

Introdución

Neste tema descríbese toda unha serie de aplicacións ou programas que utilizan a rede como medio de comunicación, así como os protocolos de comunicacións que teñen asociados. Devanditas aplicacións coñécense como aplicacións distribuídas, posto que están formadas por diferentes partes e cada unha se atopa en máquinas diferentes. Por norma xeral, hai unha parte chamada servidor que se executa nun computador, á que se conectan os diferentes clientes (que se atopan noutros computadores remotos) para requirir os seus servizos (polo xeral, solicitan a execución dalgún tipo de operación).

Existe unha gran cantidade de aplicacións que seguen este modelo e que, nalgúns casos, usamos diariamente, entre elas: o correo electrónico, a navegación Web, a mensaxería instantánea, a telefonía IP, o acceso remoto a outros computadores, a vídeoconferencia, a computación paralela masiva, a compartición de ficheiros, os xogos en rede multiusuario, a descarga de vídeo e audio e un longo etc.

Estas aplicacións empregan protocolos concretos para poder entenderse. Este protocolos atópanse no nivel de aplicación.

Arquitecturas de aplicacións en rede

As aplicacións execútanse en diferentes computadores no que se coñece como sistemas finais, e comunícanse mediante a rede. Por exemplo: un programa que fai de servidor Web comunícase cun programa navegador. Xa que logo, a comunicación para unha aplicación en rede ten lugar entre sistemas finais no nivel de aplicación.

Hai tres tipos de arquitecturas para as aplicacións en rede:

• Arquitectura Cliente/Servidor
• Arquitectura Peer-to-peer (P2P)
• Arquitectura híbrida entre cliente/servidor e P2P

Arquitectura cliente/servidor

O modelo ou arquitectura cliente/servidor está formado por dúas partes.

• O servidor. Sempre está funcionando (24x7) e ten unha dirección IP permanente. Pódense instalar granxas ou clusters de servidores para dar servizo a un maior número de usuarios.
• Os clientes. Poden estar conectados intermitentemente. As súas direccións IP son dinámicas. Os clientes non se comunican directamente entre eles, senón que o fan co servidor

Moitas das aplicacións de uso frecuente de Internet, como a navegación Web ou o correo electrónico, usan este modelo.

Arquitectura P2P pura

Este modelo ten unhas características diferenciadas respecto á cliente/servidor pura. Estas diferenzas son as seguintes:

• Non existe un servidor acendido permanentemente
• Non se distingue entre clientes e servidores, senón que existen sistemas arbitrarios finais, chamados peers, que se comunican directamente
• Os peers están conectados intermitentemente e cambian a súa dirección IP con frecuencia
• Todos os nodos teñen a mesma función, peso e importancia dentro da rede

Un exemplo de programa que usa unha arquitectura P2P pura é o software de intercambio de ficheiros Gnutella, que usa protocolo de distribución de ficheiros entre pares, sen un servidor central.

A principal vantaxe desta arquitectura fronte a anterior é que é moi escalable. Como contrapartida é máis difícil de xestionar.

Arquitecturas híbridas C/S e P2P

Son unha mistura das anteriores. De tal xeito que para algunhas funcións usan un servidor central e para outras fan unha comunicación directa con outro peer. Vexámolo con dúas aplicacións de exemplo:

• eMule. No programa de intercambio de ficheiros eMule a transferencia de ficheiros realízase mediante P2P. Con todo, a busca de ficheiros é centralizada xa que os pares, ou peers, rexistran contido nun servidor central (os ficheiros que comparten). Para localizar un contido, o pares consultan un servidor central ou varios servidores distribuídos, pero para a transferencia usan P2P.
• Mensaxería instantánea. As conversas que se manteñen entre dous usuarios realízase mediante P2P, pero o rexistro e localización é mediante C/S, é dicir, centralizada nun servidor. De feito, os usuarios rexistran a súa IP nun servidor cando arrincan o programa. Este servidor é un servidor central de contactos para IP de amigos.

Comunicación de procesos

Un proceso é un programa que se executa nun computador. Un proceso cliente é o que inicia a comunicación. Un proceso servidor é o que espera a ser contactado. Por exemplo: O programa dhclient lanza un proceso cliente que solicita unha dirección IP. O programa dhcpd espera a recibir peticións para respostar con direccións IP dinámicas aos clientes.

As aplicacións están formadas por varios procesos. No caso das arquitecturas P2P as aplicacións teñen procesos clientes e procesos servidores ao mesmo tempo.

Os procesos pertencen a un usuario que, normalmente, os lanza ou provoca que se lancen. Para ver os procesos dun usuario que se están executando nun computador para podes teclear:

ps ­-u nome_usuario

Nun computador pode haber varios procesos executándose polo que se identifican mediante un número de porto. Os procesos comunícanse uns cos outros a través dos sockets. Un socket especifica a dirección, o porto e o protocolo de transporte que se usa na comunicación. Por exemplo: (192.168.100.10, 80, TCP).

Protocolos do nivel de aplicación

Os procesos comunícanse enviándose mensaxes. As características destas mensaxes están determinadas no protocolo, o cal define:

• Os tipos de mensaxes que se intercambian, i.e: mensaxes de solicitude e resposta
• A sintaxe dos tipos de mensaxe, i.e: campos que terán as mensaxes
• A semántica dos campos, é dicir, o que significa a información dos campos das mensaxes
• As regras sobre cando e como os procesos poden enviar e respostar mensaxes

Os protocolos do nivel de aplicación poden ser de dominio público ou propietarios. No primeiro caso, están definidos nos RFC (Request For Comments). Ao estar publicamente accesibles permiten a interoperabilidade entre aplicacións de distintos fabricantes. Exemplos deste tipo de protcolos son HTTP (HyperText Transfer Protocol) ou o SMTP (Single Mail Transfer Protocol). No segundo caso é o fabricante dun determinado software quen o define e a interoperabilidade non está garantida. Un exemplo deste tipo de protocolos é o que usa a aplicación Skype.

O HTTP

Un pouco de historia

O HTTP naceu no 1989 no CERN (Centro Europeo de Investigación Nuclear). A Web xurdiu pola necesidade de lograr que os equipos de investigadores dispersos internacionalmente colaborasen, usando un conxunto sempre cambiante de informes, planos, debuxos, fotos e outros documentos.

A proposta inicial dunha rede (web) de documentos vinculados xurdiu do físico do CERN Tim Berners-Le. O primeiro prototipo estaba baseado só en texto. En decembro de 1991 fíxose unha demostración pública e o desenvolvemento continuou durante o seguinte ano, culminando coa liberación da primeira interface gráfica, Mosaic, no ano 1993. Mosaic tivo tanto éxito que, un ano despois, o seu autor, Marc Andreeseen formou a compañía, Netscape Communications Corp.

En 1994, o CERN e o M.I.T. asinaron un acordo para establecer o World Wide Web Consortium, unha organización adicada ao desenvolvemento da Web, a estandarización de protocolos e o fomento da interoperabilidade entre as instalacións. Berners-Le converteuse no director.

Conceptos previos

As páxinas Web están formadas por obxectos. Os obxectos poden ser ficheiros HTML, imaxes, ficheiros de audio, vídeo, etc. Unha páxina web é un ficheiro HTML base que inclúe varias referencias aos obxectos. A cada obxecto accédese mediante unURL (Uniform Resource Locator) que ten a seguinte forma:

Características

O HTTP é un protocolo do nivel de aplicación para a Web. Segue o modelo ouarquitectura cliente/servidor, tal e como se ve na figura. O cliente é un navegador (browser) que solicita, recibe, e mostra obxectos Web. O servidor Web envía obxectos como resposta ás peticións do cliente. Hai dúas versións do protocolo, o HTTP 1.0, especificada no RFC 1945, e o HTTP 1.1, especificado no RFC 2068.

HTTP utiliza TCP como protocolo de transporte. Os clientes inician conexións TCP (crean un socket) co servidor, no porto 80. Os servidores aceptan conexións TCP dos clientes. Unha vez establecida a conexión intercámbianse mensaxes HTTP (mensaxes do protocolo do nivel de aplicación) entre o cliente (cliente HTTP) e o servidor Web (servidor HTTP). Finalmente, péchase a conexión TCP.

HTTP non ten “estados” (stateless). Isto quere dicir que o servidor non mantén información sobre solicitudes anteriores dos clientes. Deseñouse así porque os protocolos que manteñen o estado son complexos, xa que hai que manter un histórico do que acontece (estado). Se o cliente ou o servidor fallan pode haber inconsistencias e deberán volver ao estado anterior, co correspondente consumo de recursos.

Tipos de conexións

As conexións HTTP poden ser de dous tipos:

• Conexión non persistentes. Nelas, envíase un obxecto como máximo en cada conexión TCP. Para cada nova petición do cliente precísase unha nova conexión TCP. HTTP/1.0 utiliza HTTP non persistente. Por exemplo, se unha páxina Web ten referencias a 10 obxectos, abriranse 10 conexións TCP.
• Conexións persistentes. Envíanse varios obxectos nunha única conexión TCP entre o cliente e o servidor. HTTP/1.1 utiliza conexións persistentes por defecto. As conexións persistentes supoñen menos sobrecarga para o SO xa que os navegadores non abren varias conexións TCP paralelas para conseguir os obxectos referenciados. O servidor deixa a conexión TCP aberta despois de enviar unha resposta, xa que logo, as mensaxes HTTP entre o mesmo cliente e servidor usan a mesma conexión TCP.

Mensaxes

En HTTP hai mensaxes de solicitude e mensaxes resposta. Ambas as dúas mensaxes están en formato ASCII, polo que poden verse e lerse se capturamos unha sesión HTTP cun analizador de rede como, por exemplo, o Wireshark.

Solicitudes

Unha mensaxe HTTP de solicitude ten o seguinte formato:

Se queremos facer unha solicitude de envío de datos (por exemplo, cando facemos unha consulta nun buscador enviámoslle ao servidor a palabra a buscar, ou cando enviamos un formulario) podemos usar dous métodos:

• Método POST, no que os datos se envían ao servidor dentro da mensaxe de solicitude HTTP.
• Método URL, tamén chamado método GET, no que os datos se envía na URL da liña de solicitude, por exemplowww.unsite.com/buscaAnimal?mono&banana

Dependendo da versión do protocolo que se use están soportadas distintas mensaxes HTTP (tamén coñecidas como métodos):

• Para HTTP 1.0: están soportadas as mensaxes GET e POST xa vistas. Tamén está soportada a mensaxe HEAD que só devolve a cabeceira, non o obxecto referenciado
• Para HTTP 1.1: están soportadas as tres mensaxes anteriores e tamén PUT, que permite subir o ficheiro especificado no URL ao servidor, e DELETE, que permite borrar o ficheiro especificado no URL.

Respostas

As mensaxes HTTP de resposta teñen un formato similar ás de solicitude:

As mensaxes de resposta inclúen un código dependendo do significado da mesma. Dito código vai na primeira liña da mensaxe (liña de estado). Algúns exemplos son os seguintes:

200 OK
Solicitude correcta, envíarase o obxecto solicitado nesta mensaxe   301 Moved Permanently
Obxecto solicitado noutro URL, especifícase a nova localización nesta mensaxe (Location:)   400 Bad Request
Mensaxe non entendida polo servidor   404 Not Found
Obxecto solicitado non atopado no servidor   505 HTTP Version Not Supported

As cookies

Dixemos que HTTP é un protocolo sen estado. Isto, ás veces, pode non ser o desexado. Por exemplo, supoñamos que temos unha web na que as súas páxinas están restrinxidas a determinados usuarios. Se non mantemos o estado do cliente teremos que estar solicitándolle para cada páxina que queira ver o seu nome de usuario e clave. HTTP resolve este escenario coas cookies.

As cookies están definidas no RFC 2109 e permiten monitorizar a navegación do usuario. Moitos sites usan cookies. Son útiles, por exemplo, para validar un usuario, escoller opcións personalizadas (idioma, etc.), rexistrar hábitos de navegación, etc. Están formadas por catro compoñentes:

1. Liña de cabeceira da cookie na resposta HTTP.
2. Liña de cabeceira da cookie na solicitude HTTP.
3. Ficheiro que se mantén no computador do cliente, xestionado polo navegador.
4. Base de datos no servidor.

Un exemplo de funcionamento das cookies podémolo ver na figura.

Servidores Proxy

Dun modo xenérico, pódese definir un proxy como un software que fai de intermediario entre un cliente e un servidor. Os proxies en HTTP úsanse, entre outras cousas, para facer de caché das páxinas visitadas. É o que se coñece como un Web cache e o seu obxectivo é respostar aos clientes sen interactuar co servidor, gañando en velocidade, xa que o proxy está normalmente na mesma rede ou máis cercano que o servidor Web que contén a páxina orixinal.

O proxy configúrase no navegador. É o navegador quen envía as solicitudes HTTP ao proxy. Se o obxecto está na cache o proxy é quen o devolve. Se non, o proxy solicita o obxecto ao servidor orixinal que á súa vez é enviado ao cliente. O proxy ten, xa que logo, unha parte cliente e outra servidor. Normalmente instálanse en universidades, compañías, ISP, etc., para axilizar o tráfico. Entre as vantaxes de usar un servidor proxy están as seguintes:

• Reducir o tempo de resposta das solicitudes dos clientes.
• Reducir o tráfico, e polo tanto ampliar o largo de banda.
• Filtrar contido.

Un exemplo de software de servidor proxy é o Squid.

Instalación e configuración do Apache

Instalación e configuración do servidor Web Apache

O File Transfer Protocol

O FTP

O DNS

O DNS

O correo electrónico

O correo-e

Práctica Sistemas de Videovigilancia

1. Configurar el equipo Servidor de videovigilancia con la cámara web AXIS. Localiza el software de la cámara en Internet e instálalo en el equipo. Establece la configuración de red (IP y máscara que estimes pertinente)

1. Una vez instalada y configurada comprueba su funcionamiento desde un equipo cliente.

1. Realiza una documentación técnica indicando los pasos realizados en los ejercicios anteriores.

1. Configurar el equipo Servidor de videovigilancia con la cámara web Logitec. Localiza en Internet un software que permita realizar tareas específicas de videovigilancia (capturar imágenes, movimientos, …). Elabora una especie de manual de usuario con las opciones de configuración del programa.

1. Exposición en clases de la documentación desarrollada.

1. Resolución de preguntas sobre el servicio y la práctica desarrollada.

NOTAS:

1. Las 3 primeras sesiones no se resolverán dudas relativas a la práctica.
2. Toda la documentación relativa a la práctica deberá ser entregada el jueves siguiente antes de comenzar la realización de la práctica siguiente, en caso contrario se considerará que no ha sido superada.

Práctica configuración de enrutadores (router)

1. Leer el manual y configurar el enrutador para que sus datos coincidan con el de la imagen. ¿Cuál es la ip de la interfaz externa? Razona porqué.

1. Asignar una ip dinámica a los equipos 1 y 2 mediante el Enrutador, de modo que queden incluidos en la misma red. Realizar un ping desde el equipo1 al equipo2. (equipo 1 y equipo2 deben estar ejecutándose en Linux en la máquina virtual). Captura una pantalla realizando ping de un equipo a otro. En qué red (escribe la ip) están el equipo 1 y 2 ¿porqué?, razona la respuesta.

1. Los equipos 1 y 2 no salen a internet. ¿Sabes a qué puede ser debido?. Habilita la salida a Internet del Equipo1. Documenta la solución

1. Instala apache en el equipo1. Comprueba que sirve la página inicial en el equipo local –equipo1. (captura la pantalla).

1. Configura el enrutador para permitir el acceso desde equipo exterior al servidor web en equipo1. Haz una captura de pantalla dónde se muestre la página web inicial de dicho equipo accediendo desde la red externa.

1. Documentación técnica indicando los pasos realizados para resolver los ejercicios (presentación odt –openoffice.org-)

1. Exposición en clases de la documentación desarrollada.

1. Resolución de preguntas sobre el servicio y la práctica desarrollada.

NOTAS:

1. Las 3 primeras sesiones no se resolverán dudas relativas a la práctica.
2. Toda la documentación relativa a la práctica deberá ser entregada el jueves siguiente antes de comenzar la realización la siguiente, en caso contrario se considerará que no ha sido superada.

Práctica PLC y cámara web inalámbrica (OvisLink)

1. Instala los dos plc y configúralos. En uno irá conectado el servidor de videovigilancia y en el otro la máquina cliente (máquina virtual).

1. Configurar el equipo Servidor de videovigilancia con la cámara web Ovislink. Localiza el software de la cámara instálalo en el equipo. Establece la configuración de red (IP y máscara que estimes pertinente)

1. Una vez instalada y configurada comprueba su funcionamiento desde un equipo cliente.

1. Realiza una documentación técnica indicando los pasos realizados en los ejercicios anteriores.

1. Configurar el equipo Servidor de videovigilancia con la cámara web Logitec. Localiza en Internet un software que permita realizar tareas específicas de videovigilancia (capturar imágenes, movimientos, …). Elabora una especie de manual de usuario con las opciones de configuración del programa.

1. Exposición en clases de la documentación desarrollada.

1. Resolución de preguntas sobre el servicio y la práctica desarrollada.

NOTAS:

1. Las 3 primeras sesiones no se resolverán dudas relativas a la práctica.
2. Toda la documentación relativa a la práctica deberá ser entregada el jueves siguiente antes de comenzar la realización de la práctica siguiente, en caso contrario se considerará que no ha sido superada.

Práctica configuración red inalámbrica

Dentro de las clases de redes y empleando el hardware  disponible para ello realizar las siguientes prácticas y respondiendo a las siguientes cuestiones:

1. Leer el manual y configurar el enrutador para que sus datos coincidan con el de la imagen. ¿Cuál es la ip de la interfaz externa? Razona porqué.
2. Instala las tarjetas de red inalámbricas en la máquina virtual bajo Windows XP
3. Qué algoritmos de encriptación puedes emplear en el router. ¿Cuál de los disponibles has empleado y por qué?¿Cuál es la ventaja de usar algún algoritmo de encriptación?
4. ¿Qué medidas de seguridad puedes emplear al usar redes inalámbricas? ¿Cuáles pueden ser implementadas en este router?¿Qué buscas configurando el router con dichos parámetros?
5. Asignar una ip dinámica a los equipos 1 y 2 mediante el Enrutador, de modo que queden incluidos en la misma red empleando los mecanismos de seguridad que habrás descrito previamente. Realizar un ping desde el equipo1 al equipo2. (equipo 1 y equipo2 deben estar corriendo Windows XP en la máquina virtual). Captura una pantalla realizando ping de un equipo a otro. En qué red (escribe la ip) están el equipo 1 y 2 porqué, razona la respuesta.
6. Los equipos 1 y 2 no salen a internet. ¿Por qué?. Habilita la salida a Internet del Equipo1. Documenta la solución.
7. REALIZAR ESTE PUNTO SÓLO SI DISPONÉIS DE TIEMPO SUFICIENTE: Existe software para intentar revelar claves en redes inalámbricas, que algoritmo de encriptación resulta más fácil de revelar. Usa alguno de los programas disponibles para intentar descubrir la clave de vuestra red. (captura una pantalla realizando dicho proceso).
8. Documentación técnica indicando los pasos realizados para resolver los ejercicios (presentación odt –openoffice.org-)
9. Exposición en clases de la documentación desarrollada.
10. Resolución de preguntas sobre el servicio y la práctica desarrollada.

NOTAS:

1. Las 3 primeras sesiones no se resolverán dudas relativas a la práctica.
2. Toda la documentación relativa a la práctica deberá ser entregada el jueves siguiente antes de comenzar la realización la siguiente, en caso contrario se considerará que no ha sido superada.

Nivel de transporte

Copio este artículo de la página del IES San Clemente

Contenido 1 Introdución 2 Servizos orientados a conexión 3 Portos 4 A Unidade de Datos do Protocolo (PDU) 5 O UDP (User Datagram Protocol) 5.1 Por que UDP 5.2 A PDU de UDP 6 O TCP (Transport Control Protocol) 6.1 Funcións 6.2 Características 6.3 A PDU de TCP 6.4 Establecemento da conexión 6.5 Peche da conexión 6.6 Transferencia de datos 6.6.1 Control de fluxo

Introdución

No nivel de enlace os datos envíanse entre equipos dentro da mesma LAN, conectados por un switch fisicamente. No nivel de rede os datos envíanse a través de distintas redes conectadas físicamente mediante routers. No nivel de transporte hai unha conexión directa entre os dous extremos que interveñen na comunicación pero é unhaconexión lóxica.

Por conexión lóxica entendemos que hai unha comunicación directa entre os programas ou equipos que interveñen na comunicación, independentemente da rede onde se atopen pero non existe conexión física directa entre eles. Existe, polo tanto, un circuíto virtual entre o emisor e receptor. A capa de transporte proporciona comunicación lóxica extremo a extremo, no canto de comunicación física. O nivel de transporte non é consciente, nin debe selo, de como están interconectados fisicamente os dous equipos (por unha LAN, unha WAN ou unha combinación de múltiples redes de ambos tipos). Que a comunicación sexa extremo a extremo quere dicir que non se coñecen os detalles da subrede, polo tanto, o nivel de transporte non sabe nada de routers, fragmentación, switches, hubs, etc.

Servizos orientados a conexión

Xeralmente as aplicacións requiren que o nivel de transporte lles garanta a entrega dos datos ao destinatario, sen erros, perdas, nin duplicados. Para que isto sexa posible o nivel de transporte pode ofrecer un servizo orientado a conexión, con retransmisións en caso necesario. Este é o caso do protocolo TCP (Transport Control Protocol), utilizado en moitas aplicacións (FTP, SMTP, HTTP...).

Noutros casos as aplicacións confórmanse (ou ata prefiren) un servizo menos fiable no que os datos se envían sen pedir confirmación, de forma independente uns doutros (como fai o IP cos paquetes). Este tipo de servizo ofréceo un protocolo non orientado a conexión que é UDP (User Datagram Protocol). UDP úsase, por exemplo, nas aplicacións en tempo real, onde non se quere incorrer no retardo propio dun protocolo orientado a conexión.

Portos

En TCP/IP defínense dúas direccións que permiten a relación cos niveis superiores e inferiores:

• A dirección IP, que xa coñecemos
• O número de porto, que identifica a aplicación que require a comunicación

Os portos son os enderezos do nivel de transporte. Cada porto está asociado a unha aplicación. Pódense asignar de dous xeitos dependendo de se falamos da aplicación cliente ou da aplicación servidor:

• Aplicación cliente: cando se abre unha aplicación, por exemplo un navegador web, cliente ftp, etc. o sistema operativo asígnalle un porto dos que teña libres.
• Aplicación servidor: as aplicacións servidor están sempre escoitando nun porto chamado ben coñecido (well known port). Este porto configúrase manualmente. Un porto ben coñecido é como un número de teléfono no que sabemos que existe un servizo determinado, por exemplo, 091 é a policía, 112 son emerxencias, etc.

Toda conexión TCP idéntificase polo par (IP_orixe, Porto_orixe)-(IP_destino, Porto_destino). Vexamos o seguinte exemplo:

Un usuario con IP 194.145.10.5 fai dobre clic sobre o navegador web. Nese intre o sistema operativo asígnalle un porto a esa aplicación (1500). O servidor ten, por exemplo, a IP 200.50.100.45. A aplicación cliente sabe en que porto está escoitando o servidor as peticións (neste caso no 80, xa que é o servizo Web). Se a aplicación servidor está escoitando nun porto distinto ao que lle corresponde, o usuario debe expresar cal é ese porto, por exemplo, o 81. A conexión TCP anterior identifícase polo par (194.145.10.5, 1500) - (200.50.100.45, 80).

As conexión TCP son full dúplex, é dicir, a información envíase en ambos sentidos por canais independentes. Isto fai que os números de porto se invirtan, dependendo de quen sexa o emisor ou o receptor, tal e como podemos ver na seguinte figura:

No seguinte gráfico podemos ver dous clientes usando o mesmo porto de destino (80) para comunicarse co mesmo servidor Web.

A Unidade de Datos do Protocolo (PDU)

O conxunto de bytes que transmite o nivel de transporte TCP coñécese como segmento TCP, mentres que ao conxunto de bytes que transmite o protocolo de transporte UDP chámase datagrama UDP. Ambos son PDU (Protocol Data Unit) do nivel de transporte en TCP/IP.

O UDP (User Datagram Protocol)

Vimos que TCP ten a robustez e funcionalidades propias dun protocolo orientado a conexión o cal conleva unha certa complexidade. O UDP, que está definido no RFC 768, é o protocolo da capa de transporte non orientado a conexión. Xa que logo, non garante que os datos se entreguen en orde (nin sequera que se entreguen, xa que non existen asentementos ou ACK), nin que a conexión se recupere de erros. En consecuencia, é máis rápido que TCP pero tamén máis inseguro.

Por que UDP

As aplicacións que non requiren unha fiabilidade total e non poden tolerar o retardo producido pola complexidade de TCP usan UDP. Algúns exemplos deste tipo de aplicacións son:

• Transmisión de vídeo ou audio en tempo real
• Aplicacións que requiren o envío dunha ou dúas mensaxes unicamente
• Sincronización de reloxos (NTP)
• Consultas ao servidor de nomes (DNS)
• Mensaxes de xestión da rede (SNMP)
• Obtención dinámica de dirección IP (DHCP)

Tamén usan UDP as aplicacións interesadas en transmitir información en modo multicast ou broadcast, é dicir, a un grupo de usuarios ou a todos os usuarios da rede, respectivamente. Isto só é posible cun protocolo non orientado a conexión, xa que pola súa propia natureza os protocolos orientados a conexión son punto a punto (en TCP non é posible establecer conexións multipunto).

A PDU de UDP

A Unidade de Datos do Protocolo no UDP é moi simple e os seus campos son os que se ven na seguinte táboa:

O significado dos campos é o seguinte:

• Porto orixe: especifica o porto da aplicación que xera o datagrama. Este valerá normalmente cero, salvo que a aplicación solicite unha resposta.
• Porto destino: especifica o porto da aplicación á que vai dirixido o datagrama.
• Lonxitude: indica a lonxitude do datagrama, incluíndo os campos de cabeceira.
• Checksum: é opcional, como en IPv4. Cando UDP recibe un datagrama e determina que hai erros, descártao e non o entrega a ningunha aplicación sen avisar ao emisor.
• Datos: contén os datos a transmitir. Un datagrama UDP vai encapsulado nun datagrama IP, o cal fixa a lonxitude máxima deste campo.

O TCP (Transport Control Protocol)

UDP non garante a entrega de información que lle proporciona unha aplicación. Tampouco reordena a información no caso de que chegue nunha orde diferente daquela en que se transmitiu. Todo o contrario que o TCP, especificado na RFC 793, que proporciona fiabilidade á aplicación xa que garante a entrega de toda a información no mesmo orde en que foi transmitida e proporciona un servizo orientado a conexión con control de fluxo e erros, ta e como veremos a continuación.

Funcións

Entre as funcións encargadas a TCP están as seguintes:

• Transmisión libre de erros: entrega á aplicación de destino exactamente a mesma información que lle entregou a aplicación de orixe
• Garante de entrega da información: toda a información transmitida pola aplicación de orixe entrégase á aplicación de destino. Se non é posible, o TCP debe avisar á aplicación.
• Garante de mantemento da secuencia de transmisión: garante a entrega no mesmo orde en que lle foi entregado pola aplicación de orixe.
• Eliminación de duplicados: o TCP garante que só entregará unha copia da información transmitida á aplicación de destino. No caso de que reciba copias a causa do funcionamento da rede ou dos protocolos que se implementan por baixo do nivel de transporte, eliminaranse.

Características

Entre as principais características deste protocolo están as seguintes:

• Orientado a conexión: para realizar unha comunicación entre dous puntos extremos, séguense tres pasos:

1. Establecer a conexión (o cliente indícalle ao servidor que quere comunicarse con el)
2. Unha vez establecida a conexión realízase o intercambio de información
3. Finalizado o intercambio, libérase a conexión

• Orientado a fluxos de bytes (stream oriented): as aplicacións non teñen ningún modo de indicar ao TCP os límites en que queren transferir a información. É o TCP o que decide en cada momento cantos bytes transfire nun segmento. Para transmitir eses fluxos usa buffers de envío e recepción, tamén coñecidos como ventás de recepción. Se a aplicación xera un byte o TCP pode esperar que a memoria intermedia (o buffer) estea máis chea antes de transferir a información. Se xera fluxos de gran tamaño transfírea de inmediato (mecanismo push).

• Ten un tamaño máximo de segmento: o MSS (Maximun Segment Size) é o tamaño do campo de datos do segmento que se especifica durante o establecemento da conexión. Polo tanto, o MSS no inclúe as lonxitudes das cabeceiras IP e TCP (MSS = MTU – 20 – 20). Cada extremo especifica un MSS pero non existe unha negociación entre os extremos. Se son distintos escollerase o menor. O feito de elixir o MSS non é trivial. En xeral, canto maior sexa o MSS, mellor, posto que as cabeceiras IP e TCP se “amortizan” máis. Con todo, se a MTU é pequena, será preciso fragmentar o datagrama IP (é dicir, o segmento TCP). Xa que logo, por norma xeral non interesa elixir MSS maiores que a MTU.
• Usa asentimentos: Son acuses de recibo, é dicir, segmentos que envía o receptor ao emisor para informalo de se recibiu correctamente o que o emisor enviou. A estes asentementos chámaselles ACK, do inglés acknowledgement. Contempla a técnica de piggybakcing que permite incluír ACK nun segmento de datos, co correspondente aforro fronte ao envío de segmentos específicos de recoñecemento.
• O TCP utiliza unha conexión full dúplex: xa o comentamos. A transferencia de información é en ambos sentidos. A aplicación ve dous fluxos independentes de bytes. No caso de que a aplicación peche un dos fluxos, a conexión pasa a ser half dúplex. Iso significa que un dos extremos (o que non pechou a conexión) pode continuar enviando información pola canle, mentres que o outro extremo (o que pechou a conexión) limítase a recoñecer a información.

A PDU de TCP

Xa vimos que á Unidade de Datos do Protocolo TCP chámaselle segmento e o seu formato é o seguinte:

Os seus campos teñen o seguinte significado:

• Porto orixe e porto destino: identifican os portos que van a utilizar en cada equipo as aplicacións.
• Número de secuencia: indica o primeiro byte do campo datos dese segmento. En TCP numéranse os bytes non os segmentos, xa que é un protocolo orientado a fluxos de bytes.
• Número de ACK: TCP recoñece datos por medio de piggybacking. Ao activar un bit da cabeceira TCP (o bit ACK), indica ao outro extremo o próximo byte que está disposto a recibir, tal e como podemos ver no seguinte exemplo:

Na figura anterior vese como o host A envía un segmento co número de secuencia 42. O host B resposta cun segmento de datos que ten o bit ACK activado. O número de ACK é 43, é dicir, Número de secuencia +1, xa que logo "recoñece" o segmento anterior ou o que é o mesmo, indícalle ao host A que recibiu correctamente o segmento 42 e espera recibir o 43. Por último, o host A envía o segmento 43 co bit ACK activado e número de ACK = 80, polo que tamén recoñece o semento enviado polo host B.

• Lonxitude de cabeceira TCP: especifica a lonxitude en palabras de 32 bits, excluído o campo datos (o campo opcións fai que dita lonxitude poida variar).

A continuación hai 6 bits non utilizados, seguidos por outros 6 bits indicadores que se están activados (a 1) teñen un significado específico, que é o seguinte:

• Bit URG (urgent): serve para indicar que o segmento contén datos urxentes. Utilízase en aplicacións como telnet e rlogin cando se pulsa a tecla de interrupción, ou no FTP cando se aborta a transferencia dun ficheiro.
• Bit ACK (acknowledgement): indica que é un segmento ACK.
• PSH (push): indica que se lle entreguen á aplicación todos os datos que estean na memoria intermedia de recepción (no buffer), sen esperar a recibir un segmento de tamaño máximo.
• RST (reset): indica que se debe abortar unha conexión porque se detectou un erro de calquera tipo; por exemplo que se recibiu un segmento cun valor inadecuado do número de secuencia ou número de ACK.
• SYN (synchronize): este bit indica que se está establecendo a conexión. Está activado só no primeiro segmento enviado por cada un dos dous equipos no inicio da conexión.
• FIN (finish): indica que non se teñen máis datos que enviar e que se quere pechar a conexión.

Os seguintes campos da PDU de TCP son:

• Tamaño de ventá: indica a cantidade de bytes que se está disposto a aceptar do outro lado en cada momento. Suponse que se garante unha cantidade suficiente de espazo nos buffers. Mediante este parámetro o receptor establece un control de fluxo sobre o caudal de datos que pode enviar o emisor. Cada extremo terá a súa ventá de recepción.
• Checksum: utilízase para detectar erros.
• O campo Urgent pointer: ten sentido cando o bit de control URG está activo polo que os datos que envía a orixe son urxentes. Así, este campo identifica o último byte do campo de datos que é urxente.
• Opcións: permite engadir funcionalidades extras ao protocolo.

Establecemento da conexión

Para establecer unha conexión o TCP utiliza un mecanismo coñecido como three-way handshake, ou conexión a tres bandas, porque necesita tres segmentos TCP para poder establecer dita conexión. Inicialmente o servidor está nun estado de escoita, chamado listen. O cliente quere establecer unha conexión co servidor polo que o TCP da máquina cliente iniciará a petición de conexión, que será contestada polo TCP da máquina servidor. O intercambio de segmentos podemos velo no seguinte gráfico:

• Paso 1: petición de conexión. O TCP cliente envía unha petición de conexión ao servidor mediante un segmento SYN (ten o bit SYN da cabeceira activado). Especifica tamén nese segmento o ISN ou Número de Secuencia Inicial para empezar a numerar os bytes que se enviarán, así como outros parámetros como o MSS. O ISN escóllese ao chou.
• Paso 2: confirmación de conexión. O servidor responde á petición de establecemento da conexión cun segmento SYN que indica o número de secuencia inicial que utilizará el. Este segmento contén un recoñecemento (ACK) do segmento SYN do cliente que indica o ISN do cliente máis 1. TCP numera os ACK co número de secuencia do próximo byte que espera recibir, tal e como xa se comentou anteriormente.
• Paso 3: recoñecemento da conexión. O cliente recoñece o segmento SYN do servidor cun ACK que contén o ISN do servidor máis 1, establecendo nese momento a conexión lóxica entre o cliente e o servidor.

Quen envía o primeiro segmento SYN (neste caso, o cliente) efectúa unha apertura activa (active open). Quen recibe o primeiro segmento SYN e envía o seguinte segmento SYN (neste caso, o servidor) leva a cabo unha apertura pasiva (passive open)

Peche da conexión

Cando a transferencia de datos remata, TCP dispón dun mecanismo de finalización da conexión para pechala. Unha conexión TCP é full dúplex, os datos flúen en ambos sentidos, independentes o un do outro, polo que calquera conexión debe pecharse independentemente. O intercambio de segmentos para o peche dunha conexión TCP podémolo ver na seguinte figura:

1. Paso 1: peche da conexión nun sentido. O cliente envía un segmento TCP co bit FIN activado o que significa que non haberá máis datos dende o cliente ao servidor, nese sentido (cliente->servidor). O servidor envía unha confirmación de peche por medio dun segmento ACK. O TCP servidor indica á súa aplicación que o cliente pecha a conexión.
2. Paso 2: peche da conexión no outro sentido. O servidor envía un segmento TCP de tipo FIN ao cliente. O TCP cliente responde automaticamente cun ACK.

Quen envía o primeiro segmento FIN (neste caso o cliente) leva a cabo un peche activo (active close). Quen o recibe (neste caso o servidor) realiza un peche pasivo (passive close).

Transferencia de datos

Unha vez establecida a conexión o TCP pode empezar a transferencia de segmentos en ambos os dous sentidos. Para transmitir información de xeito fiable, TCP implementa protocolos de control de erros e de fluxo.

Cando o TCP envía datos mantén un temporizador (timeout) ata que recibe un ACK do receptor. Se o temporizador salta, o TCP retransmite os datos (técnica de envío - espera). Cando o TCP recibe un segmento de datos envía un recoñecemento. Este último pódese retornar atrasado (non de inmediato) se o TCP o considera necesario.

Se un segmento recibido é incorrecto (o checksum indícao), o TCP descártao e devolve un segmento co mesmo número de ACK que recoñecera a última vez (ACK duplicado). O transmisor verá un ACK cun número repetido e interpretará que non lle recoñecen a información e, xa que logo, terá que volver a enviala.

No caso de que non tivese datos para enviar en sentido contrario, o TCP pode enviar un segmento que non conteña datos. Este segmento tería o indicador ACK activado e recoñecería os bytes pertinentes no campo Número de ACK. O número de secuencia non se incrementaría, posto que non se envían datos.

Se os segmentos chegan desordenados o TCP reordénaos e pasa os datos correctamente ordenados á aplicación. Se recibe segmentos duplicados, o TCP descarta as copias.

TCP posúe unha memoria limitada polo que é necesario que efectúe un control de fluxo: cada extremo avisa dos datos que está disposto a recibir en cada momento utilizando o campo Tamaño da Ventá da cabeceira TCP visto anteriormente. Trátase dun mecanismo de ventá deslizante.

Na seguinte figura vemos un escenario interesante dende o punto de vista da transferencia da información, no que se reflicte unha retransmisión debida a unha perda de segmento.

Outro escenario interesante é o da seguinte figura na que se amosa o caso dun ACK duplicado.

Ambos escenarios usan ACK acumulativos, é dicir, un único segmento ACK pode recoñecer varios segmentos de golpe.

Control de fluxo

As memorias intermedias de recepción dos extremos TCP pódense encher, xa que logo, é necesario un protocolo de ventá deslizante (sliding window) para controlar o fluxo de datos. A idea é que cada extremo TCP regula a cantidade de datos que o outro extremo pode transmitir. Por iso, cada extremo notifica ao outro, cada vez que envía un segmento, a ventá que pode aceptar nese momento.

A cabeceira do segmento TCP especifica tres parámetros para a técnica de ventá deslizante:

• O número de secuencia, que indica á súa conexión oposta o primeiro byte de datos que contén o segmento transmitido.
• O número de ACK, que indica á súa conexión oposta o próximo byte que espera recibir e, xa que logo, o último byte recibido correctamente.
• O tamaño da ventá, que indica á súa conexión oposta o tamaño da memoria intermedia de recepción e, xa que logo, o tamaño da fiestra que o transmisor debe utilizar.

O protocolo de ventá deslizante consiste en establecer límite no números de bloques de información que o emisor pode enviar sen recibir acuse de recibo deles. O tamaño da ventá deslizante en TCP mídese en bytes, isto é, cantos bytes se van poder enviar sen estar pendente do acuse de recibo.