← Back to branch summary

~ubuntu-branches/ubuntu/vivid/haproxy/vivid

« back to all changes in this revision

Viewing changes to doc/internals/entities.txt

  • Committer: Package Import Robot
  • Author(s): Apollon Oikonomopoulos
  • Date: 2014-06-20 11:05:17 UTC
  • mfrom: (1.1.15) (15.1.12 experimental)
  • Revision ID: package-import@ubuntu.com-20140620110517-u6q5p9kyy2f3ozw9
Tags: 1.5.0-1
* New upstream stable series. Notable changes since the 1.4 series:
  + Native SSL support on both sides with SNI/NPN/ALPN and OCSP stapling.
  + IPv6 and UNIX sockets are supported everywhere
  + End-to-end HTTP keep-alive for better support of NTLM and improved
    efficiency in static farms
  + HTTP/1.1 response compression (deflate, gzip) to save bandwidth
  + PROXY protocol versions 1 and 2 on both sides
  + Data sampling on everything in request or response, including payload
  + ACLs can use any matching method with any input sample
  + Maps and dynamic ACLs updatable from the CLI
  + Stick-tables support counters to track activity on any input sample
  + Custom format for logs, unique-id, header rewriting, and redirects
  + Improved health checks (SSL, scripted TCP, check agent, ...)
  + Much more scalable configuration supports hundreds of thousands of
    backends and certificates without sweating

* Upload to unstable, merge all 1.5 work from experimental. Most important
  packaging changes since 1.4.25-1 include:
  + systemd support.
  + A more sane default config file.
  + Zero-downtime upgrades between 1.5 releases by gracefully reloading
    HAProxy during upgrades.
  + HTML documentation shipped in the haproxy-doc package.
  + kqueue support for kfreebsd.

* Packaging changes since 1.5~dev26-2:
  + Drop patches merged upstream:
    o Fix-reference-location-in-manpage.patch
    o 0001-BUILD-stats-workaround-stupid-and-bogus-Werror-forma.patch
  + d/watch: look for stable 1.5 releases
  + systemd: respect CONFIG and EXTRAOPTS when specified in
    /etc/default/haproxy.
  + initscript: test the configuration before start or reload.
  + initscript: remove the ENABLED flag and logic.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/internals/entities.txt
 
1
2011/02/25 - Description of the different entities in haproxy - w@1wt.eu
 
2
 
 
3
 
 
4
1) Definitions
 
5
--------------
 
6
 
 
7
Listener
 
8
--------
 
9
 
 
10
A listener is the entity which is part of a frontend and which accepts
 
11
connections. There are as many listeners as there are ip:port couples.
 
12
There is at least one listener instanciated for each "bind" entry, and
 
13
port ranges will lead to as many listeners as there are ports in the
 
14
range. A listener just has a listening file descriptor ready to accept
 
15
incoming connections and to dispatch them to upper layers.
 
16
 
 
17
 
 
18
Initiator
 
19
---------
 
20
 
 
21
An initiator is instanciated for each incoming connection on a listener. It may
 
22
also be instanciated by a task pretending to be a client. An initiator calls
 
23
the next stage's accept() callback to present it with the parameters of the
 
24
incoming connection.
 
25
 
 
26
 
 
27
Session
 
28
-------
 
29
 
 
30
A session is the only entity located between an initiator and a connector.
 
31
This is the last stage which offers an accept() callback, and all of its
 
32
processing will continue with the next stage's connect() callback. It holds
 
33
the buffers needed to forward the protocol data between each side. This entity
 
34
sees the native protocol, and is able to call analysers on these buffers. As it
 
35
is used in both directions, it always has two buffers.
 
36
 
 
37
When transformations are required, some of them may be done on the initiator
 
38
side and other ones on the connector side. If additional buffers are needed for
 
39
such transforms, those buffers cannot replace the session's buffers, but they
 
40
may complete them.
 
41
 
 
42
A session only needs to be instanciated when forwarding of data is required
 
43
between two sides. Accepting and filtering on layer 4 information only does not
 
44
require a session.
 
45
 
 
46
For instance, let's consider the case of a proxy which receives and decodes
 
47
HTTPS traffic, processes it as HTTP and recodes it as HTTPS before forwarding
 
48
it. We'd have 3 layers of buffers, where the middle ones are used for
 
49
forwarding of the protocol data (HTTP here) :
 
50
 
 
51
            <-- ssl dec --> <-forwarding-> <-- ssl enc -->
 
52
 
 
53
              ,->[||||]--.   ,->[||||]--.   ,->[||||]--.
 
54
   client  (|)            (|)            (|)            (|)  server
 
55
              ^--[||||]<-'   ^--[||||]<-'   ^--[||||]<-'
 
56
 
 
57
                  HTTPS          HTTP          HTTPS
 
58
 
 
59
The session handling code is only responsible for monitoring the forwarding
 
60
buffers here. It may declare the end of the session once those buffers are
 
61
closed and no analyser wants to re-open them. The session is also the entity
 
62
which applies the load balancing algorithm and decides the server to use.
 
63
 
 
64
The other sides are responsible for propagating the state up to the session
 
65
which takes decisions.
 
66
 
 
67
 
 
68
Connector
 
69
---------
 
70
 
 
71
A connector is the entity which permits to instanciate a connection to a known
 
72
destination. It presents a connect() callback, and as such appears on the right
 
73
side of diagrams.
 
74
 
 
75
 
 
76
Connection
 
77
----------
 
78
 
 
79
A connection is the entity instanciated by a connector. It may be composed of
 
80
multiple stages linked together. Generally it is the part of the stream
 
81
interface holding a file descriptor, but it can also be a processing block or a
 
82
transformation block terminated by a connection. A connection presents a
 
83
server-side interface.
 
84
 
 
85
 
 
86
2) Sequencing
 
87
-------------
 
88
 
 
89
Upon startup, listeners are instanciated by the configuration. When an incoming
 
90
connection reaches a listening file descriptor, its read() callback calls the
 
91
corresponding listener's accept() function which instanciates an initiator and
 
92
in turn recursively calls upper layers' accept() callbacks until
 
93
accept_session() is called. accept_session() instanciates a new session which
 
94
starts protocol analysis via process_session(). When all protocol analysis is
 
95
done, process_session() calls the connect() callback of the connector in order
 
96
to get a connection.