2. cnp3-ebook
3. English
4. Zen

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
53 ../../principles/transport.rst:181
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An `unreliable connectionless` service may suffer from various types of problems compared to a `reliable connectionless service`. First of all, an `unreliable connectionless service` does not guarantee the delivery of all SDUs. This can be expressed graphically by using the time-sequence diagram below. 303/10000 · 303
53 ../../principles/security.rst:545
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — To authenticate herself, Alice sends her user identifier to Bob. Bob replies with a random number as a challenge to verify that Alice knows the shared secret (i.e. her password). Alice replies with the result of the computation of a hash function (e.g. SHA-1) over a string that is the concatenation between the random number chosen by Bob and Alice's password. The random number chosen by Bob is often called a `nonce` since this is a number that should only be used once. Bob performs the same computation locally and can check the message returned by Alice. This type of authentication scheme has been used in various protocols. It prevents replay attacks. If Eve captures the messages exchanged by Alice and Bob, she cannot recover Alice's password from the messages exchanged since hash functions are non-invertible. Furthermore, she cannot replay the hashed value since Bob will always send a different nonce. 915/10000 · 915
53 ../../exercises/ipv6.rst:486
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — When a network is designed, an important element of the design is the IP address allocation plan. A good allocation plan can provide flexibility and help to reduce the size of the forwarding tables. 198/10000 · 198
53 ../../exercises/routing-protocols.rst:663
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A useful command to start is `show bgp summary` which provides a summary of the state of the BGP daemon. 104/10000 · 104
53 ../../exercises/tcp-2.rst:684
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Can you explain why the sender only sends one segment first and then two successive segments (the delay between the two segments on the figure is due to graphical reasons) ? 173/10000 · 173