Layer 4 vs Layer 7, RPS, Gbps & pps — short guide for panel users

Layer 4 vs Layer 7 (in two sentences)

Layer 4 (L4) in our context usually means transport-level stress: the focus is on IP addresses, ports, and connection-style traffic (e.g. TCP/UDP style loads) rather than a specific URL path. You care about raw throughput, packets per second, and connection pressure on firewalls, routers, and listening daemons.

Layer 7 (L7) means application-level load aimed at a web or app interface: HTTP/HTTPS style requests, paths, headers, and sometimes post bodies. The target must parse requests like a real client—so you are testing web servers, reverse proxies, WAFs, and app logic, not just “open a socket on a port.”

Why it matters in the panel: L4 and L7 methods stress different parts of a stack. A service can survive huge L4 volume but struggle with L7 if each request is expensive (database, rendering, API auth). For your own environments, you pick the layer that matches what you need to validate (e.g. edge vs origin vs application).

RPS, Gbps, and pps—what the numbers mean

These are three different “speedometers.” They are related but not interchangeable.

RPS (requests per second)

How many application requests you complete in one second, usually in an L7 (HTTP) context. Higher RPS means the client side is keeping the server busy with many discrete HTTP calls. RPS is the familiar metric for web APIs, pages, and reverse proxies. On dashboards it often pairs with latency and error rate: if RPS is high but errors spike, you found a breaking point.

Gbps (gigabits per second)

A bandwidth / bitrate measure: how much raw data is moving on the wire per second. L4 marketing and backbones often use Gbps because flooding-style scenarios are about how much network volume you can push, independent of how many “pages” you fetch. If you only looked at RPS, you would miss very large L4 or volumetric issues that are measured in bits, not “HTTP requests”.

Quick intuition: 1 Gbps = 1,000,000,000 bits per second (contrast with bytes—network gear quotes bits).

pps (packets per second)

How many network packets are processed in one second. Many firewalls, NICs, and small routes hit packets-per-second limits before they run out of Gbps, because every packet has fixed overhead (routing, state tables, etc.). So two scenarios can have similar Gbps but very different pps, and your gear might fail on pps first. L4 talk often includes pps when describing stateful connection and small-packet stress.

How to read it on a plan or landing card

When you see something like “Up to X Gbps and Y Rps” on a plan, think of it as two ceilings: network volume (Gbps) and application request rate (RPS) for the relevant layer. You don’t have to use both at 100% at once; real tests mix packet sizes, concurrency, and keep-alive behavior.

pps may or may not be printed on marketing cards, but in operations it still matters. If something is “fast in Gbps” but the edge device dies on small packets, that’s a pps problem.

One-line cheat sheet

• L4 ≈ “volume and connection pressure to IPs/ports” → often Gbps + pps.
• L7 ≈ “HTTP-like requests to your app” → often RPS + latency + errors.

Use IpStress.ST's own UI labels and the documentation in the product as the source of truth for which layers and methods your plan can run—this article is a general explainer, not a promise of a specific feature name on your account.