2022년 7월 ~ 2022년 8월 동안 http 완벽 가이드 스터디를 진행하면서 노션에 정리해놨던 내용입니다.

11.1 개별 접촉

HTTP는 무상태이기 때문에 매 요청은 일회성이고 독립적으로 처리된다.하지만 아래처럼 클라이언트의 정보가 필요한 경우가 있다.

개별 인사

개인화 페이지를 제공하거나, 웹 사이트 메인에 000님 안녕하세요 같은 개별 인사 메시지를 띄워야 할 때

사용자 맞춤 추천

온라인 쇼핑몰에서 고객의 흥미를 학습에서 사용자에게 추천 상품을 제공할 때

저장된 사용자 정보

로그인을 해야하는 서비스의 경우 사이트에 방문할 때 마다 매번 로그인하는 것이 번거로우므로 로그인한 사용자 정보를 기억할 때

세션 추적

HTTP트랜잭션은 상태가 없고 독립적으로 일어나기 때문에 HTTP 트랜젝션을 식별할 때 필요함.

11.2 HTTP 헤더

• From 헤더는 사용자의 이메일 정보를 포함하는데, 악의적 사이트가 사용자의 이메일을 모아 스펨메일을 발송하기도 해서 잘 쓰지 않는다. 하지만 웹로봇의 경우 데이터를 수집하다가 웹 사이트에 문제를 일으켰을 때 해당 웹사이트의 관리자가 항의메일을 보낼 수 있또록 From 헤더를 포함한다.
• User-Agent 헤더는 사용자가 쓰고있는 브라우저 이름, 버번정보, 운영제체 정보(선택) 을 서버에게 알려준다. 특정 브라우저 속성에 맞춰 콘텐츠를 최적화하는데 유용하다. 하지만 특정 사용자를 식별하는데 큰 도움이 되진 않는다.
• Referer 헤더는 현재 페이지로 유입하게 한 웹페이지의 URL을 가리킨다. 이 헤더로 사용자의 웹 사용 형태나 취향을 파악할 수 있다.

11.3 클라이언트 IP 주소

클라이언트 ip주소는 http헤더에는 없지만, tcp 커넥션의 ip주소를 알아낼 수 있다.
하지만 ip주소로 식별하기에는 다음과 같은 단점이 존재한다.

• 클라이언트ip 주소는 사용자가 아닌 사용하는 컴퓨터를 가리키기 때문에 여러 사람이 한 컴퓨터를 사용한다면 사용자 식별 불가능
• ip가 동적으로 할당될 수 있음.
• 방화벽을 통해 인터넷을 사용하는 경우 클라이언트의 실제 ip주소를 알아낼 수 없음,
• 프락시와 게이트웨이는 원 서버에 새로운 tcp연결을 하기 때문에 웹 서버는 클라이언트의 ip주소 대신 프락시 서버의 ip주소를 본다.

11.4 사용자 로그인

Authorization 헤더에 사용자 로그인 정보를 포함해서 보낸다. (다음 장에서 자세히 다룸)

11.5 뚱뚱한 URL

사용자의 URL마다 버전을 기술하여 사용자를 식별함.

사용자가 웹 사이트를 처음 방문하면 유일한 ID가 생성되고, 그 값이 서버가 인식할 수 있는 방식으로 URL에 추가됨. 서버는 뚱뚱한 URL로 리다이렉트 시킴. 하지만 다음과 같은 문제가 있다.

못생긴 URL

사용자들에게 혼란을 준다

공유하지 못하는 URL

URL주소를 타인에게 보내 사이트를 공유하는 경우 개인정보까지 같이 공유됨.

캐시 사용 불가

URL이 달라지기 때문에 기존 캐시에 접급할 수 없음,

서버 부하 가중

서버는 이 URL에 해당하는 HTML 페이지를 다시 그려야 한다.

이탈

사용자가 이 URL을 사용하는 세션을 이탈한다면 사용자 정보가 사라짐

세션 간 지속성의 부재

사용자가 특정 뚱뚱한 URL을 북마킹하지 않는다면, 로그아웃하면 모든 정보를 잃는다.

11.6 쿠키

대부분의 캐시나 브라우저는 쿠키에 있는 내용물을 캐싱하지 않는다.

11.6.1 쿠키의 타입

• 세션쿠키
  • 사용자가 사이트를 탐색할 때, 관련한 설정과 선호 사항을 저장하는 임시쿠키
  • 브라우저를 닫으면 삭제됨.
• 지속쿠키
  • 브라우저를 닫거나 컴퓨터를 재시작해도 남아있음.
  • 사용자가 주기적으로 방문하는 사이트에 대한 설정 정보다 로그인 이름을 유지할 때 사용

11.6.2 쿠키는 어떻게 동작하는가

• 사용자가 처음 웹 사이트에 방문했을 때 웹 서버가 사용자를 식별하기 위한 유일한 값을 쿠키에 할당함.
• 쿠키는 이름=값 형태의 리스트를 갖는다.
• 리스트는 Set-Cookie, Set-Cookie2 같은 응답 헤더에 기술되어 사용자에게 전달됨

11.6.3 쿠키 상자: 클라이언트 측 상태

쿠키의 기본적인 발상: 브라우저가 서버 관련 정보를 저장하고, 사용자가 해당 서버에 접근할 때 마다 그 정보를 함께 전송하게 하는 것. 브라우저는 쿠키 정보를 저장할 책임이 있음.

11.6.4 사이트마다 각기 다른 쿠키들

브라우저는 각 사이트에 2~3개 정도의 쿠키만 보낸다. 그 이유는 다음과 같다

• 쿠키를 모두 전달하면 성능이 크게 저하된다. 실제 콘텐츠 바이트보다 더 많은 쿠키 바이트를 전달하게 된다.
• 서버에 특화된 이름/값 쌍을 포함하고 있기 때문에, 대부분 사이트에서는 인식하지 않는 무의미한 값이다.
• 모든 사이트에 쿠키 전체를 전달하는 것은, 특정 사이트에서 제공한 정보를 신뢰하지 않는 사이트에서 가져갈 수 있어 잠재적 개인정보 문제를 일으킬 수 있다.

쿠키 Domain 속성

서버는 쿠키를 생성할 때 Set-Cookie 응답 헤더에 Domain 속성을 기술해서 어떤 사이트가 그 쿠키를 읽을 수 있는지 제어할 수 있음.

Set-cookie: user="milk717"; domain="google.com"

• google.com 도메인을 가지고있는 모든 사이트에 쿠키를 전달해라

쿠키 Path 속성

웹 사이트 일부분에만 쿠키를 적용할 수도 있다.

Set-cookie: pref="compact"; domain="google.com"; path=/autos/

11.6.6 Version 0(넷스케이프) 쿠키

최초의 쿠키 명세는 넷스케이프가 정의함.

Set-Cookie 속성

Set-Cookie 속성	설명과 용례	설명
이름=값	Set-Cookie: name="ideveloper"	-
Expires	Set-Cookie: expires=Wednesday, 09-Nov-99 23:12:40 GMT	타임존 GMT만 가능
Domain	Set-Cookie: domain="ideveloper.dev"	-
Path	Set-Cookie: path:"/blog"	-
Secure	Set-Cookie: secure	http ssl 보안 연결을 사용할시에만 보냄

11.6.7 Version 1 (RFC 2965) 쿠키

• 모든 브라우저가 완전히 지원하지 않음.
• 넷스케이프 쿠기와 차이점
  • 쿠키마다 목적을 설명하는 설명문이 있음
  • 파기 주기에 상관없이 브라우저가 닫히면 쿠키를 강제로 삭제할 수 있음
  • 절대 날짜 대신에 상대 값으로 쿠키의 생명주기를 결정하는 Max-Age 사용
  • URL의 포트번호로도 쿠키를 제어할 수 있음
  • 도메인, 포트, 경로 필터가 있으면 Cookie 헤더에 담겨 되돌려 보냄
  • 호환되는 버전 번호
  • 사용자 이름과 추가적인 키워드를 구별하기 위해 Cookie 헤더에 $접두어가 있다.

11.6.8 쿠키와 세션 추적

• 쿠키는 웹 트랜잭션을 만드는데도 사용됨.

쿠키를 이용한 웹 트랜잭션

1. amazon.com 루트 페이지 요청
2. 서버는 클라이언트를 리다이렉트 시킴
3. 클라이언트는 리다이렉트 url로 요청 보냄
4. 서버는 응답에 두개 세션 쿠키 기술하고 사용자를 다른 url로 리다이렉트 시키고, 클라이언트는 다시 이 쿠키들을 첨부해 요청을 보냄.
5. 클라이언트는 새로운 url 요청을 앞서 바든 두개의 쿠키와 함께 보냄
6. 서버는 home.html 페이지로 redirect 시키고 쿠키 두개를 더 첨부함
7. 클라이언트는 home.html 페이지를 가져오고 총 4개의 쿠키를 전달함.
8. 서버는 콘텐츠를 보냄.