OSI Layer 7 of 7

Application Layer

ชั้นที่โปรแกรมใช้บริการเครือข่าย ครอบคลุม Web, HTTP/HTTPS, การส่งไฟล์, Email, DNS, ระบบ Peer-to-Peer และการนัดหมายเพื่อสื่อสารด้วยภาพและเสียงแบบ real-time

🔗

เทียบเท่าใน TCP/IP: Application Layer (รวมกับ Session+Presentation) — อ่านฉบับกระชับ →

1หลักการของ Network Applications

เมื่อผู้ใช้เปิดเว็บไซต์ ส่งอีเมล ประชุมออนไลน์ หรือดาวน์โหลดไฟล์ สิ่งที่กำลังสื่อสารกันจริง ๆ ไม่ใช่ผู้ใช้กับเครือข่ายโดยตรง แต่เป็น process ของโปรแกรมสองฝั่ง Application Layer กำหนดว่ากระบวนการเหล่านั้นจะส่งข้อความชนิดใด เรียงข้อมูลอย่างไร และเมื่อได้รับข้อความแล้วควรทำอะไรต่อ

อุปมา: ร้านอาหารกับบทสนทนา

การเชื่อมต่อเครือข่ายเหมือนมีโทรศัพท์ที่โทรถึงร้านอาหารได้ แต่โทรติดไม่ได้แปลว่าสั่งอาหารสำเร็จ เรายังต้องรู้ว่าจะพูดอะไร ร้านต้องถามอะไรกลับ เมนูเขียนอย่างไร และคำว่า “หนึ่งชุด” หมายถึงอะไร Transport ช่วยเปิดช่องทาง ส่วน Application protocol กำหนดบทสนทนาที่เกิดขึ้นบนช่องทางนั้น

	Client-Server	Peer-to-Peer (P2P)
บทบาท	Client ขอใช้บริการ ส่วน server รอรับคำขอและให้บริการ	แต่ละ peer อาจเป็นทั้งผู้ขอและผู้ให้ทรัพยากร
จุดศูนย์กลาง	มี server หรือกลุ่ม server ที่รู้ตำแหน่งและควบคุมบริการ	อาจไม่มีศูนย์กลางเลย หรือมีเพียงบางหน้าที่ที่ยังรวมศูนย์
การขยายระบบ	เพิ่มเครื่อง server, load balancer, cache หรือ CDN	Peer ใหม่อาจนำทั้งความต้องการและทรัพยากรเข้ามา จึงมีโอกาสเกิด self-scalability
การดูแล	ควบคุม version, policy และข้อมูลได้ง่ายกว่า	ต้องรับมือกับ peer ที่ไม่น่าเชื่อถือ อยู่ไม่นาน หรืออยู่หลัง NAT

Process ต่างเครื่องคุยกันด้วยการแลกเปลี่ยน message ปลายทางระดับ Transport มักระบุด้วย IP address และ port number เพราะเครื่องเดียวเปิดหลายบริการพร้อมกันได้ IP ช่วยพาไปถึงเครื่อง ส่วน port ช่วยส่งต่อไปยัง process ที่ถูกต้อง เหมือนที่อยู่พาไปถึงอาคาร และเลขห้องพาไปถึงคนที่ต้องการพบ

Application protocol ต้องตกลงอย่างน้อยสี่เรื่อง

ชนิดข้อความ: มี request, response, notification หรือ error แบบใดบ้าง
Syntax: แต่ละช่องอยู่ตำแหน่งใด เขียนเป็นข้อความหรือ binary และจบข้อความตรงไหน
Semantics: ค่าที่ส่งหมายถึงอะไร เช่น 404 หมายถึงหา resource ไม่พบ ไม่ได้หมายถึงเครือข่ายขาด
กติกาการแลกเปลี่ยน: ใครเริ่มก่อน ต้องตอบเมื่อใด ส่งซ้ำได้หรือไม่ และทำอย่างไรเมื่อข้อความไม่ครบ

งาน	สิ่งที่ให้ความสำคัญ	สิ่งที่พอยอมได้
File transfer และการอัปเดตโปรแกรม	ข้อมูลต้องถูกทุก byte	รอเพิ่มได้บ้าง
Email และ Web document	ข้อมูลครบและลำดับถูก	ความล่าช้าระดับหนึ่ง
ถ่ายทอดสด	เล่นต่อเนื่องและตามเหตุการณ์ทัน	ลดคุณภาพหรือหน่วงเล็กน้อย
ประชุม real-time	latency ต่ำ เสียงต่อเนื่อง และโต้ตอบทัน	ภาพลด resolution หรือ frame rate ได้

คำว่า “เครือข่ายดี” จึงไม่ได้มีคำตอบเดียว งานส่งไฟล์อาจยอมรอเพื่อให้ข้อมูลครบ แต่งานประชุมไม่ควรรอ packet เก่าจนบทสนทนาช้าไปหลายวินาที Application เป็นผู้รู้ว่าข้อมูลกำลังถูกใช้ทำอะไร และต้องเลือกบริการให้เหมาะกับงานนั้น

2Web และ HTTP

HTTP คืออะไร

HTTP — Hypertext Transfer Protocol กำหนดวิธีที่ client ส่ง request เพื่อขอ resource และ server ส่ง response กลับ Resource อาจเป็น HTML, CSS, JavaScript, รูปภาพ, JSON หรือไฟล์ชนิดอื่น HTTP แบบไม่เข้ารหัสมักใช้ port 80 ส่วน HTTPS มักใช้ port 443

HTTP มักถูกเรียกว่าเป็น stateless protocol หมายความว่า request แต่ละครั้งควรมีข้อมูลพอให้ server เข้าใจได้โดยไม่ต้องอาศัยความจำจาก request ก่อนหน้า แต่ไม่ได้แปลว่า Web application ห้ามจำผู้ใช้ ระบบยังสร้าง state ผ่าน cookie, session database หรือ token ได้ เพียงแต่ state นั้นเป็นกลไกที่สร้างเพิ่มเหนือ HTTP

อุปมา: ยื่นแบบฟอร์มทีละใบ

HTTP คล้ายเคาน์เตอร์ที่รับเอกสารทีละใบ เจ้าหน้าที่อ่านแบบฟอร์มปัจจุบันแล้วตอบกลับ หากต้องการให้จำว่าเป็นลูกค้าคนเดิม ระบบต้องให้บัตรคิวหรือรหัสสมาชิกติดมาด้วย Cookie จึงไม่ใช่การทำให้ HTTP เลิกเป็น stateless แต่เป็นการส่งตัวอ้างอิงของ state มากับ request แต่ละครั้ง

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

Request มี method, target, version, header และอาจมี body ส่วน response มี status code, header และ body การแยก header ออกจาก body ทำให้ข้อมูลกำกับกับเนื้อหามีหน้าที่ชัดเจน

GET /courses/network/ HTTP/1.1
Host: example.edu
Accept: text/html
Accept-Encoding: gzip, br
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 4210
Cache-Control: max-age=3600

<!doctype html> ...

Method	ความตั้งใจ	ข้อสังเกต
`GET`	อ่านหรือขอ representation ของ resource	ควรเป็น safe และไม่เปลี่ยนสถานะสำคัญของระบบ
`HEAD`	ขอเฉพาะ header โดยไม่รับ body	ใช้ตรวจ metadata หรือความเปลี่ยนแปลง
`POST`	ส่งข้อมูลให้ server ประมวลผลหรือสร้างผลลัพธ์	เรียกซ้ำอาจเกิดผลซ้ำ เช่น สร้างคำสั่งซื้อสองรายการ
`PUT`	สร้างหรือแทน representation ที่ URI ระบุ	โดยแนวคิดควร idempotent คือทำซ้ำแล้วได้สถานะปลายทางเดิม
`PATCH`	แก้บางส่วนของ resource	รูปแบบของ patch ต้องตกลงกัน
`DELETE`	ขอลบ resource	สิทธิ์และผลจริงขึ้นกับ application

Safe กับ idempotent ไม่ใช่คำเดียวกัน Safe หมายถึงตั้งใจไม่ให้เปลี่ยนสถานะของ resource ส่วน idempotent หมายถึงส่งคำขอเดิมซ้ำหลายครั้งแล้วสถานะสุดท้ายควรเหมือนส่งครั้งเดียว ความแตกต่างนี้สำคัญเมื่อ client ไม่แน่ใจว่า request ก่อนหน้าถึง server หรือไม่

	Non-Persistent	Persistent
จำนวน object/connection	อย่างมาก 1	หลาย object ผ่าน connection เดียว
Response time	`2×RTT + transmission time` ต่อ object	อย่างน้อย 1 RTT รวม

สูตร 2×RTT เป็นแบบจำลองอย่างง่ายของ HTTP แบบเดิมบน TCP: หนึ่ง RTT สำหรับ TCP handshake และอีกหนึ่ง RTT สำหรับ request ไปถึง server กับ byte แรกของ response เดินทางกลับ ยังไม่รวม DNS, TLS handshake, queueing, server processing และเวลาส่งข้อมูลจริง จึงควรใช้เพื่อเห็นโครงสร้างของต้นทุน ไม่ใช่ทำนายเวลาเปิดเว็บจริงแบบตายตัว

HTTP/1.1, HTTP/2 และ HTTP/3 แก้คอขวดคนละจุด

รุ่น	แนวคิดหลัก	ข้อจำกัดที่ควรรู้
HTTP/1.1	ใช้ persistent connection เป็นหลัก ลดการเปิด TCP ซ้ำ	การส่งคำขอต่อกันอาจติดคิว และ browser มักเปิดหลาย connection ช่วย
HTTP/2	แบ่งข้อมูลเป็น binary frame และ multiplex หลาย stream ใน TCP connection เดียว	เมื่อ TCP packet หาย stream อื่นยังอาจรอร่วมกัน เพราะ TCP ต้องคืนลำดับ byte
HTTP/3	ใช้ QUIC บน UDP แยก stream และรวมการตั้งค่าความปลอดภัยไว้ใน connection	ซับซ้อนขึ้น และอาศัยการรองรับ QUIC จากทุกส่วนบนเส้นทาง

การบอกว่า HTTP/3 ใช้ UDP ไม่ได้แปลว่าเลิกสนใจความถูกต้อง QUIC สร้าง reliability, congestion control, stream management และ security เหนือ UDP เอง เหตุผลที่ใช้ UDP คือเปิดพื้นที่ให้พัฒนา transport ใน user space ได้คล่องขึ้น ไม่ใช่เพราะอยากส่งข้อมูลแบบตามมีตามเกิด

Status Code บอกว่าผลเกิดขึ้นที่ระดับใด

กลุ่ม	ความหมาย	ตัวอย่าง
`1xx`	ข้อมูลชั่วคราวระหว่างดำเนินการ	100 Continue
`2xx`	คำขอสำเร็จ	200 OK, 201 Created, 204 No Content
`3xx`	เปลี่ยนเส้นทางหรือใช้สำเนาเดิม	301 Moved Permanently, 304 Not Modified
`4xx`	คำขอจาก client ใช้ไม่ได้หรือไม่มีสิทธิ์	400, 401, 403, 404
`5xx`	server ทำงานตามคำขอไม่ได้	500, 502, 503

401 Unauthorized มีชื่อที่ชวนให้แปลว่า “ไม่มีสิทธิ์” แต่โดยการใช้งานมักหมายถึงยังไม่ได้ยืนยันตัวตนหรือข้อมูลยืนยันไม่ผ่าน ส่วน 403 Forbidden คือ server เข้าใจคำขอแล้วแต่ไม่อนุญาต การแปลศัพท์ตรงตัวโดยไม่ดูความหมายใน protocol จึงพาไปผิดห้องได้ง่าย ๆ

Cookie, Session และ Token

การจำผู้ใช้บน HTTP ที่ไม่จำอดีต

Server ส่ง Set-Cookie ให้ browser เก็บค่า และ browser ส่งค่าเดิมกลับผ่าน Cookie ใน request ถัดไป ค่านั้นอาจเป็น session ID ที่อ้างถึงข้อมูลในฐานข้อมูล ไม่ควรใส่ข้อมูลลับแบบอ่านได้ตรง ๆ เพียงเพราะมันอยู่ใน cookie

คุณสมบัติ Cookie	หน้าที่
`Secure`	ส่ง cookie ผ่าน HTTPS เท่านั้น
`HttpOnly`	ไม่ให้ JavaScript อ่านโดยตรง ช่วยลดผลกระทบบางส่วนจาก XSS
`SameSite`	ควบคุมการส่ง cookie ข้าม site ช่วยลด CSRF ตามรูปแบบการตั้งค่า
`Expires/Max-Age`	กำหนดอายุของ cookie

Token แบบ bearer มีหลักง่าย ๆ ว่า “ใครถือก็ใช้ได้” จึงต้องป้องกันไม่ให้รั่ว การเลือก session cookie หรือ token ไม่ได้ทำให้ระบบปลอดภัยเอง ความปลอดภัยยังขึ้นกับที่เก็บ อายุ การเพิกถอน ขอบเขตสิทธิ์ และช่องทางที่ใช้ส่ง

Web Cache และ Conditional Request

ไม่ต้องส่งของเดิม หากยังใช้ของเดิมได้

Cache เก็บสำเนา response ไว้ใกล้ผู้ใช้ เมื่อยังสดอยู่ก็ส่งสำเนาได้ทันที หากต้องตรวจสอบกับ origin server อาจใช้ If-Modified-Since หรือ If-None-Match พร้อม ETag ถ้าข้อมูลไม่เปลี่ยน server ตอบ 304 Not Modified โดยไม่ต้องส่ง body ซ้ำ

Cache อาจอยู่ใน browser, proxy, CDN หรือ gateway ค่า Cache-Control ช่วยบอกว่าเก็บได้นานเท่าใด เก็บใน cache ร่วมได้หรือไม่ และต้องตรวจสอบก่อนใช้หรือเปล่า Cache ช่วยทั้ง latency, bandwidth และภาระ origin แต่ถ้ากำหนดผิดก็อาจแสดงข้อมูลเก่า หรือเก็บข้อมูลส่วนตัวในที่ที่ผู้ใช้อื่นเข้าถึงได้

อุปมา: หนังสือสำรองหน้าห้อง

ถ้านักศึกษาทุกคนต้องเดินไปยืมหนังสือเล่มเดียวจากหอสมุดกลาง คิวจะยาว การวางสำเนาไว้หน้าห้องช่วยให้หยิบได้เร็ว แต่ต้องมีวิธีรู้ว่าอาจารย์ออกฉบับแก้ไขแล้วหรือยัง ETag คล้ายเลขฉบับ ถ้าเลขยังเดิมก็ใช้สำเนาต่อได้ โดยไม่ต้องขนหนังสือทั้งเล่มมาเทียบใหม่

จาก HTTP ไปเป็น HTTPS

HTTPS ไม่ใช่ protocol สำหรับสร้างหน้าเว็บอีกชุดหนึ่ง แต่คือ HTTP ที่เดินทางผ่านช่องทางซึ่ง TLS ป้องกันไว้ HTTP/1.1 และ HTTP/2 มักใช้ TLS เหนือ TCP ส่วน HTTP/3 ใช้ QUIC ซึ่งรวม TLS 1.3 เข้าไว้ในกระบวนการตั้ง connection

TLS เพิ่มหลักประกันสำคัญสามด้าน

Confidentiality: เข้ารหัสเนื้อหา ไม่ให้ผู้ดักฟังอ่าน request, response, cookie หรือรหัสผ่านได้ง่าย
Integrity: ตรวจว่าข้อมูลถูกแก้ระหว่างทางหรือไม่
Authentication: Client ตรวจว่า public key ที่ได้รับผูกกับชื่อเว็บไซต์ตาม certificate chain ที่เชื่อถือได้หรือไม่

ภาพรวม TLS Handshake

Client ส่งความสามารถที่รองรับ เช่น TLS version, cipher suites และข้อมูลสำหรับ key exchange
Server เลือกค่าที่ใช้ ส่ง certificate และข้อมูลที่ช่วยพิสูจน์ว่าครอบครอง private key
Client ตรวจชื่อโดเมน วันหมดอายุ ลายเซ็น และสายโซ่จาก certificate ไปยัง CA ที่เชื่อถือ
ทั้งสองฝั่งคำนวณ shared secret แล้วสร้าง session keys
ข้อมูล HTTP หลังจากนั้นถูกเข้ารหัสและตรวจความถูกต้องด้วย symmetric cryptography ซึ่งเหมาะกับข้อมูลจำนวนมาก

อุปมา: ซองจดหมายที่มีตรารับรอง

HTTP ธรรมดาเหมือนโปสการ์ด คนระหว่างทางอ่านและแก้ข้อความได้ HTTPS เหมือนตกลงสร้างกล่องที่ล็อกด้วยกุญแจเฉพาะการสนทนา พร้อมตรวจเอกสารว่าปลายทางควบคุมชื่อที่ต้องการติดต่ออยู่ แต่ certificate รับรองความสัมพันธ์ระหว่างกุญแจกับชื่อ ไม่ได้รับรองว่าเจ้าของเว็บไซต์เป็นคนดี เว็บหลอกลวงก็มี HTTPS ได้เช่นกัน

HTTPS ป้องกันอะไร และไม่ได้ป้องกันอะไร

ข้อมูลหรือความเสี่ยง	HTTPS ช่วยอย่างไร	ข้อจำกัด
หน้าเว็บ รหัสผ่าน และ cookie ระหว่างทาง	เข้ารหัสและตรวจ integrity	ปลายทางหรือเครื่องผู้ใช้ที่ถูกยึดยังอ่านข้อมูลได้
ผู้โจมตีปลอมเป็นเว็บไซต์กลางทาง	ตรวจ certificate, hostname และกุญแจ	ผู้ใช้อาจเข้าโดเมนสะกดคล้ายที่ผู้โจมตีเป็นเจ้าของจริง
IP address และรูปแบบ traffic	ไม่ได้ซ่อนด้วย HTTPS ปกติ	ผู้สังเกตยังเห็น IP เวลา และปริมาณข้อมูลโดยประมาณ
Malware หรือ phishing บนเว็บไซต์	ส่งเนื้อหาจากเว็บไซต์นั้นอย่างปลอดภัย	ช่องทางปลอดภัยไม่ได้แปลว่าเนื้อหาสุจริต

Redirect, HSTS และ Mixed Content

เว็บไซต์อาจรับ HTTP แล้ว redirect ไป HTTPS แต่ request แรกยังอาจถูกแทรกแซงได้ HSTS บอก browser ว่าโดเมนนี้ควรใช้ HTTPS เท่านั้นในช่วงเวลาที่กำหนด ส่วน preload list ช่วยให้ browser บางตัวรู้กติกาก่อนเข้าครั้งแรก

Mixed content เกิดเมื่อหน้า HTTPS ดึง resource บางรายการผ่าน HTTP ช่องทางหลักอาจล็อกประตูแล้ว แต่กลับเปิดหน้าต่างทิ้งไว้ โดยเฉพาะ JavaScript ที่ถูกแก้แล้วอาจทำงานแทนหน้าเว็บ Browser จึงมักบล็อกหรือยกระดับ resource เหล่านี้

ประเด็นที่มักตอบสลับกัน

HTTPS ไม่ได้แทนการ login TLS certificate ช่วยให้ client ตรวจตัวตนของ server เป็นหลัก ส่วนการยืนยันตัวผู้ใช้เป็นกลไกระดับ application อีกชุดหนึ่ง รูปแม่กุญแจก็ไม่ได้รับรองว่าเว็บไซต์ไม่มีช่องโหว่ มันบอกว่ากำลังคุยกับชื่อที่ตรวจสอบได้ผ่านช่องทางที่ถูกป้องกัน

3FTP — File Transfer Protocol

แยกช่องคำสั่งออกจากช่องส่งข้อมูล

Client เปิด control connection ไปยัง server ที่ port 21 แล้วใช้ช่องนี้ส่งคำสั่งและรับรหัสตอบกลับ ส่วนรายชื่อไฟล์หรือเนื้อหาไฟล์เดินทางผ่าน data connection แยกต่างหาก FTP แบบ active มีความเกี่ยวข้องกับ server port 20 แต่แบบ passive ให้ client เชื่อมไปยัง port ที่ server ประกาศ จึงไม่ควรจำว่า data connection ทุกกรณีต้องใช้ port 20

FTP server เก็บ state ของการใช้งาน เช่น ผู้ใช้ปัจจุบันและ directory ปัจจุบัน ต่างจากแนวคิด stateless ของ HTTP การแยก control กับ data ดูเป็นระเบียบ แต่ทำให้ firewall และ NAT ต้องเข้าใจ connection มากกว่าหนึ่งช่อง ในงานทั่วไปจึงพบ HTTPS download, SFTP หรือบริการ object storage แทน FTP มากขึ้น ทั้งนี้ SFTP เป็น protocol ส่งไฟล์เหนือ SSH ไม่ใช่ FTP ที่เพียงเติมตัว S ข้างหน้า

4Electronic Mail

ระบบอีเมลไม่ได้ใช้ protocol เดียวทำทุกอย่าง การส่งออก การส่งต่อระหว่างองค์กร และการเปิดอ่านกล่องจดหมายเป็นคนละช่วง จึงใช้ protocol คนละชุด หากมองทุกอย่างว่าเป็น “ส่งเมล” เราจะสับสนทันทีว่า SMTP, POP3 และ IMAP ซ้ำกันทำไม

อุปมา: ระบบไปรษณีย์

SMTP เหมือนรถไปรษณีย์ที่รับจดหมายจากที่ทำการหนึ่งแล้วส่งต่อไปยังที่ทำการปลายทาง ส่วน POP3 และ IMAP เหมือนวิธีที่เจ้าของตู้ไปรษณีย์เปิดอ่านจดหมายของตน คนส่งไม่จำเป็นต้องใช้กุญแจเปิดตู้ของผู้รับ และผู้รับก็ไม่ต้องขับรถไปคัดแยกจดหมายเอง

เส้นทางของอีเมลหนึ่งฉบับ

ผู้ใช้เขียนจดหมายใน Mail User Agent (MUA) เช่นโปรแกรมหรือหน้า Webmail
โปรแกรมส่งจดหมายไปยัง Mail Submission Agent ของผู้ให้บริการ โดยมักยืนยันตัวตนก่อน
Mail server ดู domain หลังเครื่องหมาย @ แล้วถาม DNS หา MX record
Mail Transfer Agent (MTA) ใช้ SMTP ส่งจดหมายไปยัง MTA ของ domain ปลายทาง อาจผ่าน server กลางมากกว่าหนึ่งตัว
ปลายทางส่งจดหมายเข้า mailbox ของผู้รับ
ผู้รับอ่านและจัดการจดหมายผ่าน IMAP, POP3 หรือ Webmail

SMTP — ส่งและส่งต่อจดหมาย

SMTP เป็น protocol แบบ push ฝ่ายส่งเป็นผู้เปิดการเชื่อมต่อและผลักจดหมายไปยัง server ถัดไป การส่งระหว่าง mail server มักใช้ TCP port 25 ส่วนการส่งจากโปรแกรมผู้ใช้เข้าสู่บริการ mail มักใช้ message submission ที่ port 587 และอาจใช้ TLS กับการยืนยันตัวตน

SMTP Conversation: คุยกับซองก่อนคุยกับเนื้อหา

S: 220 mail.example.org ESMTP ready
C: EHLO client.example.net
S: 250-mail.example.org
C: MAIL FROM:<[email protected]>
S: 250 OK
C: RCPT TO:<[email protected]>
S: 250 OK
C: DATA
S: 354 End data with <CRLF>.<CRLF>
C: Subject: Meeting
C:
C: See you at 10:00.
C: .
S: 250 Message accepted

MAIL FROM และ RCPT TO เป็นข้อมูลบน envelope ที่ระบบส่งต่อใช้ ส่วน From:, To: และ Subject: อยู่ใน header ของตัวจดหมาย ทั้งสองส่วนอาจไม่เหมือนกันทุกประการ เหมือนชื่อบนซองกับข้อความหัวกระดาษซึ่งมีหน้าที่คนละอย่าง การกรอง spam และการตรวจสอบผู้ส่งจึงต้องพิจารณามากกว่าช่อง From ที่ผู้ใช้มองเห็น

MIME: ทำให้อีเมลส่งได้มากกว่าข้อความ ASCII

SMTP ดั้งเดิมออกแบบมาสำหรับข้อความ 7-bit ขณะที่อีเมลจริงมีภาษาไทย HTML รูปภาพ และไฟล์แนบ MIME — Multipurpose Internet Mail Extensions เพิ่ม header เพื่อบอกชนิดข้อมูล การเข้ารหัส และขอบเขตของแต่ละส่วน เช่น Content-Type, Content-Transfer-Encoding และ multipart boundary

ทำไมไฟล์แนบจึงใหญ่กว่าต้นฉบับ

ข้อมูล binary มักถูกแปลงเป็น Base64 เพื่อเดินทางผ่านระบบข้อความได้ปลอดภัยขึ้น Base64 ใช้อักขระ 4 ตัวแทนข้อมูล 3 byte จึงเพิ่มขนาดโดยหลักประมาณหนึ่งในสาม ยังไม่รวม header และขอบเขตของ MIME ไฟล์ 15 MB จึงอาจกลายเป็นอีเมลที่ใหญ่กว่า 20 MB ได้

POP3 กับ IMAP ตอบโจทย์คนละยุค

ประเด็น	POP3	IMAP
แนวคิด	ดาวน์โหลดจดหมายจาก mailbox มายังเครื่องผู้ใช้	จัดการ mailbox ที่อยู่บน server และซิงโครไนซ์มุมมองกับ client
State บน server	ค่อนข้างน้อย และไม่ได้ออกแบบมาเพื่อโครงสร้าง folder ซับซ้อน	เก็บ folder, flag, สถานะอ่านแล้ว และลำดับของข้อความข้าม session
หลายอุปกรณ์	ทำได้แต่ไม่เป็นธรรมชาติ โดยเฉพาะเมื่อใช้ download-and-delete	เหมาะกว่า เพราะโทรศัพท์และคอมพิวเตอร์เห็น mailbox ชุดเดียวกัน
การทำงาน offline	จดหมายที่ดาวน์โหลดแล้วเปิดได้ในเครื่อง	Client อาจ cache จดหมายบางส่วนเพื่อใช้ offline แล้วซิงโครไนซ์ภายหลัง
Port ที่พบบ่อย	110 หรือ 995 เมื่อใช้ TLS โดยตรง	143 หรือ 993 เมื่อใช้ TLS โดยตรง

การบอกว่า POP3 “ต้องดาวน์โหลดแล้วลบเสมอ” ไม่แม่นนัก เพราะ client สามารถตั้งให้เก็บสำเนาไว้บน server ได้ แก่นของความต่างคือ POP3 เน้นรับข้อความลงมา ส่วน IMAP ออกแบบให้จัดการ mailbox บน server และรักษา state ระหว่างหลาย client

Store-and-Forward: ผู้รับไม่ต้องออนไลน์พร้อมผู้ส่ง

อีเมลต่างจากการโทรศัพท์ตรงที่ปลายทางไม่ต้องพร้อมในขณะส่ง Mail server รับจดหมายเข้า queue แล้วพยายามส่งต่อ หาก server ปลายทางล่มชั่วคราวก็รอและลองใหม่ได้ นี่คือ store-and-forward ความล่าช้าจึงยอมรับได้มากกว่า real-time แต่ต้องมีการกำหนดเวลาลองใหม่ อายุของ queue และข้อความแจ้งเมื่อส่งไม่สำเร็จ

ความปลอดภัยของอีเมลมีหลายขอบเขต

TLS ช่วยป้องกันช่องทางระหว่าง client กับ mail server หรือระหว่าง server ใน hop ที่ใช้งาน แต่ไม่ได้แปลว่าเนื้อหาถูกเข้ารหัสแบบ end-to-end เสมอ Mail server ที่รับและส่งต่ออาจยังอ่านเนื้อหาได้ ส่วน SPF, DKIM และ DMARC ช่วยตรวจนโยบายและแหล่งที่มาของ domain เพื่อลดการปลอมผู้ส่ง แต่ไม่ได้รับรองว่าทุกข้อความจาก domain ที่ผ่านการตรวจนั้นปลอดภัยหรือเป็นความจริง

5DNS — Domain Name System

DNS คือฐานข้อมูลชื่อแบบลำดับชั้นและกระจายหลายแห่ง

DNS แปลงชื่อที่มนุษย์อ่านง่ายให้เป็นข้อมูลที่ระบบต้องใช้ เช่น IP address หรือชื่อ mail server หากรวมทุกชื่อไว้ที่ศูนย์กลางเดียว จะเกิดทั้งจุดล้มเหลว คอขวด ปัญหาระยะทาง และภาระดูแล DNS จึงแบ่งอำนาจตามลำดับชั้นและอนุญาตให้แต่ละ domain ดูแลข้อมูลของตน

อุปมา: ถามที่อยู่แบบแบ่งเขต

เราไม่จำเป็นต้องมีเจ้าหน้าที่คนเดียวจำที่อยู่ทุกบ้านในโลก Root รู้ว่าจะไปถามผู้ดูแลนามสกุลอย่าง .th ที่ไหน ผู้ดูแล .th รู้ว่าจะไปถามผู้มีอำนาจของ domain ใด และ authoritative server จึงตอบข้อมูลของชื่อจริง โครงสร้างนี้ไม่ได้ทำให้ทุกคนรู้ทุกอย่าง แต่ทำให้รู้ว่า “ควรถามใครต่อ”

ชื่อ Domain เป็นลำดับชั้นที่อ่านจากขวาไปซ้าย

ในชื่อ www.example.ac.th ส่วน th อยู่ใต้ root, ac อยู่ภายใต้ th, example อยู่ภายใต้ ac.th และ www เป็นชื่อที่ zone นั้นกำหนด จุดแบ่งการบริหารเรียกว่า delegation ผู้ดูแล domain หนึ่งจึงมอบหมาย subdomain ให้คนอื่นดูแลต่อได้

ระดับ	หน้าที่
Root name server identities	มี 13 ชื่อเชิงตรรกะตั้งแต่ A ถึง M แต่แต่ละชื่อให้บริการด้วยเครื่องจริงหลายแห่งทั่วโลกผ่าน anycast ทำหน้าที่ชี้ไปยังระบบของ TLD
TLD name servers	ดูแลการมอบหมายภายใต้ top-level domain เช่น `.com`, `.org` และ `.th`
Authoritative name servers	ให้คำตอบที่เป็นทางการสำหรับ zone ที่ตนรับผิดชอบ
Recursive resolver	รับคำถามจากเครื่องผู้ใช้ เดินค้นตามลำดับชั้น และเก็บผลไว้ใน cache

ตัวอย่างการค้นหา `www.example.com`

Browser และระบบปฏิบัติการตรวจ cache ของตนก่อน
ถ้าไม่พบ เครื่องส่งคำถามแบบ recursive ไปยัง resolver ที่ตั้งค่าไว้
Resolver ถาม root และได้รับ referral ว่าควรไปถาม name server ของ .com
Resolver ถาม .com แล้วได้รับ referral ไปยัง authoritative server ของ example.com
Authoritative server ตอบ record ของ www.example.com
Resolver ส่งคำตอบกลับ client และเก็บไว้ตาม TTL เพื่อใช้กับคำถามถัดไป

Iterative กับ Recursive Query

Iterative คือผู้ถูกถามตอบข้อมูลที่ดีที่สุดที่มี หรือบอกว่าให้ไปถามใครต่อ ส่วน recursive คือผู้ถูกถามรับหน้าที่หาคำตอบสุดท้ายให้ เครื่องผู้ใช้มักถาม recursive resolver แบบ recursive แต่ resolver เดินถาม root, TLD และ authoritative server แบบ iterative เพื่อลดภาระของระบบชั้นบน

Resource Record ที่พบได้บ่อย

Record	ความหมาย	ตัวอย่างการใช้
`A`	ชื่อ → IPv4 address	ชี้ Web server หรือบริการอื่น
`AAAA`	ชื่อ → IPv6 address	บริการเดียวกันบน IPv6
`NS`	ระบุ authoritative name server ของ zone	ใช้ในการ delegation
`CNAME`	กำหนดชื่อหนึ่งให้เป็น alias ของอีกชื่อ	`www` อ้างไปยังชื่อ canonical
`MX`	ระบุ mail exchanger พร้อมลำดับความสำคัญ	SMTP ใช้หา mail server ของ domain ปลายทาง
`TXT`	เก็บข้อความตามวัตถุประสงค์ของระบบ	พบใน SPF และการยืนยันความเป็นเจ้าของ domain
`PTR`	ทำ reverse lookup จาก address ไปเป็นชื่อ	ใช้ประกอบการตรวจสอบระบบและ mail server

Cache และ TTL: คำตอบเร็วขึ้น แต่ไม่เปลี่ยนพร้อมกันทั้งโลก

แต่ละ record มี TTL — Time to Live บอกว่า cache เก็บคำตอบได้นานเท่าใด TTL ยาวลดจำนวน query และภาระ authoritative server แต่เมื่อเปลี่ยน IP ผู้ใช้บางส่วนอาจยังเห็นค่าเก่าจน TTL หมด TTL สั้นช่วยให้เปลี่ยนเร็วขึ้น แต่เพิ่ม traffic การตั้ง TTL จึงเป็นการแลกระหว่างความสดกับต้นทุน ไม่ใช่ตั้งให้สั้นที่สุดแล้วจะดีที่สุดเสมอ

Negative caching เก็บผลว่า “ไม่พบชื่อนี้” ชั่วคราวด้วย หากไม่มี negative cache ชื่อที่พิมพ์ผิดหรือไม่มีอยู่จะทำให้ resolver ถามซ้ำตลอด แต่เมื่อเพิ่งสร้างชื่อใหม่ ผู้ใช้อาจยังได้คำตอบว่าไม่พบจน cache เดิมหมดอายุเช่นกัน

DNS ใช้ UDP หรือ TCP

DNS query ทั่วไปมักเริ่มด้วย UDP เพราะ overhead ต่ำ แต่ DNS ใช้ TCP ได้เมื่อคำตอบมีขนาดหรือเงื่อนไขที่ต้องการ และการโอนข้อมูล zone ใช้ TCP ตามลักษณะงาน อย่าจำว่า DNS เท่ากับ UDP เท่านั้น ระบบสมัยใหม่ยังมี DNS over TLS และ DNS over HTTPS เพื่อป้องกัน query บนช่วงระหว่าง client กับ resolver ที่เลือกใช้

ความปลอดภัย: ความลับกับความถูกต้องเป็นคนละเรื่อง

กลไก	สิ่งที่ช่วย	สิ่งที่ไม่ได้แก้ทั้งหมด
DNSSEC	ใช้ลายเซ็นช่วยตรวจที่มาและความครบถ้วนของ DNS data ตามสายโซ่ความเชื่อถือ	ไม่ได้เข้ารหัสชื่อที่ถาม และไม่ได้รับรองว่า server ปลายทางปลอดภัย
DoT / DoH	เข้ารหัสช่องทางระหว่าง client กับ recursive resolver	Resolver ยังเห็น query และต้องเดินค้นต่อ รวมทั้งไม่ได้ลงลายเซ็นข้อมูลแทน DNSSEC
Source-port และ transaction-ID randomization	ทำให้การเดาคำตอบปลอมเพื่อ poison cache ยากขึ้น	ไม่ใช่การยืนยันข้อมูลแบบ cryptographic

การโจมตีที่ควรแยกให้ออก

Cache poisoning พยายามใส่คำตอบปลอมลงใน resolver ส่วน amplification attack ปลอม source address เป็นเหยื่อแล้วส่ง query ที่ได้คำตอบใหญ่ไปยัง resolver เปิด ทำให้เหยื่อรับ traffic มากกว่าที่ผู้โจมตีส่ง การโจมตีหนึ่งมุ่งเปลี่ยนคำตอบ อีกการโจมตีใช้ DNS เป็นเครื่องขยาย traffic จึงป้องกันคนละแบบ

6P2P Applications

ระบบ Peer-to-Peer ไม่ได้เริ่มจากคำถามว่า “จะไม่มี server ได้อย่างไร” แต่เริ่มจากคำถามว่า “ถ้าเครื่องปลายทางจำนวนมากมี storage, bandwidth และข้อมูลของตนเอง เราจะใช้ทรัพยากรเหล่านั้นร่วมกันอย่างไรโดยไม่ต้องให้ศูนย์กลางทำทุกงาน” Peer หนึ่งเครื่องจึงสลับบทบาทได้ บางขณะขอข้อมูลจากผู้อื่น และอีกขณะส่งข้อมูลที่ตนมีให้เครือข่าย

อุปมา: ห้องสมุดของชุมชน

Client-server เหมือนทุกคนยืมหนังสือจากหอสมุดกลาง ถ้าคนมาเพิ่ม หอสมุดต้องซื้อชั้น หนังสือ และเจ้าหน้าที่เพิ่ม ส่วน P2P เหมือนทุกคนถือหนังสือคนละส่วนและยืมกันเอง สมาชิกใหม่ไม่ได้เข้ามาสร้างคิวอย่างเดียว แต่เอาหนังสือกับกำลังช่วยแจกติดมือมาด้วย ปัญหาใหม่คือเราจะรู้ได้อย่างไรว่าใครมีเล่มที่ต้องการ และถ้าคนนั้นกลับบ้านกะทันหันจะทำอย่างไร

Overlay Network: เครือข่ายที่สร้างทับบนเครือข่าย

Peer เชื่อมถึงกันผ่าน Internet ตามปกติ แต่ application สร้างความสัมพันธ์เชิงตรรกะเพิ่มขึ้น เรียกว่า overlay network เส้นเชื่อมใน overlay หมายถึง peer รู้จักกันหรือเปิด connection ถึงกัน ไม่ได้หมายความว่ามีสายจริงต่อโดยตรง เส้น overlay หนึ่งเส้นอาจผ่าน router จำนวนมากในเครือข่ายจริง

Topology ของ overlay จึงไม่จำเป็นต้องเหมือน physical topology เพื่อนบ้านใน DHT อาจอยู่คนละประเทศ ขณะที่เครื่องในห้องเดียวกันอาจไม่ได้เป็นเพื่อนบ้านเชิงตรรกะ ประเด็นนี้ทำให้ P2P ออกแบบง่ายขึ้น เพราะ algorithm มองโครงสร้างของตนเองได้ แต่ก็อาจเลือกเส้นทางที่ดีในโลกของ ID และแย่ในโลกของ latency

P2P ไม่ได้มีเพียงแบบกระจายทั้งหมด

รูปแบบ	การค้นหา	ข้อดีและข้อจำกัด
Centralized index	Server กลางเก็บว่า peer ใดมีข้อมูล แต่การส่งข้อมูลเกิดระหว่าง peer	ค้นหาเร็วและง่าย แต่ index เป็นคอขวด จุดควบคุม และจุดล้มเหลว
Unstructured P2P	ถามเพื่อนบ้านแล้วกระจายคำถามต่อ เช่น flooding หรือ random walk	ยืดหยุ่นกับข้อมูลทุกแบบ แต่การค้นหาอาจแพงและไม่รับประกันว่าจะพบ
Supernode	Peer ที่มีกำลังมากรับหน้าที่ทำดัชนีให้กลุ่มย่อย	ลดภาระจากศูนย์กลางเดียว แต่ supernode ยังเป็นเป้าหมายสำคัญ
Structured P2P / DHT	วาง key กับ peer ตามโครงสร้างคณิตศาสตร์	ค้นหาได้เป็นระบบและมีขอบเขตจำนวน hop แต่รองรับคำถามซับซ้อนได้ไม่ตรงเท่าการค้นข้อความทั่วไป

โจทย์การกระจายไฟล์: ทำไม P2P มีโอกาสโตไปพร้อมผู้ใช้

เวลากระจายไฟล์: Client-Server vs P2P

D_c-s ≥ max{NF/uₛ, F/d_min} — พจน์ NF/uₛ โตเป็นสัดส่วนตรงกับ N

D_P2P ≥ max{F/uₛ, F/d_min, NF/(uₛ+Σuᵢ)} — self-scaling เพราะ peer นำ capacity มาด้วย

ให้ F เป็นขนาดไฟล์ N เป็นจำนวนผู้รับ uₛ เป็น upload rate ของ server uᵢ เป็น upload rate ของ peer แต่ละราย และ d_min เป็น download rate ที่ต่ำที่สุด ใน client-server server ต้องส่งข้อมูลรวมอย่างน้อย NF จึงมีคอขวดชัดเจน ส่วน P2P เมื่อ peer ได้ชิ้นส่วนแล้วสามารถส่งต่อได้ upload capacity รวมจึงเพิ่มตามสมาชิก

คำว่า self-scaling ไม่ได้แปลว่าเร็วขึ้นเสมอ Peer อาจปิดเครื่องเร็ว มี upload ต่ำ อยู่หลัง NAT หรือไม่ยอมแบ่งข้อมูล หากผู้ใช้เข้ามารับอย่างเดียว สมการที่สวยก็ไม่ช่วย ระบบจึงต้องมีทั้งกลไกค้นหา การเลือกคู่แลกเปลี่ยน แรงจูงใจ และการรับมือกับ churn

BitTorrent: แบ่งไฟล์ แบ่งงาน และกระจายแหล่งส่ง

BitTorrent แบ่งไฟล์เป็น piece และอาจแบ่ง piece เป็น block ย่อยสำหรับร้องขอ ขนาด piece ไม่ได้ตายตัวที่ 256 KB แต่กำหนดตาม torrent และรูปแบบที่ใช้ Peer ที่กำลังแลกข้อมูลชุดเดียวกันเรียกว่า swarm ผู้ที่มีข้อมูลครบและยังแจกต่อเรียกว่า seeder ส่วนผู้ที่กำลังรับและส่งชิ้นที่มีอยู่เรียกว่า leecher

ส่วนประกอบที่ควรแยกให้ออก

Metadata: บอกชื่อไฟล์ ขนาด โครงสร้าง piece และ hash สำหรับตรวจความถูกต้อง
Tracker: ช่วยแนะนำรายชื่อ peer ใน swarm แต่ไม่ได้ขนข้อมูลทุกชิ้นแทน peer
Peer discovery: อาจใช้ tracker, DHT, Peer Exchange หรือวิธีท้องถิ่นร่วมกัน
Piece exchange: Peer เปิดเผยว่ามี piece ใด แล้วเลือกขอชิ้นส่วนจากหลายแหล่ง
Integrity check: ตรวจ hash ก่อนยอมรับว่าชิ้นส่วนนั้นถูกต้อง

Rarest-first: แจกชิ้นที่หายากก่อนจะหายไปจริง ๆ

ถ้าทุกคนขอ piece แรกแล้วไล่ไปตามลำดับ ชิ้นท้ายอาจมีอยู่กับ seeder เพียงคนเดียวและกลายเป็นคอขวด BitTorrent จึงมักเลือก rarest-first คือขอ piece ที่พบในเพื่อนบ้านน้อยที่สุดก่อน ทำให้ชิ้นหายากถูกทำสำเนาเร็ว และกระจายความพร้อมของข้อมูลใน swarm

อุปมา: สำเนาหนังสือที่ขาดคนละบท

หากนักศึกษาสิบคนช่วยกันถ่ายสำเนาหนังสือ และทุกคนมีบทที่ 1 อยู่แล้ว แต่บทที่ 9 มีเพียงคนเดียว งานที่ควรทำก่อนคือถ่ายบทที่ 9 กระจาย ไม่ใช่ทำบทที่ 1 เพิ่มอีกสิบชุด Rarest-first ลดโอกาสที่ peer คนเดียวซึ่งถือชิ้นสำคัญจะออกจากระบบก่อนแจกต่อ

Tit-for-tat และ Optimistic unchoke

Peer มักให้ upload slot แก่คู่ที่ส่งข้อมูลกลับมาได้ดี แนวคิดนี้คล้าย tit-for-tat และช่วยลด free-rider แต่ถ้าเลือกเฉพาะคนที่เคยให้กันอยู่แล้ว peer ใหม่จะไม่มีโอกาสเริ่ม จึงมี optimistic unchoke เปิดโอกาสให้ peer อื่นเป็นระยะ ถ้าคู่ใหม่ทำได้ดีก็อาจกลายเป็นคู่แลกเปลี่ยนประจำ

ปัญหาการค้นหา: ถ้าไม่มีสมุดโทรศัพท์กลาง จะถามใคร

การส่งข้อมูลระหว่าง peer ไม่ใช่ส่วนที่ยากที่สุดเสมอไป ก่อนส่ง เราต้องตอบให้ได้ว่า peer ใดถือข้อมูลที่ต้องการ ระบบ P2P รุ่นแรกจำนวนหนึ่งจึงยังใช้ server ทำดัชนี แม้ข้อมูลจริงจะวิ่งระหว่าง peer ข้อดีคือค้นหาเร็ว แต่เมื่อ server กลางล้ม ถูกปิด หรือรับโหลดไม่ไหว ความสามารถในการค้นหาก็หายไป

Flooding และ Time-to-Live

ใน unstructured P2P peer อาจส่ง query ไปยังเพื่อนบ้าน แล้วให้ทุกคนส่งต่อ วิธีนี้เรียกว่า flooding เพื่อไม่ให้คำถามเดินทางตลอดไป ต้องมี TTL หรือ hop limit ลดลงทุกครั้ง เมื่อเป็นศูนย์ก็หยุด และต้องมี query ID เพื่อไม่ประมวลผลคำถามเดิมซ้ำ

จำนวนข้อความของ flooding อาจเพิ่มเร็วตามจำนวนเพื่อนบ้านและจำนวน hop จึงค้นของยอดนิยมได้ง่ายแต่ใช้ traffic สูง ส่วน random walk ให้ query เดินเพียงบางทาง ลดจำนวนข้อความแต่ใช้เวลามากขึ้นและอาจไม่พบข้อมูล

DHT — Distributed Hash Table

แนวคิดหลัก

DHT ให้บริการคล้ายตาราง put(key, value) และ get(key) แต่แบ่ง key space ให้หลาย peer ดูแล ใช้ hash แปลงทั้งข้อมูลและตัวตนของ peer ให้อยู่ในพื้นที่เดียวกัน แล้วใช้ routing algorithm เดินไปยัง peer ที่รับผิดชอบ key โดยไม่ต้องมีตารางรวมศูนย์

DHT ไม่จำเป็นต้องเก็บไฟล์ทั้งก้อน ค่าในตารางอาจเป็นตำแหน่ง peer รายชื่อผู้ให้บริการ หรือ metadata เช่น hash(file) → รายชื่อ peer ที่ประกาศว่ามีไฟล์ การใช้ hash ทำให้ key กระจายค่อนข้างทั่ว แต่ก็แลกกับการค้นแบบช่วงหรือค้นตามความหมายที่ทำได้ยาก หากต้องการค้น “ไฟล์เกี่ยวกับเครือข่าย” เราไม่สามารถ hash ประโยคนั้นแล้วหวังว่าจะพบทุก key ที่เกี่ยวข้องได้ทันที

Consistent Hashing: ย้ายสมาชิกหนึ่งคน ไม่ควรย้ายของทั้งห้อง

ถ้าแบ่ง key ด้วยสูตร hash(key) mod N เมื่อจำนวน node จาก N เปลี่ยนเป็น N+1 ตำแหน่งของ key จำนวนมากจะเปลี่ยนทันที Consistent hashing วาง node และ key บนวงแหวนของ identifier space แล้วให้ key อยู่กับ node ถัดไปตามเข็มนาฬิกา หรือ successor เมื่อ node เข้า–ออก โดยหลักจึงกระทบเฉพาะช่วงใกล้ node นั้น ไม่ต้องสับข้อมูลทั้งระบบ

อุปมา: โต๊ะกลมกับตู้รับเอกสาร

วางตู้รับเอกสารรอบโต๊ะกลม แล้ววางเอกสารแต่ละฉบับตามเลข hash หากตำแหน่งเอกสารไม่มีตู้ ให้เดินตามเข็มจนเจอตู้แรก ตู้นั้นรับผิดชอบเอกสาร เมื่อเพิ่มตู้ใหม่ มันรับเอกสารเพียงช่วงระหว่างตู้ก่อนหน้ากับตัวเอง ไม่ได้ทำให้ทุกตู้ต้องเทเอกสารมาจัดใหม่หมด

Chord: เดินบนวงแหวนด้วย Finger Table

Chord ใช้ identifier ขนาด m bit จึงมีตำแหน่งตั้งแต่ 0 ถึง 2^m−1 ทั้ง node และ key ถูก hash ลงบนวงแหวน Key k อยู่ที่ node แรกซึ่งมี ID เท่ากับหรือมากกว่า k เมื่อวนตามเข็มนาฬิกา เรียกว่า successor(k)

ถ้าแต่ละ node รู้เพียง successor ถัดไป การค้นหาแย่สุดอาจเดินเกือบครบวง ใช้ข้อความระดับ O(N) Chord จึงสร้าง finger table ที่ชี้ไปยังตำแหน่งห่างออกไปแบบกำลังสอง ทำให้กระโดดไกลช่วงต้นและละเอียดขึ้นเมื่อใกล้เป้าหมาย คล้ายค้นคำในพจนานุกรมด้วยการเปิดข้ามทีละครึ่ง แทนการไล่ทีละหน้า

Kademlia: วัดระยะด้วย XOR

Kademlia ไม่ใช้วงแหวนแบบ Chord แต่กำหนดระยะระหว่าง identifier ด้วย distance(a,b) = a XOR b ถ้า bit นำเหมือนกันหลายตำแหน่ง ค่า XOR จะเล็ก แปลว่าอยู่ใกล้กันใน key space แต่ความใกล้นี้เป็นความใกล้เชิง ID ไม่ใช่ระยะทางภูมิศาสตร์

แต่ละ node เก็บเพื่อนบ้านเป็นกลุ่มเรียกว่า k-bucket แยกตามช่วงระยะทาง เมื่อค้นหา key จะถาม node ที่ใกล้เป้าหมายที่สุดหลายตัวพร้อมกัน แล้วรับรายชื่อ node ที่ใกล้กว่าเดิมกลับมา ทำซ้ำจนไม่มีใครพาเข้าใกล้ได้อีก การถามแบบขนานช่วยลดผลกระทบจาก node ช้าและ node ที่หายไป

ประเด็น	Chord	Kademlia
โครงสร้าง	วงแหวนและ successor	ระยะ XOR และ bucket
ตารางเพื่อนบ้าน	Finger table กระโดดระยะกำลังสอง	k-bucket ครอบคลุมหลายช่วงระยะ
การค้นหา	ส่งต่อไปยัง node ที่เข้าใกล้ key	ถามหลาย node แบบ iterative และมักขนานกัน
เป้าหมายร่วม	ค้นหาในระดับประมาณ O(log N) hop พร้อมรับมือกับ node จำนวนมาก

ข้อจำกัดที่ควรจำ

DHT ทำให้ค้นหาอย่างมีโครงสร้าง แต่ไม่ได้แก้ทุกปัญหา Peer ยังเข้า–ออกตลอดหรือเกิด churn ข้อมูลจึงต้องมีสำเนาและ routing table ต้องได้รับการซ่อมเป็นระยะ Peer จำนวนมากยังอยู่หลัง NAT และรับ connection ตรง ๆ ไม่ได้ นอกจากนี้ O(log N) บอกจำนวน hop เชิงตรรกะ ไม่ได้บอกว่าแต่ละ hop ใช้เวลาเท่าใดหรือ peer ที่ตอบกลับน่าเชื่อถือเพียงใด

7Multimedia Applications: Signaling

โปรโตคอล	บทบาท
SDP	บอกรายละเอียด session (media type, port, encoding)
SIP	คล้าย HTTP (request/response) — user location, availability, capabilities, session setup/management
H.323 (ITU)	ชุดข้อกำหนดสำหรับ multimedia บน packet network ซับซ้อนมาก

Resource allocation ใช้ DiffServ — แอปตั้งค่า DSCP ใน IP header ขอ priority ที่เหมาะสม

เชื่อมโยงกับ Session Layer

SIP และ SDP เป็นตัวอย่างจริงของงานจัดการ session ซึ่งแบบจำลอง OSI แยกไว้ใน Session Layer แต่ชุด TCP/IP รวมหน้าที่นี้ไว้กับ Application Layer ดูรายละเอียดเพิ่มเติมได้ที่หน้า Session Layer

8สรุปและขั้นตอนถัดไป

Application protocol กำหนดชนิด รูปแบบ ความหมาย และลำดับของข้อความที่ process แลกเปลี่ยนกัน
HTTP ไม่จำ request ก่อนหน้า แต่ Web application สร้าง state เพิ่มได้ด้วย cookie, session และ token
HTTP/2 multiplex หลาย stream บน TCP ส่วน HTTP/3 ใช้ QUIC เพื่อแยก stream และลดการรอร่วมกัน
HTTPS คือ HTTP ผ่านช่องทางที่ TLS ให้ confidentiality, integrity และการตรวจตัวตนของ server
Certificate รับรองชื่อกับกุญแจ ไม่ได้รับรองว่าเนื้อหาหรือเจ้าของเว็บไซต์สุจริต
SMTP ใช้ส่งและส่งต่ออีเมล ส่วน POP3 เน้นดาวน์โหลดข้อความ และ IMAP เน้นซิงโครไนซ์ mailbox บน server
MIME ช่วยให้อีเมลรองรับภาษา HTML และไฟล์แนบ แต่ Base64 ทำให้ข้อมูล binary มีขนาดเพิ่มขึ้น
DNS เป็นฐานข้อมูลแบบลำดับชั้นและกระจายหลายแห่ง Root มี 13 ชื่อเชิงตรรกะ ไม่ใช่เครื่องจริงเพียง 13 เครื่อง
DNS cache ลดเวลาและ traffic ส่วน TTL กำหนดจุดแลกระหว่างความสดของข้อมูลกับจำนวนคำถาม
P2P สร้าง overlay ที่สมาชิกช่วยทั้งใช้และให้ทรัพยากร แต่ต้องรับมือ discovery, churn, NAT, security และแรงจูงใจ
BitTorrent ใช้ piece exchange, rarest-first, choking และการทดลองคู่ใหม่เพื่อกระจายข้อมูลอย่างมีประสิทธิภาพ
DHT ใช้ hash และ routing structure ให้ค้นหา key ได้โดยไม่ต้องมีดัชนีกลาง Chord ใช้วงแหวนกับ finger table ส่วน Kademlia ใช้ระยะ XOR กับ k-bucket

ลองตอบด้วยความเข้าใจ

เพราะเหตุใด HTTP จึงยังเรียกว่า stateless แม้เว็บไซต์จะจำตะกร้าสินค้าได้
อธิบายความต่างของ HTTP/1.1, HTTP/2 และ HTTP/3 จากคอขวดที่แต่ละรุ่นพยายามแก้
HTTPS เพิ่มอะไรเหนือ HTTP และมีข้อมูลหรือความเสี่ยงใดที่ HTTPS ไม่ได้ซ่อนหรือป้องกัน
ไล่เส้นทางอีเมลหนึ่งฉบับจาก MUA ของผู้ส่ง ไปจนถึง mailbox และโปรแกรมของผู้รับ
เหตุใด envelope sender จึงไม่จำเป็นต้องตรงกับช่อง From ที่ผู้ใช้มองเห็น และความต่างนี้สำคัญอย่างไร
เปรียบเทียบ POP3 กับ IMAP ในแง่ state และการใช้งานหลายอุปกรณ์
อธิบาย iterative กับ recursive query ของ DNS และเหตุผลที่ root ไม่ควรรับภาระ recursive จากทุกคน
TTL ยาวกับ TTL สั้นมีข้อดีข้อเสียต่างกันอย่างไรเมื่อย้ายบริการไป IP ใหม่
เพราะเหตุใด rarest-first จึงช่วยทั้ง availability และความเร็วของ swarm
เปรียบเทียบ flooding, centralized index และ DHT ในด้านความแม่นของการค้นหา จำนวนข้อความ และจุดล้มเหลว