| Willy Tarreau | 5c01782 | 2014-10-28 15:58:25 +0100 | [diff] [blame] | 1 | 2014/10/28 - Server connection sharing |
| 2 | |
| 3 | For HTTP/2 we'll have to use multiplexed connections to the servers and to |
| 4 | share them between multiple streams. We'll also have to do this for H/1, but |
| 5 | with some variations since H1 doesn't offer connection status verification. |
| 6 | |
| 7 | In order to validate that an idle connection is still usable, it is desirable |
| 8 | to periodically send health checks over it. Normally, idle connections are |
| 9 | meant to be heavily used, so there is no reason for having them idle for a long |
| 10 | time. Thus we have two possibilities : |
| 11 | |
| 12 | - either we time them out after some inactivity, this saves server resources ; |
| 13 | - or we check them after some inactivity. For this we can send the server- |
| 14 | side HTTP health check (only when the server uses HTTP checks), and avoid |
| 15 | using that to mark the server down, and instead consider the connection as |
| 16 | dead. |
| 17 | |
| 18 | For HTTP/2 we'll have to send pings periodically over these connections, so |
| 19 | it's worth considering a per-connection task to validate that the channel still |
| 20 | works. |
| 21 | |
| 22 | In the current model, a connection necessarily belongs to a session, so it's |
| 23 | not really possible to share them, at best they can be exchanged, but that |
| 24 | doesn't make much sense as it means that it could disturb parallel traffic. |
| 25 | |
| 26 | Thus we need to have a per-server list of idle connections and a max-idle-conn |
| 27 | setting to kill them when there are too many. In the case of H/1 it is also |
| 28 | advisable to consider that if a connection was created to pass a first non- |
| 29 | idempotent request while other idle connections were still existing, then a |
| 30 | connection will have to be killed in order not to exceed the limit. |
| 31 | |