Una gran reducción de la norma para las conexiones HTTP

Toda esta propuesta me parece interesante porque yo realmente creo que disminuiría la carga sobre los servidores de una gran cantidad, así como acelerar el tiempo que se tardaría para cargar las páginas en los clientes finales. La mayoría de la carga en el servidor es ozzu conexiones HTTP.

Creo que normalmente en el pasado la mayoría de los navegadores han establecido el valor por defecto para un máximo de dos conexiones simultáneas (HTTP mantener vivas las conexiones-o las conexiones persistentes) por RFC2616. Esto es realmente una buena cosa para los servidores, ya que ayuda a extender la carga:



http://www.w3.org/Protocols/rfc2616/rfc ... l#sec8.1.4

Sin embargo, creo que he escuchado con FF3 se aumentó a 6, que tendría que comprobar si están haciendo esto y si de hecho no lo son a raíz de la recomendación RFC2616 (o en caso de que la recomendación ha cambiado recientemente). Por lo tanto, si una página web que se visita había 1000 objetos de carga (de CSS, imágenes, javascript, etc), podría tomar algún tiempo dependiendo de la carga del servidor y los clientes y equipo de procesamiento de la velocidad de transferencia, y si algo no se almacena en caché.

Lo primero que pensé al ver este hilo es cómo este es similar a cómo los programadores de juego de todo el paquete en unos archivos. Por ejemplo, un juego que han jugado de Westwood (ahora EA) paquetes de seguridad de todos los contenidos del juego en archivos llamados. Mezclar archivos. Permite a su carga un archivo frente a miles de archivos por separado. De alguna manera este tipo de concepto de la misma, excepto que aquí sería la reducción de las conexiones HTTP y también encontrar la manera de sacar el mayor provecho de la RFC2616 recomienda conexión persistente límite. Por la forma en caso que estaba interesado en cambiar este límite con el IE (no está seguro de cómo hacerlo con FF), hice un hilo hace mucho tiempo sobre la forma de hacerlo:

html "> mswindows-forum/increase-browser-default-persistant-connection-t490.html

Por las RFC aunque probablemente no debería hacerlo por el respeto de las personas que ejecutan los servidores. Lo he probado en el pasado y han notado un gran aumento en la velocidad de carga de páginas web. Esa es una razón por la cual creo que Joeberts propuesta realmente podría mejorar los tiempos de carga en los clientes finales para los sitios web, así como la disminución de la carga en el servidor final. Si algo como esto era posible, lo más probable es que su ejecución.

* suspiro *...Echo de menos los días de Command & Conquer.

Spork Lo siento, yo estaba tratando de señalar que este sería un problema si se aplicara la forma en que por primera vez. Estaban en la misma página ahora.



Ahora bien, si era capaz de ponerse en práctica con el nombre de archivo zip en primer lugar, y el recurso después de que el hash, que tendría que estar en desacuerdo con que sea hacker. De los navegadores ya utiliza el hash para referirse a lugares específicos, o de los recursos, dentro de una página web, de modo que un hash que apunta a un nombre de archivo en un archivo zip que parece natural.
Sin embargo, como la única manera de poner en práctica sin romper las páginas en los navegadores que no soportan que sea para colocar el nombre del archivo después de el hash, sería contra-intuitivo de utilizar el hash.

Realmente me estoy inclinando hacia el elemento propuesto <link> para un archivo, sin embargo no estoy de acuerdo con el uso de un formato de archivo, según cómo de fácil acceso y fácil transición a los formatos existentes zip/gz/bz2 sería.
Creo que el tipo mime debe seguir siendo application / x-gzip | application / zip | etc, siendo la extensión zip | gz | bz2 | etc, y un atributo rel sería la única cosa que decirle al navegador qué hacer con el archivo.






Ive leer un par de cosas sobre los años que realmente animar a la gente para aumentar el número de conexiones a través de Firefoxes sobre & #058; de configuración o lo que sea.

Im seguro de que el defecto en Opera es de ocho conexiones.

Quiero esto sería tan...sería realmente asombroso! ¿O es así? jajaja

Estoy totalmente de acuerdo en que los estándares de compresión existentes debe ser apoyada. Supongo que era más o menos usando. ANR como una especie de idea abstracta para representar cualquier tipo de formato de archivo comprimido.

suena interesante. si es que existe entonces es que existen en todos los navegadores IE, pero desde el primer día y aparecen en el IE unos 10 años de retraso cuando se lo sustituye por algo nuevo...

Sin embargo, con las imágenes que ya utilizo una imagen con varias áreas sobre el mismo, y que han pasado por píxeles para reducir las peticiones http - similar a la del ratón común-técnica sobre el cambio de imagen

Ya veo.




Bueno, la cosa que me pasa con esto en primer lugar, es que Im que trabaja actualmente en la renovación de un foro temático y la forma en su configuración actual, ya sea que tienen que reescribir algunas partes de la solicitud de apoyo a los sprites CSS, vivir con numerosas HTTP conexiones, o deshacerse de unos ojos dulces.

Básicamente, todas las opciones de mi chupar por el momento.

Im pensando que con un <link> elemento y un paquete, la estructura de directorios del archivo comprimido que necesita coincidir con la que se encuentra en los elementos de uso de los recursos.

Esto sería fácil de hacer en la mayoría de los casos, creo. Dado que la estructura del directorio ya existe en el servidor, sólo tendría que ser envasados en el DocumentRoot del sitio y el paquete tendría que ser cargadas desde el DocumentRoot.

Im no está seguro de si una norma debe exigir a los paquetes de estar en el DocumentRoot sin embargo. Y si se les permite paquetes a ser cargados desde cualquier ubicación en el servidor, por ejemplo,



Si el navegador para buscar los elementos de ese paquete asumiendo el paquete empieza en DocumentRoot, o de que los caminos de ser relativa al lugar donde se carga el paquete.

Por ejemplo, si el paquete anterior se ha cargado y contenía "botones / / botón. png ", si la ruta de acceso a disposición de los nuevos elementos en la página de ser" botones / / button.png "O" / recursos / botones / button.png "?

Supongo que los theres de la opción de añadir soporte para un elemento <meta> para decidir esta trabajando en una forma similar a un elemento <base>. Tal vez podría llamarse "ANR-base".

En mi opinión, la ruta especificada en un elemento en particular debe ser el camino directo al elemento dentro del archivo, así:



sería establecer la ubicación del archivo en sí, y todas las referencias a los archivos dentro de ese archivo debe ser relativo, con la raíz de los archivos de calidad de la raíz del recurso en sí mismo:

Si bien la propuesta es interesante y podría ser el comienzo de la solución del problema que presente, no me parece que el problema que se presenta es en realidad un problema de actualidad, o se convertirá en uno en el futuro. Permítanme explicar.

En primer lugar, usted está diciendo que está interesado en la reducción de las conexiones, no pide. Suponiendo que está utilizando un servidor de mantenimiento de conexión y el navegador es compatible con él, cientos de archivos puede ser servido dentro de una sola conexión a través de solicitudes por separado.

Si está recibiendo en la reducción de las solicitudes, entonces, evidentemente, el archivo de recursos en un único archivo o de otra manera el envío de una respuesta de varias partes (como en archivos adjuntos de correo electrónico) sería una manera de hacerlo. Una vez más, sin embargo, yo realmente no ve ningún problema con la forma en su momento hacer, siempre que el servidor está configurado correctamente, lo que me lleva al siguiente paso...

Manipulación de una solicitud HTTP para una de recursos debe ser de bajo costo, siempre que la conexión de ancho de banda adecuado y el archivo no es grande. Un pequeño servidor puede determinar el archivo solicitado, determinar el mejor método para servir, y servir, dentro de unos pocos milisegundos y sin utilizar mucha memoria. Incluso en el caso de miles de peticiones simultáneas de miles de archivos única, un sistema que disponga de los aparatos de la caché de archivos en la memoria y no incurren en pena de rendimiento en la lectura de archivos desde el disco.



Aquí es donde las cosas se problemático. En lugar de servir a las solicitudes mediante un servidor configurado correctamente para servir archivos estáticos, que está usando un servidor configurado como una talla única para todos la solución que pueda cargar con varios mods para la autorización, el almacenamiento en caché, SSL, y PHP. Debido a la arquitectura de Apache, los mods incurrir en un golpe de memoria incluso cuando no se utilizan (de modo que cada mensaje ha de Apache de PHP capacidades, incluso para las solicitudes de recursos estática).

La solución a este problema es simplemente utilizar varias instancias del mismo servidor (Apache, por ejemplo), configurado para manejar diferentes tipos de archivos. Im no como mucho de un tipo de Apache como lighttpd Soy un chico, sin embargo, por lo que no puedo decirte cómo hacerlo (aunque no sé DreamHost). Alternativamente, puede usar Apache para seguir atendiendo las solicitudes dinámico, ya que actualmente hace, y luego usar una ligera luz lighttpd servidor configurado para servir archivos estáticos.

Photoshop es excesiva para el tamaño de imágenes JPG. Apache configurado para el contenido dinámico es excesiva para el servicio de archivos CSS 3KB.

----

Sólo por diversión: Suponiendo que hemos implementado algún tipo de archivo de la arquitectura dentro de los envases de HTTP, lo que ocurre con la memoria caché cuando un solo archivo de un paquete de 100 cambios? Si bien puede reducir el número total de peticiones HTTP, puede muy bien aumentar la cantidad de ancho de banda que sirve a menos que el servidor puede servir selectivamente los archivos de un paquete (esencialmente su servidor web tendrá que hacer la compilación de todos los archivos cuando la solicitud viene a través). Creo que una mejor solución sería sencilla para permitir a varias de las peticiones HTTP y respuestas similares a la forma e-mails son manipulados.

Mala elección de las palabras de mi parte. Tenía la intención de conexiones que se incluya a todas las partes de las conexiones y de las solicitudes que se están realizando.

Cualquier forma de decirlo, la situación sigue siendo análoga a la de una docena de viajes a la tienda de comestibles para una sola caja de recolección de huevos.
Mantenimiento de conexiones si se utiliza o no es como si usted siga conduciendo el mismo coche o en obtener un auto nuevo cada viaje.



¿Cuántos octetos usted contar se utilizan en una petición HTTP / respuesta para las cabeceras?
¿Sabías que Google utiliza un CSS Sprite para su página de resultados de logotipo y los botones / etc?
¿Sabía usted que recientemente Slashdot, un sitio con el nombre de un término que para la adopción de los sitios con tráfico, comenzó a utilizar CSS Sprites para reducir su carga?



Theres una gran cantidad de servidores por ahí haciendo exactamente de lo que he reunido durante la lectura de todo.



Lo mismo que ocurre cuando el CSS Sprite Google utiliza cambios. El expediente se sustituye.
Si los cambios son a menudo suficiente para incrementar el uso de los recursos, su probablemente una buena idea de repensar qué archivos se encuentran en los paquetes.

No nitpick, pero se trata de algo barato aquí. Conducción a la tienda varias veces consume una gran cantidad de recursos en comparación con el resultado. Las cabeceras HTTP consumen ancho de banda de algunos, sí, pero normalmente su insignificannot en comparación con el contenido que se transfiere. Todavía no podemos manejar a la gente para eliminar los espacios en blanco extras que las cuentas de varios de sus kilobytes HTML, CSS, JavaScript y archivos que van en un entorno de producción, por no hablar de eliminar fundamentalmente inútil servidor de etiquetas de identificación que tienden a chupar hasta varios cientos de octetos .

Apenas creo que deberíamos poner en marcha nuevos protocolo HTTP para Google y Slashdot, personalmente. Google, por su parte, podría simplemente utilizar su Google Gears (Slashdot también podría, de hecho) para almacenar los archivos en la máquina de los usuarios y actualizar sólo cuando necesitan ser actualizados.



Estoy de acuerdo, y creo que su ridículo, especialmente cuando las cuestiones (como en Ozzu). Una vez más, sin embargo, no creo que la solución es crear nuevos métodos para resolver el momento de una forma mucho más semántica existe. Para reciclar su metáfora, estos sitios están utilizando una gran camioneta para ir por los huevos en lugar de tomar una scooter o una bicicleta.

Usted no ha mencionado varias partes peticiones o respuestas. ¿Cuáles son sus pensamientos en un sistema como ese?

effim plantea un argumento interesante. Sin embargo, la propuesta técnica que requieren los cambios realizados en el lado del cliente - y el paquete de recursos que se reunieron en una petición HTTP no es más que un archivo normal.
por ejemplo:
index.html
files.zip

files.zip contiene las imágenes y hojas de estilo (siempre que no se produce dinámicamente).
Y tal vez podría ser dinámica archivos desde el archivo externo - de modo que el servidor no es nuevo edificio para todas las solicitudes.

Creo que la especificación HTTP actual podría apoyar una respuesta multiparte se citan como yo...Im cavar para ver lo que puedo encontrar...

http://www.w3.org/Protocols/rfc2616/rfc ... l#sec3.7.2

y

http://www.motobit.com/tips/detpg_multi ... e-request/

Actualizar

Appare notly es sólidamente apoyado, mediante un multiparte / Mimetype relacionados en la respuesta HTTP. Lamentablemente, el RFC para el cliente pide de manera explícita en "Permitir" multiparte una respuesta en las cabeceras. Quiero darle una oportunidad un poco más tarde y ver lo que puedo llegar a.

En la actualidad, el servidor Ozzu está haciendo bien, pero yo estaba justo señalar que la mayoría de la carga está viniendo de. Estoy de acuerdo con tu punto sobre el uso de diferentes configuraciones para estático vs contenido dinámico, etc Finalmente, en el camino si es lo suficientemente grande como ozzu allí sería probablemente el servidor de contenido estático, un servidor para contenido dinámico como los guiones, y un servidor SQL para todos la base de datos cosas. Por el momento, aunque todo eso no es necesario ya que trato de optimizar todo lo que pueda y el servidor es aún capaz de manejar la carga. Yo lo clasifican como una talla única para todos en este momento.



Creo que la mayoría de las personas no lo hacen porque simplemente no conocen nada mejor. Yo uso esta:

http://developer.yahoo.com/yui/compressor/

para comprimir todos los de la CSS y Javascript en el sitio. Si mal no recuerdo que es el ahorro de unos 40KB por usuario que visita el sitio. Si su sitio web no recibe mucho tráfico es probable que no necesita preocuparse por la nitty arenoso detalles así, pero una vez que los visitantes reciben suficiente cada cosa pequeña suma.

30000 visitantes 40KB = x 1,2 GB por día guardado