> ## Content Index
> Fetch the complete content index at: https://huizhou92.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Can We Still Use HTTP?
- URL: https://huizhou92.com/can-we-still-use-http/
- Published: 2024-11-26T11:42:47.000Z
- Updated: 2026-09-08T02:30:00.000Z
- Description: Can We Still Use HTTP?. I recently launched a new service, and a collection interface takes up more bandwidth. This interface is straightforward, and I’m c。
- Author: huizhou92
- Tags: #Migrated-1788833207488, #Import 2026-09-08 02:07

I recently launched a new service, and a collection interface takes up more bandwidth. This interface is straightforward, and I’m curious about how much data is transferred in a `HTTPS` request. Relative to HTTP packets, how much larger?

I wrote a demo to test it.

```go
func helloHandler(w http.ResponseWriter, r *http.Request) {   
    fmt.Fprintf(w, "Hello, World!")   
}   
   
var port int   
   
func init() {   
    flag.IntVar(&port, "port", 8082, "port to listen on")   
    flag.Parse()   
}   
func main() {   
   
    http.HandleFunc("/", helloHandler)   
    fmt.Println(fmt.Sprintf("Starting server at port %d", port))   
    if err := http.ListenAndServe(fmt.Sprintf(":%d", port), nil); err != nil {   
       fmt.Println("Error starting server:", err)   
    }   
}
```

Then, use caddy locally to provide the `https`

```shell
http://your-domain.com { 
    reverse_proxy 127.0.0.1:8082 
} 
 
https://your-domain.com { 
    reverse_proxy 127.0.0.1:8082 
    tls internal 
}
```

Finally, grabbing packets with `wireshark`, I was surprised to find. A simple HTTPS request transfers 2164 bytes of data.

![A simple HTTPS request transfers 2164 bytes of data](https://huizhou92.com/content/images/2026/09/1-489eikmtobul8kurcyz9nw.png)

Assuming concurrency of `500 QPS`, the bandwidth required for this interface is:

![2164×8×500/1000000 ≈ 8.656Mbps](https://huizhou92.com/content/images/2026/09/1-yphtofisdqsqzfk8ntvcpw.png)

The full name of `HTTPS` is `HTTP` over `TLS`. Each time a new TCP connection is established, it usually requires a full `TLS Handshake`. During the handshake, the client and server must exchange information such as certificates, public keys, encryption algorithms, etc; this data takes up more bytes. The main components of a TLS Handshake include:

- Random numbers for the client and server
- Supported encryption algorithms and TLS version information
- Digital certificate of the server (with public key)
- Pre-Master Secret” for symmetric key generation This process is time-consuming and consumes bandwidth and CPU resources.

Therefore, the crudest solution that comes to mind is relatively simple: use HTTP directly, omitting the TLS Handshake process, and then, naturally, there will be no TLS transmission.   
So, is it effective? Verify it to find out.

![](https://huizhou92.com/content/images/2026/09/1-yil1sektnu9kx-mouyzccq.png)

http reques

For the same request, the `HTTP` interface takes only `223 bytes`, which is about 1/10th of an `HTTP` request.

HTTPS is the preferred choice in most cases, providing better security and SEO.

*`HTTP` can be chosen to optimize performance in controlled environments with intranet or high-performance requirements and when transferring non-sensitive data.*

Of course, `HTTPS` can also optimize the `TLS Handshake` process, which is `Keep-Alive`. `Keep-Alive` is a connection multiplexing mechanism that allows multiple request-response interactions over a single TCP connection without creating a new connection for each request. It significantly reduces connection establishment and closure overhead in HTTPS and improves performance.