Hi, I'm Nishant. I work on eBPF and Linux networking.

eBPF / XDPKernel NetworkingQUIC / HTTP3Go · RustLinux

I build things that live in the parts of the stack most engineers don't touch — kernel networking, QUIC/HTTP3 edge proxies, eBPF-based packet filtering. When something is slow, broken, or under attack, I want to understand exactly why and fix it at the right layer.

Currently at CloudArmour — eBPF/Kernel DDoS mitigations, NAT/WireGuard infrastructure, nftables firewall tooling. Also writing about it — 44 articles on Hashnode & Medium.

Featured Projects

Impulse[v0.5.1-beta]
--rust--http-3---quic--reverse-proxy--health-check--config-driven
21K req/sp99 102msHTTP/3→HTTP/2100% success under QUIC packet loss
  • ›Built an HTTP/3 (QUIC) → HTTP/2 edge proxy with dual ingress (QUIC + HTTP/1.1/2 Alt-Svc upgrade) and hierarchical routing (O(1) exact match + radix trie fallback).
  • ›Implemented multi-level overload protection with inflight limits, adaptive admission control, brownout shedding, circuit breakers, and retry/hedging logic.
  • ›Hardened control plane with TLS APIs, constant-time token auth, privilege dropping (CAP_NET_BIND_SERVICE), and RFC-compliant header stripping.
  • ›Added distributed quota policies (Redis or in-memory backed) for cluster-wide request budgets, plus a packaged observability bundle — Prometheus alerts, SLOs, and Grafana dashboards for traffic, admission, and backend health.
  • ›Achieved 21K req/s (p99: 102ms) on 4-core test system; sustained 12.5K req/s under QUIC packet loss with 100% success rate.
vex[dev]
--rust--http-3---quic--load-testing--performance-benchmarking
  • ›Experimental HTTP/3 load testing tool built in Rust for benchmarking QUIC-based services.
  • ›Measures throughput, latency, and concurrent connection performance under controlled load.
  • ›Designed to test HTTP/3 servers and infrastructure with detailed performance metrics and reporting.

EXPERIENCE

WRITING

View all >
PERMSREADTITLE / SUMMARY
›Understanding ctx->data in XDP: Parsing Raw Packets Across Protocols

A deep dive into how XDP programs parse raw packets from ctx->data, covering Ethernet, IPv4, IPv6, and next protocol headers with practical parsing patterns.

[ebpf][xdp][networking][packetparsing]
›NIC Queues, RSS, RPS, and RFS — Why They Matter More Than You Think

When software can't keep up with traffic, the bottleneck isn't always threads or hot paths — sometimes it's the NIC itself. A deep dive into receive queues, RSS, RPS, and RFS and why they matter for high-throughput Linux networking.

[linux][networking][kernel][performance][ebpf]
›GRO, GSO, TSO, LRO — How the Linux Kernel Cheats

The bottleneck in Linux networking is often the per-packet cost, not the bandwidth. A walkthrough of how GRO, GSO, TSO, and LRO reduce that cost by coalescing and segmenting at the right layer.

[linux-kernel][networking][ebpf][system-programming][performance]
›Same Rules. Different Cost. We Benchmarked nftables vs Neurowall (eBPF/XDP) Under a Real SYN Flood.

Both nftables and NeuroWall (eBPF/XDP) blocked the attack — but the cost was not the same. A real benchmark under ~128K pkt/s SYN flood reveals what enforcing the same policy at different points in the Linux packet path actually costs.

[ebpf][nftables][ddos][ddos-mitigation][firewall]
# also on medium & hashnode

TECHNICAL SKILLS

Specialties
eBPF/XDPnftablesWireGuardGoRustC (eBPF/XDP)
Kernel & Networking
iptablesLinuxIPv6NATdnsmasqtcpdumpDebian/Devuan
Languages
PythonTypeScript
Infrastructure
DockerHetzner CloudOVHCloudAnsibleNginxGitHub ActionsGitSSL/TLS
Databases
PostgreSQLRedisKeyDB

SIDE QUESTS

PIDPROJECT / INTERESTRUNTIME LOGS
101Technical Writing60+ articles on Hashnode & Medium — eBPF, Rust, networking, systems
102WeAreBackbenchersbuilt it out of boredom — had a spare VPS and an extra domain
103Spanishmi español es malo — still learning
104Cricketoccasional follower, barely watch anymore
105UFCoccasional viewer