> For the complete documentation index, see [llms.txt](https://http3-explained.haxx.se/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://http3-explained.haxx.se/es/criticism.md).

# Críticas habituales

## UDP nunca funcionará

Muchas empresas, operadores y organizaciones bloquean o limitan el tráfico UDP fuera del puerto 53 (utilizado para DNS) ya que en los últimos días se ha abusado de él para realizar ataques. En particular, algunos de los protocolos UDP existentes y las implementaciones de servidores populares para ellos han sido vulnerables a los ataques de amplificación en los que un atacante puede hacer una gran cantidad de tráfico saliente para atacar a víctimas inocentes.

QUIC tiene una mitigación incorporada contra los ataques de amplificación al requerir que el paquete inicial sea de al menos 1200 bytes y mediante una restricción en el protocolo que dice que un servidor no debe enviar más de tres veces el tamaño de la solicitud en respuesta sin recibir un paquete del cliente en respuesta.

## UDP es lento en los núcleos

Esto parece ser la verdad, al menos inicialmente. Por supuesto, no podemos saber cómo evolucionará esto y cuánto de esto es simplemente el resultado de que el rendimiento de la transferencia UDP no ha estado en el foco de los desarrolladores durante muchos años.

Para la mayoría de los clientes, es probable que esta "lentitud" ni siquiera se note.

## QUIC consume demasiada CPU

Al igual que la observación anterior de que "UDP es lento", esto se debe en parte a que el uso de TCP y TLS en el mundo ha tenido más tiempo para madurar, mejorar y obtener asistencia de hardware.

Hay razones para esperar que esto mejore con el tiempo, y ya \[estamos viendo algunas mejoras en este espacio] (<https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency>). La cuestión es hasta qué punto este uso adicional de la CPU perjudicará a los implantadores.

## Esto es sólo Google

No, no lo es. Google llevó la especificación inicial al IETF después de haber demostrado, a gran escala en Internet, que el despliegue de este estilo de protocolo sobre UDP realmente funciona y tiene un buen rendimiento.

Desde entonces, personas de un gran número de empresas y organizaciones han trabajado en la organización neutral de proveedores IETF para elaborar un protocolo de transporte estándar a partir de él. En ese trabajo, los empleados de Google han participado, por supuesto, pero también lo han hecho los empleados de un gran número de otras empresas que están interesadas en promover el estado de los protocolos de transporte en Internet, como Mozilla, Fastly, Cloudflare, Akamai, Microsoft, Facebook y Apple.

## Es una mejora demasiado pequeña

Esto no es realmente una crítica, sino una opinión. Tal vez lo sea, y tal vez sea una mejora demasiado pequeña desde que se lanzó HTTP/2.

Es probable que HTTP/3 funcione mucho mejor en redes con pérdida de paquetes, ofrece handshakes más rápidos, por lo que mejorará la latencia tanto percibida como real. Pero, ¿es esto suficiente para motivar a la gente a desplegar el soporte de HTTP/3 en sus servidores y servicios? El tiempo y las futuras mediciones de rendimiento seguramente lo dirán.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://http3-explained.haxx.se/es/criticism.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
