Every request in your app travels over a stack of networking layers that mostly stay invisible — until something breaks or gets slow. This covers the foundations that underpin APIs, load balancers, and CDNs: how a domain name turns into a connection, how HTTPS keeps it secure, and what the HTTP versions actually change. If Cartara flagged this in your diff, you likely touched DNS configuration, HTTPS setup, or something related to how requests move between client and server.
What actually happens when you load a page
Typing a URL kicks off a chain of steps:
- DNS lookup — your browser turns the domain (
myapp.com) into an IP address - TCP connection — opens a connection to that IP (a handshake)
- TLS handshake — negotiates encryption so the connection is HTTPS
- HTTP request/response — the browser asks for the page; the server replies
Each step adds latency. Repeat visits feel faster because connections get reused, DNS answers get cached, and assets come from cache. Understanding this chain is what makes "why is it slow" questions solvable.
DNS: the internet's address book
Computers route by IP address, but humans use names. DNS (Domain Name System) translates names to IPs. When you visit a site, your machine asks a chain of DNS servers for the IP and caches the answer for a time governed by the record's TTL (time to live).
Record types you'll actually touch:
- A / AAAA — maps a name to an IPv4 / IPv6 address
- CNAME — aliases one name to another (
www.myapp.com→myapp.com). This is how you point a domain at a hosting platform - MX — mail servers for the domain
- TXT — arbitrary text, used for domain verification and email security
DNS changes aren't instant. They propagate as old cached answers expire — this can take minutes to hours depending on the TTL. When you connect a custom domain in your hosting platform, you're editing these records and then waiting for the change to spread.
TCP and UDP
Two ways data moves across the network:
- TCP — connection-oriented and reliable. It guarantees delivery and ordering by acknowledging packets and retransmitting losses. The default for the web because you want every byte of a page to arrive
- UDP — connectionless and "fire and forget." No delivery guarantee, but fast. Used where speed beats perfect reliability — video calls, gaming, DNS lookups
You rarely choose directly, but knowing the difference explains why HTTP/3 switching to UDP is significant.
Ports: getting to the right service
An IP address gets you to a machine; a port gets you to the right service on it. Conventions: port 80 for HTTP, 443 for HTTPS, 5432 for Postgres, 6379 for Redis.
In practice, your app listens on some internal port and a reverse proxy (Nginx, or your cloud load balancer) sits in front on port 443, terminates TLS, and forwards traffic to it.
TLS and HTTPS
HTTPS is HTTP wrapped in TLS (Transport Layer Security). TLS does three things:
- Privacy — eavesdroppers see encrypted gibberish
- Integrity — data isn't tampered with in transit
- Authentication — you're talking to the actual server, not an imposter
The server presents a certificate issued by a trusted Certificate Authority vouching for its identity. Client and server do a handshake to establish the encrypted channel. The good news: this is largely solved for you. Let's Encrypt made certificates free and automatic, and every major hosting platform provisions and renews them when you connect a domain. The essentials: HTTPS everywhere (never send credentials over plain HTTP), and let your platform auto-renew certificates — an expired cert is a common, embarrassing outage.
HTTP versions and why they matter for performance
HTTP is the request/response protocol of the web. The version affects performance, not functionality:
- HTTP/1.1 — one request at a time per connection. Multiple requests queue behind each other (head-of-line blocking), so browsers open many connections to compensate
- HTTP/2 — multiplexing: many requests share one connection in parallel, plus header compression. A big speedup for pages loading many assets
- HTTP/3 — runs over QUIC (built on UDP) instead of TCP, removing the remaining transport-level blocking and making connections faster to establish on flaky networks
You usually don't configure this directly — your CDN or hosting platform negotiates the best version each client supports. Serving behind a modern CDN gets you HTTP/2 and HTTP/3 essentially for free.
CDNs: bringing content closer to users
A CDN (Content Delivery Network) puts copies of your content on servers around the world so users connect to a nearby edge node instead of your origin server. This cuts latency dramatically and offloads traffic from your infrastructure.
CDNs commonly add: TLS termination, DDoS protection, edge caching, and rate limiting. Putting one in front of your app is one of the cheapest and biggest wins for global performance.
Why distance and round trips matter
Networking has a physics floor: data can't travel faster than light. A round trip to a server on another continent costs real milliseconds — and a page load is many round trips (DNS, TCP, TLS, then the requests themselves). This is why CDNs, connection reuse, and caching exist: they reduce either the distance or the number of round trips.
What You'll See in Your Code
Cartara often flags missing security headers or HTTP-only connections. A common pattern:
```javascript
// Missing HTTPS enforcement and security headers
app.get('/', (req, res) => {
res.send('Hello')
})
// Better: add security headers and HTTPS redirect
app.use((req, res, next) => {
// Force HTTPS
if (req.header('x-forwarded-proto') !== 'https' && process.env.NODE_ENV === 'production') {
return res.redirect(301, https://${req.hostname}${req.url})
}
// HSTS: tell browsers to always use HTTPS for this domain
res.setHeader('Strict-Transport-Security', 'max-age=63072000; includeSubDomains')
next()
})
```
DNS configuration in code comments (e.g., in a README or platform config):
```
Connecting a custom domain to Vercel
Add these DNS records at your registrar:
Type: A
Name: @
Value: 76.76.21.21
Type: CNAME
Name: www
Value: cname.vercel-dns.com
Changes propagate within 24-48 hours (usually much faster)
```
For builders on managed platforms
Almost all of this is handled for you — managed DNS, automatic HTTPS, HTTP/2 and /3 via the CDN, reverse proxying built into the host. What's worth understanding rather than configuring: how DNS records point your domain (and that changes take time), that HTTPS must be everywhere, and that a CDN in front of your app is a cheap, high-impact improvement. Knowing the plumbing makes debugging "why won't my domain resolve" or "why is the cert broken" far less mysterious.