---
# System prepended metadata

title: Mạng máy tính

---

# Mạng máy tính

## Chương 1: Giới thiệu
### 1. Internet là gì?
#### a. Các thành phần:
+ Hàng tỉ thiết bị: smart phone, pc, sever, ...
    + Được gọi là hosts = end systems
    + Chạy các ứng dụng mạng
+ Packet switches: Trung chuyển gói tin (packet)
    + routers, switches
+ Communication links: kết nối trực tiếp giữa hai thiết bị
    + cáp quang, cáp đồng, sóng vô tuyến, vệ tinh
    + độ trao đổi: băng thông (bandwidth)
+ Networks:
    + Là tập hợp gồm các thiết bị: được quản lý bởi cùng 1 tổ chức
![](https://i.imgur.com/Psnb4ND.png)

+ Internet: "network of networks"
    + messages: thông điệp
+ protocol: điều khiển các thông điệp
+ Tiêu chuẩn Internet:
    + RFC: Request for Comments
    + IETF: Internet Engineering Task Force
#### b. Chức năng:
+ Là hạ tầng cung cấp dịch vụ cho ứng dụng mạng
+ Cung cấp giao diện lập trình API (programming interface)

### 2. Protocol là gì?
+ Gồm tập hợp các luật mà hai thực thể muốn trao đổi thông tin với nhau thì phải tuân theo tập hợp luật đó

### 3. Network edges
#### a. Cấu trúc Internet
+ Network edge:
    + hosts: clients, severs
    + severs thường nằm trong data centers
+ Access network, physical media
    + wired, wireless communication links 
+ Networt cores:
    + interconnected routers
    + network of networks
#### b. Access networks and physical media:
+ Edge router: router ở rìa
+ Kết nối end system và edge router:
    + residental access nets
    + institutional .. (school,company)
    + mobile ... (Wifi, 4G/5G)
![](https://i.imgur.com/e6McuvO.png)

##### b.1. Access network: home networks
![](https://i.imgur.com/wjG8gLD.png)
##### b.2. Wireless access networks
![](https://i.imgur.com/17g4VCW.png)
##### b.3. Access network: enterprise networkss
![](https://i.imgur.com/BtCcKVt.png)
#### c. Host:
+ Tốc độ truyền dẫn(transmission rate R)

#### d. Links: Physical media
+ Có dây
    + Twisted pair: Cáp xoắn
    + Coaxial cable: Cáp đồng
    + Fiber optic cable: Các quang
+ Không dây:
    + Wireless radio
    + Radio link types: Wifi, 4G, Bluetooth, sóng vi ba, vệ tinh

### 4. Network core
- **packet-switching**: host chia các thông điệp ở tầng ứng dụng thành các packet
    - mạng sẽ chuyển tiếp (forwards) từ một router này đến router tiếp theo, qua các tuyến đường liên kết từ đầu --> đích
    - ![](https://hackmd.io/_uploads/BkLlwUgD3.png)
- Hai chức năng chính của network-core:
    - Forwarding: local action
    - Routing: global action

#### a. Packet-switching: store-and-forward
- **packet transmission delay**: mất L/R (giây) để vận chuyển một packet có L bit trong một liên kết R bps
- **store and forward**: gói hiện tại phải hoàn toàn đến router trước khi nó có thể được vận chuyển trên 1 liên kết khác
- ![](https://hackmd.io/_uploads/Hy07dIlPh.png)
- **Queueing**: ![](https://hackmd.io/_uploads/HJcBuLlDn.png)

#### b. Circuit switching:
- Nguyên tắc chia nguồn tài nguyên từ điểm đầu đến điểm cuối dành riêng cho cuộc "gọi" giữa nguồn và đích.
    - Trong sơ đồ, mỗi liên kết có bốn mạch.
        - Cuộc gọi sẽ sử dụng mạch thứ hai trên liên kết trên cùng và mạch thứ nhất trên liên kết bên phải.
    - Nguồn tài nguyên được cấp cho riêng cuộc gọi, không chia sẻ.
    - Đảm bảo hiệu suất tương tự như mạch (đảm bảo)
        - Mạch trống nếu không được sử dụng bởi cuộc gọi (không chia sẻ)
    - Thường được sử dụng trong các mạng điện thoại truyền thống.
    - ![](https://hackmd.io/_uploads/rkBIY8ewh.png)

- FDM (Frequency Division Multiplexing):
    - Các tần số quang học hoặc điện từ được chia thành các dải tần số (hẹp).
    - Mỗi cuộc gọi được cấp phát một dải tần số riêng, có thể truyền tại tốc độ tối đa của dải tần số hẹp đó.
    - Các cuộc gọi này có thể tồn tại song song trên cùng một kênh truyền dữ liệu, mỗi cuộc gọi sử dụng một dải tần số khác nhau.
    - FDM thường được sử dụng trong các hệ thống truyền thông quang học hoặc truyền thông không dây, nơi các tín hiệu tương đối đa dạng về tần số được chia sẻ trên một đường truyền duy nhất.
    - ![](https://hackmd.io/_uploads/H1vZsIevn.png)

- TDM (Time Division Multiplexing):
    - Thời gian được chia thành các khe (slots).
    - Mỗi cuộc gọi được cấp phát một hoặc nhiều khe thời gian định kỳ, có thể truyền với tốc độ tối đa của băng tần (rộng) trong khe thời gian của nó.
    - Trong mỗi chu kỳ thời gian, các cuộc gọi sử dụng khe thời gian riêng của mình để truyền dữ liệu.
    - TDM thường được sử dụng trong hệ thống điện thoại kỹ thuật số, nơi các cuộc gọi được chia sẻ trên cùng một đường truyền, nhưng sử dụng các khe thời gian khác nhau để phân chia tài nguyên truyền thông.
    - ![](https://hackmd.io/_uploads/BkbGsUlDh.png)
- ![](https://hackmd.io/_uploads/SyddoLxD2.png)


### 5. Performance: loss, delay, thoughput
#### a. Tại sao mất mát gói tin:
+ Các gói tin được xếp hàng, được đợi trong RAM của router --> khi hết ram, các gói tin tiếp theo sẽ bị drop

### 6. Security
+ Các cách tấn công mạng:
    + Packet interception/sniffing (chặn bắt gói tin): thông qua các môi trường truyền dữ liệu chung (shared Ethernet, WIFI), hacker dùng các phần mềm chặn các gói tin (VD: wideshark...) và đánh cắp nó.
    + Fake identity: giả mạo địa chỉ để đánh cắp thông tin.
    + Denial of Service (DoS): lựa chọn đối tượng, thâm nhập vào hệ thống máy đã bị kiểm soát, liên tục gửi gói tin đến máy chủ --> quá tải
+ Các cách an ninh mạng:
    + Authentication: xác thực người dùng để không bị giả mạo 
    + Confidentiality: mã hoá tin nhắn
    + Integrity checks: chữ kí điện tử để tránh bị can thiệp.
    + Access restriction
    + Firewall  
### 7. Protocol layers, service models:
+ Application --> Transport --> Network --> Link --> Physical
    + Application: Hỗ trợ ứng dụng mạng.  Tầng này quản lý các ứng dụng và dịch vụ được sử dụng trên mạng internet.
        + HTTP, IMAP, SMTP,DNS
    + Transport: Chuyển dữ liệu từ process - process. Tầng này quản lý việc truyền tải dữ liệu giữa các chương trình đang chạy trên hai máy tính kết nối với nhau
        + TCP, UDP
    + Network: Định hướng các gói dữ liệu từ nguồn đến đích. Tầng này quản lý việc truyền tải dữ liệu giữa các mạng khác nhau.
        + IP, routing protocol
    + Link: Chuyển dữ liệu giữa hai phần tử mạng gần nhau. Tầng này quản lý việc truyền tải dữ liệu giữa hai máy tính kết nối với nhau trong cùng một mạng. 
    + Physical: Nhiệm vụ của tầng này là chuyển đổi tín hiệu từ dạng số sang dạng vật lý và ngược lại để các máy tính và thiết bị mạng có thể giao tiếp với nhau.
## Chương 2: Application Layer (Lớp ứng dụng)

### 1. Mô hình clients - sever
#### - Sever:
+ Luôn luôn bật
+ Địa chỉ IP cố định
+ Thường ở trung tâm dữ liệu 

#### - Clients:
+ Giao tiếp với sever
+ Không cần kết nối liên tục
+ Có địa chỉ IP linh động
+ Giao tiếp gián tiếp với các clients khác
+ VD: HTTP, IMAP (Mail), FTP, ...

### 2. Mô hình peers-to-peers
+ Không có máy chủ luôn bật
+ Các end systems đều có thể liên kết được với nhau
+ Peers yêu cầu dịch vụ đến peers khác, cung cấp dịch vụ ngược trở lại cho peers khác
    - Khả năng tự mở rộng: Peers mới đem sự phục vụ mới, cũng như nhu cầu về dịch vụ
+ Peers kết nối không liên tục và thay đổi địa chỉ IP
+ VD: P2P file sharing

### 3. Processes communicating (Tiến trình giao tiếp)
#### **process:** Chương trình chạy trong host
+ 2 tiến trình giao tiếp trong cùng 1 host sử dụng inter-process communication (do OS - Hệ điều hành)
+ Tiến trình ở các host khác nhau giao tiếp bằng các trao đổi tin nhắn

#### **clients, severs**
+ client process: tiến trình bắt đầu giao tiếp (gửi tin nhắn)
+ sever process: tiến trình đợi được liên lạc (nhận tin nhắn)

**Note:** Ứng dụng với kiến trúc p2p có cả client, sever process

### 4. Sockets
+ Tiến trình gửi/nhận tin nhắn từ sockets của chính nó
+ Socket giống cánh cửa
    + Tiến trình gửi --> Đưa tin nhắn ra khỏi cửa
    + Tiến trình nhận: Tiến trình gửi dựa vào đường đi ở phía bên kia cánh cửa để vận chuyển tin nhắn
+ 2 socket cùng tham gia: Mỗi cái ở 1 bên

### 5. Addressing processes 
+ Để nhận tin nhắn, tiến trình phải có **identifier (định danh)**
+ Các host đều có một địa chỉ IP dài 32 bit, là duy nhất
+ **identifier** gồm cả địa chỉ IP và số hiệu cổng (port number) liên kết với tiến trình trên host
+ Liệu địa chỉ IP của host mà process đang chạy không đủ để xác định tiến trình, vì có nhiều tiến trình có thể chạy trên cùng 1 host

### 6. App-layer protocol defines:
+ Các kiểu thông điệp được trao đổi: request, response
+ Cú pháp thông điệp
+ Ý nghĩa thông điệp
+ Quy tắc về thời điểm, cách thức các tiến trình gửi và phản hồi

#### **open protocols:** Giao thức công hữu
+ Được định nghĩa ở RFCs
+ Cho phép phối hợp làm việc: HTTP, SMTP, ...

#### **proprietary protocols:** Giao thức tư hữu
+ Skype, Zoom

### 7. Transport service (an app need)
#### a. Toàn vẹn dữ liệu (Dataloss):
+ Một số ứng dụng (audio) có thể chấp nhận mất dữ liệu
+ Các ứng dụng khác(file transfer, telnet) đòi hỏi dữ liệu chính xác tuyệt đối

#### b. Kịp thời(Time sensitive):
+ Một số ứng dụng (Internet telephony, ...) đòi hỏi độ trễ ở mức chấp nhận được

#### c. Băng thông (Throughput):
+ Vài ứng dụng (multimedia) cần băng thông tối thiểu để đạt hiệu quả
+ Các ứng dụng khác ("elastic apps") có thể thích nghi với băng thông hiện có (email, truyền file, ...)

#### d. An toàn:
+ Mã hóa, toàn vẹn dữ liệu,...

![](https://i.imgur.com/DJjdLi4.png)

### 8. Internet transport protocols services:
#### a. TCP service (Transmission Control Protocol)
+ connection-oriented: cần quá trình thiết lập kết nối "handshake" giữa tiến trình client và sever
+ reliable transport: Vận chuyển đảm bảo giữa hai tiến trình chuyển và nhận
    + Đúng nội dung, ko mất, trùng gói tin
    + Đúng thứ tự
+ flow control: bên gửi ko gửi quá nhanh, làm tràn dữ liệu bên nhận
+ congestion control: điều tiết tốc độ gửi dữ liệu khi mạng quá tải
+ does not provide (không đảm bảo): tính kịp thời, băng thông tối thiểu, an ninh 
#### b. UDP service (User Datagram Protocol)
+ Vận chuyển thường (ko bảo đảm) giữa các tiến trình gửi và nhận
+ Ko đảm bảo: quá trình thiết lập thông số, vận chuyển đảm bảo, flow control, congestion control, kịp thời, bảo đảm băng thông tối thiểu, an ninh
+ VD:
![](https://i.imgur.com/kxAWikm.png)

### 9. Securing TCP:
#### a. Vanilla TCP & UDP sockets:
+ Không mã hóa
+ Mật khẩu gốc gửi vào Internet đi qua socket ở dạng văn bản gốc.

#### b. Transport Layer Security (TLS)
+ Cung cấp kết nối TCP được mã hóa
+ Toàn vẹn dữ liệu
+ Xác thực tại điểm cuối


### 10. Web và HTTP:
- Một trang web gồm nhiều thực thể (objects) được lưu trong nhiều web sever khác nhau
- Object gồm file HTML, ảnh JPEG, ....
- Web page gồm **base HTML-file** mà chứa một vài **referenced objects**:
![](https://i.imgur.com/0dQkWly.png)

#### a. Overview
- HTTP: **hypertext transfer protocol**
- Web’s application-layer protocol
- Mô hình client/sever:
    - client: trình duyệt yêu cầu, nhận, (SD giao thức HTTP), và hiển thị Web objects
    - sever: Web sever gửi (SD HTTP) objects để phản hồi yêu cầu
- HTTP SD TCP:
    - client tạo kết nối TCP (tạo socket) đến sever, cổng 80
    - sever chấp nhận kết nối TCP từ client
    - Thông điệp HTTP (application-layer protocol messages) trao đổi giữa trình duyệt (HTTP client) và Web sever (HTTP sever)
    - Kết nối TCP đóng
- HTTP is "stateless":
    - sever duy trì ko có thông tin về các yêu cầu trước của client
    - Các giao thức duy trình "trạng thái" rất phức tạp
        - các trạng thái trước phải được duy trì
        - nếu client/sever gặp sự cố, các trạng thái không được nhất quán, phải được đối chiếu
#### b. HTTP connections:
- Non-persistent HTTP:
    - Mở kết nối TCP
    - Nhiều nhất 1 object được gửi qua kết nối TCP (TCP connection)
    - Đóng kết nối TCP
    - Tải nhiều object yêu cầu nhiều kết nối
- Persistent HTTP:
    - Kết nối TCP được mở đến sever
    - Nhiều đối tượng có thể được gửi qua một kết nối TCP giữa client và sever
    - Đóng kết nối TCP
#### c. Non-persistent HTTP:
- VD:![](https://i.imgur.com/oPCuExr.png)
![](https://i.imgur.com/A8vtxrI.png)
- Response time: 
    - RTT (Round-trip time): Thời gian cho một cái **small packet** di chuyển từ client đến sever và ngược lại
    - HTTP response time (per object):
        - 1 RTT để khởi động kết nối TCP
        - 1 RTT cho HTTP request và một vài byte đầu tiên của HTTP response trả về
        - Thời gian object/file trao đổi
        - Non-persistent HTTP response time =  2RTT+ file transmission  time
#### d. Persistent HTTP (HTTP 1.1):
- Vấn đề của Non-persistent HTTP:
    - 2 RTT cho mỗi object
    - Chi phí của HĐH cho mỗi kết nối TCP
    - Các trình duyệt thường mở nhiều kết nối TCP song song để nạp referenced objects song song
- Persistent HTTP (HTTP 1.1):
    - Máy chủ để kết nối mở sau khi phản hồi
    - Thông điệp HTTP liền kề giữa client/sever được gửi qua kết nối mở
    - client gửi request ngay khi gặp đối tượng tham chiếu\
    - Chỉ cần 1 RTT cho các đối tượng được tham chiếu (giảm nửa TG phản hồi)
#### e. HTTP request message:
- 2 loại thông điệp HTTP: request, response
- HTTP request message: ASCII (human-readable format)
- ![](https://i.imgur.com/mnmXvLo.png)
- HTTP request message: general format
![](https://i.imgur.com/ZslJq6i.png)
- Phương thức POST: 
    - Trang web thường gồm input mẫu
    - Input của users được gửi từ client đến sever trong entity body của HTTP POST request message
- Phương thức HEAD:
    - Header của request (chỉ) sẽ được trả về nếu URL được chỉ định được yêu cầu bằng phương thức HTTP GET.
- Phương thức GET (gửi dữ liệu đến sever):
    - gồm dữ liệu của user trong trường URL của HTTP GET (sau dấu ?)
    - VD: www.somesite.com/animalsearch?monkeys&banana
- Phương thức PUT:
    - Upload new file/object đến sever
    - Thay thế hoàn toàn file đã tồn tại ở URL đã chỉ định bằng nội dung trong entity body của HTTP POST
#### f. HTTP response status codes
![](https://i.imgur.com/w9C8L75.png)
#### g. Cookies:
- Các trang web và trình duyệt của client sử dụng cookie để duy trì một số state giữa các giao dịch
- 4 thành phần:
    - Dòng tiêu đề cookie của thông báo phản hồi HTTP
    - Dòng tiêu đề cookie trong thông báo yêu cầu HTTP tiếp theo
    - Tệp cookie được lưu trên máy chủ của người dùng, được quản lý bởi trình duyệt của người dùng
    - Cơ sở dữ liệu back-end tại trang Web
- VD: ![](https://i.imgur.com/ZLA8mTp.png)
#### h. Web caches:
- Mục đích: Thỏa mãn yêu cầu của clients mà không liên quan đến sever chính
- Người dùng định cấu hình trình duyệt để trỏ đến Web caches (cục bộ)
- trình duyệt gửi tất cả các yêu cầu HTTP đến bộ đệm
    - Nếu đối tượng trong cache: cache trả đối tượng cho máy khách
    - Ngược lại, cache yêu cầu đối tượng từ máy chủ gốc, lưu trữ đối tượng đã nhận, sau đó trả đối tượng về máy khách
- Web cache giống như client và sever
    - client với máy chủ chính
    - sever với client đang request
- Sever nói với caches cho phép chứa các thực thể trong các response header
    - Cache-Control: max-age=< seconds >, tồn tại bao nhiêu thời gian thì xóa trong cache --> cập nhật lại cái mói từ sever chính. 
    - Cache-Control: no-cache
- Conditional GET
    - Mục đích: Không gửi object nếu cache có bản mới nhất
    - client: thêm một dòng thời điểm lấy cache trong HTTP request 
        - if-modified-since: < date >
    - sever: nếu bản cache đã là bản mới nhất, sever sẽ phản hồi lại không chứa object
### 11. E-mail:
- Gồm có 3 thành phần:
    - user agents:
        - là "mail reader"
        - VD: Gmail, out
    - mail server:
        - mailbox: chứa các mail được gửi đến user
        - message queue: gửi các mail ra ngoài
    - SMTP (simple mail transfer protocol)
        - client: sending mail server
        - "server": receiving mail server
- SMTP RFC:
    - sử dụng TCP bởi TCP là giao thức tin cậy, ko mất mát dữ liệu, port 25
    - 3 giai đoạn trao đổi:
        - SMTP handshaking (greeting)
        - SMTP transfer of messages
        - SMTP closure
- So sánh
    - HTTP: client pull
    - SMTP: client push
    - Cả hai sử dụng mã ASCII, status codes
    - HTTP: mỗi object được đóng gói trong một response message
    - SMTP: có nhiều object được đóng gói trong một message nhiều phần
- Mail message format
    - header lines
        - To:
        - From:
        - Subject:
    - Body: ký tự ASCII
- Retrieving Email (lấy email): mail access protocols
    - SMTP: vận chuyển, lưu trữ email cho server nhận
    - mail access protôcl: nhận từ server
        - IMAP: Internet Mail Access Protocol [RFC 3501]: tin nhắn lưu trên server, IMAP dịch vụ nhận, xóa, tổ chức tin nhắn thành folder trên sever
        - HTTP: gmail, Hotmail, ... cung cấp giao diện web cơ sở cho SMTP (gửi), IMAP/POP3 (nhận)

### 12. The Domain Name System (DNS)
- Là **cơ sở dữ liệu phân tán** được triển khai ở rất nhiều server
- Hoạt động ở **application-layer protocol**: phân giải tên miền, địa chỉ ip

- DNS services:
    - phân giải từ tên miền --> địa chỉ IP
    - host aliasing
    - mail server aliasing
    - load distribution
- Tại sao không là là **CSDL tập trung**:
    - Nếu server chết --> DNS chết
    - Quá tải dung lượng
    - Khoảng cách giữa cơ sở dữ liệu và các máy sẽ bị xa
    - Khó bảo trì
- DNS: CSDL phân tán, phân cấp
    ![](https://i.imgur.com/hEzqlR6.png)
    - root name servers:
        - Có 13 root name servers
        - Cực kỳ quan trọng
        - ICANN (Internet Corporation for Assigned Names and Numbers) quản lý root DNS domain
    - Top-Level Domain (TLD) servers
        - Quản lý các tên miền liên quan đến .com, .org, .net, và top-level contry domain: .cn, .vn, ...
    - Authoritative DNS servers:
        - Thuộc quyền quản lý của cơ quan, tổ chức
    - Client muốn địa chỉ của www.amazon.com:
        - client truy vấn root sever để tìm .com DNS server
        - client hỏi TLD để tìm amazon.com
        - client hỏi amazon.com DNS server để lấy địa chỉ IP của www.amazon.com
    - Local DNS name servers:
        - Khi host gửi một DNS query, chúng sẽ được gửi đến local DNS name server trước
            - Local DNS server trả lời:
                - Lưu trữ các dữ liệu để trả lời cho host
            - Mỗi ISP đều có local DNS name server, để tìm của mình
                - MacOS: % scutil --dns
                - Windows: >ipconfig /all
        - local DNS server không thuộc hệ thống phân cấp trên (vì không có nó thì hệ thống vẫn hoạt động, chỉ tăng tốc truy vấn DNS)

- Phân giải DNS: tìm kiếm tuần tự
![](https://i.imgur.com/S1dMWFY.png)
Hỏi đến local --> local hỏi root --> root trả về TLD DNS --> local hỏi TLD --> ....
- Phân giải DNS: tìm kiếm tuần tự
![](https://i.imgur.com/ZDve77u.png)
Hỏi đến local --> local hỏi root --> root tìm TLD rồi hỏi --> TLD hỏi tiếp đến authoriative --> authoriative trả về
- Caching DNS Information:
    - Tăng tốc độ truy vấn khi lưu những DNS đã được truy vẫn
    - Dữ liệu biến mất sau khoảng thời gian TTL (time to live)
    - cached có thể out-of-date
        - Tên miền vẫn thế, nhưng đổi địa chỉ IP, trên cache không còn
- DNS records
    - DNS: lưu resourse records (RR
    - ![](https://i.imgur.com/ykPp3GO.png)
- DNS protocol messages:
    - DNS query và reply messages có format giống nhau:
    - ![](https://i.imgur.com/bUF2Bdr.png)
- DNS security
    - DDoS
    - Spoofing attacks
### 13. Peer-to-peer (P2P) architecture
- Không có máy chủ luôn bật
- Các end system kết nối trực tiếp với nhau
- Peer gửi yêu cầu, cung cấp dịch vụ cho các peer khác
- Peers kết nối không liên tục và thay đổi địa chỉ IP
#### a. Chia sẻ file: client-server và P2P
- Hỏi: Thời gian để chia sẻ file (size F) từ 1 server đến N peers
- client-server:
    - server: Sẽ phải gửi N lần
    - client: download file từ server
    - ![](https://i.imgur.com/wxXJQS4.png)
- P2P:
    - server: chỉ cần upload đúng 1 lần
    - client: phải download file
    - ![](https://i.imgur.com/vXWozjY.png)
#### b. P2P file distribution: BitTorrent 
- File được chia thành các chunks (mảnh nhỏ) kích thước 256Kb
- peers trong torrent sẽ nhận/gửi các chunks
- ![](https://i.imgur.com/2RJjLY5.png)
    - tracker: theo dõi các peer tham gia torrent
    - torrent: tập hợp các peers đang trao đổi các chunks của file
- Peer tham gia torrent:
    - Đầu tiên không có chunk, như sẽ tích lũy theo thời gian từ các peers khác
    - Đăng ký với tracker để lấy danh sách các peer, kết nối với các peers hàng xóm
- Trong khi tải, peer cũng tải chunks cho các peers khác
- churn: peers có thể đến và đi bất kỳ lúc nào
- Peer có thể thay đổi peers mà nó trao đổi chunks
- Sau khi peer đã có tất cả các chunks, nó có thể rời đi hoặc ở lại

#### c. BitTorrent: requesting, sending file chunks
- Requesting chunks:
    - Tại bất kỳ thời điểm nào, các peers sẽ có bộ chunks khác nhau
    - Peer sẽ hỏi các peers danh sách chunks mà các peers đã có
    - Peer sẽ yêu cầu các chunks không có, theo thứ tự là các chunks hiếm nhất
- Sending chunks: có qua có lại
    - Peer sẽ gửi chunks cho 4 peers khác mà hiện có tốc độ gửi chunks cho peer là cao nhất
        - Đánh giá lại top 4 sau 10s
    - 30s 1 lần, sẽ lựa chọn 1 peer ngẫu nhiên để gửi chunks
- VD: ![](https://i.imgur.com/R0V0MMO.png)

### 14. Video streaming and content distribution networks
#### a. Video Streaming and CDNs: context
- Truyền lưu lượng video: consumer sử dụng chính của băng thông Internet

#### b. Multimedia: video
- Video: chuỗi các hình ảnh được hiển thị theo tỉ lệ cố định
- Digital image: là một chuỗi các pixels
    - mỗi pixels là một tập hợp chuỗi bits
- Coding (mã hóa): giảm số bit cần phải gửi mà vẫn đảm bảo được nội dung của các bức ảnh
    - spatial coding (within image): giảm số bit cần phải gửi đi trong 1 bức ảnh. Thay vì gửi N giá trị giống nhau, ta chỉ cần gửi 2 giá trị: giá trị màu và số lượng điểm ảnh có giá trị đó
        - ![](https://i.imgur.com/c0hKeiU.png)
    - temporal coding (from one image to next): giảm số bit phải gửi dựa trên nhiều bức ảnh. Chỉ gửi những sự khác biệt giữa bức ảnh hiện tại và bức ảnh trước
        - ![](https://i.imgur.com/iVRe5Wa.png)
- CBR (constant bit rate): video encoding rate fixed
- VBR (variable bit rate): video encoding rate changes as amount of spatial, temporal coding changes 

#### c. Streaming stored video
- Thách thức: 
    - Băng thông kết nối từ client-server sẽ thay đổi liên tục
    - packet loss, delay
- Streaming: client phát phần video trước, server gửi phần video sau
- Buffering: có bộ nhớ để trong trường hợp dữ liệu chưa kịp gửi đến --> chờ rồi phát
- Streaming multimedia: DASH (**D**ynamic, **A**daptive, **S**treaming over **H**TTP)
    - server:
        - chia video file thành nhiều chunk
        - mỗi mảnh sẽ được mã hóa thành nhiều tốc độ khác nhau
        - các phiên bản mã hóa khác nhau sẽ được lưu ở từng file
        - file sẽ được nhân bản tại nhiều CDN node
        - **manifest file**: cung cấp URLs cho các chunks
    - client:
        - định kỳ sẽ tính toán tốc độ từ client đến server
        - xem manifest file để lấy các chunk
            - nếu băng thông thấp, lấy chunks thấy
            - băng thông cao, lấy chunks cao
#### d. Content distribution networks (CDNs)

## Chương 3: Transport layer
### 1. Transport-layer services
#### a. Transport services and protocols
- Cung cấp 1 kết nối về mặt logic (ảo) giữa các process chạy bởi các host khác nhau 
- Các hoạt động của  transport protocol trong end systems:
    - Phía gửi: chia các application message thành các segment, rồi chuyển xuống network layer
    - Phía nhận: gộp các segment thành các message ban đầu, rồi chuyển lên application layer
- Hai giao thức hoạt động ở tầng transport với mạng Internet: **TCP**, **UDP**

#### b. Transport vs. network services and protocols 
- Network layer: logical communication between **hosts**
- Transport layer: logical communication between **processes**

#### c. Transport layer actions
- Phía gửi:
    - Chuyển application-layer message xuống tầng transport
    - Thêm header vào message --> tạo thành segment
    - Chuyển segment đến tầng dưới
- Phía nhận:
    - Nhận message từ IP
    - Kiểm tra header
    - Giải mã application-layer message
    - Gộp các thành tin nhắn đến application từ socket
#### d. Two principal Internet transport protocols
- TCP:
    - reliable, in-order delivery
    - congestion control
    - flow control
    - connection setup
- UDP:
    - unreliable, unordered delivery
    - no-frills extension of "best effort" IP
- Các dịch vụ mà cả hai ko có
    - delay guarantees: Đảm bảo độ trễ
    - bandwidth guarantess: Đảm bảo băng thông

### 2. Multiplexing and demultiplexing
#### a. Multiplexing/demultiplexing
- Multiplexing ở phía gửi:
    - Kiểm soát data từ nhiều socket, thêm transport header
- Demultiplexing ở phía nhận:
    - Sử dụng thông tin header để vẫn chuyển các segment đã nhận đến đúng socket

#### b. How demultiplexing work
- Host nhận IP datagram
    - Mỗi datagram có địa chỉ IP nguồn, đích
    - Mỗi datagram chở 1 transport layer segment
    - Mỗi segment có số cổng nguồn, đích
- Host sử dụng địa chỉ IP và số cổng để kết nối segment đến socket
- ![](https://i.imgur.com/KHKhAL0.png)

#### c.Connectionless demultiplexing
![](https://i.imgur.com/EM3It33.png)
#### d. Connection-oriented demultiplexing
- TCP socket gồm 4 thành phần
    - Địa chỉ IP nguồn
    - Cổng nguồn
    - Địa chỉ IP đích
    - Cổng đích

#### e. Summary
- UDP: demultiplexing chỉ sử dụng địa chỉ đích
- TCP: demultiplexing sử dụng cả địa chỉ nguồn, đích

### 3. Connectionless transport: UDP
#### a. UDP
- best effort;
- UDP segment:
    - có thể mất
    - không theo thứ tự
- Connectionless:
    - khôg có handshaking
    - mỗi UDP segment được quản lý độc lập với nhau
- ![](https://i.imgur.com/4qQBT0s.png)
- Trao đổi thông tin đáng tin cậy qua UDP:
    - triển khai độ tin cậy, kiểm soát độ nghẽn ở application-layer
- UDP segment header: ![](https://i.imgur.com/PWQos9N.png)
#### b. UDP checksum
- Phát hiện lỗi 
- Phía gửi:
    - Chia UDP segment thành các nhóm gồm 16 bit
    - Checksum: tính tổng các nhóm rồi đảo ngược bit
    - Thêm vào header checksum
- ![](https://i.imgur.com/qM9mES1.png)
- Internet checksum: weak protection

### 4.Principles of reliable data transfer (Nguyên tắc trao đổi thông tin đáng tin cậy)
#### a. Principles of reliable data transfer
#### b. Reliable data transfer protocol (rdt): interfaces
- ![](https://i.imgur.com/lP4o4PF.png)
- rdt_send(): Chuyển dữ liệu xuống từ application --> transport
- udt_send() (ỉneliable data transfer): Chuyển từ transport --> network
- delivery_data(): Chuyển dữ liệu từ transport --> application
- rdt_rcv(): Thông báo có packet chuyển từ network --> transport
#### c. Reliable data transfer: getting started
- Mô hình finate state machine (FSM) để mô tả phía gửi, nhận
    - Mỗi một thực thể tồn tại ở một trạng thái ("state")
        - Khi có một sự kiện ("event") xảy ra ở thực thể hiện tại, nó sẽ chuyển ("transition") sang trạng thái khác
    - Việc chuyển trạng thái gây ra hành vi ("action") khác
    - --> event/action
    - ![](https://i.imgur.com/jD6GCAv.png)
#### d. rdt1.0: reliable transfer over a reliable channel
- Giả sử môi trường gửi dữ liệu hoàn toàn tin cậy:
    - Không mất mát, không lỗi bit
- Mô hình FSM:
    - Phía gửi: đợi dữ liệu từ trên --> rdt_send(data)/packet = make_pkt(data), udt_send(packet) --> đợi dữ liệu
    - Phía nhận: đợi dữ liệu từ dưới --> rdt_rcv(data)/extract(packet, data), delivery_data(data) --> đợi dữ liệu
- ![](https://i.imgur.com/xrLeSE5.png)
#### e. rdt2.0: channel with bit errors
- Tích hợp 2 tính năng:
    - Cơ chế checksum để phát hiện bit sai
    - Khôi phục từ lỗi 
        - Acknowledgements (ACKs): Cơ chế phản hồi từ phía nhận thông báo cho phía gửi là OK
        - Negative acknowledgements (NAKs): Cơ chế phản hồi từ phía nhận thông báo cho phía gửi bị lỗi
        - Phía gửi sẽ gửi lại gói tin cho các phản hồi NAKs
- Giao thức rdt2.0 thuộc kiểu **stop and wait**:
    - Phía gửi gửi 1 gói tin, sau đó chờ phản hồi của phía nhận
- Mô hình FSM:
    - Phía gửi: Có hai trạng thái:
        - Ngồi đợi dữ liệu (có lệnh từ application layer)
        - Ngồi đợi ACK, NAK (phản hồi từ phía nhận)
        - Khi có sự kiện rdt_send(data) từ lớp app --> đóng gói gói tin và checksum, gửi gói tin
        - Sau đó chuyển trạng thái chờ đợi phản hồi --> Nhận được gói tin phản hổi, kiểm tra phản hổi, có 2 sự kiện:
            - Phản hổi nhận được là ACK --> Chuyển về đợi dữ liệu tiếp theo
            - Phản hồi nhận được là NAK --> Gửi lại gói tin --> Vẫn chuyển về trạng thái chờ đợi phản hồi
        - ![](https://i.imgur.com/5LcSGHm.png)
    - Phía nhận: Một trạng thái ngồi đợi dữ liệu (từ tàng network đẩy lên)
        - Khi có sự kiện nhận được gói tin bị lỗi --> Gửi NAK, chuyển về đợi gói tin
        - Khi có sự kiện nhận được gói tin ko bị lỗi --> Mở gói tin, chuyển dữ liệu lên trên, gửi ACK
        - ![](https://i.imgur.com/Ws0EWul.png)
- Lưu ý: "trạng thái" của phía nhận (phía nhận có nhận được tin nhắn chính xác không?) không được phía gửi biết trừ khi bằng cách nào đó có thể giao tiếp từ phía nhận đến phía gửi
    - đó là lý do tại sao chúng ta cần một giao thức!
- Lỗi cực kỳ nghiêm trọng:
    - Khi NAK, ACK bị lỗi
        - phía gửi ko biết điều gì xảy ra
        - không thể gửi lại --> sẽ bị lặp lại gói tin
    - Giải pháp:
        - Gửi lại gói tin hiện tại nếu ACK/NAK bị lỗi
        - Phía gửi thêm một số thứ tự (sequence number) với mỗi gói tin
        - Phía nhận hủy bỏ những gói tin bị trùng lặp
#### f. rdt2.1: sender/receiver, handling garbled ACK/NAKs
- Sender: ![](https://i.imgur.com/8XDNK7P.png)
    - Số thứ tự seq # được add vào gói tin
    - Chỉ cần sử dụng stt seq #s (0, 1) là đủ
        - Vì số thứ tự này chỉ để kiểm tra 1 gói tin nên chỉ hai giá trị 0, 1 là đủ
    - Cơ chế kiểm tra ACK và NAK có bị lỗi không
    - Số trạng thái gấp đôi 2.0
- Receiver: ![](https://i.imgur.com/p2Jru1X.png)
    - Phải kiểm tra xem gói tin có bị trùng lặp hay không
#### g. rdt2.2: a NAK-free protocol
- Giống rdt2.1, nhưng chỉ sử dụng ACK
- Thay vì gửi NAK, phía nhận sẽ gửi ACK của gói tin cuối cùng đến đích thành công
- ACK trùng lặp tại phía gửi--> tương tự như NAK: truyền lại pkt hiện tại
- TCP sử dụng phương pháp này để không có NAK
- Mô hình FSM: 
- ![](https://i.imgur.com/1S1Z8nN.png)

#### h. rdt3.0: channels with errors and loss (kênh truyền bị mất, lỗi)
- Giả định kênh có thể bị lỗi, mất mát gói tin (dữ liệu, ACKs)
- Cách tiếp cận: Đợi một khoảng thời gian nhất định cho phản hồi ACK
    - gửi lại nếu không có ACK
    - nếu gói tin (hoặc ACK) bị chậm (không mất): Có số thứ tự seq để check trùng lặp
    - Có thêm cơ chế "time out": Sau một thời gian thì nếu ko có phản hồi --> sẽ gửi lại
- Hiệu suất của rdt3.0 (stop-and-wait)
    - Cực kỳ kém hiệu quả
- rdt3.0: pipelined protocols operation
    - Phía gửi được phép gửi nhiều gói tin --> sau đó ngồi đợi phản hồi
##### h.1. rdt3.0: Go-Back-N (pipelined protocols operation)
- Phía gửi:
    - Phía gửi được gửi liên tiếp tối đa **N** gói tin, sau đó dừng lại để đợi ACK
    - "**window**": Không gian số thứ tự, được sử dụng **k** bit để đánh số seq #
    - cumulative ACK (n): khi gửi ACK (n) tức là gửi thành công các gói tin có số thứ tự <= n
    - timeout(n): truyền lại gói n và tất cả gói thứ tự cao hơn trong "window"
- Phía nhận:
    - Bỏ tất cả các gói tin không đến đích theo thứ tự

##### h.2. rdt3.0: Selective repeat (pipelined protocols operation)
- Phía nhận: phản hổi ACK tất cả các gói tin đến đích thành công
    - Buffer những gói tin đến đích không theo đúng thứ tự
- Phía gửi: time-out/gửi lại những gói tin chưa được phản hồi ACK
- ![](https://i.imgur.com/UjPnDTN.png)

### 5. Connection-oriented transport: TCP
#### a. Overview:
- Từ điểm này --> điểm khác
- Tin cậy, in-order byte
- Gửi dữ liệu theo hai chiều
    - MSS: maximun segment size
- Cumulative ACK: Khi gửi một ACK (n) tức là đã nhận được các byte < n
- Pipelining:
    - TCP congestion, flow control set window size
- Connection-oriented
    - Trải qua bước bắt tay (handshaking)
- Flow controled:
    - Phía gửi không gửi quá tải phía nhận

#### b. TCP segment structure:
- Segment = header + data
- Header:
    - Sort, des port
    - sequence number: số thứ tự
    - ACK number
    - Checksum
    - Length: Độ dài của TCP header
    - R (RST), S (SYN), F (FIN): quản lý kết nối
    - A (ACK bit)
- ![](https://i.imgur.com/967F7W2.png)

#### c. TCP sequence numbers, ACKs
- Sequence numbers: 
    - Là số thứ tự của byte đầu tiên nằm trong segment đó
    - VD: seg 1 - (0 - 19) byte --> seq 0, seg 2 (20 - 39) --> seq 20
- ACK number (phản hổi từ phía nhận):
    - Thông báo cho phía gửi byte tiếp theo được nhận là bao nhiêu
    - Chính là số thứ tự của byte tiếp theo mà phía gửi muốn nhận

#### d. TCP fast retransmit
- Nếu phía gửi nhận được ba lần ACK giống nhau, gửi lại segment chưa được ACK với sequence nhỏ nhất
- ![](https://i.imgur.com/dNQrVCe.png)
#### e. Flow control:
- Là thông tin trong receive window
- Receive window(rwnd): số byte tối đa mà phía nhận nhận được
- Flow control: Kiểm soát để tránh làm tràn buffer phía nhận
- ![](https://i.imgur.com/kVHvdlJ.png)
#### f. TCP connection management:
- Trước khi trao đổi dữ liệu, phía gửi và nhận phải "handshake".
- TCP bắt tay trong 3 bước:
    - ![](https://i.imgur.com/ZMea7oD.png)
        - Client gửi
            - SYN bit = 1 --> gói tin yêu cầu khởi tạo kết nối
            - Seq = x --> gói tin đầu tiên mà Client gửi có số hiệu là x
        - Server phản hồi
            - SYN bit = 1 --> gói tin yêu cầu khởi tạo kết nối
            - Seq = y --> gói tin đầu tiên mà Server gửi có số hiệu là y
            - ACKBit = 1 --> Chấp nhận
            - ACKNum = x + 1 --> Thông báo đã nhận được từ client
        - Client gửi tiếp
            - ACKbit = 1 --> Chấp nhận
            - ACKNum = y + 1 --> Thông báo đã nhận được từ server

#### g. TCP round trip time (RTT), timeout
- Đặt timeout lớn hơn RTT
- Cần xác định được RTT:
    - Sample RTT: Thời gian từ việc gửi dữ liệu đến khi nhận được ACK 
    - EstimatedRTT (Giá trị trung bình RTT) = (1 - alpha) * EstimatedRTT + alpha * SampleRTT
    - alpha = 0.125

Phần 2 ở: https://hackmd.io/@mzkFhoCYQfG3iOK4ewNv4Q/rkF0IvaUn

Câu hỏi trắc nghiệm:
https://hackmd.io/@mzkFhoCYQfG3iOK4ewNv4Q/Skh_bWgv2


