Definition
HTTP/2 is the second major version of the HTTP protocol defined by IETF RFC 7540. It is based on binary framing, multiplexing, header compression (HPACK), and other technologies, significantly improving transmission efficiency while maintaining HTTP semantics (requests/responses, methods, status codes). HTTP/2 is based on TCP+TLS, and IoT devices can use HTTP/2 to communicate with cloud APIs. Its successor, HTTP/3, is based on QUIC and further reduces latency.
Core Features
- Binary Framing: Splits HTTP messages into frames, supporting multiplexing and priority
- Multiplexing: Multiple concurrent request/response streams on a single TCP connection, eliminating HTTP/1.1 head-of-line blocking
- Header Compression HPACK: Huffman coding + static/dynamic tables, reducing redundant header overhead
- Server Push: The server can actively push resources to reduce round trips.
And MQTT
HTTP/2 is suitable for request-response API calls; MQTT is suitable for publish/subscribe and bidirectional push. IoT device management, configuration delivery, OTA upgrades, etc., can use HTTP/2; real-time data reporting and command delivery can use MQTT. Both can coexist on the same platform.
Typical Use Cases
IoT Cloud Platform API, device management, OTA upgrades, configuration delivery, etc. The SimtoLink cloud platform API supports HTTP/2, which can reduce connection overhead and improve transmission efficiency.
The SimtoLink cloud platform API supports HTTP/2. When IoT devices communicate with the cloud, it can utilize multiplexing and header compression to reduce connection overhead and improve transmission efficiency. For scenarios that require frequent API calls, such as device management and OTA upgrades, HTTP/2 can significantly reduce latency and traffic consumption. SimtoLink provides customers with efficient cloud connectivity.
The stream window and the connection window are two levels of rate limit
HTTP/2 splits many requests into frames and multiplexes them on one transport connection. Each stream has its own flow-control window, and the whole connection has one total window. When one large file fills the connection window, a small request on the same connection cannot go out even if its stream window still has room. This is different from head-of-line blocking in the previous version of the protocol: the requests are already concurrent, and they are stuck on the window, not on a response that has to finish in order. See whether one stream is slow, or every stream stops together. If every stream stops, check the connection window and congestion underneath first. If only one stream stops, check application handling of that stream.
A window that is too small wastes bandwidth waiting for a window update. A window that is too large lets a slow device pile up memory on the peer. When module memory is limited, cap the number of concurrent streams and the window together. Raising concurrency without raising processing capacity queues requests inside the module. On the air interface it is still one connection.
The dynamic header table has to be learned again after the connection resets
Header compression uses a static table and a connection-level dynamic table. A repeated header is replaced by an index. The longer the connection lives, the better the compression. If a weak network knocks the connection down often, the dynamic table is cleared each time, the following requests send full headers again, the compression gain disappears, and traffic is larger than on a long-lived connection. The sign is that byte count on short connections is close to an uncompressed request, and it drops clearly on a long connection. IoT should reuse the connection, not handshake on every report.
The dynamic table has a size cap. If the table is too small, old header indexes are pushed out, and the sender and the receiver must stay in step on that cap. If a proxy in the middle rewrites headers, the index and the real header fall out of alignment. The symptom is an occasional 400-class error while the underlying connection is still up. A proxy must state whether it terminates HTTP/2. It cannot rewrite headers transparently.
Server push is often turned off outright on a module
The protocol lets the server push a resource it thinks the client will need, beyond the response itself. A browser can use that to fetch page dependencies early. Most IoT modules want only the configuration or firmware they asked for. A push takes a stream and memory, and modules often disable push in the settings frame. If the server ignores the disable and pushes anyway, the module resets that stream, and both sides waste a round trip. Deliver configuration to a device on a request the device starts, or on a dedicated downlink channel, rather than depending on push.
If a SimtoLink cloud-platform interface enables HTTP/2, the gain is mainly shared connections across many calls and compression of repeated headers. The card and the module still have to deliver that connection to the platform steadily. The protocol does not replace coverage. If the platform sees the same device handshake again and again with few service requests, lengthen connection hold time to cover the report period before talking about concurrent streams. A large stream such as a firmware download should have its window limited on its own, so it does not block a status query on the same connection.
The concurrent-stream cap has to be written into the settings frame together with module memory
The settings frame at the start of a connection negotiates the maximum concurrent streams and the window. If the server offers a large concurrency the way it would for a browser, module memory cannot hold the matching stream state, and the module resets the connection or drops frames silently. After a reset the application sees the whole connection fail, not only one request. The cap should be the number of requests the module can handle at once, not the maximum the protocol allows. Do not run status queries, configuration reads, and firmware blocks in parallel without a limit. Firmware blocks in particular fill the window easily.
If a proxy in the middle terminates HTTP/2 and converts it to the older version, concurrency in the settings frame applies only to the first stretch. The second stretch may queue again. End-to-end multiplexing gain disappears at the proxy. If the SimtoLink cloud platform offers HTTP/2 to devices directly, it should publish the concurrency and window the device side must keep, and return a clear stream error when the limit is exceeded, rather than closing the whole connection. The card and coverage only deliver the connection to the platform. When the settings frame knocks the connection down, retrying coverage does not help. Lower concurrency to a count the module can hold first.