Protocolo de Transferencia de Hipertexto
| Protocolo de Transferencia de Hipertexto | |
|---|---|
| |
| Familia: | Familia de protocolos de Internet |
| Campo de aplicación: | Transferencia de datos (hipertexto, etc.) en la capa de aplicación |
| Residencia en | TCP (transporte) |
| Introducción: | 1991 |
| versión actual: | 2 (2015) |
| Versión preliminar: | 3 |
| Defecto: |
RFC 1945 HTTP / 1.0 (1996) RFC 2616 HTTP / 1.1 (1999) |
El Protocolo de transferencia de hipertexto ( HTTP , inglés para protocolo de transmisión de hipertexto ) es un protocolo sin estado para la transmisión de datos en la capa de aplicación a través de una red informática . Se utiliza principalmente para cargar páginas web (documentos de hipertexto) desde la World Wide Web (WWW) en un navegador web . Sin embargo, en principio no se limita a esto y también es muy común como protocolo general de transferencia de archivos.
HTTP fue estandarizado por Internet Engineering Task Force (IETF) y el World Wide Web Consortium (W3C). La versión actual es HTTP / 2, que se publicó como RFC 7540 el 15 de mayo de 2015. El desarrollo posterior está organizado por el grupo de trabajo HTTP del IETF (HTTPbis). Existen estándares que complementan y se basan en HTTP, como HTTPS para cifrar el contenido transmitido o el protocolo de transmisión WebDAV .
propiedades
Según los modelos de capa establecidos para clasificar los protocolos de red según sus tareas más fundamentales o más abstractas, HTTP se asigna a la llamada capa de aplicación. Esto es abordado por los programas de aplicación , en el caso de HTTP, este suele ser un navegador web. En el modelo de capa ISO / OSI , la capa de aplicación corresponde a la séptima capa.
HTTP es un protocolo sin estado . Se pierde información de solicitudes anteriores. La transferencia confiable de datos de sesión solo se puede implementar en la capa de aplicación por medio de una sesión usando un identificador de sesión . Sin embargo, al usar cookies en la información del encabezado, se pueden implementar aplicaciones que pueden asignar información de estado (entradas de usuario, carritos de compras). Esto habilita aplicaciones que requieren propiedades de sesión o estado . La autenticación de usuario también es posible. Normalmente, la información que se transmite a través de HTTP se puede leer en todas las computadoras y enrutadores que pasan por la red . Sin embargo, la transmisión se puede cifrar a través de HTTPS .
Al expandir sus métodos de solicitud, información de encabezado y códigos de estado, HTTP no se limita al hipertexto , sino que se utiliza cada vez más para intercambiar cualquier dato. También es la base del protocolo WebDAV , que se especializa en la transferencia de archivos . Para la comunicación, HTTP es un protocolo de transporte confiable que depende, para el cual en casi todos los casos se utiliza TCP .
Actualmente existen dos versiones principales del protocolo, HTTP / 1.0 y HTTP / 1.1. Las versiones más recientes de los navegadores web cotidianos como Chromium , Chrome , Opera , Firefox , Edge e Internet Explorer también son compatibles con la versión 2 de HTTP (HTTP / 2) recién introducida.
construcción
Las unidades de comunicación en HTTP entre cliente y servidor se denominan noticias llamadas de las cuales existen dos formas diferentes: la solicitud ( Solicitud en inglés ) del cliente al servidor y la respuesta ( Respuesta en inglés ) en respuesta de servidor a cliente.
Cada mensaje consta de dos partes, el (Inglés encabezado del encabezado del mensaje , en definitiva cabecera llamada o cabecera HTTP) y el cuerpo del mensaje (Inglés cuerpo del mensaje , en suma cuerpo ). El encabezado del mensaje contiene información sobre el cuerpo del mensaje, como la codificación utilizada o el tipo de contenido, para que el destinatario pueda interpretarlo correctamente ( ver artículo principal: Lista de campos de encabezado HTTP ). El cuerpo del mensaje finalmente contiene los datos del usuario.
funcionalidad
Si el enlace a la URL http://www.example.net/infotext.html está activado en un navegador web , la solicitud se envía a la computadora con el nombre de host www.example.net para enviar el recurso /infotext.html espalda.
El nombre www.example.net se convierte primero en una dirección IP utilizando el protocolo DNS . Para la transmisión, se envía una solicitud HTTP GET a través de TCP al puerto estándar 80 del servidor HTTP.
Consulta:
GET /infotext.html HTTP/1.1
Host: www.example.net
Si el enlace contiene caracteres que no están permitidos en la solicitud, estos están codificados en% . Se puede transmitir información adicional, como información sobre el navegador, el idioma deseado, etc., a través del encabezado (encabezados) en cada comunicación HTTP. Con el campo "Host", se pueden diferenciar diferentes nombres DNS bajo la misma dirección IP. Es opcional en HTTP / 1.0, pero se requiere en HTTP / 1.1. Tan pronto como el encabezado termina con una línea en blanco (o dos finales de línea consecutivos), la computadora que opera un servidor web (en el puerto 80) envía una respuesta HTTP. Consiste en la información del encabezado del servidor, una línea en blanco y el contenido real del mensaje, es decir , el contenido del archivo infotext.html . Los archivos generalmente se transmiten en lenguajes de descripción de página como ( X ) HTML y todas sus adiciones, por ejemplo, imágenes, hojas de estilo ( CSS ), scripts ( JavaScript ), etc., que generalmente están vinculados entre sí por un navegador en una representación legible. En principio, cualquier archivo se puede transmitir en cualquier formato, por lo que el "archivo" también se puede generar dinámicamente y no necesita estar disponible en el servidor como un archivo físico (por ejemplo, cuando se utiliza CGI , SSI , JSP , PHP o ASP .NET ). Cada línea del encabezado termina con un salto de línea < CR > < LF >. La línea en blanco después del encabezado solo puede constar de <CR> <LF>, sin espacios cerrados .
Respuesta:
El servidor devuelve un mensaje de error y un código de error si la información no se puede enviar por algún motivo, pero los códigos de estado se utilizan incluso si la solicitud fue exitosa, en ese caso (la mayoría de las veces) 200 OK. La secuencia exacta de este proceso (solicitud y respuesta) se especifica en la especificación HTTP.
historia
A partir de 1989, Tim Berners-Lee y su equipo en el CERN , el centro europeo de investigación nuclear en Suiza, desarrollaron el Protocolo de transferencia de hipertexto, junto con los conceptos de URL y HTML , que sentaron las bases de la World Wide Web. Los primeros resultados de estos esfuerzos fueron la versión HTTP 0.9 en 1991.
HTTP / 1.0
La solicitud publicada en mayo de 1996 como RFC 1945 ( Solicitud de comentarios núm. 1945) se conoce como HTTP / 1.0. Con HTTP / 1.0, se establece una nueva conexión TCP antes de cada solicitud y, de forma predeterminada, el servidor vuelve a cerrarla después de que se haya transmitido la respuesta. Si, por ejemplo, se incrustan diez imágenes en un documento HTML, se requieren un total de once conexiones TCP para configurar la página en un navegador con capacidad para gráficos.
HTTP / 1.1
En 1999 se publicó un segundo requisito como RFC 2616 , que refleja el estándar HTTP / 1.1. Con HTTP / 1.1, un cliente puede usar una entrada de encabezado adicional ( keepalive ) para expresar el deseo de no terminar la conexión para poder usar la conexión nuevamente (conexión persistente). Sin embargo, el soporte en el lado del servidor es opcional y puede causar problemas junto con los proxies. La versión 1.1 permite que se envíen múltiples solicitudes y respuestas por conexión TCP mediante canalización HTTP . Solo se requiere una conexión TCP para el documento HTML con diez imágenes. Dado que la velocidad de las conexiones TCP es bastante baja al principio debido al uso del algoritmo de inicio lento , el tiempo de carga de toda la página se reduce significativamente. Además, las transmisiones que fueron abortadas con HTTP / 1.1 pueden continuar.
Una forma de usar HTTP / 1.1 en salas de chat es usar el tipo MIME multiparte / replace , en el que el navegador envía un código de límite , y un Content-Length -Headerfeldes reciente y un nuevo tipo de contenido -Headerfeldes el contenido de Rebuilds the ventana del navegador.
Con HTTP / 1.1 no solo es posible obtener datos, sino también transferirlos al servidor. Con la ayuda del método PUT , los diseñadores web pueden publicar sus páginas directamente a través del servidor web utilizando WebDAV, y el método DELETE les permite eliminar datos del servidor. Además, HTTP / 1.1 ofrece un método TRACE con el que se puede rastrear la ruta al servidor web y verificar si los datos se transfieren allí correctamente. Esto permite determinar la ruta al servidor web a través de los distintos proxies , un traceroute a nivel de la aplicación.
Debido a inconsistencias y ambigüedades, en 2007 se inició un grupo de trabajo para mejorar la especificación. El objetivo aquí era simplemente una formulación más clara, no se incorporaron nuevas funciones. Este proceso finalizó en 2014 y dio como resultado seis nuevos RFC:
- RFC 7230 - HTTP / 1.1: Sintaxis y enrutamiento de mensajes
- RFC 7231 - HTTP / 1.1: Semántica y contenido
- RFC 7232 - HTTP / 1.1: solicitudes condicionales
- RFC 7233 - HTTP / 1.1: Solicitudes de rango
- RFC 7234 - HTTP / 1.1: Almacenamiento en caché
- RFC 7235 - HTTP / 1.1: Autenticación
HTTP / 2
En mayo de 2015, el IETF adoptó HTTP / 2 como sucesor de HTTP / 1.1. El estándar está especificado por RFC 7540 y RFC 7541 . El desarrollo fue impulsado en gran medida por Google ( SPDY ) y Microsoft (HTTP Speed + Mobility) , cada uno con sus propias sugerencias. Un primer borrador, que se basó en gran medida en SPDY, se publicó en noviembre de 2012 y desde entonces se ha adaptado en varios pasos.
Con HTTP / 2, la transmisión debe acelerarse y optimizarse. Sin embargo, el nuevo estándar debería ser totalmente compatible con HTTP / 1.1.
Nuevas oportunidades importantes son
- la posibilidad de combinar varias consultas,
- más opciones de compresión de datos ,
- la transmisión codificada binaria de contenido y
- Transferencias de datos iniciadas por el servidor (procedimiento push),
- Se pueden priorizar los flujos individuales.
Una aceleración resulta principalmente de la nueva posibilidad de combinar ( multiplexar ) varias solicitudes para poder procesarlas a través de una conexión. La compresión de datos ahora también puede incluir datos de encabezado (utilizando un nuevo algoritmo especial llamado HPACK). El contenido se puede transmitir en código binario. Para no tener que esperar las solicitudes de seguimiento del cliente que se pueden prever en el lado del servidor, las transferencias de datos pueden ser iniciadas parcialmente por el servidor (procedimiento push). Al usar HTTP / 2, los operadores de sitios web pueden reducir la latencia entre el cliente y el servidor y aliviar el hardware de la red.
La opción planificada originalmente de que HTTP / 2 usa TLS de forma predeterminada no se implementó. Sin embargo, los fabricantes de navegadores Google y Mozilla anunciaron que sus navegadores web solo admitirán conexiones HTTP / 2 cifradas. Para esto, ALPN es una extensión de cifrado que requiere TLSv1.2 o más reciente.
HTTP / 2 es compatible con la mayoría de los navegadores, incluido Google Chrome (incluido Chrome en iOS y Android) desde la versión 41, Mozilla Firefox desde la versión 36, Internet Explorer 11 bajo Windows 10, Opera desde la versión 28 (y Opera Mobile desde la versión 24) y Safari desde la versión 8.
HTTP / 3
En noviembre de 2018, el IETF decidió que HTTP / 3 debería usar QUIC .
Google ha estado trabajando en una alternativa llamada QUIC desde 2012 . QUIC ya no se basa en el TCP orientado a la conexión , sino en el Protocolo de datagramas de usuario (UDP) sin conexión . Incluso con HTTP / 3 basado en él, los flujos de datos se procesan por separado. Si un paquete se pierde en ruta, ya no afecta a todos los flujos de datos, como es el caso de TCP. Con HTTP / 3, la secuencia afectada esperará hasta que llegue el paquete faltante. HTTP / 3 generalmente está encriptado y promete importantes ventajas de velocidad.
A mediados de 2019, Google Chrome Canary fue el primer navegador disponible que había integrado soporte experimental #QUIC y HTTP / 3. CURL pronto siguió su ejemplo . Las versiones preliminares de Firefox (nocturno y beta) han estado intentando usar HTTP / 3 automáticamente desde abril de 2021 si lo ofrece el servidor web (actualmente, por ejemplo, Google o Facebook ). Los servidores web pueden indicar soporte utilizando el encabezado de respuesta alt-svc o anunciando el soporte HTTP / 3 con un registro DNS HTTPS . Tanto el cliente como el servidor deben admitir la misma versión de borrador QUIC y HTTP / 3 para poder conectarse. Por ejemplo, Firefox actualmente admite los borradores 27 a 32 de la especificación, por lo que el servidor debe informar la compatibilidad con una de estas versiones (por ejemplo, "h3-32") en la entrada Alt-Svc o HTTPS para que Firefox intente QUIC y HTTP / 3. para usar con este servidor. Al visitar un sitio web de este tipo, la información de solicitud de red debe indicar que se está utilizando HTTP / 3.
Métodos de solicitud HTTP
- OBTENER
- es el método más común. Se utiliza para solicitar un recurso (por ejemplo, un archivo) del servidor especificando un URI . El contenido también se puede transferir al servidor como argumentos en el URI, pero de acuerdo con el estándar, una solicitud GET solo debe recuperar datos y no tener ningún efecto (como cambios de datos en el servidor o cierre de sesión). (ver más abajo )
- CORREO
- envía cantidades ilimitadas de datos al servidor para su posterior procesamiento, dependiendo de la configuración física del servidor utilizado; estos se transmiten como el contenido del mensaje y pueden, por ejemplo, consistir en pares de nombre-valor que provienen de un formulario HTML. De esta forma, se pueden crear nuevos recursos en el servidor o se pueden modificar los existentes. Los datos POST generalmente no se almacenan en caché . Además, con este tipo de transmisión, los datos también se pueden agregar al URI, como en el método GET. (ver más abajo )
- CABEZA
- indica al servidor que envíe los mismos encabezados HTTP que con GET, pero no el cuerpo del mensaje con el contenido real del documento. Por ejemplo, la validez de un archivo en la caché del navegador se puede verificar rápidamente .
- PONER
- se utiliza para cargar un recurso (por ejemplo, un archivo) a un servidor web especificando el URI de destino. Si un recurso ya existe bajo el URI de destino especificado, se reemplazará; de lo contrario, se creará.
- PARCHE
- Cambia un documento existente sin reemplazarlo completamente como con PUT. Fue especificado por RFC 5789 .
- ELIMINAR
- elimina el recurso especificado en el servidor.
- RASTRO
- devuelve la solicitud tal como la recibió el servidor. De esta forma se puede comprobar si la solicitud se ha modificado en el camino al servidor y cómo se ha modificado, lo que resulta útil para depurar conexiones.
- OPCIONES
- proporciona una lista de los métodos y funciones admitidos por el servidor.
- CONECTAR
- se implementa mediante servidores proxy que pueden proporcionar túneles SSL .
Los servicios web RESTful utilizan los diferentes métodos de solicitud para implementar servicios web . En particular, los métodos de solicitud HTTP GET, POST, PUT / PATCH y DELETE se utilizan para esto.
WebDAV agrega los métodos PROPFIND , PROPPATCH , MKCOL , COPY , MOVE , LOCK y UNLOCK a HTTP.
Transferencia de argumentos
A menudo, un usuario desea enviar información a un sitio web. En principio, HTTP ofrece dos opciones para esto:
- HTTP OBTENER
- Los datos forman parte de la URL y, por lo tanto, se conservan cuando el enlace se guarda o se transmite. Deben estar codificados en URL , es decir, los caracteres reservados deben representarse con "% < valor hexadecimal >" y los espacios con "+".
- POST HTTP
- Transmisión de los datos con un tipo de solicitud especialmente diseñado en el cuerpo del mensaje HTTP para que no sean visibles en la URL.
HTTP OBTENER
Aquí, los pares de parámetro-valor son introducidos por el carácter ?en la URL . Este procedimiento se elige a menudo para transmitir una lista de parámetros que la estación remota debe tener en cuenta al procesar una solicitud. Esta lista a menudo consta de pares de valores, que &están separados entre sí por el símbolo. Los respectivos pares de valores están estructurados en forma de nombre de parámetro = valor de parámetro . El carácter rara vez se usa ;para separar entradas en la lista.
Un ejemplo: en la página de inicio de Wikipedia, se ingresa "gatos" en el campo de búsqueda y se hace clic en el botón "Artículo". El navegador envía la siguiente solicitud o una similar al servidor:
GET /wiki/Spezial:Search?search=Katzen&go=Artikel HTTP/1.1
Host: de.wikipedia.org
…
Se transfieren dos pares de valores al servidor de Wikipedia:
| argumento | valor |
|---|---|
| buscar | Gatos |
| ir | elementos |
Estos pares de valores tienen la forma
Parameter1=Wert1&Parameter2=Wert2
con un prefijo ?adjunto a la página solicitada.
Esto le dice al servidor que el usuario quiere ver el artículo gatos . El servidor procesa la solicitud, pero no envía un archivo, sino que reenvía el navegador a la página correcta con un encabezado de ubicación , por ejemplo con:
HTTP/1.0 302 Found
Date: Fri, 13 Jan 2006 15:12:44 GMT
Location: http://de.wikipedia.org/wiki/Katzen
…
El navegador sigue esta instrucción y, basándose en la nueva información, envía una nueva solicitud, por ejemplo:
GET /wiki/Katzen HTTP/1.1
Host: de.wikipedia.org
…
Y el servidor responde y genera el artículo gatos , algo como:
HTTP/1.1 200 OK
Date: Fri, 13 Jan 2006 15:12:48 GMT
Last-Modified: Tue, 10 Jan 2006 11:18:20 GMT
Content-Language: de
Content-Type: text/html; charset=utf-8
Die Katzen (Felidae) sind eine Familie aus der Ordnung der Raubtiere (Carnivora)
innerhalb der Überfamilie der Katzenartigen (Feloidea).
…
La parte de datos suele ser más larga, aquí solo se debe considerar el registro.
La desventaja de este método es que los parámetros especificados con la URL generalmente se guardan en el historial del navegador y, por lo tanto, los datos personales se pueden guardar involuntariamente en el navegador. En su lugar, debe utilizar el método POST en este caso.
POST HTTP
Dado que los datos no están en la URL, se pueden transferir grandes cantidades de datos, como imágenes, a través de POST.
El siguiente ejemplo solicita el artículo gatos nuevamente , pero esta vez el navegador usa method="POST"una solicitud POST debido a un código HTML modificado ( ). Las variables no están en la URL, sino por separado en la parte del cuerpo, por ejemplo:
POST /wiki/Spezial:Search HTTP/1.1
Host: de.wikipedia.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 24
search=Katzen&go=Artikel
El servidor también entiende esto y responde con el siguiente texto, por ejemplo:
HTTP/1.1 302 Found
Date: Fri, 13 Jan 2006 15:32:43 GMT
Location: http://de.wikipedia.org/wiki/Katzen
…
Códigos de estado HTTP
Cada solicitud HTTP es respondida por el servidor con un código de estado HTTP. Por ejemplo, proporciona información sobre si la solicitud se ha procesado correctamente o, en caso de error, informa al cliente, es decir, al navegador, dónde (por ejemplo, redirección) o cómo (por ejemplo, con autenticación) ha recibido la información deseada (si es posible) puede obtener.
- 1xx - información
- El procesamiento de la solicitud aún está en curso a pesar de los comentarios. A veces, esta respuesta intermedia es necesaria porque después de un cierto período de tiempo ( tiempo de espera ) , muchos clientes asumen automáticamente que se ha producido un error en la transmisión o el procesamiento de la solicitud y terminan con un mensaje de error.
- 2xx - Operación exitosa
- La solicitud ha sido procesada y la respuesta se enviará de vuelta al solicitante.
- 3xx - redireccionar
- Para garantizar que la solicitud se procese correctamente, se requieren más pasos por parte del cliente. Este es el caso, por ejemplo, cuando el operador ha rediseñado un sitio web para que el archivo deseado se encuentre ahora en una ubicación diferente. Con la respuesta del servidor, el cliente puede averiguar dónde está ahora el archivo en el encabezado Ubicación .
- 4xx - Error del cliente
- Se produjo un error al procesar la solicitud de la que es responsable el cliente. Un 404 ocurre, por ejemplo, si se solicitó un documento que no existe en el servidor. Un 403 advierte al cliente que no se le permite acceder al documento respectivo. Por ejemplo, puede ser un documento confidencial o un documento al que solo se puede acceder a través de HTTPS .
- 5xx - Error del servidor
- Se ha producido un error cuya causa reside en el servidor. Por ejemplo, 501 significa que el servidor no tiene las funciones necesarias (es decir, programas u otros archivos, por ejemplo) para procesar la solicitud.
Además del código de estado, la cabecera de la respuesta del servidor contiene una descripción del error en la llanura Inglés . Por ejemplo, el siguiente encabezado puede reconocer un error 404 :
HTTP/1.1 404 Not Found
…
Autenticación HTTP
Si el servidor web determina que se requiere un nombre de usuario o contraseña para un archivo solicitado, lo informa al navegador con el código de estado 401 No autorizado y el encabezado WWW-Authenticate . Esto verifica si la información está disponible o presenta al usuario un diálogo en el que debe ingresar el nombre y la contraseña y los transmite al servidor. Si los datos son correctos, se envía la página correspondiente al navegador. Según RFC 2617, se hace una distinción entre:
- Autenticación básica
- La autenticación básica es el tipo más común de autenticación HTTP. El servidor web solicita autenticación, el navegador busca el nombre de usuario / contraseña para este archivo y pregunta al usuario si es necesario. Luego envía la autenticación con el encabezado de autorización en forma de nombre de usuario: contraseña codificada en Base64 al servidor. Base64 no ofrece ninguna protección criptográfica, por lo que este método solo puede considerarse seguro cuando se usa HTTPS .
- Autenticación de acceso implícito
- Con la autenticación de acceso implícita, el servidor también envía una cadena de caracteres aleatorios generada especialmente ( nonce ) con el encabezado WWW-Authenticate . El navegador calcula el código hash de todos los datos (nombre de usuario, contraseña, cadena de caracteres recibida, método HTTP y URI solicitado ) y lo envía de vuelta al servidor en el encabezado de autorización junto con el nombre de usuario y la cadena de caracteres aleatorios, que luego lo envía de vuelta al servidor con las comparaciones de suma de comprobación autocalculadas. Escuchar la comunicación no es de utilidad para un atacante aquí, ya que los datos no se pueden reconstruir a partir del código hash debido a la función hash criptológica utilizada y es diferente para cada solicitud.
Compresión HTTP
Para reducir la cantidad de datos transferidos, un servidor HTTP puede comprimir sus respuestas . Al realizar una solicitud, un cliente debe indicar qué método de compresión puede procesar. El encabezado Accept-Encoding se utiliza para esto ( por ejemplo, Accept-Encoding: gzip , deflate ). A continuación, el servidor puede comprimir la respuesta utilizando un método admitido por el cliente y especifica el método de compresión utilizado en el encabezado Content-Encoding .
La compresión HTTP ahorra cantidades considerables de datos, especialmente con datos textuales (HTML, XHTML, CSS, código Javascript, XML, JSON), ya que estos se pueden comprimir fácilmente. En el caso de datos que ya han sido comprimidos (por ejemplo, formatos comunes para imágenes, audio y video), la (re) compresión es inútil y, por lo tanto, generalmente no se usa.
Sin embargo, junto con una comunicación con cifrado TLS , la compresión conduce a BREACH - Exploit , por lo que es posible cifrar roto.
Aplicaciones a través de HTTP
HTTP como protocolo basado en texto no solo se utiliza para la transmisión de sitios web, también se puede utilizar en aplicaciones independientes, los servicios web . Los comandos HTTP como GET y POST se utilizan para operaciones CRUD . Esto tiene la ventaja de que no es necesario desarrollar un protocolo separado para la transmisión de datos . Esto se usa como ejemplo en REST .
HTTP en comparación con el protocolo QUIC
HTTP se basa en el Protocolo de control de transmisión (TCP). TCP confirma la recepción de cada paquete de datos. Esto significa que, en caso de pérdida de un paquete, todos los demás paquetes deben esperar la retransmisión del perdido si el caché del destinatario se desborda ( bloqueo de cabecera de línea ).
El protocolo QUIC en su totalidad está destinado a permitir un envío más rápido de paquetes de datos a través del protocolo UDP sin conexión . Las funciones de las que carece el protocolo UDP, como los acuses de recibo, deben ser proporcionadas por el protocolo de nivel superior. QUIC regula el control de la conexión en sí mismo. En el caso de una conexión de datos, el remitente y el receptor solo intercambian el certificado y la clave durante el primer protocolo de enlace, lo que reduce la latencia. Para otros procesos de transmisión, QUIC “recuerda” la conexión que se estableció en el pasado y accede a los datos almacenados. TLS versión 1.3 se utiliza actualmente como protocolo de cifrado . El protocolo QUIC también ofrece la opción de multiplexación . Se pueden transmitir varios flujos de datos simultáneamente a través de una conexión cliente-servidor, lo que reduce significativamente el tiempo de carga.
Ver también
- Ciclo de solicitud
- JABÓN
- Lenguaje de marcado extensible (XML)
- Codificación de caracteres
- Negociación de contenido
- HTTP ETag
- Almacenamiento en caché HTTP
enlaces web
- Grupo de trabajo del IETF para un mayor desarrollo de HTTP
- HttpTea , un analizador HTTP (software gratuito, inglés)
- Catálogo de enlaces sobre el tema de HTTP en curlie.org (anteriormente DMOZ )
- Informe detallado de Microsoft sobre http 2.0 (inglés)
Evidencia individual
- ^ Tim Berners-Lee: El HTTP original como se definió en 1991 . En: w3.org , consultado el 13 de noviembre de 2010.
- ↑ Protocolo de transferencia de hipertexto RFC 2616 - HTTP / 1.1
- ↑ RFC para HTTP / 2 definidas y escritas . iX , noticia del 15 de mayo de 2015 14:23 h.
- ↑ Christian Kirsch: Microsoft tiene su propia propuesta para HTTP 2.heise.de, 29 de marzo de 2012, consultado el 4 de abril de 2012 .
- ↑ Christian Kirsch: Se supone que SPDY de Google acelera la web . heise.de, 13 de noviembre de 2009; Consultado el 4 de abril de 2012.
- ↑ Borrador de la especificación de HPACK (el algoritmo de compresión de encabezados para HTTP / 2). Grupo de trabajo HTTP IETF
- ↑ HTTP / 2: navegue más rápido con la nueva versión del protocolo. pcwelt.de, 30 de enero de 2016, consultado el 21 de febrero de 2018 .
- ↑ M. Belshe, R. Peon, M. Thomson: Protocolo de transferencia de hipertexto versión 2, Uso de funciones TLS. Consultado el 10 de febrero de 2015 .
- ↑ Firefox 36 implementa HTTP / 2
- ↑ IETF: HTTP sobre Quic se convierte en HTTP / 3. 12 de noviembre de 2018, consultado el 27 de abril de 2019 .
- ↑ Kim Rixecker: HTTP / 3: explicamos la próxima versión del Protocolo de transferencia de hipertexto. En: revista t3n. 13 de agosto de 2021, consultado el 19 de agosto de 2021 .
- ↑ Tonino Jankov: ¿Qué es HTTP / 3? - Información general sobre el nuevo protocolo rápido basado en UDP. En: Kinsta. 18 de mayo de 2021, consultado el 19 de agosto de 2021 .
- ↑ Apéndice B: Notas de rendimiento, implementación y diseño . En: Consorcio World Wide Web [W3C] (Ed.): Especificación HTML 4.01 . 24 de diciembre de 1999, B.2.2: Ampersands en valores de atributo URI ( w3.org ).
- ↑ ¿Qué es HTTP? Consultado el 25 de marzo de 2021 .
- ↑ QUIC: Esto está detrás del protocolo experimental de Google. Consultado el 25 de marzo de 2021 .