Google propone 1 protocolo para doblar la velocidad d la web

Pues si... la verdad es que nunca me ha parecido bien eso de descargar todas las imagenes e iconos individualmente...


Saludos!

NeDark escribió:Pues si... la verdad es que nunca me ha parecido bien eso de descargar todas las imagenes e iconos individualmente...


Saludos!

Mmm, si, pero tampoco me imagíno que mi conexión diera para tanto, aun que 6 megas son 6 megas, pero en cuanto vean que pueden sobrecargar mas las web con ese protocolo, 6 megas ya no serán suficientes, y tardaríamos lo mismo en cargar varias web del tirón...

No se trata de eso en realidad, es la latencia propia, te explico.

Para cada distinto elemento tiene que cargar el navegador archivos esternos (todas las imagenes e iconos, distintos scripts de javascript, hojas de etilo...)

Para cada una de ellas se tiene que abrir una conexion HTTP, pero resulta que el numero de conexiones esta limitada. Si por ejemplo el maximo es 10, y hay 35 elementos en una pagina, pues tiene que ir cargandolos todos hasta ir dejando conexiones libres. Eso unido al tiempo de peticion y respuesta del propio protocolo hace que pueda sea mas lento comparandolo con este nuevo protocolo.

Este protocolo (si no me equivoco) agrupa en una unica peticion (una unica conexion) todos los elementos de una pagina, asi que se van recibiendo uno detras de otro y pueden ser ordenados de mas "importantes" (estilos, javascript) y despues los menos importantes (iconos seguidos de imagenes).

Y segun sus pruebas han conseguido aumentar la velocidad ese porcentaje.

Y recalco una cosa por si no ha quedado clara. No depende de los KB/s sino del propio PING el tiempo de carga de las mayoria de la paginas. En realidad los archivos de texto (hojas de estilo, javascript) y tambien las imagenes de pocos KB (avatares, firmas, iconos aqui en el foro) no se tarda nada en ser transferidos sino que tarda mas por el propio ping (el ping de cada elemento sumado a todos los elementos y teniendo en cuenta el limite de conexion). Pero por ejemplo una imagen mediana o grande si que depende de la velocidad de descarga. Eso si que depende de la velocidad no mejora nada ahi este protocolo, pero la estructura basica de una pagina o las paginas con elementos pequeños si que aumentaria muchisimo el tiempo de carga.


Saludos!

NeDark escribió:No se trata de eso en realidad, es la latencia propia, te explico.

Para cada distinto elemento tiene que cargar el navegador archivos esternos (todas las imagenes e iconos, distintos scripts de javascript, hojas de etilo...)

Para cada una de ellas se tiene que abrir una conexion HTTP, pero resulta que el numero de conexiones esta limitada. Si por ejemplo el maximo es 10, y hay 35 elementos en una pagina, pues tiene que ir cargandolos todos hasta ir dejando conexiones libres. Eso unido al tiempo de peticion y respuesta del propio protocolo hace que pueda sea mas lento comparandolo con este nuevo protocolo.

Este protocolo (si no me equivoco) agrupa en una unica peticion (una unica conexion) todos los elementos de una pagina, asi que se van recibiendo uno detras de otro y pueden ser ordenados de mas "importantes" (estilos, javascript) y despues los menos importantes (iconos seguidos de imagenes).

Y segun sus pruebas han conseguido aumentar la velocidad ese porcentaje.

Y recalco una cosa por si no ha quedado clara. No depende de los KB/s sino del propio PING el tiempo de carga de las mayoria de la paginas. En realidad los archivos de texto (hojas de estilo, javascript) y tambien las imagenes de pocos KB (avatares, firmas, iconos aqui en el foro) no se tarda nada en ser transferidos sino que tarda mas por el propio ping (el ping de cada elemento sumado a todos los elementos y teniendo en cuenta el limite de conexion). Pero por ejemplo una imagen mediana o grande si que depende de la velocidad de descarga. Eso si que depende de la velocidad no mejora nada ahi este protocolo, pero la estructura basica de una pagina o las paginas con elementos pequeños si que aumentaria muchisimo el tiempo de carga.


Saludos!

A ver, no se, esto me lo explicaron hará bastante tiempo, pero por lo que me dijeron (y no me lo dijo un cualquiera), no todas las aplicaciones web (javascripts, flash player y etc...) se cargan desde la web, las hay que se cargan desde el servidor enviando el resultado al ordenador, y de otras que se descargan en el ordenador para luego ejecutarlas.

De todas formas, de lo que se habla aquí, no solo es la latencia de respuesta, si no también de los elementos que se descargan al ordenador desde el servidor, por que vale que puedas tener 25ms de respuesta de tu linea y el servidor tenga (no se, por ejemplo) 10ms de respuesta, pero dado que tu linea tiene 15ms de mas igualmente te iría como el culo. Pero bueno, de todos modos, si no me va ni por 3 o 4 segundos de mas, ¿que me importan los milisegundos de ping de respuesta?.

Sin contar los "por que si, se tienen que contar" la tasa real de tu conexión, que bueno, con 6Mb (que en realidad suponen mas que unos 700-750Kbytes limpios -mas o menos-) y 5 o 6 webs sobrecargadas no tienes muchos problemas, pero los hay que aun navegan con 4,3,2,1Mbit/s e incluso con conexiones de 56Kbps, lo cual la cosa ya jode bastante.

Si por lo que dices, lo único que tal vez fuera necesario el nuevo protocolo son tal vez las prioridades de descarga, por que vamos, a mi ordenador se la trae floja (y a cualquier persona también) que tu ordenador tenga que hacer 10 peticiones para cargar 10 objetos por separado, como si esas 10 peticiones están conjuntas en una lista. A lo sumo, para la próxima revisión del protocolo http y derivados, podrían incluso añadirle la descarga en paralelo y las prioridades de descarga de elementos.

Pero vamos, que no lo se, tal vez ha cambiado mucho el internet desde la última vez que me interese por ello...
P.D. No se si me explico, digo esto desde la ignorancia mas que nada, pero bueno, por eso contesto, para saber si mis dudas tiene respuesta.

Y, aunque prospere, el límite de peso de una firma en EOL seguirá siendo 25Kb

nesquik escribió:A ver, no se, esto me lo explicaron hará bastante tiempo, pero por lo que me dijeron (y no me lo dijo un cualquiera), no todas las aplicaciones web (javascripts, flash player y etc...) se cargan desde la web, las hay que se cargan desde el servidor enviando el resultado al ordenador, y de otras que se descargan en el ordenador para luego ejecutarlas.

Si, claro, pero al final es lo mismo. Por ejemplo para un archivo php (contenido dinamico, casi todas las paginas webs (incluido eol) funcionan con el aunque este oculta la extension en las URL), se hace la peticion al servidor y es el servidor quien se encarga de procesar el php y una vez procesado manda la respuesta en HTML. En este nuevo protocolo seria exactamente igual, solo que haria la peticion de todos los elementos de una vez, y es el servidor quien se tiene que preocupar de devolverlo.

nesquik escribió:De todas formas, de lo que se habla aquí, no solo es la latencia de respuesta, si no también de los elementos que se descargan al ordenador desde el servidor, por que vale que puedas tener 25ms de respuesta de tu linea y el servidor tenga (no se, por ejemplo) 10ms de respuesta, pero dado que tu linea tiene 15ms de mas igualmente te iría como el culo. Pero bueno, de todos modos, si no me va ni por 3 o 4 segundos de mas, ¿que me importan los milisegundos de ping de respuesta?.

Mira un ejemplo practico, el de antes: 35 elementos en unas pagina

Cada elemento vamos a darle una media de 30KB.

PC: Peticion HTTP (Ping EFECTIVO entre PC y servidor: 60ms).
Server: Respuesta HTTP (Ping EFECTIVO entre servidor y PC: 20ms).

En cada peticion de pierde 80ms. Pero se pueden hacer 10 peticiones a la vez.

80mb * 35 (elementos) / 10 (peticiones paralelas) = 280ms

Se han perdido 280ms cuando con una peticion se podria dejar en una conexion (80ms).

nesquik escribió:Sin contar los "por que si, se tienen que contar" la tasa real de tu conexión, que bueno, con 6Mb (que en realidad suponen mas que unos 700-750Kbytes limpios -mas o menos-) y 5 o 6 webs sobrecargadas no tienes muchos problemas, pero los hay que aun navegan con 4,3,2,1Mbit/s e incluso con conexiones de 56Kbps, lo cual la cosa ya jode bastante.

Si por lo que dices, lo único que tal vez fuera necesario el nuevo protocolo son tal vez las prioridades de descarga, por que vamos, a mi ordenador se la trae floja (y a cualquier persona también) que tu ordenador tenga que hacer 10 peticiones para cargar 10 objetos por separado, como si esas 10 peticiones están conjuntas en una lista. A lo sumo, para la próxima revisión del protocolo http y derivados, podrían incluso añadirle la descarga en paralelo y las prioridades de descarga de elementos.

Pero vamos, que no lo se, tal vez ha cambiado mucho el internet desde la última vez que me interese por ello...
P.D. No se si me explico, digo esto desde la ignorancia mas que nada, pero bueno, por eso contesto, para saber si mis dudas tiene respuesta.

En eso si que estoy de acuerdo, que hagan mas rapido el firefox primero por ejemplo que esta empezando a apestar bastante contra chrome y opera.

PD: Si es verdad que unos 200ms no es nada, pero ahora en chrome tarda nada en cargar, pues supondra los porcentajes que han logrado. Y tampoco es por el tiempo, como dije antes eso de pedir todos los elementos individualmente y abrir un monton de conexiones ¿para que? si se puede hacer de una vez.


Saludos!


EDIT:

Pego unas cosas del FAQ de google:

Q: TCP has been time-tested to avoid congestion and network collapse. Will SPDY break the Internet?

A: No. SPDY runs atop TCP, and benefits from all of TCP's congestion control algorithms. Further, HTTP has already changed the way congestion control works on the Internet. For example, HTTP clients today open up to 6 concurrent connections to a single server; at the same time, some HTTP servers have increased the initial congestion window to 4 packets. Because TCP independently throttles each connection, servers are effectively sending up to 24 packets in an initial burst. The multiple connections side-step TCP's slow-start. SPDY, by contrast, implements multiple streams over a single connection.

http://dev.chromium.org/spdy/spdy-whitepaper

entonces, si esto se hace oficial, toda la programación de paginas web cambiará no?
es decir, esto del spdy es un nuevo lenguaje al igual que php, html, asp etc. no?
habria que acoplar este formato a los programas de diseños de web como dreamweaver y demas o se podria hacer con un conversor o como? ademas, tambien habria que cambiar los navegadores y demas... es que la verdad, siempre se ha usado el html. ahora cambiar todo eso me parece un paso muy grande, tal vez despues con el tiempo nos acostumbremos como con todo, pero, de momento, si esto se instaura habria simplemente otro formato mas, no?

Hellraiser_92 escribió:entonces, si esto se hace oficial, toda la programación de paginas web cambiará no?
es decir, esto del spdy es un nuevo lenguaje al igual que php, html, asp etc. no?
habria que acoplar este formato a los programas de diseños de web como dreamweaver y demas o se podria hacer con un conversor o como? ademas, tambien habria que cambiar los navegadores y demas... es que la verdad, siempre se ha usado el html. ahora cambiar todo eso me parece un paso muy grande, tal vez despues con el tiempo nos acostumbremos como con todo, pero, de momento, si esto se instaura habria simplemente otro formato mas, no?

Ya estamos mezclando churras con merinas...

No confundas HTTP con HTML

Hellraiser_92 escribió:entonces, si esto se hace oficial, toda la programación de paginas web cambiará no?
es decir, esto del spdy es un nuevo lenguaje al igual que php, html, asp etc. no?
habria que acoplar este formato a los programas de diseños de web como dreamweaver y demas o se podria hacer con un conversor o como? ademas, tambien habria que cambiar los navegadores y demas... es que la verdad, siempre se ha usado el html. ahora cambiar todo eso me parece un paso muy grande, tal vez despues con el tiempo nos acostumbremos como con todo, pero, de momento, si esto se instaura habria simplemente otro formato mas, no?

No es un lenguaje, es un protocolo.

A que nunca has visto HTTP en dreamweaver? Es solo un protocolo, lo unico que tendria que cambiar es el programa de servidor, normalmente Apache.


Saludos!

Es que el tema está en que Google es una empresa privada y SPDY sería propiedad de google... vale que HTML tiene limitaciones pero también se puede hacer evolucionar dicho lenguaje en lugar de crear uno nuevo que si no habrá que reprogramarlo todo de nuevo y como he dicho en un primer momento, no me gusta que un protocolo esté en manos de una empresa privada, al final saldremos perdiendo.

Un saludo

BY DERHYUS.

DERHYUS escribió:Es que el tema está en que Google es una empresa privada y SPDY sería propiedad de google... vale que HTML tiene limitaciones pero también se puede hacer evolucionar dicho lenguaje en lugar de crear uno nuevo que si no habrá que reprogramarlo todo de nuevo y como he dicho en un primer momento, no me gusta que un protocolo esté en manos de una empresa privada, al final saldremos perdiendo.

Un saludo

BY DERHYUS.

Y dale... HTML NO ES HTTP.

DERHYUS escribió:Es que el tema está en que Google es una empresa privada y SPDY sería propiedad de google... vale que HTML tiene limitaciones pero también se puede hacer evolucionar dicho lenguaje en lugar de crear uno nuevo que si no habrá que reprogramarlo todo de nuevo y como he dicho en un primer momento, no me gusta que un protocolo esté en manos de una empresa privada, al final saldremos perdiendo.

Un saludo

BY DERHYUS.

No todas las empresas privadas hacen protocolos cerrados. Muchos protocolos abiertos e implementaciones abiertas están contribuidas por "grandes" empresas como IBM o la propia apple (cito esta última por que tiene cosas muy cerradas como el iPhone y cosas abiertas como cups).

Cualquiera puede enviar un Request For Comments.

Pero volviendo a los protocolos de comunicaciones, Google suele hacer uso exclusivo (o casi exclusivo) de protocolos abiertos.

NeDark escribió:

Hellraiser_92 escribió:entonces, si esto se hace oficial, toda la programación de paginas web cambiará no?
es decir, esto del spdy es un nuevo lenguaje al igual que php, html, asp etc. no?
habria que acoplar este formato a los programas de diseños de web como dreamweaver y demas o se podria hacer con un conversor o como? ademas, tambien habria que cambiar los navegadores y demas... es que la verdad, siempre se ha usado el html. ahora cambiar todo eso me parece un paso muy grande, tal vez despues con el tiempo nos acostumbremos como con todo, pero, de momento, si esto se instaura habria simplemente otro formato mas, no?

No es un lenguaje, es un protocolo.

A que nunca has visto HTTP en dreamweaver? Es solo un protocolo, lo unico que tendria que cambiar es el programa de servidor, normalmente Apache.


Saludos!

Dreamweaver apesta, usar notepad++, o el bloc de notas a pelo

sisa989 escribió:Dreamweaver apesta, usar notepad++, o el bloc de notas a pelo

Tampoco uséis Photoshop, que consume muchos recursos. Usad Paint.

O mejor aún, comprad una caja de plastidecor y dos libretas, que están dando muy buenos resultados en los últimos benchmarks.

Kentaro_ escribió:

sisa989 escribió:Dreamweaver apesta, usar notepad++, o el bloc de notas a pelo

Tampoco uséis Photoshop, que consume muchos recursos. Usad Paint.

O mejor aún, comprad una caja de plastidecor y dos libretas, que están dando muy buenos resultados en los últimos benchmarks.

Pues yo para hacer HTML/javascript uso notepad++, basta y sobra.

¿Se irian a la mierda los actuales navegadores o los que no soporten plugins para el nuevo spdy:// ?

ayba! perdon, es que lei mal, es solamente eso, no se porque he leido html
ya lo siento
gracias por la aclaración

Kentaro_ escribió:

sisa989 escribió:Dreamweaver apesta, usar notepad++, o el bloc de notas a pelo

Tampoco uséis Photoshop, que consume muchos recursos. Usad Paint.

O mejor aún, comprad una caja de plastidecor y dos libretas, que están dando muy buenos resultados en los últimos benchmarks.

LOL

Chomin escribió:¿Se irian a la mierda los actuales navegadores o los que no soporten plugins para el nuevo spdy:// ?

¿O simplemente se actualizarán los navegadores y nos tendremos que "olvidar" de poner http (si es que no lo hemos olvidado ya)?

SPDY es como un parche para HTTP, solo tienen que actualizar los nevegadores. Y por supuesto los servidores seguiran siendo compatibles con el HTTP aunque tenga tambien este protocolo.

NeDark escribió:SPDY es como un parche para HTTP, solo tienen que actualizar los nevegadores. Y por supuesto los servidores seguiran siendo compatibles con el HTTP aunque tenga tambien este protocolo.

Yo creo que también habría que actualizar los proxy-cache y más software http que navegadores y servidores.

Has de pensar de lo dificil que resultará así cachear imágenes al tener que leerse todo lo que pasa por la capa de aplicación.

Joder, que sigue siendo HTTP coño, pero mandando todos los archivos a la vez, el navegador ya se encargara de separarlos y procesarlos.

Y no es algo imprescindible, solo si los dos clientes tienen SPDY pues usuara este protocolo, sino pues se siguira con HTTP.


Saludos!