{"id":21215,"date":"2026-08-31T18:19:53","date_gmt":"2026-08-31T16:19:53","guid":{"rendered":"https:\/\/webhosting.de\/tcp-time-wait-optimierung-webserver-performance-netzwerk\/"},"modified":"2026-08-31T18:19:53","modified_gmt":"2026-08-31T16:19:53","slug":"optimizacion-del-tiempo-de-espera-de-tcp-rendimiento-del-servidor-web-red","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/tcp-time-wait-optimierung-webserver-performance-netzwerk\/","title":{"rendered":"Optimizaci\u00f3n del estado TIME_WAIT de TCP en servidores web: gu\u00eda pr\u00e1ctica para administradores"},"content":{"rendered":"<p>Muestro c\u00f3mo <strong>TCP TIME_WAIT<\/strong> en los servidores web de tal forma que una carga elevada a corto plazo no agote los puertos y las nuevas conexiones se establezcan r\u00e1pidamente. La gu\u00eda pr\u00e1ctica ofrece puntos de medici\u00f3n claros, opciones seguras del n\u00facleo, optimizaci\u00f3n de sockets orientada a las aplicaciones y trucos de arquitectura que mantienen TIME_WAIT como una \u00fatil red de seguridad y, al mismo tiempo, aumentan el rendimiento.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>Los siguientes aspectos clave te gu\u00edan de forma espec\u00edfica a trav\u00e9s del an\u00e1lisis y la optimizaci\u00f3n de TIME_WAIT en servidores web Linux.<\/p>\n<ul>\n  <li><strong>Comprender<\/strong>: TIME_WAIT protege la integridad de los datos; el objetivo es el control, no la desconexi\u00f3n.<\/li>\n  <li><strong>ferias<\/strong>: Registrar con precisi\u00f3n el porcentaje de TIME_WAIT, la utilizaci\u00f3n de los puertos y las tasas de reconexi\u00f3n.<\/li>\n  <li><strong>N\u00facleo<\/strong>: Ajustar con cuidado y de forma gradual los par\u00e1metros ip_local_port_range, tcp_fin_timeout y tcp_tw_reuse.<\/li>\n  <li><strong>Enchufes<\/strong>: Keep-Alive, HTTP\/2\/3 y los grupos de conexiones reducen la rotaci\u00f3n de conexiones.<\/li>\n  <li><strong>Arquitectura<\/strong>: El escalado, las direcciones IP y los puertos adicionales, as\u00ed como los proxies, distribuyen la carga de TIME_WAIT.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-optimierung-1423.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Entender correctamente el estado TIME_WAIT<\/h2>\n\n<p>Muchos administradores ven miles de conexiones en <strong>TIME_WAIT<\/strong> y pensamos que se trata de un error, pero ocurre exactamente lo contrario. Este estado mantiene las conexiones cerradas durante un breve periodo de tiempo para que los segmentos tard\u00edos no interfieran con las conexiones nuevas y todos los bytes lleguen a su destinatario. Respeto esta l\u00f3gica de seguridad, ya que evita la mezcla de datos y los molestos RST. En servidores web muy concurridos, el n\u00famero de sockets de corta duraci\u00f3n aumenta de forma natural, lo que requiere una evaluaci\u00f3n serena y no una reacci\u00f3n de p\u00e1nico. Lo decisivo sigue siendo si realmente se producen escasez de puertos, desbordamientos de la cola de espera o errores de los usuarios antes de que inicie el ajuste del sistema.<\/p>\n\n<h2>Detectar s\u00edntomas en servidores con una carga elevada<\/h2>\n\n<p>Primero compruebo el <strong>Puerto<\/strong>-Mensajes de error: \u201eCannot assign requested address\u201c o \u201eAddress already in use\u201c indican agotamiento. Los handshakes retrasados, los rechazos espor\u00e1dicos y los picos de uso de la CPU del kernel en la ruta de red son otras se\u00f1ales de alarma. Cuando la supervisi\u00f3n muestra un n\u00famero inusual de sockets TIME_WAIT, siempre comparo esta cifra con las tasas de nuevas conexiones y los tiempos de respuesta. Una proporci\u00f3n elevada de TIME_WAIT por s\u00ed sola sigue siendo tolerable, siempre y cuando los puertos ef\u00edmeros libres y las tablas de sockets ofrezcan suficiente margen. Solo los cuellos de botella concretos me llevan a ajustar los par\u00e1metros de forma espec\u00edfica, en lugar de actuar por mera sospecha.<\/p>\n\n<h2>Medici\u00f3n y evaluaci\u00f3n: visi\u00f3n general de los estados y los puertos<\/h2>\n\n<p>Sin cifras no puedo optimizar nada, as\u00ed que empiezo con <strong>ss<\/strong> y Netstat, para registrar las distribuciones de estados y las tendencias. Adem\u00e1s, echo un vistazo a \/proc\/net\/tcp, ya que all\u00ed se pueden consultar detalles sobre los puertos locales y remotos y sus estados. De la monitorizaci\u00f3n extraigo los recuentos de TIME_WAIT por host, las nuevas conexiones por segundo y las tasas de error por minuto. Me interesa la relaci\u00f3n entre TIME_WAIT y el total de sockets, as\u00ed como la carga de los puertos ef\u00edmeros, para distinguir la presi\u00f3n real de lo que simplemente parece tal. Solo cuando estas m\u00e9tricas confirman la existencia de cuellos de botella, planifico medidas concretas a nivel del n\u00facleo y de las aplicaciones.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_timewait_optimierung_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ajuste del kernel: ajustes seguros con sentido de la proporci\u00f3n<\/h2>\n\n<p>Empiezo con <strong>conservador<\/strong> Realiza cambios e implem\u00e9ntalos de forma gradual, siempre acompa\u00f1ados de mediciones y con la opci\u00f3n de revertirlos. Un valor m\u00e1s amplio de `ip_local_port_range` ampl\u00eda la selecci\u00f3n de puertos de origen, lo que reduce las colisiones de puertos. Una reducci\u00f3n cautelosa de `tcp_fin_timeout` acorta determinados estados finales sin correr el riesgo de interrupciones prematuras. En configuraciones sin NAT, tcp_tw_reuse puede reducir notablemente la carga en los puertos, siempre que conozca bien el entorno y las pruebas se desarrollen sin problemas. Un valor suficientemente alto de tcp_max_tw_buckets evita el descarte agresivo, pero debe ajustarse a la capacidad de RAM disponible.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Par\u00e1metros<\/strong><\/th>\n      <th><strong>Prop\u00f3sito<\/strong><\/th>\n      <th><strong>Valor de ejemplo<\/strong><\/th>\n      <th><strong>Riesgo<\/strong><\/th>\n      <th><strong>Variable medida<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>net.ipv4.ip_local_port_range<\/td>\n      <td>Ampliar el grupo de puertos ef\u00edmeros<\/td>\n      <td>12000 65535<\/td>\n      <td>M\u00e1s abiertas <strong>Puertos<\/strong> consumen recursos del n\u00facleo<\/td>\n      <td>Puertos libres, errores de conexi\u00f3n<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_fin_timeout<\/td>\n      <td>Reducir la duraci\u00f3n de las fases FIN<\/td>\n      <td>30-45 segundos<\/td>\n      <td>Los valores demasiado bajos favorecen los abortos espont\u00e1neos<\/td>\n      <td>Retransmisiones, cuota de RST<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_tw_reuse<\/td>\n      <td>Reutilizar sockets en estado TIME_WAIT<\/td>\n      <td>1 (selectivo)<\/td>\n      <td>Es arriesgado en entornos NAT<\/td>\n      <td>Porcentaje de TIME_WAIT, \u00edndices de error<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_max_tw_buckets<\/td>\n      <td>N\u00famero m\u00e1ximo de sockets TIME_WAIT<\/td>\n      <td>Valor alto y adecuado<\/td>\n      <td>Si es demasiado peque\u00f1o, provoca distorsiones<\/td>\n      <td>Ca\u00eddas del kernel, RST<\/td>\n    <\/tr>\n    <tr>\n      <td>Opciones obsoletas (p. ej., tcp_tw_recycle)<\/td>\n      <td>Comportamientos antiguos y problem\u00e1ticos<\/td>\n      <td>Dejar desactivado<\/td>\n      <td>Bloqueos en NAT y errores leg\u00edtimos de conexi\u00f3n<\/td>\n      <td>Acumulaci\u00f3n de errores, reclamaciones de los clientes<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Buenas pr\u00e1cticas para realizar modificaciones en la pila de red<\/h2>\n\n<p>En cada paso solo cambio unos pocos <strong>Par\u00e1metros<\/strong>, para poder relacionar claramente causa y efecto. Para empezar, defino objetivos claros, como evitar el agotamiento de puertos, mantener cifras aceptables de TIME_WAIT y valores de latencia constantes. Cada cambio se aplica primero en sistemas de prueba con patrones de carga realistas y planes de reversi\u00f3n controlados. Durante la implementaci\u00f3n, correlaciono las m\u00e9tricas de red y de las aplicaciones, ya que solo la interacci\u00f3n entre ambas refleja la experiencia del usuario. Solo cuando los valores medidos resultan convincentes a lo largo de varias fases de carga, aplico los ajustes de forma permanente.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-time-wait-optimization-guide-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimizaci\u00f3n de sockets a nivel de aplicaci\u00f3n<\/h2>\n\n<p>A menudo consigo el mayor alivio a trav\u00e9s de <strong>Keep-Alive<\/strong> y la reutilizaci\u00f3n de conexiones, ya que un menor n\u00famero de nuevas conexiones genera menos TIME_WAIT. Activo HTTP Keep-Alive y elijo tiempos de inactividad adecuados, de modo que unas pocas conexiones de larga duraci\u00f3n puedan gestionar muchas solicitudes. Cuando es adecuado, utilizo HTTP\/2 o HTTP\/3 para multiplexar varias solicitudes a trav\u00e9s de unas pocas conexiones. Para los clientes de backend, trabajo con grupos de conexiones que mantienen las conexiones abiertas y las renuevan cuidadosamente. Mi enlace a <a href=\"https:\/\/webhosting.de\/es\/conexion-http-reutilizacion-keepalive-optimizacion-serverperf-boost\/\">HTTP Keep-Alive<\/a>, que utilizo sistem\u00e1ticamente para los servicios web.<\/p>\n\n<h2>Decisiones de arquitectura que mitigan el problema de TIME_WAIT<\/h2>\n\n<p>Distribuyo la carga horizontalmente para que <strong>TIME_WAIT<\/strong> no se concentren en un \u00fanico servidor y los puertos se agoten. Un mayor n\u00famero de direcciones IP o puertos de escucha adicionales aumentan el n\u00famero de combinaciones posibles de origen y destino y reducen las colisiones. Los proxies inversos situados delante del servidor de origen agrupan las conexiones de los clientes y se comunican de forma eficiente a nivel interno con los backends agrupados en un pool. Sigue siendo fundamental ajustar los valores de tiempo de espera para que los proxies, los equilibradores de carga y los backends no corten las conexiones prematuramente. Quien utilice Apache deber\u00eda <a href=\"https:\/\/webhosting.de\/es\/configuracion-optima-del-tiempo-de-espera-de-apache-keepalive-enfoque-en-el-rendimiento\/\">Tiempo de espera de Keep-Alive<\/a> adaptar cuidadosamente a los patrones de tr\u00e1fico y a las latencias.<\/p>\n\n<h2>Elecci\u00f3n del alojamiento y del servidor teniendo en cuenta el estado TIME_WAIT<\/h2>\n\n<p>Prefiero proveedores con informaci\u00f3n actualizada <strong>Linux<\/strong>-Kernel, porque las funciones TCP modernas facilitan el d\u00eda a d\u00eda. El control granular de los par\u00e1metros sysctl ahorra tiempo en el an\u00e1lisis y la implementaci\u00f3n. La supervisi\u00f3n integrada del estado de la red y de los sockets agiliza la evaluaci\u00f3n tras los cambios. Para servicios con muchas conexiones breves, merece la pena contar con un hardware de alto rendimiento y una red capaz de soportar con soltura los picos de carga. De este modo, no solo implemento las optimizaciones de TIME_WAIT, sino que tambi\u00e9n las mantengo en buen estado de funcionamiento de forma fiable.<\/p>\n\n<h2>Gu\u00eda pr\u00e1ctica: Servidores API bajo cargas puntuales<\/h2>\n\n<p>Empiezo con una vuelta de medici\u00f3n y registro <strong>Nuevas conexiones<\/strong> por segundo, el porcentaje de TIME_WAIT y las tasas de error. A continuaci\u00f3n, ampl\u00edo el rango de ip_local_port_range y reduzco con cautela el valor de tcp_fin_timeout, mientras observo las retransmisiones. En un entorno sin NAT, activo tcp_tw_reuse a modo de prueba, documento los resultados y reacciono de inmediato ante cualquier anomal\u00eda. Al mismo tiempo, me aseguro de que Keep-Alive est\u00e9 activo, de que HTTP\/2 funcione y de que la aplicaci\u00f3n utilice correctamente los grupos de conexiones. Por \u00faltimo, compruebo las tendencias de TIME_WAIT a lo largo de varias fases de picos antes de fijar los ajustes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_timewait_optimierung_5238.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Supervisi\u00f3n y funcionamiento continuo<\/h2>\n\n<p>Documento cada <strong>Enmienda<\/strong> con el valor inicial, el objetivo y el efecto observado, para poder comprobarlo r\u00e1pidamente m\u00e1s adelante. Los procesos de cambio con una estrategia clara de reversi\u00f3n protegen contra los da\u00f1os a largo plazo en caso de errores. Adem\u00e1s de TIME_WAIT, mido el RTT, las retransmisiones, el \u00abgoodput\u00bb y las tasas de error para tener una visi\u00f3n completa de la experiencia del usuario. Para las conexiones de backend de larga duraci\u00f3n, mantengo <a href=\"https:\/\/webhosting.de\/es\/tcp-keepalive-configuracion-hosting-optimizacion-serverboost\/\">TCP Keepalive<\/a> De forma coherente, para que desaparezcan las conexiones obsoletas y los recursos queden libres. As\u00ed es como acompa\u00f1o las optimizaciones en el d\u00eda a d\u00eda, en lugar de considerarlas una acci\u00f3n puntual.<\/p>\n\n<h2>\u00bfQui\u00e9n asume el tiempo de espera (TIME_WAIT)? Cierre activo frente a cierre pasivo<\/h2>\n<p>Siempre eval\u00fao qu\u00e9 parte cierra activamente la conexi\u00f3n, ya que la parte que la cierra activamente suele acabar en <strong>TIME_WAIT<\/strong>. En los clientes web cl\u00e1sicos, el cliente suele cerrarse, por lo que el servidor detecta menos casos de TIME_WAIT; en cambio, en las llamadas al backend, mi aplicaci\u00f3n es ella misma el cliente y acumula casos de TIME_WAIT. Evito el cierre activo forzado en el servidor (p. ej., SO_LINGER=0), ya que esto puede provocar RST y la p\u00e9rdida de datos. En su lugar, apuesto por <em>final elegante<\/em>, establece tiempos de espera de Keep-Alive razonables y, siempre que sea posible, deja que el cliente cierre la conexi\u00f3n primero. Esto no solo reduce el estado TIME_WAIT en el servidor, sino que tambi\u00e9n minimiza los errores provocados por cierres prematuros. Cuando establezco muchas conexiones salientes (por ejemplo, con bases de datos o servidores de nivel superior), una buena reutilizaci\u00f3n de conexiones tiene un efecto m\u00e1s inmediato que cualquier ajuste del kernel.<\/p>\n\n<h2>Dimensionar correctamente las colas de lista y de aceptaci\u00f3n<\/h2>\n<p>Me aseguro de que las conexiones entrantes no fallen antes de llegar a la aplicaci\u00f3n. Para ello, ajusto <strong>net.core.somaxconn<\/strong> y los valores de backlog de mi servidor web, para que la cola \u00abAccept\u00bb no se desborde. <strong>net.ipv4.tcp_max_syn_backlog<\/strong> Lo dimensiono en funci\u00f3n de la punta de los handshakes entrantes; unos valores demasiado bajos provocan p\u00e9rdidas ya en la fase SYN. <strong>tcp_syncookies<\/strong> Lo mantengo activado para que el sistema se mantenga estable ante picos breves, pero compruebo en pruebas de carga que el tr\u00e1fico leg\u00edtimo no se vea ralentizado. Cuando utilizo varios trabajadores, configuro <strong>SO_REUSEPORT<\/strong>, con el fin de distribuir la carga de manera uniforme entre los n\u00facleos de la CPU y reducir la contienda por el bloqueo de aceptaci\u00f3n. Estas medidas no resuelven la escasez de puertos, pero evitan interpretaciones err\u00f3neas cuando los rechazos se atribuyen err\u00f3neamente a TIME_WAIT.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_timewait_optimierung_3492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>No perder de vista NAT, el equilibrador de carga y Conntrack<\/h2>\n<p>Distingo claramente entre problemas del servidor y problemas de per\u00edmetro. Detr\u00e1s de un SNAT o un Cloud-NAT no solo puede estar el servidor, sino tambi\u00e9n la pasarela NAT con sus <em>saliente<\/em> Los puertos ef\u00edmeros se convierten en un cuello de botella. En estos casos, alivi\u00e9 la presi\u00f3n mediante direcciones IP de salida adicionales, una distribuci\u00f3n m\u00e1s precisa de los puertos o menores tasas de reconexi\u00f3n a trav\u00e9s de grupos. En los servidores perif\u00e9ricos con Linux, compruebo <strong>nf_conntrack_max<\/strong> y los tiempos de espera de TCP en Conntrack; mantener durante demasiado tiempo el seguimiento de los estados cercanos a TIME_WAIT consume memoria y puede desplazar flujos leg\u00edtimos. Solo reduzco los tiempos de espera de Conntrack con precauci\u00f3n y siempre en combinaci\u00f3n con los valores de la aplicaci\u00f3n y del n\u00facleo, para no cortar segmentos tard\u00edos. Importante: <strong>tcp_tw_reuse<\/strong> act\u00faa exclusivamente sobre las conexiones salientes del host, no sobre las entrantes en el listener, y establece <strong>tcp_timestamps=1<\/strong> Por eso, compruebo con especial minuciosidad los entornos NAT.<\/p>\n\n<h2>HTTP\/3 y UDP: \u00bfqu\u00e9 cambia?<\/h2>\n<p>Con HTTP\/3, el protocolo de transporte cambia a <strong>QUIC\/UDP<\/strong>, lo que elimina el cl\u00e1sico TCP-TIME_WAIT. Por eso, mi enfoque es diferente: en lugar de los estados TCP, observo el n\u00famero de sockets UDP, la ocupaci\u00f3n de los puertos ef\u00edmeros y las entradas de Conntrack para UDP. QUIC reduce notablemente los costes de establecimiento de conexi\u00f3n y minimiza la rotaci\u00f3n de conexiones, pero exige tiempos de espera de inactividad coherentes entre el cliente, el proxy y el origen. En entornos mixtos (H2\/H3), me aseguro de que las pol\u00edticas de Keep-Alive sean coherentes, para que las ventajas del multiplexado no se vean mermadas por tiempos de inactividad demasiado cortos.<\/p>\n\n<h2>L\u00edmites de recursos y restricciones del sistema operativo<\/h2>\n<p>Lo primero que hago es sentar unas bases s\u00f3lidas <strong>L\u00edmites de los descriptores de archivo<\/strong> un (ulimit nofile, fs.file\u2011max, fs.nr_open), ya que unos l\u00edmites demasiado estrictos generan errores secundarios que TIME_WAIT solo enmascara. Los l\u00edmites de memoria de TCP (<strong>net.ipv4.tcp_mem<\/strong>, <strong>tcp_rmem<\/strong>, <strong>tcp_wmem<\/strong>) lo configuro de tal manera que la pila no sufra \u00abpresi\u00f3n de memoria\u00bb cuando hay muchas conexiones simult\u00e1neas. Para que los puertos de servicio est\u00e9n bien separados, considero que <strong>ip_local_reserved_ports<\/strong> actualizado, para que los puertos ef\u00edmeros no entren en conflicto accidentalmente con los puertos del servidor. En las pruebas de carga, compruebo si el crecimiento de los slabs (por ejemplo, para los bloques de control de TCP) se mantiene estable; solo as\u00ed puedo evaluar si un valor m\u00e1s alto de `tcp_max_tw_buckets` es realmente viable.<\/p>\n\n<h2>Caracter\u00edsticas espec\u00edficas de los contenedores y de Kubernetes<\/h2>\n<p>En los contenedores, tengo en cuenta que los rangos de puertos ef\u00edmeros, los ulimits y los sysctls por <em>Espacio de nombres<\/em> pueden variar. Las mallas de servicios y los sidecars suelen duplicar el n\u00famero de conexiones (cliente \u2194 sidecar \u2194 proxy \u2194 backend) y, con ello, la posibilidad de que se produzcan estados TIME_WAIT; en este aspecto, obtengo los mejores resultados mediante la reutilizaci\u00f3n de conexiones y la configuraci\u00f3n adecuada de los temporizadores de inactividad. Los NodePorts y el SNAT en los workers suponen una carga adicional para las tablas de Conntrack; superviso estos valores por separado del host del pod. Bajo carga, distribuyo el tr\u00e1fico de salida entre varios nodos o utilizo puertas de enlace de salida dedicadas para evitar los puntos de congesti\u00f3n en los puertos. Lo importante es lo siguiente: si realizo ajustes en el pod, la red del host (incluidos NAT y Conntrack) debe adaptarse a ello; de lo contrario, solo estar\u00e9 trasladando el problema.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Manual de diagn\u00f3stico y valores de referencia \u00fatiles<\/h2>\n<p>Para evaluar r\u00e1pidamente la situaci\u00f3n, sigo una secuencia fija: en primer lugar, <em>ss -s<\/em> y <em>ss -tan estado tiempo de espera<\/em> En cuanto al orden de magnitud, en segundo lugar <em>\/proc\/sys\/net\/ipv4\/ip_local_port_range<\/em> Comprobar y estimar los puertos ef\u00edmeros libres; en tercer lugar, contrastar los mensajes de error y las tasas de RST en los registros de la aplicaci\u00f3n y del n\u00facleo. A continuaci\u00f3n, mido las nuevas conexiones por segundo y las correlaciono con las latencias. Como valores de referencia, tolero porcentajes elevados de TIME_WAIT siempre y cuando: no se produzca agotamiento de puertos, no se desborde la cola de aceptaci\u00f3n, las retransmisiones se mantengan estables y los tiempos de respuesta no var\u00eden. Solo doy por \u201efinalizada\u201c una optimizaci\u00f3n cuando los mismos picos de carga se repiten de forma reproducible durante varios d\u00edas sin que se produzcan anomal\u00edas.<\/p>\n\n<h2>Errores comunes y antipatrones<\/h2>\n\n<p>Evito los cortes generales de <strong>TIME_WAIT<\/strong>, ya que con ello me arriesgo a que se mezclen los datos y a que se produzcan errores espor\u00e1dicos. Reducir a ciegas los tiempos de espera castiga a los usuarios con cortes de conexi\u00f3n cuando hay mucha carga. No toco opciones obsoletas como tcp_tw_recycle, porque pueden interrumpir accesos leg\u00edtimos. El mero ajuste del n\u00facleo, sin trabajar en las aplicaciones ni en la arquitectura, sirve de poco si se producen demasiadas conexiones de corta duraci\u00f3n. Quien lo cambia todo a la vez, se impide realizar un an\u00e1lisis claro de las causas y alarga la b\u00fasqueda de errores.<\/p>\n\n<h2>Resumen compacto para administradores<\/h2>\n\n<p>Trato <strong>TIME_WAIT<\/strong> Como mecanismo de protecci\u00f3n, primero mido con precisi\u00f3n y luego optimizo paso a paso. Consigo los mejores resultados con la reutilizaci\u00f3n de conexiones mediante Keep-Alive, HTTP\/2\/3 y grupos de conexiones, junto con ajustes prudentes de sysctl. Elementos de soporte de la arquitectura como direcciones IP adicionales, proxies y escalabilidad horizontal distribuyen eficazmente la carga de las conexiones. La supervisi\u00f3n continua, una documentaci\u00f3n clara y unos objetivos bien definidos garantizan latencias constantes y puertos disponibles. De este modo, el servidor web sigue respondiendo con rapidez incluso con un tr\u00e1fico elevado, mientras que el estado TIME_WAIT funciona de forma controlada y predecible.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo optimizar de forma segura el estado \u00abtime_wait\u00bb de TCP en servidores web con una carga elevada y c\u00f3mo evitar el agotamiento de puertos mediante una optimizaci\u00f3n espec\u00edfica de Linux y los sockets.<\/p>","protected":false},"author":1,"featured_media":21208,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21215","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"178","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"TCP TIME_WAIT","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21208","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21215","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=21215"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21215\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21208"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}