{"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-kleine-wachtrijen-linux-latentieoptimalisatie-netwerkprestaties","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/tcp-small-queues-linux-latency-optimization-netzwerkperformance\/","title":{"rendered":"TCP Small Queues: latentie in het Linux-netwerk doelgericht verminderen"},"content":{"rendered":"<p>TCP Small Queues beperkt per TCP-flow het aantal nog te verzenden bytes in het Linux-verzendpad en zorgt er zo voor dat <strong>Latency<\/strong> inclusief bufferbloat doelgericht verminderen. Ik laat zien hoe dit mechanisme in de <strong>Linux-netwerken<\/strong> Stack laat zien hoe ik zinvolle limieten instel en welke wisselwerkingen er ontstaan met pacing, QDiscs en congestiecontrole.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>Per-flow-limiet<\/strong>: TSQ beperkt het aantal uitstaande bytes per TCP-socket.<\/li>\n  <li><strong>Minder bufferbloat<\/strong>: Kortere wachtrijen verlagen de RTT.<\/li>\n  <li><strong>Tegendruk<\/strong>: Toepassingen schrijven langzamer wanneer de limiet van kracht wordt.<\/li>\n  <li><strong>Eerlijkheid<\/strong>: Geen enkele afzonderlijke flow neemt volledige wachtrijen in beslag.<\/li>\n  <li><strong>Adaptief<\/strong> Regeling: De limiet is afhankelijk van de snelheid en de segmentgrootte.<\/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>Hoe TCP Small Queues werkt<\/h2>\n\n<p>TSQ begint op het punt waar TCP-segmenten worden <strong>QDisc<\/strong> en doorgeeft aan de driver. Als ik gegevens naar een socket schrijf, controleert de kernel v\u00f3\u00f3r elke enqueue de reeds toegewezen bytes voor deze flow. Als de flow de limiet bereikt, markeert de logica de socket als afgeremd en stopt verdere enqueue. Pas wanneer de netwerkkaart bufferruimte vrijgeeft, mag de socket weer verzenden en kan ik opnieuw gegevens in de stack plaatsen. Deze strakke terugkoppeling houdt de <strong>Wachtrijen<\/strong> kort en maakt reactietijden voorspelbaarder.<\/p>\n\n<h2>Waarom lange wachtrijen de responstijd be\u00efnvloeden<\/h2>\n\n<p>Grote driver- en QDisc-wachtrijen aanmaken <strong>Bufferbloat<\/strong>, vooral bij TSO\/GSO en grote verzendvolumes. Een grote download kan de uitgaande wachtrijen vullen, terwijl interactieve stromen zoals SSH, API-aanroepen of VoIP achteraan in de rij komen te staan. De overvolle wachtrij domineert dan de <strong>RTT<\/strong> in plaats van de daadwerkelijke verbindingstijd. Congestion Control reageert traag omdat ACK\u2019s te laat binnenkomen, en neemt daardoor slechtere cwnd-beslissingen. TSQ beperkt het aantal vooraf gebufferde bytes per flow, zodat kleine, tijdkritische pakketten snel op de lijn terechtkomen.<\/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>Een kijkje onder de motorkap: wat de kernel telt<\/h2>\n\n<p>Onder de oppervlakte telt de kernel geen \u201epakketten\u201c, maar bytes, om precies te zijn: de geheugenbytes die de socket al in de wachtrij heeft geplaatst. Bepalend is wat de stack aan skbuff-structuren, inclusief <em>truesize<\/em> heeft toegewezen en nog niet door de NIC is verwerkt. TSQ koppelt hieraan een <strong>Gas geven\/Gas loslaten<\/strong>\u2011Pad: Als een socket de kredietlimiet bereikt, zet de stack een beperkingsvlag en roept pas weer op nadat TX-bewerkingen zijn voltooid (NAPI\/IRQ) <em>write_space()<\/em> zodat de toepassing opnieuw mag verzenden. Deze terugkoppeling is sneller dan signalen uit congestiecontrole die uitsluitend op verlies zijn gebaseerd en werkt v\u00f3\u00f3r de QDisc. Met TSO\/GSO blijft het mechanisme effectief, omdat de limiet op de <em>voor<\/em> het bytebudget dat aan de segmentatie ten grondslag ligt: grote superframes worden alleen in de QDisc toegelaten als er voldoende krediet beschikbaar is, waardoor bursts worden beperkt.<\/p>\n\n<h2>Dynamische limieten en tempo<\/h2>\n\n<p>Ik profiteer van TSQ omdat de limiet niet simpelweg statisch blijft, maar op <strong>Prijs<\/strong> en let op de segmentgrootte. Het doel is ongeveer \u00e9\u00e9n milliseconde aan gegevens in het verzendpad per flow, ongeacht of er 100 Mbit, 1 Gbit of 10 Gbit wordt verzonden. Bij een snelle verbinding neemt het toegestane byte-krediet toe, bij een langzamere verbinding neemt het af. In combinatie met TCP-pacing blijven bursts klein en komen bevestigingen sneller terug. Zo bereik ik merkbaar lagere <strong>Pieken in latentie<\/strong>, zonder de doorvoer onnodig te beperken.<\/p>\n\n<h2>Interactie per socket en per app<\/h2>\n\n<p>TSQ werkt alleen als ook de applicatie de tegendruk waarneemt. Daarom houd ik rekening met instellingen zoals <strong>SO_SNDBUF<\/strong>, <strong>TCP_NOTSENT_LOWAT<\/strong> en autocorking. Een te groot verzendbuffervenster kan op korte termijn veel bytes in de stack duwen; TSQ remt weliswaar af, maar de app merkt het pas op als <em>send()<\/em> geblokkeerd is of de foutcode EAGAIN retourneert. Met <strong>TCP_NOTSENT_LOWAT<\/strong> ik haal het \u201eniet-verzonden\u201c deel in userland terug en vul daarmee TSQ aan aan de kernelzijde. Autocorking (of expliciet <em>TCP_CORK<\/em>\/MSG_MORE) helpt bij het bundelen van kleine schrijfbewerkingen zonder dat dit leidt tot pieken in de latentie. Pacing-limieten per socket (bijv. via <em>SO_MAX_PACING_RATE<\/em>) sluiten aan bij TSQ: de frequentie zorgt voor een afvlakking in de tijd, de byte-limiet zorgt voor een beperking in de ruimte. Belangrijk: <strong>TCP_NODELAY<\/strong> schakelt Nagle uit en kan de interactiviteit vergroten, maar zonder TSQ neemt het risico op bursts toe; met TSQ heb ik beide onder controle.<\/p>\n\n<h2>Praktijkgids: zinvolle TSQ-waarden<\/h2>\n\n<p>Het algemene kader leg ik vast met <strong>net.ipv4.tcp_limit_output_bytes<\/strong> (Sysctl). De gebruikelijke standaardwaarden liggen tussen de 128 en 262 KB per flow. Voor veel web- en API-workloads kies ik lagere waarden, zodat interactieve reacties vlot blijven. Voor back-ups of replicatie verhoog ik de limiet gematigd, zolang de RTT stabiel blijft. Wie dieper in de queue-pagina wil duiken, vindt basisinformatie over <a href=\"https:\/\/webhosting.de\/nl\/server-pakketwachtrijen-netwerkstabiliteit-hosting-optimalisatie-latentie\/\">Pakketwachtrijen op de server<\/a>, die helpen bij de indeling.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Scenario<\/strong><\/th>\n      <th><strong>Link-snelheid<\/strong><\/th>\n      <th><strong>Richtwaarde tcp_limit_output_bytes<\/strong><\/th>\n      <th><strong>Doel<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>API\/HTTP zeer interactief<\/td>\n      <td>100 Mbit \u2013 1 Gbit<\/td>\n      <td>64\u2013128 KB<\/td>\n      <td>laag <strong>RTT<\/strong>, korte spikes<\/td>\n    <\/tr>\n    <tr>\n      <td>Gemengde belasting: web + downloads<\/td>\n      <td>1\u201310 Gbit<\/td>\n      <td>128\u2013256 KB<\/td>\n      <td>Balans uit <strong>Doorvoer<\/strong> en latentie<\/td>\n    <\/tr>\n    <tr>\n      <td>Replicatie\/back-ups<\/td>\n      <td>1\u201310 Gbit<\/td>\n      <td>256\u2013512 KB<\/td>\n      <td>constante bulkstroom, aanvaardbaar <strong>Latency<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>WAN met hoge RTT<\/td>\n      <td>10\u2013100 Mbit<\/td>\n      <td>96\u2013192 KB<\/td>\n      <td>kortere bursts, eerlijkere <strong>Cues<\/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 en congestiebeheer in combinatie<\/h2>\n\n<p>TSQ werkt aan de ingang van de <strong>QDisc<\/strong>, terwijl algoritmen zoals fq_codel de congestie op de lijn beheren. Samen zorgen ze ervoor dat wachtrijen worden verkort en dat de verdeling eerlijk blijft. Met <a href=\"https:\/\/webhosting.de\/nl\/tcp-bbr-congestiebeheersing-webserveroptimalisatie-bandbreedte\/\">TCP BBR<\/a> daar heb ik ook nog eens voordeel van, omdat realistischere RTT-metingen leiden tot een betere pacing en cwnd-regeling. CUBIC reageert ook soepeler als ik te lange wachttijden uitschakel. Zo groeit de doorvoer op een organische manier, terwijl de <strong>Reactietijd<\/strong> onder controle blijft.<\/p>\n\n<h2>Virtualisatie en cloudstacks<\/h2>\n\n<p>In VM\u2019s stapelen meerdere bufferniveaus zich op: gast-QDisc, virtio\/vhost-wachtrijen, host-QDisc en de fysieke NIC. Ik houd TSQ in de gast actief en stel daar een conservatieve limiet in, zodat er geen grote bursts in de host terechtkomen. Op de hypervisor zorg ik met fair QDiscs, gematigde TX-ringen en nette IRQ-pinning voor korte latentieketens. SR-IOV kan de latentie verlagen, maar verschuift de verantwoordelijkheid naar de gasten: zonder TSQ in de gast dreigen lange VF-wachtrijen. In containers past TSQ per <em>NetNS<\/em> zoals gewoonlijk; met cgroup-pacing en CPU-limieten voorkom ik dat een luidruchtige buur indirect de latentie verhoogt. Het is ook belangrijk om te kijken naar coalescing en offloads in het virtio-pad: overmatige bundeling verlengt de ACK-tijden, te weinig vermindert de effici\u00ebntie \u2013 ik pas dit aan op basis van de latentiedoelstelling, niet dogmatisch.<\/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>Wifi en embedded systemen: speciale gevallen correct aanpakken<\/h2>\n\n<p>Bij WLAN-verbindingen is de <strong>Aggregatie<\/strong> in de MAC-laag. Als ik te weinig bytes in het verzendpad laat staan, kan het stuurprogramma minder frames bundelen, wat de effici\u00ebntie vermindert. In dergelijke opstellingen verhoog ik de limiet voorzichtig en controleer ik de aggregatiegraad. OpenWrt- en embedded-platforms profiteren bovendien van gestroomlijnde paden in stuurprogramma\u2019s en minder atomaire bewerkingen. Ik test elke aanpassing onder re\u00eble draadloze belasting voordat ik een <strong>Profiel<\/strong> breed uitrollen.<\/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>Monitoring en statistieken die echt tellen<\/h2>\n\n<p>Ik observeer de <strong>RTT<\/strong>-Verdeling per socket en let op uitschieters, niet alleen op gemiddelden. Met ss, tc en exporters lees ik wachtrijlengtes, hertransmissies en pacing_rate uit. eBPF-programma\u2019s leveren mij gebeurtenissen wanneer sockets worden afgeremd en weer vrij komen. Time-to-First-Byte en het 95e\/99e percentiel laten zien of TSQ zijn werk doet. Zonder meetwaarden blijft elke <strong>Optimalisatie<\/strong> een blinde vlucht.<\/p>\n\n<h2>Zinvolle A\/B- en belastingstests<\/h2>\n\n<p>Ik meet TSQ-effecten op een reproduceerbare manier: eerst een baseline zonder wijzigingen, daarna ge\u00efsoleerde parameter-sweeps (bijv. 64, 96, 128, 192 KB). Voor gemengde workloads draai ik parallelle streams (bulk + veel korte verzoeken) en vergelijk ik het 95e en 99e percentiel van de latenties, niet alleen de mediaan. Als ik testruns duidelijk onderbreek (opwarmen, meetvenster, afkoelen), blijven artefacten herkenbaar. Ik let op constante factoren: dezelfde payload-patronen, identieke route\/MTU, identieke CPU-frequenties van server en client. Op WAN-trajecten simuleer ik vertraging\/jitter\/verlies met <em>tc netem<\/em>, om te controleren of de TSQ-limieten bij een hoge BDP niet te vroeg worden afgetopt. Pas wanneer de percentielen dichter bij elkaar komen te liggen en het aantal heruitzendingen en verlies stabiel blijven, neem ik de waarden over naar de productie.<\/p>\n\n<h2>Hardware-optimalisatie en details over stuurprogramma\u2019s<\/h2>\n\n<p>Ik controleer de TSO\/GSO-instellingen, de ringbuffer van de NIC en de IRQ-regeling, zodat <strong>TSQ<\/strong> goed werkt. Te grote TX-ringen verlengen de wachtrij bij het apparaat; te kleine ringen verminderen de benutting. Grove interruptbundeling vertraagt de ACK\u2019s, fijne bundeling verhoogt de CPU-belasting. Ik pas de uitleg aan de praktijk aan en verwijs ter inleiding naar <a href=\"https:\/\/webhosting.de\/nl\/interrupt-coalescing-netwerk-optimalisatie-serverflux\/\">Interrupt samenvoegen<\/a>. Het doel blijft een betrouwbare <strong>Latency<\/strong> bij een haalbare doorvoercapaciteit.<\/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 en CPU-affiniteit<\/h2>\n\n<p>Korte wachtrijen hebben weinig nut als pakketten voortdurend over NUMA-grenzen heen gaan. Ik koppel RX\/TX-wachtrijen via RSS\/irqbalance aan kernen van hetzelfde NUMA-domein waarop de app ook draait. Met XPS\/RPS bepaal ik welke CPU\u2019s TX-werk overnemen, waardoor ik cross-socket-hoppers vermijd. Minder cache-misses en minder lock-contention helpen TSQ indirect: Voltooiingen komen sneller terug, de socket wordt eerder \u201eontthroatled\u201c en er treden geen latentiepieken op. Bij zeer veel flows per host plan ik voldoende wachtrijen in en voorkom ik dat meerdere luidruchtige flows op dezelfde TX-ring met elkaar in botsing komen.<\/p>\n\n<h2>Stap voor stap: TSQ actief controleren<\/h2>\n\n<p>Ik begin met een blik op <strong>Sysctl<\/strong>: sysctl net.ipv4.tcp_limit_output_bytes geeft de huidige limiet weer. Vervolgens raadpleeg ik ss -tin voor afzonderlijke sockets, let ik op send\u2011q en rtt, en vergelijk ik belastingfasen met en zonder aanpassing van de limiet. Met iperf3 genereer ik achtergrondbelasting en meet ik tegelijkertijd API-responstijden om prioriteiten zichtbaar te maken. tc -s qdisc geeft me de pakket- en drop-aantallen van de uitgaande discipline. Blijven het 95e en 99e percentiel dicht bij elkaar en de <strong>CPU<\/strong>\u2011Belasting in het frame, pas de limiet aan.<\/p>\n\n<h2>Veelvoorkomende misvattingen en anti-patronen<\/h2>\n\n<ul>\n  <li>\u201eMeer buffer = meer prestaties\u201c: dit klopt voor doorvoertests zonder latentiedoel, maar gaat niet op voor interactieve diensten. TSQ vervangt overgedimensioneerde wachtrijen door een op de behoefte afgestemd krediet per flow.<\/li>\n  <li>\u201eTSQ kost doorvoer\u201c: Als het goed is ingesteld, beperkt TSQ de bursts, niet de gemiddelde snelheid. Bij bulk-workloads schaal ik de limiet gematigd omhoog en meet ik de percentielen in plaats van alleen de piek in Mbit\/s.<\/li>\n  <li>\u201ePacing alleen is voldoende\u201c: Tijdmatige afvlakking is belangrijk, maar zonder byte-limiet glijden grote GSO-frames toch in de QDisc. TSQ en pacing vullen elkaar aan.<\/li>\n  <li>\u201eE\u00e9n waarde voor alles\u201c: workloads, links en NIC\u2019s verschillen van elkaar. Ik werk met bereikwaarden en valideer per omgeving.<\/li>\n  <li>\u201eAlleen TCP is betrokken\u201c: de focus ligt op TCP, maar het systeem beschikt over nog meer instelmogelijkheden (bijvoorbeeld voor de UDP-belasting). Ik voorkom dat parallelle protocollen dezelfde wachtrijen ongecontroleerd verstoppen.<\/li>\n<\/ul>\n\n<h2>Conclusie: latentie doelgericht onder controle<\/h2>\n\n<p>TSQ verplaatst het beheer van driver-wachtrijen naar de <strong>Socket<\/strong> en vermindert zo congestie direct bij de bron. Ik beperk het aantal vooraf gebufferde bytes per flow en zorg zo voor snelle ACK\u2019s, een lagere RTT en eerlijk verdeelde wachtrijen. In combinatie met fq_codel en moderne congestiecontrole blijft de reactietijd ook onder belasting betrouwbaar. Voor speciale gevallen met wifi en embedded systemen hanteer ik aangepaste limieten en voer ik tests uit onder re\u00eble omstandigheden. Wie de statistieken in de gaten houdt en de limieten stapsgewijs aanpast, houdt de <strong>Latency<\/strong> consequent laag, zonder onnodig aan doorvoer in te boeten.<\/p>","protected":false},"excerpt":{"rendered":"<p>TCP Small Queues in de Linux-kernel beperkt het aantal gebufferde TCP-pakketten per flow en is een krachtig hulpmiddel voor het optimaliseren van de latentie. Ontdek hoe TSQ bufferbloat vermindert en de responstijden van servers verbetert.<\/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":"126","_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\/nl\/wp-json\/wp\/v2\/posts\/21034","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21034"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21034\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21027"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21034"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21034"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21034"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}