2. cnp3-ebook
3. English
4. Zen

16 ../../exercises/routing-policies.rst:155
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Propose a configuration on R1 that achieves the same objective as the one shown in the figure but also preserves the reachability of all IP addresses inside `AS456` if one of `AS456`'s interdomain links fails. 209/10000 · 209
16 ../../exercises/routing-protocols.rst:245
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The Hello packet contains some parameters such as the `Hello interval` that is set to 1 second. This interval is the delay between the transmission of successive Hello packets. Since the `Router Dead Interval` is set to 3 seconds, the router will consider the link as down if it does not receive Hello packets during a period of 3 seconds. The second packet of the trace is sent by router ``r1``. 396/10000 · 396
16 ../../exercises/tcp-2.rst:88
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The description of TCP packets in packetdrill_ uses a syntax that is very close to the tcpdump_ one. The ``+0`` timing indicates that the line is executed immediately after the previous event. The ``<`` sign indicates that packetdrill_ injects a TCP segment and the ``S`` character indicates that the ``SYN`` flag must be set. Like tcpdump_, packetdrill_ uses sequence numbers that are relative to initial sequence number. The three numbers that follow are the sequence number of the first byte of the payload of the segment (``0``), the sequence number of the last byte of the payload of the segment (``0`` after the semi-column) and the length of the payload (``0`` between brackets) of the ``SYN`` segment. This segment does not contain a valid acknowledgment but advertises a window of 1000 bytes. All ``SYN`` segments must also include the ``MSS`` option. In this case, we set the MSS to 1000 bytes. The next line of the packetdrill_ script verifies the reply sent by the instrumented Linux kernel. 1003/10000 · 1003
16 ../../exercises/trace.rst:96
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — wireshark_ is very good at displaying packets, but it also contains several analysis tools that can be very useful. The first tool is `Follow TCP stream`. It is part of the `Analyze` menu and allows you to reassemble and display all the payload exchanged during a TCP connection. This tool can be useful if you need to analyze for example the commands exchanged during an HTTP or SMTP session. 393/10000 · 393
16 ../../protocols/bgp.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — over a `provider->customer` relationship, the `provider` advertises all the routes that it knows to its `customer`. 115/10000 · 115
16 ../../protocols/congestion.rst:93
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The original TCP congestion control mechanism proposed in [Jacobson1988]_ recommended that each TCP connection should begin by setting :math:`cwnd=MSS`. However, in today's higher bandwidth networks, using such a small initial congestion window severely affects the performance for short TCP connections, such as those used by web servers. In 2002, :rfc:`3390` allowed an initial congestion window of about 4 KBytes, which corresponds to 3 segments in many environments. Recently, researchers from Google proposed to further increase the initial window up to 15 KBytes [DRC+2010]_. The measurements that they collected show that this increase would not significantly increase congestion but would significantly reduce the latency of short HTTP responses. Unsurprisingly, the chosen initial window corresponds to the average size of an HTTP response from a search engine. This proposed modification has been adopted in :rfc:`6928` and TCP implementations support it. 965/10000 · 965
16 ../../protocols/dnssec.rst:171
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `DS` record contains a hash of a public key. It is used by a parent zone to certify the public key used by one of its child zones. 134/10000 · 134
16 ../../protocols/email.rst:101
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The date. This header line starts with `Date:`. :rfc:`5322` precisely defines the format used to encode a date. 111/10000 · 111
16 ../../protocols/ethernet.rst:96
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — delivers frames to their destination with a very high probability of successful delivery 88/10000 · 88
16 ../../protocols/http.rst:77
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second part of the URI is the `authority`. With retrievable URIs, this includes the DNS name or the IP address of the server where the document can be retrieved using the protocol specified via the `scheme`. This name can be preceded by some information about the user (e.g. a user name) who is requesting the information. Earlier definitions of the URI allowed the specification of a user name and a password before the `@` character (:rfc:`1738`), but this is now deprecated as placing a password inside a URI is insecure. The host name can be followed by the semicolon character and a port number. A default port number is defined for some protocols and the port number should only be included in the URI if a non-default port number is used (for other protocols, techniques like service DNS records can used). 817/10000 · 817
16 ../../protocols/http2.rst:79
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To understand the benefits of pipelining, let us consider a simple but illustrative example. A client needs to retrieve 5 web objects that are each 100 bytes. The underlying transport connection has a 1 Gbps bandwidth but a one-way delay of 100 msec. A normal HTTP/1.x client would send the first request, wait 200 msec to receive the answer, then send another request... It would need one entire second to retrieve the five web objects. This is illustrated in the figure below. 478/10000 · 478
16 ../../protocols/ipv6.rst:93
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The IETF decided to pursue the development of IPng based on the SIPP proposal. As IP version `5` was already used by the experimental ST-2 protocol defined in :rfc:`1819`, the successor of IP version 4 is IP version 6. The initial IP version 6 defined in :rfc:`1752` was designed based on the following assumptions : 316/10000 · 316
16 ../../protocols/ethernet.rst:5
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Ethernet 8/10000 · 8
16 ../../protocols/routing.rst:56
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Format of the RIP IPv6 route entries 36/10000 · 36
16 ../../protocols/rpc.rst:50
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In this representation, the first bit (`S`) is the sign (`0` represents positive). The next 11 bits represent the exponent of the number (`E`), in base 2, and the remaining 52 bits are the fractional part of the number (`F`). The floating point number that corresponds to this representation is :math:`(-1)^{S} \times 2^{E-1023} \times 1.F`. XDR also allows encoding complex data types. A first example is the string of bytes. A string of bytes is composed of two parts : a length (encoded as an integer) and a sequence of bytes. For performance reasons, the encoding of a string is aligned to 32 bits boundaries. This implies that some padding bytes may be inserted during the encoding operation is the length of the string is not a multiple of 4. The structure of the string is shown below (source :rfc:`1832`). 813/10000 · 813
16 ../../protocols/ssh.rst:138
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the client generates the random number :math:`a` and sends :math:`A=g^{a} \mod p` to the server 95/10000 · 95
16 ../../protocols/tcp.rst:41
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the port chosen by the client 29/10000 · 29
16 ../../protocols/tls.rst:45
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 119 3/10000 · 3
16 ../../protocols/transport-service.rst:52
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `2001:db8:0:0:8:800:200c:417a` 30/10000 · 30
16 ../../protocols/udp.rst:60
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the privileged port numbers (1 < port < 1024 ) 46/10000 · 46