# TCP Published articles for TCP. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## The Evolution of HTTP, Clearly Explained DevFeed: [The Evolution of HTTP, Clearly Explained]() Original publisher: [Read original article]() Author: Nikki Siapno Published: 2026-09-04T16:39:02Z Content type: article Language: en Sources: [Level Up Coding System Design Newsletter]() Topics: [HTTP](), [client](), [servers](), [Caching](), [Web]() Tags: [browser](), [caching](), [encoding](), [evolution](), [http](), [http-3](), [protocol](), [request](), [responses](), [server](), [tcp]() ### AI overview An explanatory article traces HTTP from versions 0.9 through 1.1, describing how headers, status codes, persistent connections, caching, and chunked transfer encoding addressed the web's growing scale and performance needs. It introduces HTTP/3 as part of that broader evolution. ### Source excerpt From 0.9 to 3.0: What changed and why? ## Networking Concepts Every DevOps Engineer Needs to Know DevFeed: [Networking Concepts Every DevOps Engineer Needs to Know]() Original publisher: [Read original article]() Author: Pramodh Kumar M Published: 2026-08-14T17:14:08Z Content type: tutorial Language: en Sources: [Kubernetes - KodeKloud Blog | DevOps, Cloud, Kubernetes, AI Tutorials & More]() Topics: [networking](), [DevOps](), [browser](), [Kubernetes]() Tags: [browser](), [cidr-and-subnets](), [cloud](), [conntrack](), [devops](), [dns](), [ephemeral-ports](), [kubernetes](), [kubernetes-networking](), [linux](), [mtu-mismatch](), [nat-and-snat](), [network](), [network-troubleshooting-commands](), [networking](), [networking-concepts-for-devops](), [osi-model-for-devops](), [platform-engineering](), [proxy](), [routing](), [tcp](), [tcp-handshake](), [timeout](), [tls-handshake](), [vpn]() ### AI overview A tutorial follows a request from a browser to a container to explain networking concepts relevant to DevOps engineers. It maps symptoms such as connection refusal, timeouts, resets, and packet-size-related hangs to network layers and discusses diagnosis across VPN gateways, Kubernetes, and other infrastructure. ### Source excerpt Follow one request from a browser to a container and back. Every networking concept you actually need shows up on that path, in order, and so does every place it breaks. ## Shared Host Ephemeral Port Exhaustion Caused Overnight Job Failures DevFeed: [Shared Host Ephemeral Port Exhaustion Caused Overnight Job Failures]() Original publisher: [Read original article]() Author: PULKIT GARG Published: 2026-08-11T05:58:23Z Content type: article Language: en Sources: [Housing.com]() Topics: [ephemeral ports](), [incident](), [Kernel]() Tags: [incident](), [port](), [production-issue](), [rate-limiting](), [ruby-on-rails](), [tcp]() ### AI overview An engineering incident report explains how a neighboring bulk job exhausted the shared operating system's ephemeral TCP port pool, causing scheduled background jobs to fail until the temporary traffic pressure subsided. ### Source excerpt A neighbor's bulk job drained every ephemeral port on a shared box. Twice. Here's the one kernel setting that would have stopped it -- and the architecture that makes it a non-issue. At 1:38 AM, one of our background-job services started failing. Scheduled jobs -- the nudges and reminders we send users overnight -- began throwing an error most engineers rarely see: Errno::EADDRNOTAVAIL -- Cannot assign requested address Not "connection refused." Not "timeout." Cannot assign requested address. The machine wasn't saying the other end was down. It was saying it had run out of addresses to call from. Here's the strange part: we hadn't deployed anything. Our code was untouched for days. And by ~3 AM it healed itself, with nobody doing a thing. Two nights later, same window, it happened again. The bug wasn't in our service. It was in a service we don't own -- and don't even talk to. Act 1: A crime scene with no suspect ~7,800 job executions failed across the two nights. The first night slipped in under the alerting threshold entirely -- we only found it in the errors inbox after the fact. Everything about it was confusing: Our service hadn't changed. The internal APIs we call were all healthy. It happened in a tight window (~1:30-3:00 AM), then vanished. No human fixed it. It just... stopped. An outage that fixes itself is telling you something important: the thing that broke wasn't yours, and the pressure that caused it was temporary. Act 2: The noisy neighbor That service doesn't run on its own machine. It shares one box with about ten other apps -- a normal, cost-efficient setup. What's easy to forget is what they silently share: not just CPU and memory, but the operating system's ephemeral port pool. Quick refresher. Every time a program opens an outbound TCP connection, the OS assigns it a temporary "ephemeral" source port. That pool is finite -- by default, roughly 28,000 ports. And on a shared box, every app draws from the same pool. Ephemeral ports are an unmonitored, multi ## tcpdump: analiza tráfico de red en terminal DevFeed: [tcpdump: analiza tráfico de red en terminal]() Original publisher: [Read original article]() Author: Antonio Pérez Published: 2026-08-01T12:00:00Z Content type: tutorial Language: es Sources: [tengoping.com]() Topics: [Command-line interface](), [Linux](), [Firewall]() Tags: [firewall](), [linux](), [port](), [resolver](), [tcp](), [terminal]() ### AI overview A practical guide to using tcpdump from the terminal to capture and inspect network traffic, apply filters, interpret TCP packets, and save or reread pcap files while troubleshooting network problems. ### Source excerpt Guía práctica de tcpdump: sintaxis de filtros, lectura de paquetes y captura en archivos pcap para depurar problemas de red desde terminal. ## netcat (nc) Command in Linux, with Examples DevFeed: [netcat (nc) Command in Linux, with Examples]() Original publisher: [Read original article]() Author: Hayden James Published: 2026-08-01T10:42:27Z Content type: tutorial Language: en Sources: [Hayden James]() Topics: [networking](), [Linux](), [Tool]() Tags: [blog](), [commands](), [connectivity](), [debugging](), [examples](), [guide](), [linux](), [networking](), [port](), [security](), [server](), [sysadmins](), [tcp](), [tool](), [troubleshooting](), [udp]() ### AI overview A practical guide to the Linux nc (netcat) command, covering port testing, file transfers, banner grabbing, reverse shells, proxies, and network-service debugging over TCP and UDP. It also explains implementation differences across OpenBSD netcat, Ncat, BusyBox, and traditional netcat. ### Source excerpt The nc command (netcat) is a lightweight but surprisingly powerful networking tool for port testing, file transfers, banner grabbing, and connectivity debugging. This practical guide covers the flags and real-world usage patterns that Linux users and sysadmins actually reach for. Continue reading... ## Your SQS consumer can hang forever by default DevFeed: [Your SQS consumer can hang forever by default]() Original publisher: [Read original article]() Author: Ivan Cernja Published: 2026-07-28T00:00:00Z Content type: article Language: en Sources: [Encore Updates]() Topics: [Amazon Simple Queue Service (SQS)](), [SDK](), [Rust](), [Amazon Web Services]() Tags: [aws](), [health-check](), [queue](), [retry](), [rust](), [sdk](), [sqs](), [tcp](), [timeout]() ### AI overview The article explains that the AWS Rust SDK has no request timeout by default. A failed or silently dropped connection can leave an SQS receive waiting indefinitely, stopping a sequential consumer loop while the process and health check still appear healthy. It describes fixing the issue with a per-attempt timeout. ### Source excerpt The AWS Rust SDK ships no request timeout by default, so one SQS receive on a dead connection can hang a whole consumer with nothing in the logs. ## Нейро сети для самых маленьких. Часть первая (которая после нулевой). Удобство в прокрустовом ложе оптимизации DevFeed: [Нейро сети для самых маленьких. Часть первая (которая после нулевой). Удобство в прокрустовом ложе оптимизации]() Original publisher: [Read original article]() Author: eucariot (Яндекс, Yandex Cloud & Yandex Infrastructure) Published: 2026-07-01T07:00:06Z Content type: article Language: ru Sources: [Яндекс - Как мы делаем Яндекс / Статьи]() Topics: [High-Performance Computing](), [GPU](), [InfiniBand](), [NVLink](), [Linux]() Tags: [ethernet](), [gpu](), [gpudirect-rdma](), [high-performance-computing](), [infiniband](), [linux](), [nvidia](), [nvlink](), [performance](), [rdma](), [roce](), [tcp](), [zero-copy]() ### AI overview This introductory article in a series explains the infrastructure used to train and run neural networks and for high-performance computing. It surveys specialized technologies including GPUs and TPUs, RDMA, kernel bypass, NVLink, InfiniBand, and RoCE, arguing that specialized solutions can outperform and cost less than a generic Linux and Ethernet/IP stack at scale. ### Source excerpt Это первая (после нулевой) статья из серии Нейро сети для самых маленьких, в которой мы разбираем инфраструктуру для запуска нейронных сетей. Для обучения и инференса нейросетей и для любых видов High Performance Computing используются специализированные технологии: GPU/TPU, RDMA, Kernel bypass, NVLink, InfiniBand, RoCE и другие. Про некоторые из них большинство только что-то слышали, но сталкиваться с ними не приходилось. Нельзя просто взять ванильный стек Linux, воткнуть в него 400Gb Ethernet+IP и получить рабочее решение. Почему? Потому что общее решение на масштабе в большинстве случаев проигрывает специализированным как в скорости, так и в стоимости. Как бы странно последнее ни звучало. Читать далее ## SSH Port 22: Custom Ports, Port Forwarding Security, and Production SSH Hardening DevFeed: [SSH Port 22: Custom Ports, Port Forwarding Security, and Production SSH Hardening]() Original publisher: [Read original article]() Author: info@goteleport.com (Matt Keib) Published: 2026-05-01T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Security](), [OpenSSH](), [ssh](), [Authentication](), [rate-limiting](), [Authorization](), [configuration]() Tags: [configuration](), [hardening](), [port](), [rate-limiting](), [security](), [server](), [ssh](), [tcp](), [tcp-handshake]() ### AI overview This article explains that SSH port 22 is a historical TCP entry point with no inherent cryptographic or authentication significance. It covers port forwarding risks, cryptographic and authentication configuration, rate limiting, and production SSH hardening. ### Source excerpt Learn about SSH port 22, its limitations, port forwarding security, and how to harden production SSH. ## Worth Reading: BGP Route Leaks, TCP Latency, and Datacenter Packet-Processing Energy DevFeed: [Worth Reading: BGP Route Leaks, TCP Latency, and Datacenter Packet-Processing Energy]() Original publisher: [Read original article]() Author: Russ Published: 2026-04-29T19:44:35Z Content type: article Language: en Sources: [rule 11 reader]() Topics: [BGP](), [Networks](), [datacenter](), [systems](), [Internet]() Tags: [bgp](), [datacenter](), [internet](), [networks](), [privacy](), [quic](), [systems](), [tcp](), [technical](), [worth-reading]() ### AI overview This developer reading roundup covers BGP route leaks that may be brief artifacts of normal convergence, the effects of long round-trip times on TCP, the energy costs of host-side packet processing in high-speed datacenter networks, changing satellite internet capabilities, orbital models, and what unsolicited QUIC traffic can reveal about deployments and metadata privacy. ### Source excerpt Many BGP route leaks reported by automated detection systems are actually brief, low-impact artifacts of normal BGP convergence. Long round-trip times have serious consequences for protocols like TCP, which rely on a steady stream of acknowledgements (ACKs) to manage sending rates, estimate delay, and trigger retransmissions. As datacenter networks evolve toward ultra-high-speed links, the energy footprint of host-side packet processing grows increasingly significant. The old perception of satellite internet as slow, expensive, and marginal is increasingly outdated. Today's market includes multiple orbital models, each with distinct technical and operational characteristics. What can we learn about QUIC deployments just by listening to unsolicited QUIC traffic? This question becomes specifically exciting since QUIC aims to enhance privacy by obfuscating metadata. ## How TCP Handshake Works DevFeed: [How TCP Handshake Works]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-03-31T08:17:52Z Content type: tutorial Language: en Sources: [System Design Codex]() Topics: [Handshake](), [client](), [servers]() Tags: [client](), [communication](), [http-3](), [quic](), [sequence](), [server](), [tcp](), [tcp-handshake]() ### AI overview A tutorial explaining the TCP three-way handshake. It describes how a client sends SYN, a server responds with SYN-ACK, and the client completes the connection with ACK, including the role of initial sequence numbers and control flags. ### Source excerpt The 3 step process ## HTTP/2 System Design: How It Fixes HTTP/1.1 DevFeed: [HTTP/2 System Design: How It Fixes HTTP/1.1]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-03-16T00:00:00Z Content type: tutorial Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [HTTP](), [Latency](), [Concurrency](), [Compression]() Tags: [compression](), [concurrency](), [http](), [http1-1](), [http2](), [latency](), [networking](), [parallel](), [performance](), [protocols](), [reliability](), [rest](), [system-design](), [tcp](), [tls](), [web-performance]() ### AI overview This article explains how HTTP/2 addresses HTTP/1.1 limitations through binary framing, multiplexed streams over one TCP connection, HPACK header compression, server push, and stream prioritisation. It also describes how HTTP/2 preserves HTTP semantics while improving latency and reducing application-layer head-of-line blocking. ### Source excerpt HTTP/1.1 hit concurrency limits that forced hacks like domain sharding and sprite sheets. HTTP/2 keeps HTTP semantics but replaces the wire format with binary framing, multiplexed streams over a single TCP connection, HPACK header compression, server push, and stream prioritisation, which removes most head-of-line blocking at the HTTP layer. ## Analysis of Dahua CCTV Camera Authentication DevFeed: [Analysis of Dahua CCTV Camera Authentication]() Original publisher: [Read original article]() Published: 2025-12-01T23:00:00Z Content type: tutorial Language: en Sources: [Dennis Yurichev]() Topics: [webcam](), [hash](), [Python]() Tags: [auth](), [camera](), [hash](), [python](), [tcp]() ### AI overview A pentesting-oriented analysis of Dahua CCTV camera authentication over its proprietary TCP protocol. It describes a fake Python server used to observe a camera login and presents the known portion of the hash calculation, while noting that the remaining 16 bytes are not understood and no Hashcat workflow was found. ### Source excerpt [Pentesting] Dahua (CCTV cameras) auth ## \[Pentesting\] ONVIF (CCTV cameras) auth DevFeed: [\[Pentesting\] ONVIF (CCTV cameras) auth]() Original publisher: [Read original article]() Published: 2025-11-27T23:00:00Z Content type: tutorial Language: en Sources: [Dennis Yurichev]() Topics: [passwords](), [XML](), [Python]() Tags: [auth](), [camera](), [cameras](), [password](), [python](), [tcp](), [xml]() ### AI overview This article examines ONVIF authentication for CCTV cameras over TCP. It explains the username, password digest, nonce, and date fields, gives the digest calculation, and describes using Hashcat to crack a known password digest. ### Source excerpt [Pentesting] ONVIF (CCTV cameras) auth ## An overview of the PPPP protocol for IoT cameras DevFeed: [An overview of the PPPP protocol for IoT cameras]() Original publisher: [Read original article]() Author: Wladimir Palant Published: 2025-11-05T15:11:36Z Content type: article Language: en Sources: [Almost Secure]() Topics: [Internet of things](), [Protocol (disambiguation)](), [P2P](), [Reverse Engineering](), [Security]() Tags: [cameras](), [firmware](), [iot](), [network](), [p2p](), [protocol](), [reverse-engineering](), [security-research](), [servers](), [tcp]() ### AI overview An overview of the PPPP protocol used primarily by network-connected IoT cameras. The article explains that PPPP relies on central servers while allowing bulk data transfer through direct client-to-device connections, and describes device identifiers, connection establishment, fallback mechanisms, redundant servers, and related protocol research. ### Source excerpt My previous article on IoT "P2P" cameras couldn't go into much detail on the PPPP protocol. However, there is already lots of security research on and around that protocol, and I have a feeling that there is way more to come. There are pieces of information on the protocol scattered throughout the web, yet every one approaching from a very specific narrow angle. This is my attempt at creating an overview so that other people don't need to start from scratch. While the protocol can in principle be used by any kind of device, it is mostly being used for network-connected cameras. It isn't really peer-to-peer as advertised but rather relies on central servers, yet the protocol allows to transfer the bulk of data via a direct connection between the client and the device. It's hard to tell how many users there are but there are lots of apps, I'm sure that I haven't found all of them. There are other protocols with similar approaches being used for the same goal. One is used by ThroughTek's Kalay Platform which has the interesting string "Charlie is the designer of P2P!!" in its codebase (32 bytes long, seems to be used as "encryption" key for some non-critical functionality). I recognize both the name and the "handwriting," it looks like PPPP protocol designer found a new home here. Yet PPPP seems to be still more popular than the competition, thanks to it being the protocol of choice for cheap low-end cameras. Disclaimer: Most of the information below has been acquired by analyzing public information as well as reverse engineering applications and firmware, not by observing live systems. Consequently, there can be misinterpretations. Contents The general design The network ports The device IDs The protocol variants CS2 Network Yi Technology iLnk HLP2P "Encryption" "Secret" messages Applications Changelog The general design The protocol's goal is to serve as a drop-in replacement for TCP. Rather than establish a connection to a known IP address (or a name to be resolved ## Adding a Syslog Server to a netlab Lab Topology DevFeed: [Adding a Syslog Server to a netlab Lab Topology]() Original publisher: [Read original article]() Published: 2025-10-27T06:23:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [Logging](), [Containers](), [Ansible](), [Open Source]() Tags: [ansible](), [configuration](), [container](), [containers](), [github](), [json](), [logging](), [logs](), [netlab](), [ospf](), [router](), [server](), [storage](), [tcp](), [udp]() ### AI overview A tutorial shows how to add an Rsyslog-based Syslog server to a netlab lab topology. It configures a collector container to receive logs over TCP and UDP, adds Arista cEOS router nodes, applies logging configuration through templates, and verifies the resulting log files. ### Source excerpt netlab does not support a Syslog server (yet), but it's really easy to add one to your lab topology, primarily thanks to the Rsyslog team publishing a ready-to-run container. Let's do it ;) Adding a Syslog Server Rsyslog is an open-source implementation of a Syslog server (with many bells and whistles, most of which we won't use) that can (among other things) log incoming messages to a file. Even better (for our use case), the Rsyslog team regularly publishes Rsyslog containers; we'll use the rsyslog/rsyslog-collector container because it can "receive logs via UDP, TCP, and optionally RELP, and can send them to storage backends or files." Read more ... ## Using the OSI Model for Effective Production Issue Debugging DevFeed: [Using the OSI Model for Effective Production Issue Debugging]() Original publisher: [Read original article]() Author: Kamal Kumar Published: 2025-08-28T17:37:45Z Content type: tutorial Language: en Sources: [Housing.com]() Topics: [debugging](), [networking](), [Network](), [Routing (disambiguation)](), [Server](), [Authentication](), [Encryption](), [configuration](), [business logic](), [Framework]() Tags: [analysis](), [apis](), [authentication](), [configuration](), [debugging](), [devops](), [errors](), [firewalls](), [load](), [mapping](), [network](), [osi-model](), [production-debugging](), [production-issue](), [rca](), [root-cause-analysis](), [routing](), [servers](), [sre](), [tcp](), [troubleshooting](), [udp](), [web]() ### AI overview This tutorial explains how to use the seven-layer OSI model to structure root cause analysis for production alerts. It recommends checking lower layers for network and gateway errors, and higher layers for application and client errors, including connectivity, routing, logs, APIs, authentication, and configuration. ### Source excerpt In production environments, debugging alerts can sometimes feel like finding a needle in a haystack. Over the years, I've found the OSI (Open Systems Interconnection) model to be a reliable guide during Root Cause Analysis (RCA) of production issues. What is the OSI Model? The OSI model is a conceptual framework that standardizes the functions of a telecommunication or computing system into seven layers: Physical Layer -- Hardware, cables, switches Data Link Layer -- MAC addresses, switches, network topology Network Layer -- IP addressing, routing Transport Layer -- TCP/UDP, ports, session reliability Session Layer -- Session management, authentication Presentation Layer -- Data translation, encryption Application Layer -- APIs, web servers, applications How I Use OSI Layers in RCA: When I debug production alerts, I follow different approaches depending on the type of error: Network / Gateway Errors (e.g., 502, 504): These errors usually indicate communication issues between services. I start from the bottom layers (Physical -> Network -> Transport) to check connectivity, firewalls, routing, or load balancers. Application / Client Errors (e.g., 500, 503, 404): These errors generally originate from the application or business logic. I start from the top layers (Application -> Presentation -> Session) to check service logs, APIs, authentication issues, or configuration problems. Why this approach works: Following the OSI model provides a structured, layer-by-layer method for troubleshooting, ensuring that we don't miss low-level network issues or high-level application errors. It helps reduce mean time to resolution (MTTR) and improves the quality of RCA reports. Takeaway: The OSI model is not just a theoretical concept -- it's a practical tool that can guide engineers through complex production debugging. Next time you face a tricky alert, try mapping it to the OSI layers, and you might find the root cause faster than you think. Using the OSI Model for Effective Production Issue ## Beware the false false-positive: how to distinguish HTTP pipelining from request smuggling DevFeed: [Beware the false false-positive: how to distinguish HTTP pipelining from request smuggling]() Original publisher: [Read original article]() Author: James Kettle Published: 2025-08-19T14:30:44Z Content type: article Language: en Sources: [PortSwigger Research]() Topics: [HTTP](), [vulnerability]() Tags: [2025](), [false-positive](), [how-to](), [http](), [tcp](), [tls](), [vulnerability]() ### AI overview This article explains how to distinguish HTTP pipelining, keep-alive, and connection reuse from genuine HTTP request smuggling vulnerabilities. It recommends disabling connection reuse when testing and introduces Burp Suite tools that help analyze low-level HTTP behavior. ### Source excerpt Sometimes people think they've found HTTP request smuggling, when they're actually just observing HTTP keep-alive or pipelining. This is usually a false positive, but sometimes there's actually a real ## HTTP/1.1 must die: the desync endgame DevFeed: [HTTP/1.1 must die: the desync endgame]() Original publisher: [Read original article]() Author: James Kettle Published: 2025-08-06T22:20:00Z Content type: article Language: en Sources: [PortSwigger Research]() Topics: [HTTP](), [Security](), [Vulnerabilities](), [Parser](), [Open Source]() Tags: [2025](), [akamai](), [cloudflare](), [http](), [issue](), [netlify](), [open-source](), [paper](), [protocol](), [security](), [tcp](), [tls](), [vulnerabilities](), [web]() ### AI overview This paper argues that HTTP/1.1 has a fundamental request-boundary flaw that enables HTTP desync and request smuggling attacks. It presents attack techniques, case studies involving Akamai, Cloudflare, and Netlify, an open-source detection toolkit, and the case for replacing HTTP/1.1 with HTTP/2 or later. ### Source excerpt Abstract Upstream HTTP/1.1 is inherently insecure and regularly exposes millions of websites to hostile takeover. Six years of attempted mitigations have hidden the issue, but failed to fix it. This p ## How We Export Postgres Logs to Third-Party Services DevFeed: [How We Export Postgres Logs to Third-Party Services]() Original publisher: [Read original article]() Author: Roman Zaynetdinov Published: 2025-06-24T16:27:45Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Logging](), [OpenTelemetry](), [log management](), [Kubernetes](), [observability](), [Protocol (disambiguation)]() Tags: [architecture](), [blog](), [blog-post](), [company](), [config](), [configuration](), [datadog](), [implementation](), [kubernetes](), [logging](), [logs](), [metrics](), [observability](), [opentelemetry](), [platform](), [postgres](), [product](), [tcp](), [third-party]() ### AI overview The article explains how Postgres logs are exported to third-party observability platforms. Because the OpenTelemetry Collector could not scrape Kubernetes pod logs by labels and NeonVM contains multiple processes, the implementation uses a push-based design: Postgres sends selected logs through TCP syslog to an OpenTelemetry Collector, which enriches them with Kubernetes metadata and forwards them to Datadog or another destination. ### Source excerpt We've been supporting metrics export to Datadog for a few months, and we just extended this capability to any OLTP-compatible third party - but it has taken us much longer to ship any sort of Postgres log export. You might wonder: why did it take so long? The question is valid, a... ## How Browsers Choose Between HTTPS over TCP and QUIC DevFeed: [How Browsers Choose Between HTTPS over TCP and QUIC]() Original publisher: [Read original article]() Published: 2025-06-03T06:30:00Z Content type: opinion Language: en Sources: [ipSpace.net blog]() Topics: [browser](), [Web](), [servers](), [Protocol (disambiguation)]() Tags: [browser](), [distributed](), [protocol](), [quic](), [server](), [tcp](), [trust](), [worth-reading]() ### AI overview The article discusses how browsers determine whether a web server supports QUIC and choose between HTTPS over TCP and QUIC. It notes that browser vendors do not trust distributed database data about server capabilities and instead use a happy eyeballs-like protocol. ### Source excerpt Jan Schaumann published an interesting blog post describing the circuitous journey a browser might take to figure out that it can use QUIC with a web server. Now, if only there were a record in a distributed database telling the browser what the web server supports. Oh, wait... Not surprisingly, browser vendors don't trust that data and have implemented a happy eyeballs-like protocol to decide between HTTPS over TCP and QUIC. ## Comparing IP and CLNP: Local (Node) Multihoming DevFeed: [Comparing IP and CLNP: Local (Node) Multihoming]() Original publisher: [Read original article]() Published: 2025-04-02T07:21:00Z Content type: comparison Language: en Sources: [ipSpace.net blog]() Topics: [networking](), [Networks](), [Protocol (disambiguation)](), [Routing (disambiguation)](), [Firewall](), [Mainframe]() Tags: [firewall](), [ibm](), [ip](), [networking-fundamentals](), [networks](), [protocol](), [routing](), [stateful](), [tcp](), [tcp-ip]() ### AI overview The article compares local node multihoming in IP/TCP/IP and CLNP. It explains that TCP/IP multihomed hosts use multiple IP addresses and lack a single well-defined behavior, with strong and weak end-system models leading to routing asymmetry and complications for stateful firewalls. It describes loopback addressing and routing advertisements as a TCP/IP solution. The supplied excerpt is incomplete. ### Source excerpt Another area where CLNP is a clear winner when compared to the TCP/IP stack is multi-homed nodes (nodes with multiple interfaces, not site multi-homing, where whole networks are connected to two upstream providers). Multi-homed TCP/IP nodes must have multiple IP addresses because IP uses address interfaces. There is no well-defined procedure in TCP/IP for how a multi-homed node should behave. In the early days of TCP/IP, they tried to address that in RFC 1122 (Host Requirements RFC), but even then, there were two ideas about dealing with multiple interfaces: the strong and weak end system models (more details). Read more ... ## Understanding and Observing the BGP Connect State DevFeed: [Understanding and Observing the BGP Connect State]() Original publisher: [Read original article]() Published: 2025-01-30T06:55:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [BGP](), [Finite-state machine](), [Cisco]() Tags: [arp](), [bgp](), [cisco](), [how-to](), [machine](), [mpls](), [state](), [tcp]() ### AI overview The article explains why the BGP Connect state is difficult to observe, especially on Cisco IOS, whose implementation predates the state and does not display it. It describes the BGP state transitions and conditions that can cause a peer to remain in Connect long enough to observe, including dropped TCP SYN packets and certain routing or filtering configurations. ### Source excerpt I got this question from Paul: Have you ever seen a BGP peer in the "Connect" state? In 20 years, I have never been able to see or reproduce this state, nor any mention in a debug/log. I am starting to believe that all the documentation is BS, and this does not exist. The BGP Finite State Machine (FSM) (at least the one defined in RFC 4271 and amended in RFC 9687) is "a bit" hard to grasp but the basics haven't changed from the ancient days of RFC 1771: Read more ... ## ERR\_PROXY\_CONNECTION\_FAILED errors with HTTP proxies DevFeed: [ERR\_PROXY\_CONNECTION\_FAILED errors with HTTP proxies]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2024-12-11T17:00:00Z Content type: tutorial Language: en Sources: [HTTP Toolkit]() Topics: [HTTP](), [browser](), [Security](), [debug](), [TLS (Transport Layer Security)](), [cURL](), [Postman]() Tags: [authentication](), [browser](), [chrome](), [curl](), [debugging](), [errors](), [http](), [issue](), [port](), [postman](), [protection](), [proxy](), [server](), [tcp](), [tls](), [tools]() ### AI overview This tutorial explains how to diagnose ERR_PROXY_CONNECTION_FAILED when using a local debugging proxy with Chrome or similar applications. It covers incorrect connection details, unreachable proxies, and antivirus software that intercepts local proxy traffic and rejects the proxy's TLS certificate. ### Source excerpt If you're using a local debugging proxy tool like HTTP Toolkit, you might run into the dreaded ERR_PROXY_CONNECTION_FAILED error in Chrome and other similar apps. This can be a very frustrating and unhelpful error! There's only a few possible causes though, and it's usually easy to fix. The Simple Case The simplest explanation is exactly what it says: the browser can't connect to your proxy. In the simple case this may be caused by a basic connection issue: you have the address, port or some authentication details wrong, or the details are correct but the proxy is just not reachable on your connection, and so the browser can't talk to it. The easiest way to confirm this is to try connecting to the details directly using an HTTP client tool like curl, Postman, or the HTTP Toolkit Send page, to manually check if the server is listening on the port you expect. If you see a TCP error then the details are wrong, but if you see any kind of HTTP error or similar then you know that the server does exist and it's reachable with the given details. If the failure comes from a browser intercepted by a tool like HTTP Toolkit though, where intercepted clients are preconfigured & launched for you, this is not what's happening - the server is definitely reachable (it's running locally) and the config is correct (it's been done automatically). Instead, this might be caused by something more complicated... Beyond the Simple Case If you know the settings are correct, and you know the proxy is reachable, what could cause this ERR_PROXY_CONNECTION_FAILED error? Once you're ruled out basic connection issues, the most likely cause is antivirus software on your computer that is intercepting your connections. This is becoming a common feature of some antivirus & security software, most notably ESET. It's not directly related to viruses at all, but is a separate security feature that's often enabled automatically for additional protection. What happens in this case is that your browser is tryi ## IBGP Source Interface Selection Still Requires Configuration DevFeed: [IBGP Source Interface Selection Still Requires Configuration]() Original publisher: [Read original article]() Published: 2024-12-10T07:32:00Z Content type: article Language: en Sources: [ipSpace.net blog]() Topics: [BGP](), [networking](), [configuration]() Tags: [bgp](), [configuration](), [ip](), [networking](), [spoofing](), [tcp]() ### AI overview The article explains that FRRouting does not automatically select the correct source interface for IBGP sessions. Because BGP runs over TCP and IBGP commonly uses loopback addresses, the router must be configured to send TCP SYN packets with the appropriate loopback source address. ### Source excerpt A fellow networking engineer recently remarked, "FRRouting automatically selects the correct [IBGP] source interface even when not configured explicitly." TL&DR: No, it does not. You were just lucky. Basics first1. BGP runs over TCP sessions. One of the first things a router does when establishing a BGP session with a configured neighbor is to open a TCP session with the configured neighbor's IP address. Read more ... [Next page]()