Incoming HTTP Requests Part 0 - HTTP Traffic Overview
What
In the previous stories you learned what happens when an app dev pushes a new app with a route. In this story, you will learn at a high level what happens when an end user connects to an app using the route.
Each step marked with a ✨ will be explained in more detail in a story in this track.
When an internet user sends traffic to your app
- The user visits your route in the browser or curls it via the command line.
- The traffic first hits a load balancer in front of the CF Foundation.
- The load balancer sends it to one of the GoRouters.
- ✨ The GoRouter consults the route table and sends it to the listed IP and port. If Route Integrity is enabled, it sends this traffic via TLS. (This was explored in the previous story!)
- ✨ The traffic makes its way to the correct Diego Cell, where it hits iptables DNAT rules that reroutes the traffic to the sidecar envoy for the app.
- ✨ The Envoy terminates the TLS from the GoRouter and then sends the traffic on to the app.
How
The following stories will look at how many components (Cloud Controller, Diego BBS, Route Emitter, Nats, GoRouter, DNAT Rules, Envoy) work together to make routes work.
- 🤔 Step through steps above and follow along on the HTTP Routing section of this diagram
Expected Result
You can talk about HTTP network traffic flow with fellow CF engineers.
Logistics
In the next few stories, you are going to need to remember values from one story to another, there will be a space provided at the bottom of each story for your to record these values so you can store them.
Resources for the entire route propagation track
Cloud Controller
Diego
NATs
GoRouter
Iptables
Route Integrity
Envoy