Application Layer 1: HTTP and DNS

In the client-server model:

• clients send requests
• servers are typically always on
• servers often have stable names and addresses
• clients may be intermittently connected
• clients may use dynamic IP addresses
• clients usually communicate through the server, not directly with each other

Examples given include HTTP and FTP. Servers are often placed in data centers and may run as virtual machines rather than as dedicated physical machines.

In a peer-to-peer model:

• hosts communicate directly with each other
• each host can act as both client and server
• there is no need for one central always-on server

Advantages:

• adding peers can also add service capacity

Challenges:

• peers may be intermittently connected
• peer discovery is non-trivial
• peers may have highly unequal resources
• many users prefer consuming resources rather than contributing them
• management and routing can be complex
• scaling is not automatically easy

BitTorrent is used as the classic example. The lecturer notes that peer-to-peer traffic used to be a very large fraction of Internet traffic, but today is much less dominant. Still, torrents remain useful for some software distribution scenarios.

• the client process initiates communication
• the server process must already be running to receive contact

This distinction still makes sense even in peer-to-peer systems, because a peer can play either role at different times.

Processes do not directly inject packets into the network.

Instead, communication goes through the operating system, which provides the interface used by applications.

A socket is like a door:

• the application hands data to the socket
• the OS then takes care of getting it to the destination

The lecturer connects sockets to the Berkeley sockets API, which has remained stable and influential for decades.

A key idea is that many socket operations resemble file operations:

• open a connection
• write data
• read data
• manage the connection

This familiar interface makes socket programming practical for application developers.

Because lower-layer mechanisms are in the operating system:

• changing lower layers is harder
• changing application-layer protocols is much easier

That is one reason application-layer innovation happens quickly.

Syntax defines the form of messages:

• which fields appear
• in what order
• which exact formatting is valid

If syntax is not followed exactly, communication can fail.

Semantics defines what the message means and what action should occur after receiving it.

For example, a request such as asking for the time has a semantic meaning: the receiver should determine and provide the current time.

A major goal in networking is interoperability:

• one implementation’s sender should work with another implementation’s receiver

The lecture states that this is why most Internet protocols are open protocols with public specifications. Many are documented in RFCs (Requests for Comments) through the IETF. Proprietary protocols exist, but historically many were reverse engineered.

A host may have a domain name such as:

• cnn.com

But machines ultimately need an IP address, such as an IPv4 or IPv6 address. Domain names must therefore be translated to IP addresses.

To identify a process on the destination host, a port number is used.

Examples mentioned:

• HTTP: port 80
• HTTPS: port 443
• SMTP: port 25
• SSH: port 22
• Telnet: port 23

The /etc/services file is mentioned as a place where common service/port mappings can be found. DNS tools such as dig can be used to discover IP addresses associated with a domain.

A communicating endpoint is therefore identified by:

• IP address
• port number

This pair uniquely identifies the target process on a host. The same port number can exist on different hosts without conflict because the IP addresses differ.

Port numbers range up to roughly 65K, giving many possible process endpoints on a single host, though in practice operating-system limits and resource constraints matter.

Some applications require full, correct delivery:

• email
• file upload/download
• web documents

Partial delivery is unacceptable for these cases.

Some applications are delay-sensitive:

• interactive games
• certain real-time communications
• medical scenarios

Others, like email, are not real-time sensitive.

Some applications want sustained throughput:

• video
• audio
• large data transfers

The precise requirement depends on the application.

Applications may require:

• confidentiality
• integrity
• protection against tampering

These are not automatically provided by basic TCP or UDP.

TCP is presented as offering:

• reliable transfer
• flow control
• congestion control
• connection-oriented operation

What TCP does not inherently provide:

• timing guarantees
• minimum throughput guarantees
• encryption / security

Flow control prevents overwhelming the receiver.

Congestion control prevents overwhelming the network.

UDP provides very little beyond:

• addressing data to the correct process

It does not provide:

• reliability
• flow control
• congestion control
• timing guarantees
• security

So why use it?

• less overhead
• no connection setup handshake
• useful for very small exchanges
• useful when the application itself is willing to manage missing data or build extra logic on top

The lecturer warns that developers using UDP must be careful, because if they need properties such as congestion control and do not implement them properly, they can damage the network.

The lecture associates transport choices with common applications:

• file transfer: TCP
• web documents: TCP
• Internet telephony: sometimes UDP, sometimes TCP
• interactive games: often UDP, but TCP is also possible

The choice depends on application goals and deployment realities such as firewall behavior.

• it requires another handshake
• it exchanges security-related information
• it is commonly used over TCP
• from the application perspective, it offers an API similar in spirit to sockets
• applications can often be adapted to use TLS without changing their overall communication structure very much

The lecturer strongly recommends using TLS when implementing networked applications.

The lecture briefly mentions that there are protocols combining security and UDP-style transport, especially QUIC, and notes that such designs became more practical once UDP-based traffic became more widely accepted in the network.

A web page is not just one monolithic item.

HTTP stands for Hypertext Transfer Protocol.

It is the application-layer protocol used by the web.

A key property emphasized in the lecture is that HTTP is stateless by default.

HTTP uses a request-response model.

Because HTTP itself is stateless, state has to be added explicitly.

Cookies are small pieces of text stored in the browser. A website can encode values into them and later use them to identify a returning client.

The lecture presents cookies as a four-part mechanism:

1. a cookie is sent by the server in an HTTP response header;
2. the browser stores it locally in a cookie file/storage;
3. future HTTP requests send the cookie back;
4. the server associates the cookie value with data in its backend database.

This enables stateful behavior on top of stateless HTTP.

The next major topic is caching, introduced as a performance optimization.

HTTP/1.1 tried to improve efficiency further by allowing multiple outstanding requests on one TCP connection.

However, responses had to come back in order. Since responses did not explicitly carry enough information to freely reorder them, the client depended on the response sequence.

This caused head-of-line blocking:

• if the first requested object is very large,
• all later objects are delayed behind it.

The lecture uses the analogy of choosing the wrong queue at a bank counter: the person in front may take a long time, while shorter tasks behind them cannot pass.

Loss recovery also remains problematic, because TCP retransmissions can delay all subsequent data on that connection.

HTTP/2 was introduced to address these efficiency problems.

Its key idea is to split large objects into smaller frames and interleave frames from multiple objects over the same connection.

This means:

• a large object no longer monopolizes the connection,
• smaller objects can be delivered earlier,
• overall user-perceived latency is reduced.

HTTP/2 also supports features such as server push/prefetching:

• if the server can predict what the client will likely need next,
• it can send these objects proactively.

This is useful for interactive applications such as map services.

However, HTTP/2 still relies on TCP, so TCP-level loss recovery and congestion-control behavior can still affect all multiplexed streams.

Security is also not inherent unless HTTP is run over TLS.

HTTP/3 is presented as the newest version and as a further improvement.

According to the lecture, HTTP/3:

• adds security,
• improves pipelining/multiplexing behavior,
• avoids some TCP-related limitations,
• runs over UDP rather than TCP.

This means transport-like functions are partially moved up into the application layer/protocol design. That gives more flexibility, but also creates new challenges:

• congestion control must be reimplemented,
• interactions between different protocols and clients can become more complex.

The lecture postpones a deeper treatment until more transport-layer background has been covered.

Humans are good at remembering names, but bad at remembering numerical IP addresses.

Computers, by contrast, operate naturally on numbers.

DNS bridges this gap by providing name resolution:

• mapping hostnames to IP addresses.

The lecture also points out extra complications:

• names may use different character sets,
• hosts may have multiple names,
• one name may map to multiple IP addresses.

Therefore DNS is not just a trivial lookup table.

Historically, such mappings were once maintained manually in a central list or book, but that does not scale.

DNS is an application-layer protocol, even though it is essential to the functioning of the internet.

Its services include:

• hostname to IP address translation,
• support for aliases,
• support for mail servers,
• support for load balancing,
• distributed operation without a single central authority.

One important design principle is that complexity is kept at the edges, not in the network core.

DNS also helps with load balancing:

• one name can map to multiple IP addresses,
• answers can depend on location or time,
• this allows traffic distribution and service optimization.

A centralized DNS would suffer from:

• a single point of failure,
• huge maintenance burden,
• poor scalability.

The lecture emphasizes the massive scale of DNS traffic and the need for performance and distribution.

A practical symptom of DNS problems is intermittent internet failure:

• some sites still work because of cached DNS answers,
• new or expired lookups fail.

Thus caching is also important in DNS.

DNS is organized hierarchically.

At the top is the root. Below it are top-level domains such as:

• generic TLDs like com, org, edu, gov;
• country-code TLDs like de, nl, us, jp.

Below those are further delegated domains and subdomains.

Different organizations are authoritative for different parts of the namespace. This delegation avoids central bottlenecks and distributes administrative responsibility.

DNS stores information in resource records.

The lecture mentions several important record types:

A

maps a hostname to an IPv4 address.

NS

specifies a authoritative name server responsible for a domain.

CNAME

alias record.

MX

mail exchange record.

AAAA

maps a hostname to an IPv6 address.

The lecture gives the intuition for AAAA: it is the IPv6 counterpart of A.

A DNS query/response includes:

• a question section,
• an answer section,
• and additional metadata.

To resolve a name such as amazon.com, the resolver proceeds step by step through the hierarchy.

Conceptually:

1. start at the Root DNS Server;
2. ask which name servers are responsible for com;
3. ask a com DNS Server which name servers are responsible for amazon.com;
4. ask the authoritative server for the A record of amazon.com.

Important distinction:

• before reaching the authoritative server, the resolver often asks for NS records;
• only at the authoritative stage does it get the desired address record.

Thus DNS resolution is an iterative delegation process through the namespace hierarchy.

Every internet-connected system needs a preconfigured way (root hints file, or directly shipped with resolver software) to reach the DNS root.

The lecture notes that this is handled with mechanisms such as anycast:

• multiple physical servers share the same IP address,
• traffic is routed to a nearby or appropriate instance.

This makes the root system scalable and robust.

DNS contains two different kinds of roles that should not be confused.

The root of DNS is the empty label, written as a final dot.

For example, the fully qualified domain name is conceptually:

\[ www.example.com. \]

The final dot represents the root.

Usually users omit the final dot because it is always implied.

The root name servers are authoritative for the root zone ..

They know the name server mappings for all top-level domains.

For example, if a resolver asks about something under .com, the root name server does not know the final website IP address, but it knows which name servers are responsible for .com.

After the root come top-level-domain servers.

Examples:

• .com,
• .org,
• .net,
• .edu,
• country-code TLDs such as .de, .cn, .uk, .fr.

Each top-level domain has its own authoritative name servers.

Below TLDs are second-level domains.

Examples:

• example.com,
• amazon.com,
• uni-saarland.de.

For most websites, the important delegation often ends at the second-level domain.

A subdomain such as:

\[ www.uni\text{-}saarland.de \]

does not necessarily mean a separate DNS zone exists for www.

It can simply be a name inside the uni-saarland.de zone.

A key point from the lecture is that name servers themselves are identified by names.

For example, the authoritative name server for example.com might be:

\[ ns1.example.com \]

But to query ns1.example.com, the resolver needs its IP address.

This leads to a possible circular dependency:

To find the address of example.com, ask ns1.example.com. But to ask ns1.example.com, we first need the address of ns1.example.com.

This is why the parent zone may also need to provide the address of the child zone’s name server.

This additional address information is called glue.

For example:

• the parent .com zone says that ns1.example.com is authoritative for example.com,
• if ns1.example.com is inside example.com, the parent also gives its IP address.

This avoids the circular lookup problem.

The lecturer emphasized that this creates operational complexity:

• changing a name server name may require updating the parent,
• changing a name server IP address may require updating the parent,
• adding a new name server may require checking whether glue is needed.

Historically this design grew organically and is hard to replace.

DNS resolution can be described using two query styles.

DNS is heavily cached.

Whenever a resolver learns a mapping, it can cache it.

Each DNS record contains a TTL:

\[ TTL = \text{time to live} \]

The TTL tells resolvers how long the answer may be cached.

Short TTLs are useful when:

• the server may change soon,
• load balancing is performed,
• failover is expected.

Long TTLs are useful when:

• records are stable,
• query load should be reduced,
• high-level delegation information rarely changes.

Important consequence:

If a record changes, the change is not immediately visible everywhere.

Old records may remain in caches until their TTL expires.

For example, if a record has a TTL of two days and the server IP changes, some clients may still use the old IP for up to two days.

The lecturer also mentioned that some clients or systems may use stale DNS records aggressively, trying to connect using old cached data while doing fresh DNS resolution in parallel.

DNS can also map IP addresses back to names.

This is called reverse DNS.

Special DNS domains are used:

• in-addr.arpa for IPv4,
• ip6.arpa for IPv6.

For IPv4, the octets are reversed.

Example:

\[ 23.220.149.130 \]

is represented as:

\[ 130.149.220.23.in\text{-}addr.arpa. \]

For IPv6, the address is reversed nibble by nibble, i.e. 4 bits at a time, under ip6.arpa.

Reverse DNS becomes important later in the email part, especially for mail server verification.

The lecturer summarized DNS as useful but messy.

DNS is a distributed hierarchical database, and it mostly works, but it was not designed with modern security requirements in mind.

DNS is:

• a distributed hierarchical database,
• an application-layer protocol,
• a core Internet function,
• implemented at the network edge.

Authoritative name servers:

• are responsible for zones,
• store mappings,
• answer resolver queries,
• may return final answers or referrals.

Resolvers:

• query authoritative servers,
• perform the heavy lifting,
• cache results,
• reduce load and latency.

DNS is also a recurring dependency for many other protocols, especially email.