2. cnp3-ebook
3. English
4. Zen

13 ../../exercises/routing-policies.rst:143
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Consider that the AS stub (`AS456`) shown in the figure below decides to advertise two ``/48`` prefixes instead of its allocated ``/47`` prefix. 144/10000 · 144
13 ../../exercises/routing-protocols.rst:186
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In its output, we see that ``r1`` is attached to two different routers. Finally, the ``show ipv6 ospf6 database`` returns the full OSPFv3 database with all the link state information that was distributed by OSPFv3. 214/10000 · 214
13 ../../exercises/tcp-2.rst:65
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — For this first example, we program packetdrill_ to inject the segments that a client would send. The first step is thus to prepare a :manpage:`socket` that can be used to accept this connection. This socket can be created by using the four system calls below. 259/10000 · 259
13 ../../exercises/trace.rst:82
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — wireshark_ is more recent than tcpdump_. It evolved from the ethereal packet trace analysis software. It can be used as a text tool like tcpdump_. For a TCP connection, wireshark_ can provide almost the same output as tcpdump_. The main advantage of wireshark_ is that it also includes a graphical user interface that allows performing various types of analysis on a packet trace. 380/10000 · 380
13 ../../protocols/bgp.rst:53
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A simple Internet with peering relationships 44/10000 · 44
13 ../../protocols/congestion.rst:46
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Most TCP implementations update the congestion window when they receive an acknowledgment. If we assume that the receiver acknowledges each received segment and the sender only sends MSS sized segments, the TCP congestion control scheme can be implemented using the simplified pseudo-code [#fwrap]_ below. This pseudocode includes the optimization proposed in :rfc:`3042` that allows a sender to send new unsent data upon reception of the first or second duplicate acknowledgment. The reception of each of these acknowledgment indicates that one segment has left the network and thus additional data can be sent without causing more congestion. Note that the congestion window is *not* increased upon reception of these first duplicate acknowledgments. 752/10000 · 752
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