Repository navigation
TH6 ‐ Session persistence vs IP Hash
When multiple backend servers are behind an OCI Load Balancer, requests are distributed across backend servers.
For some applications, we need backend affinity, which means keeping a user's requests connected to the same backend server.
Two common methods are:
- Session Persistence
- IP Hash
Session Persistence keeps a user's requests directed to the same backend server using a persistence cookie.
OCI Load Balancer has two backend servers:
OCI Load Balancer
|
-----------------
| |
Backend-1 Backend-2
First request:
User → Load Balancer → Backend-1
The Load Balancer establishes a persistence cookie.
Subsequent requests:
User + Cookie → Load Balancer → Backend-1
User + Cookie → Load Balancer → Backend-1
So the user's session continues with Backend-1.
For an e-commerce application:
Login → Add Product to Cart → Checkout
If the user's session is stored on Backend-1, session persistence helps keep the user's requests going to Backend-1.
Session Persistence = Cookie → Same Session → Same Backend
IP Hash uses the client's source IP address to determine which backend server should receive the request.
The Load Balancer calculates a hash based on the client IP.
Client IP: 192.168.1.10
↓
Hash Function
↓
Backend-1
Subsequent requests from the same IP can continue going to Backend-1:
192.168.1.10 → Backend-1
192.168.1.10 → Backend-1
192.168.1.10 → Backend-1
IP Hash = Source IP → Hash → Backend
Suppose multiple users are behind the same office public IP:
User A ─┐
User B ─┤
User C ─┼──→ Public IP: 203.0.113.10
User D ─┘
↓
OCI Load Balancer
↓
Backend-1
Because IP Hash uses the source IP, multiple users may be mapped to the same backend.
This can cause uneven load distribution.
With IP Hash:
Old IP: 49.36.10.20
↓
Hash
↓
Backend-1
If the mobile network changes the public IP:
New IP: 49.36.20.50
↓
Hash
↓
Backend-2
The user may move from Backend-1 to Backend-2.
If the session was stored only on Backend-1, the user may lose the session.
With Session Persistence:
User + Persistence Cookie
↓
Load Balancer
↓
Backend-1
Even if the IP changes, the cookie can continue to maintain the backend association, subject to the persistence configuration and backend availability.
| Feature | Session Persistence | IP Hash |
|---|---|---|
| Mechanism | Persistence Cookie | Source IP |
| Affinity | Session/Client based | IP based |
| Cookie required | Yes | No |
| IP change | Usually does not affect cookie-based affinity | Can change backend mapping |
| Users behind same NAT | Can distinguish users using cookies | May map users to same backend |
| Main use | Stateful/session-based applications | Stable IP-based environments |
Use Session Persistence when:
- The application maintains user sessions on a backend.
- User-specific state needs backend affinity.
- Cookie-based persistence is acceptable.
- The application is stateful or legacy.
- Shopping cart
- Login session
- User-specific application state
- Legacy stateful applications
Use IP Hash when:
- Client IPs are relatively stable.
- IP-based affinity is sufficient.
- Cookie-based persistence is not required.
- The environment has a specific IP-based affinity requirement.
- Controlled corporate networks
- Stable client IP environments
- Applications requiring IP-based affinity
Session Persistence maintains backend affinity using a persistence cookie, while IP Hash uses the client's source IP address to select the backend. For example, if a user is accessing an application through a mobile hotspot and the IP changes, IP Hash can map the user to a different backend. With Session Persistence, the browser can continue sending the persistence cookie, so the session can remain associated with the same backend. Also, multiple users behind the same NAT can be mapped to the same backend with IP Hash, which may cause uneven load distribution.
Session Persistence = Cookie-based affinity, whereas IP Hash = Source-IP-based affinity.