{"id":18833,"date":"2026-04-08T11:49:31","date_gmt":"2026-04-08T09:49:31","guid":{"rendered":"https:\/\/webhosting.de\/tcp-keepalive-einstellungen-hosting-optimierung-serverboost\/"},"modified":"2026-04-08T11:49:31","modified_gmt":"2026-04-08T09:49:31","slug":"definicoes-de-tcp-keepalive-alojamento-otimizacao-serverboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/tcp-keepalive-einstellungen-hosting-optimierung-serverboost\/","title":{"rendered":"Defini\u00e7\u00f5es do TCP Keepalive: Otimiza\u00e7\u00e3o no contexto do alojamento"},"content":{"rendered":"<p><strong>TCP Keepalive<\/strong> determina a rapidez com que um servidor reconhece e termina as sess\u00f5es TCP inactivas - uma alavanca de controlo que tem um impacto direto no consumo de recursos, na lat\u00eancia e no comportamento do tempo de inatividade no alojamento. Com valores adequados de inatividade, intervalo e sonda, reduzo os pontos mortos de liga\u00e7\u00e3o, evito quedas de NAT e mantenho as aplica\u00e7\u00f5es Web em <strong>Configura\u00e7\u00f5es de alojamento<\/strong> acess\u00edvel de forma fi\u00e1vel.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>Par\u00e2metros<\/strong>Definir sondas inactivas, de intervalo, de forma direcionada<\/li>\n  <li><strong>Demarca\u00e7\u00e3o<\/strong>TCP Keepalive vs. HTTP Keep-Alive<\/li>\n  <li><strong>Por tomada<\/strong>Substitui\u00e7\u00f5es por servi\u00e7o\/pod do Kubernetes<\/li>\n  <li><strong>Firewall\/NAT<\/strong>Tempo de inatividade: considerar ativamente os tempos de inatividade<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong>Medi\u00e7\u00e3o, testes de carga, afina\u00e7\u00e3o iterativa<\/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\/04\/server-tcp-settings-1283.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como funciona o TCP Keepalive<\/h2>\n\n<p>Eu ativo <strong>Manter vivo<\/strong> a n\u00edvel da tomada ou do sistema, de modo a que a pilha envie pequenas sondas a intervalos definidos quando inativa. Ap\u00f3s um tempo de espera ajust\u00e1vel (inativo), o sistema envia a primeira verifica\u00e7\u00e3o; seguem-se outras sondas no intervalo definido at\u00e9 ser atingido o n\u00famero de tentativas. Se a esta\u00e7\u00e3o remota permanecer muda, termino a liga\u00e7\u00e3o e devolvo os descritores de ficheiros e os buffers no ficheiro <strong>Kernel<\/strong> livre. A l\u00f3gica \u00e9 claramente diferente da das retransmiss\u00f5es, porque o Keepalive verifica o estado de vivacidade de um fluxo que, de outra forma, estaria inativo. Particularmente em ambientes de alojamento com muitas sess\u00f5es simult\u00e2neas, este comportamento evita fugas de informa\u00e7\u00e3o que, de outra forma, eu s\u00f3 notaria em situa\u00e7\u00f5es de elevada vivacidade. <strong>Carga<\/strong> sentir.<\/p>\n\n<h2>Porque \u00e9 que o Keepalive conta no alojamento<\/h2>\n\n<p>Clientes com falhas, redes m\u00f3veis e gateways NAT agressivos deixam muitas vezes para tr\u00e1s <strong>Liga\u00e7\u00f5es de zombies<\/strong>, que permanecem abertos durante muito tempo sem keepalive. Isso custa soquetes abertos, RAM e CPU em processos de aceita\u00e7\u00e3o, trabalho e proxy, o que aumenta o tempo de resposta. Eu uso valores adequados para remover esses corpos mortos logo no in\u00edcio e manter ouvintes, backends e upstreams abertos. <strong>reativo<\/strong>. O efeito \u00e9 particularmente not\u00f3rio durante os picos de carga, porque menos liga\u00e7\u00f5es mortas enchem as filas de espera. Por isso, planeio o Keepalive juntamente com os timeouts HTTP e TLS e asseguro um <strong>harmonioso<\/strong> Intera\u00e7\u00e3o em todos os n\u00edveis.<\/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\/04\/tcp_keepalive_optimierung_3746.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Par\u00e2metros Sysctl: valores pr\u00e1ticos<\/h2>\n\n<p>O Linux fornece valores padr\u00e3o muito longos que s\u00e3o usados em <strong>Ambientes de alojamento<\/strong> raramente servem. Para os servidores Web, costumo definir um tempo de inatividade muito mais curto, de modo a eliminar atempadamente as sess\u00f5es pendentes. Mantenho o intervalo entre sondas moderado, de modo a reconhecer rapidamente as falhas, mas sem inundar a rede com verifica\u00e7\u00f5es. Equilibro o n\u00famero de sondas entre os falsos alarmes e o tempo de dete\u00e7\u00e3o; menos sondas encurtam o tempo at\u00e9 que o <strong>Recursos<\/strong>. Para o IPv6, presto aten\u00e7\u00e3o \u00e0s respectivas vari\u00e1veis net.ipv6 e mantenho ambos os protocolos consistentes.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Par\u00e2metros<\/strong><\/th>\n      <th>Padr\u00e3o (Linux)<\/th>\n      <th>Recomenda\u00e7\u00e3o de alojamento<\/th>\n      <th>Benef\u00edcio<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>tcp_keepalive_time<\/strong><\/td>\n      <td>7200s<\/td>\n      <td>600-1800s<\/td>\n      <td>Quando a primeira amostra \u00e9 enviada ap\u00f3s o modo inativo<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_keepalive_intvl<\/strong><\/td>\n      <td>75s<\/td>\n      <td>10-60s<\/td>\n      <td>Dist\u00e2ncia entre sondas individuais<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>tcp_keepalive_probes<\/strong><\/td>\n      <td>9<\/td>\n      <td>3-6<\/td>\n      <td>M\u00e1ximo de tentativas falhadas antes de fechar<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Eu defino os valores base em todo o sistema e aplico-os permanentemente via sysctl para que as reinicializa\u00e7\u00f5es n\u00e3o descartem o trabalho de ajuste. Al\u00e9m disso, eu documento os valores iniciais e me\u00e7o os efeitos em <strong>Taxas de erro<\/strong> e lat\u00eancias. Isto permite-me manter um equil\u00edbrio entre a dete\u00e7\u00e3o r\u00e1pida e o tr\u00e1fego de rede adicional. Costumo usar as seguintes linhas como ponto de partida e ajust\u00e1-las posteriormente para cada carga de trabalho:<\/p>\n\n<pre><code>net.ipv4.tcp_keepalive_time = 600\nnet.ipv4.tcp_keepalive_intvl = 60\nnet.ipv4.tcp_keepalive_probes = 5\nsysctl -p\n<\/code><\/pre>\n\n<h2>Ajuste por socket e plataforma<\/h2>\n\n<p>As predefini\u00e7\u00f5es globais raramente s\u00e3o suficientes para mim; defino por servi\u00e7o <strong>Por tomada<\/strong>-para que backends sens\u00edveis vivam mais tempo enquanto frontends limpam rapidamente. Em Python, Go ou Java, defino SO_KEEPALIVE e as op\u00e7\u00f5es TCP espec\u00edficas diretamente no socket. No Linux, controlo atrav\u00e9s de TCP_KEEPIDLE, TCP_KEEPINTVL e TCP_KEEPCNT, enquanto o Windows funciona atrav\u00e9s de chaves de registo (KeepAliveTime, KeepAliveInterval). No Kubernetes, substituo as configura\u00e7\u00f5es em uma base espec\u00edfica de pod ou implanta\u00e7\u00e3o para tratar gateways de API de curta dura\u00e7\u00e3o de maneira diferente dos de longa dura\u00e7\u00e3o <strong>Base de dados<\/strong>-proxies. Para configura\u00e7\u00f5es de contentores, tamb\u00e9m verifico as tabelas NAT do anfitri\u00e3o e os plug-ins CNI porque os fluxos inactivos s\u00e3o frequentemente removidos mais cedo do que eu gostaria.<\/p>\n\n<pre><code>Exemplo # (Python, Linux)\nimportar socket\nsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\nsock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)\nsock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 60)\nsock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 30)\nsock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 5)\n<\/code><\/pre>\n\n<h2>HTTP Keep-Alive vs. TCP Keepalive<\/h2>\n\n<p>O HTTP Keep-Alive mant\u00e9m as liga\u00e7\u00f5es abertas para v\u00e1rios pedidos, enquanto o <strong>TCP<\/strong> O Keepalive fornece verifica\u00e7\u00f5es puras de vivacidade ao n\u00edvel do transporte. Ambos os mecanismos se complementam, mas funcionam com objectivos e temporizadores diferentes. Em HTTP\/2 e HTTP\/3, os quadros PING assumem parcialmente o papel do Keepalive, mas continuo a proteger adicionalmente a camada TCP. Defino o timeout HTTP de acordo com a vis\u00e3o da aplica\u00e7\u00e3o, enquanto defino os valores TCP com base no lan\u00e7amento econ\u00f3mico de <strong>Recursos<\/strong> alinhar. Se quiser saber mais pormenores sobre a p\u00e1gina HTTP, pode encontrar um guia \u00fatil em <a href=\"https:\/\/webhosting.de\/pt\/http-keepalive-timeout-configuracao-do-desempenho-do-servidor\/\">Tempo limite do HTTP Keep-Alive<\/a>.<\/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\/04\/tcp-keepalive-optimization-6738.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Afina\u00e7\u00e3o do tempo limite da rede: pr\u00e1tica<\/h2>\n\n<p>Para front-ends cl\u00e1ssicos de alojamento web, trabalho frequentemente com 300s de inatividade, 30-45s de intervalo e 4-6 sondas para terminar sess\u00f5es inactivas rapidamente e <strong>Filas de espera<\/strong> magra. As liga\u00e7\u00f5es \u00e0 base de dados t\u00eam mais paci\u00eancia para que as fases de ocupa\u00e7\u00e3o curtas n\u00e3o provoquem desligamentos desnecess\u00e1rios. Nos gateways de ponta ou de API, tamb\u00e9m reduzo os tempos de espera porque h\u00e1 muitas liga\u00e7\u00f5es de curta dura\u00e7\u00e3o. Harmonizo os valores com os tempos limite do aperto de m\u00e3o TLS, os tempos limite de leitura\/escrita e os limites de tempo a montante, para que n\u00e3o haja contradi\u00e7\u00f5es nos limites das camadas. Para uma otimiza\u00e7\u00e3o passo-a-passo, \u00e9 necess\u00e1rio um <a href=\"https:\/\/webhosting.de\/pt\/http-keep-alive-ajuste-otimizacao-do-desempenho-da-carga-do-servidor-fluxo\/\">Fluxo de afina\u00e7\u00e3o<\/a>, que utilizo nas janelas de manuten\u00e7\u00e3o.<\/p>\n\n<h2>Tempo limite de inatividade da firewall, NAT e nuvem<\/h2>\n\n<p>Muitas firewalls e gateways NAT cortam os fluxos inactivos ap\u00f3s 300-900 segundos, raz\u00e3o pela qual eu <strong>Manter vivo<\/strong> para que o meu intervalo seja inferior a este. Caso contr\u00e1rio, a aplica\u00e7\u00e3o n\u00e3o reconhecer\u00e1 o t\u00e9rmino at\u00e9 o pr\u00f3ximo pedido e causar\u00e1 novas tentativas desnecess\u00e1rias. Em balanceadores de carga na nuvem, verifico os par\u00e2metros TCP ou de conex\u00e3o ociosa e comparo-os com os valores de sysctl e proxy. Em configura\u00e7\u00f5es anycast ou multi-AZ, verifico se as altera\u00e7\u00f5es de caminho conduzem a esta\u00e7\u00f5es remotas aparentemente mortas e aumento especificamente o n\u00famero de amostras para estas zonas. Eu documento a cadeia de cliente, proxy, firewall e backend para que eu possa <strong>Causas<\/strong> para gotas rapidamente.<\/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\/04\/tcp_keepalive_optimierung_4893.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Integra\u00e7\u00e3o na configura\u00e7\u00e3o do servidor Web<\/h2>\n\n<p>O Apache, o Nginx e o HAProxy organizam a persist\u00eancia HTTP a n\u00edvel da aplica\u00e7\u00e3o, enquanto o sistema operativo <strong>TCP<\/strong> O Keepalive cumpre. No Apache, ligo o KeepAlive, limito os KeepAliveRequests e mantenho o KeepAliveTimeout curto para que os trabalhadores sejam libertados prontamente. Utilizo o Nginx com um keepalive_timeout curto e keepalive_requests moderados para uma reutiliza\u00e7\u00e3o eficiente. No HAProxy, uso op\u00e7\u00f5es de soquete como tcpka ou padr\u00f5es do lado do sistema para que os tempos limite de transporte correspondam \u00e0 pol\u00edtica de proxy. Para aspectos mais aprofundados do servidor web, o <a href=\"https:\/\/webhosting.de\/pt\/guia-de-otimizacao-do-desempenho-do-servidor-web-keep-alive\/\">Guia de afina\u00e7\u00e3o do servidor Web<\/a>, que combino com as minhas personaliza\u00e7\u00f5es TCP.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o, testes e m\u00e9tricas<\/h2>\n\n<p>Me\u00e7o o efeito de cada ajustamento e n\u00e3o me baseio em <strong>Pressentimento<\/strong>. ss, netstat e lsof mostram-me quantas liga\u00e7\u00f5es ESTABLISHED, FIN_WAIT e TIME_WAIT est\u00e3o presentes e se as fugas est\u00e3o a aumentar. Nas m\u00e9tricas, monitorizo aborts, RSTs, retransmiss\u00f5es, lat\u00eancia P95\/P99 e comprimentos de fila; se um valor atinge os seus limites, vou especificamente para Idle, Interval ou Probes. Utilizo testes de carga sint\u00e9ticos (por exemplo, ab, wrk, Locust) para simular padr\u00f5es de utiliza\u00e7\u00e3o reais e verificar se a afina\u00e7\u00e3o cumpre as m\u00e9tricas pretendidas. Aplico as altera\u00e7\u00f5es por fases e comparo as s\u00e9ries cronol\u00f3gicas antes de <strong>global<\/strong> Distribuir as predefini\u00e7\u00f5es por todos os anfitri\u00f5es.<\/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\/04\/tcp_keepalive_0815.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Imagens de erros e resolu\u00e7\u00e3o de problemas<\/h2>\n\n<p>Se definir intervalos demasiado curtos, inflaciono o <strong>Tr\u00e1fego de rede<\/strong> e aumentam o risco de as falhas tempor\u00e1rias serem interpretadas como falhas. Se houver muito poucas sondas, fecho as liga\u00e7\u00f5es activas em redes lentas, o que os utilizadores encontram como uma mensagem de erro espor\u00e1dica. Os tempos de inatividade demasiado longos, por outro lado, levam ao congestionamento de sockets e a crescentes atrasos na aceita\u00e7\u00e3o. Verifico os registos de RST do cliente\/servidor, ECONNRESET e ETIMEDOUT para reconhecer a dire\u00e7\u00e3o. Se afetar principalmente os utilizadores m\u00f3veis, ajusto as sondas e os intervalos, porque h\u00e1 <strong>Pontos mortos<\/strong> e os problemas de sono ocorrem com mais frequ\u00eancia.<\/p>\n\n<h2>Predefini\u00e7\u00f5es seguras para v\u00e1rias cargas de trabalho<\/h2>\n\n<p>Come\u00e7o com valores conservadores que s\u00e3o adequados para a produ\u00e7\u00e3o e aperfei\u00e7oo-os depois de medir o <strong>Carga de trabalho<\/strong>. As APIs da Web geralmente exigem tempos de inatividade curtos, as bases de dados s\u00e3o significativamente mais longas. Os proxies entre zonas ou fornecedores beneficiam de um pouco mais de sondas para lidar com a flutua\u00e7\u00e3o do caminho. Para aplica\u00e7\u00f5es interactivas, reduzo o intervalo e aumento o n\u00famero de sondas de modo a detetar erros mais rapidamente, mas sem os fechar prematuramente. A tabela d\u00e1-me uma orienta\u00e7\u00e3o compacta, que ajusto durante a opera\u00e7\u00e3o.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Tipo de servidor<\/strong><\/th>\n      <th>Inativo<\/th>\n      <th>Intervalo<\/th>\n      <th>Provas<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>Frontend de alojamento Web<\/strong><\/td>\n      <td>300-600s<\/td>\n      <td>30-45s<\/td>\n      <td>4-6<\/td>\n      <td>Sess\u00f5es curtas, volume elevado<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>gateway de API<\/strong><\/td>\n      <td>180-300s<\/td>\n      <td>20-30s<\/td>\n      <td>5-6<\/td>\n      <td>Muitas fases de inatividade, desaparecem rapidamente<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Proxy de base de dados<\/strong><\/td>\n      <td>900-1800s<\/td>\n      <td>45-60s<\/td>\n      <td>3-5<\/td>\n      <td>Estabelecer uma liga\u00e7\u00e3o \u00e9 dispendioso, \u00e9 preciso ter paci\u00eancia<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Pod Kubernetes<\/strong><\/td>\n      <td>600-900s<\/td>\n      <td>30-45s<\/td>\n      <td>4\u20135<\/td>\n      <td>Sincronizar com os tempos limite do CNI\/LB<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/04\/tcp-setup-9182.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>TCP_USER_TIMEOUT e backoff de retransmiss\u00e3o<\/h2>\n<p>Para al\u00e9m do Keepalive, utilizo especificamente o seguinte para liga\u00e7\u00f5es de transporte de dados <strong>TCP_USER_TIMEOUT<\/strong>, para controlar quanto tempo os dados n\u00e3o confirmados podem permanecer no soquete antes que a conex\u00e3o seja ativamente cancelada. Isto \u00e9 particularmente importante para proxies e APIs, que n\u00e3o devem passar por cabides durante minutos a fio. Em contraste com o Keepalive (que verifica a vivacidade durante a inatividade), o TCP_USER_TIMEOUT tem efeito quando os dados est\u00e3o a fluir mas n\u00e3o s\u00e3o devolvidos ACKs - por exemplo, no caso de falhas assim\u00e9tricas. Eu defino-o <em>por tomada<\/em> ligeiramente abaixo dos tempos limite de leitura\/escrita da aplica\u00e7\u00e3o, para que o n\u00edvel de transporte n\u00e3o espere mais tempo do que a l\u00f3gica da aplica\u00e7\u00e3o em caso de erro.<\/p>\n\n<pre><code>Exemplo # (Go, Linux) - Keepalive e TCP_USER_TIMEOUT\nd := net.Dialer{\n    Timeout: 5 * time.Second,\n    KeepAlive: 30 * time.Second,\n    Controlo: func(rede, endere\u00e7o string, c syscall.RawConn) erro {\n        var err erro\n        c.Controlo(func(fd uintptr) {\n            \/\/ S\u00e3o permitidos 20s de dados n\u00e3o confirmados\n            err = syscall.SetsockoptInt(int(fd), syscall.IPPROTO_TCP, 0x12, 20000) \/\/ TCP_USER_TIMEOUT\n        })\n        return err\n    },\n}\nconn, _ := d.Dial(\"tcp\", \"example:443\")\n<\/code><\/pre>\n\n<p>N\u00e3o estou a esquecer que o backoff TCP (extens\u00e3o RTO) e as tentativas (<strong>tcp_retries2<\/strong>) tamb\u00e9m influenciam o comportamento em caso de perda de pacotes. Os tempos limite do utilizador demasiado curtos podem levar a desist\u00eancias em redes dif\u00edceis, mesmo que a esta\u00e7\u00e3o remota esteja acess\u00edvel. Por isso, s\u00f3 os defino com rigor quando pretendo deliberadamente uma dete\u00e7\u00e3o r\u00e1pida de erros (por exemplo, no proxy de extremo).<\/p>\n\n<h2>IPv6 e carater\u00edsticas do sistema operativo<\/h2>\n<p>As mesmas op\u00e7\u00f5es por socket (TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT) aplicam-se ao IPv6. Dependendo da vers\u00e3o do kernel, os padr\u00f5es globais para v4 e v6 se aplicam juntos; eu verifico isso com <code>ss -o<\/code> para conex\u00f5es reais. No Windows, eu personalizo as predefini\u00e7\u00f5es atrav\u00e9s do registo (KeepAliveTime, KeepAliveInterval) e uso SIO_KEEPALIVE_VALS para sockets individuais. As op\u00e7\u00f5es s\u00e3o por vezes chamadas de forma diferente nos derivados do BSD, mas a sem\u00e2ntica permanece a mesma. \u00c9 importante verificar para cada plataforma se as substitui\u00e7\u00f5es de aplicativos realmente superam os padr\u00f5es do sistema e se os tempos de execu\u00e7\u00e3o do cont\u00eainer herdam os namespaces corretamente.<\/p>\n\n<h2>WebSockets, gRPC e streaming<\/h2>\n<p>Fluxos de longa dura\u00e7\u00e3o (WebSocket, gRPC, eventos enviados pelo servidor) se beneficiam particularmente de keepalives bem dosados. Eu come\u00e7o em dois n\u00edveis: A aplica\u00e7\u00e3o envia pings\/PONGs peri\u00f3dicos (por exemplo, n\u00edvel WebSocket), enquanto a camada TCP protege com intervalos moderados. Isso evita que os NATs removam silenciosamente os fluxos. Para os clientes m\u00f3veis, aumento o n\u00famero de sondas e selecciono intervalos mais longos para ter em conta os modos de poupan\u00e7a de energia. Para o gRPC\/HTTP-2, coordeno os PINGs HTTP\/2 com o TCP Keepalive para n\u00e3o sondar duas vezes de forma demasiado agressiva e esgotar as baterias.<\/p>\n\n<h2>Tabelas Conntrack, kernel e NAT<\/h2>\n<p>Nos anfitri\u00f5es Linux com rastreio de liga\u00e7\u00e3o ativo, uma liga\u00e7\u00e3o demasiado curta <strong>nf_conntrack<\/strong>-O tempo limite pode levar a uma queda precoce - mesmo que a aplica\u00e7\u00e3o pense mais tempo. Por isso, sincronizo os temporizadores relevantes (por exemplo. <em>nf_conntrack_tcp_timeout_established<\/em>) com meus intervalos de keepalive para que uma amostra chegue com seguran\u00e7a antes do prazo final do conntrack. Em n\u00f3s com NAT forte (NodePort, NAT de sa\u00edda) eu planejo o tamanho da tabela conntrack e os baldes de hash para evitar press\u00e3o global sob carga. Configura\u00e7\u00f5es limpas de keepalive aliviam essas tabelas de forma mensur\u00e1vel.<\/p>\n\n<h2>Exemplo: Unidades de servidor proxy e web<\/h2>\n<p>No HAProxy, ativo especificamente o keepalive do lado do transporte e mantenho os tempos limite HTTP consistentes:<\/p>\n<pre><code>Extrato # (HAProxy)\npredefini\u00e7\u00f5es\n  tempo limite do cliente 60s\n  timeout servidor 60s\n  tempo limite de liga\u00e7\u00e3o 5s\n  op\u00e7\u00e3o http-keep-alive\n  option tcpka # Ativar TCP keepalive (utilizar as predefini\u00e7\u00f5es do SO)\n\naplica\u00e7\u00e3o backend\n  servidor s1 10.0.0.10:8080 check inter 2s fall 3 rise 2\n<\/code><\/pre>\n<p>No Nginx, penso que a reutiliza\u00e7\u00e3o \u00e9 eficiente sem sobrecarregar os trabalhadores:<\/p>\n<pre><code>Excerto do # (Nginx)\nkeepalive_timeout 30s;\nkeepalive_requests 1000;\nproxy_read_timeout 60s;\nproxy_send_timeout 60s;\n<\/code><\/pre>\n<p>Certifico-me de que os tempos limite do transporte e da aplica\u00e7\u00e3o se encaixam logicamente: A preven\u00e7\u00e3o de \u201elinhas mortas\u201c \u00e9 a tarefa do TCP\/Keepalive, enquanto os tempos limite da aplica\u00e7\u00e3o mapeiam a l\u00f3gica empresarial e as expectativas do utilizador.<\/p>\n\n<h2>Observabilidade na pr\u00e1tica<\/h2>\n<p>Verifico o funcionamento do Keepalive em direto no anfitri\u00e3o:<\/p>\n<ul>\n  <li><strong>ss<\/strong>: <code>ss -tin 'sport = :443'<\/code> espect\u00e1culos com <code>-o<\/code> o temporizador (por exemplo. <em>timer:(keepalive,30sec,0)<\/em>), n\u00famero de tentativas e Q de envio\/recebimento.<\/li>\n  <li><strong>tcpdump<\/strong>Filtro uma liga\u00e7\u00e3o inativa e vejo pequenos pacotes\/ACKs peri\u00f3dicos durante as fases de inatividade. Isto permite-me reconhecer se as sondas activam o NAT a tempo.<\/li>\n  <li><strong>Registos\/M\u00e9tricas<\/strong>Correlaciono os picos de RST\/timeout com as altera\u00e7\u00f5es de inatividade\/intervalo\/sondas. Uma queda nos sockets abertos com carga constante mostra que a arruma\u00e7\u00e3o foi bem sucedida.<\/li>\n<\/ul>\n<p>Para testes reproduz\u00edveis, simulo falhas de liga\u00e7\u00e3o (por exemplo, interface em baixo, iptables DROP) e observo a rapidez com que os trabalhadores\/processos libertam recursos e se as tentativas funcionam corretamente.<\/p>\n\n<h2>Planeamento de recursos e capacidades<\/h2>\n<p>O keepalive \u00e9 apenas parte do equil\u00edbrio. Certifico-me de que o ulimit\/nofile, <strong>fs.file-max<\/strong>, <strong>net.core.somaxconn<\/strong> e <strong>tcp_max_syn_backlog<\/strong> correspondem ao meu n\u00famero de liga\u00e7\u00e3o. Os tempos de inatividade demasiado longos escondem d\u00e9fices aqui, enquanto os valores demasiado curtos trazem uma suposta estabilidade mas atingem duramente os utilizadores. Eu planeio buffers (Recv-\/Send-Q) e reservas FD com cen\u00e1rios de carga e me\u00e7o quantas conex\u00f5es ociosas simult\u00e2neas meus n\u00f3s podem realmente suportar antes que o GC\/Worker e as filas de aceita\u00e7\u00e3o sofram.<\/p>\n\n<h2>Quando n\u00e3o dependo (apenas) do TCP Keepalive<\/h2>\n<p>Para tr\u00e1fego puramente interno sem NAT, um n\u00famero reduzido de liga\u00e7\u00f5es e timeouts claros da aplica\u00e7\u00e3o, por vezes dispenso keepalives agressivos e deixo a dete\u00e7\u00e3o para a aplica\u00e7\u00e3o (por exemplo, heartbeats ao n\u00edvel do protocolo). Por outro lado, em cen\u00e1rios de ponta e m\u00f3veis, dou prioridade a intervalos curtos, poucas sondas e adiciono PINGs HTTP\/2 ou pings WebSocket. \u00c9 importante que eu nunca fa\u00e7a a sintonia isoladamente: Os valores de keepalive devem estar em harmonia com as tentativas, os disjuntores e as estrat\u00e9gias de backoff, para que eu possa detetar erros rapidamente, mas sem causar a oscila\u00e7\u00e3o do sistema.<\/p>\n\n<h2>Estrat\u00e9gia de implanta\u00e7\u00e3o e valida\u00e7\u00e3o<\/h2>\n<p>Estou a implementar novas predefini\u00e7\u00f5es passo a passo: Primeiro os anfitri\u00f5es Canary, depois uma AZ\/zona e depois toda a frota. As compara\u00e7\u00f5es antes\/depois incluem conex\u00f5es abertas, CPU no modo kernel, lat\u00eancia P95\/P99, taxas de erro e retransmiss\u00f5es. No Kubernetes, testo por meio de anota\u00e7\u00f5es de pod ou cont\u00eaineres de inicializa\u00e7\u00e3o que definem namespaces sysctl antes de alterar todo o n\u00f3. Desta forma, minimizo o risco e asseguro resultados reproduz\u00edveis - e n\u00e3o apenas melhorias percept\u00edveis.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Com um planeamento bem pensado <strong>TCP<\/strong> Defini\u00e7\u00f5es Keepalive, removo as liga\u00e7\u00f5es inactivas mais cedo, reduzo a press\u00e3o sobre os recursos e estabilizo os tempos de resposta. Escolho tempos de inatividade curtos para o frontend, valores mais longos para backends com estado e protejo-me com intervalos moderados e poucas ou m\u00e9dias sondas. Harmonizo os valores com os tempos limite de HTTP, TLS e proxy e mantenho-os abaixo dos limites de inatividade da firewall e do NAT. Ap\u00f3s cada ajuste, me\u00e7o os efeitos vis\u00edveis na lat\u00eancia, nos erros e na CPU, em vez de confiar na intui\u00e7\u00e3o. \u00c9 assim que consigo <strong>fi\u00e1vel<\/strong> Plataforma capaz de lidar melhor com picos de carga e de servir uniformemente os fluxos de utilizadores.<\/p>","protected":false},"excerpt":{"rendered":"<p>Otimizar as defini\u00e7\u00f5es de TCP keepalive **rede de alojamento** e **ajuste do tempo limite da rede** para um melhor desempenho no alojamento web.<\/p>","protected":false},"author":1,"featured_media":18826,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-18833","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":"337","_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 Keepalive","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":"18826","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18833","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=18833"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/18833\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/18826"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=18833"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=18833"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=18833"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}