CURSO DE TCP/IP: (3 ENTREGA) TCP (TRANSMISION CONTROL PROTOCOL) - 1 parte.

- Empezaremos a estudiar las CABECERAS TCP - Veremos las diferencias entre TCP y UDP - Qu es eso de "protocolo orientado a la conexin"? ---> conexiones virtuales

1. INTRODUCCION
Despus de haber estado hablando indirectamente sobre el protocolo TCP/IP durante 10 meses en la serie RAW, al fin vamos a entrar de lleno en la base de todo esto: la base sobre la que se apoy toda la serie RAW. Al hablar del protocolo TCP al fin vamos a comprender qu es lo que ocurre realmente cuando hacemos un Telnet y la necesidad de establecer conexiones de este tipo. Comprenderemos tambin por qu se utiliza TCP como protocolo de transporte para la mayora de las aplicaciones, al compararlo con UDP y comprobar que son muchas las ventajas. Con este artculo, entramos a fondo en conceptos nuevos, como son las conexiones virtuales, el control de flujo, los flags, etc. Quiz no os queden del todo claros los conceptos despus de terminar de leerlo, pero no os preocupis, que est todo previsto. El curso continuar con una segunda entrega dedicada a TCP, en la cual aclararemos muchos de los conceptos que quedarn hoy en el aire, y veremos una serie de ejemplos que conseguirn
Pgina 14

con la prctica lo que no se puede conseguir con la mera teora. Adems, para hacerlo un poco ms amena, la segunda entrega incluir tambin algunas tcnicas de hacking basadas en el funcionamiento de TCP, que es lo que a muchos de vosotros ms os interesa. ;-) Aprenderemos adems a construir las cabeceras tal y como son en realidad, en binario. Pero lo ms importante es que podremos ver en detalle cmo es el trfico que circula constantemente entre nuestro ordenador y la red Internet.

2. DIFERENCIAS ENTRE TCP Y UDP

Por si no lo habis hecho, es importante que antes de continuar repasis los dos artculos anteriores del curso de TCP/IP (Introduccin, y UDP), ya que vamos a empezar comparando este nuevo protocolo con el que ya conocamos, el protocolo UDP.

2.1. Conexiones virtuales

Volvemos a insistir una vez ms en que una de las principales diferencias entre TCP y UDP es la existencia de conexiones virtuales. Como ya vimos, el protocolo TCP se dice que es orientado a conexin
PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

(en realidad conexiones virtuales), al contrario que UDP (no orientado a conexin). Las implicaciones de esto son muchas, tal y como iremos viendo a lo largo del artculo. De momento quedmonos con la idea de conexin virtual. Por qu se habla de conexiones virtuales, y no de conexiones a secas? Para encontrar una respuesta a esta pregunta basta con pensar un poco en la arquitectura de la red Internet (y de cualquier red TCP/IP). Si Internet hubiese existido hace 50 aos, probablemente su arquitectura hubiera sido muy diferente, igual que la red telefnica de ahora es muy diferente a la que haba entonces. La red telefnica de aquellos aos dependa de una figura humana bien conocida: la telefonista. Las telefonistas eran unas mujeres casi binicas que actuaban como intermediarias entre los distintos clientes de la red telefnica para que estos pudieran comunicarse entre s. Cuando un cliente deseaba hablar con otro, una telefonista tena que establecer una conexin manual entre las lneas de a m b o s clientes, conectando los cables correspondientes en un panel de conexiones.
PC PASO A PASO N 20

Imaginemos cmo habra sido la Internet en aquellos aos. Un autentico ejrcito de internetistas trabajando 24 horas para dar servicio a todas las conexiones que estableciese cualquier cliente: cada vez que alguien desease leer su correo electrnico, una internetista tendra que establecer una conexin en el panel entre el cliente y su servidor de POP3, cada vez que alguien visitase una pgina web una internetista tendra que establecer una conexin entre el cliente y el servidor de la pgina web, etc., etc. Desde luego, esto habra sido una locura inviable, sin contar con el hecho de que la red sera muy lenta y muy insegura. Si tratsemos de mejorar esta idea sustituyendo a las internetistas humanas por un medio mecnico automatizado que estableciese las conexiones mediante rels seguiramos teniendo muchos problemas, y uno de los ms preocupantes sera el de la velocidad. Se mire por donde se mire, una red en la que haya que establecer nuevas conexiones cada vez que se desee utilizar un servicio siempre ser ms lenta que una red en la que todo est conectado de antemano. Y precisamente esa es la topologa de la red Internet: todo est conectado de antemano. Nuestro PC siempre tiene un nico cable que nos conecta con Internet (el cable de red que va al router, o el cable que va al modem, o el cable etreo que nos une con nuestra estacin wireless). Y lo mismo ocurre con cualquier mquina conectada a Internet. Nunca hay que cambiar ningn cable de sitio, por muy diferentes que sean las conexiones que queramos establecer. Tanto si vamos a enviar un correo a
Pgina 15

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

nuestro mejor amigo, como si vamos a ver una pgina web de Japn, las conexiones fsicas son siempre las mismas. Esto hace que los protocolos de la red Internet tengan necesariamente que estar muy bien pensados para que esto no de lugar a un completo caos. Para evitar estas confusiones nace el concepto de conexin virtual, que busca las ventajas de las redes en las que las conexiones no estn establecidas de antemano, pero sin toparse con sus desventajas. Si bien todo sigue conectado de antemano, las conexiones virtuales emulan el mecanismo por el cual, antes de comenzar una comunicacin entre dos puntos, es necesario poner a ambas partes de acuerdo y establecer una conexin entre ambas. En teora, las conexiones virtuales permiten, igual que una conexin real, que la comunicacin no sea escuchada por nadie que no est conectado al cable que une ambos puntos, que terceras personas no puedan intervenir en la comunicacin enviando datos que no sean de ninguna de las dos partes legtimas, que nadie pueda hacerse pasar por otro, etc., etc. Por supuesto, todo esto es en teora pero, como bien sabemos, nada en este mundo funciona como en teora debera. ;-) Qu es lo que caracteriza una conexin? Las conexiones de las que hemos hablado son siempre conexiones entre dos puntos, y as son todas las conexiones en TCP. Aunque puedas estar en un chat hablando con 100 personas a la vez, en realidad toda esa comunicacin se realiza a travs de pares de conexiones.
Pgina 16

Para entenderlo, veamos el caso de un chat entre 3 personas. Podramos pensar en primer lugar en una solucin que fuese un nico cable con 3 conectores que conectase entre s a los 3 interlocutores.

Pero, que ocurrira si quisiramos meter a una persona ms en la conversacin? Tendramos que quitar el cable de 3 conectores y cambiarlo por uno de 4? Sera mucho ms sencillo un sistema en el cual todo funcionase mediante cables de slo dos conectores. Para que alguien entrase o saliese del chat, bastara con conectar o desconectar un slo cable, pero no habra que modificar toda la red, y el resto de usuarios del chat no se veran afectados por lo que hiciera uno solo. Para poder realizar este chat entre 3 personas mediante cables de 2 conectores se hace imprescindible la presencia de un intermediario que gestione todas las conexiones de todos los usuarios. Esta es precisamente la misin de un servidor de chat.
PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

Por lo que hemos visto hasta ahora, es obvio que lo primero que caracteriza a una conexin son los dos extremos que conecta. En nuestro contexto, los extremos de la conexin se identifican mediante las conocidas direcciones IP. Pero la identificacin de los extremos no es lo nico que caracteriza una conexin. Cada uno de los extremos podra tener varios conectores diferentes, as que no slo basta saber con quin conectas, si no tambin dnde. En nuestro contexto, cada uno de los conectores de un mismo extremo seran los diferentes servicios : HTTP, FTP, POP3, etc. Por tanto, al igual que ocurra con UDP, otro de los parmetros que caracterizan una conexin TCP son los puertos de conexin de ambos extremos. Si se tratase de conexiones fsicas, no hara falta mucho ms para ser caracterizadas. En cambio, al tratarse de conexiones virtuales, necesitamos algn mecanismo que identifique una conexin establecida. Y es aqu donde vemos la principal diferencia entre TCP y UDP. Los paquetes TCP contienen un campo en su cabecera que no contienen los paquetes UDP. Este campo adicional es el que permite identificar la conexin virtual a travs de la cual circula el paquete. La solucin ms obvia que podramos encontrar para implementar este identificador de conexin sera utilizar un nmero que identificase unvocamente la conexin. Pero esta solucin presentara varios problemas, el mayor de los cuales sera quiz la seguridad. Si una conexin se identifica permanentemente por un mismo nmero, es slo cuestin de tiempo que un atacante encuentre ese nmero por fuerza bruta y as, con slo spoofear su IP (utilizar algn mecanismo para enviar paquetes en nombre de una IP que no sea la suya), se pueda colar en la conexin ajena. Una solucin mucho mejor es utilizar un nmero que vaya cambiando con cada paquete, segn unas ciertas normas establecidas entre los dos extremos.
Pgina 17

Como vemos en esta otra imagen, ahora hay 3 cables en lugar de uno slo, y cada cable conecta a un nico usuario con el servidor que gestiona el chat. Es importante comprender que esto que hemos dicho de los cables de slo dos conectores no se refiere a las conexiones fsicas de Internet, si no a las conexiones virtuales que nos da el protocolo TCP. De hecho, muchas redes TCP/IP tienen fsicamente conectadas todas sus mquinas entre s, en lugar de realizar las conexiones mediante cables punto a punto, pero insisto en que esto slo ocurre con las conexiones fsicas, pero no con las conexiones virtuales, que son siempre punto a punto.

Hablando claro...

Hablando claro, no importa como conectes fsicamente tu PC a otros PCs (hay mil maneras de hacerlo, unas son punto a punto y otras no). Lo importante es que TU PC (y cualquier otro PC del mundo), cuando utilice el protocolo TCP, establecer siempre conexiones virtuales punto a punto.
PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

Esto en realidad no es tal y como lo pinto. Este nmero cambiante realmente existe, pero su principal finalidad no es la de identificar conexiones, si no ms bien la de mantener el estado de evolucin de una conexin, y saber as en todo momento qu paquetes se pueden enviar y qu paquetes se pueden recibir a travs de esa conexin. Este nmero es el llamado nmero de secuencia, pero mejor ser que no nos precipitemos ms, que ya habr tiempo de ver todo esto en detalle.

Una solucin mucho ms eficiente es englobar en un slo paquete los datos transmitidos y la confirmacin de los datos recibidos.

2.2. Fiabilidad en la comunicacin

Como ya cont en el artculo sobre UDP, al contrario que ste, el protocolo TCP tiene un mecanismo para asegurar que los datos llegan correctamente a su destino. Para conseguir esto, cada paquete TCP que llegue a un destino ha de ser respondido por ste mediante otro pequeo paquete que confirme la recepcin.

En esta figura vemos cmo las mquinas A y B intercambian paquetes a travs de una misma conexin, actuando ambos simultneamente como transmisores y receptores. En primer lugar, la mquina A enva el primer paquete (Paquete 1 A). Una vez recibido el paquete 1 A, la mquina B decide tambin empezar a enviar sus propios paquetes, por lo que enva un nico paquete a A en el que engloba la confirmacin de que recibi el paquete 1 A, as como su propio paquete 1 B. A esto responder la mquina A enviando el siguiente paquete de los que desea transmitir, pero englobando en el mismo tambin la confirmacin de que recibi correctamente el paquete 1 B. As continuara la comunicacin, hasta que la mquina A decidiese dejar de transmitir sus propios datos, por lo que su nica misin consistira ya slo en seguir confirmando la recepcin de los paquetes que le enva B, como ocurre en la figura con el caso del paquete 2 B, al cual la mquina A responde slo con una confirmacin de recepcin, pero sin englobar ms datos en el mismo paquete, ya que A no tiene ya nada ms que desee enviar.
PC PASO A PASO N 20

Esto sera as en el caso ms sencillo, pero menos comn, que sera el de una comunicacin unidireccional, donde slo una de las partes enviase datos a la otra. En la prctica, la mayora de los servicios son bidireccionales, por lo que es necesario intercalar los paquetes transmitidos con las confirmaciones de los paquetes recibidos. Esto podra dar lugar a un gran nmero de paquetes (el doble, exactamente), ya que a cada paquete de datos habra que sumar adems el correspondiente paquete de confirmacin.
Pgina 18

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

Qu ocurre si uno de los paquetes se pierde por el camino? Cada vez que una mquina transmite un paquete TCP, sta no lo borra de su memoria, si no que lo deja almacenado an por un tiempo, esperando que llegue la confirmacin de su recepcin. Si sta llega, se podr borrar el paquete de la memoria, y olvidarse para siempre de l. En cambio, si pasado un tiempo prudencial no ha llegado la confirmacin de su recepcin, se asumir que el paquete no ha llegado a su destino, por lo que ste se retransmitir. As, el paquete se conservar en la memoria todo el tiempo que sea necesario, reenvindolo cada cierto tiempo, hasta que al fin llegue la confirmacin de que el paquete fue recibido. En el caso de que, debido a estos reenvos, un mismo paquete llegue ms de una vez al mismo destino, no habr ningn problema, ya que el diseo de TCP permite diferenciar perfectamente un paquete de otro, por lo que al detectar la duplicacin simplemente se rechazar la copia.

2.4. Tratamiento de paquetes grandes

Esta capacidad de dividir los datos en fragmentos ordenados, combinada con el sistema de confirmacin de respuestas de TCP, convierte a ste protocolo en un protocolo de transporte ideal para la transmisin segura de grandes cantidades de datos.

2.5. Control de flujo

Aqu entramos ya en un nuevo concepto que habr que introducir, ya que es uno de los conceptos bsicos del campo de las redes y telecomunicaciones. Hasta ahora hemos tratado las redes y las mquinas como si fuesen perfectas, sin limitaciones. Pero sabemos muy bien que en la vida real esto no es as ya que, por ejemplo, el ancho de banda de una red es uno de los factores ms determinantes de su efectividad. Hemos asumido que los paquetes se iban transmitiendo a diestro y siniestro, y que estos iban a ser recibidos sin problemas. Bueno, no exactamente... Hemos dicho que s que poda haber problemas en la recepcin, pero realmente no hemos hablado de los problemas del ancho de banda. Si la nica solucin ante la congestin de la red fuese el mecanismo explicado anteriormente para asegurarnos de que todos los datos llegan al destino, el problema no se solucionara si no que, al contrario, sera cada vez mayor. Imaginemos la situacin. La mquina A, que transmite los paquetes, es demasiado rpida para lo que es capaz de procesar
Pgina 19

2.3. Orden en los datos

Tal y como decamos tambin en el anterior artculo, TCP identifica cada paquete con un nmero de secuencia que permite ordenarlos correctamente independientemente de su orden de llegada al destino. En el caso de UDP, los paquetes se iban procesando segn iban llegando. En cambio, en TCP un paquete se puede dividir en fragmentos que podrn llegar en cualquier orden, y los datos no se procesarn hasta que se hayan recibido todos los fragmentos y estos se hayan ordenado segn el nmero de secuencia de cada paquete.
PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

la mquina B, que recibe los paquetes. Por tanto, la mquina A empieza a enviar paquetes a toda velocidad y sin compasin, esperando las confirmaciones de la mquina B. Como B no da abasto, no es capaz de enviar las confirmaciones de recepcin a tiempo. Al no llegar las confirmaciones, A se pondr a reenviar los paquetes anteriores, al mismo tiempo que contina enviando paquetes a diestro y siniestro, por lo que la congestin, sumando los paquetes nuevos y los viejos, ser muchsimo mayor.

comunicacin, a no ser que sea un malnacido (que los hay), tendr que actuar en consecuencia, relajndose un poco y dndonos tiempo a asimilar lo que ya nos ha enviado. Ms adelante veremos en detalle cmo se implementa el control de flujo en TCP.

Todo esto que...

Todo esto que estamos explicando despus lo tocaremos en la realidad. Veremos los paquetes TCP y dnde est localizado cada concepto del que hablamos.

3. LO QUE S QUE TIENEN EN COMN TCP Y UDP

Como no todo va a ser diferencias, vamos a ver los puntos en comn entre ambos protocolos de transporte que, en el fondo, son bastante parecidos. En primer lugar, TCP tambin se apoya sobre el protocolo IP y, en este caso, el nmero de protocolo asignado a TCP para que la capa de red (la capa IP) pueda identificar el protocolo de transporte, es el nmero 6. Como ya sabemos, la cabecera IP contendr entre sus campos uno que identifique el protocolo de transporte que est por encima de l.

Si no se implementa algn mecanismo para evitar este caos, la situacin puede hacerse insostenible en poco tiempo. Un mecanismo que se encargue de ajustar el flujo de la comunicacin es precisamente lo que se conoce como control de flujo. En el caso de TCP, disponemos de un sencillo mecanismo de control de flujo, que consiste en incluir en la cabecera de cada paquete un campo que indica al otro extremo de la comunicacin cmo estamos de congestionados. Esta medida de la congestin la llevamos a cabo diciendo cuntos bytes estamos preparados para recibir. Segn nos vayamos saturando, este nmero ser cada vez menor, y el otro extremo de la

Pgina 20

PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

El punto en comn ms importante entre TCP y UDP es que el mecanismo de identificacin de servicios es el mismo: cada paquete, tanto en TCP como en UDP, lleva dos nmeros de puerto (origen, y destino), ambos comprendidos entre 0 y 65535 (16 bits). Los puertos de TCP funcionan

RFC 793 en espaol

RFC 793 en perfecto espaol!!! Como ya hemos comentado muchas veces, tenemos traducidos muchos de los RFC al espaol en la Web www.rfc-es.org. Este es el trabajo de muchas personas que desinteresadamente estn colaborando en un proyecto realmente descomunal: traducir los ms de 3000 documentos, si controlas de Ingles y te animas, ya sabes :) El RFC 793 en castellano est en http://www.rfces.org/getfile.php?rfc=0793

exactamente igual que los de UDP, pero no tienen ninguna relacin entre s, es decir, existen 65536 puertos para TCP, y otros 65536 puertos diferentes para UDP. Si, por ejemplo, en un firewall cierras el puerto 21 de TCP, no estars cerrando al mismo tiempo el puerto 21 de UDP, ya que son totalmente independientes. Otro punto en comn es que ambos protocolos incluyen una suma de comprobacin en cada paquete, que verifica la correccin de los datos incluidos en el mismo. La cabecera que se codifica en la suma de comprobacin de TCP es muy similar a la que se utiliza en UDP.

Como vemos, el RFC tiene 91 pginas, por lo que es bastante ms denso que la mayora de los RFCs que hemos visto hasta ahora (tanto en la serie RAW como en el curso de TCP/IP). An as, no es demasiado duro de leer, sobre todo si prescindimos de algunas cosas poco importantes para la comprensin del protocolo, como la especificacin de las variables del TCB, o toda la parte del final relativa al procesamiento de eventos. En cualquier caso, ya sabis que aqu tendris un buen resumen de todo lo ms importante. ;-) Como ya somos expertos en protocolos, vamos a plantar aqu directamente la cabecera TCP. No pierdas de vista esta imagen, haremos referencia a ella a lo largo de todo el artculo.

4. LA CABECERA TCP EN DETALLE

Entramos ya en los detalles tcnicos del protocolo TCP. En este caso, el RFC que los especifica es el RFC 793. Desde la pgina de los RFC (http://www.rfceditor.org) podemos bajar tanto versin en TXT (http://www.rfc-editor.org/cgibin/rfcdoctype.pl?loc=RFC&letsgo=793 &type=ftp&file_format=txt), como versin en PDF (http://www.rfc-editor.org/cgibin/rfcdoctype.pl?loc=RFC&letsgo=793 &type=ftp&file_format=pdf).

PC PASO A PASO N 20

Pgina 21

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

Bueno, bueno, la cosa ya va siendo ms seria, eh? ;-) Que nadie se asuste! Ya veris como en un momento comprendemos todo lo que hay en esa imagen aparentemente tan complicada. Vamos a ir viendo campo por campo toda la cabecera, para luego entrar en detalle en el tamao de los campos a nivel de bit (ya en el prximo artculo).

Por un lado, identifica unvocamente a cada paquete dentro de una conexin, y dentro de un margen de tiempo. Es este nmero el que nos permite detectar si un paquete nos llega duplicado. Durante un margen de tiempo (que depende del flujo de los datos y, por tanto, tambin del ancho de banda) tenemos la garanta de que en una determinada conexin virtual no habr dos paquetes diferentes con el mismo nmero de secuencia. Por ejemplo, en una conexin de 2Mbps, este margen de tiempo es de unas 4 horas y media, mientras que en una conexin de 100Mbps el margen es de 54 minutos. Por qu este margen de tiempo vara en funcin del flujo de datos? Pues lo comprenderemos en cuanto veamos qu es exactamente el nmero de secuencia. Y es que el nmero de secuencia es mucho ms que un mero identificador de paquetes. El valor del nmero de secuencia no es aleatorio, si no que tiene un significado muy concreto. El nmero de secuencia es el orden en bytes que ocupan los datos contenidos en el paquete, dentro de una sesin . Es decir, supongamos que el primer paquete enviado una vez establecida una conexin tiene un nmero de secuencia 0, y el paquete contiene 200 bytes de datos. El siguiente paquete que se enviase tendra que tener 200 como nmero de secuencia, ya que el primer paquete contena los bytes del 0 al 199 y, por tanto, el orden que ocupan los datos del segundo paquete es el siguiente: 200. Por qu decamos entonces que el nmero de secuencia identifica unvocamente un paquete dentro de un margen de tiempo? Porque el nmero de
PC PASO A PASO N 20

4.1. Puerto de origen

Este campo tiene el mismo significado que en el caso de UDP. En TCP es de especial importancia, porque es condicin necesaria (aunque no suficiente) para identificar una conexin virtual.

4.2. Puerto de destino

Tambin tiene el mismo significado que en UDP, y tambin es condicin necesaria (aunque no suficiente) para identificar una conexin virtual. Es decir, si nos llega un paquete que coincide en IP de origen, IP de destino, Puerto de origen, y nmero de secuencia, con los de una conexin virtual, pero no coincide el puerto de destino, entonces ese paquete no se puede considerar perteneciente a esa conexin virtual. Lo mismo ocurre si el que cambia es el puerto de origen.

4.3. Nmero de Secuencia

Aqu empieza lo ms divertido, ya que este campo es uno de los que ms nos dar que hablar. El nmero de secuencia es un nmero bastante grande (32 bits) que tiene varias funciones.

Pgina 22

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

secuencia es siempre creciente, por lo que un paquete posterior a otro siempre tendr un nmero de secuencia mayor. Claro que... ser mayor en mdulo 32. Esto significa que, una vez que el nmero de secuencia valga 232 1, es decir, el mayor nmero que se puede representar con 32 bits, el prximo nmero de secuencia utilizado ser 0, es decir, se dar la vuelta al marcador. Por supuesto, cunto se tarda en dar la vuelta al marcador depende directamente de cuntos datos se enven, y en cuanto tiempo.

quedara: 0 1 + 300 = 299. Por tanto, 299 sera el nmero de secuencia del prximo paquete. En realidad, el nmero de secuencia no tiene por qu comenzar en cero. El principal motivo es que si todas las conexiones empezasen en 0, no se podran reutilizar las conexiones. Ya a estas alturas, habiendo visto todos los campos relevantes, podemos afirmar que lo que identifica una conexin son estos 5 parmetros: ip de origen, ip de destino, puerto de origen, puerto de destino, y nmero de secuencia . Imaginemos que, por ejemplo, nuestro software de correo electrnico est configurado para comprobar si tenemos mensajes nuevos cada 30 segundos. El programa tendr que establecer una conexin TCP/IP con el puerto 110 (puerto de POP3) de un servidor POP3 cada 5 segundos. En este caso, 4 de los parmetros que identifican la conexin podran ser iguales: puerto de origen, puerto de destino, ip de origen, e ip de destino. Digo que podran porque el puerto de origen se podra cambiar de una conexin a otra (el resto de parmetros no se podran cambiar de ninguna manera), aunque esto en muchos casos no ser posible o conveniente. Por tanto, el nico parmetro con el que podemos jugar para poder establecer nuevas conexiones similares sin que se confunda la nueva con una vieja que ya se cerr, es el nmero de secuencia. Si cada vez que el programa de correo se reconecta al servidor POP3 utilizamos el mismo nmero de secuencia para comenzar la sesin (por ejemplo, 0), si
Pgina 23

En la imagen podemos ver reflejado esto. Como vemos, el primer nmero de secuencia es 0, y el primer paquete contiene 200 bytes de datos. Por tanto, el segundo paquete tendr nmero de secuencia 200. Este paquete contiene 12345 bytes de datos, por lo que el prximo paquete tendr como nmero de secuencia: 200 (nmero de secuencia anterior) + 12345 = 15345. As contina la sesin, hasta que un paquete tiene como nmero de secuencia 232 1, y contiene 300 bytes de datos. En teora, el prximo nmero de secuencia tendra que ser 232 1 + 300 pero, como solo contamos con 32 bits para representar este nmero, tendremos que dar la vuelta al marcador, es decir, convertir el 232 en un 0, por lo que nos
PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

llegase un paquete muy retrasado del servidor de correo de una conexin anterior (de los 5 segundos anteriores), no habra forma de saber si este paquete perteneca a la sesin anterior, o a la nueva sesin. Una forma sencilla de evitar esto es no utilizar siempre el mismo nmero de secuencia para comenzar una sesin, si no ir utilizando nmeros de secuencia cada vez mayores. Veamos un ejemplo de esto a partir de la siguiente figura.

ms de lo normal en llegar a B. Como A ya ha enviado lo que quera, cierra la conexin, a pesar de que todava no ha recibido la confirmacin de que B recibi el paquete Seq = 200. Inmediatamente despus, A decide establecer una nueva conexin con B para enviarle otros datos. Comienza enviando un primer paquete con Seq = 0, al cual responde B con su confirmacin de recepcin. Para entonces, ya ha llegado a B el paquete Seq = 200 de la anterior conexin, por lo que construye su paquete de confirmacin. Pero la mala suerte se confabula contra estas dos mquinas, y justo en ese instante A enva un nuevo paquete, que tiene tambin nmero de secuencia 200. Inmediatamente B enva la confirmacin de recepcin del paquete Seq = 200 de la anterior conexin. Qu ocurre a partir de aqu? 1.- Desde el punto de vista de A, B ha recibido correctamente el ltimo paquete, por lo que contina transmitiendo nuevos paquetes, borrando de su memoria el paquete Seq = 200, por lo que nunca lo reenviar. 2.- Desde el punto de vista de B, acaba de recibir un nuevo paquete Seq = 200. Como B ya haba recibido un paquete Seq = 200, interpreta que ste paquete es un reenvo del anterior, por lo que lo desecha. Por tanto, ni B recoge el paquete Seq = 200, ni A se entera de lo que ha pasado. En realidad las cosas no son exactamente como las pinto, pero ya iremos viendo ms adelante cmo es todo esto realmente.
PC PASO A PASO N 20

En primer lugar, la mquina A abre una conexin con la mquina B. Una vez abierta la conexin, A empieza a transmitir sus datos, empezando por un paquete con nmero de secuencia Seq = 0. B lo recibe y devuelve su confirmacin de recepcin. A continuacin, A transmite un nuevo paquete, con nmero de secuencia 200 (por tanto, el primer paquete tena que contener 200 bytes de datos). Por algn azar del destino, este paquete va a tardar
Pgina 24

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

Por supuesto, el nmero de secuencia no sirve slo para detectar paquetes duplicados, o para diferenciar unas conexiones de otras, si no tambin para poder ordenar los paquetes. Como el nmero de secuencia representa el orden exacto en bytes de los datos, es imposible confundirse a la hora de unir los datos en el orden correcto.

4.4. Nmero de confirmacin

Este campo es el que se utiliza para hacer las confirmaciones de recepcin de las que tanto hemos hablado. Su funcionamiento es muy similar al del nmero de secuencia, porque en realidad tambin representa un orden en bytes de los datos. Lo que se enva en el nmero de confirmacin es otro nmero de 32 bytes que indica cul es el prximo byte que estamos esperando recibir. Este campo slo tiene significado si el paquete tiene activo el flag ACK, pero eso ya lo veremos ms adelante.

4.5. Comienzo de datos

Este campo no era necesario en el caso de UDP, ya que la cabecera UDP tiene un tamao fijo de 8 bytes. En cambio, la cabecera TCP puede tener un tamao variable, tal y como veremos ms adelante, por lo que es necesario indicar a partir de qu punto comienzan los datos y termina la cabecera. Este punto de comienzo no se expresa en bytes, como podramos esperar, si no en palabras de 32 bits. Si nos fijamos en la cabecera, veremos que est estructurada en filas, cada una de las cuales mide 32 bits. La primera fila contiene los puertos de origen y destino, la segunda el nmero de secuencia, la tercera el nmero de confirmacin, etc. El valor ms habitual para este campo es 5, que equivale a 20 bytes de cabecera, es decir, lo mnimo que puede ocupar la cabecera TCP.
Pgina 25

Si nuestro compaero en una conexin nos enva un paquete con nmero de secuencia 2000, y el paquete contiene 350 bytes de datos, el prximo nmero de secuencia sera el 2350. Si queremos confirmar que hemos recibido el paquete con nmero de secuencia 2000, tendremos que enviar en nuestro paquete de respuesta un nmero de confirmacin que valga 2350, diciendo as: Ya puedes enviarme el paquete 2350. He recibido todo bien hasta aqu. Vamos a ver la misma figura que pusimos al hablar sobre el nmero de secuencia, pero esta vez incluyendo los nmeros de confirmacin.
PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

4.6. Espacio reservado

Despus del campo comienzo de datos, ve m o s q u e h ay u n o e n e l q u e simplemente pone 0. Este es un espacio reservado de 4 bits, que hay que dejar a cero, sin ms.

Imaginemos que queremos ver el contenido de un archivo remoto, por ejemplo en Linux, y hacemos un cat del archivo: cat archivo.txt

4.7. FLAGS (URG, ACK, PSH, RST, SYN, FIN)

Aqu tenemos tambin un asunto que va a dar mucho que hablar. Los flags son una serie de indicadores de control, de un nico bit cada uno, con diferentes funciones que detallo a continuacin.

Qu no sabis...

Qu no sabis lo que es cat? Pues tendris que repasar los artculos ya publicados sobre Linux de esta misma revista. ;-) y si no, consulta el google (www.google.com).

4.7.1. Flag URG (Urgent)

Cuando este flag est activo (vale 1, en lugar de 0), estamos indicando que el paquete contiene datos urgentes. La especificacin de TCP no detalla qu se debe hacer exactamente ante unos datos urgentes, pero lo normal es atenderlos con mxima prioridad. Si, por ejemplo, estamos procesando datos anteriores, y nos llega un paquete con datos urgentes, normalmente aplazaremos el procesamiento de los datos anteriores para prestar toda nuestra atencin a los datos urgentes. Y para qu pueden servir los datos urgentes? No es habitual encontrarlos, pero un claro ejemplo es cuando deseamos abortar alguna accin. Por ejemplo, si alguna vez habis conectado por Telnet con un sistema remoto (el propio servicio de Telnet del puerto 23, no los experimentos raros que hacamos en la serie RAW ;-) sabris que con la combinacin de teclas CONTROL- C se puede abortar cualquier accin.
Pgina 26

El caso es que, despus de hacer el cat, descubrimos que el archivo es mucho ms largo de lo que esperbamos y, para colmo, no nos interesa. Pulsamos CONTROL-C y el listado del archivo se aborta sin necesidad de esperar a que el archivo termine de mostrarse entero. El paquete que hemos enviado a la mquina remota conteniendo la orden de abortar el listado, tiene un flag URG activo. Si no existiese este mecanismo, probablemente la mquina remota seguira enfrascada en su asunto inmediato, que es mostrar el listado del archivo, y no habra hecho caso a nuestro CONTROLC hasta que no hubiera terminado con lo suyo. Para garantizar una mayor efectividad del flag URG hay que combinarlo con el flag PSH , que veremos ms adelante.

4.7.2. Flag ACK (Acknowledge)

Cuando este flag est activo (vale 1, en lugar de 0) significa que nuestro paquete, aparte de los datos propios que pueda c o n t e n e r, c o n t i e n e a d e m s u n a
PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

confirmacin de respuesta a los paquetes que est enviando el otro extremo de la conexin. Por tanto, el campo nmero de confirmacin no tiene significado a no ser que est activo este flag.

4.7.3.

Flag

PSH

(Push)
En la imagen podemos ver cmo los paquetes sin flag PSH se van encolando en el buffer de transmisin. Cuando el sistema construye el ltimo paquete (el paquete Seq = 300), ya puede comenzar el envo del archivo. Por tanto, en el ltimo paquete incluye el flag PSH. A partir del instante en que hemos metido en el buffer el paquete con flag PSH, el sistema ir enviando uno tras otro los paquetes a travs del cuello de botella que supone el canal de salida. Se trata de un cuello de botella porque por l slo puede pasar un nico paquete en cada instante, por lo que los paquetes tendrn que ir envindose de uno en uno segn el orden en que fueron ubicados en el buffer de transmisin. Al tratarse de una cola, el primero en llegar ser el primero en salir (lo que se llama una cola FIFO), por lo que primero saldr el paquete con Seq = 0. El ltimo paquete en salir ser el que tiene Seq = 300, que es precisamente el que lleva el flag PSH. En la siguiente imagen vemos todo esto desde el punto de vista del receptor.

Cuando este flag est activo (vale 1, en lugar de 0) indicamos a nuestro propio sistema, y al sistema remoto con el que estamos conectados, que deben vaciar sus buffers de transmisin y recepcin... Creo que ha llegado el momento de hablar sobre los buffers de transmisin y recepcin. :-m En todo sistema TCP tiene que haber dos pequeas memorias, o buffers: una para transmisin, y otra para recepcin. Estas memorias son unas colas de paquetes en las que se van almacenando los paquetes que hay que procesar en espera del momento adecuado. Por ejemplo, supongamos que una aplicacin que corre en nuestro sistema desea enviar un archivo, que ser partido en 4 paquetes TCP. A pesar de que nuestra aplicacin lance la orden de enviar el archivo en un slo instante, nuestro sistema no podr enviar de golpe los 4 paquetes. Por tanto, tendr que construir los paquetes, y luego ponerlos en una cola para que se vayan enviando uno tras otro. Si el sistema pudiera enviar los 4 paquetes a la vez no habra necesidad de tener ninguna cola, pero en la prctica, como en cualquier cola, slo se puede pasar de uno en uno.
PC PASO A PASO N 20

Pgina 27

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

Por el canal de entrada irn llegando los paquetes uno tras otro. Se irn almacenando en el buffer de recepcin, y no sern procesados hasta que llegue el ltimo paquete, que contiene el flag PSH . Como este paquete es el que completa el archivo de 400B, para cuando llegue, el sistema receptor ya podr procesar los datos de los 4 paquetes y reconstruir el archivo original. Como decamos, el flag PSH debe combinarse con el flag URG cuando haya datos urgentes. El flag URG ser el encargado de decir al receptor que ha de atender los datos con mxima prioridad, y el flag PSH se asegurar de que el paquete no se retrase esperando en los buffers.

servidor el resto de nuestros intentos de conexin, el servidor nos responder con RST a cada nuevo intento de conexin, para que nos olvidemos de esa conexin y nos centremos en la que ya tenemos.

4.7.5. Flag SYN (Synchronization)

Cuando este flag est activo (vale 1, en lugar de 0), estamos indicando al otro extremo que deseamos establecer una nueva conexin. Este flag se utiliza nicamente al abrir una nueva conexin. Ms adelante veremos el mecanismo exacto por el que se establecen las conexiones, as como algunas cuestiones de seguridad relacionadas con este flag.

4.7.4. Flag RST (Reset)

Cuando este flag est activo (vale 1, en lugar de 0), estamos indicando al otro extremo de la conexin que algo no anda bien, ya que los datos que nos han llegado no coinciden con nuestra conexin, por lo que se ha perdido la sincronizacin entre ambas partes. Ante cualquier campo incorrecto que recibamos (nmeros de secuencia invlidos, o flags no esperados) tendremos que responder con un paquete con este flag activo, para que el otro extremo se entere del problema, y se cierre la conexin para re-sincronizar ambas partes. Un uso tpico de este flag es cuando estamos intentando conectar con un servidor, enviando varios paquetes para establecer la conexin, y al final uno de ellos tiene xito. Si despus de ese paquete de conexin siguen llegando al
Pgina 28

4.7.6. Flag FIN (Finish)

Cuando este flag est activo (vale 1, en lugar de 0), indicamos al otro extremo de la conexin de que, por lo que a nosotros respecta, la conexin ya se puede cerrar. Normalmente, una vez que enviemos nuestro propio FIN , tendremos que esperar a que nuestro compaero nos enve el suyo. Una vez puestos los dos de acuerdo en que no hay ms que hablar, se puede cerrar la conexin pacficamente. Tanto RST como FIN se utilizan para finalizar conexiones, pero la diferencia es que RST avisa de una situacin de error, mientras que FIN avisa de una terminacin sin problemas. Ante una terminacin con RST, normalmente las aplicaciones avisarn al usuario, por ejemplo con una ventana avisando que se ha perdido la conexin.

PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

4.8. Ventana
Este campo es el que se utiliza para llevar a cabo el control de flujo implementado en TCP. Como ya dije, el control de flujo permite evitar la congestin debida a la diferencia de velocidad (bien por capacidad de procesamiento, o bien por ancho de banda) entre ambas partes de una conexin. Una forma muy sencilla de conseguir esto es hacer que cada extremo de la conexin vaya indicando a cada momento cmo de congestionado est. La mejor forma de indicar esta medida de congestin es decir cuntos bytes vamos a ser capaces de procesar en un momento dado. Por tanto, a cada paquete le acompaa un nmero de 16 bits, que es el nmero de bytes que estamos preparados para recibir en el prximo paquete. Esto significa que, como mximo, un paquete podr contener 65536 bytes de datos, es decir, 64KB, ya que es el mximo que podemos solicitar en cada momento. Normalmente, el tamao de la ventana est relacionado con la cantidad de espacio libre que tenemos en el buffer de recepcin. Vamos a ver un ejemplo.

En primer lugar, la mquina A enva un paquete de 1000 Bytes, con nmero de secuencia 0. La mquina B lo recibe y procesa correctamente, y enva su confirmacin de recepcin, indicando que la mquina A puede continuar enviando a partir del byte 1000 (Ack=1000). Adems, le indica que est preparada para recibir otros 1000 bytes ms. Si hacemos cuentas, en realidad lo que est diciendo la mquina B es que est preparada para recibir los bytes del 1000 al 1999. La mquina A contina transmitiendo, y lo hace esta vez con 1000 bytes ms de datos, empezando, por supuesto, por el nmero de secuencia 1000. La mquina B tambin los recibe sin problemas, pero se est empezando a agobiar un poco, por lo que avisa en su confirmacin de que el prximo paquete no podr ser tan grande y, como mucho, tendr que ser de 500 bytes nada ms. La mquina A, en cambio, no ha recibido a tiempo la nueva ventana, y ha seguido enviando los paquetes al ritmo que llevaba anteriormente. Por tanto, el prximo paquete (Seq=2000) contiene tambin 1000 bytes de datos, a pesar de que la nueva ventana de B admite slo 500 bytes. Justo despus de enviar este paquete demasiado grande, la mquina A recibe ya el aviso de B de que se est congestionando, por lo que decide esperar a ver cmo se las apaa su compaero. Cuando B ha podido procesar unos cuantos datos, avisa a A de que puede seguir enviando, aunque slo ha procesado 500 bytes de los 1000 que le envi y,

PC PASO A PASO N 20

Pgina 29

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

adems, el prximo paquete tendr que ser como mximo de 250 bytes. En respuesta, A enva un nuevo paquete, comenzando en el byte 2500, y conteniendo tan slo 250 bytes. Todo esto es muy bonito, A y B son muy amigos, y A le va enviando a B las cosas poco a poco cuando ste se agobia. Pero esto en realidad no es una idea muy buena. Si A va haciendo caso a B segn ste le vaya diciendo lo que puede manejar, y B va avisando a A segn vaya liberando hueco en su buffer de recepcin, los paquetes que se transmitan irn siendo cada vez ms pequeos. En el peor de los casos, podra llegar a ser 0 la ventana de B, y en el instante en que hiciese hueco para un msero byte, avisar a A, por lo que A le enviara un paquete con un nico byte de datos. Esto dara lugar a una transferencia muy poco efectiva de los datos, donde muchos de los paquetes seran de un tamao ridculo. Por tanto, es aconsejable no ir ajustndose literalmente al tamao de la ventana, si no dejar unos pequeos mrgenes. Por ejemplo, cuando se detecte que la ventana va decreciendo por momentos, lo mejor es esperar un tiempo para dejar que la ventana vuelva a recuperar toda su capacidad, y continuar entonces la transmisin. Si fusemos con prisas, empendonos en enviar ms y ms datos, la reduccin de tamao de la ventana sera cada vez mayor, y la transferencia cada vez menos eficiente. En el caso de que la ventana llegue a ser cero, la responsabilidad del receptor (el que se ha congestionado) es avisar cuando su ventana se recupere, con un
Pgina 30

mensaje (vaco si hace falta) cuya nica finalidad sea precisamente avisar del cambio de la ventana. Por otra parte, la responsabilidad del emisor (el que ha congestionado al otro) es dejar de enviar ms datos, y esperar un tiempo prudencial para continuar la transmisin pasados unos dos minutos, si es que el receptor no ha enviado una nueva ventana antes.

4.9. Suma de comprobacin

Al igual que en el caso de UDP, la suma de comprobacin se calcula mediante una operacin de aritmtica binaria (suma en complemento a uno de 16 bits) que se realiza sobre una cabecera especial que contiene los datos ms relevantes. Cada vez que se recibe un paquete TCP, hay que realizar esta misma operacin con los datos recibidos, y comparar el nmero obtenido con el campo suma de comprobacin del paquete. Si ambos nmeros no son iguales, los datos son incorrectos, y ser necesaria una retransmisin de los mismos. En ese caso, no enviaremos la confirmacin de recepcin pertinente, esperando a que el emisor decida retransmitir el paquete al ver que no les respondemos. Aunque ya lo coment en el anterior artculo, os recuerdo que tenis detallada la operacin de la suma de comprobacin en el RFC 1071, y que tenis un cdigo de ejemplo en C en la siguiente URL: http://www.netfor2.com/tcpsum.htm En este caso no tenis que realizar ninguna modificacin sobre el cdigo, ya que sirve precisamente para calcular la suma de comprobacin de TCP. La cabecera que se forma para llevar a cabo la suma de comprobacin es la siguiente:
PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

4.11. Opciones
Como vemos, es igual que la de UDP, slo que en este caso el protocolo es el 6, en lugar del 17. Llegamos al fin al ltimo campo de la cabecera TCP. Este campo es opcional, y es el responsable de que la cabecera TCP sea de tamao variable y, por tanto, de la necesidad del campo comienzo de datos. En realidad, slo existe una opcin definida por el estndar en el RFC de TCP, pero la cabecera se dise con previsin de incluir otras opciones. La opcin definida se utiliza nicamente al establecer una nueva conexin. Lo que indica este campo opcional es el mximo tamao de los segmentos que estamos dispuestos a recibir. Un segmento es cada una de las partes en las que se dividen los datos, por lo que nuestro compaero de conexin no debe enviarnos nunca paquetes ms grandes de lo que indiquemos con esta opcin. En el caso de que no usemos este campo opcional, nos podr enviar paquetes de cualquier tamao ajustndose, eso s, a nuestra ventana de recepcin. Y qu relacin hay entonces entre la ventana de recepcin y el tamao mximo de segmento? Pues la ventana es un parmetro dinmico, que va variando segn la congestin que hay en cada momento, mientras que el tamao mximo de segmento es una constante para toda la sesin, que se establece de antemano. Muchas veces, el tamao mximo de segmento ser menor que la ventana. Esto puede parecer absurdo, pero no es as, ya que el tener
Pgina 31

4.10. Puntero de urgencia

Cuando hablamos sobre el flag URG dijimos que serva para indicar que el paquete contiene datos urgentes. Pero, significa esto que los datos tienen que ir en un nico paquete para ellos solos? Esto podra ser poco eficiente, ya que los datos urgentes podran ser tan slo unos pocos bytes, y nos obligara a enviar paquetes casi vacos slo para poder transmitir el dato urgente. Por ejemplo, el CONTROL-C del que hablbamos, es un comando muy breve, y sera un desperdicio enviar paquetes vacos que slo llevasen ese comando. Por tanto, TCP permite combinar en un mismo paquete datos urgentes con datos no urgentes. Para conseguir esto, el campo puntero de urgencia nos indica el punto a partir del cual terminan los datos urgentes. Si, por ejemplo, nuestro paquete contiene 1000 bytes de datos, y el puntero de urgencia es 150, sabremos que los 150 primeros bytes del paquete son urgentes, y los otros 850 son datos normales. Por supuesto, esto slo tendr sentido si el flag URG est activo. Si no es as, el campo puntero de urgencia simplemente ser ignorado.
PC PASO A PASO N 20

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

una ventana mayor que el tamao mximo de segmento indica que tenemos recursos suficientes para recibir varios paquetes en poco tiempo. Por tanto, el tamao mximo de segmento no es til para realizar un control de flujo, si no tan slo una restriccin para el tamao mximo que pueden tener los paquetes. Pero vamos a ver cmo se indica exactamente esta opcin. Como ya hemos visto, existen dos casos: o que no indiquemos ninguna opcin , o que indiquemos el tamao mximo de segmento. En el primer caso, simplemente terminar en este punto la cabecera TCP, y comenzarn a partir de aqu los datos. Por eso, cuando hablbamos del campo comienzo de datos dijimos que el tamao mnimo de la cabecera (que es este caso) es de 20 bytes.

La opcin que hemos mencionado, la nica definida en el RFC, encaja exactamente en 32 bits, por lo que no hay que hacer ningn ajuste. El formato exacto de esta opcin lo veremos ms adelante cuando veamos las cabeceras a nivel de bits. En cambio, no slo existen las opciones definidas en el RFC 793. Podemos ver una lista de opciones TCP mantenidas, p a r a v a r i a r, p o r e l I A N A , e n : http://www.iana.org/assignments/tcpparameters Una opcin que nos podremos encontrar con facilidad de las de esa lista, es la opcin SACK, utilizada para confirmaciones selectivas ( S elective ACKnowledgment). Los detalles sobre esta opcin los tenis en el RFC 2018 (ftp://ftp.rfc-editor.org/innotes/rfc2018.txt). Si las opciones no encajan en 32 bits, habr que completar la fila con ceros. Para separar las opciones entre s se utiliza una opcin especial sin ningn efecto (NOP = No OPeration) que ocupa un nico byte. Para terminar la lista de opciones existe tambin otra opcin especial, de un nico byte, que indica que no hay mas opciones y, por tanto, una vez completada la palabra de 32 bits, vendrn a continuacin los datos del paquete. Todo esto lo veremos en ms detalle en el prximo artculo, en el cual empezaremos construyendo como ejercicio una cabecera TCP desde cero a bajo nivel, es decir, en binario puro y duro. Espero que estis preparados! ;-)
PC PASO A PASO N 20

En el segundo caso, en cambio, habr que rellenar el campo opciones de la cabecera. Y no slo eso, si no que adems hay que ajustarlo a un tamao de 32 bits, que es lo que ocupa cada fila de la cabecera TCP (en realidad, se trata del tamao de la palabra, ya que la idea de filas es slo una abstraccin para ver ms fcilmente la estructura de la cabecera).

Pgina 32

CURSO TCP/IP (III) - TCP ( TRANSMISSION CONTROL PROTOCOL)

Para terminar, os incluyo aqu la cabecera TCP con los nombres originales, en ingls, por si completis este curso con alguna otra lectura, para que veis la correspondencia y no os liis.

IMPORTANTE

IMPORTANTE: Ya habr tiempo de pasar a la practica, ahora es importante que empecemos a familiarizarnos con un montn de trminos y conceptos que seguramente (para la mayora) son completamente desconocidos. No te preocupes demasiado si muchas cosas te han quedado oscuras, ya empezars a verlas claras cuando relacionemos la teora con la practica y veas la utilidad real de cada concepto explicado aqu.

Autor: PyC (LCo)