[Home Page - Introduction to Computer Network](/@roger61205/Introduction-to-Computer-Network)
[Home Page - Operating System]()
[toc]
# Notes
## Principles of Network Applications
### Creating a Network App
To write a network app, there is no need to write software for network-core devices, it is only needed to be written a program running on end systems and is able to communicate over the network.
1. Data Integrity
2. Timing
3. Throughput
4. Security
### Computer Network Architecture
#### Client-Server Architecture
In client-server architecture, the central computer acts as a server.
1. Introductions
1. Servers
1. are always on-host.
2. have permanent IP address.
3. are often in data centers.
2. Clients
1. communitate with server.
2. may be intermittently connected.
3. may have dynamic IP addresses.
4. do not communicate directly with one another.
2. File Distribution Time
How much time to distribute file (size F) from one server to N peers?
1. Server Transmission
* Time to send one copy: $\frac{F}{u_s}$
* Time to send $N$ files: $\frac{NF}{u_s}$
2. Client
Let $d_{min}$ be client download rate, client download time is $\frac{F}{d_{min}}$

Time to distribute F to N clients using client-server approach $D_{c-s}\geq max(\frac{NF}{u_s},\frac{F}{d_{min}})$
#### Peer-Peer Architecture
In peer-peer architecture, computers are connected to each others, and there is no central computer.
1. Introductions
1. Peers are intermittently connected and change IP addresses.
2. Peers request service from other peers or provide service in return to other peers.
3. Arbitrary end systems directly communicate with one another.
4. There is no always-on server.
5. New peers bring new service capacity, and new service demands.
2. File Distribution Time
How much time to distribute file (size F) from one server to N peers?
1. Server Transmission
Time to send one copy: $\frac{F}{u_s}$
2. Client
Each client must download file copy in $\frac{F}{d_{min}}$
3. Clients
As aggregate must download NF bits in max upload rate $u_s+\sum u_i$

Time to distribute F to N clients using P2P approach: $D_{P2P}\geq max(\frac{F}{u_s},\frac{F}{d_{min}},\frac{NF}{u_s+\sum u_i})$
### Processes Communicating
#### Client Process and Server Process
1. Client Process: process that initiates communication.
2. Server Process: process that waits to be contacted.
:::info
Applications in P2P architectures have client processes & server processes.
:::
#### Processes Communicating within Same Host and in Different Host
1. Processes within Same Host
Two processes communicate using inter-process communication (defined by OS).
2. Processes in different hosts
Processes in different hosts communicate by exchanging messages.
* Sockets
Process sends/receives messages to/from its socket.
#### Addressing Processes
To receive messages, process must have identifier. Identifier includes both unique 32-bit IP address and port numbers associated with process on host.
### Application-Layer Protocols
1. Types of messages exchanging
2. Message Syntax define what fields in messages and how fields are delineated.
3. Message semantics define meaning of information in fields
4. Rules define for when and how processes send and respond to messages
5. Open Protocols
Open protocols are defined in RFCs which means everyone has access to protocol definition.
### Content Distribution Networks (CDNs)
To stream contents to hundreds of thousands of simultaneous users, we store/serve multiple copies of videos at multiple geographically distributed sites.
### Internet Transport Protocols Services
#### TCP
1. Reliable transport between sending and receiving process
2. Flow Control
3. Congestion Control
4. Connection Orientation
5. No Provide of Timing, Minimum Throughput Guarantee, Security
#### UDP
1. Unreliable data transfer between sending and receiving process
2. No Provide of Reliability, Flow Control, Congestion Control, Timing, Throughput Guarantee, Security, Connection Setup.
## Applications
### Web and HTTP
#### What is HTTP?
1. Web page consists of objects, each of which can be stored on different Web servers. Object can be HTML file, JPEG image, Java applet, audio file, etc. .
2. Hypertext Transfer Protocol (HTTP)
HTTP is a web’s application-layer protocol.
1. HTTP uses TCP
1. Step 1: Client initiates TCP connection (creates socket) to server, port `80`.
2. Step 2: Server accepts TCP connection from client.
3. Step 3: HTTP messages (application-layer protocol messages) exchange between browser (HTTP client) and Web server (HTTP server).
4. Step 4: TCP connection close.
2. HTTP is stateless which means that server maintains no information about past client requests.
:::info
* Stateful Protocol
:::
#### HTTP Connections
1. Non-Persistent HTTP
1. Procedure
1. Step 1: TCP connection opens.
2. Step 2: At most one object sends over TCP connection
3. Step 3: TCP connection closes.
2. Respond Time
1. One $RTT$ to initiate TCP connection
2. One $RTT$ for HTTP request and first few bytes of HTTP response to return
3. Object/file transmission time
* $RTT$: Time for a small packet to travel from client to server and back.
3. Properties
1. It requires 2 $RTT$s per object
2. Browsers often open multiple parallel TCP connections to fetch referenced objects in parallel
3. OS overheads for each TCP connection
2. Persistent HTTP
1. Procedure
1. Step 1: TCP connection opens to a server.
2. Step 2: Multiple objects can be sent over single TCP connection between client, and that server.
3. Step 3: TCP connection closes.
2. Respond Time
3. Properties
1. Server leaves connection open after sending response.
2. Subsequent HTTP messages between same client/server are sent over open connection.
3. Client sends requests as soon as it encounters a referenced object.
4. As little as one $RTT$ is required for all the referenced objects.
#### HTTP Messages
1. Request Messages
1. POST Method:
**English**
Users' inputs are sent from client to server in entity body of HTTP POST request message.
1. POST requests are never cached.
2. POST requests do not remain in the browser history.
3. POST requests cannot be bookmarked.
4. POST requests have no restrictions on data length.

**中文**
POST 方法用於提交指定資源的實體，通常會改變伺服器的狀態或副作用。
2. GET Method:
**English**
It includes user data in URL field of HTTP GET request message.
1. GET requests can be cached.
2. GET requests remain in the browser history.
3. GET requests can be bookmarked.
4. GET requests should never be used when dealing with sensitive data.
5. GET requests have length restrictions.
6. GET requests should be used only to retrieve data.

**中文**
GET 方法請求展示指定資源。使用 GET 的請求只應用於取得資料。
:::info
* Conditional GET
We intend not to send object if cache has up-to-date cached version.
:::
3. HEAD Method:
**English**
It requests headers (only) that would be returned if specified URL were requested with an HTTP GET method.

**中文**
HEAD 方法請求與 GET 方法相同的回應，但它沒有回應主體（response body）。
4. PUT Method:
**English**
It uploads new file (object) to server and completely replaces file that exists at specified URL with content in entity body of POST HTTP request message.

**中文**
PUT 方法會取代指定資源所酬載請求（request payload）的所有表現。
2. Respond Messages
1. `200`: OK
2. `301`: Moved Permanently
Requested object has been moved, new location specified later in this message (in Location: field)
3. `304`: Not Modified
4. `400`: Bad Request
Requested message was not understood by server
5. `404`: Not Found
Requested document was not found on this server
6. `505`: HTTP Version Not Supported
#### Cookies
Web sites and client browser use cookies to maintain states between transactions.
:::info
:::
1. Four Components
1. Cookie header line of HTTP response message
2. Cookie header line in next HTTP request message
3. Cookie file kept on user’s host, managed by user’s browser
4. Back-end database at Web site
2. What cookies can be used for?
1. Authorization
2. Shopping Carts
3. Recommendations
4. User Session State (Web e-mail)
3. How to keep state?
1. At protocol endpoints, maintain state at sender/receiver over multiple transactions
2. In messages, cookies in HTTP messages carry state
#### Web Caches
This technique satisfies client requests without involving origin server.
1. Hit Rate
Browser sends all HTTP requests to cache.
1. If object in cache, cache returns object to client.
2. Else, cache requests object from origin server, caches received object, then returns object to client.
2. Properties
1. Web cache acts as both client and server
2. Server tells cache about object’s allowable caching in response header
3. Response time for client request is less
4. Traffic on an institution’s access link is less
5. Internet is dense with caches
3. Conditional GET
We intend not to send object if cache has up-to-date cached version.
4. Scenarios
#### Versions of HTTP
1. HTTP1.1
Server responds in-order (FCFS: first-come-first-served scheduling) to GET requests.
1. Small object may have to wait for transmission behind large object(s).
2. Loss recovery (retransmitting lost TCP segments) stalls object transmission
2. HTTP/2
Server divides objects into frames, schedule frames to mitigate HOL blocking.
1. Methods, status codes, most header fields remain unchanged from HTTP 1.1.
2. Transmission order of requested objects is based on client-specified object priority.
3. It pushes unrequested objects to client
4. Recovery from packet loss still stalls all object transmissions
5. No security is guaranteed over vanilla TCP connection
3. HTTP/2 to HTTP/3
HTTP/3 adds security, per object error and congestion-control (more pipelining) over UDP.
### E-mail, SMTP, IMAP
#### Three major components:
1. User Agents (Mail Reader)
It help users to compose, edit, read mail messages.
2. Mail Servers
1. A mailbox contains incoming messages for user.
2. Outgoing messages queue.
3. Simple Mail Transfer Protocol (SMTP)
:::info
:::
1. It uses TCP to reliably transfer email message from client. (The port is 25.)
2. Three Phases of Transfer
1. SMTP handshaking (greeting)
2. SMTP transfer of messages
3. SMTP closure
3. Command/Response Interaction (Like HTTP)
1. Commands: ASCII text
2. Response: Status code and phrase
4. Comparison with HTTP
1. Client
1. HTTP: Client pull
2. SMTP: Client push
2. Both have ASCII command/response interaction, status codes.
3. Message
1. HTTP: Each object is encapsulated in its own response message
2. SMTP: Multiple objects are sent in multipart message
4. SMTP uses persistent connections
5. SMTP requires message (header & body) to be in 7-bit ASCII
6. SMTP server uses CRLF to determine end of message
#### Mail Message Format
#### Sinarios
1. Sending
:::info
:::
2. Retrieving
:::info
:::
1. SMTP: Delivery/Storage of e-mail messages to receiver’s server
2. Internet Mail Access Protocol (RFC 3501) (IMAP)
1. Messages are stored on server. IMAP provides retrieval, deletion, folders of stored messages on server.
2. IMAP is a pull protocol.
3. HTTP
It provides web-based interface on top of STMP (to send), IMAP (or POP) to retrieve e-mail messages
### Domain Name System (DNS)
#### Services
1. Hostname-to-IP-Address Translation
2. Host Aliasing
3. Mail Server Aliasing
4. Load Distribution (many IP addresses correspond to one name)
#### Properties
1. Distributed databases are implemented in hierarchy of many name servers.
2. Application-Layer Protocol
Hosts, DNS servers communicate to resolve names (address/name translation)
3. It is more complex at network’s edge.
4. Why don't centralize DNS?
1. Single Point of Failure
2. Traffic Volume
3. Distant Centralized Database
4. Maintenance
5. ICANN (Internet Corporation for Assigned Names and Numbers) manages root DNS domain
6. When host makes DNS query, it is sent to its local DNS server, and local DNS server doesn’t strictly belong to hierarchy.
7. DNS is mainly transported by UDP. (There is also a probability that DNS is transported by TCP.)
#### DNS Name Resolution
1. Iterative Query
:::info
:::
2. Recursive Query
:::info
:::
#### Caching DNS Information
1. Cached entries may be out-of-date
2. Caching improves response time
3. Cached entries timeout (disappear) after some time (TTL)
4. TLD servers are typically cached in local name servers
#### DNS Records

(name, value, type, ttl)

1. `A` Type
1. `name`: Hostname
2. `value`: IP address
2. `NS` Type
1. `name`: Domain
2. `value`: Hostname of authoritative name server for this domain
3. `CNAME` Type
1. `name`: Alias name for som canonical name
2. `value`: Canonical name
4. `MX` Type
* `value`: Name of SMTP mail server associated with `name`
#### DNS protocol Messages
#### DNS security
1. DDoS attacks
It bombards root servers with traffic
2. Spoofing attacks
It intercepts DNS queries, returning bogus replies.
### BitTorrent
:::info
:::
1. A file will be divided into $256[Kb]$ chunks.
2. Peers in torrent send/receive file chunks.
3. Peer first joining torrent has no chunks, but will accumulate them over time from other peers and registers with tracker to get list of peers, connects to subset of peers (“neighbors”).
4. While downloading, peer uploads chunks to other peers.
5. Peer may change peers with whom it exchanges chunks.
6. Peers may come to and go out of chunks.
7. Once peer has entire file, it may leave or remain in torrent.
#### Requesting and Sending File Chunks
1. Requesting
1. At any given time, different peers have different subsets of file chunks.
2. Periodically, a user asks each peer for list of chunks that they have.
3. A user requests missing chunks from peers, rarest first.
2. Sending
1. A user sends chunks to those four peers currently sending her chunks at highest rate, and other peers are choked by a user (do not receive chunks from her).
2. Top 4 is re-evaluated every $10[sec]$
3. Every $30[sec]$ another peer is randomly selected, starts sending chunks, and the newly chosen peer may join top 4.
### Video Streaming
Streaming video = encoding + DASH + playout buffering
#### Coding
1. CBR (Constant Bit Rate): Video encoding rate is fixed.
2. VBR (Variable Bit Rate): Video encoding rate changes as amount of spatial, temporal coding changes
#### Sreaming
1. Dynamic, Adaptive Streaming over HTTP (DASH)
1. Server
1. A video file is devided into multiple chunks.
2. Each chunk is encoded at multiple different rates
3. Different rate encodings are stored in different files
4. Files are replicated in various CDN nodes
5. Manifest file provides URLs for different chunks
2. Client
1. Clients periodically estimate server-to-client bandwidth.
2. Consulting manifest, clients requests one chunk at a time.
1. Clients choose maximum coding rate sustainable given current bandwidth.
2. Clients can choose different coding rates at different points in time (depending on available bandwidth at time), and from different servers.
3. Clients determine
1. when to request chunk (so that buffer starvation, or overflow does not occur)
2. what encoding rate to request (higher quality when more bandwidth available)
3. where to request chunk (can request from URL server that is “close” to client or has high available bandwidth)
#### Client-Side Buffering and Playout Delay
1. Server-to-client bandwidth varies over time, with changing network congestion levels (in house, access network, network core, video server).
2. Packet loss, delay due to congestion delay playout, or result in poor video quality.

Using client-side buffering and playout delay can imporve these problem.

# Exercises
## Jim Kurose Homepage - gaia - Interactive End-of-Chapter Exercises - Browser Caching
## Jim Kurose Homepage - gaia - Interactive End-of-Chapter Exercises - DNS and HTTP Delays

**References**
NCKU 1102_F723500 Introduction to Computer Network
Computer Networking: A Top-Down Approach 8th edition Jim Kurose, Keith Ross Pearson, 2020
[P2P: Development Situation and Operation Solutions - ztecommunications](https://www.zte.com.cn/global/about/magazine/zte-communications/2008/2/en_3/162468.html)
[Jim Kurose Homepage - gaia - Interactive End-of-Chapter Exercises - Browser Caching](https://gaia.cs.umass.edu/kurose_ross/interactive/browser_caching.php)
[Jim Kurose Homepage - gaia - Interactive End-of-Chapter Exercises - DNS and HTTP Delays](https://gaia.cs.umass.edu/kurose_ross/interactive/DNS_HTTP_delay.php)