แผนการเรียนรู้
/
สัปดาห์ที่ 1 -- ส่วนที่ 1

การพัฒนาเว็บแอปพลิเคชันเต็มรูปแบบพื้นฐาน

Basic Full Stack Web Application Development (1145101)

เป้าหมายการเรียนรู้สัปดาห์ที่ 1

1. เข้าใจสถาปัตยกรรม Client-Server และการแบ่งส่วนหน้าที่
2. อธิบายกลไกการทำงานของ IP Address & DNS
3. เข้าใจโครงสร้างโปรโตคอล HTTP Request & Response
4. ใช้เครื่องมือ Browser DevTools & cURL ตรวจสอบทราฟฟิก
จำนวน 3 หน่วยกิต 3(2-2-5) -- บรรยาย 2 ชม. | ปฏิบัติ 2 ชม. | ศึกษาด้วยตนเอง 5 ชม./สัปดาห์

วัตถุประสงค์และสัดส่วนการประเมินผล

Course Objectives & Evaluation Structure

10%
เข้าชั้นเรียน
การมีส่วนร่วมและพฤติกรรมในชั้นเรียน
20%
งานปฏิบัติการ
แบบฝึกหัดและการทดลองรายสัปดาห์
25%
กลางภาค
สอบวัดความรู้ & โครงงานย่อย Midterm
30%
โครงงานปลายภาค
Full-Stack App + Podman Deployment
15%
นำเสนอ & สรุป
นำเสนอผลงาน และเอกสารรายงาน

ข้อตกลงในการเรียน

  • เน้นการปฏิบัติจริงบนเครื่องคอมพิวเตอร์ส่วนบุคคลด้วยเครื่องมือ Open Source ทั้งหมด
  • ส่งงานปฏิบัติการและซอร์สโค้ดผ่านทางระบบควบคุมเวอร์ชัน (Git Repository)

เส้นทางการเรียนรู้ 15 สัปดาห์

15-Week Learning Roadmap

เฟส 1
สัปดาห์ที่ 1 - 3
Web & System Foundations

Client-Server, DNS/IP, HTTP/HTTPS, REST Concepts, HTTPie Desktop & CLI, System Design Overview

เฟส 2
สัปดาห์ที่ 4 - 8
Django Full-Stack Core

Django MVT Architecture, ORM & Normalization, Views/Templates, Forms, Session Management & Midterm

เฟส 3
สัปดาห์ที่ 9 - 12
APIs & Security

Web Security (XSS/CSRF), Django REST Framework (DRF), JWT Token Auth, CORS & Caching Framework

เฟส 4
สัปดาห์ที่ 13 - 15
Container & Deployment

Podman Containerization, Multi-Container Stack (Nginx + Gunicorn + Django + Postgres) & Project Presentation

เป้าหมายปลายทาง: สามารถออกแบบ พัฒนา และ Deploy ระบบ Full-Stack Application ได้ด้วยตนเองบนคอมพิวเตอร์เครื่องเดียว

เค้าโครงการเรียนรู้สัปดาห์ที่ 1

Week 1 Detailed Agenda

1

แนะนำรายวิชา & Client-Server Model

ภาพรวมรายวิชา ปรัชญาการพัฒนาเว็บ และการแบ่งส่วนความรับผิดชอบระหว่าง Client กับ Server

2

ระบบ IP Address & DNS Lookup

หมายเลขไอพี Port การแปลงชื่อโดเมน การทำ DNS Caching และการทำงานของไฟล์ Hosts

3

โปรโตคอล HTTP/HTTPS & Security

โครงสร้าง Request/Response, HTTP Methods, Status Codes และการเข้ารหัส SSL/TLS

4

ภาคปฏิบัติการตรวจสอบทราฟฟิก

ทดลองใช้ Browser DevTools (Network Tab), cURL และตั้งค่าสภาพแวดล้อมบนเครื่องส่วนบุคคล

สัปดาห์ที่ 1 -- ส่วนที่ 2

สถาปัตยกรรม Client-Server

Client-Server Architecture Fundamentals

Client (ฝั่งผู้ใช้ / ส่วนหน้า)

Initiates Requests

  • • เป็นผู้เริ่มต้นส่งคำร้องขอ (Request) ไปยังเซิร์ฟเวอร์
  • • รับผิดชอบการแสดงผลส่วนต่อประสานผู้ใช้ (User Interface)
  • • ตัวอย่าง: Web Browser, Mobile Application, HTTPie, cURL

Server (ฝั่งผู้ให้บริการ / ส่วนหลัง)

Processes & Responds

  • • รอรับและประมวลผลคำร้องขอจาก Client
  • • จัดการตรรกะทางธุรกิจ (Business Logic) และเก็บรักษาข้อมูล
  • • ตอบกลับด้วยคำตอบ (Response) เช่น HTML, JSON, Media
หลักการสำคัญ: Separation of Concerns ช่วยให้การพัฒนาฝั่งหน้าบ้านและหลังบ้านสามารถแยกออกจากกันและทำงานร่วมกันอย่างมีระบบ

เจาะลึกองค์ประกอบฝั่ง Client (Frontend)

Client Technology Stack & Responsibilities

HTML5 (Structure)

กำหนดโครงสร้างและองค์ประกอบของเนื้อหาบนหน้าเว็บ เช่น หัวข้อ ข้อความ ฟอร์มป้อนข้อมูล และลิงก์เชื่อมโยง

CSS3 (Presentation)

จัดการตกแต่งความสวยงาม จัดวางเลย์เอาต์ ควบคุมสี ฟอนต์ และจัดทำ Responsive Design รองรับทุกขนาดหน้าจอ

JavaScript (Behavior)

สร้างความตื่นตัวและโต้ตอบ (Interactivity) จัดการ DOM และส่ง HTTP Request แบบ asynchronous ผ่าน Fetch API

หน้าที่หลักของ Client ในระบบ Full-Stack Web App:
• ตรวจสอบความถูกต้องของข้อมูลเบื้องต้น (Client-Side Validation)
• ส่งสัญญาณ Request พร้อม Headers/Payload ตามโปรโตคอล
• แปลงข้อมูลคำตอบ (Response Payload) มาแสดงผลบน UI
• จัดเก็บข้อมูลสถานะชั่วคราวบนเบราว์เซอร์ (LocalStorage / Cookies)

เจาะลึกองค์ประกอบฝั่ง Server (Backend)

Server-Side Layers & Infrastructure

1. Web / Application Server
Nginx / Gunicorn / WSGI

ทำหน้าที่รับ HTTP Connection, จัดการ SSL Termination, บริการไฟล์ Static และส่งต่อ Request ให้กับแอปพลิเคชัน

2. Business Logic Layer
Django Framework

ประมวลผลตรรกะของระบบ ตรวจสอบสิทธิ์ผู้ใช้ (Authentication/Authorization) และจัดการเส้นทาง URL (Routing)

3. Data Persistence Layer
Database (PostgreSQL / SQLite)

จัดเก็บข้อมูลอย่างถาวรและเป็นระเบียบ ทำงานผ่าน Django ORM เพื่ออ่าน เขียน และอัปเดตข้อมูลในฐานข้อมูล

ข้อควรระวัง: เซิร์ฟเวอร์ต้องทำหน้าที่เป็น Single Source of Truth และดูแลความปลอดภัยอย่างเคร่งครัด ห้ามเชื่อถือข้อมูลที่ส่งมาจาก Client โดยไม่มีการตรวจสอบ

วงจรการทำงาน Request-Response

The Complete Web Request-Response Lifecycle

1
Client Request
ผู้ใช้กดปุ่ม หรือส่งฟอร์ม เบราว์เซอร์สร้าง HTTP Request Packet
2
Network & Web Server
ข้อมูลส่งผ่านอินเทอร์เน็ต เซิร์ฟเวอร์รับแพ็กเกจและส่งเข้า App
3
Django App Logic
URL Routing -> View -> Query DB -> Render Template / JSON
4
Server Response
ตอบกลับด้วย HTTP Response Packet เบราว์เซอร์วาดหน้าจอ UI

กระบวนการทั้งหมดนี้เกิดขึ้นอย่างรวดเร็ว (มักใช้เวลาน้อยกว่า 100 มิลลิวินาทีในสภาพแวดล้อมที่ได้รับการปรับแต่งประสิทธิภาพ)

แนวคิดเรื่อง Stateless Protocol

Understanding Statelessness in Web Communications

Stateless หมายถึงอะไร?

เซิร์ฟเวอร์ จะไม่จดจำ Context หรือสถานะ ของคำร้องขอก่อนหน้าเลย แต่ละ HTTP Request ที่ส่งเข้ามาจะถูกประมวลผลเสมือนเป็นคำร้องขอแรกและแยกเป็นอิสระต่อกันโดยสมบูรณ์

ข้อดี: ทำให้ระบบทำ Horizontal Scaling ได้ง่าย ขยายเซิร์ฟเวอร์กี่เครื่องก็ได้เพราะไม่มีเครื่องใดถือกรรมสิทธิ์ Session ของผู้ใช้ไว้คนเดียว

คำถาม: แล้วเว็บรู้ได้อย่างไรว่าเราคือใคร?

หาก HTTP เป็น Stateless เราต้องใช้กลไกพิเศษในการส่งข้อมูลระบุตัวตนแนบไปกับ ทุกๆ Request

  • ✓ Cookies & Sessions: ส่ง Session ID แนบไปใน Cookie Header
  • ✓ Token-based (JWT): ส่ง Bearer Token แนบไปใน Authorization Header
สัปดาห์ที่ 1 -- ส่วนที่ 3

การระบุตำแหน่งบนเครือข่าย: IP Address & Ports

Network Addressing Essentials

IP Address (ที่อยู่บนเครือข่าย)

เปรียบเสมือนบ้านเลขที่ของเครื่องคอมพิวเตอร์ในระบบเครือข่าย

  • • IPv4: เช่น 192.168.1.1 หรือ 142.250.199.14
  • • IPv6: รูปแบบใหม่รองรับอุปกรณ์จำนวนมาก
  • • Localhost: 127.0.0.1 (หมายถึงเครื่องตนเอง)
Port Number (ประตูช่องทางบริการ)

เปรียบเสมือนประตูหมายเลขห้องที่ให้บริการแอปพลิเคชันเฉพาะทาง

Port 80: HTTP
Port 443: HTTPS
Port 8000: Django Dev
Port 5432: PostgreSQL

ระบบชื่อโดเมน (DNS Fundamentals)

Domain Name System -- The Internet's Directory

ทำไมต้องมี DNS?

มนุษย์จดจำชื่อข้อความได้ดี เช่น app.demo.com แต่เครื่องคอมพิวเตอร์และอุปกรณ์เครือข่ายสื่อสารกันผ่านหมายเลข IP Address เช่น 192.0.2.1 ดังนั้น DNS จึงทำหน้าที่เป็น สมุดโทรศัพท์ของอินเทอร์เน็ต (Internet Phonebook) ในการแปลงชื่อโดเมนเป็นหมายเลขไอพี

1. User Inputs URL
https://app.demo.com
2. DNS Translation
DNS Server แปลงเป็น IP
3. Connect to IP
192.0.2.1:443

ขั้นตอนการทำงานของ DNS Resolution

Step-by-Step DNS Resolution Process

ขั้นตอนที่ 1
Browser & OS Cache Check

เบราว์เซอร์และระบบปฏิบัติการตรวจสอบในหน่วยความจำแคชของเครื่องตนเองก่อน

ขั้นตอนที่ 2
DNS Recursive Resolver

หากไม่พบ จะส่งคำถามไปยัง DNS ของ ISP หรือ Public DNS (เช่น 8.8.8.8, 1.1.1.1)

ขั้นตอนที่ 3
Root Name Server

ชี้เบาะแสต่อไปยัง TLD Server ตามนามสกุลโดเมน (เช่น .com, .org, .th)

ขั้นตอนที่ 4
TLD Name Server

ชี้เบาะแสไปยัง Authoritative Name Server ที่ดูแลโดเมนนั้นๆ โดยตรง

ขั้นตอนที่ 5
Authoritative Server

คืนค่าหมายเลข IP Address จริงของโดเมนนั้นกลับมาให้เครื่อง Client

ขั้นตอนที่ 6
Caching & HTTP Request

บันทึก IP ลงใน Cache แล้วสร้าง HTTP Request เชื่อมต่อไปยัง IP นั้นทันที

DNS Caching และการกำหนดค่าใน Local Hosts File

Optimization & Local Domain Overrides

DNS Caching & TTL

การค้นหา DNS จะถูกบันทึกไว้ในหน่วยความจำชั่วคราวเพื่อลด Latency และลดภาระทราฟฟิกบนเครือข่าย โดยมีค่า TTL (Time-To-Live) กำหนดระยะเวลาการเก็บแคชก่อนสอบถามใหม่

การตั้งค่าไฟล์ Hosts ใน Local Machine

นักพัฒนาสามารถกำหนดชื่อโดเมนจำลองในเครื่องตนเองสำหรับทดสอบ (Local Development) ผ่านไฟล์ระบบ:

# /etc/hosts (Linux/macOS) หรือ C:\Windows\System32\drivers\etc\hosts
127.0.0.1 myapp.local

แผนผังสถาปัตยกรรมระบบ: การค้นหา DNS และส่ง Request

System Architecture: From Domain Name to Web Server Request

1. Client Device
พิมพ์ URL: app.demo.com
ยังไม่ทราบหมายเลข IP Address
2. DNS Resolution
สอบถาม DNS Server
คืนค่า IP: 192.0.2.1
3. Direct Web Request
ส่ง HTTP GET Request
192.0.2.1:443
เมื่อเซิร์ฟเวอร์ 192.0.2.1 ได้รับ Request จะประมวลผลผ่าน Django Web Application และส่งผลลัพธ์ (เช่น HTML/JSON) กลับมายังเบราว์เซอร์
สัปดาห์ที่ 1 -- ส่วนที่ 4

โปรโตคอล HTTP และการวิวัฒนาการ

Hypertext Transfer Protocol Overview & Evolution

HTTP/1.1
Standard Protocol (1997)
  • • รองรับ Persistent Connections (Keep-Alive)
  • • รับส่งข้อมูลแบบเป็นลำดับทีละคำร้องขอ (Head-of-Line Blocking)
HTTP/2
Binary & Multiplexed (2015)
  • • ส่งข้อมูลหลาย Stream พร้อมกันผ่าน Connection เดียว (Multiplexing)
  • • บีบอัด Header (HPACK) และรองรับ Server Push
HTTP/3
QUIC Protocol (UDP)
  • • เปลี่ยนมาใช้ QUIC บน UDP แทน TCP
  • • ลดระยะเวลาในขั้นตอนการสร้าง Connection และแก้ปัญหา Packet Loss

โครงสร้างของ HTTP Request

Anatomy of an HTTP Request Message

GET /api/v1/products HTTP/1.1 ← Request Line
Host: app.demo.com
User-Agent: Mozilla/5.0 (Windows NT 10.0)
Accept: application/json
Authorization: Bearer eyJhbGciOi...
<บรรทัดว่าง สำหรับแยก Header และ Body>
{"category": "electronics", "page": 1} ← Request Body (Optional)
1. Request Line
ประกอบด้วย HTTP Method (เช่น GET, POST), Path/URI ที่ต้องการเข้าถึง และเวอร์ชันของโปรโตคอล
2. Request Headers
ข้อมูลอธิบายการคำร้องขอ เช่น Host, User-Agent, Content-Type, Authorization Token และ Cookies
3. Request Body (Payload)
ส่วนข้อมูลที่ส่งไปยังเซิร์ฟเวอร์ (มักใช้ในคำสั่ง POST, PUT, PATCH เช่น ข้อมูลแบบฟอร์ม หรือ JSON)

คำสั่งมาตรฐาน HTTP Methods

Standard HTTP Verbs & Operations

GET
อ่านข้อมูล (Read)
ดึงข้อมูลจากเซิร์ฟเวอร์ โดยไม่มีการเปลี่ยนแปลงข้อมูลหลังบ้าน (Safe & Idempotent)
POST
สร้างข้อมูล (Create)
ส่งข้อมูลใหม่ไปประมวลผลและสร้างทรัพยากรใหม่บนเซิร์ฟเวอร์
PUT
ทดแทนข้อมูล (Replace)
อัปเดตหรือทดแทนข้อมูลทรัพยากรเดิมแบบทั้งหมด (Full Update)
PATCH
แก้ไขบางส่วน (Update)
อัปเดตเฉพาะบางฟิลด์ข้อมูลที่ต้องการแก้ไข (Partial Update)
DELETE
ลบข้อมูล (Delete)
ลบทรัพยากรที่ระบุออกจากเซิร์ฟเวอร์

โครงสร้างของ HTTP Response

Anatomy of an HTTP Response Message

HTTP/1.1 200 OK ← Status Line
Date: Thu, 10 Sep 2026 10:00:00 GMT
Server: Nginx/1.24.0
Content-Type: application/json
Content-Length: 128
<บรรทัดว่าง สำหรับแยก Header และ Body>
{
  "status": "success",
  "data": [{"id": 1, "name": "Laptop"}]
} ← Response Body
1. Status Line
ประกอบด้วย เวอร์ชัน HTTP, รหัสสถานะ (Status Code) และข้อความอธิบายสถานะ (Reason Phrase)
2. Response Headers
ข้อมูลอธิบายการตอบกลับ เช่น Content-Type, Content-Length, Set-Cookie และ Caching Policies
3. Response Body
ส่วนเนื้อหาคำตอบจริง เช่น โครงสร้างไฟล์ HTML, ข้อมูลชุด JSON หรือไฟล์สื่อสื่อบันทึก

หมวดหมู่รหัสสถานะ HTTP (Status Codes)

HTTP Status Code Classifications & Common Codes

2xx Success
ทำงานสำเร็จ
  • • 200 OK: คำร้องขอสำเร็จ
  • • 201 Created: สร้างข้อมูลสำเร็จ
  • • 204 No Content: สำเร็จแต่ไม่มี Body
3xx Redirection
การเปลี่ยนเส้นทาง
  • • 301 Moved Permanently
  • • 302 Found (Temporary)
  • • 304 Not Modified (Cache)
4xx Client Error
ข้อผิดพลาดฝั่งผู้ใช้
  • • 400 Bad Request: รูปแบบไม่ถูกต้อง
  • • 401 Unauthorized: ไม่ได้ Login
  • • 403 Forbidden: ไม่มีสิทธิ์เข้าถึง
  • • 404 Not Found: ไม่พบทรัพยากร
5xx Server Error
ข้อผิดพลาดฝั่งเซิร์ฟเวอร์
  • • 500 Internal Server Error
  • • 502 Bad Gateway
  • • 503 Service Unavailable

รูปแบบข้อมูลและ Content-Type

Media Types & Data Payload Formats in Web Applications

text/html
HTML Document

ใช้ในเว็บแอปพลิเคชันแบบ Monolith ที่เซิร์ฟเวอร์ประมวลผลและส่งเนื้อหาเป็นโค้ด HTML เพื่อให้เบราว์เซอร์วาดหน้าจอทันที

application/json
JSON Format

มาตรฐานยอดนิยมสำหรับการสื่อสารระหว่าง RESTful API และ Frontend Framework / Mobile Apps ข้อมูลมีขนาดเล็ก ประมวลผลรวดเร็ว

multipart/form-data
Form & File Uploads

ใช้เมื่อมีการส่งข้อมูลจากแบบฟอร์มที่มีการแนบไฟล์อัปโหลด เช่น รูปภาพ หรือเอกสารต่างๆ ร่วมกับข้อมูลข้อความ

สัปดาห์หน้า: สถาปัตยกรรม REST API และการติดตั้งใช้งานเครื่องมือทดสอบ API HTTPie CLI / HTTPie Desktop ผ่าน Scoop
สัปดาห์ที่ 1 -- ส่วนที่ 5

ความเสี่ยงของโปรโตคอล Plain HTTP

Security Risks in Unencrypted Web Communications

1. Eavesdropping / Sniffing
การดักรับและแอบดูข้อมูล

ข้อมูลที่ส่งผ่าน HTTP จะเป็นข้อความเปล่า (Plain Text) ทำให้ผู้ไม่หวังดีบนเครือข่ายเดียวกันสามารถใช้เครื่องมือ Network Sniffer ดักดูรหัสผ่าน หรือข้อมูลบัตรเครดิตได้โดยง่าย

2. Man-in-the-Middle (MitM)
การแทรกซึมกลางทาง

ผู้โจมตีสวมรอยเป็นตัวกลางระหว่าง Client และ Server เพื่อดักจับ ปลอมแปลง หรือแก้ไขข้อมูลที่รับส่งโดยที่ทั้งสองฝ่ายไม่รู้ตัว

3. Data Tampering
การดัดแปลงข้อมูล

คำร้องขอหรือผลลัพธ์สามารถถูกแก้ไขระหว่างทาง เช่น การฝังโฆษณา สคริปต์อันตราย (Malicious Scripts) หรือเปลี่ยนหมายเลขบัญชีโอนเงิน

ทางออก: ปัจจุบันเว็บแอปพลิเคชันสมัยใหม่ต้องเปลี่ยนมาใช้โปรโตคอล HTTPS (HTTP over TLS/SSL) เพื่อคุ้มครองข้อมูลของผู้ใช้

โปรโตคอล HTTPS และการเข้ารหัส SSL/TLS

Data Encryption in Transit

Asymmetric Encryption (การเข้ารหัสแบบไม่สมมาตร)

ใช้กุญแจคู่เป็นหลัก: Public Key (สำหรับเข้ารหัส) และ Private Key (สำหรับถอดรหัส)

  • • ใช้ในขั้นตอนการยืนยันตัวตนและสร้างความปลอดภัยเริ่มต้น
  • • ปลอดภัยสูง แต่ประมวลผลช้ากว่าเนื่องจากคำนวณคณิตศาสตร์ซับซ้อน
Symmetric Encryption (การเข้ารหัสแบบสมมาตร)

ใช้กุญแจดอกเดียวกัน (Session Key) ทั้งในการเข้ารหัสและถอดรหัสข้อมูล

  • • ประมวลผลรวดเร็วมาก เหมาะสำหรับส่ง Payload ข้อมูลขนาดใหญ่
  • • ถูกสร้างและใช้อย่างปลอดภัยหลังจบขั้นตอน TLS Handshake
หลักการทำงานของ HTTPS: ผสมผสาน Asymmetric Encryption ในการยืนยันตัวตน และใช้ Symmetric Encryption ในการรับส่งข้อมูลจริง

ใบรับรองดิจิทัลและองค์กรออกใบรับรอง (Certificates & CA)

Public Key Infrastructure (PKI) & Server Authentication

1. Digital Certificate
เอกสารยืนยันตัวตน

ทำหน้าที่คล้ายบัตรประชาชนของเว็บไซต์ บรรจุข้อมูลชื่อโดเมน Public Key และวันหมดอายุ เพื่อยืนยันว่า Client กำลังคุยกับเซิร์ฟเวอร์ตัวจริง

2. Certificate Authority (CA)
องค์กรออกใบรับรอง

หน่วยงานกลางที่เป็นที่น่าเชื่อถือ (เช่น Let's Encrypt, DigiCert) ทำหน้าที่ตรวจสอบความเป็นเจ้าของโดเมนและลงลายมือชื่อดิจิทัลรับรอง

3. Chain of Trust
ห่วงโซ่แห่งความเชื่อมั่น

เบราว์เซอร์จะตรวจสอบใบรับรองย้อนกลับไปถึง Root CA ที่ฝังอยู่ในระบบปฏิบัติการ หากห่วงโซ่ถูกต้อง ป้ายกุญแจเขียวจะปรากฏบนเบราว์เซอร์

ขั้นตอนการทำงานของ TLS Handshake

Establishing a Secure Encrypted Connection

1
ClientHello
ส่งเวอร์ชัน TLS, Cipher Suites และ Random Byte
2
ServerHello
เลือก Cipher Suite, ส่ง Certificate & Public Key
3
Verification
Client ตรวจสอบความถูกต้องของ CA Certificate
4
Key Exchange
คำนวณและสร้าง Symmetric Session Key ร่วมกัน
5
Secure Transfer
เริ่มรับส่งข้อมูล HTTP ที่เข้ารหัสไว้ล่วงหน้า

กระบวนการจับมือนี้เกิดขึ้นบน TCP Port 443 ก่อนที่จะเริ่มส่ง HTTP Request แรก

Security Headers ที่สำคัญบนเว็บ

Protecting Web Applications via HTTP Response Headers

Strict-Transport-Security (HSTS)

บังคับให้เบราว์เซอร์เข้าถึงเว็บไซต์ผ่าน HTTPS เท่านั้น โดยปฏิเสธการเชื่อมต่อแบบ HTTP ในอนาคต

Content-Security-Policy (CSP)

จำกัดแหล่งที่มาของสคริปต์และสคริปต์ภายนอก ป้องกันการโจมตีประเภท Cross-Site Scripting (XSS)

X-Content-Type-Options: nosniff

ป้องกันไม่ให้เบราว์เซอร์สุ่มเดาประเภทไฟล์ (MIME-sniffing) นอกเหนือจากที่กำหนดใน Content-Type

X-Frame-Options: DENY / SAMEORIGIN

ป้องกันไม่ให้หน้าเว็บถูกนำไปแสดงผลใน `<iframe>` เพื่อป้องกันการโจมตีประเภท Clickjacking

สัปดาห์ที่ 1 -- ส่วนที่ 6

เครื่องมือตรวจสอบทราฟฟิกข้อมูลบนเว็บ

Inspection & Debugging Tools: GUI vs CLI

Graphical UI Tools (Browser DevTools)

เครื่องมือตรวจสอบในตัวเบราว์เซอร์ (Chrome, Firefox, Edge)

  • • เหมาะสำหรับดูภาพรวม Network Waterfall, Rendering และ Cookies
  • • แสดงผล Response Body ในรูปแบบสวยงาม (Formatted View)
Command-Line Tools (cURL & Terminal)

เครื่องมือระดับคำสั่งบน Terminal

  • • แม่นยำ รวดเร็ว ไม่มีการโหลดสคริปต์ส่วนเกินของเบราว์เซอร์
  • • เหมาะสำหรับเขียนสคริปต์อัตโนมัติ และทดสอบ API Endpoints

การใช้งาน Browser DevTools (Network Tab)

Visual Network Traffic Inspection & Analysis

1. Headers Tab

แสดง General Info (URL, Method, Status Code), Response Headers และ Request Headers ทั้งหมด

2. Preview & Response Tab

ตรวจสอบ Payload ข้อมูลที่ได้รับกลับมาจากเซิร์ฟเวอร์ ไม่ว่าจะเป็น HTML, JSON หรือรูปภาพ

3. Timing Waterfall

วิเคราะห์ระยะเวลาในแต่ละขั้นตอน: DNS Lookup, Initial Connection, SSL Handshake, และ Waiting (TTFB)

4. Filter & Preserve Log

กรองชนิดไฟล์ (Fetch/XHR, Doc, JS, CSS) และเปิด Preserve Log บันทึกทราฟฟิกข้ามหน้าเปลี่ยน URL

แนะนำเครื่องมือ cURL บน Command Line

Command-Line HTTP Client for Developers

# 1. ส่ง Request พื้นฐานดึงเนื้อหาเว็บ
curl https://httpbin.org/get
# 2. ดูเฉพาะ Response Headers (-I)
curl -I https://httpbin.org/get
# 3. โหมดVerbose แสดงทั้ง Request/Response Headers แบบละเอียด (-v)
curl -v https://httpbin.org/get
# 4. ส่ง HTTP POST พร้อมแนบข้อมูล JSON (-X POST -H -d)
curl -X POST https://httpbin.org/post -H "Content-Type: application/json" -d '{"title":"Django"}'

วิเคราะห์ HTTP Traffic ด้วย cURL ในทางปฏิบัติ

Hands-on CLI Examples: HTML vs JSON Response

ดึงข้อมูล HTML Page
curl -I https://www.django-project.com/
  • • Status: HTTP/2 200 OK
  • • Content-Type: text/html; charset=utf-8
ดึงข้อมูล JSON API Payload
curl -s https://api.github.com/users/octocat
  • • Status: HTTP/2 200 OK
  • • Content-Type: application/json

การจัดเตรียมสภาพแวดล้อมบนเครื่องเดี่ยว

Single PC Development Setup for Full-Stack Course

1. Terminal & CLI

Windows (WSL2 / PowerShell), macOS Terminal หรือ Linux Terminal

2. Python 3.x & Virtualenv

ติดตั้ง Python เวอร์ชันล่าสุด พร้อมใช้งาน `venv` สำหรับจัดการแพ็กเกจประจำโปรเจกต์

3. Scoop Package Manager

เครื่องมือจัดการซอฟต์แวร์แบบ Command-Line บน Windows สำหรับติดตั้งเครื่องมือต่างๆ ได้สะดวกรวดเร็ว

สัปดาห์ที่ 1 -- ส่วนที่ 7

สรุปประเด็นสำคัญสัปดาห์ที่ 1

Week 1 Key Takeaways & Core Concepts

Client-Server

แยกส่วน Frontend และ Backend เพื่อหลักการ Separation of Concerns

IP & DNS

DNS แปลงชื่อโดเมนเป็น IP Address ปลายทางเพื่อเริ่มสร้าง Connection

HTTP & HTTPS

Stateless Protocol เข้ารหัสความปลอดภัยข้อมูลระหว่างทางด้วย TLS/SSL

DevTools & cURL

ใช้ตรวจทราฟฟิก Headers, Status Codes และ Payload Response

งานปฏิบัติการและโจทย์ศึกษาด้วยตนเอง

Weekly Lab Exercise & Self-Study Guidelines (5 Hours/Week)

1. งานปฏิบัติการในชั้นเรียน (Lab 1)

  • • ใช้คำสั่ง curl -I ส่ง Request ไปยังเว็บไซต์ที่กำหนด แล้วบันทึกค่า Response Headers
  • • เปิด Browser DevTools ตรวจสอบการส่ง Network Request และแคปเจอร์ภาพผลลัพธ์

2. หัวข้อศึกษาด้วยตนเอง (5 ชม./สัปดาห์)

  • • อ่านเอกสารประกอบเกี่ยวกับวงจรชีวิตการทำงานของ DNS Lookup
  • • ทดลองแก้ไขไฟล์ Local Hosts (`/etc/hosts`) บนเครื่องตนเองเพื่อแมปโดเมนจำลอง
เกริ่นนำบทเรียนครั้งต่อไป

สัปดาห์ที่ 2: REST API & HTTPie Tools

REST Architecture, HTTPie CLI / Desktop & Scoop Installation

หัวข้อที่จะเรียนรู้ในสัปดาห์ที่ 2:

  • • สถาปัตยกรรม REST API: การออกแบบ Resource-Oriented URLs, HTTP Methods และ Status Codes ตามมาตรฐาน
  • • การติดตั้งผ่าน Scoop Package Manager: ฝึกใช้ Scoop ติดตั้งโปรแกรม **HTTPie CLI** และ **HTTPie Desktop**
  • • การทดสอบ API ด้วย HTTPie: ฝึกส่ง GET, POST, PUT, DELETE Request พร้อมแนบ Headers และ JSON Payload