This one is about the wire, not the chip. Nothing below changes with the board you picked, which is why the chip and language switches are not on it. They come back on the ESP32 pages this one sits underneath.
HTTP from a board
Four lines of code send one number to a server. What actually goes out is nine messages, most of a second, and 40 kB of RAM — and knowing which of those you can skip is the whole subject.
Press send and count the arrows. Only two of them carry your reading.
HTTP is text, and that is all it is
A request is a few lines you could type yourself:
GET /reading?t=21.4 HTTP/1.1
Host: api.example.com
User-Agent: esp32
The reply is the same shape: a status line, some headers, a blank line, then
the body. 200 means it worked, 404 means that path does not exist on that
server, 500 means the server broke on its own. There is nothing magic in the
protocol — the difficulty is all in what has to happen before the first line
can be sent.
The four costs, in the order they bite
| Cost | Plain HTTP | HTTPS | Why |
|---|---|---|---|
| Time | ~130 ms | ~510 ms | The handshake, not the data |
| Bytes | ~1 kB | ~5.5 kB | The server's certificate |
| RAM | ~6 kB | ~40 kB | Buffers and key maths |
| Power | a blink | a gulp | The radio is on the whole time |
The pattern is the same in every row: the reading costs nothing and getting permission to send it costs everything. That is why the fix is never a smaller payload — it is fewer connections.
Two decisions that pay for themselves
Keep the connection open. Send Connection: keep-alive and reuse the
client object, and the next reading skips DNS, TCP and TLS entirely. Turn the
toggle on in the figure and watch seven arrows become two.
Post in batches. Ten readings in one request cost one handshake. If your sensor is happy at one sample a second and your server is happy with a minute of history at a time, buffer them and send once a minute — sixty times less overhead for exactly the same data.
HTTPS on a chip this size
An ESP32 can do TLS. It is just slow and hungry: the certificate check is real public-key arithmetic on a 240 MHz core, and the buffers are tens of kilobytes of a heap that only has a few hundred. Three things make it bearable:
- Verify a certificate, don't skip it.
setInsecure()works and turns the s into decoration. Pin the root CA of the server you talk to instead. - Reuse the session. One handshake per boot, not one per reading.
- Watch the heap. If your sketch also drives a display buffer, TLS is often the allocation that fails — and the failure looks like a random reboot.
When HTTP is the wrong tool
It is the right one when the board starts the conversation, occasionally, and somebody else already runs the server: weather, a webhook, a reading pushed to a spreadsheet. It is the wrong one in two cases, and both have their own page:
- Many devices, many listeners, all the time. The overhead multiplies by the number of boards. MQTT pays the handshake once and then sends 30-byte messages forever.
- The server needs to talk first. HTTP has no way to do that; the board has to keep asking. That is what WebSocket is for, and the cost of not using it is drawn on that page.
Before any of this works the board has to be on the network at all, which is Wi-Fi station mode, and it has to know what to call the server, which is mDNS and DNS.
Edit this page — content/esp32/http-from-a-board.mdx
Discuss this article
Ask about this page. The answer stays here, on the page it belongs to, for whoever hits the same wall next.