2. cnp3-ebook
3. English
4. Zen

23 ../../protocols/dnssec.rst:220
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — There are several details of the operation of DNSSEC that are worth being discussed. First, a server that supports DNSSEC must have a public-private key pair. The public key is distributed with the `DNSKEY` record. The private key is never distributed and it does not even need to be stored on the server that uses the public key. DNSSEC does not require the DNSSEC servers to perform any operation that requires a private key in real time. All the `RRSIG` records can be computed offline, possibly on a different server than the server that returns the DNSSEC replies. The initial motivation for this design choice was the CPU complexity of computing the `RRSIG` signatures for zones that contain millions of records. In the early days of DNSSEC, this was an operational constraint. Today, this is less an issue, but avoiding costly signature operations in real time has two important benefits. First, this reduces the risk of denial of service attacks since an attacker cannot force a DNSSEC server to perform computationally intensive signing operations. Second, the private key can be stored offline, which means that even if an attacker gains access to the DNSSEC server, it cannot retrieve its private key. Using offline signatures for the `RRSIG` records has some practical implications that are reflected in the content of this record. First, each `RRSIG` record contains the original TTL of the signed record. When DNS resolvers cache records, they change the value of the TTL of these cached records and then return the modified records to their clients. When a resolver receives a signed DNS record, it must replace the received TTL of the record with the original TTL (and check that the received TTL is smaller than the original one) before checking the signature. Second, the `RRSIG` records contain a validity period, i.e. a starting time and an ending time for the validity of the signature. This period is specified as two timestamps. This period is only the validity of the signature. It does not affect the TTL of the signed record and is independent from the TTL. In practice, the validity period is important to allow DNS server operators to update their public/private keys. When such a key is changed, e.g. because the private could have been compromised, there is some period of time during which records signed with the two keys coexist in the network. The validity period allows ensuring that old signatures do not remain in DNS caches for ever. 2471/10000 · 2471
23 ../../protocols/email.rst:124
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Several other optional header lines are defined in :rfc:`5322` and elsewhere [#femailheaders]_. Furthermore, many email clients and servers define their own header lines starting from `X-`. Several of the optional header lines defined in :rfc:`5322` are worth being discussed here : 282/10000 · 282
23 ../../protocols/ethernet.rst:156
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A hierarchical Ethernet network composed of hubs 48/10000 · 48
23 ../../protocols/http.rst:110
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A simple HTML page 18/10000 · 18
23 ../../protocols/http2.rst:155
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The information exchanged over an HTTP/2.0 session is composed of frames. A frame starts with a 9 bytes-long header that carries several types of information. The HTTP/2.0 frames have a variable length. The `Length` field of the header contains the length of the frame payload in bytes. As this field is encoded as a 24 bits field, an HTTP/2.0 frame cannot be longer than :math:`2^{24} -1` bytes. It should be noted that :rfc:`7540` assumes a maximum size of :math:`2^{14}` bytes, i.e. 16,384 bytes for the HTTP/2.0 frame payload unless a longer maximum frame length has been negotiated at the beginning of the session using the HTTP/2.0 `Settings` frame that will be described later. The next field of the frames header indicates the frame type. The first frame types are `Data` which contains data from web objects and `Headers` containing HTTP/2.0 headers. When a client retrieves a web object from a server, it always receives an HTTP/2.0 `Headers` frame followed by an HTTP/2.0 `Data` frame. The `Headers` frame information contains essentially the same HTTP headers as the ones supported by HTTP/1.1, but those are encoded by leveraging a data compression technique that minimizes the number of bytes required to transmit them. 1233/10000 · 1233
23 ../../protocols/ipv6.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — IPv6 addressing architecture 28/10000 · 28
23 ../../protocols/ethernet.rst:59
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The last field of the Ethernet frame is a 32 bit Cyclical Redundancy Check (CRC). This CRC is able to catch a much larger number of transmission errors than the Internet checksum used by IP, UDP and TCP [SGP98]_. The format of the Ethernet frame is shown below. 261/10000 · 261
23 ../../protocols/routing.rst:75
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Internal router : A router whose directly connected networks belong to the area 79/10000 · 79
23 ../../protocols/rpc.rst:100
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second sub-problem is how to reach the callee. A simple solution to this problem is to make sure that the callee listens on a specific port on the remote machine and then exchange information with this server process. This is the solution chosen for JSON-RPC [JSON-RPC2]_. JSON-RPC can be used over the connectionless or the connection-oriented transport service. A JSON-RPC request contains the following fields: 417/10000 · 417
23 ../../protocols/ssh.rst:204
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a key used by the client (resp. server) to encrypt the data that it sends 73/10000 · 73
23 ../../protocols/tcp.rst:50
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the `RST` is used in case of problems or when an invalid segment has been received 82/10000 · 82
23 ../../protocols/tls.rst:47
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 990 3/10000 · 3
23 ../../protocols/transport-service.rst:65
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second transport service is the connection-oriented service. On the Internet, this service is often called the `byte-stream service` as it creates a reliable byte stream between the two applications that are linked by a transport connection. Like the datagram service, the networked applications that use the byte-stream service are identified by the host on which they run and a port number. These hosts can be identified by an address or a name. The figure below illustrates two applications that are using the byte-stream service provided by the TCP protocol on IPv6 hosts. The byte stream service provided by TCP is reliable and bidirectional. 651/10000 · 651
23 ../../protocols/udp.rst:74
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the entire UDP segment, including its header 44/10000 · 44
23 ../../protocols/wifi.rst:24
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — 11 Mbps 7/10000 · 7
23 ../../bibliography.rst:33
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Barrett, R. Silverman, R. Byrnes, `SSH: The Secure Shell (The Definitive Guide) <https://books.google.be/books?id=3XzIFG3w8-YC>`_, O'Reilly 2005 (2nd edition). 159/10000 · 159
23 ../../principles/sharing.rst:192
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Besides bandwidth and memory, a third resource that needs to be shared inside a network is the (packet) processing capacity. To forward a packet, a router needs bandwidth on the outgoing link, but it also needs to analyze the packet header to perform a lookup inside its forwarding table. Performing these lookup operations require resources such as CPU cycles or memory accesses. Routers are usually designed to be able to sustain a given packet processing rate, measured in packets per second [#fpps]_. 504/10000 · 504
23 ../../principles/transport.rst:71
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Organization of the information flow. For many applications, the flow of information must be structured and there are precedence relationships between the different types of information. In the time example above, Alice must greet Bob before asking for the current time. Alice would not ask for the current time first and greet Bob afterwards. Such precedence relationships exist in networked applications as well. For example, a server must receive a username and a valid password before accepting more complex commands from its clients. 538/10000 · 538
24 ../../exercises/ex-sharing.rst:559
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — How is the maximum round-trip-time influenced if the buffers of router `R1` store 10 packets ? 94/10000 · 94
24 ../../principles/naming.rst:125
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Benefits of names 17/10000 · 17