21–30 of 79 posts
Almost every browser, except for IE, supports the `Referrer-Policy` header. We should be aiming to avoid additional redirects, not to make them faster.
Earlier quoted context omitted.
No, the equivalent Clouflare service is Spectrum, which is tellingly expensive at $1/GB (!) than AWS Ubiquity / Global Accelerator. Cloudflare Argo is "more like" AWS Edge-optimized API Gateway.
These terms are (or the lack of terms is) pretty horrible: Ubiquity, Argo, Spectrum, Accelerator. Sounds like names given to ironic sci-fi story characters.
Using a Rwandan TLD negates pretty much all the effort in finding the fastest provider. No glue records and an unresponsive TLD nameserver translates into 100+ms for the initial DNS lookup (likely the only one that matters for such a service).
I didn't know this! How is this different from AWS CloudFront?
Full disclosure, I work at Fly.io now. This exact setup is easier on Fly.io - our proxy layer runs in 20 regions worldwide with anycast, so your requests hit the nearest region and quickly terminate TLS there. You can also run any Docker container, and either choose regions to run them in, or just set the min/max and ask us to start and stop containers in whichever region has demand, so your deployment follows the su…
On ocassion, it breaks UDP protocols that are "connection oriented" (like QUIC and WireGuard, though both have built-in capabilities to recover).
There is no way to pin traffic to VMs (route / client affinities) or shape traffic.
100+ locations with GA, and two Anycast IPs (in two distinct "zones").
---
Alternatives to Fly on AWS that I know of:
Anycast on AWS without global accelerator: S3 buckets with transfer acceleration); (edge optimized) API Gateway to Lamba / Fargate; S3 + CloudFront.
AWS AppRunner + Copilot (which are comparable to Fly + Flyctl) can be geo-routed to nearest instance by DNS-based load balancing with Route53 (not anycast specifically).
---
Fly's killer feature (and why we are transitioning to it) is its cost-effectiveness and almost 'zero-devops' setup.
- Super cheap bandwidth ($2 per 100GB!)
- Free deploys (AppRunner charges for deploys)
- Free monitoring (versus expensive but comprehensive CloudWatch)
- Free orchestration
- Free anycast transit (expensive on aws)
- Cheaper, zero-touch, global/cross-region private-network across VMs in the same fly org (zero-muck: transit gateway, nat gateway, internet gateway, vpc private endpoints, iam policies...).
- Super cheap and fast disks ($0.15 per GB/disk!)
- Easier HA Postgres and HA Redis setups.
- GA's TCP proxy does not preserve source/client ip-ports (Fly can).
Full disclosure, I work at Fly.io now. This exact setup is easier on Fly.io - our proxy layer runs in 20 regions worldwide with anycast, so your requests hit the nearest region and quickly terminate TLS there. You can also run any Docker container, and either choose regions to run them in, or just set the min/max and ask us to start and stop containers in whichever region has demand, so your deployment follows the su…
Isn’t AWS Global Accelerator more like CloudFlare Argo, rather than CloudFlare Workers?
Earlier quoted context omitted.
Looks to be a service to remove the HTTP referer header when linking to other sites. Say your on example.com and click a a link to foo.com the browser will send the http header `Referer: example.com` in the HTTP get to foo.com, this means foo.com can then track how you came to their site.
The only place I've even seen this is torrent sites linking to IMDB. Does it have a legitimate use?
Using a Rwandan TLD negates pretty much all the effort in finding the fastest provider. No glue records and an unresponsive TLD nameserver translates into 100+ms for the initial DNS lookup (likely the only one that matters for such a service).
If you dig +trace url.rw, you can see that the NS record for url.rw is held on ns-rw.afrinic.net, pch.ricta.org.rw, ns1.ricta.org.rw, ns3.ricta.org.rw and fork.sth.dnsnode.net. It's true that some of those servers are slower than others (for me, the AfriNIC server is 500ms whilst the dnsnode.net server is 50ms), but that shouldn't really matter because the TTL on the record is 86400. So the chances are that all the big DNS services (8.8.8.8 etc) should have the correct nameservers for url.rw in the cache already. Yes, if you're running a local-ish resolver, things are different... but most folks are dependent on Google, Cloudflare or their (large) ISP.
The actual A record for url.rw is held on AWS's DNS servers, with a TTL of 300. But AWS's DNS servers are fast.