{"id":52181,"date":"2019-11-02T00:00:00","date_gmt":"2019-11-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/http-3-razrushenie-osnov-i-divnyj-novyj-mir"},"modified":"2020-02-18T13:59:51","modified_gmt":"2020-02-18T10:59:51","slug":"http-3-razrushenie-osnov-i-divnyj-novyj-mir","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/http-3-razrushenie-osnov-i-divnyj-novyj-mir","title":{"rendered":"HTTP\/3: Destrucci\u00f3n de fundamentos y un mundo nuevo maravilloso","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Durante m\u00e1s de 20 a\u00f1os hemos estado navegando por p\u00e1ginas web a trav\u00e9s del protocolo HTTP. La mayor\u00eda de los usuarios ni siquiera se detiene a pensar en lo que es y c\u00f3mo funciona. Otros saben que debajo de HTTP est\u00e1 TLS, y debajo de este TCP, y luego IP, y as\u00ed sucesivamente. Y hay quienes, considerados herejes, creen que TCP es cosa del pasado y desean algo m\u00e1s r\u00e1pido, confiable y seguro. Pero en sus intentos de inventar un nuevo protocolo ideal, han regresado a las tecnolog\u00edas de los a\u00f1os 80, tratando de construir su maravilloso nuevo mundo sobre ellas.
\n\"HTTP\/3:
\n<\/a><\/noindex><\/p>\n

Un poco de historia: HTTP\/1.1<\/h2>\n

\nEn 1997, el protocolo de intercambio de informaci\u00f3n textual HTTP versi\u00f3n 1.1 obtuvo su RFC. En ese momento, el protocolo ya hab\u00eda sido utilizado por los navegadores durante varios a\u00f1os, y el nuevo est\u00e1ndar se mantuvo vigente durante otros quince. El protocolo funcionaba \u00fanicamente seg\u00fan el principio de solicitud-respuesta y estaba destinado, principalmente, a la transmisi\u00f3n de informaci\u00f3n textual.<\/p>\n

HTTP fue dise\u00f1ado para funcionar sobre el protocolo TCP, que garantiza la entrega confiable de paquetes al destinatario. El funcionamiento de TCP se basa en establecer y mantener una conexi\u00f3n confiable entre los puntos finales y en segmentar el tr\u00e1fico. Los segmentos tienen un n\u00famero de serie y un valor de comprobaci\u00f3n. Si alguno de los segmentos no llega o llega con un valor de comprobaci\u00f3n incorrecto, la transmisi\u00f3n se detiene hasta que se recupere el segmento perdido.<\/p>\n

En HTTP\/1.0, la conexi\u00f3n TCP se cerraba despu\u00e9s de cada solicitud. Esto era sumamente derrochador, ya que establecer una conexi\u00f3n TCP (3-Way-Handshake) no es un proceso r\u00e1pido. En HTTP\/1.1 se introdujo el mecanismo keep-alive, que permite reutilizar una conexi\u00f3n para varias solicitudes. Sin embargo, ya que esto puede convertirse f\u00e1cilmente en un cuello de botella, en diferentes implementaciones de HTTP\/1.1 se permite abrir varias conexiones TCP a un mismo host. Por ejemplo, en Chrome y en las \u00faltimas versiones de Firefox se permiten hasta seis conexiones.
\n\"HTTP\/3:
\nSe supon\u00eda que la cifrado tambi\u00e9n ser\u00eda delegado a otros protocolos, y para ello, sobre TCP se comenz\u00f3 a utilizar el protocolo TLS, que protege los datos de manera bastante confiable, pero tambi\u00e9n increment\u00f3 a\u00fan m\u00e1s el tiempo necesario para establecer una conexi\u00f3n. En consecuencia, el proceso de handshake se ve\u00eda as\u00ed:
\n \"HTTP\/3:
\nIlustraci\u00f3n de Cloudflare<\/i><\/p>\n

De este modo, HTTP\/1.1 ten\u00eda varios problemas:<\/p>\n