sozu-proxy / sozu Goto Github PK

In gitlab by @divarvel on Aug 12, 2015, 11:19

In gitlab by @Geal on Jan 7, 2016, 16:49

In gitlab by @divarvel on Aug 12, 2015, 11:36

In gitlab by @waxzce on Jan 7, 2016, 18:14

based on multiple docker image + nginx

In gitlab by @Geal on Mar 9, 2016, 16:42

Not sure the benefit is big here, but it can be interesting

In gitlab by @divarvel on Jun 1, 2016, 15:54

(see line 13, there is a 1 to 1 relationship between frontend (hostname * path begin) and app_id (whereas it should be one to many, so that indicates duplicate app_id), and a 1 to many relationship between frontend and instance (it should be between frontend and app_id).

The proxy should maintain a state for applications as well (sticky sessions, redirect to https, deployment in progress… )

In gitlab by @Geal on Mar 9, 2016, 18:02

Current tests are done on a 512MB droplet from Digital Ocean, with HTTP requests generated by ab or wrk, from a Dedibox. The proxy is forwarding requests to the Clever Cloud frontend, with the hostname "http://wp-perf-test.cleverapps.io" or "http://rust.cleverapps.io".

Issues with this:

• the wp-perf-test website is a Wordpress, so it has a very high latency by default
• the rust website returns a very small response, it does not look like real traffic
• ab is too limited
• wrk does not give much indication of why some requests failed
• the digital ocean droplet is too small

Ideally, a benchmark would compare to haproxy, with load balancing on multiple backends, and it would gradually increase the number of concurrent requests, until the proxy starts failing.
That benchmark would also record perf info, with sysdig or something else.

In gitlab by @Geal on Apr 8, 2016, 18:37

We should add the X-Forwarded-For header or the new spec.

There should be a configuration option to activate one or the other

In gitlab by @Geal on Feb 26, 2016, 19:22

'cos it's fast

In gitlab by @divarvel on Aug 16, 2015, 13:32

(ie the 404 clever page)

In gitlab by @divarvel on Aug 16, 2015, 13:33

In gitlab by @Geal on Jan 7, 2016, 16:43

HTTP and HTTPS proxies have a lot of code in common, but socket reads and writes, socket errors and the accept() behaviour are different.

They should be abstracted to allow HTTP or HTTPS connections to backend, independently from the frontend connection. accept() can stay proxy-specific

In gitlab by @divarvel on Aug 16, 2015, 14:09

For now we only need to get the Host header, so complete parsing of the other header fields is useless.

In gitlab by @Geal on Mar 8, 2016, 18:01

In gitlab by @Geal on Mar 9, 2016, 22:57

In gitlab by @divarvel on Jun 1, 2016, 15:34

In gitlab by @Geal on Mar 24, 2016, 19:22

In gitlab by @Geal on Mar 30, 2016, 18:47

The Serverobject makes decisions based on what a Client(an active frontend connection with possibly a related backend connection) returns, like accepting reads or writes on which socket, or which socket should be closed.
That Server or the ServerConfiguration for the related proxy should accumulate metrics from the multiples Clients, like request handling latency

In gitlab by @Geal on Jan 7, 2016, 16:35

In gitlab by @Geal on Mar 9, 2016, 16:57

In gitlab by @Geal on Mar 30, 2016, 15:48

In gitlab by @Geal on Apr 11, 2016, 19:11

Right now, the additional headers are inserted right into the input buffer, and if it is nearly full, we might not be able to insert them.

A better solution (the one implemented in HAProxy, I think) would be to avoid editing the buffer, and instead remember which slices of the input buffer to send (if some data was deleted), and which external slices (header rewriting, additional header) should be inserted.

Then, in the writable and back_writable, instead of passing just one buffer, the proxy would go through a list of slices to write to the socket. Some would advance the input buffer position, some would not.

This solution requires the parser to send back a list of subslices, and the proxy to track the end of headers (to insert headers at the right position).

In gitlab by @Geal on Mar 8, 2016, 13:41

In gitlab by @Geal on Jan 7, 2016, 16:36

In gitlab by @Geal on Jan 7, 2016, 16:40

In gitlab by @Geal on Apr 8, 2016, 18:37

Add a runtime config option, to activate it dynamically (maybe app specific?)

In gitlab by @Geal on Jan 7, 2016, 16:43

In gitlab by @Geal on Jan 7, 2016, 16:26

The client expects another response afterwards

In gitlab by @Geal on Mar 9, 2016, 16:32

it does not use network::buffer::Buffer and the splicing part does not compile

In gitlab by @Geal on Apr 11, 2016, 19:14

The current solution is very simple: generate a header Forwarded: for=client_ip;by=front_ip" and delete any Forwarded, X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port headers provided by the client.

A more correct solution would, according to the specification, parse any of those headers in a structure assembling forwarding info, check the list of forwarded addresses (with the by element as well), delete the incoming headers, then write out a correct Forwarded header

In gitlab by @Geal on Mar 7, 2016, 16:42

In gitlab by @divarvel on Aug 16, 2015, 13:38

ToDo: clearly define: "when necessary"

In gitlab by @Geal on Mar 9, 2016, 23:14

• SSE4.2 character search: https://github.com/h2o/picohttpparser/blob/master/picohttpparser.c#L104
• AVX2: https://github.com/h2o/picohttpparser/pull/10/files

In gitlab by @waxzce on Dec 14, 2015, 20:25

Maybe a great time to get a readme, even minimal ?

In gitlab by @Keruspe on Mar 1, 2016, 14:22

Currently, openssl is unconditionally built with sslv3 support (features = ["tlsv1_2", "tlsv1_1", "sslv3"]).

This makes the build fail with libressl which onlysupports TLS

In gitlab by @Geal on Mar 8, 2016, 16:15

In gitlab by @Geal on Jan 7, 2016, 16:38

In gitlab by @Geal on Mar 30, 2016, 15:42

otherwise, the loop tries to read over and over and consumes CPU for nothing

In gitlab by @Geal on Mar 30, 2016, 15:44

In gitlab by @Geal on Mar 9, 2016, 11:12

In gitlab by @Geal on Jan 7, 2016, 16:38

In gitlab by @Geal on Mar 1, 2016, 17:20

In gitlab by @Geal on Mar 9, 2016, 23:08

This will let other possible workers handle it

In gitlab by @divarvel on Jun 1, 2016, 16:11

In gitlab by @Geal on Jan 7, 2016, 16:31

In gitlab by @divarvel on Aug 12, 2015, 11:19

In gitlab by @waxzce on Jan 7, 2016, 16:09

In gitlab by @divarvel on Jun 9, 2016, 14:45

To allow for autonomous reboots

In gitlab by @Geal on Mar 8, 2016, 13:48

In gitlab by @Geal on Jan 7, 2016, 16:39