sozu-proxy / sozu Goto Github PK
View Code? Open in Web Editor NEWSōzu HTTP reverse proxy, configurable at runtime, fast and safe, built in Rust. It is awesome!
Home Page: https://www.sozu.io/
License: GNU Affero General Public License v3.0
Sōzu HTTP reverse proxy, configurable at runtime, fast and safe, built in Rust. It is awesome!
Home Page: https://www.sozu.io/
License: GNU Affero General Public License v3.0
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 @divarvel on Jun 1, 2016, 15:34
In gitlab by @Geal on Mar 9, 2016, 23:08
This will let other possible workers handle it
In gitlab by @divarvel on Aug 12, 2015, 11:36
In gitlab by @Geal on Jan 7, 2016, 16:31
In gitlab by @waxzce on Jan 7, 2016, 18:14
based on multiple docker image + nginx
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 Jan 7, 2016, 16:38
In gitlab by @Geal on Feb 26, 2016, 19:22
'cos it's fast
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 8, 2016, 16:15
In gitlab by @divarvel on Aug 12, 2015, 11:19
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 @Geal on Jan 7, 2016, 16:43
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 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 @divarvel on Aug 12, 2015, 11:19
In gitlab by @Geal on Mar 30, 2016, 18:47
The Server
object 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 Mar 8, 2016, 18:01
In gitlab by @Geal on Jan 7, 2016, 16:36
In gitlab by @Geal on Mar 8, 2016, 13:48
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 Jan 7, 2016, 16:38
In gitlab by @Geal on Mar 7, 2016, 16:42
In gitlab by @Geal on Jan 7, 2016, 16:26
The client expects another response afterwards
In gitlab by @Geal on Mar 24, 2016, 19:22
In gitlab by @divarvel on Aug 16, 2015, 13:33
In gitlab by @Geal on Mar 9, 2016, 11:12
In gitlab by @Geal on Mar 1, 2016, 17:20
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 9, 2016, 16:42
Not sure the benefit is big here, but it can be interesting
In gitlab by @Geal on Mar 8, 2016, 13:41
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 9, 2016, 22:57
In gitlab by @divarvel on Aug 16, 2015, 13:38
ToDo: clearly define: "when necessary"
In gitlab by @Geal on Jan 7, 2016, 16:40
In gitlab by @divarvel on Aug 16, 2015, 13:32
(ie the 404 clever page)
In gitlab by @Geal on Mar 9, 2016, 23:14
In gitlab by @Geal on Jan 7, 2016, 16:35
In gitlab by @divarvel on Jun 9, 2016, 14:45
To allow for autonomous reboots
In gitlab by @waxzce on Jan 7, 2016, 16:09
In gitlab by @Geal on Mar 30, 2016, 15:44
In gitlab by @Geal on Mar 9, 2016, 16:57
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:
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 Mar 30, 2016, 15:48
In gitlab by @Geal on Jan 7, 2016, 16:49
In gitlab by @divarvel on Jun 1, 2016, 16:11
In gitlab by @Geal on Jan 7, 2016, 16:39
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.