4.

ETHERNET

Segn IDC a finales de 1997 mas del 85% de las conexiones de red instaladas en el mundo eran
Ethernet, lo cual representa unos 118 millones de ordenadores. El 17% restante estaba formado
por Token Ring, FDDI, ATM y otras tecnologas. Todos los sistemas operativos y aplicaciones
populares son compatibles con Ethernet, as como las pilas de protocolos tales como TCP/IP, IPX,
NetBEUI y DECnet.
Las previsiones para 1998 eran de que el 86% de las nuevas conexiones LAN fueran Ethernet, lo
cual supone mas de 48 millones de interfaces de red y otros tantos puertos de concentradores y
conmutadores. Las ventas de ATM, FDDI, Token Ring y otras tecnologas conjuntamente seran de
5 millones de interfaces y 4 millones de puertos, un 10 y un 7% del total respectivamente.
4.1.1
4.1.1.1

Historia de Ethernet
El Nacimiento

En 1970, mientras Abramson montaba ALOHANET en Hawaii, un estudiante recin graduado en el

MIT llamado Robert Metcalfe se encontraba realizando sus estudios de doctorado en la
Universidad de Harvard trabajando para ARPANET, que era el tema de investigacin candente en
aquellos das. En un viaje a Washington Metcalfe estuvo en casa de Steve Crocker (el inventor de
los RFCs de Internet) donde ste le dej dormir en el sof. Para poder conciliar el sueo Metcalfe
empez a leer una revista cientfica donde encontr un artculo de Norm Abramson en el que
describa la red Aloha. Metcalfe pens como se poda mejorar el protocolo utilizado por Abramson,
y escribi un artculo describiendo un protocolo que mejoraba sustancialmente el rendimiento de
Aloha. Ese artculo se convertira en su tesis doctoral, que present en 1973. La idea bsica era
muy simple: las estaciones antes de transmitir deberan detectar si el canal ya estaba en uso (es
decir si ya haba 'portadora'), en cuyo caso esperaran a que la estacin activa terminara. Adems,
cada estacin mientras transmitiera estara continuamente vigilando el medio fsico por si se
produca alguna colisin, en cuyo caso se parara y retransmitira ms tarde. Este protocolo MAC
recibira ms tarde la denominacin Acceso Mltiple con Deteccin de Portadora y Deteccin de
Colisiones, o mas brevemente CSMA/CD (Carrier Sense Multiple Access / Colision Detect).
En 1972 Metcalfe se mud a California para trabajar en el Centro de Investigacin de Xerox en
Palo Alto llamado Xerox PARC (Palo Alto Research Center). All se estaba diseando lo que se
consideraba la 'oficina del futuro' y Metcalfe encontr un ambiente perfecto para desarrollar sus
inquietudes. Se estaban probando unos ordenadores denominados Alto, que ya disponan de
capacidades grficas y ratn y son considerados los primeros ordenadores personales. Tambin se
estaban fabricando las primeras impresoras lser. Se quera conectar los ordenadores entre s para
compartir ficheros y las impresoras. La comunicacin tena que ser de muy alta velocidad, del
orden de megabits por segundo, ya que la cantidad de informacin a enviar a las impresoras era
enorme (tenan una resolucin y velocidad comparables a una impresora lser actual). Estas ideas
que hoy parecen obvias eran completamente revolucionarias en 1973.
A Metcalfe, el especialista en comunicaciones del equipo con 27 aos de edad, se le encomend la
tarea de disear y construir la red que uniera todo aquello. Contaba para ello con la ayuda de un
estudiante de doctorado de Stanford llamado David Boggs. Las primeras experiencias de la red,
que denominaron Alto Aloha Network, las llevaron a cabo en 1972. Fueron mejorando
gradualmente el prototipo hasta que el 22 de mayo de 1973 Metcalfe escribi un memorndum
interno en el que informaba de la nueva red. Para evitar que se pudiera pensar que slo serva
para conectar ordenadores Alto cambi el nombre de la red por el de Ethernet, que haca

referencia a la teora de la fsica hoy ya abandonada segn la cual las ondas electromagnticas
viajaban por un fluido denominado ter que se supona llenaba todo el espacio (para Metcalfe el
'ter' era el cable coaxial por el que iba la seal). Los dos ordenadores Alto utilizados para las
primeras pruebas de Ethernet fueron rebautizados con los nombres Michelson y Morley, en alusin
a los dos fsicos que demostraron en 1887 la inexistencia del ter mediante el famoso experimento
que lleva su nombre.
La red de 1973 ya tena todas las caractersticas esenciales de la Ethernet actual. Empleaba
CSMA/CD para minimizar la probabilidad de colisin, y en caso de que sta se produjera se pona
en marcha un mecanismo denominado retroceso exponencial binario para reducir gradualmente la
agresividad del emisor, con lo que ste se adaptaba a situaciones de muy diverso nivel de trfico.
Tena topologa de bus y funcionaba a 2,94 Mb/s1 sobre un segmento de cable coaxial de 1,6Km de
longitud. Las direcciones eran de 8 bits y el CRC de las tramas de 16 bits. El protocolo utilizado al
nivel de red era el PUP (Parc Universal Packet) que luego evolucionara hasta convertirse en el
que luego fue XNS (Xerox Network System), antecesor a su vez de IPX (Netware de Novell).
En vez de utilizar el cable coaxial de 75 de las redes de televisin por cable se opt por emplear
cable de 50 que produca menos reflexiones de la seal, a las cuales Ethernet era muy sensible
por transmitir la seal en banda base (es decir sin modulacin). Cada empalme del cable y cada
'pincho' vampiro (transceiver) instalado produca la reflexin de una parte de la seal transmitida.
En la prctica el nmero mximo de pinchos vampiro, y por tanto el nmero mximo de estaciones
en un segmento de cable coaxial, vena limitado por la mxima intensidad de seal reflejada
tolerable.
En 1975 Metcalfe y Boggs describieron Ethernet en un artculo que enviaron a Communications of
the ACM (Association for Computing Machinery), publicado en 1976 [1]. En l ya describan el uso
de repetidores par aumentar el alcance de la red. En 1977 Metcalfe, Boggs y otros dos ingenieros
de Xerox recibieron una patente por la tecnologa bsica de Ethernet, y en 1978 Metcalfe y Boggs
recibieron otra por el repetidor. En esta poca todo el sistema Ethernet era propietario de Xerox.
Aunque no relacionado con Ethernet merece la pena mencionar que David Boggs construy en
1975 en el Xerox PARC el primer router y el primer servidor de nombres de la Internet.
4.1.2
4.1.2.1

Funcionamieneto de Ethernet
Topologa

El correcto funcionamiento de CSMA/CD requiere que el tiempo de ida y vuelta entre dos
estaciones cualesquiera no supere el tiempo de transmisin mnimo, es decir lo que tarda en
emitirse la trama mnima permitida. El tiempo de transmisin mnimo depende de la velocidad de la
red, y el tiempo mximo de ida y vuelta fija a su vez unas distancias mximas entre las estaciones.
Estos cuatro parmetros (velocidad de la red, tamao de trama mnimo, tiempo de ida y vuelta y
distancia mxima) estn relacionados entre s, como se muestra en la tabla 4.7.
Velocidad
(Mb/s)
10
100

Tamao de
trama
mnimo (bits)
512
512

Tiempo de
ida
Y vuelta (s)
51,2
5,12

Distancia
Mxima (m)

Nmero de
Repetidores

4000
412

1
0

1 Se eligi precisamente esta velocidad por ser exactamente la mitad que la del reloj maestro del Alto (5,88 MHz), lo cual permita
aprovechar los tics del reloj y simplificaba el diseo del adaptador de red.

1000

4096

4,096

330

Tabla 4.7.- Relacin entre la velocidad, trama mnima, tiempo de ida y vuelta y distancia
mxima en una red Ethernet.
Las distancias indicadas en la tabla 4.7 son el valor mximo, y slo pueden conseguirse muy
raramente. En la prctica la necesidad de utilizar repetidores reduce la distancia mxima de forma
considerable. En principio una determinada topologa de red es vlida si el tiempo de ida y vuelta
entre cada par de estaciones de la red es inferior al que aparece en la tabla 4.7.
El estndar IEEE 802.3 establece dos formas de verificar si una determinada topologa Ethernet es
vlida. La primera, denominada Modelo 1, corresponde a un conjunto de reglas 'enlatadas' sobre el
nmero mximo de repetidores que puede haber entre dos estaciones, y la distancia mxima entre
ellos. Cumpliendo esas reglas el usuario se asegura de que su red no excede los valores mximos
en el tiempo de ida y vuelta. Sin embargo el Modelo 1 realiza una serie de suposiciones
simplificadoras, por lo que no siempre una topologa que incumpla sus reglas supera el tiempo
mximo de ida y vuelta. Para esos casos el estndar establece el denominado Modelo 2, que
consiste en realizar clculos detallados del retardo para cada componente y tramo de cable en
cada trayecto. Una topologa aceptable segn el Modelo 2 es vlida, aun cuando viole alguna de
las reglas del Modelo 1.
Veamos un ejemplo. Supongamos que queremos montar una red Fast Ethernet 100BASE-TX
conectando entre s dos concentradores de clase II 2. Las reglas del Modelo 1 establecen en este
caso que entre los concentradores no puede haber ms de 5m de cable. Esto da una distancia
mxima entre equipos finales de 205m, 5 entre los concentradores y 100 de cada concentrador al
ordenador (ya que el Modelo 1 supone que el cable del usuario final puede tener hasta 100m de
longitud).
Supongamos que queremos instalar los concentradores separados entre s por una distancia de
100m. En principio esto viola la regla del Modelo I para esta topologa, ya que supondra una
distancia de 300m entre ordenadores, lo cual excede el mximo permitido. Pero imaginemos que
podemos asegurar que los equipos finales nunca utilizarn ms de 50m de cable, con lo que en
principio la distancia mxima no superara los 200m. Vamos a aplicar las reglas del Modelo 2 para
ver si realmente esta topologa es conforme al estndar. Para ello calcularemos el tiempo de ida y
vuelta del trayecto utilizando los valores especificados por el estndar para cada componente. El
trayecto en que estamos interesados es el siguiente:
50m
100m
50m
ordenador ---------------- concentrador ---------------- concentrador ------------------ ordenador
clase II
clase II
Los valores del tiempo de ida y vuelta se detallan en la tabla 4.8.
Componente

Tiempo de ida
y vuelta (en s)

2 Tarjetas de red 100BASE-TX

2 Repetidores clase II
200 metros de cable UTP-5
TOTAL

1,00
1,84
2,22
5,06 s

Tiempo de ida
y vuelta (en
bits)
100
184
222
506 bits

2 En Fast Ethernet existen dos tipos de concentradores, los de clase I que tienen un retardo de 1,4 s (equivalente a 140 bits)
clase II que tienen un retardo de 0,92s (equivalente a 92 bits).

y los de

Tabla 4.8.- Clculo del tiempo de ida y vuelta para una topologa de red 100BASE-TX
siguiendo el Modelo 2
Como el resultado obtenido es inferior a 5,12 s concluimos que la topologa es vlida y debe
funcionar.
Ahora supongamos que sustituimos los cables de 50m por cables de 100m, con lo que la topologa
queda de la siguiente manera:
100m
100m
100m
ordenador ---------------- concentrador ---------------- concentrador ------------------ ordenador
clase II
clase II
Si repetimos el clculo del tiempo de ida y vuelta para este caso obtenemos el resultado que
aparece en la tabla 4.9.
Componente

Tiempo de ida
y vuelta (en s)

2 Tarjetas de red 100BASE-TX

2 Repetidores clase II
300 metros de cable UTP-5
TOTAL

1,00
1,84
3,34
6,18 s

Tiempo de ida
y vuelta (en
bits)
100
184
334
618 bits

Tabla 4.9.- Clculo de una topologa de red 100BASE-TX invlida siguiendo el Modelo 2
Al superar el valor mximo permitido la topologa es invlida, como era de esperar.
Este clculo se debera hacer para el par de estaciones ms distante de la red. Generalmente ser
necesario hacerlo para varias parejas, ya que en una red compleja no suele ser evidente cual es la
que est ms distante.
Similares clculos se pueden hacer tambin para otras topologas para redes de 10, 100 o 1000
Mb/s. Para informacin detallada sobre validacin de topologas en redes Ethernet, siguiendo el
Modelo 1 o el Modelo 2, se pueden consultar las referencias [3], [13], [14] y [15] as como la
documentacin de los fabricantes.
En el ejemplo anterior hemos supuesto los valores estndar de retardo. Los valores reales sern
siempre inferiores. Si se dispone del retardo real suministrado por el fabricante para cada
componente es posible hacer el clculo con mas precisin. Por ejemplo el cable categora 5 debe
tener segn el estndar un retardo mximo de 1,112 bits/m (equivalente a una velocidad de la onda
electromagntica de 180.000 Km/s), pero hoy en da prcticamente todo el cable categora 5 que
se fabrica tiene un retardo de 1,0 bits/m (200.000 Km/s). Tomando esto en cuenta el clculo de la
tabla 4.9 habra dado un resultado final de 4,84 s. En algn caso puede suceder que una
topologa supere el lmite de retardo con valores estndar, pero est por debajo al utilizar los
valores de los componentes utilizados. Aunque dicha topologa es vlida y debe funcionar
correctamente, en general no es recomendable ajustar tanto ya que esto puede suponer que una
determinada topologa vlida deje de serlo si ms adelante se sustituye un componente por otro
con un retardo mayor. Si a pesar de todo se hace deber documentarse el hecho de forma muy
detallada para evitar problemas futuros.

Una ventaja del Modelo 2 es que nos permite conocer el retardo en la comunicacin de
ordenadores de nuestra red; como veremos ms adelante este dato tiene su inters a la hora de
optimizar el rendimiento de la red, y para interpretar de forma correcta datos tales como la tasa de
colisiones.
Es fundamental para el correcto funcionamiento de una red asegurarse de que no se supera en
ningn caso el retardo mximo permitido. En caso de duda siempre deberemos comprobar
recurriendo al clculo detallado en base al Modelo 2. El principal sntoma de una topologa invlida
es la prdida injustificada de tramas y las colisiones tardas, de las que hablaremos mas adelante;
en casos extremos puede llegar a ser imposible el intercambio de paquetes pequeos entre
determinados pares de estaciones de la red.
Por suerte en las redes que se disean actualmente es raro encontrarse con problemas de
topologa, ya que hoy en da los equipos normalmente se conectan directamente a conmutadores,
o si se conectan a concentradores stos solo aparecen en el primer nivel, estando el segundo nivel
y superiores ocupados por un conmutador. Adems al conectar directamente equipo a conmutador
la transmisin puede realizarse en modo full duplex, con lo que desaparecen las colisiones y por
tanto la limitacin de distancias impuesta por la necesidad de detectarlas.
IP4 e IP6
Internet funciona a travs de protocolos, que son combinaciones numricas que establecen
conexiones entre computadoras. Cuando alguien inicia la conexin a Internet, miles de nmeros y
direcciones mantienen esa conexin online.
Los protocolos IPv4 e IPv6, todava causan ciertas dudas a los usuarios de Internet. Es preciso
saber que la norma IPv4 naci junto a la red y ahora est siendo sustituido por el IPv6 pero, en
qu
consiste
cada
protocolo?
IPv4
IPv4 significa Internet Protocol Version 4, o versin 4 del Protocolo de Internet. Es la tecnologa que
permite que los equipos puedan conectarse a Internet, cualquiera sea el dispositivo (PC, notebook,
smartphone, tablet, etc.) Cada uno de ellos en el instante que se conecta a internet, obtiene un
cdigo nico, para poder enviar y recibir datos con otras conexiones.
IPv6
El IPv6 es la sexta revisin de los protocolos de Internet y es el sucesor natural del IPv4.
Esencialmente, cumple la misma funcin, pero en 128 bits.
Por qu se usa el IPv4
El IPv4 transfiere direcciones de protocolos de 32 bits. Sostiene aproximadamente 4,29 billones de
IPs alrededor del mundo, provocando la crisis actual que ocasiona que el sistema ya no soporte
ms
direcciones.
Cmo resolver este problema el IPv6
El
nuevo
sistema
soportar
aproximadamente
340.282.366.920.938.000.000.000.000.000.000.000.000 de direcciones. Un nmero prcticamente
incalculable, pero lo positivo es que lograr soportar la demanda del crecimiento de Internet por
muchos aos. Y eso se debe a que los IPs trabajan en 128 bits.
Cmo se va a realizar el cambio de protocolos?

Los protocolos ya comenzaron a ser sustituidos, es ms, los dos sistemas funcionan
paralelamente. Google, Facebook y otras grandes compaas realizan constantes pruebas para
conocer cmo funcionarn los sistemas cuando comience la migracin definitiva.
Cmo afectar esto a los usuarios?
En primera instancia, no afectar a ningn tipo de usuario. Los sistemas operativos como Windows
7 Service Pack 1, Mac OS X 10.2 y posteriores cuentan con IPv6, el problema est en los routers
que debern ser sustituidos por modelos ms actuales para poder servir a las conexiones.
4.1.3 Protocolo TCP
La descripcin completa del protocolo TCP se encuentra en el documento RFC793 o su traduccin
al espaol. TCP (Transmission-Control-Protocol, en espaol Protocolo de Control de Transmisin)
es uno de los protocolos fundamentales en Internet. Fue creado entre los aos 1973 - 1974 por
Vint Cerf y Robert Kahn.
Muchos programas dentro de una red de datos compuesta por computadoras pueden usar TCP
para crear conexiones entre ellos a travs de las cuales puede enviarse un flujo de datos. El
protocolo garantiza que los datos sern entregados en su destino sin errores y en el mismo orden
en que se transmitieron. Tambin proporciona un mecanismo para distinguir distintas aplicaciones
dentro de una misma mquina, a travs del concepto de puerto.
TCP da soporte a muchas de las aplicaciones ms populares de Internet, incluidas HTTP, SMTP,
SSH y FTP.
TCP es un protocolo de comunicacin orientado a conexin y fiable del nivel de transporte,
actualmente documentado por IETF en el RFC 793. Es un protocolo de capa 4 segn el modelo
OSI.
Funciones de TCP
En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la
aplicacin. Habitualmente, las aplicaciones necesitan que la comunicacin sea fiable y, dado que la
capa IP aporta un servicio de datagramas no fiable (sin confirmacin), TCP aade las funciones
necesarias para prestar un servicio que permita que la comunicacin entre dos sistemas se efecte
libre de errores, sin prdidas y con seguridad.
Los servicios provistos por TCP corren en el anfitrin (host) de cualquiera de los extremos de una
conexin, no en la red. Por lo tanto, TCP es un protocolo para manejar conexiones de extremo a
extremo. Tales conexiones pueden existir a travs de una serie de conexiones punto a punto, por lo
que estas conexiones extremo-extremo son llamadas circuitos virtuales. Las caractersticas del
TCP son:

Orientado a la conexin: dos computadoras establecen una conexin para intercambiar

datos. Los sistemas de los extremos se sincronizan con el otro para manejar el flujo de
paquetes y adaptarse a la congestin de la red.

Operacin Full-Duplex: una conexin TCP es un par de circuitos virtuales, cada uno en una
direccin. Slo los dos sistemas finales sincronizados pueden usar la conexin.

Error Checking: una tcnica de checksum es usada para verificar que los paquetes no
estn corruptos.

Acknowledgements: sobre recibo de uno o ms paquetes, el receptor regresa un

acknowledgement (reconocimiento) al transmisor indicando que recibi los paquetes. Si los
paquetes no son notificados, el transmisor puede reenviar los paquetes o terminar la
conexin si el transmisor cree que el receptor no est ms en la conexin.

Flow Control: si el transmisor est desbordando el buffer del receptor por transmitir
demasiado rpido, el receptor descarta paquetes. Los acknowledgement fallidos que llegan
al transmisor le alertan para bajar la tasa de transferencia o dejar de transmitir.

Servicio de recuperacin de Paquetes: el receptor puede pedir la retransmisin de un

paquete. Si el paquete no es notificado como recibido (ACK), el transmisor enva de nuevo
el paquete.

Los servicios confiables de entrega de datos son crticos para aplicaciones tales como
transferencias de archivos (FTP por ejemplo), servicios de bases de datos, proceso de
transacciones y otras aplicaciones de misin crtica en las cuales la entrega de cada paquete debe
ser garantizada.
Formato de los Segmentos TCP
En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de protocolo o
PDU ('Protocol Data Unit') se llaman "segmentos". El formato de los segmentos TCP se muestra en
el siguiente esquema:

Bits 0 - 3 4 - 7

Puerto Origen

32

Nmero de Secuencia

64

Nmero de Acuse de Recibo (ACK)

96

longitud
cabecer
a TCP

128

Suma de Verificacin (Checksum)

160

Opciones + Relleno (opcional)

Reservad
o

8 - 15

16 - 31

Puerto Destino

Flags

Ventana

Puntero Urgente

224

Datos

Datos
Las aplicaciones envan flujos de bytes a la capa TCP para ser enviados a la red. TCP divide el
flujo de bytes llegado de la aplicacin en segmentos de tamao apropiado (normalmente esta
limitacin viene impuesta por la unidad mxima de transferencia (MTU) del nivel de enlace de
datos de la red a la que la entidad est asociada) y le aade sus cabeceras. Entonces, TCP pasa
el segmento resultante a la capa IP, donde a travs de la red, llega a la capa TCP de la entidad
destino. TCP comprueba que ningn segmento se ha perdido dando a cada uno un nmero de
secuencia, que es tambin usado para asegurarse de que los paquetes han llegado a la entidad
destino en el orden correcto. TCP devuelve un asentimiento por bytes que han sido recibidos
correctamente; un temporizador en la entidad origen del envo causar un timeout si el
asentimiento no es recibido en un tiempo razonable, y el (presuntamente desaparecido) paquete
ser entonces retransmitido. TCP revisa que no haya bytes daados durante el envo usando un
checksum; es calculado por el emisor en cada paquete antes de ser enviado, y comprobado por el
receptor.

Puerto de origen (16 bits): Identifica el puerto a travs del que se enva.

Puerto destino (16 bits): Identifica el puerto del receptor.

Nmero de secuencia (32 bits): Sirve para comprobar que ningn segmento se ha perdido,
y que llegan en el orden correcto. Su significado vara dependiendo del valor de SYN:

Si el flag SYN est activo (1), entonces este campo indica el nmero inicial de secuencia
(con lo cual el nmero de secuencia del primer byte de datos ser este nmero de
secuencia ms uno).

Si el flag SYN no est activo (0), entonces este campo indica el nmero de secuencia del
primer byte de datos.

Nmero de acuse de recibo (ACK) (32 bits): Si el flag ACK est puesto a activo, entonces
en este campo contiene el nmero de secuencia del siguiente paquete que el receptor
espera recibir.

Longitud de la cabecera TCP (4 bits): Especifica el tamao de la cabecera TCP en

palabras de 32-bits. El tamao mnimo es de 5 palabras, y el mximo es de 15 palabras (lo
cual equivale a un tamao mnimo de 20 bytes y a un mximo de 60 bytes). En ingls el
campo se denomina Data offset, que literalmente sera algo as como desplazamiento
hasta los datos, ya que indica cuntos bytes hay entre el inicio del paquete TCP y el inicio
de los datos.

Reservado (4 bits): Bits reservados para uso futuro, deberan ser puestos a cero.

Bits de control (flags) (8 bits): Son 8 flags o banderas. Cada una indica activa con un 1 o
inactiva con un 0.

CWR o Congestion Window Reduced (1 bit): Este flag se activa (se pone a 1) por parte
del emisor para indicar que ha recibido un paquete TCP con el flag ECE activado. El flag
ECE es una extensin del protocolo que fue aadida a la cabecera en el RFC 3168. Se
utiliza para el control de la congestin en la red.

ECE o ECN-Echo (1 bit): Indica que el receptor puede realizar notificaciones ECN. La
activacin de este flag se realiza durante la negociacin en tres pasos para el
establecimiento de la conexin. Este flag tambin fue aadido a la cabecera en el RFC
3168.

URG o urgent (1 bit, ver URG): Si est activo significa que el campo Urgente es
significativo, si no, el valor de este campo es ignorado.

ACK o acknowledge (1 bit, ver ACK): Si est activo entonces el campo con el nmero de
acuse de recibo es vlido (si no, es ignorado).

PSH o push (1 bit, ver PSH): Activa/desactiva la funcin que hace que los datos de ese
segmento y los datos que hayan sido almacenados anteriormente en el buffer del receptor
deben ser transferidos a la aplicacin receptora lo antes posible.

RST o reset (1 bit, ver Flag RST): Si llega a 1, termina la conexin sin esperar respuesta.

SYN o synchronize (1 bit, ver SYN): Activa/desactiva la sincronizacin de los nmeros de

secuencia.

FIN (1 bit, ver FIN): Si se activa es porque no hay ms datos a enviar por parte del emisor,
esto es, el paquete que lo lleva activo es el ltimo de una conexin.

Ventana (16 bits): Es el tamao de la ventana de recepcin, que especifica el nmero de

bytes que el receptor est actualmente esperando recibir.

Suma de verificacin (checksum) (16 bits): Es una suma de verificacin utilizada para
comprobar si hay errores tanto en la cabecera como en los datos.

Puntero urgente (16 bits): Si el flag URG est activado, entonces este campo indica el
desplazamiento respecto al nmero de secuencia que indica el ltimo byte de datos
marcados como urgentes.

Opciones (nmero de bits variable): La longitud total del campo de opciones ha de ser
mltiplo de una palabra de 32 bits (si es menor, se ha de rellenar al mltiplo ms cercano),
y el campo que indica la longitud de la cabecera ha de estar ajustado de forma adecuada.

Datos (nmero de bits variable): No forma parte de la cabecera, es la carga (payload), la

parte con los datos del paquete TCP. Pueden ser datos de cualquier protocolo de nivel
superior en el nivel de aplicacin; los protocolos ms comunes para los que se usan los
datos de un paquete TCP son HTTP, telnet, SSH, FTP, etctera.

Detalles del funcionamiento

Las conexiones TCP se componen de tres etapas: establecimiento de conexin, transferencia de
datos y fin de la conexin. Para establecer la conexin se usa el procedimiento llamado
negociacin en tres pasos (3-way handshake). Una negociacin en cuatro pasos (4-way

handshake) es usada para la desconexin. Durante el establecimiento de la conexin, algunos

parmetros como el nmero de secuencia son configurados para asegurar la entrega ordenada de
los datos y la robustez de la comunicacin.

Negociacin en tres pasos o Three-way handshake

Establecimiento de la negociacin
Aunque es posible que un par de entidades finales comiencen una conexin entre ellas
simultneamente, normalmente una de ellas abre un socket en un determinado puerto tcp y se
queda a la escucha de nuevas conexiones. Es comn referirse a esto como apertura pasiva, y
determina el lado servidor de una conexin. El lado cliente de una conexin realiza una apertura
activa de un puerto enviando un paquete SYN inicial al servidor como parte de la negociacin en
tres pasos. En el lado del servidor se comprueba si el puerto est abierto, es decir, si existe algn
proceso escuchando en ese puerto. En caso de no estarlo, se enva al cliente un paquete de
respuesta con el bit RST activado, lo que significa el rechazo del intento de conexin. En caso de
que s se encuentre abierto el puerto, el lado servidor respondera a la peticin SYN vlida con un
paquete SYN/ACK. Finalmente, el cliente debera responderle al servidor con un ACK,
completando as la negociacin en tres pasos (SYN, SYN/ACK y ACK) y la fase de establecimiento
de conexin.
Transferencia de datos
Durante la etapa de transferencia de datos, una serie de mecanismos claves determinan la
fiabilidad y robustez del protocolo. Entre ellos estn incluidos el uso del nmero de secuencia para
ordenar los segmentos TCP recibidos y detectar paquetes duplicados, checksums para detectar
errores, y asentimientos y temporizadores para detectar prdidas y retrasos.
Durante el establecimiento de conexin TCP, los nmeros iniciales de secuencia son
intercambiados entre las dos entidades TCP. Estos nmeros de secuencia son usados para
identificar los datos dentro del flujo de bytes, y poder identificar (y contar) los bytes de los datos de
la aplicacin. Siempre hay un par de nmeros de secuencia incluidos en todo segmento TCP,
referidos al nmero de secuencia y al nmero de asentimiento. Un emisor TCP se refiere a su
propio nmero de secuencia cuando habla de nmero de secuencia, mientras que con el nmero
de asentimiento se refiere al nmero de secuencia del receptor. Para mantener la fiabilidad, un
receptor asiente los segmentos TCP indicando que ha recibido una parte del flujo continuo de

bytes. Una mejora de TCP, llamada asentimiento selectivo (SACK, Selective Acknowledgement)
permite a un receptor TCP asentir los datos que se han recibido de tal forma que el remitente solo
retransmita los segmentos de datos que faltan.
A travs del uso de nmeros de secuencia y asentimiento, TCP puede pasar los segmentos
recibidos en el orden correcto dentro del flujo de bytes a la aplicacin receptora. Los nmeros de
secuencia son de 32 bits (sin signo), que vuelve a cero tras el siguiente byte despus del 232-1.
Una de las claves para mantener la robustez y la seguridad de las conexiones TCP es la seleccin
del nmero inicial de secuencia (ISN, Initial Sequence Number).
Un checksum de 16 bits, consistente en el complemento a uno de la suma en complemento a uno
del contenido de la cabecera y datos del segmento TCP, es calculado por el emisor, e incluido en la
transmisin del segmento. Se usa la suma en complemento a uno porque el acarreo final de ese
mtodo puede ser calculado en cualquier mltiplo de su tamao (16-bit, 32-bit, 64-bit...) y el
resultado, una vez plegado, ser el mismo. El receptor TCP recalcula el checksum sobre las
cabeceras y datos recibidos. El complemento es usado para que el receptor no tenga que poner a
cero el campo del checksum de la cabecera antes de hacer los clculos, salvando en algn lugar el
valor del checksum recibido; en vez de eso, el receptor simplemente calcula la suma en
complemento a uno con el checksum incluido, y el resultado debe ser igual a 0. Si es as, se asume
que el segmento ha llegado intacto y sin errores.
Hay que fijarse en que el checksum de TCP tambin cubre los 96 bit de la cabecera que contiene
la direccin origen, la direccin destino, el protocolo y el tamao TCP. Esto proporciona proteccin
contra paquetes mal dirigidos por errores en las direcciones.
El checksum de TCP es una comprobacin bastante dbil. En niveles de enlace con una alta
probabilidad de error de bit quiz requiera una capacidad adicional de correccin/deteccin de
errores de enlace. Si TCP fuese rediseado hoy, muy probablemente tendra un cdigo de
redundancia cclica (CRC) para control de errores en vez del actual checksum. La debilidad del
checksum est parcialmente compensada por el extendido uso de un CRC en el nivel de enlace,
bajo TCP e IP, como el usado en el PPP o en Ethernet. Sin embargo, esto no significa que el
checksum de 16 bits es redundante: sorprendentemente, inspecciones sobre el trfico de Internet
han mostrado que son comunes los errores de software y hardware[cita requerida] que introducen
errores en los paquetes protegidos con un CRC, y que el checksum de 16 bits de TCP detecta la
mayora de estos errores simples.
Los asentimientos (ACKs o Acknowledgments) de los datos enviados o la falta de ellos, son usados
por los emisores para interpretar las condiciones de la red entre el emisor y receptor TCP. Unido a
los temporizadores, los emisores y receptores TCP pueden alterar el comportamiento del
movimiento de datos. TCP usa una serie de mecanismos para conseguir un alto rendimiento y
evitar la congestin de la red (la idea es enviar tan rpido como el receptor pueda recibir). Estos
mecanismos incluyen el uso de ventana deslizante, que controla que el transmisor mande
informacin dentro de los lmites del buffer del receptor, y algoritmos de control de flujo, tales como
el algoritmo de Evitacin de la Congestin (congestion avoidance), el de comienzo lento (Slowstart), el de retransmisin rpida, el de recuperacin rpida (Fast Recovery), y otros.
Es interesante notar que existe un nmero de secuencia generado por cada lado, ayudando de
este modo a que no se puedan establecer conexiones falseadas (spoofing).
Tamao de ventana
El tamao de la ventana de recepcin TCP es la cantidad de datos recibidos (en bytes) que pueden
ser metidos en el buffer de recepcin durante la conexin. La entidad emisora puede enviar una
cantidad determinada de datos pero antes debe esperar un asentimiento con la actualizacin del
tamao de ventana por parte del receptor.

Un ejemplo sera el siguiente: un receptor comienza con un tamao de ventana x y recibe y bytes,
entonces su tamao de ventana ser (x - y) y el transmisor slo podr mandar paquetes con un
tamao mximo de datos de (x - y) bytes. Los siguientes paquetes recibidos seguirn restando
tamao a la ventana de recepcin. Esta situacin seguir as hasta que la aplicacin receptora
recoja los datos del buffer de recepcin. Para una mayor eficiencia en redes de gran ancho de
banda, debe ser usado un tamao de ventana mayor. El campo TCP de tamao de ventana
controla el movimiento de datos y est limitado a 16 bits, es decir, a un tamao de ventana de
65.535 bytes.
Escalado de ventana
Como el campo de ventana no puede expandirse se usa un factor de escalado. La escala de
ventana TCP (TCP window scale) es una opcin usada para incrementar el mximo tamao de
ventana desde 65.535 bytes, a 1 Gigabyte.
La opcin de escala de ventana TCP es usada solo durante la negociacin en tres pasos que
constituye el comienzo de la conexin. El valor de la escala representa el nmero de bits
desplazados a la izquierda de los 16 bits que forman el campo del tamao de ventana. El valor de
la escala puede ir desde 0 (sin desplazamiento) hasta 14. Hay que recordar que un nmero binario
desplazado un bit a la izquierda es como multiplicarlo en base decimal por 2.
Fin de la conexin
La fase de finalizacin de la conexin usa una negociacin en cuatro pasos (four-way handshake),
terminando la conexin desde cada lado independientemente. Cuando uno de los dos extremos de
la conexin desea parar su "mitad" de conexin transmite un paquete FIN, que el otro interlocutor
asentir con un ACK. Por tanto, una desconexin tpica requiere un par de segmentos FIN y ACK
desde cada lado de la conexin.
Una conexin puede estar "medio abierta" en el caso de que uno de los lados la finalice pero el
otro no. El lado que ha dado por finalizada la conexin no puede enviar ms datos pero la otra
parte si podr.
Puertos TCP
TCP usa el concepto de nmero de puerto para identificar a las aplicaciones emisoras y
receptoras. Cada lado de la conexin TCP tiene asociado un nmero de puerto (de 16 bits sin
signo, con lo que existen 65536 puertos posibles) asignado por la aplicacin emisora o receptora.
Los puertos son clasificados en tres categoras: bien conocidos, registrados y dinmicos/privados.
Los puertos bien conocidos son asignados por la Internet Assigned Numbers Authority (IANA), van
del 0 al 1023 y son usados normalmente por el sistema o por procesos con privilegios. Las
aplicaciones que usan este tipo de puertos son ejecutadas como servidores y se quedan a la
escucha de conexiones. Algunos ejemplos son: FTP (21), SSH (22), Telnet (23), SMTP (25) y HTTP
(80). Los puertos registrados son normalmente empleados por las aplicaciones de usuario de forma
temporal cuando conectan con los servidores, pero tambin pueden representar servicios que
hayan sido registrados por un tercero (rango de puertos registrados: 1024 al 49151). Los puertos
dinmicos/privados tambin pueden ser usados por las aplicaciones de usuario, pero este caso es
menos comn. Los puertos dinmicos/privados no tienen significado fuera de la conexin TCP en
la que fueron usados (rango de puertos dinmicos/privados: 49152 al 65535, recordemos que el
rango total de 2 elevado a la potencia 16, cubre 65536 nmeros, del 0 al 65535).
Desarrollo de TCP
TCP es un protocolo muy desarrollado y complejo. Sin embargo, mientras mejoras significativas
han sido propuestas y llevadas a cabo a lo largo de los aos, ha conservado las operaciones ms
bsicas sin cambios desde el RFC 793, publicado en 1981. El documento RFC 1122 (Host
Requirements for Internet Hosts), especifica el nmero de requisitos de una implementacin del
protocolo TCP. El RFC 2581 (Control de Congestin TCP) es uno de los ms importantes
documentos relativos a TCP de los ltimos aos, describe nuevos algoritmos para evitar la

congestin excesiva. En 2001, el RFC 3168 fue escrito para describir la Notificacin de Congestin
Explcita (ECN), una forma de eludir la congestin con mecanismos de sealizacin. En los
comienzos del siglo XXI, TCP es usado en el 95% de todos los paquetes que circulan por Internet.
Entre las aplicaciones ms comunes que usan TCP estn HTTP/HTTPS (World Wide Web),
SMTP/POP3/IMAP (correo electrnico) y FTP (transferencia de ficheros). Su amplia extensin ha
sido la prueba para los desarrolladores originales de que su creacin estaba excepcionalmente
bien hecha.
Recientemente, un nuevo algoritmo de control de congestin fue desarrollado y nombrado como
FAST TCP (Fast Active queue management Scalable Transmission Control Protocol) por los
cientficos de Caltech (California Institute of Technology). Es similar a TCP Vegas en cuanto a que
ambos detectan la congestin a partir de los retrasos en las colas que sufren los paquetes al ser
enviados a su destino. Todava hay un debate abierto sobre si ste es un sntoma apropiado para
el control de la congestin.
4.1.4 Protocolo UDP
La descripcin completa del protocolo UDP se encuentra en el documento RFC768 o su traduccin
al espaol.
User Datagram Protocol (UDP) es un protocolo del nivel de transporte basado en el intercambio de
datagramas. Permite el envo de datagramas a travs de la red sin que se haya establecido
previamente una conexin, ya que el propio datagrama incorpora suficiente informacin de
direccionamiento en su cabecera. Tampoco tiene confirmacin ni control de flujo, por lo que los
paquetes pueden adelantarse unos a otros; y tampoco se sabe si ha llegado correctamente, ya que
no hay confirmacin de entrega o recepcin. Su uso principal es para protocolos como DHCP,
BOOTP, DNS y dems protocolos en los que el intercambio de paquetes de la
conexin/desconexin son mayores, o no son rentables con respecto a la informacin transmitida,
as como para la transmisin de audio y vdeo en tiempo real, donde no es posible realizar
retransmisiones por los estrictos requisitos de retardo que se tiene en estos casos.
Descripcin
User Datagram Protocol (UDP) es un protocolo mnimo de nivel de transporte orientado a mensajes
documentado en el RFC 768 de la IETF.
En la familia de protocolos de Internet UDP proporciona una sencilla interfaz entre la capa de red y
la capa de aplicacin. UDP no otorga garantas para la entrega de sus mensajes y el origen UDP
no retiene estados de los mensajes UDP que han sido enviados a la red. UDP slo aade
multiplexado de aplicacin y suma de verificacin de la cabecera y la carga til. Cualquier tipo de
garantas para la transmisin de la informacin deben ser implementadas en capas superiores.
La cabecera UDP consta de 4 campos de los cuales 2 son opcionales (con fondo rojo en la tabla).
Los campos de los puertos fuente y destino son campos de 16 bits que identifican el proceso de
origen y recepcin. Ya que UDP carece de un servidor de estado y el origen UDP no solicita
respuestas, el puerto origen es opcional. En caso de no ser utilizado, el puerto origen debe ser
puesto a cero. A los campos del puerto destino le sigue un campo obligatorio que indica el tamao
en bytes del datagrama UDP incluidos los datos. El valor mnimo es de 8 bytes. El campo de la
cabecera restante es una suma de comprobacin de 16 bits que abarca la cabecera, los datos y
una pseudo-cabecera con las IP origen y destino, el protocolo, la longitud del datagrama y 0's hasta
completar un mltiplo de 16. pero no los datos. El checksum tambin es opcional, aunque
generalmente se utiliza en la prctica.
El protocolo UDP se utiliza por ejemplo cuando se necesita transmitir voz o vdeo y resulta ms
importante transmitir con velocidad que garantizar el hecho de que lleguen absolutamente todos los
bytes.

Puertos
UDP utiliza puertos para permitir la comunicacin entre aplicaciones. El campo de puerto tiene una
longitud de 16 bits, por lo que el rango de valores vlidos va de 0 a 65.535. El puerto 0 est
reservado, pero es un valor permitido como puerto origen si el proceso emisor no espera recibir
mensajes como respuesta.
Los puertos 1 a 1023 se llaman puertos "bien conocidos" y en sistemas operativos tipo Unix
enlazar con uno de estos puertos requiere acceso como superusuario.
Los puertos 1024 a 49.151 son puertos registrados.
Los puertos 49.152 a 65.535 son puertos efmeros y son utilizados como puertos temporales, sobre
todo por los clientes al comunicarse con los servidores.
Ejemplo en python
El siguiente ejemplo muestra cmo usar el protocolo UDP para una comunicacin cliente/servidor:

Servidor:
import socket
PUERTO = 10000
BUFLEN = 512
server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
server.bind(('', PUERTO))
while True:
(message, address) = server.recvfrom(BUFLEN)
print 'Recibiendo paquete desde %s:%d' % (address[0], address[1])
print 'Dato: %s' % message
Cliente (Cambia "127.0.0.1" por la direccin IP del servidor):
import socket
IP_SERVIDOR = '127.0.0.1'
PUERTO_SERVIDOR = 10000
client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
for i in range(3):
print 'Enviando paquete %d' % i
message = 'Este es el paquete %d' % i
client.sendto(message, (IP_SERVIDOR, PUERTO_SERVIDOR))
client.close()
Ejemplo en C++
El siguiente ejemplo muestra cmo usar el protocolo UDP para una comunicacin cliente/servidor:

Servidor:

#include <winsock.h>
#pragma comment(lib,"ws2_32.lib")
int main()
{
WSADATA wsaData;
SOCKET RecvSocket;
sockaddr_in RecvAddr;
int Puerto = 2345;
char RecvBuf[1024];
int BufLen = 1024;
sockaddr_in SenderAddr;
int SenderAddrSize = sizeof(SenderAddr);
WSAStartup(MAKEWORD(2,2), &wsaData);
RecvSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
RecvAddr.sin_family = AF_INET;
RecvAddr.sin_port = htons(Puerto);
RecvAddr.sin_addr.s_addr = INADDR_ANY;
bind(RecvSocket, (SOCKADDR *) &RecvAddr, sizeof(RecvAddr));
recvfrom(RecvSocket,RecvBuf,
BufLen,0,(SOCKADDR
*)&SenderAddr,&SenderAddrSize);
printf("%s\n",RecvBuf);
closesocket(RecvSocket);
WSACleanup();
}
Cliente (Cambia "127.0.0.1" por la direccin IP del servidor):
#include <winsock.h>
#pragma comment(lib,"ws2_32.lib")
int main()
{
WSADATA wsaData;
SOCKET SendSocket;
sockaddr_in RecvAddr;
int Puerto = 2345;
char ip[] = "127.0.0.1";
char SendBuf[] = "Hola!!!!";
WSAStartup(MAKEWORD(2,2), &wsaData);
SendSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
RecvAddr.sin_family = AF_INET;
RecvAddr.sin_port = htons(Puerto);
RecvAddr.sin_addr.s_addr = inet_addr(ip);
sendto(SendSocket,SendBuf,strlen(SendBuf)+1,0,(SOCKADDR
&RecvAddr,sizeof(RecvAddr));
WSACleanup();
}
4.1.5
UDP

*)

Comparativa entre UDP y TCP

Proporciona un nivel de transporte no fiable de datagramas, ya que apenas aade la
informacin necesaria para la comunicacin extremo a extremo al paquete que enva al
nivel inferior. Lo utilizan aplicaciones como NFS (Network File System) y RCP (comando
para copiar ficheros entre ordenadores remotos), pero sobre todo se emplea en tareas de
control y en la transmisin de audio y vdeo a travs de una red. No introduce retardos para
establecer una conexin, no mantiene estado de conexin alguno y no realiza seguimiento

de estos parmetros. As, un servidor dedicado a una aplicacin particular puede soportar
ms clientes activos cuando la aplicacin corre sobre UDP en lugar de sobre TCP.
TCP
Es el protocolo que proporciona un transporte fiable de flujo de bits entre aplicaciones. Est
pensado para poder enviar grandes cantidades de informacin de forma fiable, liberando al
programador de la dificultad de gestionar la fiabilidad de la conexin (retransmisiones,
prdida de paquetes, orden en el que llegan los paquetes, duplicados de paquetes...) que
gestiona el propio protocolo. Pero la complejidad de la gestin de la fiabilidad tiene un
coste en eficiencia, ya que para llevar a cabo las gestiones anteriores se tiene que aadir
bastante informacin a los paquetes que enviar. Debido a que los paquetes para enviar
tienen un tamao mximo, cuanta ms informacin aada el protocolo para su gestin,
menos informacin que proviene de la aplicacin podr contener ese paquete (el segmento
TCP tiene una sobrecarga de 20 bytes en cada segmento, mientras que UDP solo aade 8
bytes). Por eso, cuando es ms importante la velocidad que la fiabilidad, se utiliza UDP. En
cambio, TCP asegura la recepcin en destino de la informacin para transmitir.
4.1.5.1 Transmisin de vdeo y voz
UDP es generalmente el protocolo usado en la transmisin de vdeo y voz a travs de una red.
Esto es porque no hay tiempo para enviar de nuevo paquetes perdidos cuando se est escuchando
a alguien o viendo un vdeo en tiempo real.
Ya que tanto TCP como UDP circulan por la misma red, en muchos casos ocurre que el aumento
del trfico UDP daa el correcto funcionamiento de las aplicaciones TCP. Por defecto, TCP pasa a
un segundo lugar para dejar a los datos en tiempo real usar la mayor parte del ancho de banda. El
problema es que ambos son importantes para la mayor parte de las aplicaciones, por lo que
encontrar el equilibrio entre ambos es crucial.
4.1.5.2 Lista de puertos UDP
Nmeros de puerto bien conocidos usados por TCP y UDP. Tambin se aade algn otro puerto no
asignado oficialmente por IANA, pero de inters general dado el uso extendido que le da alguna
aplicacin.
Puerto/prot
Descripcin
ocolo
n/d / GRE

GRE (protocolo IP 47) Enrutamiento y acceso remoto

n/d / ESP

IPSec ESP (protocolo IP 50) Enrutamiento y acceso remoto

n/d / AH

IPSec AH (protocolo IP 51) Enrutamiento y acceso remoto

1/tcp

Multiplexor TCP

7/tcp

Protocolo Echo (Eco) Reponde con eco a llamadas remotas

7/udp

Protocolo Echo (Eco) Reponde con eco a llamadas remotas

9/tcp

Protocolo Discard Elimina cualquier dato que recibe

9/udp

Protocolo Discard Elimina cualquier dato que recibe

13/tcp

Protocolo Daytime Fecha y hora actuales

17/tcp

Quote of the Day (Cita del Da)

19/tcp

Protocolo Chargen Generador de caractres

19/udp

Protocolo Chargen Generador de caractres

20/tcp

FTP File Transfer Protocol (Protocolo de Transferencia de Ficheros) - datos

21/tcp

FTP File Transfer Protocol (Protocolo de Transferencia de Ficheros) - control

22/tcp

SSH, scp, SFTP

23/tcp

Telnet comunicaciones de texto inseguras

25/tcp

SMTP Simple Mail Transfer Protocol (Protocolo Simple de Transferencia de Correo)

37/tcp

time

43/tcp

nicname

53/tcp

DNS Domain Name System (Sistema de Nombres de Dominio)

53/udp

DNS Domain Name System (Sistema de Nombres de Dominio)

67/udp

BOOTP BootStrap Protocol (Server), tambin usado por DHCP

68/udp

BOOTP BootStrap Protocol (Client), tambin usado por DHCP

69/udp

TFTP Trivial File Transfer Protocol (Protocolo Trivial de Transferencia de Ficheros)

70/tcp

Gopher

79/tcp

Finger

80/tcp

HTTP HyperText Transfer Protocol (Protocolo de Transferencia de HiperTexto)

(WWW)

88/tcp

Kerberos Agente de autenticacin

110/tcp

POP3 Post Office Protocol (E-mail)

111/tcp

sunrpc

113/tcp

ident (auth) antiguo sistema de identificacin

119/tcp

NNTP usado en los grupos de noticias de usenet

123/udp

NTP Protocolo de sincronizacin de tiempo

123/tcp

NTP Protocolo de sincronizacin de tiempo

135/tcp

epmap

137/tcp

NetBIOS Servicio de nombres

137/udp

NetBIOS Servicio de nombres

138/tcp

NetBIOS Servicio de envo de datagramas

138/udp

NetBIOS Servicio de envo de datagramas

139/tcp

NetBIOS Servicio de sesiones

139/udp

NetBIOS Servicio de sesiones

143/tcp

IMAP4 Internet Message Access Protocol (E-mail)

161/tcp

SNMP Simple Network Management Protocol

161/udp

SNMP Simple Network Management Protocol

162/tcp

SNMP-trap

162/udp

SNMP-trap

177/tcp

XDMCP Protocolo de gestin de displays en X11

177/udp

XDMCP Protocolo de gestin de displays en X11

389/tcp

LDAP Protocolo de acceso ligero a Bases de Datos

389/udp

LDAP Protocolo de acceso ligero a Bases de Datos

443/tcp

HTTPS/SSL usado para la transferencia segura de pginas web

445/tcp

Microsoft-DS (Active Directory, comparticin en Windows, gusano Sasser, Agobot)

445/udp

Microsoft-DS comparticin de ficheros

500/udp

IPSec ISAKMP, Autoridad de Seguridad Local

512/tcp

exec

513/tcp

login

514/udp

syslog usado para logs del sistema

520/udp

RIP

591/tcp

FileMaker 6.0 (alternativa para HTTP, ver puerto 80)

631/tcp

CUPS sistema de impresin de Unix

666/tcp

identificacin de Doom para jugar sobre TCP

993/tcp

IMAP4 sobre SSL (E-mail)

995/tcp

POP3 sobre SSL (E-mail)

1080/tcp

SOCKS Proxy

1337/tcp

suele usarse en mquinas comprometidas o infectadas

1352/tcp

IBM Lotus Notes/Domino RCP

1433/tcp

Microsoft-SQL-Server

1434/tcp

Microsoft-SQL-Monitor

1434/udp

Microsoft-SQL-Monitor

1494/tcp

Citrix MetaFrame Cliente ICA

1512/tcp

WINS

1521/tcp

Oracle listener por defecto

1701/udp

Enrutamiento y Acceso Remoto para VPN con L2TP.

1723/tcp

Enrutamiento y Acceso Remoto para VPN con PPTP.

1761/tcp

Novell Zenworks Remote Control utility

1863/tcp

MSN Messenger

1935/???

FMS Flash Media Server

2049/tcp

NFS Archivos del sistema de red

2082/tcp

CPanel puerto por defecto

2086/tcp

Web Host Manager puerto por defecto

2427/upd

Cisco MGCP

3030/tcp

NetPanzer

3030/upd

NetPanzer

3128/tcp

HTTP usado por web caches y por defecto en Squid cache

3128/tcp

NDL-AAS

3306/tcp

MySQL sistema de gestin de bases de datos

3389/tcp

RDP (Remote Desktop Protocol)

3396/tcp

Novell agente de impresin NDPS

3690/tcp

Subversion (sistema de control de versiones)

4662/tcp

eMule (aplicacin de comparticin de ficheros)

4672/udp

eMule (aplicacin de comparticin de ficheros)

4899/tcp

RAdmin (Remote Administrator), herramienta de administracin remota (normalmente

troyanos)

5000/tcp

Universal plug-and-play

5060/udp

Session Initiation Protocol (SIP)

5190/tcp

AOL y AOL Instant Messenger

5222/tcp

XMPP/Jabber conexin de cliente

5223/tcp

XMPP/Jabber puerto por defecto para conexiones de cliente SSL

5269/tcp

XMPP/Jabber conexin de servidor

5432/tcp

PostgreSQL sistema de gestin de bases de datos

5517/tcp

Setiqueue proyecto SETI@Home

5631/tcp

PC-Anywhere protocolo de escritorio remoto

5632/udp

PC-Anywhere protocolo de escritorio remoto

5400/tcp

VNC protocolo de escritorio remoto (usado sobre HTTP)

5500/tcp

VNC protocolo de escritorio remoto (usado sobre HTTP)

5600/tcp

VNC protocolo de escritorio remoto (usado sobre HTTP)

5700/tcp

VNC protocolo de escritorio remoto (usado sobre HTTP)

5800/tcp

VNC protocolo de escritorio remoto (usado sobre HTTP)

5900/tcp

VNC protocolo de escritorio remoto (conexin normal)

6000/tcp

X11 usado para X-windows

6112/udp

Blizzard

6129/tcp

Dameware Software conexin remota

6346/tcp

Gnutella comparticin de ficheros (Limewire, etc.)

6347/udp

Gnutella

6348/udp

Gnutella

6349/udp

Gnutella

6350/udp

Gnutella

6355/udp

Gnutella

6667/tcp

IRC IRCU Internet Relay Chat

6881/tcp

BitTorrent puerto por defecto

6969/tcp

BitTorrent puerto de tracker

7100/tcp

Servidor de Fuentes X11

7100/udp

Servidor de Fuentes X11

8000/tcp

iRDMI por lo general, usado errneamente en sustitucin de 8080. Tambin utilizado

en el servidor de streaming ShoutCast.

8080/tcp

HTTP HTTP-ALT ver puerto 80. Tomcat lo usa como puerto por defecto.

8118/tcp

privoxy

9009/tcp

Pichat peer-to-peer chat server

9898/tcp

Gusano Dabber (troyano/virus)

10000/tcp

Webmin (Administracin remota web)

19226/tcp

Panda SecurityPuerto de comunicaciones de Panda Agent.

12345/tcp

NetBus en:NetBus (troyano/virus)

31337/tcp

Back Orifice herramienta de administracin remota (por lo general troyanos)