{"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-small-queues-linux-latency-optimization-network-performance","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/tcp-small-queues-linux-latency-optimization-netzwerkperformance\/","title":{"rendered":"TCP Small Queues: Targeted Reduction of Latency in Linux Networks"},"content":{"rendered":"<p>TCP Small Queues limits the number of pending bytes in the Linux outbound path per TCP flow, thereby reducing <strong>Latency<\/strong> including buffer bloat, in a targeted manner. I'll show how this mechanism works in the <strong>Linux networking<\/strong> Stack shows how I set reasonable limits and what interactions arise with pacing, QDiscs, and congestion control.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>Per-Flow Limit<\/strong>: TSQ caps the number of outstanding bytes per TCP socket.<\/li>\n  <li><strong>Less Bufferbloat<\/strong>: Shorter queues reduce RTT.<\/li>\n  <li><strong>Backpressure<\/strong>: Applications write more slowly when the limit is reached.<\/li>\n  <li><strong>Fairness<\/strong>: No single flow occupies an entire queue.<\/li>\n  <li><strong>Adaptive<\/strong> Control: The limit is based on the rate and segment size.<\/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>How TCP Small Queues Works<\/h2>\n\n<p>TSQ picks up where TCP segments leave off <strong>QDisc<\/strong> and passes it to the driver. When I write data to a socket, the kernel checks the bytes already allocated for that flow before each enqueue operation. If the flow reaches the limit, the logic marks the socket as throttled and stops further enqueue operations. Only when the network card frees up buffers is the socket allowed to send again, and I can push data back into the stack. This tight feedback loop keeps the <strong>Queues<\/strong> It's short and makes response times more predictable.<\/p>\n\n<h2>Why Long Queues Drive Up Response Times<\/h2>\n\n<p>Create large driver and QDisc queues <strong>Buffer bloat<\/strong>, especially with TSO\/GSO and high outbound traffic volumes. A large download can fill up the outbound queues, while interactive flows such as SSH, API calls, or VoIP are put on hold. The overflowing queue then dominates the <strong>RTT<\/strong> instead of the actual link time. Congestion control reacts slowly because ACKs arrive late, and makes poorer CWND decisions. TSQ limits the number of pre-buffered bytes per flow so that small, time-critical packets are sent over the link quickly.<\/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>A Look Under the Hood: What the Kernel Does<\/h2>\n\n<p>Under the hood, the kernel does not count \u201epackets,\u201c but rather bytes\u2014more precisely, the memory bytes that the socket has already placed in the queue. What matters is what the stack contains in terms of skbuff structures, including <em>truesize<\/em> has been allocated but has not yet been processed by the NIC. TSQ links this to a <strong>Throttle\/Unthrottle<\/strong>-Path: If a socket reaches the credit limit, the stack sets a throttling flag and does not resume until TX operations are complete (NAPI\/IRQ) <em>write_space()<\/em> so that the application can send again. This feedback is faster than purely loss-based signals from congestion control and takes effect before the QDisc. With TSO\/GSO, the mechanism remains effective because the limit at the <em>before<\/em> applies the byte budget associated with the segmentation: Large superframes are only admitted into the QDisc if there is sufficient credit available, which helps contain bursts.<\/p>\n\n<h2>Dynamic Limits and Pacing<\/h2>\n\n<p>I benefit from TSQ because the limit doesn't remain strictly static, but rather adjusts to <strong>Rate<\/strong> and takes segment size into account. The goal is about one millisecond of data in the transmission path per flow, regardless of whether the rate is 100 Mbit, 1 Gbit, or 10 Gbit. With a fast connection, the allowed byte credit increases; with a slow connection, it decreases. In combination with TCP pacing, bursts remain small and ACKs return faster. This way, I achieve noticeably lower <strong>Latency peaks<\/strong>, without unnecessarily reducing throughput.<\/p>\n\n<h2>Per-Socket and App Interaction<\/h2>\n\n<p>TSQ is only effective if the application also senses the backpressure. Therefore, I take into account settings such as <strong>SO_SNDBUF<\/strong>, <strong>TCP_NOTSENT_LOWAT<\/strong> and autocorking. A send buffer window that is too large can push many bytes onto the stack in a short period of time; TSQ does slow things down, but the app doesn't notice it until <em>send()<\/em> is blocked or returns EAGAIN. With <strong>TCP_NOTSENT_LOWAT<\/strong> I adjust the \u201eunsent\u201c portion in userland and use it to supplement TSQ on the kernel side. Autocorking (or explicitly <em>TCP_CORK<\/em>\/MSG_MORE) helps bundle small writes without causing latency spikes. Pacing limits per socket (e.g., via <em>SO_MAX_PACING_RATE<\/em>) are compatible with TSQ: The rate smooths out over time, and the byte limit restricts the data in space. Important: <strong>TCP_NODELAY<\/strong> It disables Nagle and can increase interactivity, but without TSQ, the risk of bursts increases; with TSQ, I have both under control.<\/p>\n\n<h2>Practical Guide: Useful TSQ Values<\/h2>\n\n<p>I establish the global framework with <strong>net.ipv4.tcp_limit_output_bytes<\/strong> (Sysctl). Typical defaults range from 128 to 262 KB per flow. For many web and API workloads, I choose lower values to keep interactive responses snappy. For backups or replication, I raise the limit moderately, as long as the RTT remains stable. If you want to dive deeper into the queue page, you\u2019ll find the basics at <a href=\"https:\/\/webhosting.de\/en\/server-packet-queues-network-stability-hosting-optimization-latency\/\">Packet Queues on the Server<\/a>, which help with classification.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Scenario<\/strong><\/th>\n      <th><strong>Link Rate<\/strong><\/th>\n      <th><strong>Guideline: tcp_limit_output_bytes<\/strong><\/th>\n      <th><strong>Goal<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>API\/HTTP: Highly Interactive<\/td>\n      <td>100 Mbit \u2013 1 Gbit<\/td>\n      <td>64\u2013128 KB<\/td>\n      <td>low <strong>RTT<\/strong>, short spikes<\/td>\n    <\/tr>\n    <tr>\n      <td>Mixed Load: Web + Downloads<\/td>\n      <td>1\u201310 Gbit<\/td>\n      <td>128\u2013256 KB<\/td>\n      <td>Balance off <strong>Throughput<\/strong> and latency<\/td>\n    <\/tr>\n    <tr>\n      <td>Replication\/Backups<\/td>\n      <td>1\u201310 Gbit<\/td>\n      <td>256\u2013512 KB<\/td>\n      <td>Constant bulk flow, acceptable <strong>Latency<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>WAN with high RTT<\/td>\n      <td>10\u2013100 Mbit<\/td>\n      <td>96\u2013192 KB<\/td>\n      <td>shorter bursts, fairer <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 and Congestion Control Working Together<\/h2>\n\n<p>TSQ operates at the entrance to the <strong>QDisc<\/strong>, while algorithms such as fq_codel manage congestion on the link. Together, they reduce queues and ensure fair distribution. With <a href=\"https:\/\/webhosting.de\/en\/tcp-bbr-congestion-control-web-server-optimization-bandwidth\/\">TCP BBR<\/a> I also benefit because more realistic RTT measurements lead to better pacing and cwnd control. CUBIC also responds more smoothly when I eliminate excessive queueing times. This allows throughput to grow organically, while the <strong>Response time<\/strong> remains under control.<\/p>\n\n<h2>Virtualization and Cloud Stacks<\/h2>\n\n<p>In VMs, multiple buffer levels add up: guest QDisc, virtio\/vhost queues, host QDisc, and the physical NIC. I keep TSQ active in the guest and set a conservative limit there to prevent large bursts from reaching the host. On the hypervisor, I ensure short latency chains by using fair QDiscs, moderate TX rings, and proper IRQ pinning. SR-IOV can reduce latency but shifts responsibility to the guests: without TSQ in the guest, long VF queues are a risk. In containers, TSQ per <em>NetNS<\/em> As usual, I use cgroup pacing and CPU limits to prevent a noisy neighbor from indirectly increasing latency. It\u2019s also important to look at coalescing and offloads in the virtio path: excessive coalescing lengthens ACKs, while too little reduces efficiency\u2014I adjust based on the latency target, not dogmatically.<\/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 and Embedded Systems: Handling Special Cases Correctly<\/h2>\n\n<p>On Wi-Fi connections, the <strong>Aggregation<\/strong> at the MAC layer. If I set the number of bytes in the transmission path too low, the driver can\u2019t bundle as many frames, which reduces efficiency. In such setups, I carefully increase the limit and check the aggregation level. OpenWrt and embedded platforms also benefit from streamlined driver paths and fewer atomic operations. I test every adjustment under real-world wireless load before I <strong>Profile<\/strong> roll out widely.<\/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 and metrics that really count<\/h2>\n\n<p>I observe the <strong>RTT<\/strong>\u2014Distribution per socket, and I look for outliers, not just averages. Using ss, tc, and exporters, I read queue lengths, retransmissions, and pacing_rate. eBPF programs send me events when sockets are throttled and become available again. Time-to-First-Byte and the 95th\/99th percentiles show whether TSQ is having the desired effect. Without measurement data, any <strong>Optimization<\/strong> a flight by blind flight.<\/p>\n\n<h2>Meaningful A\/B and load tests<\/h2>\n\n<p>I measure TSQ effects in a reproducible manner: First, a baseline without any changes, then isolated parameter sweeps (e.g., 64, 96, 128, 192 KB). For mixed workloads, I run parallel streams (bulk + many short requests) and compare the 95th and 99th percentiles of latencies, not just the median. Even when I clearly segment test runs (warm-up, measurement window, cool-down), artifacts remain detectable. I ensure consistency: the same payload patterns, identical route\/MTU, and identical server and client CPU frequencies. On WAN links, I simulate delay, jitter, and loss using <em>tc netem<\/em>, to check whether TSQ limits cap too early at high BDP. Only when the percentiles narrow and retransmits\/losses remain stable do I implement the values into production.<\/p>\n\n<h2>Hardware Tuning and Driver Details<\/h2>\n\n<p>I'm checking the TSO\/GSO settings, the NIC's ring buffer, and IRQ control so that <strong>TSQ<\/strong> works smoothly. TX rings that are too large extend the queue at the device; those that are too small reduce utilization. Coarse interrupt bundling delays ACKs, while fine bundling increases the CPU load. I adapt the presentation to real-world scenarios and, to get started, refer to <a href=\"https:\/\/webhosting.de\/en\/interrupt-coalescing-network-optimization-serverflux\/\">Interrupt coalescing<\/a>. The goal remains a reliable <strong>Latency<\/strong> with a viable throughput.<\/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, and CPU Affinity<\/h2>\n\n<p>Short queues aren't very helpful if packets are constantly crossing NUMA boundaries. I bind RX\/TX queues to cores in the same NUMA domain where the app is running using RSS\/irqbalance. Using XPS\/RPS, I control which CPUs handle TX work, thereby avoiding cross-socket hopping. Fewer cache misses and less lock contention indirectly benefit TSQ: Completions return faster, the socket is \u201eunthrottled\u201c sooner, and latency spikes are avoided. When there are a very large number of flows per host, I allocate sufficient queues and prevent multiple high-traffic flows from colliding on the same TX ring.<\/p>\n\n<h2>Step-by-Step: Checking TSQ Status<\/h2>\n\n<p>I start with a look at <strong>Sysctl<\/strong>: `sysctl net.ipv4.tcp_limit_output_bytes` displays the current limit. I then use `ss -tin` to examine individual sockets, paying attention to `send-q` and `rtt`, and compare load phases with and without limit adjustments. Using iperf3, I generate background load and measure API response times in parallel to highlight priorities. tc -s qdisc provides me with packet and drop counts for the output discipline. If the 95th and 99th percentiles remain close together and the <strong>CPU<\/strong>-Load within the frame; adjust the limit accordingly.<\/p>\n\n<h2>Common Mistakes and Anti-Patterns<\/h2>\n\n<ul>\n  <li>\u201eMore buffer = more performance\u201c: This holds true for throughput tests without a latency target, but fails for interactive services. TSQ replaces oversized queues with demand-based credit per flow.<\/li>\n  <li>\u201eTSQ costs throughput\u201c: When set correctly, TSQ limits bursts, not the average rate. For bulk workloads, I scale the limit moderately high and measure the percentiles instead of just the peak Mbit\/s.<\/li>\n  <li>\u201ePacing alone is enough\u201c: Time smoothing is important, but without a byte cap, large GSO frames will still slip into the QDisc. TSQ and pacing complement each other.<\/li>\n  <li>\u201eOne value for all\u201c: Workloads, links, and NICs differ. I work with range values and validate them on a per-environment basis.<\/li>\n  <li>\u201eOnly TCP is affected\u201c: The focus is on TCP, but there are other configuration options in the system (e.g., for UDP load). I prevent parallel protocols from clogging up the same queues in an uncontrolled manner.<\/li>\n<\/ul>\n\n<h2>Conclusion: Keeping Latency Under Control<\/h2>\n\n<p>TSQ shifts control of driver queues to the <strong>socket<\/strong> and thus reduces congestion right at the source. I limit the number of pre-buffered bytes per flow, ensuring fast ACKs, lower RTT, and fairly shared queues. Combined with fq_codel and modern congestion control, the response time remains reliable even under load. I handle special cases involving Wi-Fi and embedded systems with customized limits and tests under real-world conditions. By monitoring the metrics and gradually adjusting the limits, you can maintain the <strong>Latency<\/strong> consistently low, without losing unnecessary throughput.<\/p>","protected":false},"excerpt":{"rendered":"<p>TCP Small Queues in the Linux kernel limits the number of TCP packets buffered per flow and is a powerful tool for latency optimization. Learn how TSQ reduces bufferbloat and improves server response times.<\/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":"85","_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\/en\/wp-json\/wp\/v2\/posts\/21034","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=21034"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21034\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21027"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21034"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21034"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21034"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}