Donde dice: “…un paquete de confirmación, sino no acabaríamos nunca”, debe decir: “…un paquete de confirmación, si no, no acabaríamos nunca”

Kent, espero que sigas escribiendo, que tienes a medias la serie y está fenomenal

No hay perdón!!! a la hogueraaaaaa!!!!!

Es broma ^^

@uno más,

Conocia la ventana deslizante, pero la obvié para simplificar la explicación. Sin embargo, creo que es un punto importante, lo añadiré al artículo.

@Aracem

Aqui no valen disculpas, he metido el zueco hasta el fondo al confundir la fragmentación con la gestion cliente-servidor que hace TCP. Pido disculpas a todos por ellos, lo cambiaré en los artículos para que quede claro.

Otro error gracioso que nos comentó mi profesor fue el del famoso incendio de la expo de sevilla que fue causado porque utilizaban un tipo de cable (la memoria no me llega para tanto :S pero debe ser que utilizaban SLIP ) que sólo permitía un tipo de protocolo a la vez Es decir, si se usa http pues http Pues se quemó porque al saltar las alarmas éstas no podían mandar el aviso por el cable porque ya estaba siendo utilizado por otro protocolo.

Maldición, ¿qué errores?? Prácticamente nadie tiene en cuenta una cosa tan estúpida (y trivial) como que las aplicaciones, los programas, las redes, los cables, los servidores, etc, TODO puede fallar. Es más, según la conocida y nunca bien ponderada Ley de Golub:

-”Todo lo que puede ir mal, irá mal”. Ley que tiene un conocido Corolario:

• “Aquello que de ninguna manera puede ir mal, irá mal, no obstante”.

En el mundo real, todo sistema tiene que estar preparado para cuando pasen estas cosas. No para “que” pasen, sino para “cuando” pasen. En las redes, mediante los controles de errores que citas (los más usados, los CRC, controles de redundancia cíclica, algortimos que no sólo son capaces de detectar un error con una altísima probabilidad, aunque, Ojo, nunca del 100%, sino que en muchos casos pueden incluso recuperar el error, si no es “demasiado” grande), puesto que “Todo aquello que se transmite de un lado a otro puede llegar alterado”, según nos decía en los turbulentos mediados de los 70 mi profesor de “Tele-rollo”.

Pero en las aplicaciones, también: hay que estar preparado para cuando un programa “se vuelve loco” y te destroza toda la Base de Datos de Clientes (yo lo he visto con mis ojitos), o cuando un disco “hace pluff” y queda inservible, y nos deja sin poder acceder a la información que había dentro, o cuando un servidor explota y nos quedamos sin el “Importantísimo Servicio X” sin el cuál, nuestra empresa no puede seguir funcionando…

Un ejemplo: En una instalación grandecita española, digamos un gran Banco, una Eléctrica, un buen Ministerio, etc, con operación 365×24, es normal tener datos valiosos con un tamaño de unas 400 ó 500 Teras de información. Es decir, medio millón de Gigas, ó 400 ó 500 millones de Megas. Y eso sin contar el Data Warehouse, que se puede llevar otros 200 Teras él solito.

Esa cantidad de datos necesitan alrededor de 5.000 discos de 100 Gb cada uno, aunque no necesariamente tienen por qué ser tan grandes: lo normal es que su tamaño medio sea más pequeño.

Sigamos. Cada disco, de alta calidad, puede tener un MTBF de, digamos, tres años, que está bastante bien (MTBF es el Medium Time Between Failures, es decir, el tiempo medio que ese dispositivo tarda en fallar. En este ejemplo, estar tres añitos de media funcionando 24 horas diarias sin fallar, no está nada mal). Sigamos siguiendo: Unas breves operaciones nos dirán que:

En dicha instalación de ejemplo, pero perfectamente real, se estropea un número medio de… 5 discos diarios. 5 diarios. Habrá días de doce o quince. Que lo mismo contienen un trozo de la Base de Datos de Clientes, como de facturas, como ficheros personales de los usuarios, documentos importantes, Planes de Negocio,….

Poca gente es consciente de estas cifras, pero son “El pan nuestro de cada día”.

… Por cierto: ¿Habéis hecho backup de vuestra información esta semana? Ejem…

Un saludo

Un saludo

P.D: Kent, si quieres ponerte en contacto conmigo para que yo me ocupe de las capas bajas de internet y tú de aplicación y así queda mucho mejor la serie envíame un mp o un correo a marcostruji@hotmail.com y ya lo gestionamos ok?

Por lo demás , em gustaría comentar unas pequeñas incorrecciones que has cometido.

El protocolo TCP no es el encargado de reagrupar los paquetes como has comentado, es más, en las cabeceras de TCP NO están los campos necesarios para tal fin.

Más técnicamente al hecho que tú comemtas se le llama “fragmentación de paquetes”

El protocolo encargado de ello es el IP, mediante unos sencillos campos (no tan sencillos de programar , por experiencia xD )

Hay un campo de tan solo un bit, comúnmente llamados en programación “flags” o “banderas” , este campo se le llama More Fragment (MF) que si está a 1 indica que hay fragmentación y por lo tanto el paquete está “roto” en varios trocitos, y si está a 0 indica que no hay fragmentación ( o en tal caso que es el último paquete si el siguiente campo es distinto de 0 )

El siguiente campo es el Offset del fragmento, o hablando en cristiano, el lugar que debe ocupar el trocito de mensaje siguiente. Digamos que si tenemos un texto de 100 palabras y tenemos que dividirlo en 5 partes, el “offset del primero sería 0, el del segundo sería 20, el del tercero sería 40 ….

De esta forma “tan bien pensá” se pueden enviar paquetes de cualquier tamaño por internet ( otra incorrección no sé si de esta entrada o de la anterior es que internet no siempre son paquetes de 1500 bytes, eso es para ethernet, pero por ejemplo ieee 802 es 1492 (es otro tipo de cable) en redes ppp (punto a punto ) es bastante bajo etc etc ) sin riesgo a que se descoloquen y a que no ocurra nada si no llegan ordenados.

Lo que sí hace TCP , y a lo mejor te referías a ello pero no lo has explicado muy bien, es que TCP es orientado a conexión y utiliza un protocolo de “comunicación entre el cliente y el servidor ” para comunicarse. Para comunicarte , tú avispado tamicero (cliente) con , así una página de internet al azar …. mmmm eltamiz.com por ejemplo (servidor ) , tú ordenador y eltamiz.com deben primero conectarse. Básicamente y con un lenguaje así un poco coloquial sería algo así: El cliente(yo) le mando un saludo a eltamiz.com y le digo que quiero conectarme para ver esta magnífica entrada,el serñor tamiz dice que ok, que tiene sitio para mi y me manda un saludo.yo le contesto que me ha llegado su saludo y además le digo que quiero ver esta entrada en concreto (esto ya entraría en el protocolo http ) , el señor tamiz empieza enviarme la página, yo voy contestando que si me llega, el señor tamiz termina y me dice que ya está, el cliente se despide y eltamiz le devuelve la despedida. Y fin. Ese es el protocolo TCP. Dentro de esta conexión están los protocolos de las aplicaciones que imagino que irán en una entrada posterior.

Lo que tu llamas control de entrega es esta conversación extraña que he explicado, no el control de la fragmentación. Se basa en lo que has comentado, que cuando te llega un mensaje como me quiero conectar se envía un mensaje de respuesta diciendo ok, te he oído y yo también me conecto. O cuando se envía un parrafo de esta página, el cliente contesta oye que el parrafo me ha llegado. Todo se hace mediante unos campos de los datagramas llamados Secuencia (SEQ) y ACK , pero eso ya es otra historia, además, puede volverse bastante compleja.

Y así adelantando cosillas que podría explicar yo en una futura entrada sería por ejemplo como se solucionan los problema de los errores. Todas los medios de comunicación (el cable de tu casa, el que va de tu casa al nodo más cercano, el de la antena que se ocmunica con un satélite … ) tienen errores, hay veces que por el cable ethernet de tu casa (por cierto es bastante seguro osea que no tiene muchos ^^ )le afecta un campo magnético que pasaba pro allí de camino a murcia y la importantísima frase : “0001010100111101111″ se convierte en “1001010100111101111″ (sí, están iguales salvo el primer 0 ) Esto, aunque sólo sea un numerito es fatal, puede ser que la foto de tus vacaciones tenga ahora un pixel de otro color ( no lo queremos!!!) o que la página que lees no tenga bien el formato, o lo que es peor!!! que el error esté en la dirección destino a la que es enviado y esta se modifique a otra totalmente diferente (imagínate que quieres leer el tamiz.com para enseñárseloa tú madre y se de cuenta que el LHC no le va a matar y en vez de eso por un error te manda a cualquier otra página un tanto comprometida xXx ) Pues tiene los inventores de estos protocolos diseñaron un campo en la cabecera que mediante una fórmula (eltamiz me prohibe exponerla ) se puede asegurar que si cuando envías el paquete tiene un código , cuando llega aplicando la misma fórmula debe dar un resultado conocido, sino es que ha llegado mal! . Y como TCP, como acabo de explicar, está orientado a conexión (esa conversación extraña que has leído con eltamiz.com ) ese paquete no se tendrá en cuenta y el que lo ha enviado como no le llega un “oye, que te he oído” pues sabe que lo tiene que volver a enviar. (Tu reputación ante tu madre está a salvo! )

Y así como curiosidad, es bueno comentar que internet no es perfecto,que aún hoy se sigue mejorando y los protocolos se perfeccionan ( a parte de crearse otros como voz/ip interesante a la par que Demoledor en los exámenes de junio :’( ) . Sin ir más lejos este verano salió a la luz una importantísima vulnerabilidad del protocolo DNS (protocolo que si le preguntas eltamiz.com te dice su dirección ip básicamente)

Yo voy a explicar una un tanto curiosa que provocó la quiebra de una empresa y la modificación del TCP.

Básicamente a una empresa que vendía por internet unos Crakers conocedores de la red le hicieron un ataque. Éste consistió en desde muchos puntos de internet enviarle peticiones de conexión todo el tiempo. Para hacerlo más gráfico volvemos a la conversación:

Cracker1: Hola quiero conectarme! Servidor: No contigo no Cracker2:Hola quiero conectarme Servidor: No me gustas, así que no. Cracker2:Hola quiero conectarme Cracker3:Hola quiero conectarme Cracker4:Hola quiero conectarme Servidor : mmm al 2 ya te he dicho que no, el 3 y 4 tampoco Cracker1:Hola quiero conectarme Cracker2:Hola quiero conectarme Cracker5:Hola quiero conectarme Cracker21:Hola quiero conectarme Servidor: Oye 2 eres un pesado que no, al 1 tampoco y el resto tampoco Cracker2:Hola quiero conectarme …. [muchísimas peticiones más ] Servidor: Que nooooooooooo Usuario normal: Hola que pasa con mi página que quiero ver, que me la has dejado a medias!!! Servidor: Lo siento, no tengo tiempo, estoy diciéndole ha estos millones de crakers que no quiero conectarme con ellos!!!

Resultado, el servidor estaba tooooooooodo el tiempo gestionando conexiones y no podía hacer otra cosa. El protocolo TCP no estaba correcto y la empresa se fue al garete simplemente, porque internet estaba mal !!

Después de eso, se rediseñó TCP para que si pasaba esto, simplemente no se les hiciera caso a estas conexiones.

Y bueno, espero que mi aporte haya gustado, y a ver si me dais ánimos para hacer la entrada ^^

Un saludo!