2. cnp3-ebook
3. English
4. Zen

52 ../../exercises/ipv6.rst:484
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When creating these forwarding tables, try to minimize the number of entries that you install on each router. 109/10000 · 109
52 ../../exercises/routing-protocols.rst:649
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In these exercises, we mainly consider the ``show`` that extracts information from the BGP daemon. We type `show bgp` and press the `tabulation` key to see the available commands in the `show bgp`. 197/10000 · 197
52 ../../exercises/tcp-2.rst:649
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To understand the operation of the TCP congestion control, it is often useful to write time-sequence diagrams for different scenarios. The example below shows the operation of the TCP congestion control scheme in a very simple scenario. The initial congestion window (``cwnd``) is set to 1000 bytes and the receive window (``rwin``) advertised by the receiver (supposed constant for the entire connection) is set to 2000 bytes. The slow-start threshold (``ssthresh``) is set to 64000 bytes. 490/10000 · 490
52 ../../protocols/bgp.rst:162
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `Local Routing Information Base` (`Loc-RIB`) contains all the routes that are considered as acceptable by the router. The `Loc-RIB` may contain several routes, learned from different BGP peers, towards the same destination prefix. 234/10000 · 234
52 ../../protocols/congestion.rst:229
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A wide range of congestion control schemes have been proposed in the scientific literature and several of them have been widely deployed. A detailed comparison of these congestion control schemes is outside the scope of this chapter. A recent survey paper describing many of the implemented TCP congestion control schemes may be found in [TKU2019]_. 349/10000 · 349
52 ../../protocols/email.rst:232
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A 1/10000 · 1
52 ../../protocols/ethernet.rst:199
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The attentive reader may question the need for different `EtherTypes` for IPv4 and IPv6 while the IP header already contains a version field that can be used to distinguish between IPv4 and IPv6 packets. Theoretically, IPv4 and IPv6 could have used the same `EtherType`. Unfortunately, developers of the early IPv6 implementations found that some devices did not check the version field of the IPv4 packets that they received and parsed frames whose `EtherType` was set to `0x0800` as IPv4 packets. Sending IPv6 packets to such devices would have caused disruptions. To avoid this problem, the IETF decided to apply for a distinct `EtherType` value for IPv6. Such a choice is now mandated by :rfc:`6274` (section 3.1), although we can find a funny counter-example in :rfc:`6214`. 779/10000 · 779
52 ../../protocols/http.rst:183
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — By parsing this line, a server cannot determine which `index.html` file is requested. Thanks to the `Host:` header line, the server knows whether the request is for `http://web.example.com/index.html` or `http://www.dummy.net/index.html`. Without the `Host:` header, this is impossible. The `Host:` header line allowed web hosting companies to develop their business by supporting a large number of independent web servers on the same physical server. 451/10000 · 451
52 ../../protocols/ipv6.rst:178
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``/32`` for an Internet Service Provider 40/10000 · 40
52 ../../protocols/ethernet.rst:175
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Category 5 UTP or STP, 100 m maximum 36/10000 · 36
52 ../../protocols/routing.rst:162
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`hash(NextHeader,IP_{src},IP_{dst},Port_{src},Port_{dst}) \pmod{N}` 73/10000 · 73
52 ../../protocols/tcp.rst:179
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Apart from these two paths in the TCP connection establishment FSM, there is a third path that corresponds to the case when both the client and the server send a `SYN` segment to open a TCP connection [#ftcpboth]_. In this case, the client and the server send a `SYN` segment and enter the `SYN Sent` state. Upon reception of the `SYN` segment sent by the other host, they reply by sending a `SYN+ACK` segment and enter the `SYN RCVD` state. The `SYN+ACK` that arrives from the other host allows it to transition to the `Established` state. The figure below illustrates such a simultaneous establishment of a TCP connection. 624/10000 · 624
52 ../../protocols/tls.rst:268
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Perfect Forward Secrecy (PFS) is an important property for key exchange protocols. A protocol provides PFS if its design guarantees that the keys used for former sessions will not be compromised even if the private key of the server is compromised. This is a very important property. ``DHE_RSA`` provides Perfect Forward Secrecy, but the ``RSA`` key exchange does not provide this property. In practice, ``DHE_RSA`` is costly from a computational viewpoint. Recent implementations of TLS thus prefer ``ECDHE_RSA`` or ``ECDHE_ECDSA`` when Perfect Forward Secrecy is required. 575/10000 · 575
52 ../../protocols/wifi.rst:146
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Two types of encapsulation schemes were defined to support IP in Ethernet networks : the original encapsulation scheme, built above the Ethernet DIX format is defined in :rfc:`894` and a second encapsulation :rfc:`1042` scheme, built above the LLC/SNAP protocol [IEEE802.2]_. In 802.11 networks, the situation is simpler and only the :rfc:`1042` encapsulation is used. In practice, this encapsulation adds 6 bytes to the 802.11 header. The first four bytes correspond to the LLC/SNAP header. They are followed by the two bytes Ethernet Type field (`0x800` for IP and `0x806` for ARP). The figure below shows an IP packet encapsulated in an 802.11 frame. 653/10000 · 653
52 ../../exercises/sockets.rst:369
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — to wrap the ``create_and_send_message`` in a ``client`` executable that can parse user arguments (the ``getopt(3)`` function might help) and appropriately call the wrapped function; 181/10000 · 181
52 ../../principles/network.rst:333
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In networks that rely on source routing, hosts use control packets to automatically discover the best path(s). In addition to the source and destination addresses, `control packets` contain a list that records the intermediate nodes. This list is often called the `record route` because it allows recording the route followed by a given packet. When a node receives such a `control packet`, it first checks whether its address is included in the record route. If yes, the packet has already been forwarded by this node and it is silently discarded. Otherwise, it adds its own address to the `record route` and forwards the packet to all its interfaces, except the interface over which the packet has been received. Thanks to this, the `control packet` can explore all paths between a source and a given destination. 815/10000 · 815
53 ../../exercises/network.rst:373
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — B 1/10000 · 1
53 ../../glossary.rst:252
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The HyperText Markup Language specifies the structure and the syntax of the documents that are exchanged on the world wide web. HTML is maintained by the `HTML working group <https://www.w3.org/html/wg/>`_ of the :term:`W3C` 224/10000 · 224
53 ../../principles/network.rst:335
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — For example, consider again the network topology above. `A` sends a control packet towards `B`. The initial `record route` is empty. When `R1` receives the packet, it adds its own address to the `record route` and forwards a copy to `R2` and another to `R3`. `R2` receives the packet, adds itself to the `record route` and forwards it to `R3`. `R3` receives two copies of the packet. The first contains the `[R1,R2]` `record route` and the second `[R1]`. In the end, `B` will receive two control packets containing `[R1,R2,R3,R4]` and `[R1,R3,R4]` as `record routes`. `B` can keep these two paths or select the best one and discard the second. A popular heuristic is to select the `record route` of the first received packet as being the best one since this likely corresponds to the shortest delay path. 805/10000 · 805
53 ../../principles/reliability.rst:229 • ../../principles/reliability.rst:268
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Transmitted frame 17/10000 · 17