TCP/IP Layer 4 of 4

Application Layer

ชั้นบนสุดของ TCP/IP — รวมหน้าที่ของ OSI Session + Presentation + Application ไว้ด้วยกัน: HTTP, DNS, Email, P2P, การจัดรูปแบบข้อมูล และการจัดการ session ล้วนอยู่ที่นี่

📚

เทียบเท่าใน OSI: Application + Presentation + Session Layer — Application → · Presentation → · Session →

🧭 หน้านี้เน้นเหตุผลที่ TCP/IP รวมสามชั้นบนของ OSI มากกว่าทบทวน HTTP, JPEG หรือ SIP ซ้ำ รายละเอียดของแต่ละ protocol อ่านต่อจากหน้า OSI ได้ ส่วนที่นี่จะดูว่าหน้าที่เหล่านั้นไปอยู่ใน library, protocol และ application จริงอย่างไร

1ทำไม 3 ชั้นของ OSI ยุบเหลือชั้นเดียว

หน้าที่ตาม OSI	Implement จริงใน TCP/IP Application
Session (จัดตั้ง/ดูแล session)	SIP/SDP จัดการ session ของ VoIP โดยตรงในระดับ application
Session (รักษา state ข้าม request)	HTTP Cookie จำลอง session state บนโปรโตคอลที่เป็น stateless
Presentation (format/encoding)	JPEG/MPEG เป็น format ที่ application เลือกใช้เอง; XML/JSON กำหนด structure เอง
Presentation (encryption)	TLS/SSL ผนวกเข้ากับ application (เช่น HTTPS)

2Web และ HTTP

HTTP

client/server บน TCP port 80, stateless โดยธรรมชาติ — Non-persistent (2RTT+transmission ต่อ object) vs Persistent (1 RTT รวมสำหรับหลาย object)

Cookie แก้ปัญหา state, Web cache + Conditional GET (If-modified-since → 304 Not Modified) ลด delay และ traffic ได้มาก

3FTP, Email, DNS

โปรโตคอล	สรุปย่อ
FTP	แยก control connection ที่ port 21 ออกจาก data connection ส่วน port ของ data ขึ้นกับ active หรือ passive mode
SMTP	push protocol, port 25, ส่งเมลระหว่าง mail server
POP3 vs IMAP	POP3 เน้นดาวน์โหลดจดหมายและอาจเก็บสำเนาบน server ได้ ส่วน IMAP จัดการ folder และสถานะของ mailbox บน server
DNS	distributed hierarchical database: root → TLD → authoritative, cache ด้วย TTL, ใช้ record type A/NS/CNAME/MX

4P2P: BitTorrent และ DHT

Self-Scaling ของ P2P

D_P2P ≥ max{F/uₛ, F/d_min, NF/(uₛ+Σuᵢ)} — peer ใหม่นำ capacity มาด้วย ต่างจาก client-server ที่โตแบบ linear

BitTorrent ใช้ tit-for-tat (ส่งให้ peer ที่ให้ตนเร็วสุด) + optimistic unchoke — DHT assign key ด้วยหลัก closest-successor

5Presentation: Marshalling และการบีบอัด

หัวข้อ	สรุปย่อ
Marshalling	ต้องตอบ 3 คำถาม: data type, conversion strategy (canonical vs receiver-makes-right), tag — ตัวอย่าง: XDR (canonical, big-endian), ASN.1 (tagged), NDR (receiver-makes-right)
JPEG	แปลงสีและอาจลดข้อมูล chroma จากนั้นใช้ DCT, Quantization ซึ่งเป็นจุดสูญเสียหลัก และ entropy coding เพื่อเขียนค่าที่เหลือให้สั้นลง
MPEG	I-frame (self-contained), P-frame (อ้างอิงย้อนหลัง), B-frame (อ้างอิงสองทาง)

6Multimedia Signaling: SIP/SDP/H.323

SDP บอกรายละเอียด session เช่นชนิดสื่อ port และ codec ส่วน SIP ช่วยค้นหาผู้ใช้ ตรวจความพร้อม แลกเปลี่ยนความสามารถ และจัดตั้งหรือเปลี่ยน session ด้วยรูปแบบ request-response คล้าย HTTP นี่เป็นตัวอย่างชัดเจนว่างานของ Session Layer ใน OSI ถูกสร้างไว้ในระดับ Application ของ TCP/IP อย่างไร

จุดต่างสำคัญ: TCP/IP ไม่ได้สร้าง Protocol กลางสำหรับทุกหน้าที่ของสามชั้นบน

OSI แยก Session, Presentation และ Application เพราะต้องการอธิบายหน้าที่ให้ชัด แต่ TCP/IP ที่เติบโตจากการใช้งานจริงเปิดให้ application เลือกกลไกที่เหมาะกับตน HTTP ใช้ cookie หรือ token จัดการ state, วิดีโอเลือก codec, RPC เลือก serialization และ Web เลือก TLS หน้าที่คล้ายกันจึงไม่ได้แปลว่าต้องผ่าน protocol กลางตัวเดียว

อุปมา: อาคารที่ไม่มีชั้นธุรการแยก

OSI เหมือนองค์กรที่มีแผนกนัดหมาย แผนกแปลเอกสาร และแผนกบริการลูกค้าแยกกัน ส่วน TCP/IP เหมือนทีมที่รับผิดชอบงานทั้งสามผ่านเครื่องมือหลายชนิด งานไม่ได้หายไป เพียงไม่มีป้ายหน้าห้องบอกว่าเครื่องมือนี้อยู่ชั้น Session หรือ Presentation อย่างเป็นทางการ

หน้าที่	OSI วางไว้	พบที่ใดใน TCP/IP จริง
สร้างและปิดบทสนทนา	Session	SIP dialog, RPC context, application login หรือ connection management
เก็บ state ต่อเนื่อง	Session	Cookie, server-side session, token, WebSocket state
แปลงโครงสร้างข้อมูล	Presentation	JSON, XML, Protocol Buffers, ASN.1 หรือรูปแบบเฉพาะ protocol
บีบอัดภาพและเสียง	Presentation	JPEG, PNG, AAC, video codec และ content encoding
เข้ารหัสช่องทาง	Presentation ในคำอธิบาย OSI บางแบบ	TLS library ระหว่าง application protocol กับ transport
บริการที่ผู้ใช้ต้องการ	Application	HTTP, DNS, SMTP, SSH, MQTT และ protocol ของระบบงาน

การรวมชั้นไม่ได้แปลว่า Application หนึ่งก้อนทำทุกอย่างปนกัน

แม้ model เรียกรวมว่า Application Layer แต่ software ที่ดีอาจยังแยก module ภายใน เช่น HTTP parser, authentication middleware, TLS library, JSON serializer และ business logic การยุบชั้นใน model จึงไม่ใช่คำแนะนำให้เขียนไฟล์เดียว 20,000 บรรทัด มันเพียงบอกว่า TCP/IP ไม่กำหนด network layer แยกสำหรับหน้าที่เหล่านั้น

HTTP แสดงให้เห็นการประกอบหน้าที่หลายชั้น

HTTP กำหนด request และ response ซึ่งเป็นงาน Application แต่ Web application ใช้ cookie หรือ token เพื่อสาน request หลายครั้งให้กลายเป็น session ใช้ JSON หรือ HTML แทนข้อมูล ใช้ gzip หรือ Brotli บีบอัด และใช้ TLS สร้าง HTTPS หนึ่งการเปิดหน้าเว็บจึงใช้หน้าที่ของ OSI สามชั้นบนพร้อมกัน โดยผู้ใช้ไม่เห็นจุดต่อระหว่างชั้นเหล่านั้น

ตัวอย่าง Stack ของ Web หนึ่งคำขอ

Application สร้าง object ที่ต้องการตอบ
Serializer แปลง object เป็น JSON
HTTP ใส่ status, header และ body
ระบบอาจบีบอัด body ตาม Accept-Encoding
TLS เข้ารหัสและตรวจความถูกต้องของช่องทาง
TCP หรือ QUIC ขนข้อมูลไปยังปลายทาง
IP พา packet ข้ามหลายเครือข่าย
ปลายทางย้อนขั้นตอนกลับจนได้ object ที่ application ใช้งาน

การเรียงนี้ช่วยคิด แต่ระบบจริงอาจปรับลำดับหรือรวมขั้นตอน เช่น HTTP/3 ทำงานกับ QUIC ซึ่งมี TLS 1.3 อยู่ในกระบวนการเชื่อมต่อ เราจึงควรใช้ model เพื่อถามว่า “ใครรับผิดชอบอะไร” มากกว่าถามว่า “กล่องนี้อยู่ชั้นเลขใดเท่านั้น”

Content Negotiation คือการตกลง Presentation ภายใน HTTP

Client ส่ง header เช่น Accept, Accept-Language และ Accept-Encoding เพื่อบอก representation ที่รับได้ Server เลือกรูปแบบแล้วตอบ Content-Type, Content-Language หรือ Content-Encoding นี่คือหน้าที่เชิง Presentation ที่ไม่ได้มี protocol Presentation แยก แต่ฝังเป็นส่วนหนึ่งของ HTTP conversation

อุปมา: สั่งหนังสือเล่มเดียวกันคนละฉบับ

เนื้อหาเดียวกันอาจมีฉบับภาษาไทย ภาษาอังกฤษ ตัวพิมพ์ หรือ e-book URI ระบุสิ่งที่ต้องการ ส่วน representation คือรูปแบบที่ส่งกลับ Content negotiation ช่วยเลือกฉบับที่คู่สื่อสารใช้ได้ โดยไม่ต้องสร้าง URI ใหม่ให้ทุกความเป็นไปได้เสมอไป

Session ของแต่ละ Application มีความหมายไม่เหมือนกัน

Session ใน Web อาจหมายถึงช่วงที่ผู้ใช้ login และมี session ID ส่วน SIP session หมายถึงการสื่อสารที่มี participant, media และสถานะการเจรจา Database session อาจผูก transaction และค่าตั้งต้นของ connection เพราะ TCP/IP ไม่บังคับ Session protocol กลาง Application จึงกำหนดขอบเขต อายุ และการกู้คืน state ตามโจทย์ของตน

ข้อดีคือยืดหยุ่น ข้อเสียคือแต่ละระบบอาจสร้างวิธีจัดการ session ใหม่และทำผิดซ้ำกัน เช่น session fixation, token หมดอายุไม่เหมาะสม หรือ state กระจายหลาย server แล้วไม่ตรงกัน การไม่มีชั้นแยกไม่ได้ทำให้ปัญหาหาย เพียงย้ายความรับผิดชอบมาอยู่กับ framework และผู้ออกแบบ application

TLS อยู่ตรงไหน: คำตอบขึ้นกับสิ่งที่กำลังอธิบาย

ในแง่หน้าที่ TLS แปลงและป้องกัน representation จึงคล้าย Presentation Layer ในแง่การใช้งาน HTTPS วาง TLS ระหว่าง HTTP กับ TCP ส่วน QUIC รวม TLS เข้าใน transport handshake การถามว่า TLS “อยู่ชั้นไหนแน่” จึงมีประโยชน์น้อยกว่าการถามว่า TLS ป้องกันข้อมูลช่วงใด ใครเป็น endpoint และ application เห็นข้อมูลก่อนหรือหลังเข้ารหัสตรงไหน

ข้อมูลหนึ่งก้อนอาจมีการห่อหลายระดับใน Application Layer เดียว

ตัวอย่างเช่น object ถูกแปลงเป็น Protocol Buffers แล้วใส่ใน gRPC message จากนั้นบรรจุใน HTTP/2 frame และป้องกันด้วย TLS แม้ model TCP/IP จะเรียกทั้งหมดเหนือ Transport ว่า Application Layer แต่แต่ละรูปแบบยังมี header, framing และกติกาของตน การรวมชื่อชั้นจึงไม่ได้ลดจำนวน protocol header ที่เกิดขึ้นจริง

Middlebox และ Proxy ทำให้ End-to-End Application Protocol มีจุดพักระหว่างทาง

HTTP proxy, reverse proxy, API gateway และ CDN อาจ terminate TCP/TLS แล้วสร้าง connection ใหม่ไปยัง origin จากมุมผู้ใช้ดูเหมือนคุยกับบริการเดียว แต่จริง ๆ มี application endpoint หลายช่วง Certificate และ encryption ป้องกันแต่ละช่วงตามจุดที่ TLS สิ้นสุด จึงต้องรู้ว่า proxy ใดได้รับอนุญาตให้อ่านข้อมูล

ข้อดีและต้นทุนของการรวมสามชั้น

ด้าน	ข้อดี	ต้นทุน
การพัฒนา	Application เลือก format, security และ session ได้เหมาะกับงาน	เกิดวิธีซ้ำกันและคุณภาพไม่เท่ากัน
วิวัฒนาการ	เพิ่ม JSON, TLS รุ่นใหม่ หรือ codec ใหม่ได้โดยไม่เปลี่ยน IP	ต้องเจรจาความเข้ากันได้เอง
การเรียนรู้	Model มีเพียงสี่ชั้นและใกล้ protocol ที่ใช้จริง	ผู้เรียนอาจเข้าใจผิดว่าหน้าที่ Session/Presentation หายไป
การวินิจฉัย	เลือกเครื่องมือเฉพาะ protocol ได้	ขอบเขตชั้นไม่ชัดเมื่อ TLS, QUIC, proxy และ library ซ้อนกัน

แก่นที่ควรนำไปใช้

TCP/IP Application Layer ไม่ใช่ OSI Application Layer ที่เปลี่ยนชื่อ แต่เป็นพื้นที่รวมทุกสิ่งเหนือ Transport ความแตกต่างนี้อธิบายได้ทั้งความยืดหยุ่นของ Internet และภาระที่ตกกับนักพัฒนา เพราะสิ่งที่ OSI แยกไว้ให้เห็นชัด TCP/IP ปล่อยให้เราเลือก ประกอบ และรับผิดชอบเอง

การตกลงรูปแบบเกิดขึ้นได้ทั้งก่อนรันและระหว่างรัน

บางระบบกำหนด schema กับ codec ไว้ในโปรแกรมล่วงหน้า หากสองฝั่งใช้คนละ version อาจคุยกันไม่ได้ บางระบบเจรจาระหว่างทำงาน เช่น HTTP content negotiation หรือ SDP ที่เสนอ media capability การไม่มี Presentation protocol กลางทำให้แต่ละ application เลือกว่าจะเข้มงวด ยืดหยุ่น หรือส่งข้อมูลอธิบายตัวเองมากเพียงใด

Versioning กลายเป็นความรับผิดชอบของ Application

เมื่อเปลี่ยน field ใน JSON, Protocol Buffers หรือ API นักพัฒนาต้องคิดว่า client รุ่นเก่าจะอ่านได้หรือไม่ Field ใหม่เป็น optional หรือ required ชื่อเดิมเปลี่ยนความหมายหรือเปล่า OSI บอกว่าการแทนข้อมูลเป็นหน้าที่สำคัญ ส่วน TCP/IP ไม่ได้ส่ง protocol กลางมาจัดการ version ให้เรา Framework ช่วยได้ แต่ผู้ออกแบบยังต้องกำหนดกติกา

วิธีเปลี่ยนระบบ	ผลต่อความเข้ากันได้
เพิ่ม field ที่ผู้รับเก่าเพิกเฉยได้	มักรักษา backward compatibility ได้ง่ายกว่า
ลบหรือเปลี่ยนความหมาย field เดิม	เสี่ยงทำให้ client เก่าตีความผิด
เพิ่ม version ใน URL หรือ header	แยกสัญญาชัด แต่ต้องดูแลหลายรุ่น
เจรจา capability	ยืดหยุ่นขณะรัน แต่ protocol และการทดสอบซับซ้อนขึ้น

การรักษา State ทำให้ Scale และ Failure ซับซ้อนขึ้น

HTTP request ที่เป็นอิสระสามารถกระจายไปยัง server หลายเครื่องได้ง่ายกว่า แต่เมื่อ session state อยู่ในหน่วยความจำของเครื่องหนึ่ง request ถัดไปอาจต้องกลับเครื่องเดิม หรือย้าย state ไป shared store หาก server ล้ม ผู้ใช้จะเสีย session หรือระบบสร้างใหม่อย่างไร คำถามเหล่านี้คือหน้าที่ Session ที่กลับมาในรูปปัญหา deployment

อุปมา: ฝากเรื่องไว้กับพนักงานคนเดียว

หากลูกค้าต้องคุยกับพนักงานคนเดิมทุกครั้ง การสนทนาต่อเนื่องง่าย แต่เมื่อพนักงานหยุดงานเรื่องทั้งหมดติดขัด หากเขียนข้อมูลลงระบบกลาง พนักงานคนอื่นรับต่อได้ แต่ต้องลงทุนให้ข้อมูลกลางถูกต้องและเข้าถึงทัน การเลือกระหว่าง sticky session กับ shared state ก็มีโครงสร้างคล้ายกัน

End-to-End Encryption กับ Hop-by-Hop Encryption

ถ้า TLS สิ้นสุดที่ reverse proxy แล้ว proxy เปิด TLS connection ใหม่ไป backend ข้อมูลได้รับการป้องกันบนทั้งสองช่วง แต่ proxy มองเห็น plaintext ได้ นี่คือ hop-by-hop protection ระหว่าง endpoint แต่ละคู่ ส่วน end-to-end encryption ที่แท้จริงต้องทำให้ตัวกลางไม่มีกุญแจอ่านเนื้อหา แม้อาจยังต้องเห็น metadata บางส่วนเพื่อส่งต่อ

การบอกว่า “ใช้ HTTPS แล้วเข้ารหัสจากผู้ใช้ถึงฐานข้อมูล” จึงอาจเกินจริง HTTPS บอกขอบเขตถึง TLS endpoint ซึ่งอาจเป็น CDN, load balancer หรือ gateway ก่อนถึง application server การวาดเส้นทางข้อมูลจริงสำคัญกว่ามองรูปแม่กุญแจเพียงจุดเดียว

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

TCP/IP Application = OSI Application + Presentation + Session รวมกัน
HTTP/FTP/SMTP/DNS คือโปรโตคอล "Application" ดั้งเดิมของ OSI
JPEG/MPEG/XDR คือหน้าที่ "Presentation" ที่ผนวกเข้ามาอยู่ในระดับ application เดียวกัน
SIP, SDP และ Cookie เป็นตัวอย่างงานด้าน session ที่สร้างไว้ในระดับ application

คำถามซ้อมสอบ

ดูชุดคำถามซ้อมสอบแบบละเอียดที่หน้า OSI Application, Presentation และ Session Layer — ครอบคลุมเนื้อหาเดียวกับหน้านี้ทั้งหมด

เรียนครบทั้ง 4 ชั้นของ TCP/IP แล้ว

หากต้องการดูรายละเอียดของหน้าที่แต่ละชั้นแบบแยกส่วน สามารถเริ่มเส้นทาง OSI ได้ที่ OSI Physical Layer หรือกลับไปเลือกหัวข้ออื่นจาก หน้าหลัก