Analise do nivel de transporte

Análise do Nivel de Transporte Planificación e Administración de Redes

1 O servizo de transporte

O servizo de transporte pretende ofrecer un servizo de envío de información eficiente, de confianza e económico aos procesos da capa de aplicación, empregando para ese obxectivo os servizos proporcionados pola capa de rede. A gran diferencia cos niveis inferiores é que neste caso o nivel de transporte execútase extremo a extremo, é dicir, entre a máquina que orixina a comunicación e a que recibe os datos. Ao igual que nos niveis de enlace e rede, é posible empregar protocolos orientados ou non á conexión, e o protocolo debe ser capaz de ofrecer este servizo independentemente de que o servizo de rede sexa orientado ou non a conexión. De feito o obxectivo final é que o servizo de transporte ofreza maior confianza que o servizo de rede subxacente, detectando e compensando a perda de paquetes ocultando os erros introducidos polo nivel de rede.

A unidade de datos de transporte denomínase TPDU (Transport Protocol Data Unit), e consta ao igual que no caso das unidades de datos de capas inferiores dunha carga útil procedente do nivel de aplicación e un encabezado do nivel de transporte.

1.1 Direccionamento.

Como calquera dos niveis, o de transporte tamén require o uso de algún tipo de direccionamento. Aínda que a máquina queda identificada a nivel de rede e de enlace, é posible (ou mellor dito frecuente) que existan varias aplicacións e procesos que empreguen a mesma dirección de rede, polo que será necesario identificar cal deses procesos é o referido por cada TPDU. Hai casos nos que esas direccións empregadas por certos procesos son estables e moi coñecidas, polo que simplemente cando un equipo quere conectarse a un servizo concreto dunha máquina (por exemplo, o servizo de páxinas web) a dirección dese servizo na máquina é un estándar coñecido. En outras configuración emprégase un servizo de directorio para recoñecer a dirección de transporte á que debe conectarse un cliente.

1


1.2 Control da conexión.

O proceso de creación de conexións implica realizar un control exhaustivo do proceso de comunicación, evitando a posibilidade de que cheguen paquetes atrasados, establecendo números de secuencia de transporte o suficientemente grandes como para evitar este tipo de problemas. O procedemento para establecer a conexión é normalmente a través do acordo a tres vías, consistente en que un equipo pida a conexión, reciba a confirmación de que se quere iniciar a conexión, e que esta se estableza finalmente cando o receptor recibe os primeiros datos acompañados dunha confirmación de que a conexión está aberta. Deste xeito, cando se establece a conexión tanto o emisor como o receptor recibiron e enviaron confirmacións de recepción, e con un sistema de numeración das TPDU axeitado o sistema é o suficientemente robusto como para asegurar que o establecemento da conexión é estable.

Máis problemático é o proceso de liberación da conexión, onde é imposible ter un sistema totalmente fiable de liberación da mesma. O problema queda exemplificado polo problema dos dous exércitos:

Os azuis queren atacar aos brancos, pero o único xeito de poñerse de acordo para atacar ao mesmo tempo é comunicarse a través do val no que están os brancos, co perigo de que o mensaxeiro sexa capturado. Podemos ver que non hai ningún xeito de que ambos exércitos saiban que están de acordo para o ataque, porque sempre está a posibilidade de que se perda o último mensaxe. A mesma situación darase cando intentemos conectar dous equipos a través dunha rede, de xeito que ademais do acordo a tres vías ao final haberá que confiar nun temporizador para liberar definitivamente a conexión.

2


1.3 Control de fluxo.

Outro dos aspectos importantes dun protocolo de transporte é o control de fluxo e o almacenamento en buffers dea información. O problema é similar ao da capa de enlace, coa diferencia de que neste caso a cantidade de conexións dun equipo e moito maior que a cantidade de liñas dun enrutador, o que fai que as estratexias cambien, aínda que o uso de protocolos de ventá corrediza seguen sendo os mías empregados. En xeral o emisor almacena nun buffer todas as TPDUs enviadas ata que recibe unha confirmación da recepción. Do mesmo xeito, o receptor almacena en buffers os paquetes recibidos antes de entregalos á capa de aplicación, tendo en conta ademais que dado que a capa de rede pode non ser (e de feito moitas veces non é) orientada a conexión é posible que as TPDUs cheguen desordenadas ao destino, tendo que encargarse o nivel de transporte do receptor de entregalas secuencialmente á capa superior.

1.4 Multiplexión.

Cando se establecen varias comunicacións entre un equipo e o exterior, é necesario que os distintos procesos do Host teñan asignado un identificador que os diferencie do resto de procesos de transporte que empregan unha mesma tarxeta de rede. O mecanismo polo que cando chega unha TPDU o protocolo de transporte asigna a mesma a un proceso de aplicación empregando a dirección de transporte denomínase multiplexión cara arriba, e permite que varias aplicacións distintas poidan empregar a mesma dirección de rede ao mesmo tempo sen que haxa problemas de identificación das TPDUs.

Outra situación é a da multiplexión cara abaixo, que permite que unha conexión de transporte empregue varias direccións de rede co obxectivo de obter un maior ancho de banda. Este tipo de multiplexión é menos habitual, aínda que no seu momento era fundamental para o bo aproveitamento das liñas RDSI. Non esquezamos que ambas multiplexións poden ser empregadas ao mesmo tempo, con varias aplicacións que empregan unha ou varias direccións de rede para enviar os seus datos de xeito simultáneo.

3


2 UDP (User Data Protocol)

UDP é un dos dous protocolos principais da capa de transporte en Internet. É un protocolo non orientado a conexión e polo tanto moi sinxelo, xa que unicamente inclúe un encabezado corto aos paquetes IP que permite identificar a aplicación á que se refiren, o cal fai posible a multiplexión de varias comunicacións (que non conexións) de transporte de xeito paralelo.

UDP transmite segmentos con un encabezado de 8 bytes seguido pola carga útil que chega do nivel de aplicación. Os campos do encabezado son o porto de orixe e porto de destino, ambos de 16 bits e que se coñecen normalmente polo número decimal correspondente, entre 0 e 65535, dos que os 1024 primeiros serán os Well-Known-Ports, que explicaremos no apartado de TCP. O campo lonxitude UDP indica a lonxitude de cabeceira máis datos, e a suma de verificación é opcional e permite recoñecer erros.

É un protocolo non orientado a conexión que non realiza control de fluxo, control de retransmisión de erros, de paquetes duplicados o de ningún outro tipo, deixando estes controis en mans dos protocolos de aplicación correspondentes, proporcionando unicamente unha interface ao protocolo IP que permite a multiplexión de varios procesos a través dos portos. A súa utilidade é fundamentalmente nas aplicacións cliente-servidor, onde un cliente envía unha solicitude curta ao servidor, esperando unha contestación tamén curta. Se unha petición ou unha resposta se perden, o nivel de aplicación pode simplemente probar a pedila novamente. O sinxelo do protocolo convertese nunha vantaxe para estes casos, dado que o custe de crear a conexión sería en moitos casos superior mesmo ao custe de volver a enviar os datos. Aplicacións de amplio uso en Internet como DNS ou DHCP empregan UDP para o envío de paquetes, nos portos 53 (DNS) e 67-68 (DHCP).

4


3 TCP (Transmission Control Protocol)

O outro protocolo de transporte de Internet é o TCP. Neste caso falamos dun protocolo orientado a conexión, e polo tanto moito máis complexo tanto no que se refire á súa cabeceira como sobre todo no que se refire ao seu funcionamento. A versatilidade deste protocolo, capaz de adaptarse de xeito dinámico ás propiedades da rede e ofrecer un servizo de calidade en condicións de traballo moi distintas como pode ser unha rede local de alta capacidade ou un acceso a Internet de poucos Kilobits por segundo é unha das claves do éxito do TCP/IP como base da Internet.

3.1 Modelo de servizo TCP

O servizo TCP emprega puntos terminais tanto no servidor como no cliente denominados sockets, identificados por unha dirección que consiste na dirección IP do Host e un número de 16 bits chamado porto, exactamente igual que o porto de UDP. As conexións identificaranse mediante os sockets de orixe e destino, é dicir, que cada socket pode empregarse para múltiples conexións co mesmo ou con distintos equipos, pero nunca pode haber dúas conexións que empreguen os mesmos sockets tanto na orixe como no destino. Os números de porto irán do 0 ao 65535, e ao igual que no UDP os 1024 primeiros son os Well-Known-Ports (portos ben coñecidos), que se reservan para servizos estándar que sempre ou case sempre estarán neses portos. As dirección deses portos publícanse por parte do IANA, e non é unha boa práctica facer que outras aplicación empreguen eses portos reservados.

Todas as conexións TCP son dúplex e punto a punto, non soportando multidifusión nin difusión. O fluxo de información é en forma de bytes, non de mensaxes, de xeito que o que se debe asegurar é o fluxo completo de datos sen que sexa necesario (nin posible) coñecer os fragmentos polos que foron enviados. Normalmente os datos recíbense nun buffer de recepción e agardase pola chegada dun grupo de bytes antes de entregalo á capa de aplicación, permitíndose a entrega de datos urxentes en caso necesario.

3.2 O protocolo TCP. Cabeceira

En TCP emisor e receptor intercambian segmentos que consisten nun encabezado TCP fixo de 20 bytes, ao que se lle pode engadir unha parte opcional seguido dos bytes de datos. O protocolo TCP permite establecer o tamaño dos segmentos con un límite dos 65515 bytes do protocolo IP, tendo en conta ademais que cada rede ten unha unidade máxima de transferencia (MTU) na que debe caber cada segmento. Os dous equipos deben indicar cal é o valor da MTU e polo tanto o máximo tamaño dos segmentos, que na maior parte das ocasións terá un valor arredor dos 1500 bytes, o tamaño da carga útil en Ethernet.

5


O protocolo empregado para o control de fluxo é o de ventá corrediza, de xeito que cando un transmisor envía un segmento inicia un temporizador. Cando o segmento chega ao destino o receptor devolve un segmento con datos ou sen eles que contén un número de confirmación de recepción igual ao seguinte número de secuencia do seguinte byte que espera recibir. Se o temporizador expira antes de que chegue a confirmación enviarase novamente o segmento, debendo ser o receptor capaz de identificar se os datos foron ou non recibidos con anterioridade.

A cabeceira TCP consta dos seguintes campos:

• Porto de orixe: 16 bits que identifican o porto TCP de orixe da mensaxe, que xunto coa dirección IP identificada na cabeceira IP permite coñecer o socket de transmisión.

• Porto de destino: 16 bits que identifican o porto TCP de destino da mensaxe, que xunto coa dirección IP de destino identificada na cabeceira IP permite coñecer o socket de recepción, e polo tanto entregar a mensaxe no destino.

• Número de secuencia: O campo número de secuencia identifica a orde do primeiro byte de datos do segmento no total dos bytes que se envían nesa comunicación. Así, se nunha comunicación hai que enviar 5000 bytes en segmentos de 1300 bytes de datos, os números de secuencia serían 0, 1300, 2600 e 3900.

6


• Número de confirmación de recepción: Indica o seguinte byte que espera recibir, é dicir, o número de secuencia que espera que teña o seguinte segmento. Non esquezamos que se poden recibir segmentos desordenados.

• Lonxitude do encabezado TCP: Indica a cantidade de bytes do encabezado en múltiplos de 4, de xeito que o mínimo é 5 cando non hai opcións.

• URG: Indica se hai datos urxentes. Se o valor é 1 haberá datos urxentes que terán que entregarse de xeito inmediato, aínda que non chegase toda a información.

• ACK: Se vale 1 indica que o número de confirmación de recepción é válido, e se é 0 significa que non se está confirmando a recepción de ningún dato.

• PSH: Indica que os datos deben entregarse inmediatamente en vez de esperar por novos segmentos antes de comunicalos ao nivel de aplicación, algo que se fai habitualmente por motivos de eficiencia.

• RST: Serve para restablecer unha conexión que se perdeu por algunha razón. Se aparece un 1 significa que houbo un problema na conexión.

• SYN: Emprégase para establecer conexións. Cando vale 1 e o ACK é 0 trátase de unha solicitude de conexión, se vale 1 e o ACK vale 1 é unha confirmación de conexión.

• FIN: Serve para sinalizar a finalización da conexión.

• Tamaño da ventá: Indica o tamaño da ventá corrediza de tamaño variable empregada polo protocolo TCP. O valor deste campo indica a cantidade de bytes que se lle poden enviar a partir do byte do que se confirma a recepción no mesmo segmento

• Suma de verificación: Permite verificar encabezado e datos do segmento.

• Apuntador urxente: Cando hai datos urxentes permite identificar a partir de que byte dos datos se atopan, xa que é posible que os datos urxentes non se correspondan con todo o segmento enviado (en tal caso o normal sería empregar o PSH)

• Opcións: Permite engadir características extra non cubertas polo encabezado normal, como especificar a carga útil máxima, permitir campos de tamaño de ventá de máis de 16 bits mediante un multiplicador, repetición selectiva de segmentos mediante NACK, controis de tempo....

7


3.3 Establecemento e liberación da conexión

En TCP as conexións establécense empregando o acordo a tres vías comentado anteriormente. Para establecer unha conexión necesitamos un lado servidor que espera pasivamente que se inicie unha conexión, nun estado denominado normalmente LISTEN. No outro lado o cliente comeza a conexión co envío dun segmento TCP no que o destino é a IP e o porto TCP do servizo ao que se quere conectar, no que o bit SYN ten o valor 1 e o bit ACK ten o valor 0.

Cando o servidor recibe un intento de conexión e as normas internas de ese servidor indican que se vai aceptar a conexión, a resposta é un segmento no que o bit SYN ten o valor 1 e o bit ACK ten tamén o valor 1, confirmando a recepción do byte 0 enviando un valor superior en 1 ao número de secuencia do segmento inicial. Isto é unha confirmación de ter recibido a petición de conexión, e os segmentos SYN, que non conteñen ningún dato, se consideran de tamaño 1. Cando o cliente recibe esta confirmación considera aberta a conexión pola súa parte, e envía unha confirmación de recepción deste segmento ao servidor, sen enviar datos. Cando esta mensaxe é recibida polo servidor ambos equipos terán aberta a mesma e poderán intercambiar datos.

Ante calquera perda de segmento o sistema é capaz de recuperarse da mesma, xa que todos os segmentos están numerados e se repetirán en caso de perda. Tamén é capaz de xestionar problemas como a colisión de chamadas cando nos atopamos con dous sockets que poden actuar indistintamente como servidor ou como cliente, e empregando un número de secuencia baseado en reloxo poderase evitar o problema de que unha confirmación perdida nunha conexión anterior se confunda coa actual.

A liberación da conexión en TCP efectúase de xeito diferenciado para os dous sentidos da comunicación. Cando un equipo quere rematar a conexión porque non ten máis datos que enviar, envía un segmento co bit FIN a 1, de xeito que o equipo remoto entende que non se van enviar máis datos nese sentido, enviando un ACK do último segmento. Sen embargo, a conexión está aberta no outro sentido da comunicación, debendo esperar o primeiro equipo a recibir un segmento con bit FIN a 1 para realizar o peche definitivo da mesma. Para evitar que a perda de segmentos deixe a conexión en estado inestable empregaremos temporizadores que darán por rematada unha conexión cando non se reciban confirmacións.

Con todo o estudado ata agora, podemos compoñer o esquema de estados dunha conexión TCP na que non se produzan erros, seguindo a imaxe seguinte. As liñas grosas amosan o funcionamento habitual, no caso do servidor con liñas de puntos. As liñas delgadas amosan as situacións menos habituais. Xunto as liñas se amosan separados por unha barra os eventos que provocan un cambio de estado (en negriña cando son eventos que chegan da capa de aplicación) e as mensaxes enviadas cando se produce dito evento.

8


3.4 Control de conxestión.

Outra das tarefas do protocolo é a de evitar que se produza conxestión, é dicir, que o envío de datos non sature ao receptor ou a rede. En canto ao que se refire ao receptor, xa vimos na cabeceira TCP como cada segmento actualiza a ventá de de transmisión, de xeito que un equipo sabe en cada momento cantos bytes está disposto a recibir o receptor.

Sen embargo, o problema pode responder a que a rede non sexa capaz de xestionar os datos enviados. Neste caso o protocolo non é capaz de negociar entre os extremos cal é a ventá máis axeitada, pero debería ser capaz de atopala. O mecanismo usado é a ventá de conxestión, cantidade de bytes máxima que se considera capaz de xestionar a rede sen ter en conta ao receptor.

9


O funcionamento da ventá de conxestión será tal que se combinará coa ventá de transmisión para que o emisor transmita sen esperar ás confirmacións o valor máis baixo das súas ventás. Deste xeito, se considera que a rede ten alta capacidade pero o receptor soamente é capaz de recibir unha cantidade de datos, non se superará esa cantidade. Se polo contrario o receptor pode recibir unha cantidade maior da que consideramos capaz de xestionar por parte da rede de transmisión, usarase o valor da ventá de conxestión para limitar os datos enviados.

O xeito de atopar cal é a ventá de conxestión é distinto ao da de transmisión, porque como xa dicíamos non é un valor negociado senón un valor que debe atopar o protocolo de xeito indirecto. Unha primeira aproximación é que non se producen perdas de paquetes por ruído, e que polo tanto todas as perdas que se produzan sexan por conxestión na rede. Esta é unha aproximación bastante válida para redes de cable, pero non tanto para redes sen fíos, o que obrigará a tomar medidas para que nestas redes o comportamento de TCP sexa o axeitado. En condicións normais TCP asume polo tanto que se se produce unha perda de segmento a perda ten que ver coa conxestión, xa que o receptor está dispoñible xa que non se superou a ventá de recepción que el mesmo envía e a perda de paquetes por ruído considerase intranscendente.

O cálculo da ventá de conxestión realízase mediante o sistema coñecido por algoritmo de arranque lento. Consiste en que a ventá inicialmente toma o valor do tamaño máximo do segmento, e segundo van chegando as confirmacións de recepción duplícase o seu valor. No momento en que se produza unha expiración do temporizador considerarase que houbo unha perda por conxestión e que a ventá óptima é a atopada no paso anterior.

Para conseguir que o sistema se vaia adaptando aos cambios será necesario ter un sistema que actualice está ventá de conxestión co paso do tempo. O sistema empregado é o uso dun novo parámetro, o umbral. Cando se produce unha expiración do temporizador o umbral fíxase na metade do tamaño da ventá de conxestión, e esta pasa a ser o tamaño de segmento máximo. A partir de aí emprégase o algoritmo de arranque lento para buscar o novo tamaño da ventá de conxestión ata acadar o valor do umbral.

Unha vez que o tamaño da ventá chega a este valor, o tamaño da ventá de conxestión vaise incrementando linealmente, empregando cada vez un tamaño que supera ao anterior nun segmento máximo. Na figura seguinte vemos o tamaño da ventá de conxestión cando se perden dous paquetes, o primeiro deles con ventá de conxestión fixada en 64 KB e con un tamaño máximo de segmento de 1 KB.

10


Como vemos o tamaño da ventá vaise adaptando á situación, producíndose unha lóxica desaceleración dos envíos cando se perde un paquete. Isto ten a vantaxe de que, ademais de preparar a nova busca do tamaño da ventá, reduce o tráfico no momento en que se produce a conxestión, favorecendo a recuperación do sistema.

11


4 NAT estático.

O NAT estático (tamén coñecido como PAT, Port Address Translation) consiste na tradución de direccións IP e porto TCP/UDP dun equipo interno, de xeito que un par IP+porto da porta de enlace da rede está asignada para enviar paquetes ao equipo interno. A interese desta configuración é que, mentres que no NAT dinámico era necesario que un equipo da rede interna iniciase unha comunicación co exterior para que se producise, neste caso podemos ter un servizo na rede interna que sexa accesible desde o exterior mediante a dirección mencionada da porta de enlace.

Este sistema sen embargo ten as súas limitacións. Por exemplo, se queremos ter máis dun servidor web no porto TCP 80 necesitaremos que a nosa porta de enlace dispoña de máis de unha dirección IP, xa que en caso contrario non poderíamos asignar a dous equipos distinto a mesma combinación de porto e IP. Ademais neste caso o sistema non é transparente, é dicir, o administrador debe dar de alta a asignación na porta de enlace para que esta sexa efectiva.

12


Táboa de contidos 1 O servizo de transporte.....................................................................................................................1

1.1 Direccionamento.......................................................................................................................1 1.2 Control da conexión..................................................................................................................2 1.3 Control de fluxo........................................................................................................................3 1.4 Multiplexión..............................................................................................................................3

2 UDP (User Data Protocol)................................................................................................................4 3 TCP (Transmission Control Protocol)..............................................................................................5

3.1 Modelo de servizo TCP............................................................................................................5 3.2 O protocolo TCP. Cabeceira.....................................................................................................5 3.3 Establecemento e liberación da conexión.................................................................................8 3.4 Control de conxestión...............................................................................................................9

4 NAT estático...................................................................................................................................12

13

Analise do nivel de transporte

Documents

Transcript of Analise do nivel de transporte