{"id":21143,"date":"2026-08-29T15:03:43","date_gmt":"2026-08-29T13:03:43","guid":{"rendered":"https:\/\/webhosting.de\/linux-socket-backlog-richtig-dimensionieren-tcp-tuning-netzwerkoptimierung\/"},"modified":"2026-08-29T15:03:43","modified_gmt":"2026-08-29T13:03:43","slug":"dimensionar-correctamente-el-backlog-de-sockets-en-linux-ajuste-de-tcp-optimizacion-de-la-red","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-socket-backlog-richtig-dimensionieren-tcp-tuning-netzwerkoptimierung\/","title":{"rendered":"Dimensionar correctamente el backlog de sockets de Linux para obtener el m\u00e1ximo rendimiento de la red"},"content":{"rendered":"<p>Te voy a ense\u00f1ar concretamente c\u00f3mo... <strong>Pendientes de Linux<\/strong> dimensionar correctamente, para que las conexiones entrantes se almacenen de forma ordenada y se acepten con rapidez. As\u00ed conseguir\u00e1s una <strong>constante<\/strong> Rendimiento de la red incluso en picos de carga, sin que las solicitudes se queden colgadas ni sean rechazadas.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<p>Resumo los siguientes puntos clave a modo de introducci\u00f3n, antes de profundizar en el tema.<\/p>\n<ul>\n  <li><strong>Cola de aceptaci\u00f3n<\/strong> Dimensionar de forma espec\u00edfica; no confundir la cola SYN.<\/li>\n  <li><strong>somaxconn<\/strong> establece el l\u00edmite m\u00e1ximo estricto para la cola de espera de `listen()`.<\/li>\n  <li><strong>tcp_max_syn_backlog<\/strong> protege los \u00abhandshakes\u00bb en caso de picos de tr\u00e1fico.<\/li>\n  <li><strong>min(backlog, somaxconn)<\/strong> determina el valor efectivo.<\/li>\n  <li><strong>Monitoreo<\/strong> y las pruebas de carga determinan cada ajuste.<\/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\/linux-socket-backlog-5609.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00f3mo funciona la cola de espera de sockets de Linux<\/h2>\n\n<p>Un socket de servidor cambia con <strong>listen()<\/strong> pasa al estado de escucha y, al hacerlo, obtiene un valor de backlog que almacena en b\u00fafer las conexiones ya establecidas hasta que la aplicaci\u00f3n las libere a trav\u00e9s de <strong>accept()<\/strong> se encarga de ello. Los n\u00facleos modernos de Linux utilizan este valor exclusivamente para la cola de aceptaci\u00f3n (Accept-Queue), mientras que las conexiones semiabiertas durante el protocolo de enlace (handshake) van a parar a la cola SYN. Separo estrictamente estas dos colas para poder asignar correctamente la causa y el efecto y no ajustar los par\u00e1metros equivocados. La cola de aceptaci\u00f3n evita desbordamientos a corto plazo cuando la aplicaci\u00f3n no acepta las conexiones de inmediato, mientras que la cola SYN gestiona los handshakes durante un breve intervalo de tiempo. Quien ignore esta sem\u00e1ntica, optimiza en <strong>falso<\/strong> Lugar y desperdicia valiosas reservas.<\/p>\n\n<h2>Por qu\u00e9 elegir la talla adecuada mejora directamente el rendimiento<\/h2>\n\n<p>El tama\u00f1o de la cola determina cu\u00e1ntas sesiones completamente establecidas pueden quedar en espera de aceptaci\u00f3n, lo que <strong>Tiempo de respuesta<\/strong> influye en el establecimiento de la conexi\u00f3n. Si la cola de aceptaci\u00f3n est\u00e1 llena, el n\u00facleo rechaza los nuevos intentos o los retrasa notablemente, lo que se manifiesta en forma de errores espor\u00e1dicos y dificultades para iniciar las conexiones. A modo de aproximaci\u00f3n sencilla, se aplica lo siguiente: tasa m\u00e1xima de aceptaci\u00f3n \u2248 tama\u00f1o de la cola dividido por el tiempo de permanencia medio por entrada. Si las solicitudes se procesan en muy poco tiempo y en grandes cantidades, aumenta la importancia de contar con una cola de aceptaci\u00f3n suficientemente dimensionada. En lo que respecta a los paquetes, merece la pena fijarse en <a href=\"https:\/\/webhosting.de\/es\/servidor-colas-de-paquetes-estabilidad-de-la-red-optimizacion-del-alojamiento-latencia\/\">Colas de paquetes del servidor<\/a>, porque ah\u00ed es donde se encuentra el siguiente nivel de almacenamiento intermedio, que incluyo en el ajuste y coordino con la estrategia de trabajo pendiente.<\/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\/linux_socket_backlog_opt_8492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Par\u00e1metros del n\u00facleo: somaxconn y tcp_max_syn_backlog<\/h2>\n\n<p>Para calcular la cartera de pedidos efectiva, no solo cuenta el valor en <strong>listen()<\/strong>, ya que el n\u00facleo establece un l\u00edmite m\u00e1ximo estricto a trav\u00e9s de net.core.somaxconn. Adem\u00e1s, net.ipv4.tcp_max_syn_backlog controla el n\u00famero de handshakes semiapertos, lo cual resulta decisivo, sobre todo en picos de carga o patrones similares a los de un ataque DDoS. En la pr\u00e1ctica se aplica una regla sencilla: backlog efectivo = min(backlog, somaxconn), algo que tengo siempre presente al realizar cualquier ajuste. Los valores por defecto conservadores han resultado hist\u00f3ricamente bajos, lo que hace que los servicios web y de API modernos se vean r\u00e1pidamente afectados por cuellos de botella. Por ello, elijo somaxconn de tal forma que las conexiones aceptadas dispongan de un b\u00fafer suficiente, y ajusto tcp_max_syn_backlog adecuadamente para que los handshakes no se desborden y los clientes leg\u00edtimos puedan conectarse con rapidez.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e1metros<\/th>\n      <th>Prop\u00f3sito<\/th>\n      <th>Comprobar<\/th>\n      <th>Valores iniciales habituales<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.somaxconn<\/strong><\/td>\n      <td>L\u00edmite m\u00e1ximo para la cola de aceptaci\u00f3n y, por lo tanto, para el backlog de `listen()`<\/td>\n      <td>sysctl net.core.somaxconn<\/td>\n      <td>De 128 a 4096+, dependiendo del n\u00facleo<\/td>\n      <td>Carga de trabajo efectiva = min(carga de trabajo de la aplicaci\u00f3n, somaxconn)<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.ipv4.tcp_max_syn_backlog<\/strong><\/td>\n      <td>L\u00edmite para conexiones semiabiertas (cola SYN)<\/td>\n      <td>sysctl net.ipv4.tcp_max_syn_backlog<\/td>\n      <td>De 256 a 8192+, seg\u00fan el uso<\/td>\n      <td>Combinar con las cookies SYN para amortiguar los picos de tr\u00e1fico<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_max_backlog<\/strong><\/td>\n      <td>B\u00fafer para paquetes entrantes en la ruta SoftIRQ<\/td>\n      <td>sysctl net.core.netdev_max_backlog<\/td>\n      <td>De 1000 a 5000+, dependiendo de la tarjeta de red y la IRQ<\/td>\n      <td>Evaluar conjuntamente con los b\u00faferes de recepci\u00f3n y env\u00edo<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Valores orientativos seg\u00fan el perfil de carga y la latencia<\/h2>\n\n<p>Dimensiono la cola de aceptaci\u00f3n en funci\u00f3n del <strong>perfil de carga<\/strong> y la duraci\u00f3n media de tramitaci\u00f3n de la aplicaci\u00f3n. Para servicios de tr\u00e1fico moderado, suelen bastar valores entre 256 y 1024, mientras que las API o tiendas con mucho tr\u00e1fico se benefician de valores entre 2048 y 8192, siempre que el hardware y la arquitectura del servidor web lo permitan. Un gran n\u00famero de solicitudes breves justifica valores m\u00e1s altos, ya que hay m\u00e1s conexiones que esperan brevemente y, aun as\u00ed, se procesan con rapidez. Las sesiones de larga duraci\u00f3n requieren m\u00e1s bien un n\u00famero optimizado de trabajadores y rutas de E\/S, en lugar de colas cada vez m\u00e1s largas. Presto atenci\u00f3n a la interacci\u00f3n con los programadores de la CPU, la distribuci\u00f3n de las IRQ y la ruta de aceptaci\u00f3n del espacio de usuario, para que la cola no tenga que ser el \u00fanico recurso utilizado.<\/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\/linux-socket-backlog-netzwerk-4421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Medir la situaci\u00f3n actual e identificar los cuellos de botella<\/h2>\n\n<p>Antes de modificar los valores, mido el uso de la cola con <strong>ss<\/strong> o netstat y compruebo si hay anomal\u00edas en las colas de recepci\u00f3n y env\u00edo. Las estad\u00edsticas del n\u00facleo y los mensajes de dmesg proporcionan informaci\u00f3n sobre desbordamientos de colas, paquetes descartados o p\u00e9rdidas en el backlog, que correlaciono temporalmente con los picos de carga. Analizo los registros del servidor web y de los proxies de origen para detectar tasas de error en el establecimiento de conexiones y en los reintentos. Al mismo tiempo, observo la carga de la CPU, el equilibrio de IRQ y el comportamiento del programador, para no pasar por alto posibles cuellos de botella en otras capas. Solo cuando he comprendido la situaci\u00f3n, planifico los siguientes pasos para una soluci\u00f3n espec\u00edfica <strong>Sintonizaci\u00f3n<\/strong>.<\/p>\n\n<h2>Medici\u00f3n en profundidad: indicadores clave, patrones de error y proceso de diagn\u00f3stico<\/h2>\n<p>Para realizar un diagn\u00f3stico preciso, consulto los contadores del n\u00facleo en \/proc\/net\/netstat. En la l\u00ednea \u201eTcpExt\u201c, me interesan especialmente los valores de \u201eListenOverflows\u201c y \u00abListenDrops\u00bb (cola de aceptaci\u00f3n), as\u00ed como \u00abSyncookiesSent\u00bb y \u00abSyncookiesRecv\u00bb (fase SYN). Si aumentan los \u00abListenOverflows\u00bb, la cola de aceptaci\u00f3n es demasiado peque\u00f1a o la aplicaci\u00f3n acepta conexiones demasiado lentamente. Si aumentan los contadores de Syncookies, la cola SYN est\u00e1 saturada o el servicio est\u00e1 sufriendo patrones de tr\u00e1fico agresivos. Con el comando \u00abss -ltn\u00bb compruebo el backlog configurado actualmente por cada puerto y detecto si la aplicaci\u00f3n realmente transmite el valor deseado al n\u00facleo. Los mensajes de `dmesg` como \u00abTCP: request_sock_queue is full\u00bb indican un desbordamiento de la cola SYN, mientras que \u00abTCP: listen overflow\u00bb apunta a la cola de aceptaci\u00f3n. Sincronizo estos indicadores con las m\u00e9tricas de monitorizaci\u00f3n (latencias, tasas de error, reintentos) para poder actuar con precisi\u00f3n.<\/p>\n<p>En caso de picos de corta duraci\u00f3n, genero series temporales de alta resoluci\u00f3n. Correlaciono el nivel m\u00e1ximo de llenado de la cola de aceptaci\u00f3n con la latencia de aceptaci\u00f3n en el espacio de usuario. Opcionalmente, utilizo trazas basadas en eBPF para perfilar los tiempos de espera de \u00abAccept\u00bb y las activaciones. Esto resulta especialmente \u00fatil cuando intervienen muchos oyentes, afinidades de procesos o conflictos de bloqueo, y los efectos no pueden explicarse \u00fanicamente a trav\u00e9s de los contadores.<\/p>\n\n<h2>Optimizaci\u00f3n gradual mediante bucles de medici\u00f3n<\/h2>\n\n<p>Empiezo por documentar la situaci\u00f3n actual, anoto los valores predeterminados existentes y las caracter\u00edsticas de carga actuales en <strong>horas punta<\/strong>. A continuaci\u00f3n, aumento moderadamente el valor de somaxconn y el backlog de la aplicaci\u00f3n, en dos o tres pasos, y observo en cada caso las tasas de error, las latencias y los tiempos de aceptaci\u00f3n. A continuaci\u00f3n, compruebo tcp_max_syn_backlog y las \u00abSYN-cookies\u00bb, en caso de que los handshakes fallen antes de llegar a la cola de aceptaci\u00f3n. En cada etapa, realizo pruebas de carga reproducibles y me baso en m\u00e9tricas fijas en lugar de en corazonadas. La mejor configuraci\u00f3n se obtiene en un ciclo de medici\u00f3n en el que incorporo sistem\u00e1ticamente la informaci\u00f3n obtenida de la monitorizaci\u00f3n y el perfilado de la aplicaci\u00f3n a la siguiente <strong>Personalizaci\u00f3n<\/strong> demuestre.<\/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\/linuxsocketbacklognetzwerk5234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuraci\u00f3n de la aplicaci\u00f3n y estrategia de aceptaci\u00f3n<\/h2>\n\n<p>Compruebo la configuraci\u00f3n del backlog de los servicios del servidor, como Apache, NGINX o los servidores de aplicaciones, para que un valor predeterminado demasiado bajo no afecte a todo el <strong>cola<\/strong> limita. Algunos frameworks establecen sus propios valores o ignoran los par\u00e1metros elevados hasta que se haya configurado expl\u00edcitamente una opci\u00f3n. Cuando hay muchos n\u00facleos de CPU disponibles, ampl\u00edo el concepto mediante <a href=\"https:\/\/webhosting.de\/es\/reuseport-linux-servidor-web-optimizacion-del-rendimiento-nucleo\/\">SO_REUSEPORT<\/a>, para que varios listeners ejecuten \u00abaccept()\u00bb en paralelo en el mismo puerto. De este modo, reduzco notablemente el tiempo de aceptaci\u00f3n, lo que disminuye el tiempo medio de permanencia en la cola de aceptaci\u00f3n. Es importante que ajuste de forma sincronizada los posibles l\u00edmites de descriptores de archivo abiertos y procesos de trabajo, para que no se produzca un nuevo cuello de botella en el espacio de usuario.<\/p>\n\n<h2>Aplicaci\u00f3n pr\u00e1ctica en servidores y marcos de trabajo habituales<\/h2>\n<p>En la pr\u00e1ctica, controlo el backlog efectivo por servicio: NGINX permite especificar el backlog en el bloque \u00ablisten\u00bb; adem\u00e1s, existen los par\u00e1metros \u00abaccept_mutex\u00bb y \u00abworker_processes\u00bb, que determinan la tasa de aceptaci\u00f3n. En Apache, configuro `ListenBacklog` (por vHost\/Bind) y me aseguro de que el MPM (por ejemplo, `event`) disponga de suficientes trabajadores. En HAProxy, determino el backlog mediante opciones de `bind` y, al mismo tiempo, ajusto `tune.maxaccept` y el n\u00famero de procesos\/hilos. En las pilas de Java (Netty, Undertow, Tomcat) suele haber una propiedad \u00absoBacklog\u00bb; Node.js\/Libuv acepta un par\u00e1metro de backlog en server.listen(), que, sin una especificaci\u00f3n expl\u00edcita, suele estar por debajo de somaxconn. En Go, net.Listen o http.Server utilizan los valores predeterminados del sistema operativo; en este caso, presto especial atenci\u00f3n a que el valor de `somaxconn` sea suficiente, ya que la capa de aplicaci\u00f3n rara vez establece su propio backlog.<\/p>\n<p>Pruebo cada servicio con series de conexiones breves e intensas (por ejemplo, sin Keep-Alive) para verificar la resiliencia ante el backlog. Solo cuando el rendimiento se mantiene constante incluso en condiciones de picos de tr\u00e1fico, vuelvo a permitir tiempos de Keep-Alive m\u00e1s largos y la reutilizaci\u00f3n de conexiones en el d\u00eda a d\u00eda, con el fin de ahorrar recursos.<\/p>\n\n<h2>SO_REUSEPORT: Paralelizaci\u00f3n sin conflictos de acceso<\/h2>\n<p>Con SO_REUSEPORT distribuyo las conexiones entrantes entre varios sockets de escucha, normalmente uno por trabajador o n\u00facleo de CPU. Cada socket tiene su propia cola de aceptaci\u00f3n con su propio backlog, lo que multiplica de forma efectiva la capacidad total. Es fundamental que todos los listeners est\u00e9n configurados de forma id\u00e9ntica (mismos valores de backlog, mismas prioridades) para que el kernel realice una distribuci\u00f3n equitativa y no se produzcan desequilibrios. Superviso si alg\u00fan trabajador est\u00e1 sobrecargado o infrautilizado, y ajusto el n\u00famero de procesos o la afinidad de la CPU. En la pr\u00e1ctica, esta estrategia reduce considerablemente la contienda por los bloqueos en la ruta de aceptaci\u00f3n y minimiza las tormentas de despertares, lo que suaviza las latencias.<\/p>\n\n<h2>TCP_DEFER_ACCEPT, datos tempranos y momento de la aceptaci\u00f3n<\/h2>\n<p>Mediante TCP_DEFER_ACCEPT puedo configurar que el n\u00facleo no active la funci\u00f3n `accept()` hasta que ya hayan llegado datos de usuario. De este modo, se reduce el n\u00famero de activaciones innecesarias (clientes que se conectan pero no env\u00edan nada) y el tiempo de permanencia en la cola de aceptaci\u00f3n parece menor. Utilizo este par\u00e1metro con precauci\u00f3n, ya que los tiempos de espera a nivel de aplicaci\u00f3n, el comportamiento de los dispositivos intermedios y las pilas de los clientes pueden interactuar entre s\u00ed. Las cargas de trabajo pasivas (por ejemplo, protocolos que env\u00edan datos del servidor inicialmente) se benefician menos; por el contrario, los protocolos \u00abchatty\u00bb con env\u00edos inmediatos por parte del cliente pueden verse aliviados. Por eso, siempre compruebo c\u00f3mo afecta DEFER_ACCEPT a los reintentos, los tiempos de espera y las latencias totales antes de activarlo de forma permanente. Adem\u00e1s, solo considero la posibilidad de utilizar TCP_FASTOPEN cuando los costes del handshake son predominantes y la infraestructura lo gestiona de forma estable.<\/p>\n\n<h2>Seguridad ante picos de carga y avalanchas de paquetes SYN<\/h2>\n\n<p>Los valores elevados en la cola SYN los detecto con <strong>Cookies SYN<\/strong> que hacen que los handshakes sean m\u00e1s llevaderos cuando hay muchas conexiones a medio establecer esperando. Si detecto anomal\u00edas en la etapa de entrada, aumento el valor de tcp_max_syn_backlog en incrementos moderados y observo si los clientes leg\u00edtimos vuelven a conectarse con rapidez. A esto le a\u00f1ado l\u00edmites de tasa, estrategias de retroceso y par\u00e1metros de retransmisi\u00f3n bien definidos, para que los patrones desfavorables no provoquen efectos domin\u00f3. En el contexto, recojo indicaciones detalladas sobre c\u00f3mo defenderse eficazmente de patrones recurrentes. <a href=\"https:\/\/webhosting.de\/es\/syn-proteccion-contra-inundaciones-gestion-de-sockets-defensa-del-servidor\/\">Protecci\u00f3n contra SYN-Flood<\/a> en conjunto. Las funciones de seguridad resultan m\u00e1s \u00fatiles si las coordino con los tama\u00f1os de los backlogs, los b\u00faferes de paquetes y el rendimiento de aceptaci\u00f3n de aplicaciones, y las comparo peri\u00f3dicamente con perfiles de prueba realistas.<\/p>\n\n<h2>Optimizaci\u00f3n de la cola de tareas en el d\u00eda a d\u00eda del alojamiento web<\/h2>\n\n<p>En el alojamiento web profesional, siempre compruebo los valores del backlog junto con <strong>somaxconn<\/strong>, tcp_max_syn_backlog, el backlog de netdev y los trabajadores de la aplicaci\u00f3n. De este modo, me aseguro de que los tiempos de respuesta prometidos se mantengan incluso ante fluctuaciones en el tr\u00e1fico. Documento todos los par\u00e1metros del n\u00facleo y de los servicios para que las auditor\u00edas, las rutinas de SRE y los traspasos aporten claridad r\u00e1pidamente. El sistema de monitorizaci\u00f3n emite alertas en caso de niveles de colas, errores de recepci\u00f3n y reintentos, lo que agiliza los ajustes posteriores. Quien compare paquetes de alojamiento deber\u00eda evaluar, adem\u00e1s de la CPU y la RAM, estos detalles de red, ya que tienen un impacto notable en los costes, el \u00abtime-to-first-byte\u00bb y el \u00e9xito de <strong>Sesiones<\/strong> tener.<\/p>\n\n<h2>Evite los errores t\u00edpicos<\/h2>\n\n<p>Un error muy com\u00fan: solo aumento la lista de tareas pendientes de la aplicaci\u00f3n, pero <strong>somaxconn<\/strong> demasiado peque\u00f1o, por lo que el l\u00edmite m\u00e1ximo efectivo permanece sin cambios. Igualmente enga\u00f1oso es confundir la cola \u00abAccept\u00bb con la \u00abSYN\u00bb, lo que da lugar a correcciones err\u00f3neas. Los valores extremadamente altos sin una estrategia clara ocultan las deficiencias de la aplicaci\u00f3n, consumen memoria y dificultan el an\u00e1lisis de las causas. Si accept() no gestiona las conexiones con la suficiente rapidez, la cola permanece llena a pesar de los grandes n\u00fameros y los clientes siguen esperando. Por lo tanto, primero compruebo la ruta del espacio de usuario, minimizo la contienda por los bloqueos, distribuyo el trabajo entre los n\u00facleos y, a continuaci\u00f3n, calibro los tama\u00f1os del backlog. <strong>Dirigido a<\/strong>.<\/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\/linux-backlog-serverraum-9472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Contenedores, m\u00e1quinas virtuales y orquestaci\u00f3n<\/h2>\n<p>En entornos virtualizados y contenedores, el backlog efectivo depende del n\u00facleo del host. Si configuro `somaxconn` en el contenedor, el host debe permitirlo y mantenerlo de forma persistente. En Kubernetes, activo expl\u00edcitamente los sysctls necesarios y me aseguro de que las pol\u00edticas de seguridad lo permitan. Adem\u00e1s, compruebo los valores de ulimit (nofile) y los l\u00edmites de cgroup para garantizar que se puedan abrir muchos sockets simult\u00e1neos. Si hay un controlador de Ingress o un NodePort delante, dimensiono su lista de espera (listen backlog) al igual que la de la propia aplicaci\u00f3n, para que el primer salto no se convierta en el cuello de botella. Lo mismo se aplica a los equilibradores de carga de capa 3\/4 o a los proxies: cada nivel tiene sus propias colas, que analizo de forma conjunta.<\/p>\n\n<h2>Planificaci\u00f3n de la capacidad: ejemplos de c\u00e1lculo para el volumen de pedidos pendientes<\/h2>\n<p>Realizo el dimensionamiento en tres pasos: (1) determinar la tasa m\u00e1xima de llegada (conexiones por segundo) en los picos; (2) medir la latencia media de aceptaci\u00f3n de la aplicaci\u00f3n; (3) prever un margen de seguridad. Ejemplo: si se produce un pico de 10 000 conexiones por segundo y el tiempo medio desde la llegada hasta la funci\u00f3n accept() es de 3 ms, entonces hay que almacenar temporalmente una media de 10 000 \u00d7 0,003 = 30 conexiones. Para los picos y las fluctuaciones en la distribuci\u00f3n, elijo un factor de 5 a 10, es decir, de 150 a 300. Si, adem\u00e1s, planifico varios listeners mediante SO_REUSEPORT, la capacidad se adapta proporcionalmente al n\u00famero de listeners. Para peticiones muy breves (p. ej., de 5 a 20 ms), realizo c\u00e1lculos m\u00e1s conservadores, ya que predominan las fluctuaciones estad\u00edsticas. En el caso de sesiones de larga duraci\u00f3n, doy prioridad al n\u00famero de trabajadores, al escalado de epoll y a las rutas de E\/S antes de seguir aumentando los backlogs.<\/p>\n<p>Adem\u00e1s, calculo las necesidades de memoria: cada entrada de la cola de aceptaci\u00f3n ocupa espacio en las estructuras del n\u00facleo. Por lo tanto, solo tiene sentido establecer valores muy altos si la memoria RAM disponible, los descriptores de archivo y los procesos del espacio de usuario pueden seguir el ritmo. El objetivo no es disponer de un b\u00fafer lo m\u00e1s grande posible, sino de uno lo suficientemente grande como para suavizar los picos sin sobrecargar otros recursos.<\/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\/linuxsocketbacklog1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gesti\u00f3n de cambios, persistencia y reversi\u00f3n<\/h2>\n<p>Separo las pruebas del entorno de producci\u00f3n: primero realizo los ajustes en un entorno de staging con perfiles de carga representativos y, a continuaci\u00f3n, los implemento gradualmente en producci\u00f3n. Escribo los par\u00e1metros del kernel en archivos sysctl.d espec\u00edficos, los documento indicando su finalidad y la fecha, y compruebo su eficacia tras el reinicio. Establezco los backlogs de los servicios en el archivo de configuraci\u00f3n correspondiente y los protejo mediante la gesti\u00f3n de la configuraci\u00f3n para evitar desviaciones. Para los sistemas cr\u00edticos, establezco una ventana de reversi\u00f3n y, tras el despliegue, superviso de cerca los desbordamientos de listas, las latencias de aceptaci\u00f3n y las tasas de error. Si se observan efectos secundarios (por ejemplo, un aumento de la carga de memoria o la saturaci\u00f3n de subprocesos), retrocedo un paso y abordo primero el nuevo cuello de botella.<\/p>\n\n<h2>Herramientas y rutinas operativas<\/h2>\n<p>En mis rutinas de funcionamiento, dispongo de un peque\u00f1o conjunto de herramientas fiables: ss\/netstat para visualizar los sockets en escucha y los valores actuales de backlog, sysctl para la configuraci\u00f3n de par\u00e1metros, journalctl\/dmesg para consultar los mensajes del kernel, y una herramienta de pruebas de carga capaz de generar picos de forma breve, repetible y cuantificable. Adem\u00e1s, utilizo exportadores de procesos que registran el tiempo de aceptaci\u00f3n y los niveles de llenado de las colas, as\u00ed como perfiles del sistema (perf, eBPF) para profundizar en la ruta de aceptaci\u00f3n cuando es necesario. La monitorizaci\u00f3n recopila histogramas de las latencias en el establecimiento de conexiones, de modo que no solo veo valores medios, sino tambi\u00e9n distribuciones y los percentiles P95\/P99 \u2014que es precisamente donde se esconden los s\u00edntomas de colas demasiado peque\u00f1as\u2014.<\/p>\n\n<h2>Lista de comprobaci\u00f3n para la puesta en pr\u00e1ctica<\/h2>\n<ul>\n  <li>Recopilar el perfil de carga: Conn\/s, amplitud de r\u00e1faga, latencia de aceptaci\u00f3n, tasa de Keep-Alive.<\/li>\n  <li>Documentar los valores reales: somaxconn, tcp_max_syn_backlog, netdev-backlog, backlogs de servicios, nofile.<\/li>\n  <li>Comprobar los contadores del n\u00facleo: desbordamientos y p\u00e9rdidas de listas, contadores de Syncookies, mensajes de dmesg.<\/li>\n  <li>Aumentar el backlog de forma gradual: sincronizar la aplicaci\u00f3n y somaxconn, con bucles de medici\u00f3n en cada etapa.<\/li>\n  <li>Proteger la fase SYN: aumentar moderadamente el valor de tcp_max_syn_backlog, activar las \u00abSYN-cookies\u00bb y realizar un seguimiento.<\/li>\n  <li>Paralelizaci\u00f3n: utilizar SO_REUSEPORT, calibrar los trabajadores y las afinidades.<\/li>\n  <li>Supervisi\u00f3n de la ruta de los paquetes: ajustar el backlog de netdev, el equilibrio de IRQ y los b\u00faferes de recepci\u00f3n\/env\u00edo.<\/li>\n  <li>Persistencia y reversi\u00f3n: sysctl.d, gesti\u00f3n de versiones, implementaci\u00f3n por fases, telemetr\u00eda bajo control.<\/li>\n<\/ul>\n\n<h2>Resumen para una aplicaci\u00f3n r\u00e1pida<\/h2>\n\n<p>Dimensiono el backlog de forma pragm\u00e1tica: primero mido, luego <strong>personalizar<\/strong>, y despu\u00e9s volver a medir. Para muchos servidores web y de API, unos valores de 2048 a 8192 para \u00absomaxconn\u00bb, junto con la configuraci\u00f3n adecuada de la aplicaci\u00f3n, suponen un nivel inicial viable, que compruebo mediante pruebas de carga. En caso de picos de handshake, aumento tcp_max_syn_backlog por etapas y activo las \u00abSYN-cookies\u00bb para que los clientes leg\u00edtimos no se vean ralentizados. Paralelamente, me ocupo del backlog de netdev, los b\u00faferes de recepci\u00f3n y env\u00edo, el equilibrio de IRQ y la estrategia de aceptaci\u00f3n en el espacio de usuario. De este modo, mantengo bajo control el establecimiento de conexiones, el tiempo de respuesta y las tasas de error, y aprovecho el <strong>Pendientes de Linux<\/strong> como herramienta eficaz para garantizar un rendimiento constante de la red.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprende a dimensionar correctamente el backlog de sockets de Linux y a mejorar de forma sostenible el rendimiento de red de tus servidores mediante un ajuste espec\u00edfico del protocolo TCP.<\/p>","protected":false},"author":1,"featured_media":21136,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21143","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":"149","_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":"Linux Backlog","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":"21136","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21143","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=21143"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21143\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21136"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}