[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"academy-blogs-th-1-1-all-cookie-vs-session-explained-all--*":3,"academy-blog-translations-rnj71f99yfx3r2p":92,"academy-blog-faqs-rnj71f99yfx3r2p-th":93},{"data":4,"page":91,"perPage":91,"totalItems":91,"totalPages":91},[5],{"alt":6,"collectionId":7,"collectionName":8,"content":9,"cover_image":10,"cover_image_l_url":11,"cover_image_m_url":12,"cover_image_path":13,"cover_image_s_url":14,"created":15,"created_by":16,"expand":17,"id":84,"keywords":85,"locale":54,"published_at":86,"scheduled_at":71,"school_blog":80,"short_description":87,"status":78,"title":88,"updated":89,"updated_by":90,"slug":81,"views":83},"เคาน์เตอร์ฝากเสื้อโค้ต มือกำลังรับตั๋วเปล่าหนึ่งใบ มีเสื้อโค้ตแขวนบนราวด้านหลัง พร้อมป้ายข้อความ Cookie: เก็บที่ Browser และ Session: เก็บที่ Server","sclblg987654321","school_blog_translations","\u003Cp>ลองนึกภาพว่าเมื่อวานคุณล็อกอินเว็บไว้ ปิดแท็บไปทำอย่างอื่น วันนี้เปิดกลับมา เว็บยังทักชื่อคุณได้เหมือนไม่เคยจากกันไปไหน ทั้งที่คุณไม่ได้พิมพ์รหัสผ่านซ้ำเลยสักครั้ง น้องๆ ที่เพิ่งเริ่มเขียนเว็บมักถามทีมเราว่า \"เว็บมันจำเราได้ยังไง\" แล้วคำตอบก็มักลากไปเจอสองคำที่ถูกพูดคู่กันเสมอ คือ Cookie กับ Session\u003C\u002Fp>\u003Cp>ปัญหาคือสองคำนี้ถูกใช้ปนกันจนหลายคนคิดว่าเป็นของอย่างเดียวกัน วันนี้ Superdev Academy จะพาไปดูว่าสองอย่างนี้ต่างกันตรงไหน ทำงานร่วมกันยังไง และให้ดู Header จริงที่ browser กับ server ส่งหากัน เพื่อให้คุณเห็นกับตาว่ากลไกนี้ไม่มีอะไรลึกลับเลย\u003C\u002Fp>\u003Ch2>ทำไมเว็บต้องมีตัวช่วยจำ ทั้งที่ HTTP ไม่จำอะไรเลย\u003C\u002Fh2>\u003Cp>ทุกครั้งที่ browser ขอหน้าเว็บ มันส่ง Request (คำขอ) ไปหา server แล้ว server ส่ง Response (คำตอบ) กลับมา จบแค่นั้น HTTP ถูกออกแบบให้เป็น Stateless (ไม่เก็บสถานะ) คือ server ไม่ได้จำว่า Request ก่อนหน้ามาจากใคร เอกสาร \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.rfc-editor.org\u002Frfc\u002Frfc6265\">RFC 6265\u003C\u002Fa> ซึ่งเป็นมาตรฐานของ Cookie เองก็เขียนไว้ในบทคัดย่อว่า Cookie มีไว้สร้าง Session ที่มีสถานะ บนโปรโตคอล HTTP ที่ส่วนใหญ่ไม่มีสถานะ\u003C\u002Fp>\u003Cp>ถ้าไม่มีตัวช่วย คุณจะต้องล็อกอินใหม่ทุกครั้งที่กดเปลี่ยนหน้า เพราะในสายตา server ทุก Request คือคนแปลกหน้า Cookie กับ Session คือคำตอบของปัญหานี้ แต่ทำหน้าที่คนละส่วนกัน\u003C\u002Fp>\u003Ch2>Cookie กับ Session ต่างกันอย่างไร: ตู้ฝากเสื้อโค้ตกับตั๋วรับของ\u003C\u002Fh2>\u003Cp>นึกถึงเคาน์เตอร์ฝากเสื้อโค้ตในโรงละคร คุณยื่นเสื้อให้พนักงาน พนักงานแขวนเสื้อไว้บนราวหลังเคาน์เตอร์ แล้วยื่นตั๋วใบเล็กๆ ให้คุณหนึ่งใบ ตอนกลับคุณยื่นตั๋วใบนั้น พนักงานก็หยิบเสื้อตัวที่ถูกต้องคืนให้\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>Session\u003C\u002Fstrong> คือราวแขวนเสื้อหลังเคาน์เตอร์ ข้อมูลจริงของคุณ เช่น คุณคือใคร ล็อกอินอยู่ไหม มีของอะไรในตะกร้า ถูกเก็บไว้ฝั่ง server\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Cookie\u003C\u002Fstrong> คือตั๋วในมือคุณ ตัวมันไม่ได้มีเสื้ออยู่ข้างใน มีแค่หมายเลขที่ใช้ชี้ไปหาเสื้อ ซึ่งในโลกเว็บเรียกว่า Session ID\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>สรุปเป็นสองบรรทัดที่ควรจำไว้:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>Cookie: เก็บที่ Browser\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>Session: เก็บที่ Server\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>ตั๋วหายหรือถูกขโมยเมื่อไหร่ คนที่ถือตั๋วก็ไปรับเสื้อแทนคุณได้ นี่คือเหตุผลที่เรื่องความปลอดภัยของ Cookie สำคัญมาก ซึ่งเราจะกลับมาพูดในหัวข้อ Attribute ด้านล่าง\u003C\u002Fp>\u003Cblockquote>\u003Cp>Cookie กับ Session ไม่ได้เป็นคู่แข่งกัน ส่วนใหญ่มันทำงานด้วยกัน Cookie ถือตั๋ว Session เก็บของ\u003C\u002Fp>\u003C\u002Fblockquote>\u003Ch2>ดู Header จริง: Set-Cookie กับ Cookie\u003C\u002Fh2>\u003Cp>กลไกทั้งหมดเกิดขึ้นใน Header สองตัวเท่านั้น ตอนที่ server อยากให้ browser ถือตั๋ว มันส่ง Header ชื่อ \u003Ccode>Set-Cookie\u003C\u002Fcode> มากับ Response และหลังจากนั้นทุก Request ที่ไปเว็บเดียวกัน browser จะแนบ Header ชื่อ \u003Ccode>Cookie\u003C\u002Fcode> กลับไปเองโดยอัตโนมัติ\u003C\u002Fp>\u003Cp>ทีมเราลองยิง \u003Ccode>curl\u003C\u002Fcode> ไปที่หน้าล็อกอินของ GitHub เมื่อวันที่ 29 กันยายน 2026 ได้ Header ตัวนี้กลับมา (ตัดค่าที่ยาวมากให้สั้นลง):\u003C\u002Fp>\u003Cpre>\u003Ccode>set-cookie: _gh_sess=CV5197blwy...; path=\u002F; HttpOnly; secure; SameSite=Lax\nset-cookie: logged_in=no; expires=Wed, 29 Sep 2027 04:40:57 GMT; domain=.github.com; path=\u002F; HttpOnly; secure; SameSite=Lax\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>สังเกตว่าเรายังไม่ได้ล็อกอินเลย แต่ GitHub ก็ออกตั๋วให้แล้ว และ \u003Ccode>logged_in=no\u003C\u002Fcode> บอกตรงๆ ว่าตอนนี้ยังเป็นคนแปลกหน้าอยู่ ส่วนตัวแรก \u003Ccode>_gh_sess\u003C\u002Fcode> ไม่มี \u003Ccode>expires\u003C\u002Fcode> ซึ่งมีความหมาย เดี๋ยวเราจะอธิบายในหัวข้อถัดไป\u003C\u002Fp>\u003Cp>เพื่อให้เห็นทั้งสองฝั่ง ทีมเราเขียน server เล็กๆ ด้วย Node.js ไม่ถึง 20 บรรทัด ให้สร้าง Session ตอนล็อกอิน แล้วลองยิงด้วย \u003Ccode>curl\u003C\u002Fcode> ผลที่ได้จริงเป็นแบบนี้:\u003C\u002Fp>\u003Cpre>\u003Ccode>$ curl -i localhost:3456\u002Flogin\nSet-Cookie: sid=fdcada48136db79c388c5993fefcdc22; Path=\u002F; HttpOnly; Secure; SameSite=Lax\nlogged in\n\n$ curl localhost:3456\u002Fme\nwho are you?\n\n$ curl -H \"Cookie: sid=fdcada48136db79c388c5993fefcdc22\" localhost:3456\u002Fme\nhello somchai\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>บรรทัดสุดท้ายคือหัวใจของเรื่องนี้ ค่า \u003Ccode>sid\u003C\u002Fcode> เป็นแค่ตัวอักษรสุ่ม ไม่มีชื่อ somchai อยู่ข้างในเลย ชื่อนั้นอยู่ในหน่วยความจำของ server พอเราแนบตั๋วใบเดิมไปใน Header \u003Ccode>Cookie\u003C\u002Fcode> server ก็เอาไปเปิดดูที่ราวของตัวเองแล้วรู้ทันทีว่าเราเป็นใคร ส่วน Request ที่ไม่มีตั๋ว server ตอบกลับว่าไม่รู้จัก\u003C\u002Fp>\u003Ch2>Attribute ที่ติดมากับตั๋ว: HttpOnly, Secure, SameSite, Expires\u003C\u002Fh2>\u003Cp>ข้อความหลังเครื่องหมาย \u003Ccode>;\u003C\u002Fcode> ใน \u003Ccode>Set-Cookie\u003C\u002Fcode> เรียกว่า Attribute มันคือกติกาที่ server สั่ง browser ว่าให้ดูแลตั๋วใบนี้ยังไง ตัวที่มือใหม่ควรรู้จักมีสี่ตัว (อ้างอิงคำอธิบายจาก \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FHTTP\u002FReference\u002FHeaders\u002FSet-Cookie\">MDN หน้า Set-Cookie\u003C\u002Fa>):\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>Expires \u002F Max-Age:\u003C\u002Fstrong> กำหนดอายุตั๋ว \u003Ccode>Expires\u003C\u002Fcode> ระบุเป็นวันเวลา ส่วน \u003Ccode>Max-Age\u003C\u002Fcode> ระบุเป็นจำนวนวินาที ถ้าใส่ทั้งคู่ \u003Ccode>Max-Age\u003C\u002Fcode> ชนะ ถ้าไม่ใส่เลย Cookie ตัวนั้นจะกลายเป็น Session Cookie ที่ถูกลบเมื่อ browser ปิด นี่คือเหตุผลที่ \u003Ccode>_gh_sess\u003C\u002Fcode> ของ GitHub ไม่มี \u003Ccode>expires\u003C\u002Fcode> ติดมา\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>HttpOnly:\u003C\u002Fstrong> ห้าม JavaScript อ่าน Cookie ตัวนี้ผ่าน \u003Ccode>document.cookie\u003C\u002Fcode> ช่วยลดความเสียหายจาก XSS (การฝังสคริปต์อันตรายลงในหน้าเว็บ) เพราะต่อให้สคริปต์แปลกปลอมรันได้ ก็หยิบตั๋วไปไม่ได้ แต่ Cookie ยังถูกส่งไปกับ \u003Ccode>fetch()\u003C\u002Fcode> ตามปกติ\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Secure:\u003C\u002Fstrong> ส่ง Cookie เฉพาะตอนเชื่อมต่อแบบ \u003Ccode>https:\u003C\u002Fcode> เท่านั้น (ยกเว้น localhost) กันไม่ให้ตั๋วหลุดระหว่างทางบนเครือข่ายที่ไม่เข้ารหัส\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>SameSite:\u003C\u002Fstrong> คุมว่าจะส่ง Cookie ไปกับ Request ที่มาจากเว็บอื่นไหม มีสามค่า \u003Ccode>Strict\u003C\u002Fcode> ส่งเฉพาะ Request จากเว็บเดียวกัน \u003Ccode>Lax\u003C\u002Fcode> ยอมส่งเพิ่มตอนผู้ใช้กดลิงก์จากเว็บอื่นเข้ามา และ \u003Ccode>None\u003C\u002Fcode> ส่งทุกกรณี แต่ต้องคู่กับ \u003Ccode>Secure\u003C\u002Fcode> เสมอ ช่วยป้องกัน CSRF (การหลอกให้ browser ส่งคำสั่งแทนคุณจากเว็บอื่น)\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>เรื่องค่าเริ่มต้นของ SameSite มีจุดที่ต้องระวัง \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.chromium.org\u002Fupdates\u002Fsame-site\u002F\">ทีม Chromium ประกาศ\u003C\u002Fa>ว่าตั้งแต่ Chrome 80 เป็นต้นมา Cookie ที่ไม่ระบุ SameSite จะถูกถือว่าเป็น \u003Ccode>SameSite=Lax\u003C\u002Fcode> แต่ MDN เขียนไว้ว่า \"บาง browser\" เท่านั้นที่ทำแบบนี้ ไม่ใช่ทุกตัว ข้อสรุปที่ปลอดภัยที่สุดจึงเป็นการใส่ SameSite เองให้ชัดทุกครั้ง อย่าฝากชีวิตไว้กับค่าเริ่มต้นของ browser ใด browser หนึ่ง\u003C\u002Fp>\u003Ch2>แล้ว localStorage ล่ะ ใช้เก็บแทน Cookie ไปเลยได้ไหม\u003C\u002Fh2>\u003Cp>ได้ และในหลายกรณีเป็นทางที่ดีกว่าด้วย \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FHTTP\u002FGuides\u002FCookies\">MDN แนะนำเอง\u003C\u002Fa>ว่าถ้าอยากเก็บข้อมูลฝั่ง client เช่น ธีมที่ผู้ใช้เลือก ให้ใช้ Web Storage API อย่าง \u003Ccode>localStorage\u003C\u002Fcode> หรือ \u003Ccode>sessionStorage\u003C\u002Fcode> แทน Cookie เพราะ Cookie ถูกส่งไปกับทุก Request ถ้ามีเยอะก็ทำให้เว็บช้าลง โดยเฉพาะบนเน็ตมือถือ ส่วน \u003Ccode>localStorage\u003C\u002Fcode> ไม่ถูกส่งไป server เลย และข้อมูลไม่มีวันหมดอายุจนกว่าจะถูกลบ ส่วน \u003Ccode>sessionStorage\u003C\u002Fcode> แม้ชื่อจะมีคำว่า session แต่เป็นคนละเรื่องกับ Session ฝั่ง server ที่เราพูดถึงในบทความนี้ มันคือ Web Storage ใน Browser ที่แยกตามแท็บ และข้อมูลจะถูกล้างเมื่อปิดแท็บหรือหน้าต่างนั้น\u003C\u002Fp>\u003Cp>แต่เรื่องจะเปลี่ยนเมื่อข้อมูลนั้นคือ \"ตั๋วยืนยันตัวตน\" \u003Ccode>localStorage\u003C\u002Fcode> ไม่มีอะไรเทียบเท่า HttpOnly สคริปต์ใดๆ ที่รันบนหน้านั้นอ่านได้ทั้งหมด ถ้าวันหนึ่งหน้าเว็บโดน XSS ตั๋วก็หลุดทันที ในขณะที่ Session ID ใน Cookie แบบ HttpOnly ยังปลอดภัยกว่าในสถานการณ์เดียวกัน\u003C\u002Fp>\u003Cp>พูดง่ายๆ คือ ข้อมูลที่ไม่ลับและ server ไม่ต้องรู้ เก็บ \u003Ccode>localStorage\u003C\u002Fcode> ได้ ส่วนตั๋วที่ใช้บอกว่าคุณคือใคร Cookie ที่ตั้ง Attribute ครบยังเป็นตัวเลือกมาตรฐาน\u003C\u002Fp>\u003Ch2>JWT คือทางเลือกที่ไม่ต้องมีราวแขวนเสื้อ\u003C\u002Fh2>\u003Cp>บางระบบไม่อยากให้ server ต้องจำ Session ของทุกคน เลยเปลี่ยนวิธีเป็นเขียนข้อมูลผู้ใช้ลงในตั๋วเองแล้วเซ็นกำกับไว้กันปลอม ตั๋วแบบนั้นคือ JWT (JSON Web Token) server แค่ตรวจลายเซ็น ไม่ต้องไปค้นราว ข้อดีข้อเสียของวิธีนี้มีรายละเอียดพอสมควร เราแยกไว้ในบทความ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fwhat-is-jwt-token-explained\">JWT Token คืออะไร\u003C\u002Fa> ถ้าอยากเห็นว่าฝั่ง server ตอบกลับยังไงเวลาไม่มีตั๋วหรือตั๋วใช้ไม่ได้ ลองอ่านเรื่อง 401 ใน \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fhttp-status-codes-explained\">HTTP Status Code\u003C\u002Fa> ต่อได้\u003C\u002Fp>\u003Ch2>ป้ายขอให้กดยอมรับคุกกี้ เป็นเรื่องเดียวกันไหม\u003C\u002Fh2>\u003Cp>เป็น Cookie ตัวเดียวกันในเชิงเทคนิค แต่เป็นคนละคำถาม Cookie ที่ใช้จำ Session ตอนล็อกอินคือสิ่งที่เว็บต้องมีเพื่อให้ทำงานได้ ส่วนป้ายที่เด้งขึ้นมาขอความยินยอมส่วนใหญ่เกี่ยวกับ Cookie ประเภทวิเคราะห์พฤติกรรมหรือโฆษณา ซึ่ง MDN จัดไว้ในกลุ่ม Tracking แยกจาก Session Management เรื่องการกดยอมรับเราเคยเขียนไว้แล้วใน \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fwhat-is-accepting-cookies-and-why\">การยอมรับคุกกี้คืออะไร ทำไมต้องยอมรับ\u003C\u002Fa> บทความนี้จึงขอโฟกัสที่ฝั่งกลไกอย่างเดียว\u003C\u002Fp>\u003Cp>ถ้าอยากเห็นภาพรวมว่า Session อยู่ในส่วนไหนของระบบเว็บ บทความ \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fweb-development-front-end-back-end-full-stack\">สำรวจโลกการพัฒนาเว็บไซต์ Front End, Back End และ Full Stack\u003C\u002Fa> จะช่วยให้เห็นว่าราวแขวนเสื้อตัวนี้อยู่ฝั่ง Back End และถ้าพร้อมลองของจริงในภาษา Go ตอน \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fblogs\u002Fgo-websocket-security-session-authentication\">Go กับ WebSocket Security\u003C\u002Fa> มีตัวอย่างการใช้ Session กับการยืนยันตัวตน\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>สรุป: Cookie กับ Session ต่างกันอย่างไร\u003C\u002Fh2>\u003Cp>Cookie คือตั๋วที่ browser ถือไว้และส่งกลับไปทุก Request ส่วน Session คือข้อมูลจริงที่ server เก็บไว้และใช้ตั๋วนั้นเปิดหา ทั้งสองอย่างทำงานคู่กันเพื่อแก้ปัญหาเดียว คือ HTTP จำใครไม่ได้ ถ้าจำได้แค่ประโยคเดียว ให้จำว่าข้อมูลอยู่ที่ server ส่วน browser ถือแค่ตั๋ว และตั๋วที่ดีต้องมี HttpOnly, Secure กับ SameSite กำกับเสมอ\u003C\u002Fp>\u003Cp>วิธีที่เร็วที่สุดที่จะเข้าใจเรื่องนี้จริงๆ คือเปิด DevTools ของ browser ไปที่แท็บ Network แล้วล็อกอินเว็บที่คุณใช้อยู่ทุกวัน ดูว่า Response ไหนมี \u003Ccode>Set-Cookie\u003C\u002Fcode> และ Request ถัดไปแนบ \u003Ccode>Cookie\u003C\u002Fcode> อะไรกลับไปบ้าง ห้านาทีกับการดูของจริงช่วยได้มากกว่าการอ่านนิยามซ้ำสิบรอบ\u003C\u002Fp>\u003Cp>ติดตามบทความและเทคนิคสำหรับคนเริ่มต้นสายโปรแกรมเมอร์ได้ที่ช่องทางของเรา\u003C\u002Fp>\u003Cp>Facebook: \u003Cstrong>Superdev School (Superdev)\u003C\u002Fstrong> — \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.facebook.com\u002Fsuperdev.school.th\">https:\u002F\u002Fwww.facebook.com\u002Fsuperdev.school.th\u003C\u002Fa>\u003C\u002Fp>\u003Cp>Instagram: \u003Cstrong>superdevschool\u003C\u002Fstrong> — \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.instagram.com\u002Fsuperdevschool\u002F\">https:\u002F\u002Fwww.instagram.com\u002Fsuperdevschool\u002F\u003C\u002Fa>\u003C\u002Fp>\u003Cp>TikTok: \u003Cstrong>superdevschool\u003C\u002Fstrong> — \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.tiktok.com\u002F@superdevschool\">https:\u002F\u002Fwww.tiktok.com\u002F@superdevschool\u003C\u002Fa>\u003C\u002Fp>\u003Cp>Website: \u003Cstrong>www.superdevacademy.com\u003C\u002Fstrong> — \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002F\">https:\u002F\u002Fwww.superdevacademy.com\u002F\u003C\u002Fa>\u003C\u002Fp>","cover_cover_nnoe78h814.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F5o1irkaf3iz5hnf\u002Fl\u002Fcover_cover_nnoe78h814.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F5o1irkaf3iz5hnf\u002Fm\u002Fcover_cover_nnoe78h814.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F5o1irkaf3iz5hnf\u002Fcover_cover_nnoe78h814.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002F5o1irkaf3iz5hnf\u002Fs\u002Fcover_cover_nnoe78h814.webp","2026-09-29 04:46:20.220Z","wfztm6bp9384v3u",{"keywords":18,"locale":48,"school_blog":58},[19,25,29,33,36,40,44],{"collectionId":20,"collectionName":21,"created":22,"created_by":16,"id":23,"name":24,"updated":22,"updated_by":16},"sclkey987654321","school_keywords","2026-09-29 04:46:20.212Z","w963558kn166h79","cookie กับ session ต่างกันอย่างไร",{"collectionId":20,"collectionName":21,"created":26,"created_by":16,"id":27,"name":28,"updated":26,"updated_by":16},"2026-09-29 04:46:20.213Z","yuspyafvu2u6ptl","session คืออะไร",{"collectionId":20,"collectionName":21,"created":30,"created_by":16,"id":31,"name":32,"updated":30,"updated_by":16},"2026-09-29 04:46:20.215Z","u4w7npeduxukkuz","session cookie",{"collectionId":20,"collectionName":21,"created":30,"created_by":16,"id":34,"name":35,"updated":30,"updated_by":16},"6xx0oa2skxld2dq","httponly cookie",{"collectionId":20,"collectionName":21,"created":37,"created_by":16,"id":38,"name":39,"updated":37,"updated_by":16},"2026-09-29 04:46:20.216Z","stj7co03owu7fsy","localstorage vs cookie",{"collectionId":20,"collectionName":21,"created":41,"created_by":16,"id":42,"name":43,"updated":41,"updated_by":16},"2026-09-29 04:46:20.217Z","m941gwcgtdww0d4","set-cookie",{"collectionId":20,"collectionName":21,"created":45,"created_by":16,"id":46,"name":47,"updated":45,"updated_by":16},"2026-10-01 01:50:37.374Z","8n39x00sbmj0vzd","session หมดอายุ",{"code":49,"collectionId":50,"collectionName":51,"created":52,"flag":53,"id":54,"is_default":55,"label":56,"updated":57},"th","pbc_1989393366","locales","2026-01-22 10:59:55.832Z","twemoji:flag-thailand","s8wri3bt4vgg2ji",true,"Thai","2026-04-10 15:42:46.614Z",{"category":59,"collectionId":60,"collectionName":61,"created":62,"expand":63,"id":80,"slug":81,"updated":82,"views":83},"rfxf19ot4iq992c","pbc_2105096300","school_blogs","2026-09-29 04:46:20.218Z",{"category":64},{"blogIds":65,"collectionId":66,"collectionName":67,"created":68,"created_by":69,"id":59,"image":70,"image_alt":71,"image_path":72,"image_s_url":73,"label":74,"name":75,"priority":76,"publish_at":77,"scheduled_at":71,"status":78,"updated":79,"updated_by":69},[],"sclcatblg987654321","school_category_blogs","2026-03-04 08:32:03.969Z","76qprkevbgfdps8","7acfigk1qkd_lv1k6bkji3_7h89h9h63a.webp","","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclcatblg987654321\u002Frfxf19ot4iq992c\u002F7acfigk1qkd_lv1k6bkji3_7h89h9h63a.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclcatblg987654321\u002Frfxf19ot4iq992c\u002Fs\u002F7acfigk1qkd_lv1k6bkji3_7h89h9h63a.webp",{"en":75,"th":75},"Web Development",0,"2025-01-21 03:43:00.282Z","published","2026-08-18 14:48:42.218Z","rnj71f99yfx3r2p","cookie-vs-session-explained","2026-10-07 10:10:02.849Z",103,"5o1irkaf3iz5hnf",[23,27,31,34,38,42,46],"2026-10-07 10:09:45.835Z","Cookie กับ Session ต่างกันอย่างไร ดู Header Set-Cookie ของจริง ทำไมข้อมูลอยู่ที่ server ส่วน browser ถือแค่ตั๋ว พร้อม HttpOnly, Secure, SameSite","Cookie กับ Session ต่างกันอย่างไร ทำไมเว็บจำว่าคุณล็อกอินอยู่","2026-10-07 10:09:45.837Z","ebkf8ra4nd55ual",1,{"th":81,"en":81},[94,98,102,106,110,114],{"answer":95,"id":96,"question":97},"Cookie คือข้อมูลชิ้นเล็กที่ browser เก็บไว้และแนบไปใน Header ชื่อ Cookie ทุกครั้งที่ส่ง Request ส่วน Session คือข้อมูลของผู้ใช้ที่ server เก็บไว้ฝั่งตัวเอง สองอย่างนี้มักทำงานคู่กัน โดย server ส่ง Set-Cookie ที่มี Session ID ให้ browser ถือไว้เหมือนตั๋วรับของ แล้วใช้ตั๋วนั้นเปิดหาข้อมูล Session ที่ถูกต้องในทุก Request ถัดไป","u8rrs4yz7900j8u","Cookie กับ Session ต่างกันอย่างไร",{"answer":99,"id":100,"question":101},"Session Cookie คือ Cookie ที่ server ส่งมาโดยไม่ใส่ Attribute Expires หรือ Max-Age ตาม MDN มันจะถูกลบเมื่อ browser ปิด ส่วน Cookie ที่ใส่ Expires เป็นวันเวลา หรือ Max-Age เป็นจำนวนวินาที จะอยู่ได้จนถึงเวลานั้นแม้ปิด browser ไปแล้ว ถ้าใส่ทั้งสองตัว Max-Age มีผลเหนือกว่า ตัวอย่างจริงคือ Cookie _gh_sess ของ GitHub ที่ส่งมาโดยไม่มี Expires ติดมาเลย","7b2rezdw7rgng2q","Session Cookie คืออะไร ต่างจาก Cookie ที่อยู่ได้นานยังไง",{"answer":103,"id":104,"question":105},"Session หมดอายุหมายความว่า server ไม่รู้จัก Session ID ที่ browser ส่งมาอีกต่อไป อาจเพราะ server ลบข้อมูล Session ทิ้งหลังไม่มีการใช้งานตามเวลาที่ระบบตั้งไว้ หรือเพราะ Cookie ที่ถือ Session ID หมดอายุตาม Expires หรือ Max-Age ผลคือ Request ถัดไปถูกมองเป็นคนแปลกหน้า เว็บจึงพาคุณกลับไปหน้าล็อกอิน ระยะเวลาเป็นค่าที่แต่ละเว็บกำหนดเอง ไม่มีตัวเลขมาตรฐานกลาง","fquljs2k0zo8ojd","Session หมดอายุ หมายความว่าอะไร ทำไมต้องล็อกอินใหม่",{"answer":107,"id":108,"question":109},"HttpOnly คือ Attribute ใน Set-Cookie ที่ห้าม JavaScript อ่าน Cookie ตัวนั้นผ่าน document.cookie ทำให้สคริปต์อันตรายที่ฝังเข้ามาทาง XSS หยิบ Session ID ไปไม่ได้ แต่ browser ยังแนบ Cookie ไปกับ Request ปกติ รวมถึงที่ส่งด้วย fetch() อยู่ MDN จึงอธิบายว่า HttpOnly ช่วยลดความเสียหายจาก XSS ไม่ได้ป้องกันทุกการโจมตี ควรใช้คู่กับ Secure และ SameSite","tu2hppe2brmbb4e","HttpOnly Cookie คืออะไร ช่วยเรื่องความปลอดภัยยังไง",{"answer":111,"id":112,"question":113},"localStorage เก็บข้อมูลไว้ใน browser โดยไม่ถูกส่งไป server เลย และไม่มีวันหมดอายุจนกว่าจะถูกลบ ส่วน Cookie ถูกแนบไปกับทุก Request ของเว็บนั้นและกำหนดอายุได้ด้วย Expires หรือ Max-Age MDN แนะนำให้ใช้ localStorage กับข้อมูลฝั่ง client ทั่วไป เช่น ธีมที่ผู้ใช้เลือก แต่ JavaScript ทุกตัวบนหน้าอ่าน localStorage ได้ จึงไม่มีการป้องกันแบบ HttpOnly ที่ Cookie มี","dnwy0vvzw5qmie9","localStorage กับ Cookie ต่างกันอย่างไร",{"answer":115,"id":116,"question":117},"มาตรฐาน RFC 6265 กำหนดว่า browser ทั่วไปควรรองรับอย่างน้อย 4096 bytes ต่อ Cookie หนึ่งตัว นับรวมชื่อ ค่า และ Attribute อย่างน้อย 50 ตัวต่อโดเมน และ 3000 ตัวรวมทั้งหมด ตัวเลขนี้คือขั้นต่ำที่ควรรองรับ ไม่ใช่เพดานที่ทุก browser ใช้เท่ากัน RFC เดียวกันแนะนำให้ server ใช้ Cookie ให้น้อยและเล็กที่สุด เพราะ Header Cookie ถูกส่งไปกับทุก Request","54qaun2eh7u8iqy","Cookie หนึ่งตัวเก็บข้อมูลได้สูงสุดเท่าไหร่"]