Key Takeaways
- A load test only exercises the protocol your tool actually speaks. Point an HTTP/1.1-only client at a site that serves HTTP/2 or HTTP/3 and you have tested a different connection pattern than your users produce.
- k6 has HTTP/1.1, HTTP/2, WebSockets and gRPC built in (grafana.com/docs/k6, October 2026). JMeter’s built-in samplers cover HTTP/1.1, JDBC, JMS, TCP, FTP, SMTP and LDAP, and reach WebSocket, gRPC and MQTT through community plugins. Gatling’s docs list HTTP, WebSocket, SSE, GraphQL, JMS, MQTT and gRPC. Locust has built-in HTTP and HTTPS and expects you to wrap other protocols in a client.
- What you measure changes with the protocol: connection setup and time to first byte for HTTP, concurrent open connections and message latency for WebSocket, call status in trailers for gRPC, delivery by QoS level for MQTT, pool saturation for databases.
- Stock tools do not generate HTTP/3. Confirm which protocol a run really used before you trust a result.
A load testing protocol is the way a client and server talk, and it decides what “a request” means and what you can measure. Below are seven protocols a performance tester is likely to meet in 2026: what a load test actually measures for each, and which of JMeter, k6, Gatling and Locust support it. Tool facts were read from each project’s documentation on 23 October 2026 and change between releases, so check the linked pages before you commit to a tool.
Which protocols do JMeter, k6, Gatling and Locust support?
The table sums up what the documentation of each tool says. “Plugin” means a community add-on you install separately, and “extension” is k6’s term for a custom binary built with xk6. “Not documented” means I found no mention in that tool’s docs, which is not proof that it cannot be done.
| Protocol | JMeter | k6 | Gatling | Locust |
|---|---|---|---|---|
| HTTP/1.1 | Built in (HTTP Request sampler) | Built in | Built in (HTTP) | Built in (HTTP and HTTPS) |
| HTTP/2 | Not in the built-in sampler per the component reference; a community HTTP plugin adds it | Built in, used automatically when the server offers it | Built in, opt-in with enableHttp2 | Not documented |
| HTTP/3 (QUIC) | Not documented | Not built in; an experimental community extension exists | Not documented | Not documented |
| WebSocket | Plugin | Built in | Documented protocol section | Custom client |
| gRPC | Plugin | Built in | Documented protocol section | Custom client (docs give an example) |
| MQTT | Plugin | Official extension (xk6-mqtt, experimental, MQTT 3.1.1) | Documented protocol section | Experimental MqttUser in the docs |
| SQL databases | Built in (JDBC Request sampler) | Official extension (xk6-sql) | Not in the protocol list | Custom client |
Sources: jmeter.apache.org component reference and changes page; grafana.com/docs/k6 protocols and extensions pages; docs.gatling.io concepts and HTTP protocol reference; docs.locust.io “Testing other systems” (all October 2026). The JMeter changes page lists 5.6.3 as the latest release.
How do you load test each protocol?
1. HTTP/1.1
HTTP/1.1 is still what many APIs, internal services and older clients speak. A load test of it measures connection setup, TLS handshake time, time to first byte, download time, status codes and throughput. On this protocol a connection handles one request at a time in practice, so real clients open several connections, and your test’s connection behaviour (keep-alive, number of connections per virtual user) shapes the result. If you are new to the protocol itself, start with what HTTP is. Every tool in the table handles it natively.
2. HTTP/2
HTTP/2 (RFC 9113) allows multiple concurrent exchanges on the same connection, each as its own stream, and compresses repeated header fields. A test of it should watch how many connections each virtual user opens (usually one), how many streams run at once, and the server’s stream limit. RFC 9113 says SETTINGS_MAX_CONCURRENT_STREAMS starts out unlimited and recommends a value of at least 100, so a lower server setting can queue requests that a browser would have sent in parallel. The RFC also states that TCP head-of-line blocking is not addressed: one lost packet stalls every stream on that connection.
The practical risk is a silent fallback to HTTP/1.1. In k6 you can check by logging res.proto: against a public HTTPS site on k6 1.7.1 it printed HTTP/2.0. Gatling negotiates HTTP/2 through ALPN only when you enable it, and falls back to HTTP/1 if the remote lacks support, so check the protocol in the results rather than assuming it.
3. HTTP/3 and QUIC
HTTP/3 (RFC 9114) maps HTTP onto QUIC, which runs over UDP, includes TLS 1.3 and multiplexes streams so that, in the RFC’s words, a blocked or lossy stream does not prevent progress on others. Clients normally discover it through the Alt-Svc response header (the h3 token), try QUIC, and use TCP-based HTTP if UDP is blocked. A load test of HTTP/3 would measure handshake time, behaviour under packet loss and the share of clients that fall back to TCP.
Here the tools stop. I found no built-in HTTP/3 client in the JMeter, Gatling or Locust documentation, and k6’s own docs do not list it either; an experimental community extension, xk6-http3, exists. So a load test of a site that also serves HTTP/3 is, with stock tools, a test of HTTP/1.1 or HTTP/2 against the same origin. That is still useful, but it is not an HTTP/3 test. For the deeper discussion see HTTP/3 load testing.
4. WebSocket
WebSocket (RFC 6455) starts as an HTTP Upgrade request and then keeps one TCP connection open for traffic in both directions. A request rate does not describe it. Measure how many connections you can hold open at once, the connect (handshake) rate, the delay between sending a message and receiving the response or broadcast, and how many connections drop. On the server side, watch memory and file descriptors per connection. k6 recommends its k6/websockets module for new tests, and JMeter users typically add the WebSocket Samplers plugin by Peter Doornbosch.
5. gRPC
gRPC carries calls over HTTP/2 streams. The gRPC documentation defines four call types: unary, server streaming, client streaming and bidirectional streaming. The outcome of a call is reported in trailers (grpc-status), and the gRPC HTTP/2 specification notes that an error response still uses HTTP status 200. So an HTTP-level check will call a failed call a success: assert on the gRPC status. Measure per-call latency by type, streaming message rates and deadline failures (DEADLINE_EXCEEDED). k6 has the k6/net/grpc module built in for unary and streaming calls, Gatling documents gRPC, and for JMeter the usual route is a community plugin (the jmeter-grpc-request repository was archived in April 2024, so check its state before relying on it). The comparison of gRPC load testing tools goes into each option.
6. MQTT
MQTT is a publish/subscribe messaging protocol widely used for IoT devices, standardised by OASIS, with three delivery levels: QoS 0 (at most once), 1 (at least once) and 2 (exactly once). A test measures the connect rate, publish-to-delivery latency, messages lost or duplicated at each QoS level, and how the broker behaves as the number of subscriptions and the fan-out grow. The meaningful load is the number of connected clients and the message fan-out, not requests per second. k6 lists an official xk6-mqtt extension (its README calls it experimental and MQTT 3.1.1 only), Gatling documents MQTT, and JMeter uses a community plugin.
7. SQL databases (JDBC)
A database is not a network protocol in the same sense, since each engine has its own wire protocol, but testers meet it constantly, and JMeter’s JDBC Request sampler sends SQL queries natively. Load testing it measures query latency under concurrency, connection pool saturation and the number of connections the database accepts. k6 reaches databases through the official xk6-sql extension and its driver extensions. Test the database directly when you suspect it is the limit behind an API, because an HTTP test only shows its effect indirectly.
What about DNS, TCP, FTP, SMTP and SNMP?
Earlier versions of this article gave each of them a section. Most are better treated as part of something else. DNS lookup and TLS handshake are phases of an HTTP request, and the tools report them as part of connection time rather than as separate load targets. JMeter has native samplers for raw TCP, FTP, SMTP, LDAP and JMS if you operate those services (JMeter component reference, October 2026). SNMP is a monitoring protocol: you poll devices with it, you do not normally load test a product through it, so it does not belong in a performance test plan.
How do you choose which protocols to test?
List what your real clients send, by traffic share and by business risk, and test those first. A site whose users are all in browsers needs HTTP/2 coverage before anything exotic. A chat or live-dashboard feature needs WebSocket concurrency. An IoT product needs MQTT with its real QoS mix. Then choose the tool that speaks those protocols without a plugin you have to maintain. Whatever the protocol, report percentiles rather than averages (see why percentiles are more useful than averages) and keep an eye on the relation between throughput and response time.
Where does LoadFocus fit?
LoadFocus’s load testing page describes HTTP requests (GET, POST, PUT, PATCH, DELETE and others, with query parameters, headers, cookies and Basic authentication) and lists no other protocols. It runs JMeter and k6 scripts from 25+ cloud regions and reports response time, throughput and the 50th, 90th and 99th percentiles in real time (load testing, October 2026). Whether a script that uses a plugin or a k6 extension runs on its cloud generators is not stated on the pages I read, so check the LoadFocus docs or ask support before you plan a WebSocket, gRPC or MQTT test there. For HTTP APIs, JMeter in the cloud and k6 load testing are the places to start.
Frequently Asked Questions
Which network protocols are most important in performance testing?
HTTP/1.1 and HTTP/2 for almost every web application and API, then whatever else your clients actually use: WebSocket for real-time features, gRPC between services, MQTT for IoT, SQL for the database behind it. Start from your traffic, not from a list.
Does JMeter support HTTP/2?
Not in the built-in HTTP Request sampler according to the JMeter component reference and the 5.6.3 changes page. A community HTTP plugin adds HTTP/2, and a pull request for an HttpClient5 sampler with HTTP/2 support was open on the JMeter repository on 23 October 2026. Check the release notes of the version you use.
Does k6 support HTTP/3?
Not out of the box. k6 supports HTTP/1.1, HTTP/2, WebSockets and gRPC natively. An experimental community extension, xk6-http3, adds an HTTP/3 client, and you must build a custom k6 binary to use it.
How do I test gRPC with a load testing tool?
Use a tool with a gRPC client: k6’s built-in k6/net/grpc module is the shortest path. Check the gRPC status of each call, not only the HTTP status, because failed calls still arrive as HTTP 200.
How do I know my test really used HTTP/2?
Read the protocol back from the tool. In k6, log res.proto (it printed HTTP/2.0 in a test against a public HTTPS site). In other tools, look for the protocol field or the connection count in the results.
Should I simulate packet loss and latency?
Yes for protocols that react to loss, such as HTTP/2 over TCP and QUIC, but most load testing tools do not add loss themselves. Use network emulation on the load generator or test from regions with realistic latency, and say in the report which conditions applied.
Sources
- RFC 9113: HTTP/2
- RFC 9114: HTTP/3
- RFC 6455: The WebSocket Protocol
- gRPC over HTTP/2 and gRPC core concepts
- MQTT.org
- Grafana k6: Protocols (grafana.com/docs/k6/latest/using-k6/protocols), WebSockets (grafana.com/docs/k6/latest/using-k6/protocols/websockets), gRPC (grafana.com/docs/k6/latest/using-k6/protocols/grpc) and extensions (grafana.com/docs/k6/latest/extensions/explore)
- Apache JMeter component reference and changes
- Gatling HTTP protocol reference
- Locust: Testing other systems
