Chapter 2 - Network

Creating a newtork app
	run on different end system
	communicate over network
	web server software communicates with browser software
	No need to write software for network-core devices

Application architectures:
	Client-server
	P2P (peer-to-peer)
	Hybrid of client-server and P2P

Client-server:
	server:
		always on host
		permanent IP address
		server farms for scaling
	client:
		communicate with server
		maybe intermittently connected
		may have dynamic IP addresses
		do not communicate directly with each other


P2P:
	no always-on server
	arbitrary end systems directly communicate
	peers are intermittently connected and change IP addresses
	Highly scalable but difficult to manage

Hybrid of client-server and P2P:
	Skype: Voice-over-IP
		centralized server: finding address of remote party
		client-client connection (direct, not through server)
	Instant messaging:
		chatting between 2 users: P2P
		centralized service: client presence detection/location

Processes communicating
	same host: 2 processes inter-process communication
	exchanging message

	Client process: process that initiates communication
	Server process: process that waits to be contacted

Sockets:
	process sends/receives messages to/from its socket

Addressing processes:
	to receive messages, process must have identifier
	IP address + port number

App-layer protocol:
	Types of messages exchanged
	Message syntax
	Message semantics
	Rules for when and how processes send and respond to messages

	Public domain protocols: defined in RFCs, allows for interoperability
					HTTP, SMTP, BitTorrent
	Proprietary protocols: Skype, ppstream

Transport services that an app needs:
	Data loss
	Timing
	Throughput
	Security

TCP service:
	connection-oriented
	reliable transport
	flow control
	congestion control
	does not provide: timing, minimum throughput guarantees, security

UDP service:
	unreliable data transfer
	does not provide:
		connection setup
		reliability
		flow control
		congestion control
		timing, throughput guarantee, security

Web and HTTP:
	Wep page consists of objects, base HTML file
	Each objects is addressed by a URL (hostname + pathname)

HTTP: hypertext transfer protocol:
	web's application layer protocol
	client/server model:
		client: browser requests, receives, displays Web objects
		server: Web server sends objects in response to request

	use TCP:
		client initiates TCP connection, create socket, port 80
		server accept TCP connection from client
		HTTP msg exchange between browser (HTTP client) & Web server (HTTP server)
		TCP connection close

	stateless: server maintain no info about past client requests

HTTP connections:
	Nonpersistent HTTP: at most 1 object is sent over a TCP connection
	Persistent HTTP: multiple objects can be sent over single TCP connection

	Nonpersistent HTTP:
		HTTP clients initiates TCP connection to HTTP server
		HTTP server and host wait for TCP connection at port 80, accept connection, notify client
		HTTP client send HTTP request msg into TCP connection socket
		HTTP server receives request msg, form response msg, send msg to socket
		HTTP server close TCP connection
		HTTP client receive response msg contain html file, display html

	Nonpersistent HTTP:
		RTT: time for a small packet to travel from client to server and back
		Response Time:
			one RTT to initiate TCP connection
			one RTT for HTTP request and first few bytes of HTTP response to return
			file transmission time

			total = 2RTT + transmit time

	Persistent HTTP:
		Nonpersistent HTTP:
			require 2 RTT per object
			OS overhead for each TCP connection
			browser open parallel TCP connection to fetch

		Persistent HTTP:
			server leaves connection open after sending response
			subsequent HTTP msg between same client/server sent over open connection
			clent send request as soon as it encounter a reference object
			1 RTT for the reference object

HTTP msg:
	Request msg:
		request line (GET, POST, HEAD)
		header lines
		carriage return, line feed indicate end of msg
	Response msg:
		status line (protocol status code, status phrase)
		header lines
		data (requested HTML file)

POST method:
	include for input
	input is uploaded to server in entity body

URL method:
	use GET method
	input is uploaded in URL field of request line

HTTP 1.0 (GET, POST, HEAD)
HTTP 1.1 (GET, POST, HEAD, PUT, DELETE)

HTTPp response:
	200 OK
	301 Moved Permanently
	400 bad request
	404 not found
	500 http version not supported

User-server state: cookies
	cookie header line of HTTP response msg
	cookie header line in HTTP request msg
	cookie file kept on user host, manage by user browser
	back-end database at Website

	authorization
	recommendations
	user sessions tate
	shopping carts

Web cache (proxy server)
	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 request obj from origin server, then return obj to client

	act as both client and server
	typically installed by ISP

	reduce response time for client request
	reduce traffic on an institution's access link
	Internet dense with caches:
		enables poor content provider to effectively deliver content

Conditional GET:
	dont't send obj if cache has up-to-date cached version
	cache: specify date of cached copy in HTTP request:
		If-modified-since: <data>
	server: response contains no obj if cached copy is up-to-date

FTP:
	transfer file to/from remote host
	client/server model:
		clent: side that initiates transfer (eirther to/from remote)
		server: remote host

	contact FTP server at port 21
	TCP: transport protocol
	client authorize over control connection
	client browser remote directory by sending commands over control connection
	when server receive file transfer command, server open 2nd TCP connection to client
	after transferring, server close data connection

	FTP maintain state: current directiory, earlier authentication

Electronic Mail:
	user agents
	mail servers
	simple mail transfer protocol: SMTP

User agent:
	mail reader
	compse, edit, read mail msg
	outgoing, incoming msg store on server

Mail server:
	mailbox contain incoming msg for user
	msg queue of outgoing (to be sent) mail msg
	SMTP protocol between mail server to send email msg:
		client: sending mail server
		server: receiving mail server

	use TCP (port 25)
	direct transfer (sending server to receiving server)
	3 phases:
		handshaking (greeting)
		transfer of msg
		closure

	command/response interaction:
		commands: ASCII text
		response: status code and phrase

	msg must be in 7-bit ASCII

SMTP:
	persistent connection
	require msg (header + body) in 7-bit ASCII
	use CRLF.CRLF to determine end of msg

	HTTP: pull
	SMTP: push

	both have ASCII command/response, interaction, status code

	HTTP: each obj encapsulate in its own response msg
	SMTP: multiple obj sent in multipart msg

SMTP format:
	header (to, from, subject)
	body (ASCII only)

Mail access protocol:
	SMTP: delivery storage to receiver's server
	POP: Post Office Protocol
	IMAP: Internet Mail Access Protocol
	HTTP: gmail, Hotmail, Yahoo! Mail

POP3 protocol:
	authorization phase:
		client commands: user, pass
		server response
	transaction phase:
		list msg numbers
		retrieve msg by number

POP3: download and delete mode
	cannot reread email if change client
	download and keep copy of msg of different client
	stateless across sessions

IMAP: keep msg in one place: server
	  allow user to organize msg in folder
		keep user state across sessions


DNS: Domain Name System
	distributed database: implement in hierarchy of many name servers
	application-layer protocol:
		host, routers, name servers to communicate to resolve names
		core Internet function
		complexity at network edge

DNS Service:
	hostname to IP address translation
	host aliasing
	mail server aliasing
	load distribution

not centralize DNS:
	single point of failure
	traffic volume
	distance centralized database
	maintenance
	doesn't scale

Root name server:
	contacted by local name server that cant resolve name
	contact authoritative name server if name mapping not known
	gets mapping
	return mapping to local name server

Top-level domain (TLD) server:
	responsible for com, org, net, edu ... and top-country domain (uk, fr, ca, jp)
	Network Solutions maintains server for com TLD
	Educause for edu TLD

Authoritative DNS server
	organization DNS server, providing authoritative hostname to IP mappings for organization server
	can be maintain by organization or service provider

Local name server:
	does not strictly belong to hierarchy
	each ISP has one (default name server)
	when host make DNS query, query is sent to its local DNS server

	Query: Local DNS server
					-> root DNS server
					-> TLD DNS server
					-> authoritative DNS server

	iterated query (local DNS server -> every other)
	recursive query (Below model )

DNS caching and updating records:
	any name server learns mapping, it caches mapping
		cache entries timeout after sometime
		TLD server typically cached in local name server
	update/notify mechanism

DNS protocol msg:
	msg header
		identification (16 bit)
		flags
	questions
	answers
	authority
	additional info