Exit Zen
10
../../protocols/bgp.rst:41
English
In the early days of the Internet, domains would simply exchange all the routes they know to allow a host inside one domain to reach any host in the global Internet. However, in today's highly commercial Internet, this is no longer true as interdomain routing mainly needs to take into account the economical relationships between the domains. Furthermore, while intradomain routing usually prefers some routes over others based on their technical merits (e.g. prefer route with the minimum number of hops, prefer route with the minimum delay, prefer high bandwidth routes over low bandwidth ones, etc) interdomain routing mainly deals with economical issues. For interdomain routing, the cost of using a route is often more important than the quality of the route measured by its delay or bandwidth.
0/8000 · 800
10
../../protocols/congestion.rst:34
English
Evaluation of the TCP congestion window with severe congestion
0/620 · 62
10
../../protocols/dnssec.rst:114
English
These attacks affect the DNS messages that are exchanged between a client and its resolver or between a resolver and name servers. Another type of attack exploits the possibility of providing several resource records inside one DNS response. A frequent optimization used by DNS servers and resolvers is to include several related resource records in each response. For example, if a client sends a DNS query for an `NS` record, it usually receives in the response both the queried record, i.e. the name of the DNS server that serves the queried domain, and the IP addresses of this server. Some DNS servers return several `NS` records and the associated IP addresses. The `cache poisoning` attack exploits this DNS optimization.
0/7280 · 728
10
../../protocols/email.rst:58
English
Email messages, like postal mail, are composed of two parts :
0/610 · 61
10
../../protocols/ethernet.rst:70
English
Where should the CRC be located in a frame ?
0/440 · 44
10
../../protocols/http.rst:49
English
A standard document format : the `HyperText Markup Language <http://www.w3.org/MarkUp>`_
0/880 · 88
10
../../protocols/http2.rst:59
English
A second approach is to rely on `k` reverse proxies and `N-k` servers. The servers store the content and the proxies cache the most frequently used files. The proxies can be geographically close to the clients while the servers can reside in the datacenters of the content provider. The DNS server can also distribute the load among the different proxies or return the geographically closest proxy. An important point to note about reverse proxies is that they receive HTTP requests from clients and send HTTP requests to the original servers that host the content. Several companies, usually called Content Distribution Networks, have deployed such reverse proxies throughout the world to cache web content next to the end-users. A good description of such a CDN may be found in [NSS2010]_.
0/7910 · 791
10
../../protocols/ipv6.rst:77
English
IP version 6
0/120 · 12
10
../../protocols/ppp.rst:21
English
The PPP framing :rfc:`1662` was inspired by the datalink layer protocols standardized by ITU-T and ISO. A typical PPP frame is composed of the fields shown in the figure below. A PPP frame starts with a one byte flag containing `01111110`. PPP can use bit stuffing or character stuffing depending on the environment where the protocol is used. The address and control fields are present for backward compatibility reasons. The 16 bit Protocol field contains the identifier [#fpppid]_ of the network layer protocol that is carried in the PPP frame. `0x002d` is used for an IPv4 packet compressed with :rfc:`1144` while `0x002f` is used for an uncompressed IPv4 packet. `0xc021` is used by the Link Control Protocol, `0xc023` is used by the Password Authentication Protocol (PAP). `0x0057` is used for IPv6 packets. PPP supports variable length packets, but LCP can negotiate a maximum packet length. The PPP frame ends with a Frame Check Sequence. The default is a 16 bits CRC, but some implementations can negotiate a 32 bits CRC. The frame ends with the `01111110` flag.
0/10710 · 1071
10
../../protocols/ppp.rst:31
English
PPP played a key role in allowing Internet Service Providers to provide dial-up access over modems in the late 1990s and early 2000s. ISPs operated modem banks connected to the telephone network. For these ISPs, a key issue was to authenticate each user connected through the telephone network. This authentication was performed by using the `Extensible Authentication Protocol` (EAP) defined in :rfc:`3748`. EAP is a simple, but extensible protocol that was initially used by access routers to authenticate the users connected through dial-up lines. Several authentication methods, starting from the simple username/password pairs to more complex schemes have been defined and implemented. When ISPs started to upgrade their physical infrastructure to provide Internet access over `Asymmetric Digital Subscriber Lines` (ADSL), they tried to reuse their existing authentication (and billing) systems. To meet these requirements, the IETF developed specifications to allow PPP frames to be transported over other networks than the point-to-point links for which PPP was designed. Nowadays, most ADSL deployments use PPP over either ATM :rfc:`2364` or Ethernet :rfc:`2516`.
0/11710 · 1171
10
../../protocols/routing.rst:31
English
In this section, we briefly describe the key features of the two main intradomain unicast routing protocols : RIP and OSPF. The basic principles of distance vector and link-state routing have been presented earlier.
0/2150 · 215
10
../../protocols/rpc.rst:20
English
The first problem to be solved is how to transfer the information from the caller to the callee. This problem is not simple and includes two sub-problems. The first sub-problem is the encoding of the information. How to encode the values of the parameters so that they can be transferred correctly through the network ? The second problem is how to reach the callee through the network ? The callee is identified by a procedure name, but to use the transport service, we need to convert this name into an address and a port number.
0/5310 · 531
10
../../protocols/ssh.rst:85
English
encryption
0/100 · 10
10
../../protocols/tcp.rst:26
English
To provide this service, TCP relies on a simple segment format that is shown in the figure below. Each TCP segment contains a header described below and, optionally, a payload. The default length of the TCP header is twenty bytes, but some TCP headers contain options.
0/2680 · 268
10
../../protocols/tls.rst:43
English
110
0/100 · 3
10
../../protocols/transport-service.rst:22
English
`IP version 4` addresses that are 32 bits wide
0/460 · 46
10
../../protocols/udp.rst:51
English
The UDP header contains four fields :
0/370 · 37
10
../../protocols/wifi.rst:19
English
Range (m) indoor/outdoor
0/240 · 24
11
../../bibliography.rst:36
English
Buford, J., Yu, H., Lua, E.K., `P2P Networking and Applications <http://books.google.com/books?id=O9NkAaY9YxMC>`_, Morgan Kaufmann, 2008
0/1360 · 136
11
../../glossary.rst:270
English
The Address Resolution Protocol is a protocol used by IPv4 devices to obtain the datalink layer address that corresponds to an IPv4 address on the local area network. ARP is defined in :rfc:`826`
0/1950 · 195