2. cnp3-ebook
3. English
4. Zen

33 ../../principles/security.rst:371
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — These two keys are generated together and they are linked by a complex mathematical relationship that is such that it is computationally difficult to compute :math:`K_{priv}` from :math:`K_{pub}`. 196/10000 · 196
33 ../../exercises/dns.rst:112
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Footnotes 9/10000 · 9
33 ../../exercises/ipv6.rst:297
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ... 3/10000 · 3
33 ../../exercises/routing-protocols.rst:378
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Exploring BGP 13/10000 · 13
33 ../../exercises/tcp-2.rst:259
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another very interesting utilization of packetdrill_ is to explore how a TCP stack reacts to acknowledgments that would correspond to lost or reordered segments. For this analysis, we configure a very large initial congestion window to ensure that the connection does not start with a slow-start. 296/10000 · 296
33 ../../protocols/bgp.rst:110
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — BGP routers exchange routes over BGP sessions. A BGP session is established between two routers belonging to two different domains that are directly connected. As explained earlier, the physical connection between the two routers can be implemented as a private peering link or over an Internet eXchange Point. A BGP session between two adjacent routers runs above a TCP connection (the default BGP port is 179). In contrast with intradomain routing protocols that exchange IP packets or UDP segments, BGP runs above TCP because TCP ensures a reliable delivery of the BGP messages sent by each router without forcing the routers to implement acknowledgments, checksums, etc. Furthermore, the two routers consider the peering link to be up as long as the BGP session and the underlying TCP connection remain up [#flifetimebgp]_. The two endpoints of a BGP session are called `BGP peers`. 886/10000 · 886
33 ../../protocols/congestion.rst:186
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Modeling TCP congestion control 31/10000 · 31
33 ../../protocols/email.rst:176
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The `Content-Transfer-Encoding:` header line is used to specify how the message has been encoded. When MIME was designed, some email servers were only able to process messages containing characters encoded using the 7 bits ASCII character set. MIME allows the utilization of other character encodings. 301/10000 · 301
33 ../../protocols/ethernet.rst:173
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Two pairs of category 3+ UTP 28/10000 · 28
33 ../../protocols/http.rst:144
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Several types of method can be used in HTTP requests. The three most important ones are : 89/10000 · 89
33 ../../protocols/http2.rst:232
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — As the server can send multiple objects at the same time, there is a risk of overloading the client buffers. To cope with this potential problem, HTTP/2.0 includes its own flow control mechanism. When an HTTP/2.0 session starts, a receiver agrees to receive up to 65,535 bytes over this connection (unless it has indicated a different initial window in its `Settings` frame). This limits the amount of data that a sender can transmit over the HTTP/2.0 session. The receiver can advertise a large receive window by sending a `Window_Update` frame at any time. This flow control mechanism can be applied to the entire connection or to a specific stream. In practice, using a small `HTTP/2.0 window` could severely limit the throughput over an HTTP/2.0 session. 758/10000 · 758
33 ../../protocols/ipv6.rst:121
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — ``0:0:0:0:0:0:0:1`` is represented as ``::1`` 45/10000 · 45
33 ../../protocols/ethernet.rst:99
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first property is a consequence of the utilization of CSMA/CD. The second property is a consequence of the physical organization of the Ethernet network as a shared bus. These two properties are important and all revisions to the Ethernet technology have preserved them. 274/10000 · 274
33 ../../protocols/routing.rst:101
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — On the other hand, consider the prefixes `2001:db8:aaaa:0000::/64` and `2001:db8:aaaa:0001::/64` that are inside `area 1`. Router `RA` is the only area border router that is attached to this area. This router can create two different network summary advertisements : 266/10000 · 266
33 ../../protocols/rpc.rst:118
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — `error`: if the method called does not exist or its execution causes an error, the `result` element will be replaced by an `error` element which contains the following members : 177/10000 · 177
33 ../../protocols/ssh.rst:246
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Authenticating messages with HMAC 33/10000 · 33
33 ../../protocols/tcp.rst:111
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A TCP connection is established by using a three-way handshake. The connection establishment phase uses the `sequence number`, the `acknowledgment number` and the `SYN` flag. When a TCP connection is established, the two communicating hosts negotiate the initial sequence number to be used in both directions of the connection. For this, each TCP entity maintains a 32 bits counter, which is supposed to be incremented by one at least every 4 microseconds and after each connection establishment [#ftcpclock]_. When a client host wants to open a TCP connection with a server host, it creates a TCP segment with : 612/10000 · 612
33 ../../protocols/tls.rst:130
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In a nutshell, the client starts the TLS handshake by proposing a random nonce. The server replies with its random nonce and a certificate that binds its name to a public key. The client generates a MasterSecret that will be used later to derive the session keys and encrypts it with the public key of the server. It also generates a `Finished` message that contains a MAC of all the messages exchanged to allow the server to detect any modification of the messages sent by the client. The server also sends its own `Finished` message. At that point, the client and the server sent encrypted records thanks to the keys derived from the MasterSecret. 649/10000 · 649
33 ../../protocols/wifi.rst:35
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The architecture of WiFi networks is slightly different from the Local Area Networks that we have discussed until now. There are, in practice, two main types of WiFi networks : `independent` or `adhoc` networks and `infrastructure` networks [#fBSS]_. An `independent` or `adhoc` network is composed of a set of devices that communicate with each other. These devices play the same role and the `adhoc` network is usually not connected to the global Internet. `Adhoc` networks are used when for example a few laptops need to exchange information or to connect a computer with a WiFi printer. 591/10000 · 591
33 ../../exercises/reliability.rst:64
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Checksums and CRCs should not be confused with secure hash functions such as MD5 defined in :rfc:`1321` or SHA-1 described in :rfc:`4634`. Secure hash functions are used to ensure that files or sometimes frames/packets/segments have not been modified. Secure hash functions aim at detecting malicious changes while checksums and CRCs only detect random transmission errors. Use the `shasum <http://linux.die.net/man/1/shasum>`_ or `md5sum <http://linux.die.net/man/1/md5sum>`_ programs on Linux to perform the same tests as above. 530/10000 · 530