User Guide 19.11 documentation
Time between the first client packet of the query (e.g.: a POST) and the last server packet of the corresponding answer. In a simple two-packet conversation between a client and a server, this would be the time between the two packets and as such, would be equal to the hit response time. More complex pages make use of ressources that may not be directly embedded into the page itself. The sniffer tracks the referrer that lets it determine which hits were provoked by the loading of the page. To better qualify a hit, it may be categorised in two kinds according to its MIME type:
- embeddable: CSS, JavaScript, images, fonts, ...
- stand-alone: HTML, PDF, PostScript
There are three settings in SkyLIGHT PVX that may be used to tweak a page’s load time with regards to the referred hits:
- the HTTP page analysis flag: enables the attachment of hits to their parent pages
- the page construction maximum delay: delay after which the hit, if its MIME type is not considered as an embeddable one, won’t be attached to its parent page and, as such, won’t contribute to its statistics (stand-alone hits are never attached to a parent page, only referred)
- the page contribution maximum delay: delay after which attached pages don’t contribute to their parent’s statistics
The statistics of a page include the page load time, volume, number of errors, ...
Expression used to match against strings.
Every pattern is anchored, meaning it must match exactly the provided input string, from the beginning to its end.
For example, the pattern bar will only match the string bar.
However it will not match the following string due to being implicitly
anchored:
foo barbar bazfoo bar bazTo avoid specifying multiple similar patterns, the use of a wildcard
is allowed, represented by the character *.
In the above example, if the desired behavior was to match everything
starting with foo and ending with bar, the pattern would
have to be written as foo*baz. It would match everything from this
non-exhaustive list (the inclusive range of the wildcard being specified
by [ and ]):
foo[]baz because the wildcard doesn’t imply the required presence of somethingfoo[ ]bazfoo[ bar ]bazfoo[ foo bar bar baz ]bazOf course, the wildcard may be used at the beginning or the end of
a pattern, so it’s possible to ignore the beginning or the end of
a string, respectively.
The pattern *baz would match everything from this
non-exhaustive list (the inclusive range of the wildcard being specified
by [ and ]):
[bar ]baz[foo bar ]baz[]baz because the wildcard doesn’t imply the required presence of somethingIt is possible to use multiple wildcards but care should be taken to ensure the set of matched string isn’t too large.
The * character can not be escaped so it’s not possible to
match a literal * in the input string.
Fortunately, it’s possible to put the pattern in an enhanced mode
by prefixing it with the special character ~.
Everything following the ~ will be used as a
Perl regular expressions,
without any anchoring.
With Perl regular expressions, it’s possible to escape the *
character, match optional patterns, match some number of
repetitions, etc. For example ~\d{3}$ will match three digits
at the end of string.
Ethernet/IPv4/TCP/HTTP protocol
stack, whereas in the case of an IPv6 in a v4 tunnel, the
protocol stack would be Ethernet/IPv4/IPv6/TCP/HTTP. Not
only does this notation make all sort of tunnels visible, it
also makes apparent some protocols that are detected by the
sniffer despite running on non-standard ports.Means of recognizing an Application based on a Pattern from the TLS payload.
The Common Name or CN pattern will be matched against the Common Name field from the certificate presented by either the client or the server (if present).
The Server Name Indication or SNI will be matched against the Server Name extension provided during the handshake, allowing a fine-grained matching of client requests based on the hostname used by the client to address a server.
Both information have their own input in the rules
definition. Usually you should use only one of them. If you
use both to define an application, then the flow must validate
both CN and SNI patterns. If you want to create an
application that match one pattern OR an other one, then
create one rule per pattern.
Means of recognizing an Application based on a Pattern in the payload. Currently, these patterns are checked against HTTP URLs. The pattern syntax allows for a hostname and, optionally, a path separated by ‘/’ (for example, ‘www.example.com/my/path’ or ‘www.example.com’).
The pattern *.example.org* will match everything under
example.org with or without URLs because it is equivalent to
~^.*\.example\.org.*$.
The pattern *example.org* will match everything having a domain
name of example.org because it is equivalent to
~^.*example\.org.*$.
example.org*will match theexample.org/index.htmlURL but NOT URLs ofwww.example.org, being anchored and not allowing prefixes (equivalent to~^example\.org.*$
Keep in mind that for HTTP URLs, ports different than 80 (the default HTTP port) are always appended to the host because the scheme is never provided to match against:
*example.org:443/*will only match URLs served on port 443 for theexample.orgdomain
The patterns should always be applied restrictively: the
*example.org* pattern may match the example.organization.net
domain which may not be intended.