docs(blog): clarify HTTP/3 proxy rationale in one-core bottleneck article

[josecelano]

Overview

The blog post below is useful and technically solid on the softirq/RPS-RFS root cause:

• https://torrust.com/blog/how-we-fixed-a-one-core-packet-processing-bottleneck-in-torrust-tracker

However, after ISSUE-29 follow-up analysis, we identified that the wording around disabling Caddy UDP 443 (HTTP/3 edge support) could be clearer to avoid misinterpretation.

Why clarification is needed

Readers could interpret the post as if disabling HTTP/3 was a confirmed performance optimization. The evidence actually showed:

1. Disabling HTTP/3 at the proxy did not materially improve CPU/load in the measured windows.
2. The effective remediation for the one-core hotspot was enabling RPS/RFS.
3. HTTP/3 support at the edge proxy is a separate capability decision, not the root-cause fix for that incident.

Clarifications to add

1. Explicitly separate outcomes:
   • Experiment result: disabling HTTP/3 did not solve the CPU bottleneck.
   • Root-cause fix: packet steering (RPS/RFS).
2. Clarify protocol boundaries:
   • Client -> proxy can be HTTP/3.
   • Proxy -> backend services can remain on existing HTTP transport.
   • Backend native HTTP/3 support is not required to offer HTTP/3 at the edge.
3. Add a short note that HTTP/3 enable/disable should be treated as a product/operations choice with monitoring, not as a default performance lever.
4. Optionally add an update note linking follow-up issues for traceability.

References

• Tracker demo issue about re-enabling edge HTTP/3 and documenting rationale:
  • docs(issue): re-enable caddy http3 and document issue-29 rationale torrust-tracker-demo#31
• Tracker repo issue about documenting proxy-based HTTP/3 support and future native HTTP/3 follow-up:
  • docs(http): document HTTP/3 support via reverse proxy and track native HTTP/3 follow-up torrust-tracker#1736

Acceptance criteria

• The article clearly states that disabling HTTP/3 was not the fix for the one-core bottleneck.
• The article clearly identifies RPS/RFS as the remediation that removed the hotspot.
• The article includes a concise proxy-vs-backend protocol clarification.
• Readers can trace the follow-up rationale through linked issues.