28 November 2018

A Few Milliseconds in the Life of an HTTP Request (CTD416)

by mo


Jorge Vasquez - Sr. Software Engineer Hongmin Liu

In Amazon CloudFront, a lot happens in just a few milliseconds. Join us for a dive deep into the infrastructure and architecture of the AWS edge services, including Amazon CloudFront, Amazon Route 53, AWS Shield, and AWS WAF. We break down the life of an HTTP request, and any request in general, and walk you through how each of the AWS edge services work together in just a few milliseconds to consistently deliver your application’s content with high availability, security, and performance. Learn how edge services intelligently route requests to the most ideal edge location, secure your content behind the scenes, and leverage the AWS private network for improved performance.

  • Overview
  • DNS
  • TCP/TLS
  • Request flow in cloudfront
  • cloudfront layers

  • POP - point of presence (aka edge servers)
    • 150 pop servers
  1. isp dns resolver (recursive resolver. breaksdown name and requests from other resolvers)
  2. route 53 front every dns request -> will choose best point of presense server -> isp caches this dns result
  3. user tcp/tls -> cloudfront pop

resolver -> pop

  • need to think of perf.
  • need to think of capacity. (capacity changes)
  • need to check pop health. (pops go down for maintenance)
  • network capacity. (if network is congested we need to choose a better path.)

Measuring the internet in realtime: look up on youtube

tcp connection

  • 3 way handshake:
    • syn, syn + ack, ack, data1
    • syn, syn + ack, ack, data2

TCP fast open

  • client can tell server that it supports fast open.
  • cf sends cookie to identify client
  • 1 less round trip for the data

TLS security

  • security
    • secrecy: coffee shop privacy
    • identity:
    • non-replayability: cannot capture a request and send it again.

cloudfront tls

  • on top of security issues
  • best practices: do not manually have to configure ciphers and dropdown. easy and PCI compliant.
  • compliance

best security is invisible

TLS performance

  • visible security
    • go to airport and show what is in your bag and get scanned
  • invisible security keyfob to open car is imperceptible

client -> server

extra roundtrip to start tls session.

  • 2 RTT

cloud front support sessions resumption

  • 1 RTT

cloudfront pop

  • many layers

router chooses a random server for each connection. round robin

  • l1 server: terminate tls
  • l2 server: cache keys for resources
    • each has different content
    • if cache content is not there it needs to fetch the content from the origin server
  • l3 server:
    • connect to origin server
    • keep connections open to avoid additional handshakes
    • connection re-use is why we have l3 servers.

cloudfront can skip layers

  • L1 two components tls/tcp components
  • L1 can skip the second component and go straight to layer 2

regional edge caches (REC)

  • CDN for CDN’s

Layer 1

  • from layer of cache backend. no cache. only security. security check before getting on your flight.
  • signed urls
    • serve private content
    • policy, signature, key pair id
      • key pair id is used to lookup public key to verify signature.
  • field level encryption (FLE)
    • cloudfront can server private data by encrypting data.
    • cached content at edge locations can be encrypted.
  • aws waf
  • lambda @ edge

Resources:

devops