forked from superfly/docs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
services.html.md.erb
63 lines (40 loc) · 4.03 KB
/
services.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
---
title: "Public Network Services"
layout: docs
sitemap: false
nav: firecracker
---
Fly has public and private network services available. The public network services connect applications to the wider public internet, while the [private network services](/docs/reference/private-networking) allow application instances to communicate with other application instances within the Fly private network.
## _IP addresses_
Fly applications have dedicated IP addresses. Each application starts with two addresses — one IPv6 and one IPv4. IPv6 addresses are free, global IPv4 addresses are billed monthly.
### Anycast
We announce global IP blocks from all of our datacenters over BGP, otherwise known as anycast. Anycast is a core internet routing mechanism that connects clients to the "nearest" server advertising a block of IPs. [You can read all about it on Wikipedia](https://en.wikipedia.org/wiki/Anycast).
## _Connection handlers_
The `handlers` config setting specifies which middleware applies to incoming TCP connections. Use these to convert TCP connections into something your application can handle.
### TLS
The `TLS` middleware terminates TLS using Fly managed application certificates, then forwards a plaintext connection to the application process. This is useful for running TCP services and offloading `TLS` to the Fly proxy.
For performance purposes, the Fly proxy will terminate TLS on the host a client connects to, and then forward the connection to the nearest available application instance.
_Note:_ the `TLS` handler includes ALPN negotiation for HTTP/2. When possible, applications will connect to these kinds of Fly services using HTTP/2, and we will forward an unencrypted HTTP/2 connection (`h2c`) to the application process.
### HTTP
Many applications have limited HTTP support, the `HTTP` middleware normalizes HTTP connections and sends HTTP 1.1 requests to the application process. This is roughly how `nginx` and other reverse proxies work, and allows your application to globally accept modern HTTP protocols (like HTTP/2) without extra complexity.
If your application stack has good HTTP/2 support (like Go), you will get better performance accepting TCP connections directly, and using the TLS handler to terminate SSL. Your application _does_ need to understand `h2c` for this to work, however.
The HTTP handler adds a number of standard HTTP headers to requests, and a few Fly specific headers for convenience:
| Header | Description
| -- | -- |
| `Fly-Client-IP` | The IP address Fly accepted a connection from |
| `X-Forwarded-For` | A comma separated list of proxy servers the request passed through. MDN has [full documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For) for this header |
| `X-Forwarded-Proto` | Original client protocol, either `http` or `https` |
| `X-Forwarded-SSL` | Indicates if client connected over SSL, either `on` or `off` |
| `X-Forwarded-Port` | Original connection port, header may be set by client |
| `Fly-Forwarded-Port` | Original connection port, always set by Fly |
| `Fly-Region` | Original incoming connection region |
You can set a preference on HTTP requests for which region you would like to connect to:
```
Fly-Prefer-Region: region-code
```
### TCP pass through
If you don't specify handlers, we just forward TCP to your application as is. This is useful if you want to handle TLS termination yourself, for example.
### Proxy protocol
The `proxy_proto` handler adds information about the original connection, including client IP + port and server IP + port (from the client's perspective). Most applications need additional logic to accept the proxy protocol, either using a prebuilt library or implementing the [proxy protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt) directly.
## _HTTP to HTTPS redirects_
The `force_https` configuration option automatically redirects HTTP to HTTPS. When enabled, all HTTP requests return a redirect response with a `301` status code. This option can only be set on HTTP handlers - deployments will fail if set on other handlers.