COMP S368 & COMP 4680SED — Final Exam Concept Map 期末考試概念圖

OSI 7-Layer vs TCP/IP 4-Layer 七層 vs 四層

Why TCP/IP 4-layer wins in practice: simpler, implementation-friendly, covers OSI's core functions with less overhead. You must be able to draw this.

Use case 用途: OSI — teaching / reference model, network troubleshooting (e.g. "issue is at Layer 7 vs Layer 3"). TCP/IP — every real-world network (the Internet, LAN, mobile data) runs on this 4-layer stack.

Encapsulation (draw this) 封裝過程（必畫）

Sender wraps (encapsulates) top-down; receiver unwraps (decapsulates) bottom-up. Each layer's PDU becomes the next layer's payload.

TCP vs UDP 可靠 vs 快速

Trade-off to memorise: Reliability ↔ Speed.

Socket Programming 套接字編程

A socket = IP address + Port. Bridges application ↔ transport layer.

TCP sequence

UDP sequence

Server must start before the client, otherwise ConnectionRefused. Java and Python sockets interoperate because both speak standard TCP/UDP.

Architecture Models 架構模式

Three-Tier Model 三層架構

Benefits: modularity, code reuse, layers upgraded independently. Key to explain Java EE & Spring MVC architectures.

Cloud Computing (NIST) 雲端運算（NIST 定義）

5 essential characteristics

SPI service models (shared responsibility)

Deployment models

Cloud-Native Principles 雲原生原則

• Containerisation — Docker, consistent runtime across envs
• Microservices — small, independent, single-capability services
• Dynamic orchestration — Kubernetes auto-scales & load-balances
• DevOps / CI-CD — automated build, test, deploy; IaC
• Scalability & resilience — horizontal scaling, self-healing, multi-zone, circuit breakers

Benefits: agility, cost efficiency (pay-per-use), resilience. Risks: complexity, network latency, distributed-tracing overhead.

Kubernetes Essentials K8s 核心概念

Scaling: HPA (replicas by CPU/metric), VPA (resource requests), Cluster Autoscaler (nodes).
Self-healing: liveness/readiness probes, automatic pod replacement, node failure rescheduling.

Big Data & MapReduce 大數據與 MapReduce

3V: Volume, Variety, Velocity. Extra: Variability, Veracity, Visualisation, Value.

Example: Map squares inputs (0,1,2,3,4)→(0,1,4,9,16), Reduce sums → 30. Same mapper/reducer scales from 10 to 100+ CPUs unchanged.

Lock + Condition (BankAccount pattern) 鎖 + 條件變量（銀行例題）

Lock lock = new ReentrantLock();
Condition getDeposit = lock.newCondition();

void deposit(int n) {
  lock.lock();
  try {
    balance += n;
    getDeposit.signalAll();   // wake all waiters
  } finally { lock.unlock(); }
}

void withdraw(int n) {
  lock.lock();
  try {
    while (balance < n)     // ⭐ while, not if
      getDeposit.await();      // releases lock + waits
    balance -= n;
  } finally { lock.unlock(); }
}

• while (not if): protects against spurious wake-ups and multiple waiters.
• await(): releases lock → waits → re-acquires on wake.
• signalAll() over signal(): safer when multiple waiters may be eligible; avoids starvation.

Common Concurrency Bugs 常見並行錯誤

Deadlock

// T1: lock1 → lock2     T2: lock2 → lock1  → DEADLOCK

Fixes: fixed lock ordering, tryLock(timeout), higher-level primitives.

Starvation

Using signal() may always wake the same thread → others starve. Prefer signalAll() / fair locks.

Spurious wake-up

Always re-check the condition in a while after await().

Pessimistic vs Optimistic Control 悲觀鎖 vs 樂觀鎖（深入版）

Pessimistic Locking 悲觀鎖

Assumes conflicts will happen. Lock the resource before touching it so no one else can interfere.

-- SQL example: "SELECT ... FOR UPDATE" acquires a row-level exclusive lock
BEGIN;
SELECT balance FROM Account WHERE id=1 FOR UPDATE;  -- others wait
UPDATE Account SET balance = balance - 300 WHERE id=1;
COMMIT;                                                  -- lock released

• Real-world analogy 比喻: 廁所門鎖 — 入去就鎖門，其他人要等。
• Guarantees no lost updates or dirty reads.
• Cost: other transactions block and wait; deadlock possible if multiple locks acquired out of order.

Optimistic Concurrency Control (OCC) 樂觀鎖（無鎖）

Assumes conflicts are rare. Don't lock anything — just work on a local copy, then at commit time check if anyone else modified the data. If yes, rollback and retry.

Three phases:

Conflict Detection — 2 techniques 衝突檢測方法

// JPA: a single @Version field turns on optimistic locking automatically
@Entity
class Account {
  @Id Long id;
  Double balance;
  @Version Long version;    // JPA bumps this on every update
}

// At commit time, if another transaction already bumped the version,
// JPA throws OptimisticLockException — application must catch & retry.

• Analogy 比喻: 維基百科編輯 — 你改緊嘅時候冇人阻你，但 save 嗰陣如果有人搶先改咗，你要 refresh 同合併先再 save。
• No blocking → higher throughput when few conflicts.
• When conflicts do happen, the whole transaction is wasted and must retry.

Side-by-side 詳細對比

When to pick which — decision guide 點揀？

Lock Types & Granularity 鎖類型與粒度

Granularity: record < page < table < database. Smaller = more concurrency but more lock overhead.

Centralised vs Decentralised Coordination 中心化 vs 去中心化

Two-Phase Commit (2PC) 兩階段提交（深入版）

Problem solved: making a transaction atomic across multiple nodes (e.g. bank A and bank B are on different databases). Either all nodes commit, or all abort — never a mix.

Roles 角色

• Coordinator — one node drives the protocol (e.g. transaction manager).
• Participants — the other nodes that hold the data being changed.

Phase 1 — Prepare / Voting 階段一：準備投票

1. Coordinator sends PREPARE to every participant.
2. Each participant does its local work, writes an undo + redo log, and locks the resources.
3. Participant replies YES (ready to commit) or NO (must abort).

Phase 2 — Commit / Abort 階段二：提交/中止

1. If all participants voted YES → coordinator writes COMMIT to its log, sends COMMIT to all.
2. If any voted NO (or timed out) → coordinator sends ABORT to all.
3. Participants finalise (release locks, apply or undo changes) and send ACK.

Coordinator                 Participants (P1, P2, ...)
    |  ── PREPARE ─────────►  |  do work, write log, lock
    |                         |
    |  ◄── YES / NO ─────────  |  vote
    |                         |
    |  (all YES?)             |
    |  ── COMMIT or ABORT ──► |  finalise
    |                         |
    |  ◄── ACK ──────────────  |

Why it can block 點解 2PC 會卡死

• Coordinator crashes after PREPARE but before sending COMMIT/ABORT → participants are stuck holding locks, not knowing the outcome. This is 2PC's famous weakness: it is a blocking protocol.
• Participant failure after voting YES → on recovery it must consult the log and the coordinator to learn the outcome.
• Mitigation: add a third phase (3PC) or replace with consensus protocols (Paxos, Raft) or the Saga pattern for long-running business flows.

2PC vs OCC — don't confuse 唔好同樂觀並行撈亂

SQL vs NoSQL 關聯式 vs 非關聯式

4 NoSQL families: key-value (Redis — session cache), column (Cassandra — time series), document (MongoDB — CMS/profiles), graph (Neo4j — social networks, fraud).

Relational Concepts 關聯式資料庫概念

• Primary Key — unique, non-null, one per table (Entity Integrity)
• Foreign Key — matches a PK elsewhere or is NULL (Referential Integrity)
• Cardinalities: 1:11:N (FK on many side)M:N (junction table)

SQL categories

Java EE vs Spring Java EE vs Spring 框架

JPA Essentials JPA 核心

• @Entity + @Id are mandatory; add @GeneratedValue for auto-PK
• Class: non-final, public/protected no-arg constructor, usually Serializable
• Customise mapping: @Table, @Column, @Temporal, @Transient
• Relationships: @OneToOne, @OneToMany(mappedBy=...), @ManyToOne, @ManyToMany

Entity lifecycle

Spring Data JPA Spring Data JPA（免寫 SQL）

interface CustomerRepository extends JpaRepository<Customer,Long> {
  Optional<Customer> findByCustName(String n);          // derived
  @Query("select c from Customer c where c.email like :e")
  List<Customer> byEmail(@Param("e") String e);          // declared
}

• save() is an upsert — insert if id is null, update otherwise. Don't mutate the PK.
• Inherits findById, findAll, existsById, deleteById.
• JPQL uses entity/field names, not table/column names → vendor-independent.

Spring MVC & the DispatcherServlet Spring MVC 流程（必考）

Key annotations

PRG pattern

POST → return "redirect:/success" → GET. Prevents duplicate submits on refresh; flash attributes carry one-shot messages.

REST vs SOAP REST vs SOAP 服務

Messaging (Unit 7) 訊息系統（Unit 7）

Two models

Brokers / MOM

Tech used in course

• JMS — Java API: ConnectionFactory → Connection → Session → Producer/Consumer → Destination (Queue/Topic)
• Spring Cloud Stream — binder abstraction (@EnableBinding, @StreamListener) — swap RabbitMQ/Kafka without code changes
• OpenFeign — declarative REST client (@FeignClient), boilerplate-free HTTP calls
• Hystrix — circuit breaker + fallback (@HystrixCommand(fallbackMethod=...))

CIA Triad 資安三大基石

Confidentiality — only authorised can read. Tools: encryption, ACLs.

Integrity — data not altered undetected. Tools: hashes, digital signatures, checksums.

Availability — services usable when needed. Tools: redundancy, DDoS mitigation, backups.

The 3 A's — AAA AAA 三大原則

Beyond CIA, security systems rest on the AAA triad.

Bonus principle often grouped with AAA

Non-repudiation 不可否認性 — a party cannot later deny they sent / signed a message. Achieved via digital signatures (private-key signs, anyone can verify with public key).

Real example 實例

Online banking transfer:

• AuthN: user logs in with password + SMS OTP.
• AuthZ: system checks the user has role ACCOUNT_OWNER for the source account.
• Accounting: audit log records user, source, destination, amount, timestamp, IP.
• Non-repudiation: transaction signed with user's key — cannot deny later.

Hashing vs Salted Hashing 哈希 vs 加鹽哈希

Hash = one-way function (SHA-256, bcrypt). Same input → same hash.

Plain hash is vulnerable to rainbow tables & precomputed attacks.

Salted hash = hash(password + random_salt), salt stored per user → identical passwords get different hashes.

Common Attacks & Defences 常見攻擊與防禦（深入版）

Example answer — one attack end-to-end 一個完整示範

Q: "Explain phishing and how an organisation defends against it."

Three categories of prevention

• Physical — locks, access control, CCTV, guards, server room policies.
• Educational — training users to spot phishing, safe links, password hygiene.
• Deterrent — visible monitoring, banners, logging to discourage insiders/attackers.

Zero Trust

"Never trust, always verify." No implicit trust from network location. Every request is authenticated, authorised, and encrypted. Plan Zero Trust before designing the architecture, not after.

Circuit Breaker

States: ClosedOpenHalf-Open

Stops cascading failures by short-circuiting calls to a failing service, then tests recovery.

Bulkhead

Partition resources (thread pools, connections) so one overloaded component can't sink the rest.

Saga

Long-running transaction as a chain of local transactions; each step has a compensating action to undo on failure. E.g. Order → Payment → Inventory; failures trigger Cancel / Refund / Restock.

Event-Driven Architecture

Components publish events, others subscribe. Loose coupling, async, scalable. Example: "Order Placed" triggers inventory + payment + notification.

Must be able to DRAW

• TCP/IP 4-layer model & encapsulation
• Client-server, multi-server, proxy, P2P, three-tier
• Race condition timeline (sum interleaving)
• Lock + Condition state machine (await / signal / signalAll)
• 2PC coordinator/participant flow
• Orchestration vs Choreography sequence
• Circuit breaker states

Must be able to COMPARE (tables)

• TCP vs UDP
• SQL vs NoSQL
• Java EE vs Spring
• REST vs SOAP
• Pessimistic vs Optimistic / Centralised vs Decentralised
• Process vs Thread
• Orchestration vs Choreography
• PTP vs Pub/Sub messaging

Security

Transactions

Concurrency

Networking & Big Data