MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_01DA39B5.45AA3F60" Este documento es una página web de un solo archivo, también conocido como "archivo de almacenamiento web". Si está viendo este mensaje, su explorador o editor no admite archivos de almacenamiento web. Descargue un explorador que admita este tipo de archivos. ------=_NextPart_01DA39B5.45AA3F60 Content-Location: file:///C:/8CEA59D3/1063-RTE-35-3.htm Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
https://doi.org/10.37815/rte.v35n3.1063
Artículos originales
Comparación del rendimiento en la transferencia de tráfico en
servidores HTTP/2 y QUIC
Comparison of traffic transfer performance on HTTP/2 and QUIC server=
s
Jairo
Valle1 https://orcid.org/0009-0003-6808-0131, <=
/span>Rommel Torres=
1=
https://orcid.org/0000-0003-2313-01=
18, Liliana Enc=
iso1 https://orcid.org/0000-0002-2918-90=
33, Patricia L=
udeña1 https://orcid.org/0000-0002-8909-48=
37
1Uni=
versidad
Técnica Particular de Loja, Loja, Ecuador
jsvalle1@utpl.edu.ec, rovitor@utpl.edu.ec, lenciso@utpl.edu.ec, pjludena@utpl.edu.ec
Enviado: 2023/07/16
Aceptado: 2023/09/19
Publicado:
2023/12/30
Resumen
Desde el surgimiento de la World
Wide Web en los 90´s, el protocolo HTTP (Hypertext
Transfer Protocol) ha permitido el intercambio =
de
datos entre cliente y servidor, ante el constante incremento de las
comunicaciones de red donde la transferencia de datos es cada vez más rápid=
a,
segura y fiable; este protocolo ha ido evolucionando en diferentes versiones
hasta implementar al día de hoy la versión denominada QUIC (Quick UDP Inter=
net Connections).
En el presente trabajo se evaluó mediante el us=
o de
los servidores web dedicados OpenLiteSpeed y Nginx, así como el servidor comercial Hostinguer,
el rendimiento en la transferencia de tráfico normal y multimedia mediante =
el
protocolo HTTP en sus versiones HTTP/2 y QUIC.
Para esto se configuró un entorno web que
permitiera establecer la comunicación y transferencia de archivos bajo la
arquitectura cliente-servidor. En los servidores utilizados, se implementó =
una
página web desarrollada en WordPress que posee la capacidad de cargar archi=
vos
de diversos formatos hacia el servidor.
Finalmente se establecieron 4 escenarios de pru=
ebas
para comparar de forma práctica el proceso de comunicación y transferencia
entre cliente y servidor, apoyados de la herramienta Wireshark, la cual nos
permitió monitorear y gestionar el tráfico de red.
=
Palabras clav=
e: protocolo, transferencia, versiones, escenar=
ios,
tráfico, monitorear.
Sumario:=
span> Introducción,
Materiales y Métodos, Resultados y Discusión y Conclusiones. Como citar=
: Valle,
J., Torres, R., Enciso, L. & Ludeña, P. (2023). Comparación del
rendimiento en la transferencia de tráfico en servidores HTTP/2 y QUIC=
. Revista
Tecnológica - Espol, 35(3), 68-82. http://www.rte.espol.edu.ec/index.php/tecnologica/article/view/1=
063
Abstract
Since the emergence of the Wor= ld Wide Web in the 90s, The HTTP (Hypertext Transfer Protocol) has enabled data exchange between customers and servers. Considering the constant increase in network communications where data transfer is becoming faster, safer, and m= ore reliable, this protocol has evolved through different versions, culminating= in the current implementation known as QUIC (Quick UDP Internet Connections).<= o:p>
In this study, we evaluated through the use of the dedicated web servers Open LiteSpeed and Nginx, as w= ell as the commercial server Hostinguer, the performance in normal traffic tran= sfer and multimedia through the HTTP protocol in its versions: HTTP/2 and QUIC.<= o:p>
This was achieved by configuri=
ng a
web environment to establish communication and file transfer under the
customer-server architecture. On the employed servers, a web page developed=
in
WordPress was deployed, which possessed the capability to upload files of
various formats to the server.
Finally, four test scenarios w=
ere
established to compare, in a practical way, the communication and transfer
process between the customer and server. The monitoring and management of
network traffic were facilitated by the Wireshark tool.
Keywords: protocol, transfer, versions, scenarios,
traffic, monitor.
Introducción
El prot=
ocolo
HTTP (Hypertext Transfer P=
rotocol)
se usa en los navegadores y servidores desde 1991 y ha sido uno de los
protocolos de comunicación más utilizados en Internet
El prot=
ocolo
HTTP es considerado el protocolo más utilizado a nivel de la capa de
aplicación, siendo el protocolo fundamental para el acceso de los datos en
Internet
Desde la
aparición de la World Wide Web, desde 1991, el
protocolo HTTP en su primera versión denominada HTTP/0.9 permitía el
intercambio de datos por la web sin procesar su información, con la aparici=
ón
de HTTP/1.0 en 1996
TLS se =
define
como un protocolo orientado a la seguridad en la capa de transporte de mane=
ra
criptográfica, proporciona encriptación y autenticación de todas las partes=
en
la comunicación de la red. Publicado en 1999 por la RFC2246
QUIC (Q=
uick UDP
Internet Connections) es un protocolo que nace =
de la
necesidad de reducir la latencia que genera TCP al momento de establecer
conexión
QUIC es=
un
protocolo situado en la capa de transporte que funciona bajo el User Datagram Protocol (UDP), y
desarrollado por Google desde 2012, actualmente se encuentra en discusión p=
or
el equipo de desarrollo de Google y el Internet Engine=
ering
Task Force (IETF) p=
or lo
que se cuenta con 2 variaciones del mismo, QUIC de Google (GQUIC) y IETF QU=
IC
(IQUIC)
Las pri=
ncipales
diferencias entre QUIC y TCP se presentan en la Tabla 1.
Comparación entre
QUIC Y TCP
CRITERIO |
TCP |
QUIC |
Conexión |
Para
establecer conexión TCP utiliza un=
protocolo de enlace de 3
vías. |
Para
la conexión QUIC utiliza un paquete=
de inicio. |
Seguridad |
Utiliza TLS
que consiste en cifrado de
datos. |
Utiliza
encriptado y autenticación de extremo
a extremo. |
Paquetes |
TCP
se encarga de enviar y recibir paquetes del servidor. |
QUIC
sólo envía paquetes al servidor lo =
que
mejora la latencia. |
Para es=
tablecer
la conexión en QUIC el cliente primeramente usa un mensaje de un paquete pa=
ra
obtener información del servidor denominado como Hands=
hake
inicial y así completar el protocolo de enlace. El cliente envía un mensaje=
Inchoate CHLO al servidor, este es un Client Hello incompleto y el servidor le responde con un men=
saje Reject, el cual contiene el token de dirección de ori=
gen,
una firma digital, una clave privada y los certificados del servidor que va=
n a
ayudar al cliente a continuar con la comunicación con el cliente
Existen
diversos trabajos orientados a la comparación de las diferentes versiones d=
el
protocolo HTTP y QUIC entre los que podemos destacar:
“Análisis de velocidad de acceso a sitios web comparando protocolo TCP
tradicional con SSL vs protocolo QUIC” =
span>
El obje=
tivo de
la presente investigación se centra en analizar el rendimiento en la
transferencia de tráfico normal y multimedia mediante la implementación de
servidores que trabajen con los protocolos HTTP y QUIC con el fin de establ=
ecer
sus diferencias y particularidades mediante el establecimiento de diversos
escenarios de prueba.
El pres=
ente
trabajo está organizado de la siguiente manera:
En la s=
ección
de Materiales y Métodos se establece la arquitectura a utilizar, así como l=
as
herramientas de software y los servidores seleccionados, así como también l=
os
sitios web utilizados en cada servidor con sus respectivos dominios; luego =
se
procede a establecer diferentes escenarios de pruebas con sus característic=
as
principales.
La secc=
ión de
Resultados y Discusión se evidencia los resultados obtenidos en el desarrol=
lo
de cada escenario de prueba propuesto, y se genera el detalle y análisis en=
la
comparación de características relevantes encontradas en cada uno de ellos,=
así
como la inclusión de gráficas estadísticas que aportan a la discusión y
comparación de forma gráfica.
Finalmente, en la sección de conclusiones se
genera a partir del estudio y discusión de los resultados obtenidos, las
principales características encontradas en la comparación de los protocolos
HTTP y QUIC.
Materiales y Métodos
Una vez analizados los fundamentos = y características más relevantes de las versiones a través del tiempo sobre el protocolo HTTP= , se procede a la planeación para configurar un entorno web que permita establec= er 4 escenarios de prueba sobre 3 servidores web.
Figura = 1=
Arquit= ectura del entorno web
En la <=
/span>Figura 1, se muestra el entorno web establecido con la presenc=
ia de
2 host o clientes con capacidades de comunicación mediante protocolo HTTP/2=
y
QUIC, así mismo se establece un total de 3 servidores web; 2 servidores web
dedicados (OpenLiteSpeed y Nginx) =
y 1
servidor comercial (Hostinguer).
Finalmente, la presencia de un gestor de
tráfico (Wireshark) que se trata de una herramienta de captura de paquetes =
del
tráfico de red, con la finalidad de realizar un análisis y medición del uso=
de
los diferentes protocolos en la transferencia de archivos multimedia y de
texto.
Componentes de software
Los componentes de software a utilizar para la realización del entor=
no
web y comunicación cliente – servidor se describen a continuación en la Tabla 2, donde se identifica la herramienta a utilizar=
y
una breve descripción de la misma.
Tabla
2
Componentes a utili= zar para la generación del entorno web
Componente |
Descripción |
Digital Ocean |
Servicio de aloj=
amiento cloud privado, dónde se permite la creación de droplets, el cual permite configurar un servidor re=
moto
en un sistema operativo específico |
Droplet<=
/span> |
Consiste en una =
máquina
virtual que opera como un servidor virtual privado (VPS) y con capacidad =
de
ser multipropósito |
Namecheap |
Servicio de sele=
cción y
registro de dominios web a bajos costos, es el segundo registrador de
dominios más usado en el mundo, los usuarios pueden adquirir y vender sus
dominios, así como posee una gran facilidad en las configuraciones DNS (<=
span
class=3DSpellE>Domain Name <=
span
class=3DSpellE>System) del dominio |
Wordpress |
Es un sistema de=
gestión
de contenidos (CMS) enfocado en la creación y gestión de aplicaciones y
páginas web dinámicas |
Wireshark |
Herramienta sniffer o analizador de red de código abierto, el c=
ual
nos permite capturar los paquetes de datos del tráfico que se genera en u=
na
red para su análisis, posee una interfaz gráfica, generación de reportes y
aplicación de filtros que nos permite identificar protocolos, puertos,
direcciones ip y más |
Power Bi |
Es una herramien=
ta de
análisis de datos con la capacidad de filtrar y generar reportes gráficos
interactivos a través de los datos obtenidos |
Servidores
Para el
desarrollo del entorno web que permite la carga de archivos, monitoreo de la
transferencia cliente – servidor y posteriormente la comparación de resulta=
dos,
se opta por el uso y configuración de dos servidores dedicados y uno comerc=
ial,
los cuales tienen la capacidad de comunicación y transferencia mediante
protocolo HTTP/2 y QUIC.
Servidor OpenLite= Speed
Este se=
rvidor
web es la versión gratuita de LiteSpeed Technol=
ogies,
entre sus principales características se puede destacar su notable velocida=
d en
comparación al servidor web Apache, así como su alto rendimiento, estabilid=
ad y
eficiencia
Servidor Hostingu= er
Hosting=
er es un
proveedor de alojamiento y dominios web privado, entre sus características
podemos destacar que es una plataforma ágil y fácil de configurar en la
creación de un nuevo dominio y página web, por lo cual se obtiene un plan de
hosting y se configura el dominio www.pruebaquic2.online, luego de esto s=
e crea
un sitio web mediante la gestión de contenidos en Word=
press.
Servidor Nginx
El serv=
idor Nginx sale a la luz en 2004 y su creador es Igor Sysoev, utilizado por grandes sitios web como WordPre=
ss,
Hulu y MochiMedia, se caracteriza por su estabi=
lidad,
seguridad y su fácil configuración demostrando una gran eficiencia
<= o:p>
Interfaz de usuario
Una vez
realizada la configuración de cada uno de los servidores a utilizar, se rea=
liza
la instalación y configuración de WordPress, así como el diseño de una pági=
na
sencilla que posee un formulario para la carga de los archivos. Esta página=
se
replica en los 3 servidores para así poseer características similares en ca=
da
uno de los escenarios de prueba.
La inte= rfaz de nuestra página realizada en WordPress posee un formulario de rápido acceso = para realizar la operación de selección y carga de un archivo, proceso por el cu= al se da la capacidad al cliente de poder elegir un archivo almacenado en su equipo y hacer la carga de este hacia el servidor previamente configurado.<= o:p>
Como se ha mencionado, esta interfaz se encuentra disponible en los 3
servidores configurados mediante los siguientes dominios públicos detallado=
s en
la Tabla 3.
Tabla 3=
Ip públi= ca y dominio utilizado en cada servidor
SERVIDOR |
IP PÚBLICA |
DOMINIO |
OpenLiteSpeed |
159.223.128.63 |
pruebaquic.online |
Hostinguer |
89.117.139.207 |
pruebaquic2.online |
Nginx |
142.93.253.6 |
pruebaquic1.online |
Escenarios de prueba
Una vez
establecido el entorno web se plantean los escenarios de prueba para evalua=
r la
transferencia de tráfico normal y multimedia mediante los protocolos HTTP/2=
y
QUIC. Por tanto, se describen a continuación los escenarios a realizar.
Esce=
nario 1
En este
escenario se limita el ancho de banda de la red en 500Kbps, y se realiza en los servidores OpenLiteSpeed, Hostinguer=
y Nginx la carga de los archivos que se detallan
en la Tabla 4, primero
mediante el protocolo HTTP/2 y luego
mediante QUIC.
Tabla <=
/span>4=
Archivos a utilizar en Escenario = 1
TIPO DE ARCHIVO |
TAMAÑO (Kb) |
JPG |
3030322 |
MP4 |
3040771 |
TXT |
3031970 |
Esce=
nario 2
En este escenario se limita el ancho de banda de la red en
1000 Kbps, así como la
generación de latencia en la transferencia configurado en 10ms, se realiza =
en
los servidores OpenLiteSpeed,
Hostinguer y Nginx =
la carga
de los archivos que se detallan en la =
Tabla 5, primero mediante=
el protocolo HTTP/2 y luego mediante QUIC.
Archivos a utilizar en Escenario = 2
TIPO DE ARCHIVO |
TAMAÑO (Kb) |
JPG |
5025883 |
MP4 |
5038033 |
TXT |
5030716 |
Esce=
nario 3
En este escenario se limita el ancho de banda de la red en
4000 Kbps, así como la generación de latencia en la transferencia configurado en 15ms y por último la pérdida de paquetes en un 4%, se realiza e=
sta
prueba en los servidores OpenLiteSpeed y Hostinguer la <=
/span>carga
de los archivos que se detallan en la Tabla 6, prime=
ro
mediante el protocolo HTTP/2 y =
luego mediante
QUIC.
Tabla <=
/span>6=
Archivos a utilizar en Escenario = 3
TIPO DE ARCHIVO |
TAMAÑO (Kb) |
JPG |
8028577 |
MP4 |
8042005 |
TXT |
8025669 |
En este apartado se muestran los resultados
obtenidos a partir de los escenarios de prueba descritos anteriormente.
Resultado Escenario 1
En el escenario 1 con los parámetros establecid=
os
en la sección anterior, mediante la Tabla 7 se especifica el servidor utilizado, así como =
el
ancho de banda correspondiente a este escenario definido en 500Kbps, bajo q=
ue
protocolo se realiza la prueba, el tipo de archivo y el resultado de las
métricas de evaluación obtenidas desde la herramienta Wireshark en cada ses=
ión
de prueba.
Tabla 7=
Resultados
obtenidos Escenario 1
SERVIDOR |
ANCHO DE BANDA (kbps) |
PROTOCO LO |
ARCHI VO |
TAMAÑ O (Mb) |
RTT (ms) |
PAQUETES CAPTURADO S |
TIEMPO (s) |
PESO (Kb) |
OPEN LITE SPEED |
500 |
QUIC |
JPG |
3 |
0.0055 |
5385 |
82.01 |
4833 |
OPEN LITE SPEED |
500 |
QUIC |
MP4 |
3 |
0.0054 |
5510 |
74.27 |
4988 |
OPEN LITE SPEED |
500 |
QUIC |
TXT |
3 |
0.0041 |
5177 |
70.82 |
4640 |
HOSTINGUER |
500 |
QUIC |
JPG |
3 |
0.0005 |
5494 |
80.12 |
4873 |
HOSTINGUER |
500 |
QUIC |
MP4 |
3 |
0.0097 |
5716 |
74.97 |
5121 |
HOSTINGUER |
500 |
QUIC |
TXT |
3 |
0.0006 |
5458 |
79.55 |
4793 |
NGINX |
500 |
QUIC |
JPG |
3 |
0.0042 |
6152 |
83.56 |
4901 |
NGINX |
500 |
QUIC |
MP4 |
3 |
0.0025 |
6586 |
76.65 |
5255 |
NGINX |
500 |
QUIC |
TXT |
3 |
0.0036 |
6103 |
82.65 |
4896 |
OPEN LITE SPEED |
500 |
HTTP2 |
JPG |
3 |
0.06 |
4580 |
76.53 |
4324 |
OPEN LITE SPEED |
500 |
HTTP2 |
MP4 |
3 |
0.08 |
4848 |
71.10 |
4331 |
OPEN LITE SPEED |
500 |
HTTP2 |
TXT |
3 |
0.0793 |
4941 |
72.40 |
4444 |
HOSTINGUER |
500 |
HTTP2 |
JPG |
3 |
0.1066 |
5188 |
75.58 |
4428 |
HOSTINGUER |
500 |
HTTP2 |
MP4 |
3 |
0.1151 |
4961 |
81.08 |
4317 |
HOSTINGUER |
500 |
HTTP2 |
TXT |
3 |
0.1129 |
6677 |
101.02 |
6018 |
NGINX |
500 |
HTTP2 |
JPG |
3 |
0.0873 |
6808 |
91.80 |
5672 |
NGINX |
500 |
HTTP2 |
MP4 |
3 |
0.0849 |
6941 |
93.40 |
5731 |
NGINX |
500 |
HTTP2 |
TXT |
3 |
0.0798 |
6266 |
87.02 |
5107 |
En la Figura 2 se aprecia una comparación del tiempo total de
carga entre los protocolos HTTP/2 y QUIC, se puede concluir que, en un anch=
o de
banda de 500 Kbps, los servidores Hostinguer y =
Nginx bajo el protocolo QUIC obtuvo menor tiempo de c=
arga
en comparación a HTTP/2, en cambio en el servidor Open=
LiteSpeed
la diferencia entre los dos protocolos es mínima provocando que HTTP/2 obte=
nga
un menor tiempo de carga de 7 segundos menos que QUIC. Lo que nos indica qu=
e el
protocolo QUIC obtiene menor tiempo de carga en 2 de los 3 servidores puest=
os a
prueba.
Tiempo
total de carga según protocolos HTTP/2 y QUIC en Escenario 1<=
span
style=3D'mso-bookmark:_Toc38966068'>
Resultado Escenario 2
Los resultados obtenidos en el escenario 2 se
detallan en la Tabla 8, dónde se especifica el servidor utilizado, así
como el ancho de banda correspondiente a este escenario definido en 1 Mbps,
bajo que protocolo se realiza la prueba, el tipo de archivo y el resultado =
de
las métricas de evaluación obtenidas desde la herramienta Wireshark en cada
sesión de prueba.
Resultados
obtenidos Escenario 2
SERVIDOR |
ANCHO DE BANDA (Mbps) |
PROTOCOLO |
ARCHI VO |
TAMA ÑO (Mb) |
RTT (ms) |
PAQUETES CAPTURADO |
TIEMPO (s) |
PESO (kb) |
OPEN LITE
SPEED |
1 |
QUIC |
JPG |
5 |
0.0134 |
7656 |
74.41 |
6981 |
OPEN LITE
SPEED |
1 |
QUIC |
MP4 |
5 |
0.0001 |
7770 |
55.85 |
7083 |
OPEN LITE
SPEED |
1 |
QUIC |
TXT |
5 |
0.0003 |
8063 |
55.74 |
7394 |
HOSTINGUER |
1 |
QUIC |
JPG |
5 |
0.0001 |
7662 |
56.78 |
6938 |
HOSTINGUER |
1 |
QUIC |
MP4 |
5 |
0.0055 |
7777 |
64.28 |
7059 |
HOSTINGUER |
1 |
QUIC |
TXT |
5 |
0.0021 |
7876 |
57.77 |
7154 |
NGINX |
1 |
QUIC |
JPG |
5 |
0.0145 |
7675 |
78.62 |
6992 |
NGINX |
1 |
QUIC |
MP4 |
5 |
0.0042 |
7798 |
62.56 |
7156 |
NGINX |
1 |
QUIC |
TXT |
5 |
0.0005 |
7956 |
58.56 |
7056 |
OPEN LITE
SPEED |
1 |
HTTP2 |
JPG |
5 |
0.0916 |
6835 |
70.27 |
6286 |
OPEN LITE
SPEED |
1 |
HTTP2 |
MP4 |
5 |
0.0903 |
6998 |
53.95 |
6444 |
OPEN LITE
SPEED |
1 |
HTTP2 |
TXT |
5 |
0.0948 |
6947 |
54.90 |
6467 |
HOSTINGUER |
1 |
HTTP2 |
JPG |
5 |
0.1083 |
7327 |
55.12 |
6758 |
HOSTINGUER |
1 |
HTTP2 |
MP4 |
5 |
0.1074 |
7020 |
55.24 |
6491 |
HOSTINGUER |
1 |
HTTP2 |
TXT |
5 |
0.1028 |
7860 |
54.57 |
6927 |
NGINX |
1 |
HTTP2 |
JPG |
5 |
0.0828 |
8215 |
60.60 |
7228 |
NGINX |
1 |
HTTP2 |
MP4 |
5 |
0.0957 |
8053 |
61.82 |
7189 |
NGINX |
1 |
HTTP2 |
TXT |
5 |
0.0365 |
7841 |
61.12 |
7246 |
En la Figura 3, se muestra una comparación de tiempo y paquet=
es
capturados según el formato de archivo en cada uno de los servidores puesto=
s a
prueba, en donde podemos destacar que en el servidor O=
penLiteSpeed,
el número de paquetes capturados bajo el protocolo HTTP/2 es significativam=
ente
más bajo que QUIC y la transferencia se realiza en menor tiempo, es así que
podemos considerar que en este servidor tanto
HTTP/2 como QUIC la transferencia del archivo de formato JPG es quien
más tardó a diferencia de los demás archivos.
Figura 3=
Tiempo
total de transferencia según formato de archivo en Escenario 2
En el servidor Hostinguer<=
/span>
sucede lo mismo, el número de paquetes capturados es más bajo en el protoco=
lo
HTTP/2 que en el protocolo QUIC. En el servidor Nginx<=
/span>
el tiempo de transferencia es menor en HTTP/2 que en el protocolo QUIC, per=
o el
número de paquetes es mayor en el protocolo HTTP/2 que en el protocolo QUIC=
; lo
que nos indica que el protocolo HTTP/2 obtiene mejores resultados en un
ambiente donde el ancho de banda es de 1 Mbps, con una latencia de 10 m.s y con archivos de tamaño de 5Mb.
Resultado Escenario 3
Los resultados obtenidos en el escenario 3 se
detallan en la Tabla 9, dónde se especifica el servidor utilizado, así
como el ancho de banda correspondiente a este escenario definido en 4 Mbps,
bajo que protocolo se realizó la prueba, el tipo de archivo y el resultado =
de
las métricas de evaluación obtenidas desde la herramienta Wireshark en cada
sesión de prueba.
Tabla 9=
Resultados
obtenidos Escenario 3
SERVIDOR |
ANCHO DE BANDA (Mbps) |
PROTOCOLO |
ARCHI VO |
TAMA ÑO (Mb) |
RTT (ms) |
PAQUETES CAPTURADO S |
TIEMPO (s) |
PESO (kb) |
OPEN LITE
SPEED |
4 |
QUIC |
JPG |
5 |
0 |
10449 |
78.50 |
9273 |
OPEN LITE
SPEED |
4 |
QUIC |
MP4 |
5 |
0 |
10397 |
64.54 |
9278 |
OPEN LITE
SPEED |
4 |
QUIC |
TXT |
5 |
0 |
10339 |
60.21 |
9253 |
HOSTINGUER |
4 |
QUIC |
JPG |
5 |
0.0039 |
10638 |
79.34 |
9299 |
HOSTINGUER |
4 |
QUIC |
MP4 |
5 |
0 |
10675 |
79.05 |
9311 |
HOSTINGUER |
4 |
QUIC |
TXT |
5 |
0 |
10688 |
78.06 |
9338 |
OPEN LITE
SPEED |
4 |
HTTP2 |
JPG |
5 |
0.0016 |
9361 |
128.69 |
9130 |
OPEN LITE
SPEED |
4 |
HTTP2 |
MP4 |
5 |
0.0012 |
9409 |
114.25 |
9154 |
OPEN LITE
SPEED |
4 |
HTTP2 |
TXT |
5 |
0.0016 |
9254 |
89.62 |
9129 |
HOSTINGUER |
4 |
HTTP2 |
JPG |
5 |
0.0045 |
9162 |
128.50 |
9140 |
HOSTINGUER |
4 |
HTTP2 |
MP4 |
5 |
0.0665 |
10990 |
212.85 |
10 |
HOSTINGUER |
4 |
HTTP2 |
TXT |
5 |
0.0881 |
10958 |
228.78 |
10 |
En este escenario cabe destacar que se realizó =
una
serie de pruebas de carga a los servidores mediante
el protocolo HTTP/2
con diferentes porcentajes en la pérdida
de paquetes, al ser un escenario crítico con la
presencia de latencia, pérdida de paquetes y con un ancho de banda limitado a 4Mbps se pudo
evidenciar que no se completaba el proceso de transferencia con configuraciones superiores al 4%=
de
pérdida de paquetes. Es por esto que se realizó las pruebas con los 2 servidores que presentan
=
=
=
=
Tiempo total de transferencia según formato de archivo en Escenario 3
Como se puede apreciar en la Figura 4, en este escenario el protocolo QUIC obtiene m=
enor
tiempo total en la transferencia de archivos desde cliente hacia el servido=
r en
cada uno de los formatos utilizados, siendo más notoria la diferencia exist=
ente
en el formato de archivo TXT. El servidor OpenLiteSpee=
d
es quien obtiene los mejores tiempos de transferencia en comparación a Hostinguer lo cual podemos apreciar a mayor detalle e=
n la Figura 5.
Tiempo tot= al de transferencia según protocolo de cada servidor en Escenario 3=
Por último, se realiza una comparación respecto
al número de paquetes capturados y el peso total de la transferencia real=
izada
con cada uno de los formatos de archivo utilizados en este escenario.=
Ver Figura 6.
Figura 6=
Comparación de total de paquetes capturados y peso total según formato de archivo en Escenario 3
Q=
UIC
genera una mayor cantidad de paquetes con respecto a HTTP/2 y esto implica<=
span
style=3D'letter-spacing:.05pt'> que el peso total de transferencia será mayor,
se puede atribuir este resultado a que QUIC dado que su transmisión se basa en UDP genera
datagramas de menor longitud, por ende, será mayor el número de paquetes generados y m=
ás
peso ya que se debe tomar en cuenta los bytes extras que se generan de las cabeceras de cada datagrama.
El trab=
ajo
realizado para comparar el rendimiento en servidores web tiene la intención=
de poder evidenciar las diferencias
existentes en cuanto a la transferencia de tráfico normal y multimedia que se tiene presente en la navegación por Internet hoy en día. La
versión emergente del protocolo HTTP denominado QUIC
presenta, bajo los escenarios desarrollados en este trabajo, caract=
erísticas
importantes referente a su des=
empeño
como son:
En el e=
scenario
1 dónde se limita el ancho de banda a 500 Kbps, la sumatoria del tiempo tot=
al
de carga de todos los servidores utilizados bajo el protocolo HTTP/2 es de
749.97 segundos, mientras que mediante el protocolo QUIC es de 704.64 segun=
dos,
dando una diferencia de 45.33 segundos, lo que define al protocolo QUIC com=
o el
más óptimo en la transferencia de los archivos en estas condiciones de prue=
ba
dado que genera menos tiempo de transmisión.
En el e=
scenario
2 configurado con un ancho de banda de 1 Mbps y latencia de 10 m.s, el archivo con formato JPG mediante el protocolo=
de
transferencia QUIC presenta una diferencia considerable en relación a los o=
tros
2 formatos utilizados (TXT, MP4), dando un tiempo total excedente de 10
segundos, aun cuando generó 100 paquetes de captura menos que los otros
formatos, mientras que haciendo la
comparación frente al protocolo HTTP/2 se puede notar una diferencia de 40
segundos más de tiempo y un generación de 1295 paquetes capturados de
diferencia, se puede concluir que bajo estas condiciones de prueba el forma=
to
JPG en el protocolo QUIC demuestra que tiende a demorar de manera significa=
tiva
frente a los otros formatos y más aún frente al protocolo HTTP/2.
En el e=
scenario
3 donde se limita el ancho de banda a 4
Mbps, latencia de 15 m.s y pérdida de paquetes =
al 4%,
la sumatoria de los servidores bajo el protocolo QUIC obtuvo un tiempo tota=
l de
439.72 segundos, mientras que HTTP/2 obtuvo un tiempo total de 696.99 segun=
do,
generando una diferencia de 257.27 segundos, es así que podemos concluir qu=
e el
protocolo QUIC es más eficiente en la transferencia de archivos con entorno=
s de
red con un ancho de red limitado, con presencia de latencia y pérdida de
paquetes, ya que realiza la transferencia en un tiempo menor que HTTP/2
En un entorno de red dónd=
e se
simula pérdida de paquetes mayor a 6% y con latencia mayor a 15 m.s, podemos destacar que el protocolo HTTP/2 en los
diferentes servidores utilizados, obtuvo una capacidad de respuesta muy
deficiente, no completando la fase de subida de los archivos en 2 servidore=
s (Nginx y Hostinguer) y gen=
erando
un error en la transferencia, no obstante, al hacer uso del protocolo QUIC =
bajo
los mismos parámetros de simulación; generó una respuesta positiva al primer
intento en 2 servidores (OpenLiteSpeed y Hostinguer), completando de manera exitosa el proceso=
de
subida y transferencia de los archivos, por ende podemos concluir que el
protocolo QUIC responde de mejor manera a entornos de red limitados y críti=
cos
por la presencia de latencia y pérdida de paquetes.
Referencias
Albasrawi, S. T. (20=
20).
Performance analysis of Google’s Quick UDP Internet Connection Protocol und=
er
Software Simulator. Journal of Physics: Conference Series, 1591(1),
012026.
Bermeo-Pére=
z, S.
K., & Campoverde-Molina, M. A. (2020). Implementación de inteligencia de negocios, en el
inventario de la Cooperativa GranSol, con la
herramienta Power BI. Revista Científica FIP=
CAEC
(Fomento de La Investigación y Publicación Científico-Técnica
Multidisciplinaria). ISSN: 2588-090X. Polo de Capacitación, Investigación y
Publicación (POCAIP), 5(16), 240–266.
Bock, L. (2022). Learn Wireshark: A Defin=
itive
Guide to Expertly Analyzing Protocols and Troubleshooting Networks Using
Wireshark. Packt Publishing, Limi=
ted. https://books.google.com.ec/books=
?id=3DU_X9zgEACAAJ
Calle-González, J. L. (2020). Me=
todología
para creación de contenido accesible en WordPress para productores de conte=
nido.
Espinosa, S. (2019). Evaluación =
del uso
del protocolo QUIC en internet.
https://e=
-archivo.uc3m.es/handle/10016/29744
Fernández, F. M., Zverev, M., Garri=
do
Ortiz, P., Juárez Rodríguez, J. R., Bilbao Ugalde, J., & Agüero Calvo, =
R.
(2021). Evolución del Stack IoT: MQTT
Fielding, R=
.,
Gettys, J., Mogul, J., Frystyk, H., Masinter, L=
.,
Leach, P., & Berners-Lee, T. (1999). RFC2616: Hypertext Transfer Protoc=
ol –
HTTP/1.1. RFC Editor.
Henríquez, =
R. A.
(2017). Descripción=
del
protocolo HTTP y análisis de sus transferencias mediante metalenguajes.
Iglesias, C., & Guaman,
N. (2021). Análisis de velocidad de acceso a sitios web comparando proto=
colo
TCP tradicional con SSL vs protocolo QUIC.
Ke, P. F., =
Lau, Y.
M., & Hanley, D. V. (2023). Is Web3 Better Than Web2 for Investors?
Evidence from Domain Name Auctions.
Kyaw, N. N.=
(2019).
Analysis and simulation of hypertext transfer protocol at the application l=
ayer
of the internet. International Journal of Scientific and Research
Publications (IJSRP), 9(1), 10–29322.
Morocho Tro=
ya, E.
O. (2022). Desarrol=
lo de
los módulos e-learning y evaluaciones como componentes del entorno virtual =
de
aprendizaje integrado (EVAI) para la empresa IEREC.
Murthy, A. =
A.,
John, P. M., & Kasturi Nagappasetty, R. M. =
B.
(2023). Hypertext transfer protocol performance analysis in traditional and
software defined networks during Slowloris atta=
ck. International
Journal of Electrical & Computer Engineering (2088-8708), 13(4).
NetApplicat=
ions.com.
(2017). Market Share Statistics for Internet Technologies. https://n9.cl/1fjc5
Oliveira, A. T. de. (2020). Uma análise
experimental de desempenho do protocolo QUIC. https://repositorio.ufpe.br/handle/123456789/37646<=
span
lang=3DES-EC style=3D'font-size:10.0pt'>
Priego, L. (2018). Estudio del p=
rotocolo
TLS (Transport Layer
Security). http://hdl.handl=
e.net/10609/81045
Reese=
span>, W. (2008). Nginx: the high-performa=
nce
web server and reverse proxy. Linux Journal, 2008(173), 2.
Rescorla, E.
(2018). The Transport Layer Security (TLS) Protocol Version 1.3 (Issue 8446=
). RFC Editor. https://doi.org/=
10.17487/RFC8446
Rodríguez, R. (2020). Desarrollo=
de
nuevos modelos de interacción usuario-ecommerce:
integración de ecommerce en chatbot
vía API REST.
Romero, J. C. (2020). TLS 1.3. http://hd=
l.handle.net/10609/126747
Rueda, E. E. (2019). Cifrado con=
el
protocolo ssl/tls y=
el
rendimiento de sitios web. caso: empresa web-out,
2018–2019.
Sandra, H. =
(2022).
Performance Analysis of Openlitespeed and Apach=
e Web
Servers in Serving Client Requests. Knowbase: <=
i>International
Journal of Knowledge in Database, 2(2), 114–129. https://ejournal.iainbukittinggi.=
ac.id/index.php/ijokid/article/view/5306
Thomas, L.,=
Dubois,
E., Kuhn, N., & Lochin, E. (2019). Google Q=
UIC
performance over a public SATCOM access. International Journal of Satell=
ite
Communications and Networking, 37(6), 601–611.
Tomás, E. (=
2021). Estudio comparativo de
las versiones más <=
span
class=3DSpellE>recientes de HTTP. https://riunet.upv.es:443/handle/10251/172835
Vega, D. (2014). Estudio de pres=
taciones
del protocolo HTTP versión 2. =
https://e-archivo.uc3m.es/handle/10016/27301
5
Comparación del rendimiento en la transferenci=
a de
tráfico en servidores HTTP/2 y QUIC