Outline
- DNS
- peer-to-peer
- Internet telephony
- Transport Layer
- multiplexing and demultiplexing
- User Datagram Protocol
DNS Lookup
- host requests translation (over TCP or UDP)
- server can:
- provide translation from its authoritative data
- provide translation from its cache
- "recursively" forward the request to another server
closer to the destination (in one of its neighboring zones) -- proxy
request or recursive request
- provide the address of another server closer to the destination,
in which case the client "iteratively" sends the same request to the
next server
- a client can try different suffixes if the name itself doesn't work
(e.g. .ics.hawaii.edu or .hawaii.edu)
P2P
- in peer-to-peer applications, the same program typically
acts as both a client and a server
- peer-to-peer can substantially speed up broadcasting of
content, since, after the content has been transferred a few
times, it can be sent by many systems at once
- the original content provider can also leave the network,
and the content can still be available from other peers
- P2P systems can be much less centralized than client-server
systems
BitTorrent
- BitTorrent is a content distribution protocol (it is also
the name of a BitTorrent client and of a company)
- the word "torrent" implies a large volume of water flowing quickly,
and by metaphorical extension, a bit torrent would be
a large volume of data flowing quickly
- in BitTorrent, a torrent is a group of files managed by a single
tracking node
- different torrents are managed by different trackers
- any peer willing to provide the entire content of a torrent
is a seed
- a torrent is downloaded in a non-linear order, typically from
the peers that already have the data rather than from the tracker
- once a peer has downloaded a chunk of a torrent, that chunk
is available for download by other peers
BitTorrent optimizations
- each peer tries to download one of the chunks that the fewest
other peers have -- a rare chunk
- each peer tries to download from peers with whom it maintains
the highest download speeds
- each peer also experimentally tries other peers, to see if it
can improve its download speeds
- peers that only download, and don't upload, may be penalized
in their downloading, to encourage peers to contribute back to the
system
Decentralized p2p networking
- if there is a centralized point of contact to find the tracker
for a given torrent, p2p file sharing can be very effective
- how to accomplish the same without a centralized point of
contact?
- a new peer wishing to join a p2p network must begin with
the address of at least one member of the p2p network
- the new peer can then ask the established peer to put it
in contact with other members of the network
- there must be some limitation on how far the request is
propagated, otherwise a large p2p network might spend all its time
forwarding requests from new peers
Decentralized Information Storage
- information can be searched for by identifier
- this identifier is a bit string
- in a Distributed Hash Table (DHT), each bit string can
be mapped to a small number of hosts in the p2p network
- a peer can then contact one of these hosts to obtain the
content
Internet Telephony
- there are standard, published protocols for VoIP
- but the most popular in 2009 is a proprietary protocol, Skype
- Skype uses p2p techniques in asking a relay to forward
data among two hosts, both of which connect to the relay as to
a server
Transport Protocols
- a transport protocol provides services to the
application layer by using the services provided by
the network layer
- since the network layer provides end-to-end transmission,
the transport protocol only functions on the end systems
- all internet transport protocols provide:
- integrity checks: verifying with high probability that the data
received is the same as was sent
- application-to-application communication, for example
connecting a browser with a web server that is running on a machine
on which a mail server is also running
Internet Transport Protocols
- the Internet provides three transport protocols: TCP, UDP, and SCTP
- UDP only provides the integrity check and application-to-application
communication
- TCP and SCTP also provide:
- reliable transmission: all the data sent must be acknowledged by the
receiver. Timers cause the retransmission of data that is not acknowledged.
- congestion control: the sender limits sending speed when the network
is congested
- these are needed by many applications because the underlying
network layer protocol, IP, only provides best-effort delivery, and
no information about how fast to send
Multiplexing and Demultiplexing
- whenever multiple entities are layered on top of one protocol,
it is necessary to distinguish them
- for example, when there are potentially multiple applications
using TCP, each incoming TCP packet must be delivered to exactly one
of the applications
- likewise for UDP
- this is done by including a number in each packet sent that
identifies the application that is to receive the packet
- a UDP socket will receive all packets that
carry its IP number (which delivers the packet to the host)
and port number
- this includes packets from any sender addressed to the
given destination port
TCP ports
- a listening socket in TCP is bound to a port number
- such a socket will accept connection requests
from any (host, port) that have its port number as the destination port
- a connected TCP socket is associated with four numbers:
(local host, local port, remote host, remote port)
- the packet carries source and destination ports
- the socket records local and remote ports
- when sending, the local information is used for the source,
the remote information for the destination
- when receiving, the destination is matched to the local information,
and the source is matched to the remote information
- so for example, a web client has local port 18451, and connects
to a web server on port 80, so its remote port is 80
- the HTTP request packet has source port 18451, destination port 80
- the HTTP reply packet has source port 80, destination port 18451
- each socket for the HTTP server has a different remote port number,
so a different reply can be sent, e.g. to the browser on port 45856
- a browser can even open multiple connections to the same server,
as long as its local port for the different connections is different
Port Security
- ports below 1024 are reserved for programs with administrator privileges
- many applications use a predefined port when possible, for example
port 80 for HTTP
- such ports are called well-known ports, and are listed,
for example, in /etc/services on Unix machines
- port scanning is the process of sending packets to different
port numbers on a machine (or multiple machines) to see if there
are applications listening on a given port
- for example, the probe packets could be TCP connection requests
- some applications have known vulnerabilities that can be
exploited by an attacker
UDP
- the User Datagram Protocol does very little besides
(de)multiplexing and integrity checking
- UDP is connectionless, so an application can immediately
send a UDP packet to any other process with an open UDP socket,
without first connecting to that socket (sendto and
recvfrom)
- UDP header format (from
RFC 768):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDP Header Format
Internet Checksum
- the checksum of a collection of numbers is the sum of those numbers
- in the internet protocols, the sum is negated before being sent,
so the total should be zero
- in the internet protocols, the sum is done by breaking the data
up into 16-bit units, and then logically all the 16 bit values are summed
- in the internet protocols, the sum uses 1's complement arithmetic,
so that any carry beyond 16 bits is added back into the total
- with 1's complement arithmetic, negation is done by simply
complementing each bit of the sum
- because the checksum is a 16 bit sum, if there are two random
bit errors, there is a 1/32 chance they will cancel out (if a 1 turns to
a zero and a 0 to a one in the same bit position) and the
checksum will still match even though the data is wrong
- fortunately, the likelihood of two bit errors is low in most networks
- Unlike TCP, the UDP checksum is optional, and sent as zero (0x0000) if
not computed
Pseudo-header
- In TCP and UDP, the checksum covers the header, data, and a pseudo-header
- the TCP and UDP pseudo-header has fields derived from the IP header
- this header is used in computing the checksum, but never sent
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero | Protocol | TCP/UDP length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pseudo Header Format