Cuál es la solicitud de datos http y https más pequeña posible

Question

Digamos que quiero OBTENER un byte de un servidor usando el protocolo http y quiero minimizar todo, no hay encabezados solo http://myserver.com/b donde b es un archivo de texto con un caracter en él , o mejor aún, b es solo un personaje (no estoy seguro si eso es posible). ¿Hay alguna manera de hacer esto con apache y cuál es la menor cantidad posible de datos necesarios para completar http y completar transacciones https? Alternativamente, la transacción podría realizarse con solo una solicitud principal si eso es más eficiente con los datos.

Answer 1

¿Qué es exactamente lo que estás tratando de lograr, es esto una especie de mantener vivo?

Podría hacer un "GET /", que implica que se utiliza HTTP/1.0, pero que lo bloquea de cosas como el alojamiento virtual, etc. Puede asignar "/" a un script cgi, no necesita ser un archivo real, dependiendo de lo que estés tratando de lograr. Puede configurar Apache para que solo devuelva el conjunto mínimo de encabezados, que básicamente sería "Content-Type: text/plain" (u otro tipo de mime más corto, posiblemente mimetype personalizado, por ejemplo, "Content-Type: a/b") y " Content-Length: 0 ", por lo que no devuelve un cuerpo de respuesta en absoluto.

Answer 2

Si planea usar HTTP/1.1 (más o menos lo requiere si termina en un host virtual), su solicitud GET necesitará tener el nombre de host, ya sea en el encabezado Host o como un URI absoluto en la línea de solicitud (ver RFC 2616 section 5.1.2).

Su respuesta también necesitará un Content-Length o transfer encoding headers and delimiters.

Si está dispuesto a "romper" HTTP mediante el uso de una solicitud HEAD, parece que HTTP podría no ser la mejor opción de protocolo. También es posible que pueda devolver algo en un encabezado personalizado, pero esa no es una forma limpia de hacerlo.

Tenga en cuenta que, incluso si implementa su propio protocolo, deberá implementar un mecanismo similar al Content-Length o proporcionar la codificación fragmentada, para poder determinar cuándo dejar de leer la parte remota (de lo contrario, no ganó) t ser capaz de detectar conexiones mal cerradas).

EDIT:

Aquí está un ejemplo rápido, esto puede variar dependiendo de su nombre de host (suponiendo HTTP 1.1). Supongo que podrías usar OPTIONS en su lugar. Depende de la cantidad que está dispuesto a romper HTTP ...

Solicitud:

GET/HTTP/1.1 
Host: www.example.com 

Eso es 14 + 2 + 21 + 2 + 2 = 41 bytes (2) para CRLF

Respuesta:

HTTP/1.1 200 OK 
Content-Length: 1 
Content-Type: text/plain 

a 

Eso es 15 + 2 + 17 + 2 + 24 + 2 + 2 + 1 = 65 bytes

Para HTTPS, habrá b e una pequeña sobrecarga para el canal SSL/TLS en sí, pero la mayor parte se tomará mediante el protocolo de enlace, en particular, el certificado del servidor (suponiendo que no esté utilizando la autenticación cliente-cert) debería ser el más grande. Verifique el tamaño (en formato DER) de su certificado.

Answer 3

Es una vieja pregunta, pero tal vez alguien la encontró útil, porque nadie ha respondido la parte HTTPS de la pregunta.

Para mí esto fue necesario para una fácil validación de la comunicación HTTPS en mi proxy, que conecta otros proxies imposibles de usar a través del túnel.

Este sitio explica con claridad: http://netsekure.org/2010/03/tls-overhead/

Citas de artículo:

Una cosa a tener en cuenta que influirá en el cálculo es la variable tamaño de la mayoría de los mensajes. La naturaleza variable no permitirá calcular un valor preciso, pero tomando algunos valores promedio razonables para los campos variables, uno puede obtener una buena aproximación de la sobrecarga. Ahora, repasemos cada uno de los mensajes y consideremos sus tamaños.

• ClientHello: el tamaño promedio del hello inicial del cliente es de aproximadamente 160 a 170 bytes. Varía según la cantidad de servidores de cifrado enviados por el cliente y la cantidad de extensiones de TLS ClientHello. Si se usa la reanudación de sesión, se deben agregar otros 32 bytes para el campo ID de sesión.
• ServerHello: este mensaje es un poco más estático que ClientHello, pero aún de tamaño variable debido a las extensiones TLS. El tamaño promedio es de 70 a 75 bytes. -Certificado: este mensaje es el que más varía en tamaño entre los diferentes servidores. El mensaje lleva el certificado del servidor, así como todos los certificados de emisor intermedios en la cadena de certificados (menos el certificado raíz). Dado que los tamaños de los certificados varían bastante según los parámetros y las claves utilizadas, utilizaría un promedio de 1500 bytes por certificado (los certificados autofirmados pueden ser tan pequeños como 800 bytes). El otro factor variable es la longitud de la cadena de certificados hasta el certificado raíz. Para estar en el lado más conservador de lo que hay en la web, supongamos que hay 4 certificados en la cadena. En general, esto nos da alrededor de 6k para este mensaje.
• ClientKeyExchange - supongamos nuevamente el caso más utilizado - el certificado de servidor RSA. Esto corresponde al tamaño de 130 bytes para este mensaje.
• ChangeCipherSpec - tamaño fijo de 1 (técnicamente no es un mensaje de negociación)
• Terminado - dependiendo de si se utiliza SSLv3 o TLS, el tamaño varía un bit - 36 y 12 bytes, respectivamente. La mayoría de las implementaciones de estos TLSv1.0 apoyo días por lo menos, así que vamos a suponer TLS será utilizada y, por tanto, el tamaño será de 12 bytes

Así que el mínimo puede ser tan grande (o pequeño) como:

20 + 28 + 170 + 75 + 800 + 130 + 2*1 + 2*12 ≈ 1249 

Aunque según el artículo, el promedio es aproximadamente 6449 bytes.

También es importante saber que las sesiones de TLS se pueden reanudar, por lo que solo la primera conexión tiene esta sobrecarga. Todos los demás mensajes tienen aproximadamente 330 bytes más.