{"id":18881,"date":"2026-04-09T18:20:39","date_gmt":"2026-04-09T16:20:39","guid":{"rendered":"https:\/\/webhosting.de\/http-connection-reuse-keepalive-optimierung-serverperf-boost\/"},"modified":"2026-04-09T18:20:39","modified_gmt":"2026-04-09T16:20:39","slug":"riutilizzo-della-connessione-http-keepalive-ottimizzazione-serverperf-boost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/http-connection-reuse-keepalive-optimierung-serverperf-boost\/","title":{"rendered":"Riutilizzo delle connessioni HTTP e ottimizzazione del keep-alive: aumento delle prestazioni del server web"},"content":{"rendered":"<p>Mostro come <strong>Riutilizzo della connessione HTTP<\/strong> e la sintonizzazione strutturata del keep-alive riducono l'overhead degli handshake TCP e TLS, in modo che le pagine rispondano pi\u00f9 velocemente e i server debbano fare meno cose. Con timeout, limiti e caratteristiche del protocollo adeguati, riduco <strong>Latenza<\/strong>, attenuare i picchi di carico e aumentare significativamente il rendimento.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Mantenere in vita<\/strong> riduce le strette di mano e accorcia <strong>Tempi di caricamento<\/strong>.<\/li>\n  <li><strong>Timeout<\/strong> e mantenere i limiti <strong>Risorse<\/strong> efficiente.<\/li>\n  <li><strong>HTTP\/2<\/strong> e il rinforzo HTTP\/3 <strong>Riutilizzo<\/strong> attraverso il multiplexing.<\/li>\n  <li><strong>Pooling dei clienti<\/strong> abbassa il backend<strong>Latenza<\/strong>.<\/li>\n  <li><strong>Monitoraggio<\/strong> fa s\u00ec che la messa a punto abbia successo <strong>misurabile<\/strong>.<\/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\/http-server-optimierung-9347.png\" alt=\"Ottimizzazione HTTP efficiente nella sala server\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cosa significa riutilizzo delle connessioni HTTP?<\/h2>\n\n<p>Uso <strong>Riutilizzo della connessione<\/strong>, di inviare pi\u00f9 richieste HTTP su un'unica connessione TCP, evitando cos\u00ec costose riconnessioni. Ogni nuova connessione costa tre pacchetti TCP pi\u00f9 un eventuale handshake TLS, il che fa risparmiare tempo e denaro. <strong>CPU<\/strong> mangia. Se la linea rimane aperta, le richieste successive vengono eseguite sullo stesso socket, risparmiando i viaggi di andata e ritorno. I siti con molte risorse di piccole dimensioni, come CSS, JS e immagini, ne traggono particolare vantaggio perch\u00e9 il tempo di attesa per ogni oggetto si riduce. In HTTP\/1.1, l'intestazione \u201cConnection: keep-alive\u201d segnala il riutilizzo, riducendo sensibilmente la latenza e stabilizzando il throughput.<\/p>\n\n<h2>Perch\u00e9 Keep-Alive migliora le prestazioni del server web<\/h2>\n\n<p>Mi affido a <strong>Mantenere in vita<\/strong>-perch\u00e9 riduce le spese generali del kernel e del TLS, consentendo il passaggio di una maggiore quantit\u00e0 di payload al secondo attraverso la linea. Nei test, il throughput effettivo spesso aumenta fino al 50%, in quanto gli handshake vengono eliminati e il <strong>CPU<\/strong> esegue un minor numero di cambi di contesto. Allo stesso tempo, le pagine reagiscono pi\u00f9 rapidamente, poich\u00e9 i browser possono ricaricare rapidamente gli oggetti aggiuntivi. I timeout brevi impediscono alle connessioni inattive di occupare la RAM e i limiti per le keepalive_request garantiscono la stabilit\u00e0. In questo modo, mantengo il numero di socket attivi nella zona verde ed evito i colli di bottiglia nei picchi di carico.<\/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\/http-opt-meeting-1045.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configurazione lato server: Nginx, Apache e proxy<\/h2>\n\n<p>Ho messo <strong>Nginx<\/strong> in modo che i timeout siano abbastanza brevi da risparmiare RAM, ma abbastanza lunghi da consentire ai browser di recuperare diversi oggetti in successione. Per i siti web tipici, mi trovo bene con 60-120 secondi di timeout inattivo e 50-200 richieste per connessione, che confronto con i modelli di traffico reali. Un esempio mostra come inizio e poi metto a punto. Tramite il link <a href=\"https:\/\/webhosting.de\/it\/http-keepalive-timeout-configurazione-delle-prestazioni-del-server\/\">Configurare il timeout di keep-alive<\/a> Approfondisco dettagli come i descrittori di file aperti e le code di accettazione. Per i reverse proxy, attivo proxy_http_version 1.1, in modo che il keep-alive sia trasmesso in modo pulito e che i backend traggano vantaggio dal riutilizzo.<\/p>\n\n<pre><code># Nginx (Frontend \/ Reverse Proxy)\nkeepalive_timeout 65s;\nkeepalive_requests 100;\n\n# Proxy a upstream\nproxy_http_version 1.1;\nproxy_set_header Connessione \"\";\n\n# Apache (esempio)\nKeepAlive On\nMaxKeepAliveRequests 100\nKeepAliveTimeout 5\n<\/code><\/pre>\n\n<h2>TLS, HTTP\/2 e HTTP\/3: protocolli che rafforzano il riuso<\/h2>\n\n<p>Combino <strong>Mantenere in vita<\/strong> con TLS 1.3, ripresa della sessione e pinzatura OCSP, in modo che le connessioni siano disponibili pi\u00f9 rapidamente. In HTTP\/2, raggruppo molti flussi su un'unica connessione, eliminando cos\u00ec i ritardi a livello di applicazione. L'effetto aumenta con <strong>Multiplexing<\/strong>, perch\u00e9 i browser richiedono risorse in parallelo senza dover creare nuovi socket. Per una categorizzazione fondata, si rimanda a <a href=\"https:\/\/webhosting.de\/it\/http2-multiplexing-vs-http11-prestazioni-background-ottimizzazione\/\">Multiplexing HTTP\/2<\/a>, che mostra chiaramente le differenze con HTTP\/1.1. HTTP\/3 con QUIC offre anche un avvio a 0-RTT per le richieste idempotenti e reagisce in modo sensibilmente pi\u00f9 rapido in caso di perdita di pacchetti.<\/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\/http-connection-reuse-8542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ottimizzazione lato client: Node.js e Python<\/h2>\n\n<p>Attivo <strong>Mantenere in vita<\/strong> anche nel client, in modo che le chiamate alle API e al backend richiedano meno connessioni. In Node.js, utilizzo un https.agent con pooling delle connessioni, che riduce le latenze e accelera il time-to-first-byte. Python con requests.Session() fa lo stesso in modo semplice, rendendo i servizi pi\u00f9 stabili. Ci\u00f2 consente di mantenere brevi i percorsi di trasporto e di risparmiare i viaggi di andata e ritorno in entrambe le direzioni. Ci\u00f2 si traduce in tempi di risposta pi\u00f9 costanti e in una riduzione misurabile dei tempi di risposta. <strong>Carico del server<\/strong>.<\/p>\n\n<pre><code>\/\/ Node.js\nconst https = require('https');\nconst httpsAgent = new https.Agent({\n  keepAlive: true,\n  keepAliveMsecs: 60000,\n  maxSockets: 50\n});\n\n\/\/ Uso: fetch \/ axios \/ https nativo con httpsAgent\n\n# Python\nimportare le richieste\nsession = requests.Session() # Riutilizzo e pooling\nr = session.get('https:\/\/api.example.com\/data') # meno handshake\n<\/code><\/pre>\n\n<h2>Valori tipici e loro effetto<\/h2>\n\n<p>Inizio con i conservatori <strong>Valori<\/strong> e misuro se le connessioni tendono a rimanere inattive o a chiudersi troppo presto. Se prevedo picchi di carico, accorcio i timeout per mantenere la RAM libera senza costringere i browser a riconnettersi continuamente. Se il parallelismo \u00e8 elevato, imposto il massimo dei descrittori di file in modo da evitare colli di bottiglia nell'accettazione. La tabella seguente fornisce una rapida panoramica di come inizio e di cosa fanno le impostazioni. Poi modifico per gradi e osservo con attenzione le metriche per <strong>Correzioni<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametri<\/th>\n      <th>Nginx<\/th>\n      <th>Apache<\/th>\n      <th>Valore iniziale tipico<\/th>\n      <th>Effetto<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Timeout inattivit\u00e0<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>Equalizza il riutilizzo e il consumo di RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>Richieste per connessione<\/td>\n      <td>keepalive_requests<\/td>\n      <td>MaxKeepAliveRequests<\/td>\n      <td>50-200<\/td>\n      <td>Stabilizza l'utilizzo per presa<\/td>\n    <\/tr>\n    <tr>\n      <td>Versione proxy<\/td>\n      <td>versione_http_proxy<\/td>\n      <td>\u2013<\/td>\n      <td>1.1<\/td>\n      <td>Abilita il passaggio di keep-alive<\/td>\n    <\/tr>\n    <tr>\n      <td>Descrittori aperti<\/td>\n      <td>worker_rlimit_nofile<\/td>\n      <td>ulimit -n<\/td>\n      <td>&gt;= 65535<\/td>\n      <td>Previene la carenza di prese<\/td>\n    <\/tr>\n    <tr>\n      <td>Accettare la coda<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>AscoltareBacklog<\/td>\n      <td>512-4096<\/td>\n      <td>Riduce le cadute in corrispondenza dei picchi<\/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\/webserver_perf_3498.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoraggio e test di carico: metriche che contano<\/h2>\n\n<p>Tasso <strong>Riutilizzo<\/strong>-I successi con wrk o ApacheBench e la correlazione con i log e le metriche di sistema. Sono importanti i socket aperti, i socket liberi, le richieste in sospeso e i codici di errore che indicano i colli di bottiglia. Se il numero di connessioni inattive aumenta, abbasso i timeout o riduco moderatamente le keepalive_request. Se le connessioni vengono interrotte troppo frequentemente, aumento i limiti o verifico se i backend rispondono troppo lentamente. Questo mi permette di individuare rapidamente il punto in cui latenza, throughput e <strong>Risorse<\/strong> si abbinano bene tra loro.<\/p>\n\n<h2>Pratica WordPress: meno richieste, prima vernice pi\u00f9 veloce<\/h2>\n\n<p>Riduco le richieste HTTP di <strong>CSS\/JS<\/strong> utilizzare le icone come sprite SVG e distribuire i font a livello locale. Insieme alla cache del browser, il numero di trasferimenti di rete durante le revisioni si riduce drasticamente. Questo crea maggiori possibilit\u00e0 di riutilizzo, perch\u00e9 i browser richiedono un minor numero di nuovi socket. Se volete approfondire, potete trovare dei passi pratici nella sezione <a href=\"https:\/\/webhosting.de\/it\/guida-allottimizzazione-delle-prestazioni-del-server-web-keep-alive\/\">Guida alla regolazione di Keep-Alive<\/a>, che spiega i percorsi di messa a punto dal timeout all'impostazione dei worker. Alla fine, ci\u00f2 che conta \u00e8 che le pagine vengano caricate in modo sensibilmente pi\u00f9 veloce e il <strong>Carico del server<\/strong> rimane prevedibile.<\/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\/webserverperformance1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Scalabilit\u00e0 e risorse di sistema<\/h2>\n\n<p>Controllo <strong>CPU<\/strong>-profili, l'ingombro di memoria per worker e la scheda di rete prima di aumentare i limiti. Un maggiore parallelismo \u00e8 utile solo se ogni livello dispone di buffer e descrittori sufficienti. L'affinit\u00e0 NUMA, la distribuzione degli IRQ e le implementazioni TLS veloci forniscono ulteriori riserve. Con i container, faccio attenzione ai limiti dei file aperti e ai limiti rigidi dell'host, che altrimenti rallentano il riutilizzo. In questo modo, evito i colli di bottiglia che diventano rapidamente evidenti con l'aumento del traffico e sprecano risorse preziose. <strong>Prestazioni<\/strong> costi.<\/p>\n\n<h2>Errori e risoluzione dei problemi<\/h2>\n\n<p>Riconosco <strong>Errore<\/strong> Spesso noto degli schemi: troppi socket TIME_WAIT, aumento di 502\/504 o brusche variazioni di RPS. Verifico quindi se i backend accettano keep-alive e se le intestazioni dei proxy sono impostate correttamente. Timeout di inattivit\u00e0 non corretti spesso innescano reazioni a catena su singoli hops, che correggo impostando valori coerenti. I problemi di TLS si manifestano con picchi di handshake_time, che la ripresa della sessione o le ottimizzazioni 1.3 alleviano. Con aggiustamenti mirati, stabilizzo la catena dall'edge al server dell'app e mantengo <strong>Tempi di risposta<\/strong> affidabile.<\/p>\n\n<h2>Mantenere coerenti i timeout tra i turni<\/h2>\n\n<p>Io compenso <strong>Timeout di inattivit\u00e0 e attivit\u00e0<\/strong> su tutti gli anelli: CDN\/WAF, load balancer, reverse proxy e applicazione. Un timeout di origine troppo breve interrompe le connessioni mentre il browser sta ancora caricando; un timeout di bordo troppo lungo riempie la RAM di socket inattivi. Pertanto, pianifico in cascata: Edge un po' <em>pi\u00f9 breve<\/em> come browser inattivo, proxy al centro, timeout del backend pi\u00f9 lungo. In questo modo evito gli RST e impedisco che le costose connessioni TLS vengano terminate inutilmente.<\/p>\n\n<pre><code># Nginx: timeout precisi e riutilizzo upstream\nclient_header_timeout 10s;\nclient_body_timeout 30s;\nsend_timeout 15s;\n\nproxy_read_timeout 60s;\nproxy_send_timeout 60s;\nproxy_socket_keepalive on; # Rileva i peer morti pi\u00f9 velocemente\n\nupstream backend_pool {\n  server app1:8080;\n  server app2:8080;\n  keepalive 64; # Cache delle connessioni inattive upstream\n  keepalive_timeout 60s; # (da versioni Nginx con timeout upstream)\n  keepalive_requests 1000;\n}\n<\/code><\/pre>\n\n<p>Faccio una distinzione tra <strong>HTTP - Mantenimento in vita<\/strong> da <strong>TCP-Conservazione<\/strong> (SO_KEEPALIVE). Quest'ultimo lo uso specificamente sui socket proxy per riconoscere le stazioni remote sospese senza terminare inutilmente il riutilizzo dell'HTTP.<\/p>\n\n<h2>Messa a punto di HTTP\/2 e HTTP\/3: utilizzare correttamente il multiplexing<\/h2>\n\n<p>Ho impostato HTTP\/2 in modo che i flussi vengano eseguiti in modo efficiente in parallelo senza generare head-of-line sul server. A tal fine, limito il numero massimo di flussi per sessione e mantengo brevi i timeout di inattivit\u00e0, in modo da non lasciare indietro le sessioni dimenticate. Utilizzo la prioritizzazione per <strong>Beni critici<\/strong> e assicurarsi che HTTP\/3 abbia una configurazione pulita a 0-RTT solo per le richieste idempotenti.<\/p>\n\n<pre><code># Ottimizzazione HTTP\/2 di Nginx\nhttp2_max_concurrent_streams 128;\nhttp2_idle_timeout 30s; # Inattivit\u00e0 a livello H2\nhttp2_max_field_size 16k; # Protezione delle intestazioni (vedere Sicurezza)\nhttp2_max_header_size 64k;\n<\/code><\/pre>\n\n<p>Con <strong>Coalescenza delle connessioni<\/strong> (H2\/H3), un browser pu\u00f2 utilizzare pi\u00f9 hostname tramite <em>a<\/em> se il certificato SAN e l'IP\/configurazione corrispondono. Io lo sfrutto consolidando i sottodomini statici e scegliendo certificati che coprono pi\u00f9 host. In questo modo si risparmiano ulteriori handshake e contese sulle porte.<\/p>\n\n<h2>Parametri del kernel e del socket in sintesi<\/h2>\n\n<p>Assicuro anche il Riutilizzo su <strong>Livello del kernel<\/strong> in modo che non si verifichino carenze di porte e socket. Gli intervalli di porte effimere, il comportamento FIN\/TIME_WAIT e il probing keepalive hanno un'influenza diretta sulla stabilit\u00e0 e sulla velocit\u00e0 di handshake.<\/p>\n\n<pre><code># \/etc\/sysctl.d\/99-tuning.conf (esempi, testare con cautela)\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_keepalive_time = 600\nnet.ipv4.tcp_keepalive_intvl = 30\nnet.ipv4.tcp_keepalive_probes = 5\nnet.core.netdev_max_backlog = 4096\n<\/code><\/pre>\n\n<p>Evito modifiche rischiose come l'attivazione sconsiderata di <code>tcp_tw_reuse<\/code> su server pubblicamente accessibili. Ancora pi\u00f9 importante, <strong>Quote di riutilizzo<\/strong> in modo che non ci siano molte connessioni a breve termine. In condizioni di carico elevato, scaliamo anche la distribuzione degli IRQ e l'affinit\u00e0 della CPU in modo che gli interrupt di rete non si raggruppino e generino picchi di latenza.<\/p>\n\n<h2>Sicurezza e protezione dagli abusi senza rallentamenti Riutilizzo<\/h2>\n\n<p>Keep-Alive invita gli aggressori a <strong>Slowloris<\/strong>-varianti o abuso di HTTP\/2 se mancano i limiti. Indurisco le dimensioni delle intestazioni e le velocit\u00e0 di richiesta senza interferire con i modelli di riutilizzo legittimi. Contro <em>Reset rapido<\/em>-in H2, imposto dei limiti per i flussi simultanei e le velocit\u00e0 RST e registro i client pi\u00f9 vistosi.<\/p>\n\n<pre><code># Nginx: regole di protezione\nlarge_client_header_buffer 4 8k;\nclient_body_buffer_size 128k;\n\nlimit_conn_zone $binary_remote_addr zone=perip:10m;\nlimit_conn perip 50;\n\nlimit_req_zone $binary_remote_addr zone=periprate:10m rate=20r\/s;\nlimit_req zone=periprate burst=40 nodelay;\n\n# H2-specifico gi\u00e0 sopra: http2_max_concurrent_streams, limiti header\n<\/code><\/pre>\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\/serverraum-optimierung-5743.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<p>Uso anche <strong>grazioso<\/strong> Arresto in modo che le connessioni keep-alive si esauriscano in modo pulito durante le distribuzioni e non si verifichino errori del client.<\/p>\n\n<pre><code># Nginx: cancellare le connessioni in modo pulito\nworker_shutdown_timeout 10s;\n<\/code><\/pre>\n\n<h2>Bilanciatori di carico, CDN e upstream: riutilizzo lungo tutta la catena<\/h2>\n\n<p>Mi assicuro che <strong>tra<\/strong> Il riutilizzo di LB\/proxy e backend avviene. A tal fine, gestisco pool upstream con slot sufficienti e utilizzo strategie di hashing appiccicose o coerenti se le sessioni sono necessarie nel backend. Riduco il carico sulle CDN utilizzando pochi e duraturi <em>Origine<\/em>-e limitare il numero massimo di connessioni per POP, in modo che i server delle applicazioni non anneghino in troppi piccoli socket.<\/p>\n\n<p>Importanti sono <strong>Timeout di inattivit\u00e0 omogenei<\/strong> lungo il percorso: l'Edge non deve interrompere le connessioni prima dell'Origine, altrimenti le sessioni di multiplexing saranno ristabilite inutilmente. Con HTTP\/3, tengo conto del fatto che i notebook e i client mobili cambiano IP pi\u00f9 frequentemente; quindi pianifico tempi di inattivit\u00e0 tolleranti ma limitati.<\/p>\n\n<h2>Approfondire il pooling dei client: Node.js, Python, gRPC<\/h2>\n\n<p>Dal punto di vista del cliente, mi occupo di <strong>pooling<\/strong> e limiti chiari, in modo che non si verifichino n\u00e9 stampate n\u00e9 perdite. In Node.js, imposto limiti di socket liberi e timeout di inattivit\u00e0, in modo che le connessioni rimangano calde ma non aperte per sempre.<\/p>\n\n<pre><code>\/\/ Messa a punto dell'agente Node.js\nconst https = require('https');\nconst agent = new https.Agent({\n  keepAlive: true,\n  keepAliveMsecs: 60000,\n  maxSockets: 100,\n  maxFreeSockets: 20\n});\n\/\/ axios\/fetch: httpsAgent: agent\n<\/code><\/pre>\n\n<pre><code>Richieste # Python: pool pi\u00f9 grande per host\nimportare richieste\nda requests.adapters import HTTPAdapter\n\nsessione = requests.Session()\nadapter = HTTPAdapter(pool_connections=50, pool_maxsize=200, max_retries=0)\nsession.mount('https:\/\/', adapter)\nsession.mount('http:\/\/', adattatore)\n<\/code><\/pre>\n\n<p>Per <strong>asincrono<\/strong> (aiohttp), limito il numero massimo di socket e uso la cache DNS per mantenere basse le latenze. Con <strong>gRPC<\/strong> (H2), ho impostato i ping keep-alive in modo moderato, in modo che lunghe fasi di inattivit\u00e0 non portino alla disconnessione senza inondare le reti.<\/p>\n\n<h2>Metriche e valori target per la messa a punto dei loop<\/h2>\n\n<p>Controllo la messa a punto in modo iterativo con figure chiave che rendono visibile il riutilizzo:<\/p>\n<ul>\n  <li><strong>Quota di riutilizzo<\/strong> (richieste\/connessione) separatamente per frontend e upstream.<\/li>\n  <li><strong>Strette di mano TLS\/s<\/strong> vs. richieste\/s - Obiettivo: ridurre la percentuale di strette di mano.<\/li>\n  <li><strong>latenza p95\/p99<\/strong> per TTFB e totale.<\/li>\n  <li><strong>Connessioni inattive<\/strong> e la loro durata di vita.<\/li>\n  <li><strong>Profili di errore<\/strong> (4xx\/5xx), reset, timeout.<\/li>\n  <li><strong>TEMPO_ATTESA\/FIN_ATTESA<\/strong>-contatore e l'utilizzo di porte effimere.<\/li>\n<\/ul>\n<p>Una semplice immagine di destinazione: <em>Strette di mano TLS\/s<\/em> stabile ben al di sotto <em>Richiesta\/e<\/em>, tasso di riutilizzo nell'intervallo H1 &gt;= 20-50 a seconda delle dimensioni dell'oggetto, per H2\/H3 diversi flussi simultanei per sessione senza congestione.<\/p>\n\n<h2>Strategie di front-end che favoriscono il riutilizzo<\/h2>\n\n<p>Evito <strong>Sharding del dominio<\/strong> con H2\/H3, consolidare gli host e utilizzare il precaricamento\/preconnessione in modo selettivo per risparmiare costosi handshake quando sono inevitabili. Carico immagini di grandi dimensioni in modo moderno e compresso, in modo che la larghezza di banda non diventi un collo di bottiglia che blocca inutilmente gli slot keep-alive. Riduco al minimo i cookie per mantenere le intestazioni piccole e inviare pi\u00f9 oggetti in modo efficiente nelle stesse sessioni.<\/p>\n\n<h2>Considerare le reti mobili e NAT<\/h2>\n\n<p>In ambienti radio mobili e NAT <strong>Timeout di inattivit\u00e0<\/strong> spesso pi\u00f9 brevi. Pertanto, mantengo l'inattivit\u00e0 del server moderata e accetto che i client si riconnettano pi\u00f9 spesso. Con la ripresa della sessione e 0-RTT (H3), le riconnessioni rimangono comunque veloci. Sul lato server, le sonde TCP keep-alive sui socket proxy aiutano a smaltire rapidamente i percorsi morti.<\/p>\n\n<h2>Rollout e alta disponibilit\u00e0<\/h2>\n\n<p>Per le distribuzioni gestisco le connessioni <strong>morbido<\/strong> off: Interrompe le nuove accettazioni, attende i keep-alive socket esistenti e solo allora termina i processi. Posiziono il drenaggio delle connessioni dietro i LB, in modo che le sessioni di multiplexing non vengano terminate nel bel mezzo del flusso. Mantengo i controlli di salute aggressivi, ma idempotenti, in modo da riconoscere tempestivamente gli errori e ristrutturare i pool in tempo utile.<\/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\/http-connection-reuse-8542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riassunto per un rapido successo<\/h2>\n\n<p>Mi affido a <strong>HTTP<\/strong> Riutilizzo delle connessioni, timeout brevi e limiti ragionevoli in modo che le connessioni rimangano produttive e non impegnino le risorse quando sono inattive. I protocolli moderni come HTTP\/2 e HTTP\/3 rafforzano l'effetto, mentre il pooling dei client alleggerisce i backend. Con il monitoraggio, riconosco subito i socket inattivi o troppo scarsi e regolo i valori in modo iterativo. Per WordPress e stack simili, combino il riutilizzo con la cache, il raggruppamento delle risorse e i font ospitati localmente. In questo modo si ottengono pagine veloci, curve di caricamento uniformi e un'ottima qualit\u00e0 di navigazione. <strong>Server web<\/strong>-prestazioni, che sono evidenti in ogni metrica.<\/p>","protected":false},"excerpt":{"rendered":"<p>Il riutilizzo delle connessioni HTTP e l'ottimizzazione del keep-alive aumentano enormemente le prestazioni dei server web. Scoprite i suggerimenti per ridurre la latenza e aumentare il throughput.<\/p>","protected":false},"author":1,"featured_media":18874,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-18881","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"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":"548","_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":"HTTP Connection Reuse","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":"18874","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/18881","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=18881"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/18881\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/18874"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=18881"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=18881"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=18881"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}