Transcript Lecture 1 Internet - Computer Science & Engineering

Lecture 18 Overview
What is network management?
• autonomous systems (aka “network”)
– 100s or 1000s of interacting hardware/software
components
• "Network management includes the deployment,
integration and coordination of the hardware,
software, and human elements to monitor, test, poll,
configure, analyze, evaluate, and control the network
and element resources to meet the real-time,
operational performance, and Quality of Service
requirements at a reasonable cost.“
CPE 401/601 Lecture 18 : Network Management
Infrastructure for network management
managing entity
agent data
managing
data
entity
network
management
protocol
managed devices contain
managed device
managed objects whose
data is gathered into a
agent data
Management Information
Base (MIB)
managed device
agent data
agent data
managed device
CPE 401/601 Lecture 18 : Network Management
managed device
Network Management standards
SNMP: Simple Network Management Protocol
• Internet roots
– SGMP: Simple Gateway Monitoring Protocol
• started simple
– deployed, adopted rapidly
• growth: size, complexity
• currently: SNMP V3
• de facto network management standard
CPE 401/601 Lecture 18 : Network Management
SNMP overview: 4 key parts
• Management information base (MIB):
– distributed information store of network
management data
• Structure of Management Information (SMI):
– data definition language for MIB objects
• SNMP protocol
– convey manager<->managed object info,
commands
• security, administration capabilities
– major addition in SNMPv3
CPE 401/601 Lecture 18 : Network Management
Management Information Base
Basic Data Types
• Purpose: syntax, semantics of management
data well-defined, unambiguous
• base data types:
– straightforward
• OBJECT-TYPE
– data type, status, semantics of managed object
• MODULE-IDENTITY
– groups related objects into MIB module
CPE 401/601 Lecture 18 : Network Management
Management Information Base
MIB module specified via SMI
MODULE-IDENTITY
(100 standardized MIBs, more vendor-specific)
MODULE
OBJECT TYPE:
OBJECT TYPE:OBJECT TYPE:
objects specified via SMI
OBJECT-TYPE construct
CPE 401/601 Lecture 18 : Network Management
MIB example: UDP module
Object ID
Name
Type
Comments
1.3.6.1.2.1.7.1
UDPInDatagrams Counter32 total # datagrams delivered
at this node
1.3.6.1.2.1.7.2
UDPNoPorts
Counter32 # underliverable datagrams
no app at portl
1.3.6.1.2.1.7.3
UDInErrors
Counter32 # undeliverable datagrams
all other reasons
1.3.6.1.2.1.7.4
1.3.6.1.2.1.7.5
UDPOutDatagrams Counter32 # datagrams sent
udpTable
SEQUENCE one entry for each port
in use by app, gives port #
and IP address
CPE 401/601 Lecture 18 : Network Management
SNMP Naming
• question: how to name every possible
standard object (protocol, data, more..) in
every possible network standard??
• answer: ISO Object Identifier tree:
– hierarchical naming of all objects
– each branchpoint has name, number
1.3.6.1.2.1.7.1
ISO
ISO-ident. Org.
US DoD
Internet
CPE 401/601 Lecture 18 : Network Management
udpInDatagrams
UDP
MIB2
management
SNMP protocol
• Two ways to convey MIB info, commands:
managing
entity
request
response
agent data
Managed device
request/response mode
CPE 401/601 Lecture 18 : Network Management
managing
entity
trap msg
agent data
Managed device
trap mode
SNMP protocol: message types
Function
Message type
GetRequest
GetNextRequest
GetBulkRequest
Mgr-to-agent: “get me data”
(instance,next in list, block)
InformRequest
SetRequest
Response
Trap
CPE 401/601 Lecture 18 : Network Management
Mgr-to-Mgr: here’s MIB value
Mgr-to-agent: set MIB value
Agent-to-mgr: value, response to
Request
Agent-to-mgr: inform manager
of exceptional event
SNMP security and administration
• encryption: DES-encrypt SNMP message
• authentication: compute, send MIC(m,k):
– compute hash (MIC) over message (m), secret
shared key (k)
• protection against playback: use nonce
• view-based access control
– SNMP entity maintains database of access rights,
policies for various users
– database itself accessible as managed object!
CPE 401/601 Lecture 18 : Network Management
The presentation problem
• Q: does perfect memory-to-memory copy
solve “the communication problem”?
• A: not always!
struct {
char code;
int x;
} test;
test.x = 256;
test.code=‘a’
test.code
test.x
a
00000001
00000011
host 1 format
test.code
test.x
a
00000011
00000001
host 2 format
problem: different data format, storage conventions
CPE 401/601 Lecture 18 : Network Management
Presentation problem: potential solutions
1. Sender learns receiver’s format and translates into
receiver’s format. Sender sends.
2. Sender sends. Receiver learns sender’s format and
translate into receiver-local format
3. Sender translates host-independent format and
sends. Receiver translates to receiver-local format.
CPE 401/601 Lecture 18 : Network Management
ASN.1: Abstract Syntax Notation 1
• ISO standard X.680
– used extensively in Internet
• defined data types, object constructors
– like SMI
• BER: Basic Encoding Rules
– specify how ASN.1-defined data objects to be
transmitted
– each transmitted object has Type, Length, Value
(TLV) encoding
CPE 401/601 Lecture 18 : Network Management
TLV Encoding
• Idea: transmitted data is self-identifying
– T: data type, one of ASN.1-defined types
– L: length of data in bytes
– V: value of data, encoded according to ASN.1
standard
Tag Value
1
2
3
4
5
6
9
CPE 401/601 Lecture 18 : Network Management
Type
Boolean
Integer
Bitstring
Octet string
Null
Object Identifier
Real
Network Management
• network management
– extremely important: 80% of network “cost”
– ASN.1 for data description
– SNMP protocol as a tool for conveying information
• Network management: more art than science
– what to measure/monitor
– how to respond to failures?
– alarm correlation/filtering?
CPE 401/601 Lecture 18 : Network Management
Lecture 19
Hyper Text Transfer Protocol
CPE 401 / 601
Computer Network Systems
slides
modified
from
Dave
Hollinger
slides
are are
modified
from
Dave
Hollinger
Hyper Text Transfer Protocol
• HTTP is the protocol that supports
communication between web browsers and
web servers.
• A “Web Server” is a HTTP server
• Most clients/servers today speak version 1.1,
but 1.0 is also in use.
– RFC 1945 (HTTP 1.0)
– RFC 2616 (HTTP 1.1)
HTTP
19
From the RFC
• “HTTP is an application-level protocol with the
lightness and speed necessary for distributed,
hypermedia information systems.”
• Transport Independence
– The HTTP protocol generally takes place over a
TCP connection,
– but the protocol itself is not dependent on a
specific transport layer.
HTTP
20
HTTP overview
• Web’s application layer
protocol
• client/server model
– client: browser that
requests, receives,
“displays” Web objects
– server: Web server
sends objects in
response to requests
PC running
Explorer
Server
running
Apache Web
server
Mac running
Navigator
21
Request - Response
• HTTP has a simple structure:
– client sends a request
– server returns a reply
• HTTP can support multiple request-reply
exchanges over a single TCP connection
• The “well known” TCP port for HTTP servers is
port 80
– Other ports can be used as well
HTTP
22
HTTP connections
• HTTP is “stateless”
– server maintains no information about past client
requests
• Nonpersistent HTTP
– At most one object is sent over a TCP connection
• Persistent HTTP
– Multiple objects can be sent over single TCP
connection between client and server
23
HTTP 1.0+ Request
• Lines of text (ASCII)
• Lines end with CRLF “\r\n”
• First line is called “Request-Line”
Request-Line
Headers
.
.
.
blank line
Content...
HTTP
24
Request Line
• Method URI HTTP-Version\r\n
• The request line contains 3 tokens (words)
• space characters “ ” separate the tokens
• Newline (\n) seems to work by itself
– but the protocol requires CRLF
HTTP
25
HTTP Version Number
• Starting with HTTP 1.0 the version number is
part of every request
– Client tells the server what version it can talk
• what options are supported, etc
• HTTP 0.9 did not include a version number in
a request line
– If a server gets a request line with no HTTP version
number, it assumes 0.9
– HTTP 0.9 was used for many years
HTTP
26
URI: Universal Resource Identifier
• URIs defined in RFC 2396
• Absolute URI:
– scheme://hostname[:port]/path
– http://www.cse.unr.edu:80/~mgunes/cpe401
• Relative URI:
– /path
– /blah/foo
HTTP
No server mentioned
27
URI Usage
• When dealing with a HTTP 1.1 server, only a
path is used (no scheme or hostname)
– HTTP 1.1 servers are required to be capable of
handling an absolute URI
• but there are still some out there that won’t
• When dealing with a proxy HTTP server, an
absolute URI is used
– client has to tell the proxy where to get the
document!
HTTP
28
Request Method
• The Request Method can be:
GET
PUT
HEAD
POST
DELETE
TRACE
OPTIONS
• future expansion is supported
• GET, HEAD and POST are supported
everywhere
• HTTP 1.1 servers often support PUT, DELETE,
OPTIONS & TRACE
HTTP
29
Methods
• GET: retrieve information identified by the URI
– Typically used to retrieve an HTML document
• HEAD: retrieve meta-information about the
URI
– used to find out if a document has changed
• POST: send information to a URI and retrieve
result
– used to submit a form
HTTP
30
More Methods
• PUT: Store information in location named by
URI
• DELETE: remove entity identified by URI
• TRACE: used to trace HTTP forwarding
through proxies, tunnels, etc
• OPTIONS: used to determine capabilities of
server, or characteristics of a named resource
HTTP
31
The Header Lines
• Request Headers provide information to the
server about the client
– what kind of client
– what kind of content will be accepted
– who is making the request
• Each header line contains
– an attribute name followed by a “:” followed by a
space and the attribute value
• There can be 0 headers (HTTP 1.0)
– HTTP 1.1 requires a Host: header
HTTP
32
Example HTTP Headers
Accept: text/html
Host: www.cse.unr.edu
From: [email protected]
User-Agent: Mozilla/4.0
Referer: http://www.unr.edu/
HTTP
33
End of the Headers
• Each header ends with a CRLF ( \r\n )
• The end of the header section is marked with
a blank line
– just CRLF
• For GET and HEAD requests, the end of the
headers is the end of the request!
HTTP
34
HTTP request message format
35
POST
• A POST request includes some content (some
data) after the headers
– after the blank line
• There is no format for the data
– just raw bytes
• A POST request must include a ContentLength line in the headers:
– Content-length: 267
HTTP
36
Example POST Request
POST /~mgunes/grades.cgi HTTP/1.1
Accept: */*
Host: www.cse.unr.edu
User-Agent: SecretAgent V2.3
Content-Length: 35
Referer: http://www.unr.edu/
stuid=6660182722&item=test1&grade=99
HTTP
37
Example GET Request
GET /~mgunes/cpe401/lab3.htm HTTP/1.1
Accept: */*
Host: www.cse.unr.edu
User-Agent: Internet Explorer
From: [email protected]
Referer: http://www.unr.edu/
There is a blank line here!
HTTP
38
HTTP Response
• ASCII Status Line
• Headers Section
Status-Line
Headers
.
.
.
blank line
Content...
• Content can be anything
– not just text
– typically an HTML document or some kind of
image
HTTP
39
Response Status Line
• HTTP-Version Status-Code Message
• Status Code is 3 digit number (for computers)
– 1xx
– 2xx
– 3xx
– 4xx
– 5xx
Informational
Success
Redirection
Client Error
Server Error
• Message is text (for humans)
HTTP
40
Example Status Lines
• HTTP/1.0 200 OK
• HTTP/1.0 301 Moved Permanently
• HTTP/1.0 400 Bad Request
• HTTP/1.0 500 Internal Server Error
HTTP
41
Response Headers
• Provide the client with information about the
returned entity (document)
– what kind of document
– how big the document is
– how the document is encoded
– when the document was last modified
• Response headers end with blank line
HTTP
42
Response Header Examples
Date: Wed, 30 Mar 2010 12:48:17 EST
Server: Apache/1.17
Content-Type: text/html
Content-Length: 1756
Content-Encoding: gzip
HTTP
43
Content
• Content can be anything
– sequence of raw bytes
• Content-Length header is required for any
response that includes content
• Content-Type header also required
HTTP
44
Single Request/Reply
• The client sends a complete request
• The server sends back the entire reply
• The server closes it’s socket
• If the client needs another document it must
open a new connection
This was the default for HTTP 1.0
HTTP
45
Persistent Connections
• HTTP 1.1 supports persistent connections
– this is the default
• Multiple requests can be handled over a single
TCP connection
• The Connection: header is used to exchange
information about persistence (HTTP/1.1)
• 1.0 Clients used a Keep-alive: header
HTTP
46
Non-Persistent HTTP: Response time
• RTT: time for a small packet to
travel from client to server and
back
initiate TCP
connection
• Response time:
RTT
– one RTT to initiate TCP
connection
– one RTT for HTTP request and
first few bytes of HTTP response
to return
– file transmission time
request
file
time to
transmit
file
RTT
file
received
time
time
• total = 2RTT+transmit time
47
Try it with telnet
> telnet www.cse.unr.edu 80
GET / HTTP/1.0
HTTP/1.0 200 OK
Server: Apache
...
HTTP
48
Try it with telnet (persistent)
> telnet www.cse.unr.edu 80
GET / HTTP/1.1
Host: www.cse.unr.edu
HTTP/1.0 200 OK
Server: Apache
...
HTTP
49
User-server state: cookies
• Four components:
– 1) cookie header line of HTTP response message
– 2) cookie header line in HTTP request message
– 3) cookie file kept on user’s host, managed by
user’s browser
– 4) back-end database at Web site
• Cookies and privacy:
– cookies permit sites to learn a lot about you
– you may supply name and e-mail to sites
50
User-server state: cookies
Example:
• Susan always access Internet always from PC
• visits specific e-commerce site for first time
• when initial HTTP requests arrives at site, site
creates:
– unique ID
– entry in backend database for ID
51
Cookies: keeping “state”
client
ebay 8734
cookie file
server
usual http request msg
usual http response
Set-cookie: 1678
ebay 8734
amazon 1678
usual http request msg
cookie: 1678
one week later:
usual http response msg
Amazon server
creates ID
1678 for user create
entry
cookiespecific
action
access
access
ebay 8734
amazon 1678
backend
database
usual http request msg
cookie: 1678
usual http response msg
cookiespectific
action
52
Cookies (continued)
• What cookies can bring:
– authorization
– shopping carts
– recommendations
– user session state (Web e-mail)
• How to keep “state”:
– protocol endpoints: maintain state at
sender/receiver over multiple transactions
– cookies: http messages carry state
53
Web caches (proxy server)
Goal: satisfy client request without involving origin server
• user sets browser: Web
accesses via cache
• browser sends all HTTP
requests to cache
– object in cache: cache
returns object
– else cache requests
object from origin server,
then returns object to
client
origin
server
Proxy
server
client
client
origin
server
54
More about Web caching
• cache acts as both client and server
• typically cache is installed by ISP
– university, company, residential ISP
Why Web caching?
• reduce response time for client request
• reduce traffic on an institution’s access link.
• Internet dense with caches: enables “poor”
content providers to effectively deliver
content (but so does P2P file sharing)
55
Caching example
origin
servers
• Assumptions
– average object size = 1,000,000 bits
– avg. request rate from institution’s
browsers to origin servers = 15/sec
– delay from institutional router to
any origin server and back to router
= 2 sec
• Consequences
– utilization on LAN = 15%
– utilization on access link = 100%
– total delay = Internet delay +
access delay + LAN delay
– = 2 sec + minutes + milliseconds
public
Internet
15 Mbps
access link
institutional
network
100 Mbps LAN
institutional
cache
56
Caching example (cont)
origin
servers
• possible solution
– increase bandwidth of access
link to, say, 100 Mbps
public
Internet
• consequence
– utilization on LAN = 15%
– utilization on access link = 15%
– Total delay = Internet delay +
access delay + LAN delay
– = 2 sec + msecs + msecs
– often a costly upgrade
100 Mbps
access link
institutional
network
100 Mbps LAN
institutional
cache
57
Caching example (cont)
origin
servers
• possible solution: install cache
– suppose hit rate is 0.4
public
Internet
• consequence
– 40% requests will be satisfied almost
immediately
– 60% requests satisfied by origin
server
– utilization of access link reduced to
60%, resulting in negligible delays
(say 10 msec)
– total avg delay = Internet delay +
access delay + LAN delay = .6*(2.01)
secs + .4*milliseconds < 1.4 secs
15 Mbps
access link
institutional
network
100 Mbps LAN
institutional
cache
58
Conditional GET
• Goal: don’t send object ifcache
cache has up-to-date
cached version
• cache: specify date of
cached copy in HTTP
request
– If-modified-since: <date>
• server: response contains
no object if cached copy is
up-to-date:
server
HTTP request msg
If-modified-since:
<date>
HTTP response
object
not
modified
HTTP/1.0
304 Not Modified
HTTP request msg
If-modified-since:
<date>
– HTTP/1.0 304 Not Modified
object
modified
HTTP response
HTTP/1.0 200 OK
<data>
59