서버 측 쿠키와 클라이언트 측 쿠키의 차이점은 무엇입니까?

120

서버와 클라이언트에서 쿠키를 만드는 것의 차이점은 무엇입니까? 이를 서버 측 쿠키 및 클라이언트 측 쿠키라고합니까? 서버 또는 클라이언트에서만 읽을 수있는 쿠키를 만드는 방법이 있습니까?

http cookies session-cookies

— 라훌
소스

15

'서버 측 쿠키'와 '클라이언트 측 쿠키'와 같은 것은 없습니다. 요청과 응답 모두와 함께 HTTP 헤더로 전송 된 쿠키, 이름 / 값 쌍만 있습니다.

— Dan Grossman

1

서버에 데이터를 보유하는 세션 변수를 참조 할 수 있습니다. 일반적으로 클라이언트 측 쿠키로 보관되는 세션 식별자가 있습니다.

— AndrewR

이 질문은 쿠키가 서버 측에서 인코딩되는 방식 (예 : 'Cookie'및 'Set-Cookie'응답 헤더에 인코딩되는 방식)과 클라이언트 측 (예 : '쿠키'요청 헤더에 인코딩되어 있습니다-$ 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이 브라우저에 저장됩니다. 두 번째는 9 월 30 일에 만료됩니다. 이후의 각 요청에서 브라우저는 쿠키를 서버로 다시 보냅니다.

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

세션 : 서버 측 쿠키

서버 측 쿠키를 "세션"이라고합니다. 이 경우 웹 사이트는 고유 한 세션 식별자를 포함하는 단일 쿠키를 브라우저에 저장합니다. 상태 정보 (위의 foo = 10 및 bar = 20)는 서버에 저장되고 세션 식별자는 요청을 서버에 저장된 데이터와 일치시키는 데 사용됩니다.

사용 예

세션과 쿠키를 모두 사용하여 인증 데이터, 사용자 기본 설정, 전자 상거래 웹 사이트의 차트 콘텐츠 등을 저장할 수 있습니다.

장점과 단점

솔루션의 장단점 아래. 이것이 내 마음에 가장 먼저 떠오르는 것입니다. 확실히 다른 것들이 있습니다.

쿠키 프로 :

확장 성 : 모든 데이터가 브라우저에 저장되므로 각 요청이로드 밸런서를 통해 서로 다른 웹 서버로 이동할 수 있으며 요청을 완료하는 데 필요한 모든 정보가 있습니다.
브라우저에서 자바 스크립트를 통해 액세스 할 수 있습니다.
서버에 있지 않으면 서버가 다시 시작 되어도 유지됩니다.
RESTful : 요청은 서버 상태에 의존하지 않습니다.

쿠키 단점 :

저장 용량은 80KB (쿠키 20 개, 각 4KB) 로 제한 됩니다.
보안 쿠키는 구현하기 쉽지 않습니다. 보안 쿠키 프로토콜 문서를 살펴보십시오.

세션 전문가 :

일반적으로 사용하기 쉽고 PHP에서는 큰 차이가 없을 것입니다.
무제한 저장

세션 단점 :

확장하기 더 어렵다
웹 서버가 다시 시작되면 구현에 따라 모든 세션이 손실 될 수 있습니다.
RESTful이 아님

— Filippo
소스

세션 전문가 : secure?

— user2167582

1

세션이 더 안전한 이유는 무엇입니까? http를 통해 세션 쿠키를 보내면 하이재킹 될 수 있습니다. 사이트가 HTTPS를 사용하는 경우에는 보안 쿠키 (암호화, 서명 등) 사용으로 보안은 오랫동안 같이 동일해야합니다

— 필리포

1

쿠키 단점 : 각 요청을 더 크게 만들어 잠재적으로 성능에 영향을 미칩니다. 나는 숫자를 모르지만 사람들이 쿠키없는 도메인을 사용하기 때문에 사소하지 않다고 생각합니다.

— maniexx

5

오해의 소지가있는 답변-세션은 쿠키가 아닙니다. en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#HTTP_session 세션 관리가 서버에서 구현되는 방식에 따라 세션 변수를 가질 수 있습니다. 일반적으로 세션 식별자를 보유하면 세션 관리와 관련된 하나 이상의 쿠키가 있습니다. 또한 REST 및 RESTful은 쿠키 또는 세션 관리와 관련이 없습니다. REST 및 RESTful 구현은 세션 및 쿠키를 가질 수 있습니다.

— Zlatin Zlatev

2

참조 stackoverflow.com/questions/35054840/...을 따라서는 서버 측 쿠키 등의 세션 변수에 대해 이야기하는 것은 잘못이다, 내가 세션 관리를위한 다른 옵션이 있다는 세션은 일반적으로 쿠키 구현되지 않는다는 말을하지만,되지 않았습니다. 또한 2017 년에 위의 주석에서 "REST 및 RESTful 구현은 세션과 쿠키를 가질 수 있습니다"라고 말했을 때 JWT를 언급했습니다. 일부 순수 주의자들은 이것이 REST API를 구현하는 적절한 방법이 아니라고 주장 할 수 있습니다.

— Zlatin Zlatev

57

아마도 Http Only 쿠키 와 카운터 부분 의 차이점을 의미 합니까?

Http 전용 쿠키는 클라이언트 측 JavaScript에서 액세스 (읽기 또는 쓰기) 할 수 없으며 서버 측에서만 액세스 할 수 있습니다. Http Only 플래그가 설정되지 않았거나 쿠키가 (클라이언트 측) JavaScript에서 생성 된 경우, 쿠키는 서버 측뿐만 아니라 (클라이언트 측) JavaScript에서 읽고 쓸 수 있습니다.

— nikc.org
소스

38

모든 쿠키는 클라이언트 와 서버입니다.

다른 점이 없다. 일반 쿠키는 서버 측 또는 클라이언트 측으로 설정할 수 있습니다. '클래식'쿠키는 각 요청과 함께 다시 전송됩니다. 서버에서 설정 한 쿠키는 응답으로 클라이언트로 전송됩니다. 서버는 명시 적으로 설정되거나 변경된 경우에만 쿠키를 전송하고 클라이언트는 각 요청에 대해 쿠키를 전송합니다.

그러나 본질적으로 동일한 쿠키입니다.

하지만 행동은 바뀔 수 있습니다

쿠키는 기본적으로 name=value쌍이지만 값 뒤에는 클라이언트 (또는 서버)에 의해 구현 된 경우 쿠키의 동작에 영향을주는 세미콜론으로 구분 된 속성 이 있을 수 있습니다. 이러한 속성은 수명, 컨텍스트 및 다양한 보안 설정에 관한 것일 수 있습니다.

HTTP 전용 (서버 전용 아님)

이러한 속성 중 하나는 HTTP 전용 쿠키임을 나타 내기 위해 서버에서 설정할 수 있습니다. 이는 쿠키가 계속 전송되지만 JavaScript에서는 사용할 수 없음을 의미합니다. 하지만 쿠키는 아직 거기에 있습니다! 브라우저에 내장 된 보호 기능 일 뿐이지 만, 누군가 IE5와 같은 엄청나게 오래된 브라우저 나 사용자 지정 클라이언트를 사용한다면 실제로 쿠키를 읽을 수 있습니다!

그래서 '서버 쿠키'가있는 것처럼 보이지만 실제로는 없습니다. 이러한 쿠키는 여전히 클라이언트로 전송됩니다. 클라이언트에서는 쿠키가 서버로 전송되는 것을 막을 방법이 없습니다.

'유일 함'을 달성하기위한 대안

값을 서버에만 저장하거나 클라이언트에만 저장하려면 서버의 파일이나 데이터베이스 또는 클라이언트의 로컬 저장소와 같은 다른 종류의 저장소가 필요합니다.

— GolezTrol
소스

안녕하세요, 저는 이러한 개념에 매우 익숙하며 의심이 있습니다. 미안합니다. 제 질문이 어리석게 들릴지 모르지만 여전히 묻겠습니다. 도움을 주시면 감사하겠습니다. 클라이언트 측에 설정된 쿠키를 모든 도메인으로 보낼 수 있습니까? 그게 보안 위협이 아닙니까? 또한 API 등과 같은 브라우저가 아닌 클라이언트에서는 어떻게 작동합니까?

— Karan Chadha

1

안녕하세요 @KaranChadha 님, 질문이 있으시면 페이지 상단의 '질문하기'버튼을 사용하여 정식 질문으로 질문하십시오. 7 년 된 질문에 대한 댓글 스레드는 아마도 적절한 관심을 끌지 못할 것입니다. 이 Q & A 또는이 답변에 대한 링크를 추가하는 것은 물론 괜찮습니다. 이를 위해 각 게시물 하단의 '공유'버튼을 사용할 수 있습니다.

— GolezTrol

이것이 사실입니까? 클라이언트 생성 쿠키가 전송되지 않는 것 같습니다. document.cookie="foo=bar"다음을 수행하면을 fetch("/foobar", {credentials: 'include'} )포함하는 쿠키가 전송되지 않습니다 foo=bar. DevTools와 콘솔을 사용하여이 사이트에서 직접 해당 코드를 시도했습니다.

— oligofren

예, 사실입니다 . docs도 말합니다 . 그러나 누락 된 만료 속성과 같이이를 유발할 수있는 몇 가지 세부 사항이 있습니다.

— GolezTrol

1

@MarinosAn 예, 할 수 있습니다. 하지만 내 대답은 쿠키의 동작을 수정하는 속성에 관해서는 약간 짧았 기 때문에 조금 확장했습니다.

— GolezTrol

4

예, 서버 측에서만 읽을 수있는 쿠키를 만들 수 있습니다. 이미 다른 답변에서 설명한 것처럼 "HTTP 전용"쿠키라고합니다.
아니요, 클라이언트 측에서만 읽을 수있는 "쿠키"를 만들 수있는 방법은 없습니다. 쿠키는 클라이언트-서버 통신을 용이하게하기위한 것입니다.
그러나 "클라이언트 전용 쿠키"와 같은 것을 원한다면 간단한 대답이 있습니다. "로컬 저장소"를 사용하십시오.

로컬 저장소는 실제로 쿠키보다 사용하기가 더 간단합니다. 쿠키와 로컬 저장소에 대한 간단한 요약은 다음에서 찾을 수 있습니다.

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

요점 : 클라이언트 측에서만 필요한 GUI 관련 항목을 저장하기 위해 JavaScript로 생성 된 쿠키를 사용할 수 있습니다. 그러나 쿠키는 모든 요청에 대해 서버로 전송되며 http-request 헤더의 일부가되므로 요청에 더 많은 데이터가 포함되어 전송 속도가 느려집니다.

페이지에 이미지, CSS 파일 및 스크립트와 같은 50 개의 리소스가있는 경우 쿠키는 (일반적으로) 각 요청과 함께 전송됩니다. 자세한 내용은 모든 웹 요청이 브라우저 쿠키를 전송합니까?

로컬 스토리지에는 데이터 전송 관련 단점이 없으며 데이터를 전송하지 않습니다. 훌륭합니다.

— 파누 로직
소스