2. cnp3-ebook
3. English
4. Zen

15 ../../protocols/http.rst:75
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first component of a URI is its `scheme`. A `scheme` can be seen as a selector, indicating the meaning of the fields after it. In practice, the scheme often identifies the application-layer protocol that must be used by the client to retrieve the document, but it is not always the case. Some schemes do not imply a protocol at all and some do not indicate a retrievable document [#furiretrieve]_. The most frequent schemes are `http` and `https`. We focus on `http` in this section. A URI scheme can be defined for almost any application layer protocol [#furilist]_. The characters `:` and `//` follow the `scheme` of any URI. 631/10000 · 631
15 ../../protocols/ipv6.rst:91
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — SIPP proposed in :rfc:`1710` 28/10000 · 28
15 ../../protocols/ppp.rst:37
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The IANA maintains the registry of all assigned PPP protocol fields at : http://www.iana.org/assignments/ppp-numbers 116/10000 · 116
15 ../../protocols/routing.rst:50
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Each RIP message contains a set of route entries. Each route entry is encoded as a 20 bytes field whose format is shown below. RIP was initially designed to be suitable for different network layer protocols. Some implementations of RIP were used in XNS or IPX networks :rfc:`2453`. The format of the route entries used by :rfc:`2080` is shown below. `Prefix length` is the length of the subnet identifier in bits and the `metric` is encoded as one byte. The maximum metric supported by RIP is `15`. 498/10000 · 498
15 ../../protocols/rpc.rst:43
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — XDR also supports 64 bits integers and booleans. The booleans are mapped onto integers (`0` for `false` and `1` for `true`). For the floating point numbers, the encoding defined in the IEEE standard is used. 207/10000 · 207
15 ../../protocols/ssh.rst:131
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Once the cryptographic algorithms have been negotiated, the key exchange algorithm is used to negotiate a secret key that will be shared by the client and the server. These key exchange algorithms include some variations over the basic algorithms. As an example, let us analyze how the Diffie Hellman key exchange algorithm is used within the ``ssh`` protocol. In this case, each host has both a private and a public key. 421/10000 · 421
15 ../../protocols/tcp.rst:40
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the address of the server 25/10000 · 25
15 ../../protocols/tls.rst:45
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — NNTP 4/10000 · 4
15 ../../protocols/transport-service.rst:51
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `abcd:ef01:2345:6789:abcd:ef01:2345:6789` 41/10000 · 41
15 ../../protocols/udp.rst:58
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As the port numbers are encoded as a 16 bits field, there can be up to only 65535 different server processes that are bound to a different UDP port at the same time on a given server. In practice, this limit is never reached. However, it is worth noticing that most implementations divide the range of allowed UDP port numbers into three different ranges : 356/10000 · 356
15 ../../protocols/wifi.rst:22
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 20/100 6/10000 · 6
15 ../../principles/naming.rst:81
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The possibility of using all Unicode characters to create domain names opened a new form of attack called the `homograph attack <https://en.wikipedia.org/wiki/IDN_homograph_attack>`_. This attack occurs when two character strings or domain names are visually similar but do not correspond to the same server. A simple example is https://G00GLE.COM and https://GOOGLE.COM. These two URLs are visually close but they correspond to different names (the first one does not point to a valid server [#fg00gle]_). With other Unicode characters, it is possible to construct domain names are visually equivalent to existing ones. See [Zhe2017]_ for additional details on this attack. 674/10000 · 674
15 ../../protocols/http2.rst:76
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — One of the limitations of HTTP from a performance viewpoint is that the requests that are sent by a browser must be sequential. Typically, a browser requests the HTML page. Once the page has been retrieved, the browser parses it to identify all the objects that it references and requests them one after each other. The web page can only be displayed to the user once all the required web objects have been retrieved. This implies that the browser must wait until the reception of each response before sending the next request. Another possibility is to allow the browser to send multiple requests without waiting for their corresponding responses. This approach is called `pipelining` in :rfc:`7230`. 701/10000 · 701
16 ../../exercises/ex-sharing.rst:343
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Fairness and congestion control 31/10000 · 31
16 ../../exercises/sockets.rst:137
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Receiving data from a peer using a socket 41/10000 · 41
16 ../../principles/naming.rst:84
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This hierarchical naming scheme is a key component of the Domain Name System (DNS). The DNS is a distributed database that contains mappings between fully qualified domain names and addresses. The DNS uses the client-server model. The clients are hosts or applications that need to retrieve the mapping for a given name. Each :term:`nameserver` stores part of the distributed database and answers the queries sent by clients. There is at least one :term:`nameserver` that is responsible for each domain. In the figure below, domains are represented by circles and there are three hosts inside domain `dom` (`h1`, `h2` and `h3`) and three hosts inside domain `a.sdom1.dom`. As shown in the figure below, a sub-domain may contain both host names and sub-domains. 760/10000 · 760
16 ../../principles/network.rst:93
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `virtual circuits` 18/10000 · 18
16 ../../principles/referencemodels.rst:100
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The `Datalink layer` allows directly connected hosts to exchange information, but it is often necessary to exchange information between hosts that are not attached to the same physical medium. This is the task of the `network layer`. The `network layer` is built above the `datalink layer`. Network layer entities exchange `packets`. A `packet` is a finite sequence of bytes that is transported by the datalink layer inside one or more frames. A packet usually contains information about its origin and its destination, and usually passes through several intermediate devices called routers on its way from its origin to its destination. 637/10000 · 637
16 ../../principles/reliability.rst:52
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — :math:`10^6` 12/10000 · 12
16 ../../exercises/network.rst:112
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Assume that the routers located in `Denver` and `Kansas City` need to exchange lots of packets. Can you configure the link metrics such that the link between these two routers does not carry any packet sent by another router in the network ? 241/10000 · 241