2016-12-22 15:19:38 +01:00
|
|
|
= cowboy_http2(3)
|
|
|
|
|
|
|
|
== Name
|
|
|
|
|
|
|
|
cowboy_http2 - HTTP/2
|
|
|
|
|
|
|
|
== Description
|
|
|
|
|
|
|
|
The module `cowboy_http2` implements HTTP/2
|
|
|
|
as a Ranch protocol.
|
|
|
|
|
2016-12-22 18:13:25 +01:00
|
|
|
== Options
|
2016-12-22 15:19:38 +01:00
|
|
|
|
2017-05-05 13:48:25 +02:00
|
|
|
// @todo Might be worth moving cowboy_clear/tls/stream_h options
|
|
|
|
// to their respective manual, when they are added.
|
|
|
|
|
2016-12-22 15:19:38 +01:00
|
|
|
[source,erlang]
|
|
|
|
----
|
|
|
|
opts() :: #{
|
2019-12-04 11:17:34 +01:00
|
|
|
active_n => pos_integer(),
|
2018-04-26 22:08:05 +02:00
|
|
|
connection_type => worker | supervisor,
|
2019-09-02 14:48:28 +02:00
|
|
|
connection_window_margin_size => 0..16#7fffffff,
|
|
|
|
connection_window_update_threshold => 0..16#7fffffff,
|
Implement dynamic socket buffer sizes
Cowboy will set the socket's buffer size dynamically to
better fit the current workload. When the incoming data
is small, a low buffer size reduces the memory footprint
and improves responsiveness and therefore performance.
When the incoming data is large, such as large HTTP
request bodies, a larger buffer size helps us avoid
doing too many binary appends and related allocations.
Setting a large buffer size for all use cases is
sub-optimal because allocating more than needed
necessarily results in a performance hit (not just
increased memory usage).
By default Cowboy starts with a buffer size of 8192 bytes.
It then doubles or halves the buffer size depending on
the size of the data it receives from the socket. It
stops decreasing at 8192 and increasing at 131072 by
default.
To keep track of the size of the incoming data Cowboy
maintains a moving average. It allows Cowboy to avoid
changing the buffer too often but still react quickly
when necessary. Cowboy will increase the buffer size
when the moving average is above 90% of the current
buffer size, and decrease when the moving average is
below 40% of the current buffer size.
The current buffer size and moving average are
propagated when switching protocols. The dynamic buffer
is implemented in HTTP/1, HTTP/2 and HTTP/1 Websocket.
HTTP/2 Websocket has it disabled because it doesn't
interact directly with the socket; in that case it
is HTTP/2 that has a dynamic buffer.
The dynamic buffer provides a very large performance improvement
in many scenarios, at minimal cost for others. Because it largely
depend on the underlying protocol the improvements are no all equal.
TLS and compression also impact the results.
The improvement when reading a large request body, with the
requests repeated in a fast loop are:
* HTTP: 6x to 20x faster
* HTTPS: 2x to 6x faster
* H2: 4x to 5x faster
* H2C: 20x to 40x faster
I am not sure why H2C's performance was so bad, especially compared
to H2, when using default buffer sizes. Dynamic buffers make H2C a
lot more viable with default settings.
The performance impact on "hello world" type requests is minimal,
it goes from -5% to +5% roughly.
Websocket improvements vary again depending on the protocol, but
also depending on whether compression is enabled:
* HTTP echo: roughly 2x faster
* HTTP send: roughly 4x faster
* H2C echo: roughly 2x faster
* H2C send: 3x to 4x faster
In the echo test we reply back, and Gun doesn't have the dynamic
buffer optimisation, so that probably explains the x2 difference.
With compression however there isn't much improvement. The results
are roughly within -10% to +10% of each other. Zlib compression
seems to be a bottleneck, or at least to modify the performance
profile to such an extent that the size of the buffer does not
matter. This happens to randomly generated binary data as well
so it is probably not caused by the test data.
2025-02-03 15:36:16 +01:00
|
|
|
dynamic_buffer => false | {pos_integer(), pos_integer()},
|
2018-04-26 22:08:05 +02:00
|
|
|
enable_connect_protocol => boolean(),
|
Graceful shutdown
Note: This commit makes cowboy depend on cowlib master.
Graceful shutdown for HTTP/2:
1. A GOAWAY frame with the last stream id set to 2^31-1 is sent and a
timer is started (goaway_initial_timeout, default 1000ms), to wait
for any in-flight requests sent by the client, and the status is set
to 'closing_initiated'. If the client responds with GOAWAY and closes
the connection, we're done.
2. A second GOAWAY frame is sent with the actual last stream id and the
status is set to 'closing'. If no streams exist, the connection
terminates. Otherwise a second timer (goaway_complete_timeout,
default 3000ms) is started, to wait for the streams to complete. New
streams are not accepted when status is 'closing'.
3. If all streams haven't completed after the second timeout, the
connection is forcefully terminated.
Graceful shutdown for HTTP/1.x:
1. If a request is currently being handled, it is waited for and the
response is sent back to the client with the header "Connection:
close". Then, the connection is closed.
2. If the current request handler is not finished within the time
configured in transport option 'shutdown' (default 5000ms), the
connection process is killed by its supervisor (ranch).
Implemented for HTTP/1.x and HTTP/2 in the following scenarios:
* When receiving exit signal 'shutdown' from the supervisor (e.g. when
cowboy:stop_listener/3 is called).
* When a connection process is requested to terminate using
sys:terminate/2,3.
LH: Edited tests a bit and added todos for useful tests to add.
2020-10-08 17:53:25 +02:00
|
|
|
goaway_initial_timeout => timeout(),
|
|
|
|
goaway_complete_timeout => timeout(),
|
2018-11-16 16:30:57 +01:00
|
|
|
idle_timeout => timeout(),
|
2018-04-26 22:08:05 +02:00
|
|
|
inactivity_timeout => timeout(),
|
|
|
|
initial_connection_window_size => 65535..16#7fffffff,
|
|
|
|
initial_stream_window_size => 0..16#7fffffff,
|
2020-04-08 10:27:45 +02:00
|
|
|
linger_timeout => timeout(),
|
2019-10-07 11:43:44 +02:00
|
|
|
logger => module(),
|
2018-04-26 22:08:05 +02:00
|
|
|
max_concurrent_streams => non_neg_integer() | infinity,
|
Fix HTTP/2 CVEs
A number of HTTP/2 CVEs were documented recently:
https://www.kb.cert.org/vuls/id/605641/
This commit, along with a few changes and additions in Cowlib,
fix or improve protection against all of them.
For CVE-2019-9511, also known as Data Dribble, the new option
stream_window_data_threshold can be used to control how little
the DATA frames that Cowboy sends can get.
For CVE-2019-9516, also known as 0-Length Headers Leak, Cowboy
will now simply reject streams containing 0-length header names.
For CVE-2019-9517, also known as Internal Data Buffering, the
backpressure changes were already pretty good at preventing this
issue, but a new option max_connection_buffer_size was added for
even better control over how much memory we are willing to allocate.
For CVE-2019-9512, also known as Ping Flood; CVE-2019-9515, also
known as Settings Flood; CVE-2019-9518, also known as Empty Frame
Flooding; and similar undocumented scenarios, a frame rate limiting
mechanism was added. By default Cowboy will now allow 1000 frames
every 10 seconds. This can be configured via max_received_frame_rate.
For CVE-2019-9514, also known as Reset Flood, another rate limiting
mechanism was added and can be configured via max_reset_stream_rate.
By default Cowboy will do up to 10 stream resets every 10 seconds.
Finally, nothing was done for CVE-2019-9513, also known as Resource
Loop, because Cowboy does not currently implement the HTTP/2
priority mechanism (in parts because these issues were well known
from the start).
Tests were added for all cases except Internal Data Buffering,
which I'm not sure how to test, and Resource Loop, which is not
currently relevant.
2019-10-02 10:44:45 +02:00
|
|
|
max_connection_buffer_size => non_neg_integer(),
|
2019-09-02 14:48:28 +02:00
|
|
|
max_connection_window_size => 0..16#7fffffff,
|
2018-04-26 22:08:05 +02:00
|
|
|
max_decode_table_size => non_neg_integer(),
|
|
|
|
max_encode_table_size => non_neg_integer(),
|
2024-03-14 12:36:54 +01:00
|
|
|
max_fragmented_header_block_size => 16384..16#7fffffff,
|
2018-04-27 17:58:11 +02:00
|
|
|
max_frame_size_received => 16384..16777215,
|
|
|
|
max_frame_size_sent => 16384..16777215 | infinity,
|
Fix HTTP/2 CVEs
A number of HTTP/2 CVEs were documented recently:
https://www.kb.cert.org/vuls/id/605641/
This commit, along with a few changes and additions in Cowlib,
fix or improve protection against all of them.
For CVE-2019-9511, also known as Data Dribble, the new option
stream_window_data_threshold can be used to control how little
the DATA frames that Cowboy sends can get.
For CVE-2019-9516, also known as 0-Length Headers Leak, Cowboy
will now simply reject streams containing 0-length header names.
For CVE-2019-9517, also known as Internal Data Buffering, the
backpressure changes were already pretty good at preventing this
issue, but a new option max_connection_buffer_size was added for
even better control over how much memory we are willing to allocate.
For CVE-2019-9512, also known as Ping Flood; CVE-2019-9515, also
known as Settings Flood; CVE-2019-9518, also known as Empty Frame
Flooding; and similar undocumented scenarios, a frame rate limiting
mechanism was added. By default Cowboy will now allow 1000 frames
every 10 seconds. This can be configured via max_received_frame_rate.
For CVE-2019-9514, also known as Reset Flood, another rate limiting
mechanism was added and can be configured via max_reset_stream_rate.
By default Cowboy will do up to 10 stream resets every 10 seconds.
Finally, nothing was done for CVE-2019-9513, also known as Resource
Loop, because Cowboy does not currently implement the HTTP/2
priority mechanism (in parts because these issues were well known
from the start).
Tests were added for all cases except Internal Data Buffering,
which I'm not sure how to test, and Resource Loop, which is not
currently relevant.
2019-10-02 10:44:45 +02:00
|
|
|
max_received_frame_rate => {pos_integer(), timeout()},
|
|
|
|
max_reset_stream_rate => {pos_integer(), timeout()},
|
2023-10-31 11:51:02 +01:00
|
|
|
max_cancel_stream_rate => {pos_integer(), timeout()},
|
2019-09-13 14:20:04 +02:00
|
|
|
max_stream_buffer_size => non_neg_integer(),
|
2019-09-02 14:48:28 +02:00
|
|
|
max_stream_window_size => 0..16#7fffffff,
|
2018-04-26 22:08:05 +02:00
|
|
|
preface_timeout => timeout(),
|
2018-11-14 12:32:31 +01:00
|
|
|
proxy_header => boolean(),
|
2024-01-23 14:48:15 +01:00
|
|
|
reset_idle_timeout_on_send => boolean(),
|
2018-11-03 18:55:40 +01:00
|
|
|
sendfile => boolean(),
|
2018-04-28 10:59:56 +02:00
|
|
|
settings_timeout => timeout(),
|
2019-09-02 14:48:28 +02:00
|
|
|
stream_handlers => [module()],
|
Fix HTTP/2 CVEs
A number of HTTP/2 CVEs were documented recently:
https://www.kb.cert.org/vuls/id/605641/
This commit, along with a few changes and additions in Cowlib,
fix or improve protection against all of them.
For CVE-2019-9511, also known as Data Dribble, the new option
stream_window_data_threshold can be used to control how little
the DATA frames that Cowboy sends can get.
For CVE-2019-9516, also known as 0-Length Headers Leak, Cowboy
will now simply reject streams containing 0-length header names.
For CVE-2019-9517, also known as Internal Data Buffering, the
backpressure changes were already pretty good at preventing this
issue, but a new option max_connection_buffer_size was added for
even better control over how much memory we are willing to allocate.
For CVE-2019-9512, also known as Ping Flood; CVE-2019-9515, also
known as Settings Flood; CVE-2019-9518, also known as Empty Frame
Flooding; and similar undocumented scenarios, a frame rate limiting
mechanism was added. By default Cowboy will now allow 1000 frames
every 10 seconds. This can be configured via max_received_frame_rate.
For CVE-2019-9514, also known as Reset Flood, another rate limiting
mechanism was added and can be configured via max_reset_stream_rate.
By default Cowboy will do up to 10 stream resets every 10 seconds.
Finally, nothing was done for CVE-2019-9513, also known as Resource
Loop, because Cowboy does not currently implement the HTTP/2
priority mechanism (in parts because these issues were well known
from the start).
Tests were added for all cases except Internal Data Buffering,
which I'm not sure how to test, and Resource Loop, which is not
currently relevant.
2019-10-02 10:44:45 +02:00
|
|
|
stream_window_data_threshold => 0..16#7fffffff,
|
2019-09-02 14:48:28 +02:00
|
|
|
stream_window_margin_size => 0..16#7fffffff,
|
|
|
|
stream_window_update_threshold => 0..16#7fffffff
|
2016-12-22 15:19:38 +01:00
|
|
|
}
|
|
|
|
----
|
|
|
|
|
|
|
|
Configuration for the HTTP/2 protocol.
|
|
|
|
|
|
|
|
This configuration is passed to Cowboy when starting listeners
|
2017-06-07 15:15:54 +02:00
|
|
|
using `cowboy:start_clear/3` or `cowboy:start_tls/3` functions.
|
2016-12-22 15:19:38 +01:00
|
|
|
|
|
|
|
It can be updated without restarting listeners using the
|
|
|
|
Ranch functions `ranch:get_protocol_options/1` and
|
|
|
|
`ranch:set_protocol_options/2`.
|
|
|
|
|
2016-12-22 18:13:25 +01:00
|
|
|
The default value is given next to the option name:
|
2016-12-22 15:19:38 +01:00
|
|
|
|
Implement dynamic socket buffer sizes
Cowboy will set the socket's buffer size dynamically to
better fit the current workload. When the incoming data
is small, a low buffer size reduces the memory footprint
and improves responsiveness and therefore performance.
When the incoming data is large, such as large HTTP
request bodies, a larger buffer size helps us avoid
doing too many binary appends and related allocations.
Setting a large buffer size for all use cases is
sub-optimal because allocating more than needed
necessarily results in a performance hit (not just
increased memory usage).
By default Cowboy starts with a buffer size of 8192 bytes.
It then doubles or halves the buffer size depending on
the size of the data it receives from the socket. It
stops decreasing at 8192 and increasing at 131072 by
default.
To keep track of the size of the incoming data Cowboy
maintains a moving average. It allows Cowboy to avoid
changing the buffer too often but still react quickly
when necessary. Cowboy will increase the buffer size
when the moving average is above 90% of the current
buffer size, and decrease when the moving average is
below 40% of the current buffer size.
The current buffer size and moving average are
propagated when switching protocols. The dynamic buffer
is implemented in HTTP/1, HTTP/2 and HTTP/1 Websocket.
HTTP/2 Websocket has it disabled because it doesn't
interact directly with the socket; in that case it
is HTTP/2 that has a dynamic buffer.
The dynamic buffer provides a very large performance improvement
in many scenarios, at minimal cost for others. Because it largely
depend on the underlying protocol the improvements are no all equal.
TLS and compression also impact the results.
The improvement when reading a large request body, with the
requests repeated in a fast loop are:
* HTTP: 6x to 20x faster
* HTTPS: 2x to 6x faster
* H2: 4x to 5x faster
* H2C: 20x to 40x faster
I am not sure why H2C's performance was so bad, especially compared
to H2, when using default buffer sizes. Dynamic buffers make H2C a
lot more viable with default settings.
The performance impact on "hello world" type requests is minimal,
it goes from -5% to +5% roughly.
Websocket improvements vary again depending on the protocol, but
also depending on whether compression is enabled:
* HTTP echo: roughly 2x faster
* HTTP send: roughly 4x faster
* H2C echo: roughly 2x faster
* H2C send: 3x to 4x faster
In the echo test we reply back, and Gun doesn't have the dynamic
buffer optimisation, so that probably explains the x2 difference.
With compression however there isn't much improvement. The results
are roughly within -10% to +10% of each other. Zlib compression
seems to be a bottleneck, or at least to modify the performance
profile to such an extent that the size of the buffer does not
matter. This happens to randomly generated binary data as well
so it is probably not caused by the test data.
2025-02-03 15:36:16 +01:00
|
|
|
active_n (1)::
|
2019-12-04 11:17:34 +01:00
|
|
|
|
|
|
|
The number of packets Cowboy will request from the socket at once.
|
|
|
|
This can be used to tweak the performance of the server. Higher
|
|
|
|
values reduce the number of times Cowboy need to request more
|
|
|
|
packets from the port driver at the expense of potentially
|
|
|
|
higher memory being used.
|
|
|
|
|
2017-05-05 13:48:25 +02:00
|
|
|
connection_type (supervisor)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
|
|
|
Whether the connection process also acts as a supervisor.
|
2017-05-05 13:48:25 +02:00
|
|
|
|
2019-09-02 14:48:28 +02:00
|
|
|
connection_window_margin_size (65535)::
|
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Extra amount in bytes to be added to the window size when
|
2019-09-02 14:48:28 +02:00
|
|
|
updating the connection window. This is used to
|
|
|
|
ensure that there is always some space available in
|
|
|
|
the window.
|
|
|
|
|
|
|
|
connection_window_update_threshold (163840)::
|
|
|
|
|
|
|
|
The connection window will only get updated when its size
|
2019-09-06 11:50:58 +02:00
|
|
|
becomes lower than this threshold, in bytes. This is to
|
|
|
|
avoid sending too many `WINDOW_UPDATE` frames.
|
2019-09-02 14:48:28 +02:00
|
|
|
|
2025-02-05 16:22:06 +01:00
|
|
|
dynamic_buffer ({1024, 131072})::
|
Implement dynamic socket buffer sizes
Cowboy will set the socket's buffer size dynamically to
better fit the current workload. When the incoming data
is small, a low buffer size reduces the memory footprint
and improves responsiveness and therefore performance.
When the incoming data is large, such as large HTTP
request bodies, a larger buffer size helps us avoid
doing too many binary appends and related allocations.
Setting a large buffer size for all use cases is
sub-optimal because allocating more than needed
necessarily results in a performance hit (not just
increased memory usage).
By default Cowboy starts with a buffer size of 8192 bytes.
It then doubles or halves the buffer size depending on
the size of the data it receives from the socket. It
stops decreasing at 8192 and increasing at 131072 by
default.
To keep track of the size of the incoming data Cowboy
maintains a moving average. It allows Cowboy to avoid
changing the buffer too often but still react quickly
when necessary. Cowboy will increase the buffer size
when the moving average is above 90% of the current
buffer size, and decrease when the moving average is
below 40% of the current buffer size.
The current buffer size and moving average are
propagated when switching protocols. The dynamic buffer
is implemented in HTTP/1, HTTP/2 and HTTP/1 Websocket.
HTTP/2 Websocket has it disabled because it doesn't
interact directly with the socket; in that case it
is HTTP/2 that has a dynamic buffer.
The dynamic buffer provides a very large performance improvement
in many scenarios, at minimal cost for others. Because it largely
depend on the underlying protocol the improvements are no all equal.
TLS and compression also impact the results.
The improvement when reading a large request body, with the
requests repeated in a fast loop are:
* HTTP: 6x to 20x faster
* HTTPS: 2x to 6x faster
* H2: 4x to 5x faster
* H2C: 20x to 40x faster
I am not sure why H2C's performance was so bad, especially compared
to H2, when using default buffer sizes. Dynamic buffers make H2C a
lot more viable with default settings.
The performance impact on "hello world" type requests is minimal,
it goes from -5% to +5% roughly.
Websocket improvements vary again depending on the protocol, but
also depending on whether compression is enabled:
* HTTP echo: roughly 2x faster
* HTTP send: roughly 4x faster
* H2C echo: roughly 2x faster
* H2C send: 3x to 4x faster
In the echo test we reply back, and Gun doesn't have the dynamic
buffer optimisation, so that probably explains the x2 difference.
With compression however there isn't much improvement. The results
are roughly within -10% to +10% of each other. Zlib compression
seems to be a bottleneck, or at least to modify the performance
profile to such an extent that the size of the buffer does not
matter. This happens to randomly generated binary data as well
so it is probably not caused by the test data.
2025-02-03 15:36:16 +01:00
|
|
|
|
|
|
|
Cowboy will dynamically change the socket's `buffer` size
|
|
|
|
depending on the size of the data it receives from the socket.
|
|
|
|
This lets Cowboy use the optimal buffer size for the current
|
|
|
|
workload.
|
|
|
|
+
|
|
|
|
The dynamic buffer size functionality can be disabled by
|
|
|
|
setting this option to `false`. Cowboy will also disable
|
|
|
|
it by default when the `buffer` transport option is configured.
|
|
|
|
|
2018-04-04 17:23:37 +02:00
|
|
|
enable_connect_protocol (false)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
|
|
|
Whether to enable the extended CONNECT method to allow
|
|
|
|
protocols like Websocket to be used over an HTTP/2 stream.
|
2024-01-23 15:29:41 +01:00
|
|
|
+
|
|
|
|
For backward compatibility reasons, this option is disabled
|
|
|
|
by default. It must be enabled to use Websocket over HTTP/2.
|
|
|
|
It will be enabled by default in a future release.
|
2018-04-04 17:23:37 +02:00
|
|
|
|
Graceful shutdown
Note: This commit makes cowboy depend on cowlib master.
Graceful shutdown for HTTP/2:
1. A GOAWAY frame with the last stream id set to 2^31-1 is sent and a
timer is started (goaway_initial_timeout, default 1000ms), to wait
for any in-flight requests sent by the client, and the status is set
to 'closing_initiated'. If the client responds with GOAWAY and closes
the connection, we're done.
2. A second GOAWAY frame is sent with the actual last stream id and the
status is set to 'closing'. If no streams exist, the connection
terminates. Otherwise a second timer (goaway_complete_timeout,
default 3000ms) is started, to wait for the streams to complete. New
streams are not accepted when status is 'closing'.
3. If all streams haven't completed after the second timeout, the
connection is forcefully terminated.
Graceful shutdown for HTTP/1.x:
1. If a request is currently being handled, it is waited for and the
response is sent back to the client with the header "Connection:
close". Then, the connection is closed.
2. If the current request handler is not finished within the time
configured in transport option 'shutdown' (default 5000ms), the
connection process is killed by its supervisor (ranch).
Implemented for HTTP/1.x and HTTP/2 in the following scenarios:
* When receiving exit signal 'shutdown' from the supervisor (e.g. when
cowboy:stop_listener/3 is called).
* When a connection process is requested to terminate using
sys:terminate/2,3.
LH: Edited tests a bit and added todos for useful tests to add.
2020-10-08 17:53:25 +02:00
|
|
|
goaway_initial_timeout (1000)::
|
|
|
|
|
|
|
|
Time in ms to wait for any in-flight stream creations before stopping to accept
|
|
|
|
new streams on an existing connection during a graceful shutdown.
|
|
|
|
|
|
|
|
goaway_complete_timeout (3000)::
|
|
|
|
|
|
|
|
Time in ms to wait for ongoing streams to complete before closing the connection
|
|
|
|
during a graceful shutdown.
|
|
|
|
|
2018-11-16 16:30:57 +01:00
|
|
|
idle_timeout (60000)::
|
|
|
|
|
|
|
|
Time in ms with no data received before Cowboy closes the connection.
|
|
|
|
|
2017-05-05 13:48:25 +02:00
|
|
|
inactivity_timeout (300000)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
|
|
|
Time in ms with nothing received at all before Cowboy closes the connection.
|
2017-05-05 13:48:25 +02:00
|
|
|
|
2018-04-26 22:08:05 +02:00
|
|
|
initial_connection_window_size (65535)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Initial window size in bytes for the connection. This is the total amount
|
2018-05-02 11:08:27 +02:00
|
|
|
of data (from request bodies for example) that may be buffered
|
|
|
|
by the connection across all streams before the user code
|
|
|
|
explicitly requests it.
|
2018-04-26 22:08:05 +02:00
|
|
|
+
|
2018-05-02 11:08:27 +02:00
|
|
|
Note that this value cannot be lower than the default.
|
2018-04-26 22:08:05 +02:00
|
|
|
|
|
|
|
initial_stream_window_size (65535)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Initial window size in bytes for new streams. This is the total amount
|
2018-05-02 11:08:27 +02:00
|
|
|
of data (from request bodies for example) that may be buffered
|
|
|
|
by a single stream before the user code explicitly requests it.
|
2018-04-26 22:08:05 +02:00
|
|
|
|
2020-04-08 10:27:45 +02:00
|
|
|
linger_timeout (1000)::
|
|
|
|
|
|
|
|
Time in ms that Cowboy will wait when closing the connection. This is
|
|
|
|
necessary to avoid the TCP reset problem as described in the
|
|
|
|
https://tools.ietf.org/html/rfc7230#section-6.6[section 6.6 of RFC7230].
|
|
|
|
In HTTP/2's case the GOAWAY message might also be lost when
|
|
|
|
closing the connection immediately.
|
|
|
|
|
2019-10-07 11:43:44 +02:00
|
|
|
logger (error_logger)::
|
|
|
|
|
|
|
|
The module that will be used to write log messages.
|
|
|
|
|
2018-04-25 21:32:58 +02:00
|
|
|
max_concurrent_streams (infinity)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
|
|
|
Maximum number of concurrent streams allowed on the connection.
|
2018-04-25 21:32:58 +02:00
|
|
|
|
Fix HTTP/2 CVEs
A number of HTTP/2 CVEs were documented recently:
https://www.kb.cert.org/vuls/id/605641/
This commit, along with a few changes and additions in Cowlib,
fix or improve protection against all of them.
For CVE-2019-9511, also known as Data Dribble, the new option
stream_window_data_threshold can be used to control how little
the DATA frames that Cowboy sends can get.
For CVE-2019-9516, also known as 0-Length Headers Leak, Cowboy
will now simply reject streams containing 0-length header names.
For CVE-2019-9517, also known as Internal Data Buffering, the
backpressure changes were already pretty good at preventing this
issue, but a new option max_connection_buffer_size was added for
even better control over how much memory we are willing to allocate.
For CVE-2019-9512, also known as Ping Flood; CVE-2019-9515, also
known as Settings Flood; CVE-2019-9518, also known as Empty Frame
Flooding; and similar undocumented scenarios, a frame rate limiting
mechanism was added. By default Cowboy will now allow 1000 frames
every 10 seconds. This can be configured via max_received_frame_rate.
For CVE-2019-9514, also known as Reset Flood, another rate limiting
mechanism was added and can be configured via max_reset_stream_rate.
By default Cowboy will do up to 10 stream resets every 10 seconds.
Finally, nothing was done for CVE-2019-9513, also known as Resource
Loop, because Cowboy does not currently implement the HTTP/2
priority mechanism (in parts because these issues were well known
from the start).
Tests were added for all cases except Internal Data Buffering,
which I'm not sure how to test, and Resource Loop, which is not
currently relevant.
2019-10-02 10:44:45 +02:00
|
|
|
max_connection_buffer_size (16000000)::
|
|
|
|
|
|
|
|
Maximum size of all stream buffers for this connection, in bytes.
|
|
|
|
This is a soft limit used to apply backpressure to handlers that
|
|
|
|
send data faster than the HTTP/2 connection allows.
|
|
|
|
|
2019-09-02 14:48:28 +02:00
|
|
|
max_connection_window_size (16#7fffffff)::
|
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Maximum connection window size in bytes. This is used as an upper bound
|
2019-09-02 14:48:28 +02:00
|
|
|
when calculating the window size, either when reading the request
|
|
|
|
body or receiving said body.
|
|
|
|
|
2018-04-25 16:55:52 +02:00
|
|
|
max_decode_table_size (4096)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Maximum header table size in bytes used by the decoder. This is the value
|
|
|
|
advertised to the client. The client can then choose a header table size
|
|
|
|
equal or lower to the advertised value.
|
2018-04-25 16:55:52 +02:00
|
|
|
|
|
|
|
max_encode_table_size (4096)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Maximum header table size in bytes used by the encoder. The server will
|
|
|
|
compare this value to what the client advertises and choose the smallest
|
|
|
|
one as the encoder's header table size.
|
2018-04-25 16:55:52 +02:00
|
|
|
|
2024-03-14 12:36:54 +01:00
|
|
|
max_fragmented_header_block_size (32768)::
|
|
|
|
|
|
|
|
Maximum header block size when headers are split over multiple HEADERS
|
|
|
|
and CONTINUATION frames. Clients that attempt to send header blocks
|
|
|
|
larger than this value will receive an ENHANCE_YOUR_CALM connection
|
|
|
|
error. Note that this value is not advertised and should be large
|
|
|
|
enough for legitimate requests.
|
|
|
|
|
2018-04-27 17:58:11 +02:00
|
|
|
max_frame_size_received (16384)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Maximum size in bytes of the frames received by the server. This value is
|
2018-05-02 11:08:27 +02:00
|
|
|
advertised to the remote endpoint which can then decide to use
|
|
|
|
any value lower or equal for its frame sizes.
|
2024-01-16 13:11:38 +01:00
|
|
|
+
|
|
|
|
It is highly recommended to increase this value for performance reasons.
|
|
|
|
In a future Cowboy version the default will be increased to 1MB (1048576).
|
|
|
|
Too low values may result in very large file uploads failing because
|
|
|
|
Cowboy will detect the large number of frames as flood and close the
|
|
|
|
connection.
|
2018-04-27 17:58:11 +02:00
|
|
|
|
|
|
|
max_frame_size_sent (infinity)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Maximum size in bytes of the frames sent by the server. This option allows
|
2018-05-02 11:08:27 +02:00
|
|
|
setting an upper limit to the frame sizes instead of blindly
|
|
|
|
following the client's advertised maximum.
|
2018-04-27 17:58:11 +02:00
|
|
|
+
|
2018-05-02 11:08:27 +02:00
|
|
|
Note that actual frame sizes may be lower than the limit when
|
|
|
|
there is not enough space left in the flow control window.
|
2018-04-27 17:58:11 +02:00
|
|
|
|
2020-03-29 13:51:21 +02:00
|
|
|
max_received_frame_rate ({10000, 10000})::
|
Fix HTTP/2 CVEs
A number of HTTP/2 CVEs were documented recently:
https://www.kb.cert.org/vuls/id/605641/
This commit, along with a few changes and additions in Cowlib,
fix or improve protection against all of them.
For CVE-2019-9511, also known as Data Dribble, the new option
stream_window_data_threshold can be used to control how little
the DATA frames that Cowboy sends can get.
For CVE-2019-9516, also known as 0-Length Headers Leak, Cowboy
will now simply reject streams containing 0-length header names.
For CVE-2019-9517, also known as Internal Data Buffering, the
backpressure changes were already pretty good at preventing this
issue, but a new option max_connection_buffer_size was added for
even better control over how much memory we are willing to allocate.
For CVE-2019-9512, also known as Ping Flood; CVE-2019-9515, also
known as Settings Flood; CVE-2019-9518, also known as Empty Frame
Flooding; and similar undocumented scenarios, a frame rate limiting
mechanism was added. By default Cowboy will now allow 1000 frames
every 10 seconds. This can be configured via max_received_frame_rate.
For CVE-2019-9514, also known as Reset Flood, another rate limiting
mechanism was added and can be configured via max_reset_stream_rate.
By default Cowboy will do up to 10 stream resets every 10 seconds.
Finally, nothing was done for CVE-2019-9513, also known as Resource
Loop, because Cowboy does not currently implement the HTTP/2
priority mechanism (in parts because these issues were well known
from the start).
Tests were added for all cases except Internal Data Buffering,
which I'm not sure how to test, and Resource Loop, which is not
currently relevant.
2019-10-02 10:44:45 +02:00
|
|
|
|
|
|
|
Maximum frame rate allowed per connection. The rate is expressed
|
|
|
|
as a tuple `{NumFrames, TimeMs}` indicating how many frames are
|
|
|
|
allowed over the given time period. This is similar to a supervisor
|
|
|
|
restart intensity/period.
|
|
|
|
|
|
|
|
max_reset_stream_rate ({10, 10000})::
|
|
|
|
|
|
|
|
Maximum reset stream rate per connection. This can be used to
|
|
|
|
protect against misbehaving or malicious peers that do not follow
|
|
|
|
the protocol, leading to the server resetting streams, by limiting
|
|
|
|
the number of streams that can be reset over a certain time period.
|
|
|
|
The rate is expressed as a tuple `{NumResets, TimeMs}`. This is
|
|
|
|
similar to a supervisor restart intensity/period.
|
|
|
|
|
2023-10-31 11:51:02 +01:00
|
|
|
max_cancel_stream_rate ({500, 10000})::
|
|
|
|
|
|
|
|
Maximum cancel stream rate per connection. This can be used to
|
|
|
|
protect against misbehaving or malicious peers, by limiting the
|
|
|
|
number of streams that the peer can reset over a certain time period.
|
|
|
|
The rate is expressed as a tuple `{NumCancels, TimeMs}`. This is
|
|
|
|
similar to a supervisor restart intensity/period.
|
|
|
|
|
2019-09-13 14:20:04 +02:00
|
|
|
max_stream_buffer_size (8000000)::
|
|
|
|
|
|
|
|
Maximum stream buffer size in bytes. This is a soft limit used
|
|
|
|
to apply backpressure to handlers that send data faster than
|
|
|
|
the HTTP/2 connection allows.
|
|
|
|
|
2019-09-02 14:48:28 +02:00
|
|
|
max_stream_window_size (16#7fffffff)::
|
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Maximum stream window size in bytes. This is used as an upper bound
|
2019-09-02 14:48:28 +02:00
|
|
|
when calculating the window size, either when reading the request
|
|
|
|
body or receiving said body.
|
|
|
|
|
2016-12-22 15:19:38 +01:00
|
|
|
preface_timeout (5000)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
|
|
|
Time in ms Cowboy is willing to wait for the connection preface.
|
2016-12-22 15:19:38 +01:00
|
|
|
|
2018-11-14 12:32:31 +01:00
|
|
|
proxy_header (false)::
|
|
|
|
|
|
|
|
Whether incoming connections have a PROXY protocol header. The
|
|
|
|
proxy information will be passed forward via the `proxy_header`
|
|
|
|
key of the Req object.
|
|
|
|
|
2024-01-23 14:48:15 +01:00
|
|
|
reset_idle_timeout_on_send (false)::
|
|
|
|
|
|
|
|
Whether the `idle_timeout` gets reset when sending data
|
|
|
|
to the socket.
|
|
|
|
|
2018-11-03 18:55:40 +01:00
|
|
|
sendfile (true)::
|
|
|
|
|
|
|
|
Whether the sendfile syscall may be used. It can be useful to disable
|
|
|
|
it on systems where the syscall has a buggy implementation, for example
|
|
|
|
under VirtualBox when using shared folders.
|
|
|
|
|
2018-04-28 10:59:56 +02:00
|
|
|
settings_timeout (5000)::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
|
|
|
Time in ms Cowboy is willing to wait for a SETTINGS ack.
|
2018-04-28 10:59:56 +02:00
|
|
|
|
2017-05-05 13:48:25 +02:00
|
|
|
stream_handlers ([cowboy_stream_h])::
|
2018-05-02 11:08:27 +02:00
|
|
|
|
|
|
|
Ordered list of stream handlers that will handle all stream events.
|
2017-05-05 13:48:25 +02:00
|
|
|
|
Fix HTTP/2 CVEs
A number of HTTP/2 CVEs were documented recently:
https://www.kb.cert.org/vuls/id/605641/
This commit, along with a few changes and additions in Cowlib,
fix or improve protection against all of them.
For CVE-2019-9511, also known as Data Dribble, the new option
stream_window_data_threshold can be used to control how little
the DATA frames that Cowboy sends can get.
For CVE-2019-9516, also known as 0-Length Headers Leak, Cowboy
will now simply reject streams containing 0-length header names.
For CVE-2019-9517, also known as Internal Data Buffering, the
backpressure changes were already pretty good at preventing this
issue, but a new option max_connection_buffer_size was added for
even better control over how much memory we are willing to allocate.
For CVE-2019-9512, also known as Ping Flood; CVE-2019-9515, also
known as Settings Flood; CVE-2019-9518, also known as Empty Frame
Flooding; and similar undocumented scenarios, a frame rate limiting
mechanism was added. By default Cowboy will now allow 1000 frames
every 10 seconds. This can be configured via max_received_frame_rate.
For CVE-2019-9514, also known as Reset Flood, another rate limiting
mechanism was added and can be configured via max_reset_stream_rate.
By default Cowboy will do up to 10 stream resets every 10 seconds.
Finally, nothing was done for CVE-2019-9513, also known as Resource
Loop, because Cowboy does not currently implement the HTTP/2
priority mechanism (in parts because these issues were well known
from the start).
Tests were added for all cases except Internal Data Buffering,
which I'm not sure how to test, and Resource Loop, which is not
currently relevant.
2019-10-02 10:44:45 +02:00
|
|
|
stream_window_data_threshold (16384)::
|
|
|
|
|
|
|
|
Window threshold in bytes below which Cowboy will not attempt
|
|
|
|
to send data, with one exception. When Cowboy has data to send
|
|
|
|
and the window is high enough, Cowboy will always send the data,
|
|
|
|
regardless of this option.
|
|
|
|
|
2019-09-02 14:48:28 +02:00
|
|
|
stream_window_margin_size (65535)::
|
|
|
|
|
2019-09-06 11:50:58 +02:00
|
|
|
Extra amount in bytes to be added to the window size when
|
2019-09-02 14:48:28 +02:00
|
|
|
updating a stream's window. This is used to
|
|
|
|
ensure that there is always some space available in
|
|
|
|
the window.
|
|
|
|
|
|
|
|
stream_window_update_threshold (163840)::
|
|
|
|
|
|
|
|
A stream's window will only get updated when its size
|
2019-09-06 11:50:58 +02:00
|
|
|
becomes lower than this threshold, in bytes. This is to avoid sending
|
2019-09-02 14:48:28 +02:00
|
|
|
too many `WINDOW_UPDATE` frames.
|
|
|
|
|
2016-12-22 15:19:38 +01:00
|
|
|
== Changelog
|
|
|
|
|
Implement dynamic socket buffer sizes
Cowboy will set the socket's buffer size dynamically to
better fit the current workload. When the incoming data
is small, a low buffer size reduces the memory footprint
and improves responsiveness and therefore performance.
When the incoming data is large, such as large HTTP
request bodies, a larger buffer size helps us avoid
doing too many binary appends and related allocations.
Setting a large buffer size for all use cases is
sub-optimal because allocating more than needed
necessarily results in a performance hit (not just
increased memory usage).
By default Cowboy starts with a buffer size of 8192 bytes.
It then doubles or halves the buffer size depending on
the size of the data it receives from the socket. It
stops decreasing at 8192 and increasing at 131072 by
default.
To keep track of the size of the incoming data Cowboy
maintains a moving average. It allows Cowboy to avoid
changing the buffer too often but still react quickly
when necessary. Cowboy will increase the buffer size
when the moving average is above 90% of the current
buffer size, and decrease when the moving average is
below 40% of the current buffer size.
The current buffer size and moving average are
propagated when switching protocols. The dynamic buffer
is implemented in HTTP/1, HTTP/2 and HTTP/1 Websocket.
HTTP/2 Websocket has it disabled because it doesn't
interact directly with the socket; in that case it
is HTTP/2 that has a dynamic buffer.
The dynamic buffer provides a very large performance improvement
in many scenarios, at minimal cost for others. Because it largely
depend on the underlying protocol the improvements are no all equal.
TLS and compression also impact the results.
The improvement when reading a large request body, with the
requests repeated in a fast loop are:
* HTTP: 6x to 20x faster
* HTTPS: 2x to 6x faster
* H2: 4x to 5x faster
* H2C: 20x to 40x faster
I am not sure why H2C's performance was so bad, especially compared
to H2, when using default buffer sizes. Dynamic buffers make H2C a
lot more viable with default settings.
The performance impact on "hello world" type requests is minimal,
it goes from -5% to +5% roughly.
Websocket improvements vary again depending on the protocol, but
also depending on whether compression is enabled:
* HTTP echo: roughly 2x faster
* HTTP send: roughly 4x faster
* H2C echo: roughly 2x faster
* H2C send: 3x to 4x faster
In the echo test we reply back, and Gun doesn't have the dynamic
buffer optimisation, so that probably explains the x2 difference.
With compression however there isn't much improvement. The results
are roughly within -10% to +10% of each other. Zlib compression
seems to be a bottleneck, or at least to modify the performance
profile to such an extent that the size of the buffer does not
matter. This happens to randomly generated binary data as well
so it is probably not caused by the test data.
2025-02-03 15:36:16 +01:00
|
|
|
* *2.13*: The `active_n` default value was changed to `1`.
|
|
|
|
* *2.13*: The `dynamic_buffer` option was added.
|
2024-01-23 15:29:41 +01:00
|
|
|
* *2.11*: Websocket over HTTP/2 is now considered stable.
|
2024-01-23 14:48:15 +01:00
|
|
|
* *2.11*: The `reset_idle_timeout_on_send` option was added.
|
2023-10-31 11:51:02 +01:00
|
|
|
* *2.11*: Add the option `max_cancel_stream_rate` to protect
|
|
|
|
against another flood scenario.
|
2021-05-12 10:24:40 +02:00
|
|
|
* *2.9*: The `goaway_initial_timeout` and `goaway_complete_timeout`
|
|
|
|
options were added.
|
2019-12-04 11:17:34 +01:00
|
|
|
* *2.8*: The `active_n` option was added.
|
2020-04-08 10:27:45 +02:00
|
|
|
* *2.8*: The `linger_timeout` option was added.
|
2020-03-29 13:51:21 +02:00
|
|
|
* *2.8*: The `max_received_frame_rate` default value has
|
|
|
|
been multiplied by 10 as the default was too low.
|
2019-09-02 14:48:28 +02:00
|
|
|
* *2.7*: Add the options `connection_window_margin_size`,
|
|
|
|
`connection_window_update_threshold`,
|
|
|
|
`max_connection_window_size`, `max_stream_window_size`,
|
|
|
|
`stream_window_margin_size` and
|
|
|
|
`stream_window_update_threshold` to configure
|
Fix HTTP/2 CVEs
A number of HTTP/2 CVEs were documented recently:
https://www.kb.cert.org/vuls/id/605641/
This commit, along with a few changes and additions in Cowlib,
fix or improve protection against all of them.
For CVE-2019-9511, also known as Data Dribble, the new option
stream_window_data_threshold can be used to control how little
the DATA frames that Cowboy sends can get.
For CVE-2019-9516, also known as 0-Length Headers Leak, Cowboy
will now simply reject streams containing 0-length header names.
For CVE-2019-9517, also known as Internal Data Buffering, the
backpressure changes were already pretty good at preventing this
issue, but a new option max_connection_buffer_size was added for
even better control over how much memory we are willing to allocate.
For CVE-2019-9512, also known as Ping Flood; CVE-2019-9515, also
known as Settings Flood; CVE-2019-9518, also known as Empty Frame
Flooding; and similar undocumented scenarios, a frame rate limiting
mechanism was added. By default Cowboy will now allow 1000 frames
every 10 seconds. This can be configured via max_received_frame_rate.
For CVE-2019-9514, also known as Reset Flood, another rate limiting
mechanism was added and can be configured via max_reset_stream_rate.
By default Cowboy will do up to 10 stream resets every 10 seconds.
Finally, nothing was done for CVE-2019-9513, also known as Resource
Loop, because Cowboy does not currently implement the HTTP/2
priority mechanism (in parts because these issues were well known
from the start).
Tests were added for all cases except Internal Data Buffering,
which I'm not sure how to test, and Resource Loop, which is not
currently relevant.
2019-10-02 10:44:45 +02:00
|
|
|
behavior on sending WINDOW_UPDATE frames;
|
|
|
|
`max_connection_buffer_size` and
|
2019-09-13 14:20:04 +02:00
|
|
|
`max_stream_buffer_size` to apply backpressure
|
Fix HTTP/2 CVEs
A number of HTTP/2 CVEs were documented recently:
https://www.kb.cert.org/vuls/id/605641/
This commit, along with a few changes and additions in Cowlib,
fix or improve protection against all of them.
For CVE-2019-9511, also known as Data Dribble, the new option
stream_window_data_threshold can be used to control how little
the DATA frames that Cowboy sends can get.
For CVE-2019-9516, also known as 0-Length Headers Leak, Cowboy
will now simply reject streams containing 0-length header names.
For CVE-2019-9517, also known as Internal Data Buffering, the
backpressure changes were already pretty good at preventing this
issue, but a new option max_connection_buffer_size was added for
even better control over how much memory we are willing to allocate.
For CVE-2019-9512, also known as Ping Flood; CVE-2019-9515, also
known as Settings Flood; CVE-2019-9518, also known as Empty Frame
Flooding; and similar undocumented scenarios, a frame rate limiting
mechanism was added. By default Cowboy will now allow 1000 frames
every 10 seconds. This can be configured via max_received_frame_rate.
For CVE-2019-9514, also known as Reset Flood, another rate limiting
mechanism was added and can be configured via max_reset_stream_rate.
By default Cowboy will do up to 10 stream resets every 10 seconds.
Finally, nothing was done for CVE-2019-9513, also known as Resource
Loop, because Cowboy does not currently implement the HTTP/2
priority mechanism (in parts because these issues were well known
from the start).
Tests were added for all cases except Internal Data Buffering,
which I'm not sure how to test, and Resource Loop, which is not
currently relevant.
2019-10-02 10:44:45 +02:00
|
|
|
when sending data too fast;
|
|
|
|
`max_received_frame_rate` and `max_reset_stream_rate`
|
|
|
|
to protect against various flood scenarios; and
|
|
|
|
`stream_window_data_threshold` to control how small
|
|
|
|
the DATA frames that Cowboy sends can get.
|
2019-10-07 11:43:44 +02:00
|
|
|
* *2.7*: The `logger` option was added.
|
2018-11-14 17:12:06 +01:00
|
|
|
* *2.6*: The `proxy_header` and `sendfile` options were added.
|
2018-04-26 22:08:05 +02:00
|
|
|
* *2.4*: Add the options `initial_connection_window_size`,
|
|
|
|
`initial_stream_window_size`, `max_concurrent_streams`,
|
2018-04-27 17:58:11 +02:00
|
|
|
`max_decode_table_size`, `max_encode_table_size`,
|
2018-04-28 10:59:56 +02:00
|
|
|
`max_frame_size_received`, `max_frame_size_sent`
|
|
|
|
and `settings_timeout` to configure HTTP/2 SETTINGS
|
|
|
|
and related behavior.
|
2024-01-23 15:29:41 +01:00
|
|
|
* *2.4*: Add the option `enable_connect_protocol`.
|
2016-12-22 15:19:38 +01:00
|
|
|
* *2.0*: Protocol introduced.
|
|
|
|
|
|
|
|
== See also
|
|
|
|
|
|
|
|
link:man:cowboy(7)[cowboy(7)],
|
|
|
|
link:man:cowboy_http(3)[cowboy_http(3)],
|
|
|
|
link:man:cowboy_websocket(3)[cowboy_websocket(3)]
|