Introduction to Networking

and the Internet

Copyright © University of Illinois CS 241 Staff 1

Announcements

  Brighten’s office hours cancelled for

today
  extra hours next week
  Wade Fagen lecturing on Friday

Copyright © University of Illinois CS 241 Staff 2

Where are we?

  Function calls, system calls, threads and

processes

Copyright © University of Illinois CS 241 Staff 3

What’s next?

  Networked communication and distributed

applications

Copyright © University of Illinois CS 241 Staff 4

Introduction

  What is the Internet?

  Network edge
  What is a protocol?
  Protocol layers, service models

Copyright © University of Illinois CS 241 Staff 5

What is the Internet?
Mobile network
  Communication
Global ISP
infrastructure
  Enables distributed
applications
  Web, VoIP, email, games, Home network
e-commerce, file sharing Regional ISP
  Communication services
  Provided to applications
  Reliable data delivery from Institutional network
source to destination
  “best effort” (unreliable)
data delivery

Copyright © University of Illinois CS 241 Staff 6

Network Service
  Goal
  Transfer data between end
systems
  Support For Common
Services
  Simplify the role of applications
  Hide the complexity of the
network
  Semantics and interface depend
on applications

Copyright © University of Illinois CS 241 Staff 7

Example: Sending a Letter
Bob Logical flow of information
Alice

Bob’s Alice’s
mailbox mailbox

Postman
Copyright © University of Illinois CS 241 Staff 8
Services

  Unconfirmed service

US Mail
Request Indicate

  Acknowledged service
Request Indicate

US Mail
Confirm Indicate

Copyright © University of Illinois CS 241 Staff 9

Channels
  Channel
  The abstraction for application-level communication
  Idea
  Turn host-to-host connectivity into process-to-process
communication
Host Host
Proc

Host
Proc
Channel
Host Host
Looks like IPC!

Copyright © University of Illinois CS 241 Staff 10

Networked Communication
Challenges
  Networked communication ≠ IPC
  Problems typically masked by communication channel
abstractions
  Bit errors (electrical interference)
  Packet errors (congestion)
  Link/node failures
  Message delays
  Out-of-order delivery
  Eavesdropping
  Goal
  Fill the gap between what applications expect and what the
underlying technology provides

Copyright © University of Illinois CS 241 Staff 11

Network Architecture
  Networks are   Question
complex!   Is there any hope
  Many “pieces” of organizing
  Hosts structure of
  Routers network?
  Links of various
media
  Applications
  Protocols
  Hardware, software

Copyright © University of Illinois CS 241 Staff 12

Abstraction through Layering
  Abstract system into layers:
  Decompose the problem of building a network into manageable
components
  Each layer provides some functionality
  Modular design provides flexibility
  Modify layer independently
  Allows alternative abstractions

Application programs
Unconfirmed service Acknowledged service
Host-to-host connectivity
Hardware

Copyright © University of Illinois CS 241 Staff 13

Layering Example: Air Travel

  Layers
  Each layer implements a service
  Via its own internal-layer actions
  Relying on services provided by layer below

Copyright © University of Illinois CS 241 Staff 14

Why layering?
  Complexity
  Explicit structure allows identification, relationship of
complex system’s pieces
  Modularity
  Eases maintenance, updating of system
  Change of implementation of layer’s service transparent to
rest of system
  e.g., change in gate procedure doesn’t affect rest of system

Copyright © University of Illinois CS 241 Staff 15

Protocol: Language of
communication across hosts
  Defines structure of   Protocols define
communication   Format
between two instances   Order of msgs sent
of a layer (on two and received
hosts) among network
  Protocols are defined entities
by   Actions taken on
  Specific msgs sent msg transmission,
  Specific actions receipt
taken when msgs
received, or other
events Copyright © University of Illinois CS 241 Staff 16
What is a Protocol?
  Human protocols   Network protocols
  “what’s the time?”   Machines rather than humans
  “I have a question”   All internet communication is
  Introductions governed by protocols

Hi TCP connection
request
Hi TCP connection
response
Got the Get http://www.uiuc.edu
time?
2:00 time <file>

Copyright © University of Illinois CS 241 Staff 17

Network Protocols
  A protocol implements a communication service
that higher-layer objects use to exchange
messages
  Service interface
  To objects on the same computer that want to use its
communication services
  Peer interface
  To its counterpart on a different machine
  Peers communicate using the services of lower-level
protocols

Copyright © University of Illinois CS 241 Staff 18

 Interfaces
baggage (check) baggage (claim)
departing airport

arriving airport
gates/bags (load) gates/bags (unload)

runway takeoff runway landing

airplane routing airplane routing

airplane routing airplane routing

intermediate air
airplane routing
traffic sites
Copyright © University of Illinois CS 241 Staff 19
Interfaces

Host 1 Host 2

Higher- Peer-to-peer Higher-

level level
protocol interface protocol
(TCP) (TCP)
Service interface

Lower-level Lower-level
Protocol Protocol
(IP) Peer-to-peer (IP)
interface

Copyright © University of Illinois CS 241 Staff 20

Layering Concepts
  Encapsulation
  Higher layer protocols create messages and
send them via the lower layer protocols
  These messages are treated as data by the
lower-level protocol
  Higher-layer protocol adds its own control
information in the form of headers or trailers
  Multiplexing and Demultiplexing
  Use protocol keys in the header to determine
correct upper-layer protocol

Copyright © University of Illinois CS 241 Staff 21

 Encapsulation
Application Application Application Application
DATA DATA
program program program program
UNC HDR DATA UNC HDR DATA

Best effort Reliable Best effort Reliable

Service Service Service Service

Host-to-Host Host-to-Host

HHP HDR UNC HDR DATA HHP HDR UNC HDR DATA

HHP HDR UNC HDR DATA

Copyright © University of Illinois CS 241 Staff 22

Internet Protocol Stack

Application   Application: Application specific protocols

Transport
  Transport: Process-to-process channel
Network
  Network: Host-to-host packet delivery
Data Link   Data Link: Framing of data bits
Physical   Physical: Transmission of raw bits

Copyright © University of Illinois CS 241 Staff 23

 Transport Layer
application
transport
  Provide logical communication network
data link
between application processes physical

running on different hosts

  Transport protocols run in end
systems
  Send side
  Break application messages into segments
  Pass to network layer
  Receive side
  Reassemble segments into messages application
  Pass to application layer transport
network
  More than one transport protocol data link
physical
available to applications
  Internet: TCP and UDP

Copyright © University of Illinois CS 241 Staff 24

Transport vs. Network Layer
  Transport layer
  Logical
communication Bob Logical flow of information
between Alice

processes
  Relies on,
enhances, Bob’s Alice’s
mailbox
network layer mailbox
services
  Network layer
  Logical Postman
communication
between hosts

Copyright © University of Illinois CS 241 Staff 25

Internet Architecture

  Features
  No strict layering

Application
TCP UDP
IP
Network

Copyright © University of Illinois CS 241 Staff 26

Internet Architecture –
Hourglass Design

  Features
  Hourglass shape – IP is the focal point
FTP HTTP NV TFTP

TCP UDP

IP

Ethernet 3G wireless MPLS Modem

Copyright © University of Illinois CS 241 Staff 27
Network Applications

Copyright © University of Illinois CS 241 Staff 28

Creating a Network Application

  Write programs that

  Run on (different) end systems
  Communicate over network
  e.g., web server software communicates with browser
software
  No need to write software for network-core
devices
  Network-core devices do not run user
applications

Copyright © University of Illinois CS 241 Staff 29

Client-server Architecture
  Server
  Always-on host
  Well-known IP address
  Clients
  Communicate with server
  May be intermittently
connected client/server
  May have dynamic IP
addresses
  Do not communicate
directly with each other

Copyright © University of Illinois CS 241 Staff 30

P2P Architecture
  No always-on server
  Arbitrary end systems
directly communicate peer-peer
  Peers are intermittently
connected and change
IP addresses

  Highly scalable but

difficult to manage

Copyright © University of Illinois CS 241 Staff 31

Hybrid Client-server and P2P
  Skype
  Voice-over-IP P2P application
  Centralized server: finding address of remote party
  Client-client connection: direct (not through server)
  Instant messaging
  Chatting between two users is P2P
  Centralized service: client presence detection/location
  User registers its IP address with central server when it
comes online
  User contacts central server to find IP addresses of
buddies

Copyright © University of Illinois CS 241 Staff 32

Addressing Processes
  Receiving messages   Process Identifier
  Process must have   Include both IP address
identifier and port number
  Host device has unique associated with
32-bit IP address process on host
  Question   Example port numbers
  Does the IP address of   HTTP server: 80
host suffice for   Mail server: 25
identifying the process?
  Answer: No, many
processes can be
running on same host

Copyright © University of Illinois CS 241 Staff 34

Sockets
  Process sends/receives
messages to/from its host or host or
server server
socket
  Analogous to a door
  Sending process shoves process process
messages out the door
socket socket
  Transport infrastructure
TCP with TCP with
on other side of door Internet
buffers, buffers,
brings message to variables variables
socket at receiving
process

Copyright © University of Illinois CS 241 Staff 35

Sockets
  API
host or host or
  Choice of transport server
server
protocol
  Ability to set a few
parameters process
process

socket socket
TCP with TCP with
buffers, Internet buffers,
variables variables

Copyright © University of Illinois CS 241 Staff 36

Transport Services
  Data loss   Throughput
  Some applications   Some applications
(e.g., audio) can (e.g., multimedia) have
tolerate some loss a minimum throughput
  Other apps (e.g., file to be “effective”
transfer, telnet) require   other applications
100% reliability (“elastic apps”) make
  Timing use of whatever
throughput they get
  Some applications
(e.g., IP phones,   Security
interactive games)   Encryption, data
require low delay to be integrity, …
“effective”

Copyright © University of Illinois CS 241 Staff 37

Internet Transport Protocols
TCP UDP
  Connection-oriented   Unreliable data transfer
  setup required between
  Does not provide
client and server
  Connection setup,
  Reliable transport
reliability, flow control,
  Flow control congestion control, timing,
  Won’t overwhelm receiver throughput guarantee, or
  Congestion control security
  Won’t overwhelm network
  Does not provide   Question
  Timing, throughput
  Why bother? Why is
guarantees, security
there a UDP?

Copyright © University of Illinois CS 241 Staff 38