2회차 네트워크 | 네트워크 동작 과정 등 학습 정리

웹브라우저에 google.com 치면 일어나는 과정에 대해 조사.
쿠키, 세션
웹 스토리지

---

⬛ IP 주소

• 수많은 컴퓨터들도 인터넷 상에서 서로를 구별할 수 있어야 하는데,
• 서로를 인식하기 위해 지정받은 식별용 12자리 주소 = IP 주소
• IP 주소는 12 자리 숫자로 되어 있기 때문에 사람이 외우기 힘들다는 단점이 있다.
• 우리는 12자리 IP 주소를 숫자 대신 ‘문자’로 표현한 주소(도메인 네임)로 표현한다.

⬛ 도메인 네임 (Domain Name)

• 네트워크상에서 컴퓨터를 식별하는 호스트명
• 즉, 도메인은 IP주소를 알기 쉬운 문자열로 나타낸 것
• 다시 말해 사람이 (URL)도메인 네임으로 입력하면 (DNS에서 해당 도메인 네임에 쌍을 이루는 IP 주소값을 찾아) 컴퓨터는 해당 IP 주소로 찾아갈 수 있는 것이다.

⬛ DNS (Domain Name System)

• DNS는 URL을 IP 주소로 변환하는 서비스 (시스템)
• DNS 서버는 전 세계에 흩어져서 계층적으로 연결되어 있고, 연계하면서 동작한다.

ex. DNS 서버 1 이 모르면 DNS 서버 1이 또 다른 DNS 서버 2에 요청한다. (매핑되는 IP 주소 발견할 때까지 쭉 요청)

⬛ DNS가 UDP를 사용하는 이유

TCP는 연결 지향 프로토콜이기 때문에 기본적으로 연결을 위해 소요하는 비용이 크다.

• DNS는 도메인명을 IP 주소로 변환 시 많이 사용되므로, 많은 클라이언트를 수용해야 한다.
• UDP의 경우 별도 연결을 위한 시간 지연이 없고, 연결 상태를 유지할 필요도 없는 프로토콜이므로 연결 상태 유지 X, 정보 기록을 최소화하는 UDP가 DNS에 더 알맞다.

1) 빠른 속도 : UDP는 별도 연결 설정이 없다

• TCP의 경우는 연결 위해 3 way handshake 과정이 있는 반면, UDP는 없어서 연결에 드는 비용이 줄어든다.
• 즉, 빠르다. DNS의 경우 신뢰성보다 속도가 더 중요한 서비스이므로 TCP보다 UDP 가 적합하다.

2) 연결 상태를 유지할 필요가 없다.

• TCP는 호스트 간 연결 상태를 유지한다. TCP의 패킷 안에는 연결 유지를 위한 여러 정보가 담겨져 있다.
• 반면, UDP는 연결 지향 X 어떤 정보도 기록하지 않고 유지할 필요도 없다.

---

네트워크 동작 과정

⬛ 웹 브라우저에 https://www.google.com 접속 시 일어나는 일 설명

설명

🟦 브라우저에 URL 입력 시 전체적인 흐름 설명

1) 브라우저 겁색창에 ‘www.google.com’ 입력

• 특정 웹사이트 접속을 위해서 실질적으로는 IP 주소(127.0.0.1)가 필요한데 외우기 힘들다.
• IP주소 대신 도메인 명으로 웹페이지 접속을 하고 싶다.
• 다만 컴퓨터 끼리는 IP주소로 식별하니, [도메인명:IP주소] 쌍을 가진 DNS 서버를 이용하는 거다.

2) 브라우저는 가장 먼저 캐싱된 DNS 기록을 체크한다.

• 브라우저는 사실상 4가지 캐시를 확인한다.

브라우저 캐시 → OS 캐시 (systemcall) → 라우터 캐시 → ISP 캐시

• ISP는 인터넷 서비스 공급자 약자 (ex. KT, SK 등)

3) 요청된 URL이 캐시에 없으면, ISP의 DNS 서버에서 DNS 쿼리를 통해 검색하여 해당 도메인의 IP 주소를 찾는다.

4) 브라우저가 찾은 IP주소의 서버와 TCP 연결 후, 해당 서버에 HTTP 요청을 보낸다.

• IP 주소를 알게 됐으니 해당 서버에 요청을 보내야 한다.
• HTTP 요청을 보내야 하는데, 요청 보내기 전에 먼저 해당 서버와 TCP 연결을 한다.
• 그래서 HTTP 연결 요청 전, TCP 연결을 한다.
• 연결을 위해 3-way handshake 프로세스로 클-서버 간 연결이 이루어진다.
• 그리고 HTTP 요청을 보낸다. (GET 요청)

웹 페이지 URL 정보와 전달받은 IP 주소는 HTTP 프로토콜을 사용하여 HTTP 요청 메시지를 생성함.

이렇게 생성된 HTTP 요청 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 해당 IP 주소의 컴퓨터로 전송됨

5) 서버가 요청을 처리하고, 응답을 생성한다.

검색된 웹 페이지 데이터는 또다시 HTTP 프로토콜을 사용하여 HTTP 응답 메시지를 생성함.

이렇게 생성된 HTTP 응답 메시지는 TCP 프로토콜을 사용하여 인터넷을 거쳐 원래 컴퓨터로 전송됨.

• 서버는 브라우저로부터 온 요청을 읽고 응답을 생성한다.
• 응답에는 특정 포맷 (JSON, XML, HSML) 등

6) 서버가 HTTP 응답을 보낸다.

• 서버의 응답에는 요청한 웹페이지, 상태코드, 쿠키, 개인정보 등이 포함되어 있다.

7) 브라우저는 응답받은 데이터로 HTML 콘텐츠를 보여준다,

• 브라우저는 html 콘텐츠를 단계적으로 렌더링하여 노출한다.
• 해당 컨텐츠들은 브라우저에 의해 캐싱되어 나중에 재방문시 서버에 재요청하지 않고 캐시에서 꺼내 쓰도록 한다.

---

쿠키, 세션, 토큰

HTTP 통신은 요청(Request) -> 응답(Response) 이 종료되면 stateless(상태가 유지되지 않은) 특징 때문에 연결을 끊는 처리 방식입니다.

로그인과 같은 일을 할 때, '누가' 로그인 중인지 상태를 기억하기 위해 쿠키, 세션, 토큰을 사용합니다.

⬛ 쿠키

1) 개념

• 웹 사이트에 접속할 때 생성되는 정보를 담은 임시 파일 //작은 데이터 파일
• 클라이언트 측에 저장되는 키-값 작은 데이터 파일
• 쿠키는 공개 가능한 정보를 사용자의 브라우저에 저장시킨다

[쿠키 사용 목적]

1. 세션 관리(Session Management)
   • 로그인, 사용자 닉네임, 접속 시간, 장바구니 등의 서버가 알아야할 정보들을 저장
2. 개인화(Personalization)
   • 사용자마다 다르게 그 사람에 적절한 페이지를 보여줄 수 있다.
3. 트래킹(Tracking)
   • 사용자의 행동과 패턴을 분석하고 기록

   a) 세션 쿠키 ( Session Cookie ) : 웹 브라우저가 종료될 때 제거되는 쿠키

   b) 지속 쿠키 ( Persistent Cookie ) : 유효 시간을 정하지 않은 경우 브라우저가 종료되어도 남아 있는 쿠키

→ 둘은 데이터 파기 시점이 다르다.

2) 특징 : 브라우저 종료되어도 (쿠키에 지정된 만료 시점까지) 저장된다.

• 속도 : 쿠키 > 세션
• 보안 : 세션 > 쿠키

3) 저장 위치 : 클라이언트 측 저장

4) 쿠키 동작 방식 (라이프 사이클)

쿠키 라이프사이클

• 클라이언트가 페이지를 요청한다. (사용자가 웹사이트 접근)
• 웹 서버는 쿠키를 생성한다.
• 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때 같이 클라이언트에게 돌려준다.
• 넘겨 받은 쿠키는 클라이언트가 가지고 있다가(로컬 PC에 저장),
• 다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
• 클라이언트의 PC에 해당 쿠키가 있는 경우,요청 페이지와 함께 쿠키를 전송한다.

5) 단점 : 보안 취약

→ 그렇다면 공개하면 안되는 정보 (ex. 로그인 정보)는 ? 세션 or 토큰 사용

---

⬛ 세션

1) 개념

• 서버 측에서 클라이언트 구분하고, 클라이언트 상태 유지하기 위해 사용하는 기법
• 일정 시간동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태 (세션)으로 보고, 그 상태를 유지시키는 기술
• 즉, 방문자가 웹 서버에 접속해 있는 상태 = 세션
• 클라이언트 쿠키 안에는 구분을 위한 (세션 id)만 들고 있고, 세션 저장소에서 해당 세션 id에 매핑되는 실질적 사용자 정보를 저장함 (더 보안적)

2) 특징 : 만료 시점은 저장하기 나름이다 // ? //

• 속도 : 쿠키 > 세션
• 보안 : 세션 > 쿠키
• 세션도 쿠키를 사용함

3) 저장 위치 : 서버 측 저장

4) 세션 동작 방식 (라이프 사이클)

세션 라이프사이클

• 클라이언트가 서버에 접속 시 세션 ID를 발급 받는다.
• 클라이언트는 세션 ID에 대해 쿠키 안에 저장하고 가지고 있는다.
• 클라리언트는 서버에 요청할 때, 이 쿠키의 세션 ID를 같이 서버에 전달해서 요청한다.
• 서버는 요청 헤더 속 쿠키 안의 세션 ID를 전달 받아서 세션 ID로 세션에 있는 클라언트 정보를 가져와서 사용한다.
• 클라이언트 정보를 가지고 서버 요청을 처리하여 클라이언트에게 응답한다.

5) 단점 : 서버 공간은 한계가 있기 때문에, 동시 접속자 많아지면 서버 부담

---

⬛ 토큰

1) 개념

• 클라이언트 (식별 및 인증)을 위해 사용되는 암호화된 문자열
• JWT (JSON Web Token) 는 인증에 필요한 정보들을 암호화시킨 토큰을 의미

2) 특징

• 세션의 대안으로 등장 (서버 부담 줄이기 위해 클라이언트(쿠키) 측에 상태 저장)

[세션 인증 vs 토큰 인증]

• 세션 인증 : 서버가 세션 id를 세션 저장소에 저장 후 클라이언트가 실어보낸 쿠키 속 세션 id와 대조해서 확인함
• 토큰 인증 : 해당 토큰이 자기가 발급한 토큰인지 (유효한지만) 검증 (효율 더 좋음)
• JWT 는 발급한 후 검증만 하기 때문에 추가 저장소가 필요하지 않습니다.
• (StateLess - 상태/정보 저장하지 않음) 이는 서버를 확장하거나 유지, 보수하는데 유리합니다.

3) 저장 위치 : 클라이언트 측에 저장한 것 // 클라이언트가 직접 토큰 들고 있는 방식

→ 일반적으로 쿠키 또는 로컬 스토리지에 저장

• 세션의 경우 세션 id에 매핑되는 실질적 유저 정보가 담긴 세션 저장소에서 유효한 사용자인지 확인하는 작업을 한다면,
• 토큰은 유효한 사용자에게만 발급한 토큰 정보를 클 측에 담아두기 때문에 요청이 들어올 때 쿠키 까서 해당 토큰이 유효하기만 하다면 검증된 거임 (별도 저장소X)

4) 토큰 동작 방식 (라이프사이클)

토큰 라이프사이클

• 사용자 인증 후 서버는 토큰 발급
• 클라이언트는 토큰을 저장해두고, 요청 시 헤더에 포함해서 서버에 전달
• 서버는 토큰 유효성 검증 후 요청 처리 및 응답

5) 단점 : 토큰 크기와 정보 증가로 네트워크 부하 증가, 서버에서의 제어 어려움

• 쿠키나 세션과 다르게 JWT는 토큰의 길이가 길어 인증 요청이 많아질수록 네트워크 부하가 심해진다.

[추가] JWT 토큰 (Json Web Token)

• 모바일이나 사용자 인증을 위해 사용하는 암호화된 문자열
• [장점] 세션과는 달리 서버 메모리 사용 안하고 서버 확장성에 용이하다
• [단점] JWT 토큰 길어질 수록 대역폭 낭비 심해진다는 단점 있다.

---

웹 스토리지, 캐시

⬛ 웹 스토리지

1) 개념

• 쿠키 대체할 목적으로 HTML5 부터 추가된 클라이언트에 key-value 데이터 저장 가능한 저장소
• 쿠키는 매번 클 측 저장 후 서버로 보내는 반면,
• 웹 스토리지는 클 측에 저장만 할 뿐임B. 세션 스토리지 | 일시 저장, 브라우저 종료 시 삭제
• A. 로컬 스토리지 | 영구저장

2) 저장 위치 : 클라이언트 측 저장

⬛ 캐시

• 캐시는 웹 페이지 요소를 저장하기 위한 임시 저장소
• 용량 큰 리소스 임시 저장해두어 렌더링 속도 높이는 목적
• 반복 사용 데이터 임시 저장소
• 반복 사용 데이터를 임시저장해두고 재접속 시 서버 부담 줄이고 로딩 시간 단축시킴

---

🎈한 눈에 정리하기

• 쿠키 (클라이언트 측 작은key-value 데이터 파일)
• 세션, 토큰 (클라이언트 인증/구분 및 상태 유지 목적)

→ 세션 : 클 측 쿠키 안에 (세션 id)만 담고, 요청 메시지 헤더에 쿠키 담아서 서버에 보내면 서버가 쿠키 까서 안의 세션 id 값에 매핑되는 User 정보 있는지 → 세션 저장소에서 확인 후 맞으면 요청 처리 후 응답

→ 토큰 : 클라이언트의 유효한 인증 후 서버가 발급해준 암호화된 문자열을 클 측의 쿠키 안에 담아둠. 이후 요청 시 헤더 안 쿠키 속 토큰 담아 보내기 때문에 서버는 받아서 자기가 발급한 건지만 검증 후 요청 처리하여 응답

• 웹 스토리지 (클라이언트 측에 key-value 데이터 저장 목적의 임시 저장소)
• **캐시 (**클라이언트 로컬 PC상에 반복 사용 데이터 임시 저장소)

---

XSS와 CSRF 추가 정리 필요 ! - 해킹 

XSS와 CSRF

 

[추가] 세션의 저장

일반적으로 서버의 메모리에 저장된다.

하지만 로드밸런싱 등의 이유로 서버를 수평 확장하는 경우가 있어 이렇게 되면 최초 세션이 생성된 서버와 이후의 요청을 받은 서버가 다를 수 있어 세션이 불일치하는 문제점이 발생할 수 있다.

이 문제를 해결하기 위해

1. 유저의 요청이 무조건 세션을 생성한 서버로 향하도록 하는 sticky session,
2. 여러 웹서버가 모두 동일한 세션 정보를 가지고 있는 session clustering,
3. 가장 많이 쓰이는, 세션 정보를 관리하는 서버를 별개로 두는 session storage 방식이 있다. (多)