{"id":21034,"date":"2026-08-26T18:20:23","date_gmt":"2026-08-26T16:20:23","guid":{"rendered":"https:\/\/webhosting.de\/tcp-small-queues-linux-latency-optimization-netzwerkperformance\/"},"modified":"2026-08-26T18:20:23","modified_gmt":"2026-08-26T16:20:23","slug":"tcp-code-ridotte-ottimizzazione-della-latenza-in-linux-prestazioni-di-rete","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/tcp-small-queues-linux-latency-optimization-netzwerkperformance\/","title":{"rendered":"TCP Small Queues: ridurre in modo mirato la latenza nella rete Linux"},"content":{"rendered":"<p>TCP Small Queues limita, per ogni flusso TCP, il numero di byte in coda nel percorso di trasmissione di Linux, riducendo cos\u00ec <strong>Latenza<\/strong> riducendo in modo mirato anche il \u201cbufferbloat\u201d. Vi mostrer\u00f2 come funziona questo meccanismo nel <strong>rete Linux<\/strong> Stack mostra come impostare limiti ragionevoli e quali interazioni si creano con il pacing, i QDisc e il controllo della congestione.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Limite di portata<\/strong>: TSQ limita il numero di byte in sospeso per ogni socket TCP.<\/li>\n  <li><strong>Meno \"bufferbloat\"<\/strong>: Code pi\u00f9 brevi riducono l'RTT.<\/li>\n  <li><strong>Retropressione<\/strong>: Le applicazioni scrivono pi\u00f9 lentamente quando viene applicato il limite.<\/li>\n  <li><strong>Equit\u00e0<\/strong>: Nessun singolo flusso occupa intere code.<\/li>\n  <li><strong>Adattivo<\/strong> Controllo: il limite dipende dalla frequenza e dalla dimensione del segmento.<\/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\/tcp-small-queues-4739.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Come funziona TCP Small Queues<\/h2>\n\n<p>TSQ interviene nel punto in cui i segmenti TCP vengono <strong>QDisc<\/strong> e al driver. Quando scrivo dati in un socket, il kernel verifica, prima di ogni operazione di enqueue, i byte gi\u00e0 allocati per quel flusso. Se il flusso raggiunge il limite, la logica contrassegna il socket come limitato e blocca ulteriori operazioni di enqueue. Solo quando la scheda di rete libera il buffer, il socket pu\u00f2 tornare a trasmettere e io posso nuovamente inserire dati nello stack. Questa stretta limitazione mantiene la <strong>Code<\/strong> \u00e8 breve e rende i tempi di reazione pi\u00f9 prevedibili.<\/p>\n\n<h2>Perch\u00e9 le code lunghe aumentano i tempi di risposta<\/h2>\n\n<p>Creare code di driver e QDisc di grandi dimensioni <strong>Bufferbloat<\/strong>, soprattutto con TSO\/GSO e volumi di trasmissione elevati. Un download di grandi dimensioni pu\u00f2 riempire le code di uscita, mentre i flussi interattivi come SSH, le chiamate API o il VoIP vengono messi in secondo piano. La coda sovraffollata domina quindi la <strong>RTT<\/strong> anzich\u00e9 il tempo effettivo di connessione. Il controllo della congestione reagisce con lentezza, poich\u00e9 gli ACK arrivano in ritardo, e prende decisioni cwnd meno efficaci. Il TSQ limita il numero di byte pre-bufferizzati per ogni flusso, in modo che i pacchetti piccoli e urgenti vengano inviati rapidamente sulla linea.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_small_queues_meeting_2974.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uno sguardo \u201csotto il cofano\u201d: cosa conta nel kernel<\/h2>\n\n<p>Sotto la superficie, il kernel non conta i \u201epacchetti\u201c, bens\u00ec i byte; pi\u00f9 precisamente: i byte di memoria gi\u00e0 inseriti in coda dal socket. Ci\u00f2 che conta \u00e8 ci\u00f2 che lo stack contiene in termini di strutture skbuff, comprese <em>truesize<\/em> \u00e8 stato allocato ma non \u00e8 stato ancora elaborato dal NIC. TSQ vi associa un <strong>Accelerazione\/Decelerazione<\/strong>-Percorso: se un socket raggiunge il credito, lo stack imposta un flag di limitazione e richiama nuovamente solo dopo il completamento delle operazioni di trasmissione (NAPI\/IRQ) <em>write_space()<\/em> in modo che l'applicazione possa inviare nuovamente i dati. Questo feedback \u00e8 pi\u00f9 veloce dei segnali basati esclusivamente sulle perdite provenienti dal controllo della congestione e agisce prima del QDisc. Con TSO\/GSO il meccanismo rimane efficace, poich\u00e9 il limite al <em>prima di<\/em> utilizza il budget di byte associato alla segmentazione: i super-frame di grandi dimensioni vengono ammessi nei QDisc solo se \u00e8 disponibile credito sufficiente, il che consente di contenere i picchi di traffico.<\/p>\n\n<h2>Limiti dinamici e ritmo<\/h2>\n\n<p>Traggo vantaggio da TSQ perch\u00e9 il limite non rimane rigidamente statico, ma si adatta a <strong>Tasso<\/strong> e tiene conto della dimensione dei segmenti. L\u2019obiettivo \u00e8 di circa un millisecondo di dati nel percorso di trasmissione per ogni flusso, indipendentemente dal fatto che la velocit\u00e0 sia di 100 Mbit, 1 Gbit o 10 Gbit. Con una linea veloce, il credito di byte consentito aumenta, mentre con una linea lenta diminuisce. In combinazione con il TCP-Pacing, i burst rimangono piccoli e gli Ack vengono restituiti pi\u00f9 rapidamente. In questo modo ottengo una riduzione tangibile <strong>Picchi di latenza<\/strong>, senza ridurre inutilmente la portata.<\/p>\n\n<h2>Interazione per socket e tra app<\/h2>\n\n<p>TSQ agisce solo se anche l'applicazione percepisce la contropressione. Prendo quindi in considerazione impostazioni quali <strong>SO_SNDBUF<\/strong>, <strong>TCP_NOTSENT_LOWAT<\/strong> e l'autocorking. Una finestra del buffer di trasmissione troppo grande pu\u00f2 spingere molti byte nello stack in breve tempo; il TSQ rallenta, ma l'app se ne accorge solo quando <em>send()<\/em> viene bloccato o restituisce EAGAIN. Con <strong>TCP_NOTSENT_LOWAT<\/strong> regolo la quota \u201enon inviata\u201c a livello di user space, integrando cos\u00ec il TSQ a livello del kernel. Autocorking (o esplicitamente <em>TCP_CORK<\/em>\/MSG_MORE) aiuta a raggruppare le operazioni di scrittura di piccole dimensioni senza generare picchi di latenza. Limiti di pacing per socket (ad es. tramite <em>SO_MAX_FREQUENZA_DI_ANDAMENTO<\/em>) sono in sintonia con TSQ: la frequenza livella nel tempo, il limite di byte limita nello spazio. Importante: <strong>TCP_NODELAY<\/strong> Disattiva Nagle e pu\u00f2 aumentare l'interattivit\u00e0, ma senza TSQ aumenta il rischio di burst; con TSQ ho entrambi sotto controllo.<\/p>\n\n<h2>Guida pratica: valori TSQ significativi<\/h2>\n\n<p>Definisco il quadro generale con <strong>net.ipv4.tcp_limit_output_bytes<\/strong> (Sysctl). I valori predefiniti standard oscillano tra 128 e 262 KB per flusso. Per molti carichi di lavoro web e API, scelgo valori pi\u00f9 bassi affinch\u00e9 le risposte interattive rimangano veloci. Per i backup o la replica, aumento moderatamente il limite, purch\u00e9 l\u2019RTT rimanga stabile. Chi desidera approfondire l\u2019argomento delle code trover\u00e0 le nozioni di base su <a href=\"https:\/\/webhosting.de\/it\/server-code-di-pacchetti-stabilita-della-rete-ottimizzazione-dellhosting-latenza\/\">Code di pacchetti nel server<\/a>, che aiutano nella classificazione.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Scenario<\/strong><\/th>\n      <th><strong>Tasso di collegamento<\/strong><\/th>\n      <th><strong>Valore di riferimento tcp_limit_output_bytes<\/strong><\/th>\n      <th><strong>Obiettivo<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>API\/HTTP molto interattiva<\/td>\n      <td>100 Mbit \u2013 1 Gbit<\/td>\n      <td>64\u2013128 KB<\/td>\n      <td>bassa <strong>RTT<\/strong>, punte corte<\/td>\n    <\/tr>\n    <tr>\n      <td>Carico misto: Web + download<\/td>\n      <td>1\u201310 Gbit<\/td>\n      <td>128\u2013256 KB<\/td>\n      <td>Equilibrio <strong>Produttivit\u00e0<\/strong> e latenza<\/td>\n    <\/tr>\n    <tr>\n      <td>Replica\/Backup<\/td>\n      <td>1\u201310 Gbit<\/td>\n      <td>256\u2013512 KB<\/td>\n      <td>flusso di massa costante, accettabile <strong>Latenza<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>WAN con RTT elevato<\/td>\n      <td>10\u2013100 Mbit<\/td>\n      <td>96\u2013192 KB<\/td>\n      <td>raffiche pi\u00f9 brevi, pi\u00f9 eque <strong>Spunti<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-small-queues-linux-latency-2748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>QDisc e il controllo della congestione: come interagiscono<\/h2>\n\n<p>TSQ opera all'ingresso della <strong>QDisc<\/strong>, mentre algoritmi come fq_codel gestiscono la congestione sulla linea. Insieme riducono le code e garantiscono una distribuzione equa. Con <a href=\"https:\/\/webhosting.de\/it\/tcp-bbr-controllo-della-congestione-ottimizzazione-del-server-web-larghezza-di-banda\/\">TCP BBR<\/a> ne traggo un ulteriore vantaggio, poich\u00e9 misurazioni RTT pi\u00f9 realistiche consentono una migliore gestione del pacing e del controllo cwnd. Anche CUBIC risponde in modo pi\u00f9 fluido quando elimino tempi di accodamento eccessivi. In questo modo la velocit\u00e0 di trasmissione cresce in modo organico, mentre la <strong>Tempo di risposta<\/strong> rimane sotto controllo.<\/p>\n\n<h2>Virtualizzazione e stack cloud<\/h2>\n\n<p>Nelle macchine virtuali si sommano diversi livelli di buffer: QDisc dell\u2019ospite, code virtio\/vhost, QDisc dell\u2019host e la scheda di rete fisica. Mantengo attivo il TSQ nell\u2019ospite e imposto l\u00ec un limite prudente, in modo che non arrivino picchi di traffico ingenti all\u2019host. A livello di hypervisor, garantisco catene di latenza brevi utilizzando QDisc equi, anelli TX moderati e un IRQ pinning pulito. L\u2019SR-IOV pu\u00f2 ridurre la latenza, ma trasferisce la responsabilit\u00e0 agli ospiti: senza il TSQ nell\u2019ospite si rischia di avere code VF lunghe. Nei container, il TSQ interviene per <em>NetNS<\/em> come al solito; tramite il cgroup pacing e i limiti della CPU impedisco che un vicino rumoroso aumenti indirettamente la latenza. \u00c8 importante anche prestare attenzione al coalescing e agli offload nel percorso virtio: un raggruppamento eccessivo allunga gli Ack, uno insufficiente riduce l\u2019efficienza \u2013 io regolo in base all\u2019obiettivo di latenza, senza essere dogmatico.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-small-queues-latenz-8472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wi-Fi e sistemi embedded: come gestire correttamente i casi particolari<\/h2>\n\n<p>Sui collegamenti Wi-Fi, ci\u00f2 che conta \u00e8 la <strong>Aggregazione<\/strong> nel livello MAC. Se lascio un numero insufficiente di byte nel percorso di trasmissione, il driver pu\u00f2 raggruppare meno frame, riducendo cos\u00ec l\u2019efficienza. In configurazioni di questo tipo, aumento con cautela il limite e verifico il grado di aggregazione. Le piattaforme OpenWrt ed embedded traggono inoltre vantaggio da percorsi snelli nei driver e da un numero ridotto di operazioni atomiche. Testo ogni modifica sotto carico di traffico radio reale prima di <strong>Profilo<\/strong> lo stendo bene.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_latenz_reduzieren_2837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoraggio e metriche che contano davvero<\/h2>\n\n<p>Osservo il <strong>RTT<\/strong>- Distribuzione per socket e osservo i valori anomali, non solo le medie. Con ss, tc e gli esportatori leggo le lunghezze delle code, le ritrasmissioni e il pacing_rate. I programmi eBPF mi forniscono eventi quando i socket vengono limitati e poi liberati nuovamente. Il \u00abtime-to-first-byte\u00bb e i percentili 95\u00b0 e 99\u00b0 indicano se il TSQ sta funzionando. Senza valori di misurazione, ogni <strong>Ottimizzazione<\/strong> un volo alla cieca.<\/p>\n\n<h2>Test A\/B e di carico significativi<\/h2>\n\n<p>Misuro gli effetti TSQ in modo riproducibile: prima la linea di base senza modifiche, poi le variazioni isolate dei parametri (ad es. 64, 96, 128, 192 KB). Per i carichi di lavoro misti eseguo flussi paralleli (bulk + molte richieste brevi) e confronto il 95\u00b0 e il 99\u00b0 percentile delle latenze, non solo la mediana. Anche se interrompo chiaramente le sessioni di test (warm-up, finestra di misurazione, cool-down), gli artefatti rimangono riconoscibili. Presto attenzione alle costanti: stessi modelli di payload, percorso\/MTU identici, frequenze della CPU del server e del client identiche. Sulle tratte WAN simulo ritardo\/jitter\/perdita con <em>tc netem<\/em>, per verificare che i limiti TSQ non raggiungano il tetto massimo troppo presto in caso di BDP elevato. Solo quando i percentili si restringono e le ritrasmissioni\/perdite rimangono stabili, inserisco i valori nella produzione.<\/p>\n\n<h2>Ottimizzazione hardware e dettagli sui driver<\/h2>\n\n<p>Verifico le impostazioni TSO\/GSO, il buffer circolare della scheda di rete e il controllo degli IRQ, in modo che <strong>TSQ<\/strong> funziona in modo ottimale. Gli anelli TX troppo grandi allungano la coda in attesa sul dispositivo; quelli troppo piccoli riducono l\u2019utilizzo delle risorse. Un raggruppamento grossolano degli interrupt ritarda gli Ack, mentre un raggruppamento fine aumenta il carico della CPU. Adatto la moderazione in base alle esigenze pratiche e, per iniziare, rimando a <a href=\"https:\/\/webhosting.de\/it\/interruzione-della-coalescenza-ottimizzazione-della-rete-serverflux\/\">Interruzione della coalescenza<\/a>. L'obiettivo rimane quello di garantire un servizio affidabile <strong>Latenza<\/strong> con una produttivit\u00e0 sostenibile.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_small_queues_9271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA, RSS e affinit\u00e0 della CPU<\/h2>\n\n<p>Le code brevi servono a poco se i pacchetti attraversano continuamente i confini NUMA. Associo le code RX\/TX tramite RSS\/irqbalance ai core dello stesso dominio NUMA su cui gira l\u2019applicazione. Con XPS\/RPS controllo quali CPU si occupano del lavoro TX, evitando cos\u00ec i \u201ecross-socket hopper\u201c. Un minor numero di cache miss e una minore contesa sui lock aiutano indirettamente TSQ: i completamenti tornano pi\u00f9 velocemente, il socket viene \u201csbloccato\u201d prima e non si verificano picchi di latenza. In presenza di un numero molto elevato di flussi per host, pianifico un numero sufficiente di code ed evito che pi\u00f9 flussi intensi entrino in collisione sullo stesso anello TX.<\/p>\n\n<h2>Passo dopo passo: verificare lo stato di TSQ<\/h2>\n\n<p>Inizio con uno sguardo a <strong>Sysctl<\/strong>: Il comando `sysctl net.ipv4.tcp_limit_output_bytes` mostra il limite attuale. Successivamente, utilizzo `ss -tin` per analizzare i singoli socket, prestando attenzione a `send-q` e `rtt`, e confronto le fasi di carico con e senza regolazione del limite. Con iperf3 genero un carico in background e misuro in parallelo i tempi di risposta delle API per rendere visibili le priorit\u00e0. tc -s qdisc mi fornisce il numero di pacchetti e di drop della disciplina in uscita. Se il 95\u00b0 e il 99\u00b0 percentile rimangono ravvicinati e il <strong>CPU<\/strong>- Carico nel telaio, la scelta del limite \u00e8 adeguata.<\/p>\n\n<h2>Errori comuni e anti-pattern<\/h2>\n\n<ul>\n  <li>\u201ePi\u00f9 buffer = pi\u00f9 prestazioni\u201c: vale per i test di throughput senza obiettivi di latenza, ma non funziona con i servizi interattivi. TSQ sostituisce le code sovradimensionate con un credito adeguato alle esigenze per ogni flusso.<\/li>\n  <li>\u201eIl TSQ incide sulla produttivit\u00e0\u201c: se impostato correttamente, il TSQ limita i picchi, non la velocit\u00e0 media. Per i carichi di lavoro di massa, aumento moderatamente il limite e misuro i percentili anzich\u00e9 limitarmi al picco in Mbit\/s.<\/li>\n  <li>\u201eIl pacing da solo \u00e8 sufficiente\u201c: la livellazione temporale \u00e8 importante, ma senza un limite di byte i frame GSO di grandi dimensioni finiscono comunque nel QDisc. TSQ e pacing si completano a vicenda.<\/li>\n  <li>\u201eUn valore unico per tutti\u201c: i carichi di lavoro, i collegamenti e le schede di rete sono diversi. Lavoro con valori di intervallo e effettuo la convalida per ogni ambiente.<\/li>\n  <li>\u201eSolo il TCP \u00e8 interessato\u201c: l'attenzione \u00e8 rivolta al TCP, ma nel sistema ci sono altri parametri di regolazione (ad esempio per il carico UDP). Impedisco che i protocolli paralleli intasino in modo incontrollato le stesse code.<\/li>\n<\/ul>\n\n<h2>Conclusione: la latenza sotto controllo in modo mirato<\/h2>\n\n<p>TSQ trasferisce il controllo delle code dei driver al <strong>Presa<\/strong> riducendo cos\u00ec la congestione direttamente alla fonte. Limito i byte pre-bufferizzati per ogni flusso, garantendo cos\u00ec Ack rapidi, RTT pi\u00f9 bassi e code equamente distribuite. In combinazione con fq_codel e un controllo della congestione all\u2019avanguardia, il tempo di risposta rimane affidabile anche sotto carico. Tratto i casi particolari relativi al Wi-Fi e ai sistemi embedded con limiti adeguati e test in condizioni reali. Chi monitora gli indicatori e regola i limiti gradualmente, mantiene la <strong>Latenza<\/strong> costantemente basso, senza perdere inutili portate.<\/p>","protected":false},"excerpt":{"rendered":"<p>La funzione TCP Small Queues nel kernel Linux limita il numero di pacchetti TCP bufferizzati per flusso ed \u00e8 uno strumento potente per l'ottimizzazione della latenza. Scopri come TSQ riduce il bufferbloat e migliora i tempi di risposta dei server.<\/p>","protected":false},"author":1,"featured_media":21027,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21034","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":"114","_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 Small","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":"21027","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21034","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=21034"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21034\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21027"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21034"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21034"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21034"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}