Please enable JavaScript.
Coggle requires JavaScript to display documents.
Networking Chapter 2 - Application Layer (DNS (Hierarchy (Root DNS servers…
Networking Chapter 2 - Application Layer
Principles
Architectures
P2P
self scalability
: New
peers bring new service
capacity, as well as new
service demands
IPC
server process
: process that
waits to be contacted
client process
: process that initiates communication
Sockets
process sends/receives messages to/from its socket
sending process relies on transport infrastructure on other side of door to deliver message to socket at receiving process
Addressing
Each process has a
port
and
ip address
associated with it
Required Transport Services
Data Integrity
: Some programs need files to download 100% perfectly, others don't
Timing
: Some apps Need very little delay to be effective
Throughput
: Some apps require minimum amount of throughput, others don't (elastic)
Security
: Encryption, etc.
Main transfer protocols
TCP
Reliable transport, flow control (sender won't overwhelm receiver), congestion control (throttle sender when network overloaded), doesn't provide any transport service except data integrity, and is connection oriented (setup btw client and server)
SSL
Encryption on TCP, done at application layer, apps use SSL libraries to talk to TCP and do stuff
cleartext passwords sent into socket traverse Internet encrypted
UDP
unreliable, doesn't provide anything TCP provides
Web/HTTP
Basics
Web page consists of objects (HTML file, JPEG, etc.)
Base HTML file which includes referenced objects
Host name
= everything after http:// and before first /
Path name
= everything after first slash in host name
HTTP
Uses TCP, client initiates TCP connection to server's port 80
Stateless
, no info maintained about past requests by server
Two connection types
non-persistent (HTTP 1.0)
: At most one object sent over TCP connection, then closed, required multiple connections for multiple objects
Process: client initiates TCP connection -> server checks and responds back saying it's listening -> client sends HTTP message in TCP socket -> server reads message and responds -> server closes TCP connection -> client receives data.
Repeats per object
Round Trip TIme (RTT)
: Time for small packet to travel from client->server and back
Total time: initiate TCP connection (1 RTT) + HTTP request and part of response (1 RTT) + file transmission time =
2RTT + file transmission time
persistent (HTTP 1.1)
: Multiple objects over single TCP connection
As little as
1 RTT +
file transmission time
per object
messages: requests and responses
request
request method, the path name, and HTTP version, then headers, then the raw data for body
GET, POST, HEAD, PUT DELETE, URL methods
response
HTTP version, response status, then headers, then body
Response status: 200 OK, 301 Moved Permanently (new location later in message), 400 Bad Request (not understood by server), 404 Not Found, 505 HTTP Version Not Supported
HTTP/2
Supports binary data, not backwards compatible
HTTP 1.1 headers put in HTTP/2 headers frame, HTTP 1.1 body in HTTP 2.0 body frame
Compresses header frame with
implicit parameters
, by removing unnecessary things like host, accept, etc. from headers
Break HTTP messages into independent frames, interleave them, then reassemble them on the other end, can do this for multiple requests/responses in parallel
PUSH streams
PUSH_PROMISE
frames, server pushes additional files to client like js/css which the client can cache, and can decline future PUSH_PROMISE frames with
RST_STREAM
frame
Cookies: Used to hold state
set-cookie
comes in HTTP response from server, client's browser and server's database saves it, client sends the
cookie
in the next HTTP request, server sends data based on cookie
Proxies/web caches: Client sends all requests to proxy server, proxy server sends request to destination if response isn't cached, then sends response back to client
Can reduce response time if connection between client and server is weak
REVIEW THIS
Email & SMTP
user agents (Outlook, Gmail web client, etc.), mail servers (mailbox and message queue), and SMTP protocol (client servers sending emails and "server" servers receiving emails)
TCP, port 25, persistent connection
three phases of transfer:
handshake, transfer of messages, and closure
commands
(ASCII text) and
responses
(status code/phrase) used to interact, messages must be in 7-bit ASCII
Breakdown
Alice uses UA to compose message to
bob@someschool.edu
Alice's UA sends message to her mail server; message placed in message queue
client side of SMTP opens TCP connection with Bob s mail server
SMTP client sends Alice's message over the TCP connection
Bob's mail server places the message in Bob's mailbox
Bob invokes his user agent to read message
Email message format
RFC 822: standard for text message format
Headers have to, from, subject, etc., followed by blank line
Body has ASCII text
RFC: 1341: Multipurpose Internet Mail Extensions
Push protocol
Access Protocols
POP
Two phases
Authorization phase
Client uses user and pass commands, server responds with +OK or -ERR
Transaction Phase
list (list message numbers), retr (retrieve message by number), dele, and quit commands used once authorization phase completed
download and delete mode
: User can't re-read email if client is changed
download and keep
: Copies of messages on different clients
Stateless
IMAP
All messages stored on server, can organize messages in folders, and store state across sessions
HTTP
DNS
Need to map an IP address to a readable URL
Distributed database, used in hierarchy of many name servers
An application-layer protocol, hosts and name servers communicate to resolve names
Not
a centralized service
Hierarchy
Root DNS servers
com DNS servers
google.com
org DNS servers
Client queries root DNS server to get address of
top level domain (TLD) server
in next level, then queries that for the website name->ip address mapping, uses that (iterative version)
Client queries root DNS server, that queries TLD server, that queries authoritative server, and then the address is sent back up the chain to the requesting client (recursive version)
Authoritative DNS server
: Stores name mappings, which the root DNS servers contact
Local DNS server
: Used by every ISP, when client sends DNS query, sent through here and cached before being sent into the hierarchy if cache doesn't exist
Caching
Once any server learns mapping, it's cached, which disappears after a specified time (
TTL
)
TLD servers often cached in local name servers
Cached entries may be out of date, need to notify/update for this
Resource Records (RR)
4 tuple of (name, value, type, ttl)
Types
A: name is hostname, value=ip address
NS: name is domain, value is hostname of authoritative name server for this domain
CNAME: name is
alias
for some
canonical
name, value is canonical name
MX: value is name of mailserver associated with name
Messages
Headers have a 16 bit number for query, flags (query or reply, recursive, etc.), number of Qs, number of As
After that "body" comes with answers and additional info
Inserting records
Create "A" type record for DNS server->address mapping, then a "NS" type record for hostname -> DNS server (why two of them?)
P2P networking
Scales a lot better with many users downloading one file compared to servers in some cases, gets rid of requirement of having a centralized source to download file from
BitTorrent
File divided into 256 Kb chunks, peers in torrent send/receive file chunks
Trackers
: Track peers in swarm
Swarm
: Group of peers exchanging chunks of file
When torrent file or magnet link is given, client goes to the tracker, gets list of peers, and begins exchanging file chunks with a certain subset of peers (
neighbours
)
At any time, every peer has different subset of chunks, user asks for specific chunks from specific users who have them, rarest first
User sends chunks to 4 peers currently sending her chunks at the highest rate (other peers are
choked
), re-evaluate this every 10s, and select random peer every 30s (
optimistically unchoke
)