3 ms·

What's the source IP for these sockets? Is it consistent across requests? Opening a raw socket from a worker combined with a basic HTTP implementation could le

by koolba 3y ago

What's the source IP for these sockets? Is it consistent across requests? Opening a raw socket from a worker combined with a basic HTTP implementation could let you create a dynamic proxy that uses Cloudflare's worker IP range as the source address. That sounds like a fun^Winteresting way of getting around rate limits. Related, does waiting for I/O count as "cpu time"? A proxy request might 10s of ms in total, but most of that will be waiting for packets to flow back and forth.

ignoramous 3y ago
> Opening a raw socket from a worker combined with a basic HTTP implementation could let you create a dynamic proxy Yep, see: https://github.com/zizifn/edgetunnel https://github.com/zizifn/edgetunnel > Related, does waiting for I/O count as "cpu time"? No. > but most of that will be waiting for packets to flow back and forth. If you don't await on the contents but simply pipe the streams in and out, you should be well within CPU-related limits.
eurleif 3y ago
>What's the source IP for these sockets? Is it consistent across requests? Just did some brief testing. For me, the source IP wasn't consistent, but it was from an IP range belonging to Cloudflare. Notably, however, it wasn't from one of the IP ranges listed at https://www.cloudflare.com/ips/ https://www.cloudflare.com/ips/ unlike requests made from a Worker via `fetch()`. So, if you initiate two requests from the same worker -- one with `connect()`, and the other with `fetch()` -- then the first request uses a source IP belonging to Cloudflare but not from a range listed on their IP range page, while the second uses a source IP from a range listed on their IP range page. I suspect the reason for the different behavior is to do with the `Cf-Worker` header that `fetch()` adds, which enables applications to differentiate requests made by a Worker from requests made by Cloudflare itself. Raw TCP sockets can't add headers, so they need to differentiate themselves another way.
- kentonv 3y ago
  Yes, that's correct, and yes, that's the reason. :)

by koolba 3y ago

ignoramous 3y ago

> Opening a raw socket from a worker combined with a basic HTTP implementation could let you create a dynamic proxy Yep, see: https://github.com/zizifn/edgetunnel https://github.com/zizifn/edgetunnel > Related, does waiting for I/O count as "cpu time"? No. > but most of that will be waiting for packets to flow back and forth. If you don't await on the contents but simply pipe the streams in and out, you should be well within CPU-related limits.

eurleif 3y ago

>What's the source IP for these sockets? Is it consistent across requests? Just did some brief testing. For me, the source IP wasn't consistent, but it was from an IP range belonging to Cloudflare. Notably, however, it wasn't from one of the IP ranges listed at https://www.cloudflare.com/ips/ https://www.cloudflare.com/ips/ unlike requests made from a Worker via `fetch()`. So, if you initiate two requests from the same worker -- one with `connect()`, and the other with `fetch()` -- then the first request uses a source IP belonging to Cloudflare but not from a range listed on their IP range page, while the second uses a source IP from a range listed on their IP range page. I suspect the reason for the different behavior is to do with the `Cf-Worker` header that `fetch()` adds, which enables applications to differentiate requests made by a Worker from requests made by Cloudflare itself. Raw TCP sockets can't add headers, so they need to differentiate themselves another way.

kentonv 3y ago
Yes, that's correct, and yes, that's the reason. :)