1. INTRODUCCIÓN Y ENCUADRE

Internet es una infraestructura mundial de interconexión de redes que permite transportar información entre sistemas autónomos mediante la familia de protocolos TCP/IP. No debe confundirse con la Web. Internet es la red y el conjunto de mecanismos de direccionamiento, encaminamiento, transporte y resolución de nombres; la World Wide Web es uno de los servicios que se ejecutan sobre esa infraestructura, basado principalmente en URL, HTTP, HTML y navegadores.

El enunciado del tema reúne cinco planos que conviene estudiar de forma integrada. El primero es la infraestructura: redes de acceso, operadores, sistemas autónomos, puntos de intercambio, direccionamiento IP y DNS. El segundo son los servicios tradicionales, especialmente correo y transferencia de ficheros. El tercero comprende lenguajes, formatos, herramientas y protocolos de la plataforma web. El cuarto diferencia Internet, intranet y extranet. El quinto incorpora dos atributos de calidad que en el sector público son inseparables del servicio digital: accesibilidad y usabilidad.

Para un TFA-STI del Servicio Andaluz de Salud, estos conocimientos no son meramente descriptivos. Una aplicación asistencial o administrativa depende de la resolución de nombres, certificados, balanceadores, servidores web, APIs, controles de acceso, monitorización, navegadores y tecnologías de apoyo. Una incidencia que el usuario percibe como «la aplicación no funciona» puede originarse en DNS, en un certificado caducado, en una política de proxy, en una cabecera HTTP, en un error JavaScript, en una sesión expirada o en una barrera de accesibilidad.

El estudio debe distinguir entre estándar, implementación y producto. HTTP es un protocolo normalizado por el IETF; un servidor como Apache HTTP Server, nginx o Microsoft IIS es una implementación; una plataforma corporativa es una solución concreta que combina componentes. Del mismo modo, HTML es un estándar vivo, mientras que un framework de interfaz es una herramienta que cambia con rapidez. En oposición interesa memorizar lo estable y comprender cómo se aplican las tecnologías variables.

2. ARQUITECTURA Y FUNCIONAMIENTO DE INTERNET

2.1. Red de redes y sistemas autónomos

Internet no posee un centro único de control. Está formada por miles de redes administrativas independientes que acuerdan cómo intercambiar tráfico. Una gran red gestionada bajo una política común recibe el nombre de sistema autónomo o AS y se identifica mediante un ASN. Dentro de un AS se utilizan protocolos internos de encaminamiento; entre sistemas autónomos, el protocolo de referencia es BGP, que intercambia información de alcanzabilidad y aplica políticas comerciales y técnicas.

Los operadores se conectan mediante relaciones de tránsito y peering. En el tránsito, una red paga a otra para alcanzar el resto de Internet. En el peering, dos redes intercambian directamente tráfico de sus clientes, normalmente en puntos neutros o Internet Exchange Points. Las categorías comerciales «Tier 1», «Tier 2» o «Tier 3» ayudan a describir posiciones relativas, pero no son capas técnicas normalizadas de Internet ni implican por sí solas una calidad concreta.

2.2. Capas y encapsulación

La comunicación se explica mediante capas. La capa de aplicación define el significado de los mensajes; la de transporte proporciona comunicación extremo a extremo; la capa de Internet direcciona y encamina datagramas; y la de acceso a red los transmite por Ethernet, Wi-Fi u otro medio. Cada capa añade información de control. En recepción se realiza el proceso inverso.

TCP ofrece un flujo fiable y ordenado orientado a conexión. UDP entrega datagramas sin garantizar recepción u orden, lo que reduce sobrecarga y deja a la aplicación decidir qué mecanismos necesita. QUIC se ejecuta sobre UDP, pero incorpora cifrado, establecimiento de conexión, control de congestión y múltiples flujos; por tanto, no debe describirse como «UDP sin fiabilidad» en el nivel funcional que utiliza HTTP/3.

2.3. Direccionamiento, nombres y entrega

IPv4 utiliza direcciones de 32 bits e IPv6 de 128 bits. La dirección identifica una interfaz dentro de una topología de encaminamiento, mientras que el nombre DNS aporta una referencia más estable y comprensible. Cuando un usuario solicita un recurso, normalmente se resuelve primero el nombre, se elige una dirección, se establece el transporte y, finalmente, se intercambian mensajes de aplicación.

Usuario → URL → DNS → dirección IP → ruta → transporte → TLS → HTTP → aplicación

En entornos corporativos intervienen además resolutores internos, proxies, cortafuegos, balanceadores, redes de distribución de contenidos, pasarelas API y sistemas de autenticación. La visibilidad del servicio no implica que el servidor de aplicación esté expuesto directamente: la publicación segura suele interponer varias capas de control.

3. ESTADO ACTUAL Y TENDENCIAS

3.1. Convivencia de IPv4 e IPv6

La transición a IPv6 es gradual. IPv4 continúa operativo mediante reutilización de direcciones privadas, NAT y mecanismos de compartición, mientras IPv6 elimina la escasez práctica de direcciones y simplifica el direccionamiento extremo a extremo. Las organizaciones suelen adoptar dual stack, traducción o túneles durante la migración. El reto no consiste solo en activar IPv6: deben revisarse DNS, reglas de filtrado, inventario, observabilidad, aplicaciones que almacenan direcciones y procedimientos de respuesta a incidentes.

3.2. Cifrado generalizado y confianza explícita

La tendencia dominante es cifrar por defecto el tráfico entre cliente y servicio. HTTPS, TLS para correo, VPN y SSH reducen la exposición de credenciales y datos. El cifrado no sustituye la autenticación, la autorización ni la seguridad de la aplicación: un canal cifrado puede transportar una petición maliciosa o conectar con un servidor legítimo comprometido. También exige gestionar certificados, claves, algoritmos, renovación, inventario y revocación.

La seguridad evoluciona desde el perímetro único hacia controles distribuidos: identidad fuerte, mínimo privilegio, segmentación, verificación continua y telemetría. Este enfoque se relaciona con Zero Trust, pero no significa «desconfiar de todo» de forma improvisada; significa tomar decisiones de acceso a partir de identidad, dispositivo, contexto, sensibilidad del recurso y política.

3.3. HTTP/3, QUIC y reducción de latencia

HTTP/2 introdujo una representación binaria, compresión de cabeceras y multiplexación de flujos sobre una conexión TCP. HTTP/3 conserva la semántica HTTP y utiliza QUIC. Al disponer de flujos independientes dentro de QUIC, la pérdida que afecta a uno no bloquea necesariamente el avance de los demás como sucede en el flujo ordenado único de TCP. QUIC integra TLS 1.3 en el establecimiento y facilita migrar una conexión cuando cambia la dirección de red del cliente, dentro de las condiciones del protocolo.

3.4. Edge, nube y distribución

La computación en la nube aporta elasticidad, servicios gestionados y automatización; el edge computing sitúa capacidad cerca del lugar donde se generan o consumen los datos. No son modelos excluyentes. Una arquitectura sanitaria puede procesar localmente eventos sensibles o dependientes de baja latencia y consolidar en plataformas centrales información autorizada. La decisión debe basarse en criticidad, conectividad, soberanía del dato, continuidad, coste y capacidad operativa.

3.5. IoT, movilidad y APIs

La expansión de dispositivos conectados, aplicaciones móviles y sensores incrementa el número de identidades, versiones y superficies de ataque. La tendencia técnica es desacoplar canales mediante APIs, eventos y modelos de datos comunes. En sanidad, la conectividad de un dispositivo no convierte automáticamente su dato en información clínica interoperable: se necesitan identificación, semántica, trazabilidad, control de calidad y gobierno.

3.6. Plataforma web como entorno de aplicación

La Web ha pasado de documentos enlazados a aplicaciones ricas. Navegadores actuales incorporan módulos JavaScript, almacenamiento, criptografía, gráficos, multimedia, comunicación en tiempo real, trabajadores en segundo plano y WebAssembly. El estándar HTML se mantiene como Living Standard; por eso hablar de «HTML5» es útil históricamente, pero técnicamente la plataforma evoluciona de forma continua.

3.7. Inteligencia artificial y automatización

Los servicios web integran búsqueda semántica, asistentes conversacionales, clasificación y generación de contenido. La tendencia relevante para un sistema público no es solo incorporar modelos, sino gobernar datos, trazabilidad, supervisión humana, seguridad, explicabilidad, accesibilidad y evaluación. Una interfaz conversacional no reemplaza por sí sola una navegación accesible ni elimina la obligación de ofrecer información correcta y canales alternativos.

3.8. Preparación criptográfica poscuántica

La migración poscuántica se plantea como inventario y agilidad criptográfica: conocer dónde se usan algoritmos y certificados, separar dependencias, probar mecanismos híbridos y planificar sustituciones. No debe confundirse una recomendación de preparación con la afirmación de que toda la infraestructura actual deba reemplazarse de inmediato. El valor para el examen está en comprender el riesgo de conservación prolongada de datos y el concepto «capturar ahora, descifrar después».

4. SERVICIOS DE INFRAESTRUCTURA DE INTERNET

4.1. DNS

El Sistema de Nombres de Dominio es una base de datos jerárquica y distribuida. Un nombre se divide en etiquetas; la delegación reparte autoridad desde la raíz hacia dominios de nivel superior y zonas subordinadas. Un resolver recursivo obtiene la respuesta en nombre del cliente y la almacena temporalmente según el TTL. Un servidor autoritativo responde con los datos de la zona que administra.

DNS utiliza normalmente el puerto 53 tanto con UDP como con TCP. Reducirlo a «UDP para consultas y TCP solo para transferencias de zona» es una simplificación: las respuestas grandes, truncadas, DNSSEC y otros escenarios pueden requerir TCP. La caché mejora rendimiento, pero también obliga a comprender propagación y TTL. Un cambio correcto puede tardar en observarse mientras existan respuestas válidas almacenadas.

4.2. DHCP y autoconfiguración

DHCP asigna parámetros de red como dirección, máscara, puerta de enlace y resolutores. En IPv4, el cliente sin dirección inicia el proceso mediante difusión. En IPv6 coexisten SLAAC, DHCPv6 con estado y DHCPv6 sin estado. SLAAC permite construir direcciones a partir de anuncios de router, pero la política de una organización puede exigir mecanismos adicionales para inventario, opciones o control.

4.3. Sincronización horaria

NTP sincroniza relojes a través de una jerarquía lógica de fuentes. La hora coherente es esencial para correlacionar registros, validar certificados, ordenar transacciones, aplicar caducidades y analizar incidentes. Un desfase puede provocar fallos de autenticación o hacer inútil una auditoría. La arquitectura corporativa debe definir fuentes autorizadas, redundancia y monitorización.

4.4. Proxy, caché y CDN

Un proxy directo actúa en nombre de clientes y puede aplicar filtrado, autenticación o registro. Un proxy inverso recibe peticiones destinadas a servidores y puede terminar TLS, balancear, limitar tráfico o proteger aplicaciones. Una CDN replica o aproxima contenidos para reducir latencia y descargar el origen. Ninguno de estos componentes debe considerarse transparente desde el punto de vista de seguridad: modifica rutas de confianza, cabeceras, certificados y observabilidad.

5. CORREO ELECTRÓNICO

5.1. Arquitectura funcional

El correo de Internet es un sistema de almacenamiento y reenvío. El agente de usuario compone el mensaje; el servicio de presentación lo acepta; uno o varios agentes de transferencia SMTP lo encaminan; el servidor de destino lo deposita en un buzón; y el destinatario accede mediante IMAP, POP3 o una interfaz web. El mensaje y el sobre SMTP son conceptos diferentes: las direcciones usadas para el transporte no tienen por qué coincidir exactamente con los campos visibles de cabecera.

5.2. SMTP

SMTP es el protocolo de transferencia de correo entre servidores y también la base de la presentación de mensajes. Su diálogo utiliza comandos como EHLO, MAIL FROM, RCPT TO, DATA y QUIT. ESMTP amplía capacidades anunciadas tras EHLO, por ejemplo autenticación, tamaño máximo o negociación de TLS.

El puerto 25 se asocia al intercambio entre servidores. El puerto 587 se utiliza para presentación de mensajes por clientes autenticados. El puerto 465 está registrado para presentación con TLS implícito. STARTTLS permite comenzar en texto y elevar la conexión a TLS cuando ambos extremos lo anuncian; su seguridad efectiva depende de política, validación y resistencia a degradación.

S: 220 mail.example.test ESMTP
C: EHLO cliente.example.test
S: 250-STARTTLS
S: 250 AUTH PLAIN LOGIN
C: STARTTLS
S: 220 Ready to start TLS
... negociación TLS ...

5.3. IMAP y POP3

IMAP está orientado a mantener el buzón en el servidor y sincronizar carpetas, estados y mensajes entre varios dispositivos. IMAP4rev2 se especifica en RFC 9051. Usa el puerto 143 en su servicio tradicional y 993 para IMAP sobre TLS implícito. POP3, definido en RFC 1939, ofrece un modelo más simple de descarga; usa 110 y 995 para POP3 sobre TLS. La idea de que POP3 «siempre borra» los mensajes es incorrecta: el cliente puede configurarse para conservarlos, aunque el protocolo no ofrece la riqueza de sincronización de IMAP.

5.4. Formato, MIME y adjuntos

El formato de mensaje define cabeceras y cuerpo. MIME permite múltiples partes, tipos de contenido, juegos de caracteres y adjuntos. Los binarios se codifican para viajar por infraestructuras de texto. El tipo declarado, el nombre del fichero y el contenido real deben tratarse como datos no confiables: un control seguro inspecciona y valida, no se limita a la extensión.

5.5. Autenticación de dominio y protección

SPF autoriza servidores para determinados dominios del sobre; DKIM firma cabeceras y cuerpo con una clave asociada al dominio; DMARC relaciona la identidad visible con los resultados de SPF o DKIM y publica política e informes. Estos mecanismos reducen suplantaciones de dominio, pero no demuestran que el contenido sea verdadero ni que la cuenta no haya sido comprometida.

La protección corporativa incluye filtrado antimalware, análisis de enlaces, sandboxing, límites de adjuntos, prevención de pérdida de datos, autenticación multifactor y concienciación. El correo sigue siendo un vector principal de ingeniería social porque combina confianza, urgencia y contenido externo.

6. TRANSFERENCIA DE FICHEROS

6.1. FTP

FTP es un protocolo clásico definido originalmente en RFC 959. Mantiene una conexión de control y abre conexiones de datos separadas. En modo activo, el servidor inicia la conexión de datos hacia el cliente; en modo pasivo, el cliente abre también la conexión de datos hacia el servidor. El modo pasivo facilita atravesar NAT y cortafuegos del lado cliente, pero obliga a controlar un rango de puertos de datos en el servidor.

FTP no cifra credenciales, comandos ni datos. Por tanto, no es apropiado para transferir información sensible a través de redes no confiables. Su existencia en sistemas heredados no convierte su uso en aceptable; una migración debe identificar dependencias, automatizaciones, codificación, modos activo/pasivo, permisos y validación de integridad.

6.2. FTPS

FTPS es FTP protegido con TLS, normalizado mediante las extensiones de RFC 4217. En el modo explícito, el cliente conecta al servicio FTP y solicita TLS mediante AUTH TLS. Conserva el modelo de dos canales y, por ello, la inspección y publicación a través de cortafuegos puede ser más compleja. Deben protegerse tanto el canal de control como el de datos y validarse correctamente los certificados.

6.3. SFTP

SFTP, en el uso moderno, significa SSH File Transfer Protocol. No es «FTP dentro de SSH»: es un protocolo distinto que utiliza el subsistema de SSH y normalmente una única conexión al puerto 22. Permite operaciones de ficheros, directorios, atributos y reanudación según implementación. Su especificación histórica más citada quedó como Internet-Draft, no como RFC definitivo; aun así, es un protocolo ampliamente implementado e interoperable en sus versiones comunes.

SSH proporciona confidencialidad, integridad y autenticación del servidor. El cliente debe verificar la clave del host, no aceptar cambios sin investigación. La autenticación por clave pública evita contraseñas en scripts, pero exige proteger la clave privada, limitar permisos, rotar credenciales y restringir comandos o directorios cuando proceda.

6.4. SCP, HTTPS y transferencia gestionada

SCP copia ficheros sobre SSH, pero ofrece menos semántica de gestión que SFTP y ha tenido diferencias históricas entre implementaciones. HTTPS es una alternativa natural para carga y descarga mediante APIs, formularios o almacenamiento de objetos. En organizaciones grandes se emplean plataformas MFT que añaden colas, reintentos, trazabilidad, aprobación, cifrado, antivirus, no repudio operativo y gestión centralizada.

6.5. Integridad, disponibilidad y operación

Cifrar el canal no verifica por sí solo que el fichero sea el esperado. Deben comprobarse tamaño, hash cuando proceda, estructura, origen, firma, antivirus y reglas de negocio. En transferencias automatizadas es necesario distinguir fichero temporal, fichero completo y fichero procesado para evitar leer contenidos parciales. También deben definirse reintentos idempotentes, cuarentena, retención, alertas y conciliación.

1. El emisor genera el fichero y calcula su hash.
2. Transfiere con un nombre temporal.
3. El receptor valida canal, tamaño, formato y hash.
4. El fichero se renombra de forma atómica como disponible.
5. El proceso consumidor registra resultado y conserva trazabilidad.

7. LENGUAJES Y FORMATOS PARA INTERNET

7.1. HTML

HTML describe la estructura y semántica de documentos y aplicaciones web. Elementos como header, nav, main, section, button, label o table expresan función, no solo apariencia. El navegador construye el DOM, que puede ser consultado y modificado por scripts y expuesto a tecnologías de apoyo mediante el árbol de accesibilidad.

El estándar vigente se publica como HTML Living Standard. «HTML5» identifica la gran evolución que incorporó semántica, multimedia, formularios y APIs, pero no debe interpretarse como una versión congelada que ya no cambia. La compatibilidad se gestiona con mejora progresiva: primero contenido y función básicos; después capacidades adicionales si el navegador las soporta.

<form>
  <label for="nuhsa">Identificador del paciente</label>
  <input id="nuhsa" name="nuhsa" autocomplete="off" required>
  <button type="submit">Consultar</button>
</form>

En el ejemplo, la etiqueta está asociada programáticamente al control y el botón tiene semántica nativa. Añadir un atributo ARIA no mejora un elemento que ya se ha construido correctamente; la primera regla práctica es utilizar HTML nativo antes de crear controles personalizados.

7.2. CSS

CSS controla presentación, adaptación y parte de la interacción visual. Se organiza en módulos, no en una única especificación «CSS3» cerrada. La cascada resuelve reglas por origen, importancia, capa, especificidad y orden. Flexbox y Grid permiten diseños adaptables sin usar tablas de presentación. Las media queries aplican estilos según características del entorno, principalmente el ancho del viewport.

.contenedor {
  display: grid;
  gap: 1rem;
  grid-template-columns: 1fr;
}

@media (min-width: 64rem) {
  .contenedor {
    grid-template-columns: 18rem 1fr;
  }
}

Las unidades relativas, el reflujo, el zoom y las preferencias del usuario son esenciales. Un diseño que funciona solo a un ancho exacto o que usa device-width como sustituto del viewport es frágil. La pregunta oficial de 2021 sobre una pantalla exacta refleja una formulación histórica; en diseño moderno se prefiere adaptar rangos de viewport y contenido.

7.3. JavaScript y ECMAScript

JavaScript es la implementación más extendida del lenguaje ECMAScript. El estándar define tipos, funciones, objetos, módulos, promesas e iteradores. En el navegador se combina con APIs del entorno, como DOM, Fetch, WebSocket, almacenamiento o eventos. Node.js ejecuta JavaScript fuera del navegador y permite desarrollar servidores y herramientas.

La asincronía es central: una petición no debe bloquear la interfaz mientras espera. Las promesas y async/await estructuran flujos asíncronos, pero no eliminan errores de concurrencia, cancelación o reintento. Una interfaz accesible debe comunicar estados de carga, éxito y error sin depender solo del color o de cambios visuales silenciosos.

async function cargarCitas(url) {
  const respuesta = await fetch(url, {
    headers: { "Accept": "application/json" }
  });
  if (!respuesta.ok) {
    throw new Error(`HTTP ${respuesta.status}`);
  }
  return respuesta.json();
}

7.4. XML, JSON y otros formatos

XML representa documentos y datos mediante elementos, atributos y espacios de nombres. Puede validarse con esquemas y transformarse con tecnologías asociadas. Es adecuado cuando se necesita un modelo documental rico, vocabularios extensibles, firmas XML o compatibilidad con estándares existentes. JSON representa objetos, arrays, cadenas, números, booleanos y nulo con una sintaxis compacta; es predominante en APIs web.

El formato no garantiza interoperabilidad semántica. Dos sistemas pueden intercambiar JSON válido y asignar significados distintos a un mismo campo. La interoperabilidad requiere contrato, identificadores, terminologías, versiones, reglas de obligatoriedad y gestión de errores.

7.5. Web semántica

La Web semántica busca expresar relaciones interpretables por máquinas mediante identificadores y modelos formales. RDF representa afirmaciones como triples; RDFS y OWL permiten vocabularios y ontologías; SPARQL consulta grafos RDF. En el ámbito biomédico, ontologías y terminologías ayudan a vincular conceptos, pero requieren gobernanza y no deben confundirse con una base documental convencional.

8. HERRAMIENTAS Y ARQUITECTURAS DE DESARROLLO WEB

8.1. Navegador y herramientas de desarrollo

El navegador interpreta HTML y CSS, ejecuta JavaScript, aplica políticas de seguridad, gestiona almacenamiento y comunica con servidores. Sus herramientas de desarrollo permiten inspeccionar DOM, estilos, red, tiempos, almacenamiento, accesibilidad y consola. Una prueba eficaz combina evidencia del cliente con registros del servidor y trazas distribuidas; la consola por sí sola no explica un fallo de extremo a extremo.

8.2. Servidores web y servidores de aplicaciones

Un servidor web atiende HTTP, sirve contenido estático y puede actuar como proxy inverso. Un servidor de aplicaciones ejecuta lógica de negocio, gestiona componentes y conecta con datos y servicios. La frontera depende de la tecnología: una aplicación Node.js puede escuchar HTTP directamente, mientras que una aplicación Java puede desplegarse detrás de un proxy y un contenedor.

8.3. Frameworks de cliente

React, Angular, Vue y otras herramientas facilitan componentes, estado, enrutamiento y construcción. No son estándares web y su presencia no garantiza calidad. Una aplicación de página única puede mejorar continuidad de interacción, pero también aumentar tamaño, complejidad, dependencia de JavaScript y riesgo de barreras si el foco, los títulos, el historial o los mensajes dinámicos no se gestionan.

La representación del lado servidor, la generación estática y la hidratación parcial permiten entregar HTML útil antes de ejecutar todo el código cliente. La elección debe responder a requisitos de tiempo de carga, accesibilidad, indexación, resiliencia y mantenimiento, no a la popularidad del framework.

8.4. Tecnologías de servidor

Java y Spring, .NET, Python, PHP, JavaScript/TypeScript y otros ecosistemas ofrecen frameworks para APIs, plantillas, seguridad y persistencia. Lo importante es separar responsabilidades, validar entradas, gestionar transacciones, aplicar configuración externa, registrar eventos relevantes y diseñar contratos estables. Un lenguaje interpretado o compilado no es intrínsecamente más seguro; la seguridad depende del diseño, bibliotecas, configuración y operación.

8.5. Gestión de código y entrega

Git conserva historial distribuido y facilita revisión. La integración continua compila, analiza y prueba cada cambio; la entrega continua prepara artefactos reproducibles; el despliegue continuo automatiza la puesta en producción cuando la política lo permite. Contenedores empaquetan aplicación y dependencias, mientras Kubernetes orquesta cargas, configuración y escalado. Estas herramientas no sustituyen el diseño de alta disponibilidad ni la gestión de datos persistentes.

8.6. Pruebas

Las pruebas unitarias verifican componentes aislados; las de integración comprueban colaboraciones; las de contrato validan interfaces; las end-to-end recorren procesos; las de carga evalúan capacidad; las de seguridad buscan vulnerabilidades; y las de accesibilidad comprueban requisitos automáticos y manuales. La pirámide de pruebas evita depender de suites end-to-end lentas y frágiles.

En web deben probarse también navegadores, tamaños, teclado, lectores de pantalla, zoom, tiempos de espera, pérdida de conectividad, duplicación de envíos y recuperación de sesión. Los datos de prueba no deben exponer información real sin controles adecuados.

8.7. Observabilidad

Monitorización responde a preguntas conocidas mediante métricas y alertas; observabilidad ayuda a investigar estados no previstos combinando registros, métricas y trazas. Una petición puede recibir un identificador de correlación que atraviese proxy, aplicación y servicios. Deben evitarse datos de salud, credenciales o tokens en logs. La retención y acceso se definen conforme a necesidad y normativa.

9. HTTP, HTTPS Y EVOLUCIÓN DEL TRANSPORTE WEB

9.1. Semántica HTTP

HTTP es un protocolo de aplicación sin estado para sistemas distribuidos de información. «Sin estado» significa que cada petición debe aportar la información necesaria para ser interpretada; no significa que una aplicación no pueda mantener sesión. La sesión se implementa sobre HTTP mediante cookies, tokens, almacenamiento del servidor u otros mecanismos.

La unidad conceptual es el recurso identificado por una URI. El cliente envía un método, un objetivo, cabeceras y, opcionalmente, contenido. El servidor devuelve un código de estado, cabeceras y contenido. Los métodos poseen propiedades relevantes: GET y HEAD son seguros; PUT y DELETE son idempotentes en su semántica; POST no lo es necesariamente.

9.2. Códigos de estado

Los códigos se agrupan en cinco clases. Los 1xx informan; 2xx indican éxito; 3xx redirección o uso de caché; 4xx errores atribuibles a la petición; y 5xx fallos del servidor o intermediario. No debe devolverse siempre 200 OK con un error dentro del cuerpo, porque rompe intermediarios, clientes, monitorización y semántica.

9.3. Cabeceras, caché y negociación

Las cabeceras transportan metadatos. Content-Type identifica el tipo; Accept expresa preferencias; Authorization presenta credenciales; Location señala un recurso; Cache-Control define política de caché; ETag aporta un validador; Content-Security-Policy restringe orígenes de contenido; y Strict-Transport-Security ordena usar HTTPS durante un periodo.

La caché reduce latencia y carga, pero debe diseñarse para no mezclar respuestas privadas. Una respuesta que contiene datos personales no debe almacenarse en una caché compartida salvo política explícita segura. Las URLs, cabeceras y trazas también pueden revelar información; por ello, identificadores sensibles no deberían incluirse sin necesidad en rutas o consultas.

9.4. HTTP/1.1

HTTP/1.1 usa mensajes textuales sobre TCP, conexiones persistentes y mecanismos de caché. Puede enviar varias peticiones en una conexión, pero el pipelining tuvo poco uso por problemas operativos. Los navegadores abrieron varias conexiones por origen para paralelizar, con coste de handshake, congestión y recursos.

9.5. HTTP/2

HTTP/2 conserva métodos, URI, estados y cabeceras, pero usa tramas binarias y múltiples flujos dentro de una conexión TCP. HPACK comprime cabeceras. La multiplexación evita esperar la respuesta completa de una petición antes de enviar otra en el nivel HTTP; sin embargo, la pérdida de un segmento TCP puede detener temporalmente todos los flujos porque TCP entrega un único flujo ordenado.

El server push formó parte de HTTP/2, pero no debe considerarse su ventaja esencial ni una práctica universal. La priorización ha evolucionado y depende de clientes, servidores e intermediarios. Para examen, la distinción estable es la multiplexación sobre una conexión y la representación binaria.

9.6. HTTP/3 y QUIC

HTTP/3, RFC 9114, lleva la semántica HTTP sobre QUIC, RFC 9000. QUIC opera sobre UDP, integra cifrado TLS 1.3, multiplexa flujos y gestiona pérdida por flujo. La compresión de cabeceras usa QPACK, adaptada para evitar dependencias problemáticas entre flujos. El puerto habitual sigue siendo 443 y la selección puede anunciarse mediante mecanismos HTTP.

Decir que HTTP/3 «es más rápido» sin contexto es insuficiente. Puede reducir latencia de establecimiento y mejorar comportamiento ante pérdida o cambios de red, pero el resultado depende de distancia, calidad, implementación, CPU, intermediarios y soporte. La operación debe observar tasas de negociación, fallbacks y errores UDP.

9.7. HTTPS y TLS

HTTPS es HTTP protegido por TLS. TLS autentica normalmente al servidor mediante certificado, negocia parámetros y deriva claves de tráfico. Tras el establecimiento, el contenido se protege con criptografía simétrica autenticada por eficiencia. La criptografía asimétrica y las firmas intervienen en autenticación y establecimiento, no cifran cada byte de aplicación.

TLS 1.3 está especificado actualmente por RFC 9846, que sustituyó en julio de 2026 a RFC 8446. TLS 1.2 permanece desplegado en compatibilidad, pero TLS 1.0 y 1.1 están obsoletos. La configuración segura no se reduce al número de versión: incluye algoritmos, certificados, nombres, cadena de confianza, protección de claves, renovación y desactivación de suites débiles.

10. PROTOCOLOS Y ESTILOS DE INTEGRACIÓN

10.1. REST

REST es un estilo arquitectónico para sistemas distribuidos, no un protocolo ni un sinónimo de «JSON sobre HTTPS». Sus restricciones incluyen cliente-servidor, ausencia de estado de sesión en el servidor entre peticiones, caché, interfaz uniforme, sistema por capas y código bajo demanda opcional. Una API puede usar HTTP y JSON sin cumplir bien REST si trata todos los recursos como operaciones remotas arbitrarias.

El diseño orientado a recursos usa URI estables, métodos HTTP, representaciones, códigos de estado y enlaces cuando aportan navegación. La condición stateless no impide guardar datos de negocio: impide depender de contexto conversacional oculto entre peticiones. El cliente presenta en cada llamada las credenciales y parámetros necesarios.

GET /api/citas/7f3a
Accept: application/json
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json
ETag: "v8"

{"id":"7f3a","estado":"programada"}

10.2. SOAP y servicios web

SOAP define un sobre XML extensible para intercambio de mensajes. Puede usar HTTP u otros transportes y combinarse con WSDL, esquemas XML y extensiones WS-* para seguridad, direccionamiento o fiabilidad. Frente a APIs JSON ligeras, SOAP ofrece contratos formales y capacidades consolidadas, pero añade complejidad. En entornos corporativos ambos estilos pueden coexistir.

10.3. GraphQL

GraphQL define un esquema tipado y permite al cliente seleccionar campos. Reduce sobreobtención en ciertas interfaces y facilita evolución aditiva, pero exige controlar profundidad, coste, autorización por campo, caché y observabilidad. No reemplaza automáticamente REST; es una elección de interfaz con compromisos distintos.

10.4. WebSocket y eventos del servidor

WebSocket establece un canal bidireccional persistente tras una apertura asociada a HTTP. Es útil para notificaciones, colaboración y actualización en tiempo real. El evento JavaScript message entrega los datos recibidos. Deben gestionarse autenticación inicial y renovada, límites, reconexión, orden, latidos y autorización de cada operación.

const socket = new WebSocket("wss://servicio.example.test/eventos");

socket.addEventListener("message", (evento) => {
  const dato = JSON.parse(evento.data);
  actualizarInterfaz(dato);
});

Server-Sent Events ofrece un flujo unidireccional servidor-cliente sobre HTTP y puede ser más sencillo para notificaciones. El long polling mantiene una petición hasta que hay información. La elección depende de direccionalidad, intermediarios, frecuencia y recuperación.

10.5. gRPC

gRPC usa contratos Protocol Buffers y soporta llamadas unary y streaming. Se emplea especialmente entre servicios controlados. Se beneficia de HTTP/2 y generación de clientes, pero su consumo directo desde navegadores puede requerir adaptaciones. Su contrato binario no elimina la necesidad de versionado compatible y gobierno de errores.

10.6. MQTT y mensajería

MQTT sigue un modelo publicación-suscripción con broker y niveles de calidad de servicio. Es adecuado para dispositivos con recursos limitados, pero el QoS de transporte no garantiza que el dato sea clínicamente correcto ni procesado exactamente una vez de extremo a extremo. La seguridad exige identidades por dispositivo, topics autorizados, TLS, rotación y gestión de firmware.

Las colas y buses desacoplan productor y consumidor, absorben picos y permiten reintentos. Introducen consistencia eventual y necesidad de idempotencia. Un consumidor debe tolerar mensajes duplicados y gestionar mensajes que no puede procesar mediante colas de error o cuarentena.

10.7. Autenticación y autorización web

Cookies de sesión, tokens portadores, OAuth 2.0 y OpenID Connect resuelven problemas distintos. OAuth delega autorización; OpenID Connect añade identidad sobre OAuth; SAML es frecuente en federación empresarial. Un JWT es un formato de token, no un protocolo completo ni una garantía de seguridad. Deben validarse firma, emisor, audiencia, expiración y algoritmo, y minimizarse los datos incluidos.

11. INTRANETS Y EXTRANETS

11.1. Conceptos

Una intranet aplica tecnologías de Internet dentro de una organización para ofrecer información, aplicaciones y colaboración a personal autorizado. Puede usar navegadores, HTTP, DNS, correo, directorios y APIs, pero sus recursos no están destinados al público general. Una extranet extiende de forma controlada determinados servicios a terceros: proveedores, entidades colaboradoras, profesionales externos o administraciones.

La diferencia esencial no es el protocolo, sino la comunidad de confianza y la política de acceso. Un portal accesible desde Internet con autenticación corporativa puede seguir siendo intranet lógica; una aplicación alojada en red interna que admite usuarios de otra organización actúa como extranet. La ubicación física no determina por sí sola la clasificación.

11.2. Componentes

Una intranet suele integrar directorio, SSO, DNS interno, portal, gestor documental, buscador, servicios de colaboración, catálogo de aplicaciones y soporte. La extranet añade gestión del ciclo de vida de identidades externas, patrocinador, caducidad, acuerdos, segregación y auditoría. Las cuentas de terceros no deben convertirse en cuentas internas permanentes sin propietario.

11.3. Acceso remoto y VPN

Una VPN crea conectividad protegida entre un usuario o sede y una red. Puede ser de acceso remoto o sitio a sitio. IPsec opera en la capa de red; las VPN basadas en TLS pueden publicar aplicaciones o proporcionar túneles. El hecho de entrar por VPN no debería conceder acceso amplio: se combinan MFA, postura del dispositivo, segmentación y permisos por aplicación.

11.4. DMZ y publicación

La zona desmilitarizada aloja o intermedia servicios expuestos sin situarlos en la misma zona de confianza que sistemas internos. Una arquitectura típica coloca proxy inverso o WAF en la zona publicada y limita conexiones hacia aplicaciones. Las reglas deben ser explícitas por origen, destino, puerto y necesidad. «Abrir la DMZ hacia dentro» de forma general anula su finalidad.

11.5. Segmentación y nombres

La segmentación separa puestos, servidores, administración, dispositivos y terceros. DNS de horizonte dividido puede devolver respuestas distintas según el origen, pero debe gobernarse para evitar inconsistencias. Las aplicaciones no deberían depender de direcciones IP fijas cuando un nombre y un servicio gestionado aportan desacoplamiento.

12. SEGURIDAD, OPERACIÓN Y GOBIERNO

12.1. Riesgos principales

Los servicios de Internet afrontan interceptación, suplantación, manipulación, denegación de servicio, malware, robo de sesión, inyección, ejecución de código, exposición de datos y abuso de lógica. La seguridad se diseña por capas: red, transporte, identidad, aplicación, datos, puesto, cadena de suministro y operación.

Las vulnerabilidades web frecuentes incluyen control de acceso roto, inyección, gestión insegura de secretos, errores criptográficos, configuración incorrecta, componentes vulnerables, fallos de autenticación y falta de registro. El TFA-STI debe traducirlos a requisitos comprobables: validación en servidor, consultas parametrizadas, permisos por recurso, secretos fuera del código, cabeceras seguras, inventario de dependencias y pruebas.

12.2. Seguridad del navegador

La política del mismo origen limita el acceso de scripts a recursos de otros orígenes. CORS permite al servidor declarar excepciones; no es un mecanismo de autenticación. CSP restringe qué scripts, estilos y conexiones pueden cargarse y reduce impacto de XSS. Las cookies sensibles deben usar Secure, HttpOnly y una política SameSite adecuada.

CSRF explota credenciales que el navegador envía automáticamente. Se mitiga con tokens, SameSite, comprobación de origen y diseño de APIs. XSS ejecuta contenido no confiable en el navegador; se previene codificando según contexto, evitando inserciones inseguras, sanitizando contenido y usando CSP como defensa adicional.

12.3. Identidad, sesiones y privilegios

La autenticación multifactor reduce el riesgo de credenciales robadas. Las sesiones deben tener identificadores impredecibles, expiración, revocación y regeneración tras autenticación. La autorización se comprueba en servidor en cada operación y objeto; ocultar un botón no impide llamar a la API.

12.4. Disponibilidad y resiliencia

La alta disponibilidad combina redundancia, eliminación de puntos únicos, balanceo, salud, capacidad y recuperación. La resiliencia añade comportamiento degradado, límites, colas, circuit breakers, timeouts y reintentos con control. Un reintento indiscriminado puede amplificar una caída; debe usar espera creciente, aleatoriedad e idempotencia.

12.5. Gestión de certificados

Los certificados deben inventariarse con propietario, servicio, nombres, autoridad, algoritmo y caducidad. La renovación automática reduce errores, pero necesita monitorización. El certificado válido no demuestra que la aplicación sea segura; demuestra una identidad dentro de una cadena y habilita el canal cifrado.

12.6. DevSecOps y cadena de suministro

La seguridad se integra desde requisitos hasta operación: análisis de código, dependencias, contenedores, secretos, infraestructura como código y pruebas dinámicas. Un SBOM ayuda a identificar componentes, pero no sustituye la evaluación de explotabilidad ni la actualización. Los artefactos deben ser reproducibles, firmados cuando proceda y promovidos entre entornos sin recompilar de forma distinta.

12.7. Gobierno de APIs

El catálogo de APIs identifica propietario, versión, datos, consumidores, niveles de servicio y políticas. La pasarela puede autenticar, limitar, transformar y registrar, pero la aplicación conserva la autorización de negocio. El versionado debe evitar rupturas innecesarias; añadir campos suele ser compatible, mientras cambiar su significado no lo es.

12.8. Privacidad por diseño

Debe minimizarse la información recogida, limitar finalidad, separar ambientes, controlar acceso y establecer retención. Los datos de salud requieren especial protección. Telemetría, analítica y pruebas no quedan fuera de estas obligaciones. La privacidad también afecta a URLs, nombres de ficheros, capturas, registros y mensajes de error.

13. ACCESIBILIDAD DIGITAL

13.1. Concepto y alcance

La accesibilidad digital es el conjunto de principios y técnicas que permiten que sitios web, aplicaciones móviles, documentos, formularios y procesos puedan ser percibidos, operados y comprendidos por todas las personas, especialmente personas con discapacidad y mayores. No es una función opcional ni un modo separado: debe formar parte del diseño, desarrollo, contenido, contratación, prueba y mantenimiento.

Una barrera puede ser visual, auditiva, motora, cognitiva o situacional. Un profesional con una lesión temporal, un paciente que usa móvil al sol, una persona mayor con baja visión o alguien con conexión limitada también se beneficia de contenido claro, teclado, contraste, subtítulos y rendimiento.

13.2. Marco normativo

El Real Decreto 1112/2018 regula la accesibilidad de sitios web y aplicaciones móviles del sector público. Exige que los contenidos sean perceptibles, operables, comprensibles y robustos, y que la accesibilidad se contemple integralmente durante diseño, gestión, mantenimiento y actualización. Incluye información, documentos, multimedia, interacción, formularios y procesos de identificación, autenticación, firma y pago.

La presunción de conformidad se vincula a normas armonizadas publicadas en el Diario Oficial de la Unión Europea. La referencia armonizada aplicable a la Directiva de accesibilidad web es EN 301 549 v3.2.1, cuyas cláusulas web incorporan WCAG 2.1 en niveles A y AA. WCAG 2.2 es la recomendación W3C más reciente y amplía 2.1; es recomendable adoptarla como mejora y preparación, pero no debe afirmarse sin matiz que toda su versión sustituye automáticamente la referencia armonizada legal.

La Ley 11/2023 transpone la Directiva Europea de Accesibilidad para determinados productos y servicios, aplicable desde el 28 de junio de 2025, y el Real Decreto 193/2023 extiende condiciones básicas a bienes y servicios a disposición del público. Para el sector sanitario público, el RD 1112/2018 sigue siendo el núcleo específico de webs y apps públicas, complementado por el marco general de accesibilidad universal.

13.3. Principios POUR

13.4. Semántica y tecnologías de apoyo

La semántica nativa crea nombres, roles, estados y relaciones que lectores de pantalla y otras ayudas interpretan. Un button ya es enfocable, activable y anunciado; un div con clic necesita recrear todo ese comportamiento. ARIA complementa HTML cuando no existe semántica suficiente, pero un uso incorrecto puede empeorar la accesibilidad.

<button type="button" aria-expanded="false" aria-controls="detalle">
  Mostrar detalle
</button>
<div id="detalle" hidden>...</div>

El estado aria-expanded debe actualizarse junto con la visibilidad. Los mensajes dinámicos importantes pueden anunciarse mediante regiones vivas, sin abusar de ellas. El orden del DOM debe coincidir con el orden lógico; CSS no debe crear una secuencia visual diferente que confunda teclado y lector.

13.5. Teclado y foco

Toda función debe ser operable con teclado, sin trampas. El foco debe verse, seguir un orden lógico y trasladarse de forma predecible en diálogos o cambios de vista. No se asigna tabindex positivo para «forzar» un orden; se corrige la estructura. Los atajos de una sola tecla pueden interferir con tecnologías de apoyo y deben poder desactivarse o remapearse según el criterio aplicable.

13.6. Contraste, color y reflujo

WCAG 2.1 AA establece una relación mínima de contraste de 4,5:1 para texto normal y 3:1 para texto grande, con excepciones definidas. El color no puede ser el único medio para indicar error, estado o selección. Al ampliar hasta 200 % o adaptar a un viewport estrecho, el contenido debe seguir disponible sin pérdida ni desplazamiento bidimensional innecesario, salvo contenidos que lo requieran por naturaleza.

13.7. Formularios accesibles

Cada campo necesita etiqueta visible y asociada, instrucciones antes de la entrada cuando sean necesarias, agrupación de controles relacionados y mensajes de error vinculados. El placeholder no sustituye a la etiqueta. Los errores deben identificar el campo, explicar el problema y, cuando se conozca, proponer corrección. En procesos críticos, debe permitirse revisar, corregir o confirmar antes de una acción irreversible.

13.8. Multimedia y documentos

El vídeo pregrabado requiere subtítulos y, según el contenido, audiodescripción; el audio necesita alternativa textual. Los PDF y documentos ofimáticos deben tener estructura, orden de lectura, etiquetas, idioma, títulos y tablas accesibles. Publicar un PDF escaneado sin capa de texto crea una barrera aunque la página que lo enlaza sea accesible.

13.9. Evaluación

Las herramientas automáticas detectan ausencia de etiquetas, contrastes y errores estructurales, pero no pueden decidir si un texto alternativo es útil, si el orden es comprensible o si una tarea es viable. La evaluación combina validadores, inspección, teclado, lectores de pantalla y pruebas con usuarios. El RD 1112/2018 exige revisiones y declaración de accesibilidad, además de mecanismos de comunicación y reclamación.

La accesibilidad debe incorporarse a criterios de aceptación, definición de terminado, plantillas, componentes y contratación. Corregir al final es más caro porque los fallos pueden estar en arquitectura, diseño y contenido.

14. USABILIDAD Y DISEÑO ADAPTATIVO

14.1. Definición

ISO 9241-11 define la usabilidad por la medida en que usuarios específicos alcanzan objetivos específicos con eficacia, eficiencia y satisfacción en un contexto de uso. El contexto incluye usuarios, tareas, recursos y entorno. No existe una usabilidad absoluta: una interfaz adecuada para un profesional experto puede ser inadecuada para ciudadanía ocasional.

Accesibilidad y usabilidad se solapan, pero no son idénticas. Un formulario puede cumplir criterios técnicos y seguir siendo confuso; otro puede parecer sencillo a usuarios sin discapacidad y ser imposible con teclado. El diseño de calidad necesita ambas.

14.2. Diseño centrado en el usuario

El proceso comienza investigando usuarios y tareas, no eligiendo colores. Entrevistas, observación, análisis de incidencias y métricas permiten formular necesidades. Se modelan recorridos, arquitectura de información y prototipos; se prueban temprano; se implementa; y se mide en producción. La participación de usuarios no equivale a pedir gustos: consiste en observar si completan tareas y comprender por qué fallan.

14.3. Principios de interacción

El sistema debe mostrar su estado, usar lenguaje del usuario, ofrecer control, mantener consistencia, prevenir errores y facilitar reconocimiento. Las acciones frecuentes necesitan eficiencia, pero los atajos no deben ocultar la vía comprensible. La carga cognitiva disminuye agrupando información, revelando progresivamente detalles y evitando opciones irrelevantes.

La ley de Fitts explica que objetivos grandes y próximos son más rápidos de alcanzar; la ley de Hick relaciona el tiempo de decisión con el número y complejidad de opciones. Son modelos orientativos, no reglas para agrandar todo o reducir funciones esenciales. Deben aplicarse al contexto y verificarse mediante pruebas.

14.4. Arquitectura de información

La navegación debe reflejar modelos mentales y permitir saber dónde se está, qué se puede hacer y cómo volver. Etiquetas claras superan jerga interna. Buscador, menús y migas de pan se complementan. La «regla de tres clics» no es un requisito científico; importa más que cada paso sea predecible y que el usuario no se pierda.

14.5. Formularios y prevención de errores

Se solicitan solo datos necesarios, se agrupan por finalidad, se conservan entradas válidas tras un error y se informa antes de exigir formatos especiales. Las validaciones cliente mejoran respuesta, pero el servidor debe repetirlas. En acciones críticas conviene confirmar el objeto, el efecto y la identidad, sin convertir cada paso en un diálogo innecesario.

14.6. Responsive design

El diseño responsive adapta distribución y componentes al viewport y capacidades. Utiliza rejillas fluidas, contenido flexible, media queries y componentes que reordenan sin perder significado. Mobile first define estilos base para condiciones estrechas y añade mejoras al disponer de espacio; no significa diseñar solo para móvil.

img {
  max-width: 100%;
  height: auto;
}

@media (min-width: 48rem) {
  .resumen {
    display: grid;
    grid-template-columns: 2fr 1fr;
  }
}

14.7. Rendimiento percibido

La velocidad forma parte de la experiencia. Se optimizan tamaño, número de recursos, caché, imágenes, fuentes, JavaScript y trabajo del hilo principal. Los indicadores visuales deben evitar saltos de diseño y comunicar progreso. Una pantalla rápida que muestra información errónea no es usable; el rendimiento debe equilibrarse con consistencia y seguridad.

14.8. Métricas y pruebas

Una prueba moderada observa tareas y permite preguntar; una no moderada escala a más participantes; un test A/B compara variantes con una hipótesis; la analítica detecta patrones, pero no explica por sí sola las causas. En sanidad deben seleccionarse perfiles representativos, incluidos usuarios con discapacidad y baja competencia digital.

15. APLICACIÓN EN EL SAS Y EL SSPA

15.1. Tipos de servicio

El SSPA combina servicios públicos para ciudadanía, aplicaciones profesionales, portales internos, integración entre centros, intercambio con otras administraciones y canales móviles. Cada grupo tiene usuarios, disponibilidad, datos y riesgos diferentes. El objetivo no es imponer una tecnología única, sino una arquitectura gobernada y coherente.

Los servicios ciudadanos deben funcionar desde Internet con identificación proporcional, accesibilidad, lenguaje claro y soporte multicanal. Las aplicaciones profesionales priorizan eficiencia, trazabilidad y continuidad, sin rebajar accesibilidad. Las integraciones máquina a máquina requieren contratos, autenticación, versionado, monitorización y tratamiento de errores.

15.2. Publicación segura

Una publicación típica separa exposición, aplicación y datos; termina TLS en componentes controlados; filtra tráfico; autentica; limita peticiones; y registra eventos. La arquitectura concreta depende de la infraestructura autorizada. No es prudente atribuir públicamente productos, versiones o topologías internas no verificadas.

Los certificados, DNS y balanceadores son activos de servicio. Debe existir inventario, propietario, renovación y prueba de extremo a extremo. Una renovación que solo se valida en el servidor puede fallar en un proxy intermedio o por una cadena incompleta.

15.3. Portal profesional e intranet

Una intranet corporativa integra acceso a aplicaciones, comunicaciones, procedimientos y conocimiento. El SSO reduce autenticaciones repetidas, pero aumenta el impacto de una identidad comprometida. Debe combinarse con MFA cuando corresponda, cierre de sesión, gestión de roles, caducidad y baja de cuentas.

15.4. Transferencias e interoperabilidad

Los intercambios de ficheros pueden aparecer en cargas masivas, informes, lotes, imágenes o integraciones heredadas. Deben migrarse a canales seguros, con cifrado, control de acceso, trazabilidad, validación, retención y conciliación. Siempre que sea viable, una API o mensajería gestionada puede aportar mejor control, pero no se sustituye un lote estable sin analizar volumen, ventanas, reintentos y dependencia.

15.5. Accesibilidad en servicios sanitarios

La accesibilidad afecta a cita, consulta de información, formularios, autenticación, descarga de informes y aplicaciones móviles. Un proceso no es accesible si la portada cumple pero el captcha, el selector de fecha, el PDF o la firma no. La evaluación debe recorrer tareas completas y contemplar contenido generado por terceros.

La contratación debe exigir conformidad, evidencias, corrección de defectos y mantenimiento. Una declaración del proveedor no sustituye la revisión del organismo. Los componentes comunes accesibles reducen repetición de errores y permiten evolucionar con criterios homogéneos.

15.6. Usabilidad clínica y administrativa

En aplicaciones de uso intensivo, segundos repetidos miles de veces se convierten en carga operativa. La optimización debe centrarse en tareas, valores por defecto seguros, reducción de duplicidad, navegación por teclado y prevención de errores. No debe ocultarse información crítica para simplificar; se jerarquiza y muestra en el momento adecuado.

15.7. Continuidad

La dependencia de Internet y tecnologías web exige procedimientos de contingencia. Deben definirse RTO y RPO, modos degradados, comunicación de incidencias, recuperación y pruebas. La indisponibilidad de un servicio externo de identidad, DNS o certificados puede afectar a múltiples aplicaciones; por eso se monitorizan dependencias y no solo procesos locales.

15.8. Soporte y observabilidad

El soporte necesita información reproducible: usuario y rol, fecha, canal, navegador, URL, identificador de correlación, resultado y mensajes. No se solicitan contraseñas ni capturas con datos innecesarios. Los cuadros de mando deben distinguir error técnico, rechazo funcional y abandono de usuario.

16. IDEAS CLAVE PARA EL REPASO

1. Internet no es la Web. Internet interconecta redes mediante TCP/IP; la Web usa URL, HTTP, HTML, CSS y JavaScript.
2. DNS precede normalmente al acceso. A resuelve IPv4, AAAA IPv6, MX correo y PTR resolución inversa.
3. SMTP envía. IMAP sincroniza buzones; POP3 ofrece recuperación más simple.
4. FTP no cifra. FTPS añade TLS a FTP; SFTP es un protocolo sobre SSH y no comparte arquitectura con FTP.
5. HTTP es semántica. Métodos, códigos, cabeceras, caché y recursos se conservan entre versiones.
6. HTTP/2 multiplexa sobre TCP. HTTP/3 utiliza QUIC y flujos independientes sobre UDP con seguridad integrada.
7. HTTPS es HTTP sobre TLS. Tras el handshake, el tráfico se protege con criptografía simétrica autenticada.
8. REST es un estilo. No obliga por definición a JSON ni HTTPS, aunque ambos sean elecciones habituales.
9. HTML aporta semántica. CSS presenta; JavaScript añade comportamiento; XML y JSON representan datos.
10. Una intranet no es un protocolo. Es un ámbito privado que usa tecnologías de Internet; la extranet incorpora terceros autorizados.
11. Accesibilidad y usabilidad son diferentes. La primera elimina barreras; la segunda mide eficacia, eficiencia y satisfacción.
12. POUR: perceptible, operable, comprensible y robusto.
13. Sector público: RD 1112/2018 y EN 301 549; WCAG 2.1 A y AA sustentan la conformidad armonizada, mientras WCAG 2.2 es la referencia W3C más reciente.
14. Responsive adapta el contenido al viewport; no debe diseñarse para un único ancho de dispositivo.
15. La seguridad es multicapa. TLS no corrige una autorización rota ni una aplicación vulnerable.

17. MAPA CONCEPTUAL