Session Layer

1นิยามตาม OSI

2ทำไม Session Layer ถึง "หายไป" ใน TCP/IP

ในทางปฏิบัติ ฟังก์ชันที่ OSI มอบให้ Session Layer มักถูก implementภายใน application เอง แทนที่จะแยกเป็นโปรโตคอลชั้นกลางต่างหาก — นี่คือเหตุผลที่ TCP/IP model ไม่มีชั้นนี้แยกออกมา (ยุบรวมเข้ากับ Application Layer)

3Session ไม่ใช่ Connection และไม่ใช่ Identity

Transport connection คือช่องทางส่งข้อมูลระหว่าง endpoints ส่วน session คือบริบทของกิจกรรมที่ต่อเนื่อง และ identity คือคำตอบว่า actor เป็นใคร สามอย่างนี้เกี่ยวข้องกันแต่ไม่ควรถูกผูกเป็นสิ่งเดียว Session หนึ่งอาจอยู่ต่อหลัง TCP connection ขาด ผู้ใช้หนึ่งคนมีหลาย session จากหลายอุปกรณ์ และ connection หนึ่งบรรทุกหลาย logical session ได้

4เริ่ม ดูแล และยุติ Session

ตอนเริ่ม session ทั้งสองฝ่ายอาจตกลง protocol version, capability, role, encoding และสิทธิ์ใช้งาน ขั้นนี้ต่างจาก TCP handshake ซึ่งสร้าง transport connection เท่านั้น TCP connected แล้ว application negotiation ยังล้มเหลวได้ Session establishment มักสร้าง session ID หรือ token สำหรับอ้างถึงบริบทใน request ถัดไป

ระหว่างใช้งาน ระบบต้องดู dialogue control ว่าใครส่งได้เมื่อใด บางงานส่งสองทิศพร้อมกัน บางงานต้องผลัดกันพูดหรือถือ token เพื่อแก้ไข resource เมื่อปิด session แบบปกติควรบันทึกผล ปล่อย resource และ revoke credential ตามนโยบาย แต่ถ้า client หายไปโดยไม่แจ้ง server ต้องพึ่ง expiry, heartbeat หรือ lease

5Synchronization และ Checkpoint

งานขนาดใหญ่ไม่ควรเริ่มใหม่ทั้งหมดเมื่อการสื่อสารสะดุด Checkpoint แบ่งงานเป็นช่วงและบอกจุดล่าสุดที่ยืนยันแล้ว เมื่อ reconnect ทั้งสองฝ่ายถามสถานะและทำต่อจากจุดนั้น แนวคิดนี้ใช้กับ resumable upload, database replication, workflow และการแก้เอกสารร่วมกัน

ตัวอย่าง Resumable Upload

1. Server สร้าง upload ID และกำหนดขนาด/เงื่อนไข
2. Client ส่ง chunk พร้อม offset หรือ part number
3. Server ตรวจ hash และบันทึกแบบ durable ก่อนตอบว่าได้รับแล้ว
4. ถ้าสายหลุด Client ถามสถานะด้วย upload ID
5. ส่งต่อจากส่วนที่ server ยืนยัน ไม่ใช้จำนวน byte ที่ send() รับเป็นหลักฐาน

TCP ACK ยืนยันว่า byte ถึง transport stack ไม่ได้ยืนยันว่า application เขียนลง storage แล้ว Checkpoint ระดับงานต้องมี application acknowledgment หลัง durable commit และต้องรับมือ chunk ซ้ำด้วย idempotency

Checkpoint ไม่เท่ากับ transaction Checkpoint บอกจุดกลับมาทำต่อ ส่วน transaction กำหนด atomicity หากงานมี side effect เช่นตัดเงินหรือส่งอีเมล การย้อน checkpoint ไม่ทำให้ผลภายนอกหาย ต้องใช้ idempotency key หรือ compensating action

6Session ใน Web: Cookie, Token และ Server-side State

HTTP request แต่ละครั้งตีความได้โดยไม่ต้องมี transport connection เดิม แต่ web application สร้างความต่อเนื่องด้วย cookie หรือ authorization token Cookie เป็นกลไกที่ browser เก็บและแนบข้อมูลตาม domain, path และ security attributes ไม่ใช่ session ทั้งหมด Cookie อาจถือ opaque session ID ที่ชี้ไป server-side store หรือถือ signed token ที่มี claim อยู่ภายใน

Stateless service ไม่ได้หมายถึงระบบไม่มี state แต่หมายถึง instance ไม่พึ่ง conversational state ที่ซ่อนอยู่เฉพาะ memory ของตัวเอง Request จึงไป instance ใดก็ได้โดยอ่าน state จาก token หรือ shared store Database และ session store ยังเป็น state เพียงถูกย้ายตำแหน่งให้จัดการ scaling ง่ายขึ้น

ความปลอดภัยของ Session

• เปลี่ยน session ID หลัง login หรือ privilege change เพื่อลด session fixation
• ใช้ Secure, HttpOnly และ SameSite cookie ตามบริบท พร้อม TLS
• แยก idle timeout จาก absolute lifetime
• revoke session เมื่อ logout, credential เปลี่ยน หรือพบความเสี่ยง
• อย่าบันทึก token เต็มค่าใน log และอย่าคิดว่า Base64 คือ encryption

7Session ในระบบที่มีหลาย Server

ถ้าเก็บ session ใน memory ของ instance เดียว Request ที่ load balancer ส่งไปเครื่องอื่นจะหา state ไม่เจอ Sticky session บังคับให้กลับเครื่องเดิม ช่วยง่ายช่วงแรกแต่ทำให้ failover และ balancing ยาก Shared store ทำให้ instance ทดแทนกันได้แต่เพิ่ม dependency และ latency ส่วน self-contained token ลด lookup แต่เพิ่มปัญหา revocation และ stale claim

ถ้า session store replicate แบบ asynchronous แล้ว primary ล่ม การอัปเดตล่าสุดอาจหาย ผู้ใช้อาจย้อนสถานะหรือสิทธิ์ที่เพิ่งถอนกลับมาใช้ได้ Consistency requirement ต้องดูผลเสีย ตะกร้าหายหนึ่งรายการต่างจาก admin permission ที่ถูกเพิกถอน

หลาย tab หรือหลาย request อาจแก้ session พร้อมกัน Last-write-wins ทำข้อมูลหายได้ Optimistic concurrency ใช้ version ตรวจ conflict งานบางชนิดต้อง serialize หรือออกแบบ operation ให้ commutative ระบบกระจายไม่ได้มีปัญหาเพราะ session “อยู่ผิดชั้น” แต่เพราะ state มีเจ้าของและความสอดคล้องที่ต้องนิยาม

8Heartbeat, Lease และ Presence

ระบบประชุม เกม และ service discovery ต้องอนุมานว่าสมาชิกยังอยู่ Heartbeat เป็นหลักฐานล่าสุด ส่วน lease เป็นสิทธิ์ที่หมดอายุหากไม่ต่อเวลา Heartbeat ถี่ตรวจ failure เร็วแต่เพิ่ม overhead และ false positive เมื่อระบบ pause Heartbeat ห่างลดภาระแต่ตรวจช้า ค่า timeout จึงต้องสัมพันธ์กับ jitter และ recovery objective

Lease สำหรับ distributed lock ยังมีปัญหา client เก่าที่หยุดนานแล้วฟื้นขึ้นมาและคิดว่าตนถือ lock ต้องใช้ fencing token ที่เพิ่มทุก lease ให้ resource ปฏิเสธคำสั่งจากเจ้าของรุ่นเก่า Timeout อย่างเดียวไม่หยุด zombie client

9การวิเคราะห์ปัญหา Session

1. แยก authentication failure, session lookup failure และ authorization failure
2. ตรวจว่า client ส่ง cookie/token หรือไม่ และ domain, path, expiry, SameSite ถูกหรือเปล่า
3. ตรวจ session store ว่า record หมดอายุ ถูก evict หรือ replicate ช้า
4. ตรวจ clock skew เมื่อ token ใช้ iat, nbf และ exp
5. ตรวจ sticky policy, instance restart และตำแหน่งที่ state ถูกเก็บ
6. ใช้ correlation/session ID ใน log โดยไม่เปิดเผย secret

อาการ login แล้วหลุดเมื่อ refresh อาจเกิดจาก cookie ไม่ถูกส่ง, key sign ไม่ตรงกันระหว่าง instances, session store หาย หรือ reverse proxy เปลี่ยน scheme/domain การเปิด TCP ใหม่ไม่ช่วยถ้าบริบทหาไม่พบ ต้องตามเส้นทางของ token และ state ไม่ใช่เส้นทาง packet เพียงอย่างเดียว

10SIP, SDP และ Media Session

SIP ใช้เริ่ม ปรับ และยุติ multimedia session ส่วน SDP บรรยาย media type, codec, address และ port ที่ผู้เข้าร่วมเสนอ ทั้งสองไม่ได้ขนเสียงหรือวิดีโอเอง Media มักเดินผ่าน RTP/RTCP และอาจใช้ transport path คนละเส้นกับ signalling จึงเกิดกรณีโทรติดแต่ไม่ได้ยินเสียง เพราะ session negotiation สำเร็จแต่ media path ถูก NAT/firewall ขวาง

Session การประชุมหนึ่งครั้งอาจมี signalling connection หลายช่วง, audio stream, video stream และ screen-sharing stream แต่ทั้งหมดผูกด้วย call/dialog identifiers และ negotiation context การคิดว่า session ต้องตรงกับ socket หนึ่งตัวจึงอธิบาย multimedia ไม่พอ

Re-negotiation และ Session Version

เมื่อผู้ใช้เปิดกล้อง เปลี่ยน network หรือเพิ่ม participant ระบบอาจ negotiate capability ใหม่ State ต้องรู้ offer/answer รุ่นใดกำลังใช้งานและป้องกันข้อความเก่าที่มาช้ากลับมาทับค่าใหม่ Sequence/version จึงสำคัญไม่แพ้ session ID

เมื่อ Bandwidth ลดลง คุณภาพไม่ได้ลดแบบเดียวทุกระบบ

Video แบบบันทึกล่วงหน้ามักมีเวลาสะสม buffer และสลับไป rendition ที่ bitrate ต่ำกว่าได้ ผู้ชมอาจเห็นความละเอียดลดจาก 1080p เป็น 720p หรือ 480p แต่ภาพยังเล่นต่อเนื่อง เพราะระบบยอมเพิ่มเวลา buffer เพื่อแลกกับความลื่น ส่วน live streaming มี buffer สั้นกว่าและการประชุมแบบ real-time สั้นยิ่งกว่า เพราะภาพที่คมแต่ช้ากว่าคู่สนทนาหลายวินาทีแทบใช้โต้ตอบไม่ได้

เมื่อ available bandwidth ลด Encoder มีหลายปุ่มให้ปรับ ไม่ใช่ลด “ความคมชัด” เพียงค่าเดียว ได้แก่ bitrate, resolution, frame rate, quantization, keyframe interval, spatial/temporal layers และ audio mode การลด resolution ช่วยลดรายละเอียด การลด frame rate ทำให้การเคลื่อนไหวไม่ลื่น การเพิ่ม compression ทำให้เกิด block/blur ส่วนการลด audio bitrate อาจทำให้เสียงแคบและ artifact มากขึ้น ระบบประชุมมักรักษาเสียงก่อนภาพ เพราะเสียงต่อเนื่องยังช่วยให้ประชุมเดินต่อได้แม้ภาพหยุดชั่วคราว

Adaptation ระหว่าง Session กับ Re-negotiation ไม่เหมือนกันทุกครั้ง

การเปลี่ยน bitrate ภายใน codec configuration ที่ตกลงไว้ อาจทำได้ต่อเนื่องโดยไม่ต้องเจรจา SIP/SDP ใหม่ Sender ใช้ feedback จาก RTCP, transport-wide congestion control หรือ bandwidth estimator ปรับ encoder และ pacing ได้ทันที แต่ถ้าจะเพิ่ม/ลบ media track, เปลี่ยน codec ที่ยังไม่ได้ตกลง, เปลี่ยน direction จาก receive-only เป็น send-receive หรือเปลี่ยน parameter ที่กระทบ session description จึงอาจต้อง offer/answer หรือ re-INVITE/UPDATE ตาม protocol

คำว่า “ต้องเจรจาใหม่เมื่อความเร็วตก” จึงควรแยกสองระดับ ระดับแรกคือ rate adaptation ภายในข้อตกลงเดิม เกิดถี่และรวดเร็ว ระดับที่สองคือ session renegotiation เมื่อ capability หรือโครงสร้าง stream เปลี่ยน หาก renegotiate ทุกครั้งที่ bandwidth แกว่ง ระบบ signalling จะหนักและปรับไม่ทันเครือข่าย

Simulcast และ Scalable Video Coding

ในการประชุมหลายคน Sender อาจส่ง simulcast หลาย encoding เช่นต่ำ กลาง สูง ให้ SFU เลือกส่งตามขนาดหน้าจอและ bandwidth ของผู้รับแต่ละคน ข้อดีคือ receiver ช้าไม่บังคับทุกคนรับคุณภาพต่ำ แต่ sender ใช้ CPU และ upload มากขึ้น ส่วน Scalable Video Coding แบ่ง base layer กับ enhancement layers ผู้รับอย่างน้อยรับ base layer แล้วเพิ่ม spatial/temporal quality เมื่อ bandwidth พอ

เมื่อหน้าจอแสดงผู้เข้าร่วม 20 คนเป็นช่องเล็ก ไม่จำเป็นต้องส่งทุกคน 1080p SFU เลือก layer ตาม layout และ active speaker ได้ เมื่อผู้ใช้ pin คนหนึ่งจึงขอ layer สูงขึ้น นี่คือ session context มีผลต่อ resource allocation: network condition บอกว่ารับได้เท่าไร ส่วน UI context บอกว่าคุณภาพสูงตรงไหนมีคุณค่า

Keyframe, Reference Frame และผลของ Loss

Video codec บีบอัดโดยให้ frame จำนวนมากอ้างอิง frame ก่อนหน้า หาก packet สำคัญของ reference frame หาย ความเสียหายอาจลากต่อหลาย frame Receiver อาจส่ง feedback ขอ keyframe เพื่อเริ่มภาพใหม่ที่ไม่พึ่ง chain เดิม แต่ keyframe ใหญ่ ทำให้ bandwidth spike หากผู้รับจำนวนมากขอพร้อมกันอาจยิ่งทำ congestion ต้องรวมคำขอและควบคุมการส่ง

Retransmission มีประโยชน์เมื่อ packet ที่ส่งใหม่ยังมาถึงก่อน playback deadline ใน RTT ต่ำอาจช่วยได้ แต่ในเส้นทาง RTT สูง packet ที่มาช้าไม่มีประโยชน์ FEC ส่ง redundancy ล่วงหน้าเพื่อซ่อม loss โดยไม่รอ RTT แต่กิน bandwidth แม้ไม่มี loss ระบบจึงปรับสัดส่วน recovery ตามสภาพและชนิด media

Audio/Video Synchronization

Audio กับ video อาจใช้ RTP stream คนละชุดและ timestamp คนละ clock rate RTCP Sender Report ช่วยผูก RTP timestamp กับเวลาอ้างอิงเพื่อให้ receiver sync ปากกับเสียง Jitter buffer ของแต่ละ stream ต้องประสานกัน หาก video ช้ากว่าอาจหน่วง audio เล็กน้อย แต่ถ้าหน่วงมากเกิน การรักษา lip-sync กลับทำให้การสนทนาช้าทั้งหมด ระบบจึงมี threshold ว่าจะรอ drop หรือปรับ playback

สำหรับการประชุม เสียงมักสำคัญกว่า video หาก bandwidth ตกมาก ระบบอาจปิดวิดีโอ ลด video frame rate เหลือไม่กี่ภาพต่อวินาที แต่รักษา audio packet, echo cancellation และ jitter buffer ให้ใช้งานได้ การ share screen มีธรรมชาติต่างจากกล้อง: ตัวหนังสือต้องคม แต่การเคลื่อนไหวอาจต่ำ จึงเลือก resolution สูง frame rate ต่ำได้ ขณะที่กีฬา/ท่าทางต้องการ temporal quality มากกว่า

Quality of Experience ไม่ใช่ Bitrate ตัวเดียว

คุณภาพที่ผู้ใช้รับรู้รวม join time, freezes, resolution, frame rate, audio concealment, lip-sync, end-to-end latency และความถี่ที่คุณภาพแกว่ง ภาพ 720p คงที่อาจรู้สึกดีกว่า 1080p ที่สลับลง 360p ทุกไม่กี่วินาที Adaptation จึงควรมี hysteresis และช่วงเวลาประเมินเพื่อไม่ไล่ตาม noise ของ measurement มากเกินไป

Metric ควรแยก sender, network และ receiver เช่น encode time, packets sent/lost, RTT, jitter, frames decoded/dropped และ playback delay หากดูเพียง bitrate ต่ำ เราไม่รู้ว่า network จำกัด encoder CPU เต็ม หรือผู้รับแสดงหน้าต่างเล็กแล้วตั้งใจขอ layer ต่ำ Observability ต้องเก็บบริบทการตัดสินใจ ไม่ใช่ตัวเลขผลลัพธ์อย่างเดียว

11WebSocket และ Long-lived Session

WebSocket เริ่มจาก HTTP upgrade แล้วเปลี่ยนเป็นช่องทางสองทิศที่ยาวนาน แต่ WebSocket connection ยังไม่เท่ากับ user session เมื่อ connection หลุด Client อาจ reconnect ด้วย credential เดิมและขอ resume จาก event ID ล่าสุด Server ต้องกำหนดว่า message ระหว่างช่วงขาดจะเก็บไว้ ส่งซ้ำ หรือถือว่าหาย

Long-lived connection ต้องมี heartbeat, idle timeout, authentication refresh และ backpressure หาก token หมดอายุระหว่าง connection เปิด ระบบจะยอมจนปิดหรือ re-authenticate กลางทาง หาก server restart connection ทั้งหมดขาดพร้อมกัน Client จำนวนมากอาจ reconnect พร้อมกันจนเกิด thundering herd จึงต้องใช้ randomized backoff

12Workflow Session และ Saga

งานธุรกิจหนึ่งครั้งอาจกินเวลานาทีหรือวันและเรียกหลาย service เช่นรับคำสั่งซื้อ ตัดสต็อก ชำระเงิน และจัดส่ง การเก็บ TCP connection เปิดรอตลอดไม่สมเหตุผล Session ของ workflow จึงอยู่ใน durable state machine แต่ละ step มี status, input, output, retry policy และ compensation

Saga แบ่ง transaction ข้าม service เป็น local transactions และ compensating actions แต่ compensation ไม่ใช่ rollback ทางกายภาพเสมอ เช่นอีเมลที่ส่งแล้วเรียกคืนไม่ได้ ทำได้เพียงส่งข้อความแก้ไข การออกแบบ session state ต้องบันทึก intent และผลจริงเพื่อรู้ว่าควรทำต่อหรือชดเชยอะไร

Idempotency กับ Session Command

Client อาจ retry command หลัง timeout Workflow ต้องใช้ command ID หรือ idempotency key ตรวจว่าคำสั่งเดิมถูกทำแล้วหรือยัง ผลลัพธ์ควรถูกเก็บร่วมกับ key ตามขอบเขตเวลา ไม่ใช่เพียงทิ้ง duplicate เพราะ client ต้องได้คำตอบเดิมกลับด้วย

Exactly-once effect ต้องอาศัย durable deduplication และ transaction boundary ที่เหมาะสม Session ID เพียงค่าเดียวไม่พอ หากบันทึกว่า “รับคำสั่งแล้ว” แต่ crash ก่อนทำงาน หรือทำงานแล้ว crash ก่อนบันทึกผล ระบบยังมีความกำกวม ต้องออกแบบ state transition แบบ recoverable

13Observability และ Privacy ของ Session

การตามปัญหาข้าม request ต้องมี correlation ID, trace ID หรือ session reference แต่ identifier ที่ใช้ค้น log ไม่ควรเป็น bearer token ที่ใช้เข้าถึงระบบได้ Log ควร hash หรือ redact secret และกำหนด retention เพราะ session trail อาจเปิดเผยพฤติกรรมผู้ใช้

Metric ที่มี session ID เป็น label โดยตรงสร้าง cardinality สูงจนระบบ monitoring รับไม่ไหว ควรใช้ log/trace สำหรับ identifier ราย session และใช้ metric แบบ aggregate เช่น active sessions, create rate, expiry rate, lookup latency และ error count

14Session Timeout และการต่ออายุ

Session มักมีทั้ง idle timeout และ absolute lifetime Idle timeout เลื่อนออกเมื่อมีกิจกรรมเพื่อปิด session ที่ถูกทิ้งไว้ ส่วน absolute lifetime บังคับให้ยืนยันตัวตนใหม่แม้ใช้งานต่อเนื่อง ลดเวลาที่ credential ถูกขโมยแล้วใช้ได้ การมี sliding expiration อย่างเดียวอาจทำให้ session อยู่ตลอดกาล

การต่ออายุ token ต้องแยก access token อายุสั้นจาก refresh token ที่ป้องกันเข้มกว่า Refresh token rotation ช่วยตรวจ reuse เมื่อ token เก่าถูกนำกลับมาใช้ แต่ต้องเก็บ token family state และจัดการ race จาก request พร้อมกัน การเพิ่ม token หลายชนิดไม่ได้ปลอดภัยเองหากเก็บทั้งหมดในที่ที่ script ขโมยได้เท่ากัน

Clock skew ระหว่าง client, service และ identity provider ทำให้ token ดูว่ายังไม่เริ่มหรือหมดอายุแล้ว ต้อง sync เวลาและมี tolerance จำกัด การเผื่อมากเกินไปกลับขยายเวลาที่ token หมดอายุยังใช้ได้ Log ควรเก็บเวลา issuer/verifier เพื่อแยก clock problem จาก signature failure

15Session Migration และการเปลี่ยน Version

เมื่อ deploy application รุ่นใหม่ session เก่าอาจมี schema ต่างจาก code ใหม่ การล้าง session ทั้งหมดง่ายแต่บังคับ logout ผู้ใช้และทำ workflow หาย ทางเลือกคืออ่านได้หลาย version, migrate lazily ตอน access หรือเขียน state แบบ backward compatible ช่วง rolling deployment

Signed token ที่มี claim ฝังอยู่เปลี่ยน schema ยากกว่า opaque ID เพราะ token เก่ายังอยู่จนหมดอายุ Service ใหม่ต้องรองรับ claim รุ่นเก่าหรือบังคับอายุสั้น Key rotation ก็ต้องมีช่วง overlap ให้ verifier รู้ public key เก่า จน token รุ่นเก่าหมดอายุ การลบ key ทันทีทำให้ session ทั้งระบบเสียพร้อมกัน

Session migration ระหว่าง region ต้องคิด data residency, latency และ conflict ผู้ใช้ย้าย region ขณะมี request ค้างอาจเกิด state สองสำเนา ต้องกำหนด home region, leader, version vector หรือ reconciliation ตามความสำคัญ ไม่ใช้คำว่า multi-region เป็นคำตอบโดยไม่กำหนดผู้ตัดสินเมื่อข้อมูลต่างกัน

16Session Anti-pattern ที่พบบ่อย

อีก anti-pattern คือใช้ session เป็นฐานข้อมูลเงา เก็บ object สำเนาจำนวนมากจนข้อมูลต้นทางเปลี่ยนแต่ session ยังเก่า ทางแก้ไม่ใช่ refresh ทุกอย่างตลอดเวลา แต่กำหนด ownership ว่าข้อมูลใดเป็น snapshot สำหรับ workflow และข้อมูลใดต้องอ่านจาก source of truth พร้อม version ที่ตรวจได้

17วิธีออกแบบ Session ให้ตอบคำถามได้ครบ

1. กำหนดขอบเขต — session เริ่มเมื่อใด จบเมื่อใด และหนึ่ง user มีได้กี่ session
2. กำหนดเจ้าของ state — client, instance, shared store หรือ workflow engine ใครเป็น source of truth
3. กำหนด identity และสิทธิ์ — session อ้างถึงใคร และ privilege เปลี่ยนแล้ว session เก่าทำอย่างไร
4. กำหนด lifecycle — idle timeout, absolute lifetime, renewal, logout และ revocation
5. กำหนด failure — reconnect, resume, duplicate, concurrent request และ store unavailable
6. กำหนดหลักฐาน — log state transition, metric แบบ aggregate และ audit โดยไม่เปิด secret
7. กำหนด migration — code รุ่นใหม่อ่าน session รุ่นเก่าและ rollback ได้อย่างไร

คำถามเหล่านี้ทำให้คำว่า session จากกล่องกว้าง ๆ กลายเป็น contract ที่ทดสอบได้ เช่น “logout ต้อง revoke ภายในกี่วินาที”, “upload resume หลัง server restart ได้จาก checkpoint ใด” หรือ “ถ้า session store ล่ม request ใด fail closed และ request ใดใช้ cached state ได้” เมื่อระบุผลลัพธ์ได้ ทีมจึงเลือก cookie, token, Redis หรือ database จากโจทย์ ไม่ใช่เลือกเครื่องมือแล้วค่อยสร้างเหตุผลตามหลัง

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

ขั้นตอนถัดไปคือ Presentation Layer ซึ่งถามว่าข้อมูลใน session ถูกแทนอย่างไร ทั้ง serialization, character encoding, compression และ encryption Session ช่วยจำว่าเราคุยเรื่องเดิม ส่วน Presentation ช่วยให้ทั้งสองฝ่ายตีความ byte ตรงกัน