El Mdulo TCP

Pgina 1 de 7

Manifiesto por la liberacin de la cultura

ltimos Cambios

Mi estado actual en Jabber/XMPP:

- jabberES - jabber.org

Desarrollo de una Herramienta Software para el Acceso a Redes TCP/IP a travs de la Red Telefnica Conmutada
ltima Actualizacin: 30 de Junio de 1.996 - Domingo

Captulo 8: El Mdulo TCP

El mdulo TCP (Transport Control Protocol) [RFC793] es el equivalente al nivel OSI de transporte orientado a conexin. Sus caractersticas principales son: Conexiones fiables, garantizando la integridad de la informacin, su secuenciamiento correcto y la no prdida o duplicacin Adaptacin automtica al tiempo de trnsito de la red y fiabilidad frente a congestin Capacidad de envo de datos urgentes Gestin de bfferes en transmisin y recepcin Posibilidad de esperar conexiones remotas en ciertos canales especificados, denominados "puertos" Conexiones 8 bits orientadas al byte, sin distincin alguna de campos, y bidireccionales En cuanto a los servicios que utilizan este mdulo, destacan: Distribucin de las tablas de enrutado Para que la red en su conjunto ofrezca una imagen homogenea y coherente es necesario que las diferentes pasarelas dispongan de informacin actualizada sobre su topologa. Esto se consigue mediante el intercambio de informacin de encaminamiento entre los diferentes sistemas, va los servicios UDP y TCP. Protocolo TELNET [RFC854] Este servicio posibilita el acceso en modo terminal a una mquina remota, de forma transparente. Protocolo de transferencia de ficheros (FTP) [RFC959] Este protocolo permite el intercambio de ficheros residentes en mquinas distintas, de forma simple, rpida y fiable. Protocolo de transferencia de correo electrnico (SMTP) [RFC821] Uno de los servicios ms utilizados y tiles de las redes informticas. Protocolo de transporte hipertexto (HTTP) [HTTP1.1] [RFC1866] Esta familia de protocolos son los principales responsables de crecimiento exponencial de Internet, al facilitar considerablemente la bsqueda, el acceso y la gestin de la informacin desperdigada por la red. El protocolo TCP se define en [RFC793], texto notable por el gran nmero de erratas y ambig edades que contiene. En [RFC813], [RFC879], [RFC876], [RFC944] y [RFC1122] se concretan algunos detalles oscuros y se eliminan diversos errores.

Interfaz
La interfaz de este mdulo est constituida por procesos y por subrutinas ejecutadas en el contexto del llamante. Su utilizacin es muy simple.
PROC_TCP_BC

Este proceso es el encargado de inicializar este mdulo. Debe ser invocado con un mensaje "MSG_INIT" o "MSG_QUIT". La inicializacin de este mdulo debe ser posterior a la del mdulo IP.
PROC_TCP_SUP

Este es el proceso que recibe los mensajes de las capas superiores y los gestiona adecuadamente. Los mensajes definidos son:
MSG_TCP_OPEN

Este mensaje informa a la capa TCP que se acepta una conexin solicitada por una mquina remota. Los valores de los campos son:

mhtml:file://F:\Inictel\01 Analisis de protocolo TCP-IP\El Mdulo TCP.mht

22/09/2012

El Mdulo TCP

Pgina 2 de 7

campo1: Ignorado campo2: Identificador de la conexin campo3: Ignorado El enlace podr ser utilizado a partir de ese momento. Este mensaje es generado por una capa superior cuando sta decide aceptar una conexin remota propuesta por el mdulo TCP.
MSG_TCP_CLOSE

Este mensaje informa a la capa TCP que no tenemos ms informacin que transmitir a travs de una conexin dada. TCP se encarga de que cualquier dato pendiente en los bfferes internos sea correctamente entregado. La conexin sigue abierta para recibir, y no se cerrar hasta que el otro extremo lo decida o enviemos el mensaje definido a continuacin. Los valores de los campos son: campo1: Ignorado campo2: Identificador de la conexin campo3: Ignorado
MSG_TCP_ABORT

Este mensaje cierra una conexin en ambas direcciones. Cualquier dato en trnsito o en los bfferes internos se perder. Los parmetros de este mensaje son: campo1: Ignorado campo2: Identificador de la conexin campo3: Ignorado
MSG_MBUF

A travs de este mensaje una capa superior informa al mdulo TCP que hay nueva informacin para transmitir. La capa TCP se har cargo de la entrega de los datos. Los parmetros del mensaje son: campo1: Cadena de MBUFs conteniendo la informacin que se desea transmitir campo2: Identificador de la conexin campo3: Puede contener los valores CERO, PUSH o MODO_URGENTE Un valor de cero indica que los datos especificados no estn sujetos a ningn tratamiento especial. Si su longitud es pequea la capa TCP puede realizar un almacenamiento temporal en espera de nuevos datos en vez de enviar un segmento de tamao reducido. Si campo3 tiene el valor "PUSH" significa que los datos deben enviarse cuanto antes al otro extremo, y que ste debe entregarlos lo antes posible al proceso responsable. En cuanto a "MODO_URGENTE", supone un "PUSH" implcito (aunque es recomendable incluir la bandera "PUSH" para que sea sealada adecuadamente en el otro extremo) y su objetivo primordial consiste en la resincronizacin de la transmisin y el intercambio de datos "fuera de banda".
MSG_TCP_TIMEOUT

Este mensaje se genera cuando vence el nmero de reintentos en alguna conexin. Ello puede ser debido a que la red se ha roto, a que la mquina destino se ha caido o bien a que el tiempo de trnsito de los datagramas en la red es demasiado elevado. campo1: Indeterminado campo2: Identificador de la conexin campo3: Indeterminado La conexin se cierra de forma automtica.
PROC_TCP_INF

Este proceso recibe los segmentos TCP y los gestiona adecuadamente. Est diseado para intercomunicarse con los procesos en los mdulos IP e ICMP. Los mensajes que espera recibir son:
MSG_ICMP_SOURCE_QUENCH

Este mensaje indica a la capa TCP que alguna de sus conexiones transcurre a travs de una red muy cargada (congestin) y que debera reducir su tasa de transferencia para aliviarlo. Los parmetros de este mensaje fueron definidos en el mdulo ICMP.
MSG_ICMP_DEST_UNREACHABLE

Este mensaje informa a la capa TCP que alguna de sus conexiones (o intentos de conexin) no puede alcanzar a la mquina destino. Los parmetros de este mensaje fueron definidos en el mdulo ICMP.
MSG_MBUF

Este mensaje contiene un segmento TCP recibido por la capa IP. Su formato corresponde al definido en el captulo dedicado al mdulo IP. En cuanto a los mensajes que transmite, tenemos:
MSG_TCP_OPEN

Este mensaje informa a una capa superior que se ha recibido una peticin de conexin a uno de sus puertos declarados como "LISTEN". Para que la conexin se establezca la capa superior debe responder con otro "MSG_TCP_OPEN" dirigido a "PROC_TCP_SUP", tal y como se ha visto

mhtml:file://F:\Inictel\01 Analisis de protocolo TCP-IP\El Mdulo TCP.mht

22/09/2012

El Mdulo TCP

Pgina 3 de 7

previamente. Este mensaje tambin se genera cuando somos nosotros los que iniciamos la conexin y la mquina remota lo acepta (ver ms adelante). El formato de este mensaje es: campo1: Cabecera TCP interfaz campo2: Identificador de la conexin campo3: Indeterminado La cabecera TCP interfaz se define como:
typedef struct { uint16 puerto_remoto; uint16 puerto_local; uint32 ip_remoto; uint32 dummy[4]; } tcp_header;

"puerto_remoto" y "puerto_local" indican los puertos a travs de los cuales se ha establecido la conexin. "ip_remoto" contiene la direccin IP de la otra mquina. "dummy" contiene valores indeterminados.
MSG_TCP_CLOSE

Este mensaje es generado cuando la mquina remota no desea transmitir ms informacin. Con ello se informa al nivel superior de que no hay ms datos pendientes. No obstante nosotros podemos seguir transmitiendo. Este mensaje tambin es generado cuando se aborta una conexin, ya sea en la negociacin inicial o bien durante la fase de transferencia. En ese caso cualquier dato que queramos transmitir ser ignorado. El formato de este mensaje es: campo1: Ignorado campo2: Identificador de la conexin campo3: Ignorado
MSG_MBUF

Con este mensaje enviamos a las capas superiores los datos que se van recibiendo. El formato es idntico al especificado para el proceso "PROC_TCP_SUP". No obstante resulta conveniente realizar algunas matizaciones: Dado que tanto los procesos de transmisin como los de recepcin TCP incorporan mecanismos de buffering no puede esperarse que cada segmento enviado a este mdulo mediante "MSG_MBUF" genere uno y slo un mensaje "MSG_MBUF" en el receptor. En un momento dado el transmisor puede decidir retrasar el envo de un segmento debido a su escasa longitud, congestin de la red, o al cierre de la ventana de transmisin. Por otra parte, un bloque de informacin puede suponer el envo de ms de un segmento debido al MSS (Maximum Segment Size) negociado al principio de la conexin o la MTU de las redes intermedias. Adems el receptor puede decidir concatenar varios segmentos en un slo "MSG_MBUF" si la red cambia su secuenciamiento, etc. La opcin "PUSH" tiene como objetivo la entrega cuanto antes de los datos pendientes al proceso destino. No obstante tampoco sirve como delimitador de campos dentro de lo que es la propia secuencia de bytes. El proceso receptor puede no ver el "PUSH" en la misma posicin que el transmisor, ni recibirse el mismo nmero de PUSHs que se transmitieron. De hecho en [RFC1122] se especifica que la bandera "PUSH" no necesita ser transferida al proceso receptor. En cuanto a "MODO_URGENTE", tampoco sirve como delimitador claro. Su tarea consiste en conmutar de modo al proceso receptor. Su funcionamiento es inmediato: cuando el transmisor recibe un mensaje "MSG_MBUF" urgente, todos los datos previos todava no entregados sern marcados como urgentes en el receptor. La utilidad habitual de todo esto consiste en la recuperacin de sincronismo entre el transmisor y el receptor. El proceso receptor puede, por ejemplo, ignorar todos los datos marcados como urgentes. Se utiliza una tcnica parecida en el protocolo TELNET [RFC854]. Lo nico que se garantiza en "MODO_URGENTE" es que los datos que siguen a un mensaje urgente y que no estn marcados con ese modo no son recibidos como urgentes en el proceso receptor, siempre y cuando no haya ningn segmento urgente posterior. Esa es la nica forma de marcar campos que tiene este protocolo. En cuanto a rutinas, tenemos:
uint16 tcp_puerto_libre(void);

Esta rutina devuelve un puerto TCP actualmente no utilizado. Por compatibilidad con protocolos superiores, el valor del puerto es igual o superior a 1024.
estado tcp_listen(uint16 puerto,proc_id proc_retorno,puint32 id);

Esta rutina activa un puerto y espera un intento de conexin remoto. "puerto" es el valor del puerto en el que nos ponemos a escuchar. "proc_retorno" contiene el identificador del proceso al cual hay que informar de cualquier evento. Por ltimo "id" es un puntero al lugar donde hay que dejar el identificador de esta conexin. La rutina retorna "OK" si todo ha ido bien y "ERR_OVERFLOW" si hay demasiadas conexiones TCP. "id" contendr el identificador que debemos utilizar para comunicarnos con dicha conexin. Si el puerto especificado ya est en modo "LISTEN" devuelve "ERR_EN_USO". Si necesitamos aceptar varias conexiones a un mismo puerto tendremos que lanzar un nuevo "LISTEN" cuando se recibe una peticin remota de conexin y se ocupa el anterior. Cualquier intento de conexin genera un mensaje "MSG_TCP_OPEN" que puede ser aceptado con otro "MSG_TCP_OPEN" o denegado con un

mhtml:file://F:\Inictel\01 Analisis de protocolo TCP-IP\El Mdulo TCP.mht

22/09/2012

El Mdulo TCP

Pgina 4 de 7

"MSG_TCP_CLOSE". Si se deniega, el puerto regresar al modo "LISTEN" y esperar un nuevo intento de conexin.
uint32 tcp_connect(uint16 puerto,uint32 ip,proc_id proc_retorno);

Esta rutina inicia una conexin al puerto "puerto" de la mquina "ip". "proc_retorno" es el proceso al cual hay que informar de cualquier eventualidad. La rutina retorna el identificador asociado a esa conexin. Si es cero indica que hay demasiadas conexiones abiertas. El puerto local utilizado en la conexin se elige de forma arbitraria. Si la conexin es aceptada se produce un "MSG_TCP_OPEN", mientras que si se deniega se enviar un "MSG_TCP_CLOSE". Si se excede el nmero de reintentos se enviar "MSG_TCP_TIMEOUT".
tcp_estado tcp_status(uint32 id);

Esta rutina devuelve el estado de una conexin, a partir de su identificador. Los valores posibles son:
CLOSED

La conexin no existe.
LISTEN

Esperamos una peticin remota de conexin.

LISTEN_2

Hemos recibido un intento de conexin que todava no hemos aceptado o denegado. Este estado ha sido aadido en nuestra implementacin, no estando recogido en el documento original [RFC793]. Su objetivo es el evitar que dos conexiones diferentes pero casi simultaneas al mismo puerto "LISTEN" causen problemas. La segunda conexin ser ignorada y cuando el segmento original sea reenviado ya habremos decidido si crear o no un nuevo puerto "LISTEN".
SYN_SENT

Intentamos una conexin.

SYN_RECEIVED

Hemos recibido un intento de conexin, lo hemos aceptado y ahora estamos esperando a que el otro extremo complete su inicializacin.
ESTABLISHED

Conexin establecida.
FIN_WAIT_1

La conexin est abierta pero nosotros hemos decidido que no tenemos nada ms que decir y estamos esperando a que el otro extremo tome nota de ese cambio de situacin.
FIN_WAIT_2

La conexin sigue abierta, pero nosotros no vamos a transmitir nada ms y el otro extremo TCP ha informado de ello a sus niveles superiores.
CLOSE_WAIT

La conexin sigue abierta, pero el otro extremo nos ha indicado que no piensa transmitir nada ms.
CLOSING

Ambos extremos hemos decidido que no hay nada ms que decir y estamos procediendo a cerrar la conexin
LAST_ACK

Estado equivalente a "CLOSING". Ver la seccin de implementacin para ms detalles.

TIME_WAIT

La conexin ya ha sido cerrada y no puede utilizarse, pero todava no eliminamos las tablas internas asociadas por si permanecen todava segmentos en trnsito en la red. Tras un tiempo prudencial en este estado se elimina el contexto que quedaba y se pasa al estado "CLOSED".
estado tcp_flujo(uint32 id,uint16 tamanho);

Esta rutina es la que implanta el mecanismo de control de flujo TCP. Cada vez que una capa superior desea enviar informacin a travs de una conexin TCP "id", debe pedir permiso. La rutina devuelve "OK" si el flujo est abierto y "FLUJO_LLENO" si la conexin no se encuentra en el estado "ESTABLISHED" o "CLOSE_WAIT". Es posible, aunque no recomendable, enviar informacin a travs de una conexin aunque su control de flujo est cerrado. Con ello se pretende simplificar la implementacin de algunos protocolos superiores. No debera abusarse de esta caracterstica si no se est completamente seguro de sus implicaciones. Si el control de flujo est cerrado hay que volver a intentarlo tras un tiempo prudencial (por ejemplo, una dcima de segundo).

mhtml:file://F:\Inictel\01 Analisis de protocolo TCP-IP\El Mdulo TCP.mht

22/09/2012

El Mdulo TCP

Pgina 5 de 7

void tcp_cerrar_flujo_rx(uint32 id);

A travs de esta llamada se informa a la mquina remota que la conexin "id" no admite ms datos. La capa TCP enviar un segmento vaco con el fin de actualizar la informacin de ventana del otro extremo. An cuando se reciban ms segmentos no se enviarn hacia la capa superior. No obstante se entregar cualquier segmento que ya hubiese sido enviado al dispatcher. Esta accin slo debe solicitarse en casos de necesidad. En [RFC1122] se especifica claramente que debe evitarse su uso en lo posible.
void tcp_abrir_flujo_rx(uint32 id);

Esta rutina complementa la anterior e informa al otro extremo que estamos dispuestos a aceptar nuevos datos. La capa TCP enviar un segmento para que la mquina remota pueda actualizar su informacin de ventana.
void tcp_trace(uint32 id,ttcp_trace POINTER trace);

Esta rutina facilita diversa informacin de depuracin y anlisis sobre una conexin dada. "id" contiene el identificador de la conexin en la que estamos interesados. "trace" es un puntero a una estructura definida como:
typedef struct { tcp_estado estado; uint32 bytes_tx; uint32 bytes_rx; uint32 srtt; uint16 ventana_tx; uint16 bytes_cola_tx; uint16 mss; } ttcp_trace;

"estado" contiene el estado de la conexin, tal y como se vi con anterioridad. "bytes_tx" y "bytes_rx" indican el nmero de bytes transmitidos y recibidos, respectivamente. "srtt" es el tiempo ida y vuelta estimado de la conexin, en milisegundos. "ventana_tx" informa del tamao de la ventana publicada por el otro extremo. "bytes_cola_tx" es el nmero de bytes que pendientes de confirmacin. Por ltimo "mss" es el tamao mximo de segmento que admite la mquina remota.

Implementacin
Este mdulo sigue escrupulosamente todas las guas definidas en [RFC793], implantndolo completamente. Se trata de un protocolo complejo y ambiguo. El texto original contiene dos errores graves: El grfico de la pgina 23 (diagrama de estados) no se corresponde al texto en s del documento, que elimina el estado "LAST_ACK" y transfiere el arco de salida de "CLOSE_WAIT" a "CLOSING". El efecto que tiene este cambio es el permanecer en "TIME_WAIT" an cuando el otro extremo nos haya confirmado la finalizacin. Ello resulta til ante la posibilidad de que la red desordene o duplique datagramas. Nosotros hemos optado por implantar esa caracterstica, por lo que el estado "LAST_ACK" no se alcanza nunca. Segn [RFC944] el documento TCP [RFC793] contiene un error respecto a la gestin de datos urgentes. Hemos programado este mdulo teniendo en cuenta esta eventualidad. En [RFC1122] se indican ms errores en la especificacin original, y se concretan muchos detalles oscuros. En la implementacin actual los mensajes de control de flujo, "MSG_ICMP_SOURCE_QUENCH", son ignorados. La razn de ello es que este Proyecto ha sido diseado para trabajar en redes de baja velocidad (modems) y con acceso final a redes rpidas, por lo que la congestin que provocamos es nula. Se mantiene en estudio el utilizar un esquema sencillo de control de flujo mediante, por ejemplo, la paralizacin de las transmisiones TCP durante un tiempo determinado (por ejemplo, cinco o diez segundos). Los posibles mensajes "MSG_ICMP_DEST_UNREACHABLE" tambin son ignorados, confiando en el mecanismo de reintentos para o bien solucionar el problema o bien cerrar la conexin. A la hora de calcular el tiempo de trnsito de la red se cronometra el tiempo transcurrido entre el envo de un segmento y su confirmacin, sujeto a una exponencial 2^-x. Suponemos que el retardo de la red es aproximadamente igual en ambas direcciones. El mecanismo de retransmisiones se dispara cuando transcurre un perodo superior al 25% del RTT estimado sin que llegue alguna confirmacin. Cada vez que se realiza una retransmisin crece el RTT, y la conexin se aborta cuando ste supera un valor crtico (actualmente unos 75 segundos). Todo este mecanismo est siendo estudiado con cuidado, intentando acomodarlo lo mximo posible a las caractersticas de este Proyecto. En [RFC1122] se mencionan dos esquemas alternativos que dejan obsoleto a ste, pero desgraciadamente no han sido publicados como RFCs. Uno de nuestros mayores problemas es el hecho de que la longitud de los datagramas influye considerablemente en el RTT, ya que nuestro enlace es de muy baja velocidad (comparativamente). El otro problema es que si nosotros no estamos transmitiendo nada no podemos recalcular el RTT. De todos modos la implementacin efectuada ha dado unos resultados bastante aceptables y, adems, todo esto no influye en la recepcin de datos, accin mucho ms habitual en nuestro contexto. No es necesario que los "MSG_MBUF" que se transmitan midan lo mismo que el MSS de la conexin. La capa TCP se encarga de realizar las correcciones necesarias. Lo que s es imprescindible es que nunca se supere el valor "MEM_BLOQUE" declarado en el mdulo de gestin de memoria. En la negociacin del MSS se tiene en cuenta el MTU del canal asociado a nuestra direccin IP, con el fin de evitar la fragmentacin de los segmentos. El estado "TIME_WAIT" se emplea para conservar ciertas estructuras internas asociadas a una conexin que ya ha sido cerrada, en previsin de que la red pueda duplicar y/o desordenar datagramas. Segn [RFC793] este estado debe mantenerse durante un tiempo mnimo que garantice que cualquier datagrama en trnsito agote su tiempo de vida. En la implementacin actual se ha fijado una temporizacin de dos minutos. No obstante las estructuras asociadas a una conexin son grandes y, por consiguiente, ocupan una considerable cantidad de memoria. Por ello, si se intenta abrir una conexin y no hay suficiente sitio en las tablas internas para ello, se busca la conexin en estado "TIME_WAIT" ms antigua y se elimina para acomodar los nuevos datos. Si no hay ninguna conexin en "TIME_WAIT" no se podr crear el nuevo enlace. An cuando el protocolo permite enlaces unidireccionales, cuando uno de los extremos cierra la conexin pero el otro no, la filosofa general de las aplicaciones que hacen uso de esta capa consiste en cerrar la conexin en cuanto el otro extremo lo hace.

mhtml:file://F:\Inictel\01 Analisis de protocolo TCP-IP\El Mdulo TCP.mht

22/09/2012

El Mdulo TCP

Pgina 6 de 7

Se han considerado algunas extensiones: En [RFC1072] se definen tres extensiones para redes con un producto Ancho de Banda * Retardo elevado: confirmaciones selectivas, clculo preciso del tiempo ida y vuelta, y ventanas de recepcin de ms de 16 bits. Aunque el ancho de banda de los enlaces telefnicos es bastante bajo, el tiempo de retardo suele ser muy elevado (valores de hasta treinta segundos no son raros). En [RFC1146] se definen dos algoritmos adicionales para calcular la suma de control TCP, basados en los trabajos de Fletcher. Se trata de una extensin con fines puramente experimentales. es una propuesta de estndar basada en [RFC1072], pero que no incluye la opcin de confirmaciones selectivas. Se utiliza una variante para la secuencia de numeracin, con un tamao efectivo de 64 bits (basado en firmas temporales), ya que con las redes de alta velocidad 32 bits se recorren en pocos segundos.
[RFC1323]

En el documento [RFC1263] se hace un anlisis detallado del impacto, a nivel de compatibilidad y ampliaciones futuras, de las extensiones propuestas. No se ha incluido ninguna de ellas por tratarse de modificaciones experimentales poco difundidas.

Bibliografa
[HTTP1.1] [RFC793] "HyperText Transfer Protocol" http://www.w3.org RFC793: "Transport Control Protocol" Jon Postel Septiembre 1.981 RFC813: "WINDOW AND ACKNOWLEDGEMENT STRATEGY IN TCP" David D. Clark Julio 1.982 RFC821: "SIMPLE MAIL TRANSFER PROTOCOL" Jonathan B. Postel Agosto 1.982 RFC854: "Telnet Protocol specification" Jon Postel Joyce Reynolds Mayo 1.983 RFC862: "Echo Protocol" Jon Postel Mayo 1.983 RFC863: "Discard Protocol" Jon Postel Mayo 1.983 RFC879: "The TCP Maximum Segment Size and Related Topics" Jon Postel Noviembre 1.983 RFC896: "Congestion Control in IP/TCP Internetworks" John Nagle Enero 1.984 RFC944: "Official ARPA-Internet protocols" Joyce Reynolds Jon Postel Abril 1.985 RFC959: "FILE TRANSFER PROTOCOL (FTP)" Joyce Reynolds Jon Postel Octubre 1.985 RFC1072: "TCP Extensions for Long-Delay Paths" Van Jacobson R. Braden Octubre 1.988 RFC1122: "Requirements for Internet Hosts -Communication Layers" Robert Braden Octubre 1.989 RFC1146: "TCP Alternate Checksum Options" Johnny Zweig Craig Partridge Marzo 1.990 RFC1191: "Path MTU Discovery" Jeffrey Mogul Steve Deering Noviembre 1.990 RFC1263: "TCP EXTENSIONS CONSIDERED HARMFUL" Larry L. Peterson Sean O'Malley Octubre 1.991

[RFC813]

[RFC821]

[RFC854]

[RFC862]

[RFC863]

[RFC879]

[RFC896]

[RFC944]

[RFC959]

[RFC1072]

[RFC1122]

[RFC1146]

[RFC1191]

[RFC1263]

mhtml:file://F:\Inictel\01 Analisis de protocolo TCP-IP\El Mdulo TCP.mht

22/09/2012

El Mdulo TCP

Pgina 7 de 7

[RFC1323]

RFC1323: "TCP Extensions for High Performance" Van Jacobson Bob Braden Dave Borman Mayo 1.992 RFC1435: "IESG Advice from Experience with Path MTU Discovery" Stev Knowles Marzo 1.993 RFC1693: "An Extension to TCP : Partial Order Service" Phill Conrad Paul D. Amer Tom Connolly Noviembre 1.994 RFC1866: "Hypertext Markup Language - 2.0" T. Berners-Lee D. Connolly Noviembre 1.995

[RFC1435]

[RFC1693]

[RFC1866]

La Pgina de Jess Cea Avin Mi Proyecto Fin de Carrera ndice de mi Proyecto Captulo 7: El Mdulo UDP Captulo 9: El Mdulo ECHO

mailto:jcea@jcea.es

mhtml:file://F:\Inictel\01 Analisis de protocolo TCP-IP\El Mdulo TCP.mht

22/09/2012