Glossary ======== .. glossary:: :sorted: Zone A zone corresponds to the location of a sender or emitter. See :ref:`zone_tree` for more details. Fallback By convention, a zone which collects a larger set of addresses that includes addresses of other, more specific zones. See :ref:`fallback` for more details. Application Group of logical or business-related flow to emphasize valuable perspective; an Application is identified with a name and a color, and defined by a set of Signatures or a set of Port Ranges (at least one non-empty set of either), a set of client and server zones. A conversation is attributed to an application with the following rule: (PORT_RANGE1 OR .... OR PORT_RANGEn OR SIGNATURE1 OR ... OR SIGNATUREn) AND ((SERVER_ZONE1 OR ... OR SERVER_ZONEn) AND (CLIENT_ZONE1 OR ... OR CLIENT_ZONEn) ); in case a conversation matches a previous rule of several applications, the priority will be given to the application whose definition is the most precise, i.e., the thinnest port range, signature or server/client zone. Application NC NC stands for Non-Classified. An NC Application is a special application that will match conversations that match no other configured application. Application Port Range Port or range of ports. It applies to both 'TCP' and 'UDP' when not used in conjunction with an IP protocol. Web Application Pattern Means of recognizing an Application based on a :term:`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'). .. container:: example 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 the ``example.org/index.html`` URL but **NOT** URLs of ``www.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 the ``example.org`` domain The patterns should always be applied restrictively: the ``*example.org*`` pattern may match the ``example.organization.net`` domain which may not be intended. Pattern 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 bar`` - ``bar baz`` - ``foo bar baz`` To 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 something - ``foo[ ]baz`` - ``foo[ bar ]baz`` - ``foo[ foo bar bar baz ]baz`` Of 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 something It 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. TLS Application Pattern Means of recognizing an Application based on a :term:`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. Subnet Set of network addresses that have a common declared IP address routing prefix. A Subnet is defined by an IP address and a netmask. Conversation Regroups network exchanges between two network addresses for one application during the observation period. A conversation is defined as a group of flows between a client and a server over an observation period. Flow Regroups data exchanges between two network addresses for one application during the aggregation period. A flow is a group of communications between two network addresses for one application during the aggregation period. Notice that the VLAN tag, if present, as well as the device identifier, are considered components of the network address. Device Identifier Identifies the physical network adapter that received the network traffic associated to a conversation. Observation period In all reports, defines the observation time window. Observation Period is based on a starting time and an ending time provided by the user. These user-defined boundaries will automatically be moved to the closest previous aggregation boundary for the starting time and to the next aggregation boundary for the ending time. This modified time interval is the actual observation period. Aggregation period Time period over which all data are aggregated into flows (for each set of client, server and application). The Aggregation Period is defined for an aggregation level as time interval over which all flows are aggregated in the database on their IP src/dst, Zone src/dst and Application. Individual flows within the aggregated data cannot be viewed separately; the Aggregation Period defines the data resolution for an aggregation level. Retransmission Packets being resent, when they have either been lost or damaged. Packet Retransmission is identified, thanks to their TCP sequence and acknowledgment numbers and checksum values. Only packets with a non-null payload are checked. Retransmission Delay (RD) Delay between a packet and its next retransmission. Total Retransmission Delay (TRD) Delay between a packet and its last retransmission. Retransmission Rate (RR) RR is defined as the ratio of retransmitted packets to the total number of packets with a non-zero payload in a conversation. Retransmission Duplicate ACK Duplicate acknowledgment packet with a null payload. Duplicate ACKs are TCP ACK packets that are identified, thanks to their same acknowledgment value and their empty payload. Server Response Time (SRT) Time between a query and an answer at the applicative level. Server Response Time is the elapsed time between a client packet with a non-null payload and the corresponding server response (a packet with a non-null payload and its acknowledgment number corresponds to the first packet). Round Trip Time (RTT) Time between an applicative query and a response at the network level. RTT is defined as the time between any packet and its corresponding TCP acknowledgment. Packets with RST or FIN flags are excluded. Jitter Packet delay variation. It is defined as the variance of RTT (average difference between RTT measures and the average RTT). This equation is used: Sqrt( (Average(RTT1**2, ... , RTTn**2) - Average(RTT1, ..., RTTn)**2). Data Transfer Time (DTT) Time spent by the client or the server to send data. DTT server is defined as the time between the first data packet (with ACK flag and a non-null payload) from the server and the last packet considered as part of the same answer. DTT client is the symmetric metric in opposite direction. Packets are considered part of the same answer if the packets share the same acknowledgment number: FIN, RST from server or client. A timeout will cancel a DTT. Note that if the answer is small enough to be contained in only one packet, the DTT will be '0'. End User Response Time (EURT) Total time the user waited to get an applicative answer. The EURT stands for End User Response Time. EURT is defined as the sum of the RTT (client + server), the SRT and the DTT (client + server). A timeout will cancel the computation of EURT. Session An established communication channel between two devices using TCP. It is defined as a TCP communication between 2 devices starting with a successful Handshake, and ending in a Timeout, or a Packet with the RST flag from any of the devices, or a Packet with FIN from any of the devices that is acknowledged by a FIN/ACK followed by a FIN from the other device. (No FIN/ACK is necessary to conclude that the connection is closed.) Delta sessions Number of sessions established minus those closed. Delta Session is a metric defined as the difference of the number of opened sessions to the number of closed ones. A negative value means that more sessions were closed than opened. TCP Handshake 3-way negotiation that is part of establishing a TCP session. A TCP Handshake is defined between 2 devices as an exchange of 3 TCP packets flagged SYN, SYN/ACK, and ACK. Connection Time (CT) Time taken by the exchange of the 3-way TCP handshake. CT is defined as the duration of the three-way handshake (SYN, SYN/ACK, ACK) of a TCP session. Timeout Session end by inactivity. Session Timeout will be reported after 120 seconds of complete inactivity (i.e., no packets seen). Initial Sequence Number The sequence number used in the SYN packet of a TCP connection. Maximum Transfer Unit (MTU) The MTU that's reported by the probe is the size of the biggest Ethernet frame that was seen in this conversation. It is, thus, distinct from the physical MTU, although for a large number of packets, the observed MTU is expected to converge towards the physical MTU. Operating System (OS) Different operating systems implement the core network protocols differently. The probe attempts to guess the operating system that's used at both ends of a conversation based on these differences. This information, even if inaccurate and unreliable, can still be used to help identify a host or a network trouble. Media Access Control (MAC) address Identifier assigned to each network adapter and used for addressing in the lowest physical layer. In practice, only Ethernet devices are supported so these will always be Ethernet addresses. DiffServ Code Point (DSCP) 6-bit value taken from the TOS field of the IP header, used in some networks to govern the QoS of each packet. No standard meaning is being assigned to the given values; only the raw numeric value is reported. For a given conversation, the probe only keeps the biggest DSCP encountered. In practice, a whole conversation should be governed by a single DSCP value. HTTP page The set of HTTP transactions that was required to build a whole HTML page, including its images, scripts, stylesheets and other related resources. This might also include the resources used to update the page dynamically (through AJAX, that is, Javascript, or from other means). HTTP hit Designates a single HTTP transaction used to build an HTTP page. This is typically an image, a script, a stylesheet. The transaction to obtain the HTML is itself considered a hit. Thus, a page that contains 2 images and 1 stylesheet, all stored in different URLs, is made of 4 hits. Capture Remote probe that listens and analyzes the network traffic to produce statistics that the datastore will fetch and insert into the central database. Datastore Central database and Web GUI of |Product|. The datastore can also host a local capture, and usually collects statistics from remote captures. Protocol Stack The various protocols identified in a flow. For instance, an HTTP conversation that's carried in TCP over IP over Ethernet may be reported with the ``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. Hit Response Time (Hit RT) Time between the first client packet of the query (e.g.: a GET) and the first server packet of the corresponding response. Note that only the HTTP packets are used in determining the result (for example, TCP ACK packets that come in-between will have no impact on the hit response time). Page Load Time (Page LT) 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 |Product| 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, ...