2. cnp3-ebook
3. English
4. Zen

37 ../../principles/transport.rst:97
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A simple BNF specification 26/10000 · 26
37 ../../principles/security.rst:380
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The public key is used to encrypt a message so that it can only be read by the intended recipient. For example, let us consider two users : Alice and Bob. Alice (resp. Bob) uses the keys :math:`A_{priv}` and :math:`A_{pub}` (resp. :math:`B_{priv}` and :math:`B_{pub}`). To send a secure message `M` to Alice, Bob computes :math:`CM=E_p(A_{pub},M)` and Alice can decrypt it by using :math:`D_p(A_{priv},CM)=D_p(A_{priv},E_p(A_{pub},M))=M`. 438/10000 · 438
37 ../../exercises/ipv6.rst:368
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — on router ``R3`` 16/10000 · 16
37 ../../exercises/routing-protocols.rst:437
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``AS2`` is assigned ``2001:cafe:2::/48`` 40/10000 · 40
37 ../../exercises/tcp-2.rst:364
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — More complex scenarios can be written. The script below demonstrates how the TCP stack behaves when three segments are lost. This script is available from :download:`/exercises/packetdrill_scripts/frr-rto2.pkt`. 211/10000 · 211
37 ../../protocols/bgp.rst:124
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `OPEN` : this message is sent as soon as the TCP connection between the two routers has been established. It initializes the BGP session and allows the negotiation of some options. Details about this message may be found in :rfc:`4271`. 236/10000 · 236
37 ../../protocols/congestion.rst:199
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As the losses are equally spaced, the congestion window always starts at some value (:math:`\frac{W}{2}`), and is incremented by one MSS every round-trip-time until it reaches twice this value (`W`). At this point, a segment is retransmitted and the cycle starts again. If the congestion window is measured in MSS-sized segments, a cycle lasts :math:`\frac{W}{2}` round-trip-times. The bandwidth of the TCP connection is the number of bytes that have been transmitted during a given period of time. During a cycle, the number of segments that are sent on the TCP connection is equal to the area of the yellow trapeze in the figure. Its area is thus : 650/10000 · 650
37 ../../protocols/email.rst:183
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To support these two types of MIME messages, the recipient of a message must be able to extract the different parts from the message. In :rfc:`822`, an empty line was used to separate the header lines from the body. Using an empty line to separate the different parts of an email body would be difficult as the body of email messages often contains one or more empty lines. Another possible option would be to define a special line, e.g. `*-LAST_LINE-*` to mark the boundary between two parts of a MIME message. Unfortunately, this is not possible as some emails may contain this string in their body (e.g. emails sent to students to explain the format of MIME messages). To solve this problem, the `Content-Type:` header line contains a second parameter that specifies the string that has been used by the sender of the MIME message to delineate the different parts. In practice, this string is often chosen randomly by the mail client. 937/10000 · 937
37 ../../protocols/ethernet.rst:175
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Category 5 UTP or STP, 100 m maximum 36/10000 · 36
37 ../../protocols/http.rst:156
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — HTTP clients and servers can include different HTTP headers in HTTP requests and responses. Each HTTP header is encoded as a single ASCII-line terminated by `CR` and `LF`. Several of these headers are briefly described below. A detailed discussion of the standard headers may be found in :rfc:`1945`. The MIME headers can appear in both HTTP requests and HTTP responses. 370/10000 · 370
37 ../../protocols/http2.rst:251
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The `HTTP2-Settings` line contains the HTTP/2.0 settings frame that the client would server over an HTTP/2.0 session encoded in Base64. The server replies with a response that indicates that it has accepted to upgrade the connection to HTTP/2.0. A sample response is shown below. 279/10000 · 279
37 ../../protocols/ipv6.rst:127
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``2001:0db8::cd30:0:0:0:0`` / ``60`` 36/10000 · 36
37 ../../protocols/ethernet.rst:149
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Computers can directly be attached to Ethernet hubs. Ethernet hubs themselves can be attached to other Ethernet hubs to build a larger network. However, some important guidelines must be followed when building a complex network with hubs. First, the network topology must be a tree. As hubs are relays in the physical layer, adding a link between `Hub2` and `Hub3` in the network below would create an electrical shortcut that would completely disrupt the network. This implies that there cannot be any redundancy in a hub-based network. A failure of a hub or of a link between two hubs would partition the network into two isolated networks. Second, as hubs are relays in the physical layer, collisions can happen and must be handled by CSMA/CD as in a 10Base5 network. This implies that the maximum delay between any pair of devices in the network cannot be longer than the 51.2 microseconds `slot time`. If the delay is longer, collisions between short frames may not be correctly detected. This constraint limits the geographical spread of 10BaseT networks containing hubs. 1077/10000 · 1077
37 ../../protocols/routing.rst:110
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second OSPF particularity that is worth discussing is the support of Local Area Networks (LAN). As shown in the example below, several routers may be attached to the same LAN. 179/10000 · 179
37 ../../protocols/rpc.rst:124
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Coming back to our example with the call for the `sum` procedure, it would return the following JSON structure. 111/10000 · 111
37 ../../protocols/ssh.rst:290
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``ssh`` protocol includes other features that are beyond the scope of this book. Additional details may be found in [BS2005]_. 130/10000 · 130
37 ../../protocols/tcp.rst:119
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `sequence number` set to the current value of the 32 bits counter of the server host's TCP entity 101/10000 · 101
37 ../../protocols/tls.rst:155
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `Cipher suites` : this ordered list contains the set of cryptographic algorithms that are supported by the client, with the most preferred one listed first. In contrast with ``ssh`` that allows negotiating independent algorithms for encryption, key exchange and authentication, TLS relies on suites that combine these algorithms together. Many cryptographic suites have been defined for TLS. Various recommendations have been published on the security of some of these suites :rfc:`7525`. 488/10000 · 488
37 ../../protocols/wifi.rst:56
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An 802.11 access point is a relay that operates in the datalink layer like switches. The figure below represents the layers of the reference model that are involved when a WiFi host communicates with a host attached to an Ethernet network through an access point. 263/10000 · 263
37 ../../bibliography.rst:54
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — CWE-444, `Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') <https://cwe.mitre.org/data/definitions/444.html>`_, https://cwe.mitre.org/data/definitions/444.html 182/10000 · 182