อะไรคือความแตกต่างระหว่างคุกกี้ฝั่งเซิร์ฟเวอร์และคุกกี้ฝั่งไคลเอ็นต์?


120

อะไรคือความแตกต่างระหว่างการสร้างคุกกี้บนเซิร์ฟเวอร์และบนไคลเอนต์? สิ่งเหล่านี้เรียกว่าคุกกี้ฝั่งเซิร์ฟเวอร์และคุกกี้ฝั่งไคลเอ็นต์หรือไม่ มีวิธีสร้างคุกกี้ที่สามารถอ่านได้เฉพาะบนเซิร์ฟเวอร์หรือบนไคลเอนต์หรือไม่?


15
ไม่มีสิ่งที่เรียกว่า 'คุกกี้ฝั่งเซิร์ฟเวอร์' กับ 'คุกกี้ฝั่งไคลเอ็นต์' มีเพียงคุกกี้คู่ชื่อ / ค่าที่ส่งในส่วนหัว HTTP พร้อมทั้งคำขอและการตอบกลับ
Dan Grossman

1
อาจอ้างถึงตัวแปรเซสชันซึ่งเก็บข้อมูลบนเซิร์ฟเวอร์ โดยปกติจะยังคงมีตัวระบุเซสชันที่ถือเป็นคุกกี้ฝั่งไคลเอ็นต์
AndrewR

ในความเป็นไปได้ทั้งหมดคำถามหมายถึงวิธีการเข้ารหัสคุกกี้ที่แตกต่างกันบนฝั่งเซิร์ฟเวอร์ (เช่นวิธีเข้ารหัสในส่วนหัวการตอบกลับ "คุกกี้" และ "คุกกี้ชุด") และทางฝั่งไคลเอ็นต์ (เช่น 'เข้ารหัสในส่วนหัวคำขอ' คุกกี้ '- ตัวแปร $ Path และแจ๊สทั้งหมด) ดูRFC 2109
Ophir Radnitz

คำตอบ:


146

คุกกี้ HTTP

คุกกี้คือคู่คีย์ / ค่าที่เว็บไซต์ใช้เพื่อเก็บข้อมูลสถานะบนเบราว์เซอร์ สมมติว่าคุณมีเว็บไซต์ (example.com) เมื่อเบราว์เซอร์ขอหน้าเว็บเว็บไซต์สามารถส่งคุกกี้เพื่อจัดเก็บข้อมูลบนเบราว์เซอร์ได้

ตัวอย่างคำขอเบราว์เซอร์:

GET /index.html HTTP/1.1
Host: www.example.com

ตัวอย่างคำตอบจากเซิร์ฟเวอร์:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: foo=10
Set-Cookie: bar=20; Expires=Fri, 30 Sep 2011 11:48:00 GMT
... rest  of the response

ที่นี่สองคุกกี้ foo = 10 และ bar = 20 จะถูกเก็บไว้ในเบราว์เซอร์ อันที่สองจะหมดอายุในวันที่ 30 กันยายน ในแต่ละคำขอที่ตามมาเบราว์เซอร์จะส่งคุกกี้กลับไปที่เซิร์ฟเวอร์

GET /spec.html HTTP/1.1
Host: www.example.com
Cookie: foo=10; bar=20
Accept: */*

SESSIONS: คุกกี้ฝั่งเซิร์ฟเวอร์

คุกกี้ฝั่งเซิร์ฟเวอร์เรียกว่า "เซสชัน" เว็บไซต์ในกรณีนี้เก็บคุกกี้เดียวบนเบราว์เซอร์ที่มี Session Identifier เฉพาะ ข้อมูลสถานะ (foo = 10 และ bar = 20 ด้านบน) จะถูกเก็บไว้บนเซิร์ฟเวอร์และ Session Identifier จะใช้เพื่อจับคู่คำขอกับข้อมูลที่เก็บไว้บนเซิร์ฟเวอร์

ตัวอย่างการใช้งาน

คุณสามารถใช้ทั้งเซสชันและคุกกี้เพื่อจัดเก็บ: ข้อมูลการตรวจสอบสิทธิ์การตั้งค่าของผู้ใช้เนื้อหาของแผนภูมิในเว็บไซต์อีคอมเมิร์ซ ฯลฯ ...

ข้อดีและข้อเสีย

ด้านล่างข้อดีข้อเสียของการแก้ปัญหา นี่คือสิ่งแรกที่อยู่ในความคิดของฉันมีคนอื่น ๆ อย่างแน่นอน

ข้อดีของคุกกี้:

  • ความสามารถในการปรับขนาด: ข้อมูลทั้งหมดจะถูกเก็บไว้ในเบราว์เซอร์ดังนั้นแต่ละคำขอจึงสามารถส่งผ่านตัวจัดสรรภาระงานไปยังเว็บเซิร์ฟเวอร์ต่างๆและคุณมีข้อมูลทั้งหมดที่จำเป็นในการกรอกคำขอ
  • สามารถเข้าถึงได้ผ่านทางจาวาสคริปต์บนเบราว์เซอร์
  • ไม่ได้อยู่บนเซิร์ฟเวอร์พวกเขาจะรอดจากการรีสตาร์ทเซิร์ฟเวอร์
  • RESTful: คำขอไม่ขึ้นอยู่กับสถานะเซิร์ฟเวอร์

ข้อเสียของคุกกี้:

ข้อดีของเซสชั่น:

  • โดยทั่วไปใช้งานง่ายกว่าใน PHP อาจไม่แตกต่างกันมากนัก
  • พื้นที่เก็บข้อมูลไม่ จำกัด

จุดด้อยของเซสชัน:

  • ปรับขนาดได้ยากขึ้น
  • บนเว็บเซิร์ฟเวอร์รีสตาร์ทคุณอาจสูญเสียเซสชันทั้งหมดหรือไม่ขึ้นอยู่กับการใช้งาน
  • ไม่สงบ

ข้อดีของเซสชั่น: secure?
user2167582

1
ทำไมเซสชันจึงปลอดภัยมากขึ้น? หากคุณส่งคุกกี้เซสชันผ่าน http อาจถูกไฮแจ็คได้ หากไซต์ใช้การรักษาความปลอดภัย https ควรจะเหมือนกับตราบใดที่คุณใช้คุกกี้ที่ปลอดภัย (เข้ารหัสลงนาม ฯลฯ ... )
filippo

1
ข้อเสียของคุกกี้: ทำให้แต่ละคำขอใหญ่ขึ้นและอาจส่งผลต่อประสิทธิภาพ ฉันไม่รู้ตัวเลข แต่เนื่องจากผู้คนใช้โดเมนที่ไม่มีคุกกี้ในสิ่งที่ฉันคิดว่ามันไม่สำคัญ
maniexx

5
คำตอบที่ทำให้เข้าใจผิดเป็นส่วนใหญ่ - เซสชันไม่ใช่คุกกี้ en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_sessionคุณสามารถมีตัวแปรเซสชันขึ้นอยู่กับวิธีการใช้การจัดการเซสชันบนเซิร์ฟเวอร์ โดยปกติคุณจะมีคุกกี้อย่างน้อยหนึ่งรายการที่เกี่ยวข้องกับการจัดการเซสชันโดยการถือตัวระบุเซสชัน REST และ RESTful ไม่มีส่วนเกี่ยวข้องกับคุกกี้หรือการจัดการเซสชัน - การใช้งาน REST และ RESTful สามารถมีเซสชันและคุกกี้ได้
Zlatin Zlatev

2
ดูstackoverflow.com/questions/35054840/…ฉันไม่ได้บอกว่าโดยทั่วไปเซสชันจะไม่ใช้กับคุกกี้ แต่มีตัวเลือกอื่น ๆ สำหรับการจัดการเซสชันดังนั้นจึงไม่ถูกต้องที่จะพูดถึงตัวแปรเซสชันเป็นคุกกี้ฝั่งเซิร์ฟเวอร์ ฉันยังอ้างถึง JWT เมื่อฉันพูดในปี 2017 ในความคิดเห็นด้านบนว่า "การใช้งาน REST และ RESTful สามารถมีเซสชันและคุกกี้ได้" แม้ว่านักปราชญ์บางคนอาจโต้แย้งว่านี่ไม่ใช่วิธีที่เหมาะสมในการใช้งาน REST API
Zlatin Zlatev

57

คุณอาจหมายถึงความแตกต่างระหว่างคุกกี้ Http Onlyกับส่วนที่เป็นตัวนับหรือไม่?

ไม่สามารถเข้าถึง Http คุกกี้เท่านั้น (อ่านจากหรือเขียนถึง) ใน JavaScript ฝั่งไคลเอ็นต์เฉพาะฝั่งเซิร์ฟเวอร์ หากไม่ได้ตั้งค่าสถานะ Http Only หรือคุกกี้ถูกสร้างขึ้นใน JavaScript (ฝั่งไคลเอ็นต์) คุกกี้สามารถอ่านและเขียนลงใน JavaScript (ฝั่งไคลเอ็นต์) ได้เช่นเดียวกับฝั่งเซิร์ฟเวอร์


38

คุกกี้ทั้งหมดเป็นไคลเอนต์และเซิร์ฟเวอร์

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

แต่โดยพื้นฐานแล้วมันคือคุกกี้ตัวเดียวกัน

แต่พฤติกรรมสามารถเปลี่ยนแปลงได้

โดยพื้นฐานแล้วคุกกี้เป็นname=valueคู่ แต่หลังจากค่าแล้วอาจเป็นแอตทริบิวต์ที่คั่นด้วยเครื่องหมายอัฒภาคจำนวนหนึ่งซึ่งส่งผลต่อพฤติกรรมของคุกกี้หากไคลเอ็นต์ (หรือเซิร์ฟเวอร์) ใช้งานเช่นนั้น คุณลักษณะเหล่านั้นอาจเกี่ยวกับอายุการใช้งานบริบทและการตั้งค่าความปลอดภัยต่างๆ

HTTP เท่านั้น (ไม่ใช่เซิร์ฟเวอร์เท่านั้น)

หนึ่งในแอตทริบิวต์เหล่านี้สามารถกำหนดโดยเซิร์ฟเวอร์เพื่อระบุว่าเป็นคุกกี้ HTTP เท่านั้น ซึ่งหมายความว่าคุกกี้ยังคงถูกส่งไปมา แต่จะไม่สามารถใช้งานได้ใน JavaScript อย่างไรก็ตามโปรดทราบว่าคุกกี้ยังคงอยู่ที่นั่น! มันเป็นเพียงการป้องกันในตัวเบราว์เซอร์ แต่ถ้าใครจะใช้เบราว์เซอร์รุ่นเก่าที่น่าขันเช่น IE5 หรือไคลเอนต์ที่กำหนดเองพวกเขาก็สามารถอ่านคุกกี้ได้!

ดูเหมือนว่าจะมี 'เซิร์ฟเวอร์คุกกี้' แต่จริงๆแล้วไม่มี คุกกี้เหล่านั้นยังคงถูกส่งไปยังไคลเอนต์ บนไคลเอนต์ไม่มีวิธีป้องกันไม่ให้ส่งคุกกี้ไปยังเซิร์ฟเวอร์

ทางเลือกอื่นในการบรรลุ 'only-ness'

หากคุณต้องการจัดเก็บค่าเฉพาะบนเซิร์ฟเวอร์หรือเฉพาะบนไคลเอนต์คุณจะต้องมีที่เก็บข้อมูลประเภทอื่นเช่นไฟล์หรือฐานข้อมูลบนเซิร์ฟเวอร์หรือ Local Storage บนไคลเอนต์


สวัสดีฉันใหม่มากสำหรับแนวคิดเหล่านี้และมีข้อสงสัย ฉันขอโทษคำถามของฉันอาจฟังดูไร้สาระ แต่ฉันก็ยังจะถาม ความช่วยเหลือใด ๆ ที่ได้รับการชื่นชมมาก - คุกกี้ที่ตั้งค่าทางฝั่งไคลเอ็นต์สามารถส่งไปยังโดเมนใด ๆ ได้หรือไม่? ฉันหมายความว่านั่นไม่ใช่ภัยคุกคามด้านความปลอดภัยใช่ไหม นอกจากนี้ยังทำงานกับไคลเอนต์ที่ไม่ใช่เบราว์เซอร์เช่น API ฯลฯ ได้อย่างไร
Karan Chadha

1
สวัสดี @KaranChadha หากคุณมีคำถามโปรดถามเป็นคำถามที่เป็นทางการโดยใช้ปุ่ม 'ถามคำถาม' ที่ด้านบนของหน้า กระทู้แสดงความคิดเห็นเกี่ยวกับคำถามอายุ 7 ปีอาจไม่ได้รับความสนใจมากนัก การเพิ่มลิงก์ไปยังคำถามและคำตอบนี้หรือแม้แต่กับคำตอบนี้โดยเฉพาะก็ทำได้ดี คุณสามารถใช้ปุ่ม 'แบ่งปัน' ที่ด้านล่างของแต่ละโพสต์สำหรับสิ่งนั้น
GolezTrol

นี่คือเรื่องจริง? ดูเหมือนว่าคุกกี้ที่สร้างโดยลูกค้าจะไม่ถูกโอน ถ้าทำdocument.cookie="foo=bar"ตามด้วยมีคุกกี้ถูกส่งไปที่มีไม่มีfetch("/foobar", {credentials: 'include'} ) foo=barเพิ่งลองใช้รหัสนั้นโดยตรงบนไซต์นี้โดยใช้ DevTools และคอนโซล
oligofren

ใช่มันเป็นความจริงเอกสารก็พูดเช่นกัน แต่มีข้อมูลเฉพาะบางอย่างที่อาจทำให้เกิดสิ่งนี้เช่นแอตทริบิวต์การหมดอายุที่ขาดหายไป
GolezTrol

1
@MarinosAn ใช่มันทำได้ แต่คำตอบของฉันสั้นไปหน่อยเมื่อพูดถึงคุณลักษณะที่ปรับเปลี่ยนพฤติกรรมของคุกกี้ดังนั้นฉันจึงขยายเล็กน้อยในตอนนี้
GolezTrol

4
  1. ใช่คุณสามารถสร้างคุกกี้ที่สามารถอ่านได้บนฝั่งเซิร์ฟเวอร์เท่านั้น สิ่งเหล่านี้เรียกว่าคุกกี้ "HTTP Only" ตามที่อธิบายไว้ในคำตอบอื่น ๆ แล้ว

  2. ไม่ไม่มีทาง (ฉันรู้) ในการสร้าง "คุกกี้" ที่สามารถอ่านได้เฉพาะในฝั่งไคลเอ็นต์เท่านั้น คุกกี้มีขึ้นเพื่ออำนวยความสะดวกในการสื่อสารไคลเอนต์เซิร์ฟเวอร์

  3. แต่ถ้าคุณต้องการบางอย่างเช่น "ไคลเอนต์เท่านั้น - คุกกี้" มีคำตอบง่ายๆคือใช้ "ที่เก็บข้อมูลในเครื่อง"

ที่เก็บข้อมูลในเครื่องใช้งานง่ายกว่าคุกกี้ คุณสามารถดูข้อมูลสรุปอย่างง่ายของคุกกี้กับที่เก็บข้อมูลในเครื่องได้ที่:

https://courses.cs.washington.edu/courses/cse154/12au/lectures/slides/lecture21-client-storage.shtml#slide8

ประเด็น: คุณอาจใช้คุกกี้ที่สร้างใน JavaScript เพื่อจัดเก็บสิ่งที่เกี่ยวข้องกับ GUI ที่คุณต้องการเฉพาะในฝั่งไคลเอ็นต์ แต่คุกกี้จะถูกส่งไปยังเซิร์ฟเวอร์สำหรับทุกคำขอที่ทำขึ้นมันจะกลายเป็นส่วนหนึ่งของส่วนหัวของคำขอ http จึงทำให้คำขอมีข้อมูลมากขึ้นและส่งช้าลง

หากเพจของคุณมีทรัพยากร 50 รายการเช่นรูปภาพและไฟล์ css และสคริปต์คุกกี้จะถูกส่งไปพร้อมกับคำขอแต่ละรายการ ข้อมูลเพิ่มเติมในทุกคำขอของเว็บส่งคุกกี้ของเบราว์เซอร์หรือไม่

พื้นที่จัดเก็บข้อมูลในเครื่องไม่มีข้อเสียที่เกี่ยวข้องกับการถ่ายโอนข้อมูลจึงไม่ส่งข้อมูล มันยอดเยี่ยมมาก

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.