2. cnp3-ebook
3. English
4. Zen

13 ../../protocols/dnssec.rst:158
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — DNSSEC defines four new types of DNS records that are used together to authenticate the information distributed by the DNS. 123/10000 · 123
13 ../../protocols/email.rst:63
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Email messages are entirely composed of lines of ASCII characters. Each line can contain up to 998 characters and is terminated by the `CR` and `LF` control characters :rfc:`5322`. The lines that compose the `header` appear before the message `body`. An empty line, containing only the `CR` and `LF` characters, marks the end of the `header`. This is illustrated in the figure below. 383/10000 · 383
13 ../../protocols/ethernet.rst:89
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Ethernet 802.3 frame format 27/10000 · 27
13 ../../protocols/http.rst:55
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Open standards play a key role in the success of the `world wide web` as we know it today. Without open standards, the world wide web would have never reached its current size. In addition to open standards, another important factor for the success of the web was the availability of open and efficient implementations of these standards. When CERN started to work on the `web`, their objective was to build a running system that could be used by physicists. They developed open-source implementations of the `first web servers <http://www.w3.org/Daemon/>`_ and `web clients <http://www.w3.org/Library/Activity.html>`_. These open-source implementations were powerful and could be used as is, by institutions willing to share information. They were also extended by other developers who contributed to new features. For example, the NCSA_ added support for images in their `Mosaic browser <http://en.wikipedia.org/wiki/Mosaic_(web_browser)>`_ that was eventually used to create `Netscape Communications <http://en.wikipedia.org/wiki/Netscape>`_ and the first commercial browsers and servers. 1091/10000 · 1091
13 ../../protocols/http2.rst:70
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A closer look at the average web page shows that it contains, on average, 27 KBytes of HTML, 120 KBytes of fonts, 60 KBytes of CSS information, almost 1 MBytes of images and more than 400 KBytes of javascript. Each of these web page requires about 70 different HTTP requests. In other words, a browser needs to send on average 70 requests to retrieve a complete web page. 372/10000 · 372
13 ../../protocols/ipv6.rst:89
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — TUBA proposed in :rfc:`1347` and :rfc:`1561` 44/10000 · 44
13 ../../protocols/ppp.rst:34 • ../../protocols/ethernet.rst:192 • ../../protocols/ethernet.rst:308 • ../../protocols/wifi.rst:157
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
13 ../../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
13 ../../protocols/routing.rst:40
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — RIP routers periodically exchange RIP messages. The format of these messages is shown below. A RIP message is sent inside a UDP segment whose destination port is set to `521`. A RIP message contains several fields. The `command` field indicates whether the RIP message is a request or a response. When a router boots, its routing table is empty and it cannot forward any packet. To speedup the discovery of the network, it can send a request message to the RIP IPv6 multicast address, ``FF02::9``. All RIP routers listen to this multicast address and any router attached to the subnet will reply by sending its own routing table as a sequence of RIP messages. In steady state, routers multicast one of more RIP response messages every 30 seconds. These messages contain the distance vectors that summarize the router's routing table. The current version of RIP is version 2 defined in :rfc:`2453` for IPv4 and :rfc:`2080` for IPv6. 931/10000 · 931
13 ../../protocols/rpc.rst:34
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The eXternal Data Representation (XDR) Standard, defined in :rfc:`1832` is an early specification that describes how information exchanged during Remote Procedure Calls should be encoded before being transmitted through a network. Since the transport service enables transfering a block of bytes (with the connectionless service) or a stream of bytes (by using the connection-oriented service), XDR maps each datatype onto a sequence of bytes. The caller encodes each data in the appropriate sequence and the callee decodes the received information. Here are a few examples extracted from :rfc:`1832` to illustrate how this encoding/decoding can be performed. 659/10000 · 659
13 ../../protocols/ssh.rst:89
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The IANA_ maintains a `list of the cryptographic algorithms <http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16>`_ that can be used by ``ssh`` implementations. For each type of algorithm, the client provides an ordered list of the algorithms that it supports and agrees to use. The server compares the received list with its own list. The outcome of the negotiation is a set of four algorithms [#fnull]_ that will be combined for this session. 478/10000 · 478
13 ../../protocols/tcp.rst:37
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `source and destination ports`. The source and destination ports play an important role in TCP, as they allow the identification of the connection to which a TCP segment belongs. When a client opens a TCP connection, it typically selects an ephemeral TCP port number as its source port and contacts the server by using the server's port number. All the segments that are sent by the client on this connection have the same source and destination ports. The server sends segments that contain as source (resp. destination) port, the destination (resp. source) port of the segments sent by the client (see figure :ref:`fig-tcpports`). A TCP connection is always identified by four pieces of information : 706/10000 · 706
13 ../../protocols/tls.rst:44
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 143 3/10000 · 3
13 ../../protocols/transport-service.rst:47
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Textual representation of IPv6 addresses 40/10000 · 40
13 ../../protocols/udp.rst:55
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a 16 bits length field 22/10000 · 22
13 ../../protocols/wifi.rst:22
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 0.9 Mbps 8/10000 · 8
13 ../../protocols/dns.rst:49
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In a `Resource Record` (`RR`), the `Name` indicates the name of the node to which this resource record pertains. The two-)bytes `Type` field indicates the type of resource record. The `Class` field was used to support the utilization of the DNS in other environments than the Internet. The `IN` `Class` refers to Internet names. 328/10000 · 328
13 ../../bibliography.rst:19
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J. and Jahanian, F., `Internet inter-domain traffic <http://doi.acm.org/10.1145/1851182.1851194>`_. In Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM (SIGCOMM '10). ACM, New York, NY, USA, 75-86. 265/10000 · 265
13 ../../principles/sharing.rst:117
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Sharing resources is important to ensure that the network efficiently serves its user. In practice, there are many ways to share resources. Some resource sharing schemes consider that some users are more important than others and should obtain more resources. For example, on the roads, police cars and ambulances have priority. In some cities, traffic lanes are reserved for buses to promote public services, ... In computer networks, the same problem arise. Given that resources are limited, the network needs to enable users to efficiently share them. Before designing an efficient resource sharing scheme, one needs to first formalize its objectives. In computer networks, the most popular objective for resource sharing schemes is that they must be `fair`. In a simple situation, for example two hosts using a shared 2 Mbps link, the sharing scheme should allocate the same bandwidth to each user, in this case 1 Mbps. However, in a large networks, simply dividing the available resources by the number of users is not sufficient. Consider the network shown in the figure below where `A1` sends data to `A2`, `B1` to `B2`, ... In this network, how should we divide the bandwidth among the different flows ? A first approach would be to allocate the same bandwidth to each flow. In this case, each flow would obtain 5 Mbps and the link between `R2` and `R3` would not be fully loaded. Another approach would be to allocate 10 Mbps to `A1-A2`, 20 Mbps to `C1-C2` and nothing to `B1-B2`. This is clearly unfair. 1513/10000 · 1513
14 ../../exercises/ex-sharing.rst:290
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Consider again a network that uses CSMA/CD. This time, the bandwidth is set to 1 Gbps and the cable has a length of two kilometers. When a collision occurs, consider that the hosts B and C retransmit immediately while host A waits for the next slot. 249/10000 · 249