4207
blog.chromium.org/2009/11/2x-faster-web.html Actualmente los servidores y los navegadores web se comunican utilizando HTTP, este es un protocolo del año 1996 que hasta ahora ha servido muy bien. Google ha anunciado que esta trabajando en un protocolo experimental llamado SPDY, de la palabra speedy, el cual permite streams de datos bidireccionales y compresión de los datos de las cabeceras. En sus pruebas internas este protocolo es el doble de rápido que HTTP. Google ha publicado el protocolo, la documentación, papers y el código como software libre.
menéame
No nos estarán intentando vender la moto ¿no?
"There is still a lot of work we need to do to evaluate the performance of SPDY in real-world conditions"
De todas formas, bien por Google por innovar y hacerlo libre.
De hecho la gente no imaginaba en los principios de ARPANET que se pudiera recibir algo más que no fuera texto, con lo cual una tasa de 3Ks el segundo era "excesiva".
En el 2.015 ... ¿te acuerdas de cuando Googlenet se llamaba Internet ...?
www.osnews.com/story/22486/A_2x_Faster_web_SPDY
Lo que me ha llegado al corazón es el comentario de:
Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers. On the lower-bandwidth DSL link, in which the upload link is only 375 Mbps, request header compression in particular, led to significant page load time improvements for certain sites (i.e. those that issued large number of resource requests). We found a reduction of 45 - 1142 ms in page load time simply due to header compression.
El punto l_ower-bandwith_ DSL link in which the upload is only 375 Mbps, es un error y son Kbps, pero entonces si 375 Kbps es lower-bandwith, ¿yo con los fantasticos 1Mb de bajada y 256 Kb de subida que tengo?
Quizás quiso decir: eyaculación precoz
Entiendo que lo que Google quiere es mejorar la experiencia de todos los usuarios, para atraer más usuarios a internet y aumentar sus ingresos, pero sin prácticas monopolísticas, sino de forma gratuita a los usuarios finales (ya ganan con la publicidad).
Es igual que la transición de IPv4 a IPv6... es algo que tarde ó temprano tiene que hacerse, pero el sistema actual está tan implantada, y tiene tantas raices puestas, que quitarlo puede hacer mucho daño.
Hala, ya lo están cambiando
meneame.net/story/ya-he-utilizado-ese-nombre-para-lenguaje-programacio
Encima la gente se pone paranoica cuando Google lanza un lenguaje (libre), un protocolo (libre), otro protocolo que lanzará en breve (VoIP, y sino, al tiempo), el Maps o el Street View... pero ahora, lo único que no liberan, lo único que de verdad les da un poder que a-co-jo-na, eso precisamente no emparanoia a nadie. Señores, que por lo que Google asusta no es por lanzar tecnologías, ideas, aplicaciones, protocolos o herramientas, es por la cantidad de datos tuyos y míos que tienen, y por la potencia de cálculo para jugar con ellos.
Claro que en este mundo en que la gente cede alegremente todos sus datos a facebook, tuenti y similares, ¿qué paranoia cabe esperar al respecto?
Mi comentario iba dirigido a que en Internet ya encuentras a Google hasta en la sopa.
¡MIC, MIC!
100% faster = x2
entonces,
55% faster ~= x3/2
#30 No me digas de lo que puedo o no puedo sorprenderme, gracias. Intentaba ser irónico, saludos.
Hacemos streaming de audio y video a través del navegador. Yo abro conexiones vpn a través del navegador. Usamos cookies y ñapas por el estilo para hacer de un protocolo stateless todo lo contrario. Y ya por último nos inventamos soap y los servicios web y metemos la comunicación de toda clase de aplicaciones a través de http. Todo pura inercia, por supuesto, pero muy dificil de vencer.
Y teniendo "Accept-Encoding" para comprimir el cuerpo de los mensajes, ahora alguien pretende redefinir por completo el estándar http para comprimir la cabecera. Já. Pues mucha suerte, chavales.
Al principio el protocolo por defecto sería http y convivirían durante mucho tiempo los dos pero al cabo de un tiempo si los servidores se animan a dar soporte al nuevo protocolo se podría cambiar el protocolo por defecto del navegador.
Por último para el tema de controlar el estado de la aplicación saldrían librerías multiprotocolo que te aislarían del protocolo y permitirían programar una vez para los dos protocolos.
Obviamente no es un cambio de hoy para mañana pero se pueden escalonar y compaginar los dos protocolos durante varios años hasta que el http caiga por su propia impopularidad como ha pasado con el eMule y el paso a Kademlia, por ejemplo.
innovación -> anuncia "su" lenguaje de programación Go
mejorar la experiencia en internet -> dejan caer un nuevo protocolo http...
Vale,en una semana ha dado un repaso a todos sus palos para dejarnos claro su mercado pero... empieza a dar un poco de miedo esto ya,no??