diff --git a/Browser/Browser_Storage.md b/Browser/Browser_Storage.md index 8643ccb..0564218 100644 --- a/Browser/Browser_Storage.md +++ b/Browser/Browser_Storage.md @@ -8,7 +8,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 쿠키는 웹 브라우저가 사용자의 컴퓨터에 저장하는 작은 텍스트 파일입니다. 이 파일들은 웹사이트가 사용자의 컴퓨터를 기억하도록 돕습니다. 쿠키의 주요 특징으로는 세션 관리, 개인화, 트래킹, 클라이언트 측 저장, 만료 시간 설정 가능, 보안, 크기 제한 등이 있습니다. ## 🔗 꼬리질문: 쿠키를 왜 사용하나요? @@ -16,7 +16,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 쿠키는 세션 관리, 개인화, 트래킹 및 분석, 보안, 광고 타겟팅 등 다양한 목적으로 사용됩니다. ## 🔗 꼬리질문: 쿠키는 어떻게 동작하나요? @@ -24,7 +24,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 쿠키는 HTTP 프로토콜을 사용하는 웹에서 작동하며, 클라이언트와 서버 간에 정보를 주고 받는 방식으로 동작합니다. 첫 번째로 사용자가 웹사이트를 처음 방문하면, 서버는 HTTP 응답 헤더에 'Set-Cookie' 헤더를 포함하여 응답을 보냅니다. 이 헤더에는 쿠키의 이름, 값, 만료 시간, 경로 등의 정보가 포함되어 있습니다. 브라우저는 이 정보를 받아 쿠키를 생성하고 로컬(사용자의 컴퓨터)에 저장합니다. 두 번째로 해당 웹사이트를 다시 방문할 때마다 브라우저는 자동으로 이전에 저장된 쿠키 정보를 HTTP 요청 헤더의 'Cookie' 필드에 담아 서버로 전송합니다. 세 번째로 서버는 'Cookie' 헤더에서 받은 정보를 읽어 사용자 세션을 관리하거나 개인화된 환경을 제공하는 등 다양한 목적으로 활용합니다. 네 번째로 만약 서버에서 새로운 'Set-Cookie' 응답을 보내면 기존 쿠기가 업데이트 되거나 삭제됩니다. 만료 시간이 지난 쿠키도 자동으로 삭제됩니다. ## 🔗 꼬리질문: 지속 쿠키와 세션 쿠키의 차이점은? @@ -32,7 +32,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 지속 쿠키와 세션 쿠키의 주요 차이점은 각 쿠키가 얼마 동안 브라우저에 저장되는지에 있습니다. 세션 쿠키는 사용자가 웹 사이트를 방문하는 동안만 브라우저에 저장됩니다. 사용자가 브라우저를 닫으면 세션 쿠키도 함께 삭제됩니다. 로그인 상태, 장바구니 항목 등 일시적인 정보를 저장하는 데 주로 사용됩니다. 지속 쿠키는 설정된 만료 날짜까지 브라우저에 저장되며, 그 시간 동안은 브라우저를 닫거나 컴퓨터를 재부팅해도 게속 유지됩니다. 이 만료 날짜는 몇 분에서 몇 년까지 다양하며, 개인화 설정 (사이트 테마, 언어 등), 로그인 정보 등을 저장하는데 사용됩니다. ## 🔗 꼬리질문: 쿠키의 보안 취약점은 무엇이 있나요? 그리고 이를 어떻게 해결할 수 있을까요? @@ -40,7 +40,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 쿠키는 웹의 중요한 부분이지만, 잘못 사용하면 보안 위협이 될 수 있습니다. 쿠키의 주요 보안 취약점과 이를 해결하는 방법을 간단하게 말씀드리갰습니다. 첫 번째로 세션 하이재킹입니다. 공격자가 사용자의 세션 쿠키를 가로채서 그 사용자처럼 행동할 수 있게 됩니다. 이 문제는 'Secure' 플래그가 설정된 쿠키를 사용하여 HTTPS 연결을 통해서만 쿠키를 전송함으로써 해결할 수 있습니다. 두 번째는 크로스 사이트 스크립팅(XSS)입니다. 공격자가 악성 스크립트를 웹 페이지에 주입하여 사용자의 쿠키 정보를 탈취할 수 있습니다. 이 문제는 'HttpOnly' 플래그가 설정된 쿠키를 사용함으로써, JavaScript 등의 클라이언트 사이드 스크립트에서 쿠키에 접근하는 것을 방지함으로써 해결할 수 있습니다. 세 번째는 크로스 사이트 요청 위조(CSRF)입니다. 공격자가 사용자를 속여서 그들의 의도와는 다른 요청을 서버에 전송하게 만들어, 예상치 못한 변경을 일으킬 수 있습니다. CSRF 토큰과 같은 추가적인 보호 조치를 도입함으로써 이 문제를 해결될 수 있습니다. 네 번째는 제 3자 추적입니다. 제 3자 쿠키(사용자가 직접 방문하지 않은 사이트에서 생성된 쿠키)는 종종 광고 추적 및 개인정보 침해와 관련되어있습니다. 브라우저 설정에서 제 3자 쿠키 차단 옵션을 활성화하는 것으로 이 문제를 완화시킬 수 있습니다. 다섯 번째는 데이터 노출입니다. 중요한 정보가 평문 형태로 저장되거나 전송되면 데이터 유출 위험이 발생합니다. 중요 정보는 항상 암호화되어야 하며, 가능한 경우 서버사이드 세션 저장소에 보관해야 합니다. ## 🔗 꼬리질문: 쿠키와 써드파티 쿠키(Third-Party Cookies)의 차이점은 무엇인가요? @@ -48,7 +48,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 쿠키는 일반적으로 First-Party Cookies와 Third-Party Cookies으로 분류됩니다. First-Party Cookies는 사용자가 현재 방문 중인 웹사이트에 의해 생성되며, 주로 로그인 상태 유지, 테마 저장 등 해당 웹사이트의 기능성을 개선하기 위해 사용됩니다. 써드파티 쿠키(제 3자 쿠키)는 사용자가 직접 방문하지 않은 다른 사이트에 의해 생성된 쿠키입니다. 이러한 종류의 쿠키는 주로 온라인 광고 및 행동 기반 추적을 위해 사용됩니다. 예를 들어, 한 웹사이트에서 광고를 클릭하면 그 광고 네트워크는 제 3자 쿠키를 설정하여 사용자의 행동을 추적하고 타겟팅된 광고를 제공하는데 활용합니다. 제 3자 쿠키는 개인정보 침해와 관련된 문제 때문에 논란이 많기 때문에 많은 브라우저에서 제 3자 쿠키의 작동을 제한하거나 차단하는 옵션을 제공합니다. ## 🎯 공통 질문: 세션의 정의 및 특징에 대해 설명해주세요. @@ -56,7 +56,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 세션은 특정 사용자가 웹 서버에 접속한 이후부터 접속을 종료할 때까지의 일련의 과정 또는 상호작용을 의미합니다. 이는 웹 기반 응용 프로그램에서 클라이언트와 서버 사이의 상태를 유지하기 위해 사용됩니다. HTTP 프로토콜 자체는 상태를 유지하지 않는(Stateless) 특성을 가지고 있기 때문에, 세션은 이러한 한계를 극복하고 사용자별 정보를 관리하는 방법으로 활용됩니다. 세션은 상태 정보 유지, 보안성, 서버 측 저장, 유효 기간 설정 가능, 사용자 구분 가능 등 다양한 특징을 가지고 있습니다. ## 🔗 꼬리질문: 세션의 동작 방식은? @@ -64,7 +64,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 세션의 동작 방식을 순서대로 설명드리겠습니다. 첫 번째로 사용자가 웹 사이트에 로그인하거나 특정 작업을 수행하여 세션이 필요한 상황이 발생하면, 서버는 고유한 세션 ID를 생성합니다. 이 ID는 클라이언트와 서버 간에 교환되며, 이를 통해 서버는 클라이언트를 식별할 수 있습니다. 두 번째로 생성된 세션 정보는 서버에 저장되고, 해당 세션 ID는 HTTP 응답 헤더 또는 쿠키 등을 통해 클라이언트에게 전송됩니다. 세 번째로 클라이언트가 추가적인 요청을 할 때마다 민감하지 않은 경우 쿠키 형태로 저장된 세션 ID가 자동으로 서버로 전송됩니다. 네 번째로 서버는 받은 세션 ID를 기반으로 해당 사용자의 정보나 상태 등을 찾아내어 처리합니다. 위 과정은 사용자가 로그아웃하거나 타임아웃으로 인해 세션이 종료될 때까지 계속 반복됩니다. 만약 사용자가 로그아웃하거나 타임아웃 등으로 인해 세션이 종료되면, 해당하는 세션 데이터도 삭제되고 메모리도 해제됩니다. ## 🔗 꼬리질문: 세션의 생명주기는 어떻게 관리되나요? @@ -72,7 +72,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 세션의 생명 주기는 세션 생성, 세션 유지, 세션 만료/종료 와 같은 과정을 거칩니다. 사용자가 웹 사이트에 접속하고 로그인 등의 특정 작업을 수행하면, 서버는 고유한 세션 ID를 생성하고 클라이언트에게 전달합니다. 이때 세션 데이터는 서버에 저장되며, 이 데이터는 사용자의 상태 정보를 담고 있습니다. 그리고 사용자가 웹 사이트를 계속 사용하는 동안, 해당 세션은 유지되며 모든 요청과 함께 세션 ID가 서버로 전송되며, 서버는 이 ID를 통해 해당 세션 데이터에 접근합니다. 만일 설정된 시간 동안 활동이 없거나, 사용자가 직접 로그아웃 등으로 세션이 필요 없어진 경우, 해당 세션이 종료됩니다. 세션이 종료되면 데이터도 삭제되고 메모리도 해제됩니다. ## 🔗 꼬리질문: 세션은 왜 사용하나요? @@ -80,7 +80,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 세션은 웹 애플리케이션에서 상태 정보를 유지하기 위해 사용됩니다. HTTP 프로토콜 자체는 상태를 유지하지 않는(stateless) 특성을 가지고 있습니다. 즉, 서버가 클라이언트의 이전 요청에 대한 정보를 기억하지 못한다는 것입니다. 예를 들어, 사용자가 웹 사이트에 로그인하면 서버는 그 사용자의 로그인 상태를 기억해야 합니다. 그렇지 않으면 사용자가 페이지를 이동할 때마다 다시 로그인해야 할 것입니다. 또한, 온라인 쇼핑몰에서 장바구니 기능을 구현하려면 각각의 고객이 선택한 제품들을 기억하고 있어야 합니다. 따라서 세션은 이러한 상황에서 서버가 클라이언트와의 연결 동안 일련의 요청과 응답 사이에 상태 정보를 유지할 수 있게 해주는 매우 중요한 역할을 합니다. 세션은 사용자 인증, 개인화, 장바구니 등 다양한 목적으로 쓰입니다. ## 🔗 꼬리질문: 세션 하이재킹이란 무엇인가요? 그리고 그것을 방지하기 위한 방법은? @@ -88,7 +88,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 세션 하이재킹은 공격자가 사용자의 세션을 가로채거나 중간에서 조작하여 해당 사용자처럼 행동하는 보안 공격입니다.이를 통해 공격자는 인증된 사용자의 권한으로 서버에 접근할 수 있게 됩니다. 세션 하이재킹을 방지하는 방법으로는 암호화, 세션 ID 재생성, 세션 타임아웃 설정, IP 바인딩, 사용자 에이전트 체크 등이 있습니다. 첫 번쨰로 암호화는 데이터 전송 시 SSL/TLS와같은 프로토콜을 사용하여 암호화하면, 중간에 데이터를 가로채더라도 실제 내용을 파악하기 어렵습니다. 두 번쨰로 세션 ID 재생성은 로그인 후에 새로운 세션 ID를 생성함으로써 기존의 세션 ID가 노출되더라도 실제 서비스에 영향을 주지 않도록 할 수 있습니다. 세 번째로 세션 타임아웃 설정은 일정 시간 동안 활동이 없으면 자동으로 세션이 종료되도록 설정하는 것을 말하며, 네 번째 IP 바인딩은 클라이언트의 IP 주소를 해당 세션과 연결시켜서, 해당 IP 주소에서만 그 세션 ID가 유효하게 하는 방법입니다. 해당 방법은 IP가 변경될 수 있는 모바일 네트워크 환경인 경우 문제가 될 수 있습니다. 마지막으로 사용자 에이전트 체크는 웹 브라우저마다 특정한 "사용자 에이턴트" 문자열 정보를 가지고 있는데, 이 정보를 체크해서 변조된 요청을 차단할 수 있습니다. ## 🔗 꼬리질문: 세션 저장 위치에 따른 장단점은 무엇인가요? @@ -96,7 +96,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 세션 정보를 저장하는 위치에 따라 여러 가지 장단점이 있습니다. 주로 사용되는 세션 저장 위치는 메모리, 데이터베이스, 쿠키, 외부 스토리지(Redis) 등이 있습니다. 메모리의 장점은 빠른 속도로 접근할 수 있으며, 구현도 비교적 간단합니다. 단점은 서버가 재시작되거나 다운될 경우 모든 세션 정보가 사라집니다. 또한, 많은 양의 세션 정보를 저장하면 메모리 부담이 커질 수 있습니다. 데이터베이스의 장점은 서버가 다운되거나 재시작될 때에도 데이터가 유지됩니다. 단점은 데이터베이스 I/O 작업은 상대적으로 느릴 수 있으며, 과도한 요청은 데이터베이스 부하를 증가시킬 수 있습니다. 쿠키의 장점은 클라이언트의 쿠키에 세션을 저장하면 서버의 메모리 부담을 줄일 수 있습니다. 단점은 쿠키는 용량 제한과 보안 문제가 있다는 점에서 주의해야 합니다. 마지막으로 외부 스토리지의 장점은 분산 시스템 환경에서 각각의 서버들 사이에서 동일한 세션을 공유할 수 있습니다. 단점은 추가적인 외부 시스템 관리와 네트워크 지연 문제 등을 공격자들로부터 보호해야 할 필요성 등 추가적인 복잡성과 관련된 이슈들을 가지고 있습니다. ## 🎯 공통 질문: 브라우저 저장소에 대해 설명해주세요. @@ -104,7 +104,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 웹 브라우저는 사용자의 컴퓨터에 데이터를 저장할 수 있는 여러 가지 방법을 제공합니다. 이러한 방법들은 일반적으로 브라우저 저장소라고 부릅니다. 주요 브라우저 저장소에는 쿠키, 로컬 스토리지, 세션 스토리지, IndexedDB, Web SQL, Cache API 등이 있습니다. ## 🔗 꼬리질문: 각 브라우저 저장소의 사용 예시를 들어주세요. @@ -112,7 +112,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 쿠키는 로그인 정보, 선호 언어 등 사용자의 선호 설정을 기억하는 데 주로 사용되고, 로컬 스토리지는 웹 애플리케이션에서 클라이언트 측에 데이터를 영구적으로 저장하는 데 사용됩니다. 예를 들어, 게임 진행 상태 등이 있습니다. 세션 스토리지는 페이지 세션이 유지되는 동안 데이터를 임시적으로 저장하는데 사용되며, 장바구니 항목 추적 등이 있습니다. indexedDB는 더 복잡한 데이터 구조와 큰 데이터 볼륨을 처리하기 위한 비동기 클라이언트-사이드 스토리지 시스템이며, 오프라인에서도 작동할 수 있는 PWA에서 주로 활용되며 대량의 구조화된 데이터 등을 처리합니다. Cache Storage의 Cache API는 서비스 워커(Service Worker)가 네트워크 요청 및 응답을 캐싱하는데 주로 사용됩니다. ## 🔗 꼬리질문: 브라우저 저장소에 데이터를 암호화하는 방법은 무엇인가요? @@ -120,7 +120,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 브라우저 저장소에 데이터를 저장할 때, 특히 민감한 정보를 다루는 경우 해당 데이터를 암호화하는 것이 중요합니다. 이는 JavaScript에서 제공하는 다양한 암호화 라이브러리와 API를 활용하여 수행할 수 있습니다. 최신 웹 브라우저들은 Web Cryptography API라는 내장 기능을 제공합니다. 이 API는 여러 가지 형태의 인증 및 암/복호화 작업을 지원합니다. ## 🔗 꼬리질문: indexedDB가 무엇인지 설명해주세요. @@ -128,7 +128,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: IndexedDB는 브라우저에서 복잡한 애플리케이션을 실행하기 위해 설계된 저수준 API입니다. IndexedDB는 키/값 데이터를 비동기식으로 처리하고 대용량 데이터를 인덱싱하여 고성능 검색 기능을 제공합니다. ## 🔗 꼬리질문: 로컬 스토리지와 세션 스토리지의 차이점을 설명해주세요. @@ -136,7 +136,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 로컬 스토리지는 웹에서 클라이언트 측에서 데이터를 영구적으로 저장하는 메커니즘입니다. 쿠키와 달리, 로컬 스토리지는 큰 용량을 데이터를 저장할 수 있으며, 서버로 전송되지 않습니다. 세션 스토리지도 로컬 스토리지와 비슷하지만, 페이지 세션이 종료될 때, 즉 탭을 닫을 때 삭제되는 휘발성 메모리입니다. ## 🔗 꼬리질문: 로컬 스토리지를 사용할 때의 보안 취약점은 무엇인가요? @@ -144,7 +144,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 로컬 스토리지를 사용할 때 주의해야 할 몇 가지 보안 취약점이 있습니다. 첫 번째로 크로스 사이트 스크립팅 (XXS) 공격입니다. 로컬 스토리지는 JavaScript에서 직접 접근할 수 있기 때문에, XXS 공격으로 인해 악성 스크립트가 실행되면 로컬 스토리지에 저장된 데이터가 유출될 위험이 있습니다. 이러한 공격은 사용자의 세션 토큰, 개인 정보 등을 탈취하는 데 사용될 수 있습니다. 두 번째로 데이터 노출입니다. 로컬 스토리지는 클라이언트 측에서 암호화되지 않은 텍스트 형태로 데이터를 저장합니다. 이는 민감한 정보가 로컬 스토리지에 저장되어 있다면, 그 정보는 컴퓨터나 디바이스에 물리적 접근이 가능한 사람들에게 노출될 수 있음을 의미합니다. 보안 문제를 최소화하기 위해서는 중요하거나 민감한 정보는 서버 측에서 처리하는 것이 좋습니다. ## 🔗 꼬리질문: 웹 스토리지(Web Storage)와 쿠키의 사용 케이스는 어떻게 다른가요? @@ -152,7 +152,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 웹 스토리지와 쿠키는 모두 클라이언트 측에서 데이터를 저장하는 방법이지만, 특성과 제약사항을 고려하여 사용해야 합니다. 쿠키는 원래 서버와 클라이언트 간의 상태 정보를 유지하기 위해 설계되었습니다. 예를 들어, 로그인 세션 ID나 사용자 선호 설정 등을 저장하는 데 사용됩니다. HTTP 요청마다 자동으로 서버로 전성되므로, 서버가 필요한 정보를 유지할 수 있게 해줍니다. 각 쿠키는 크기가 작고(4KB 제한), 전체적으로도 제한된 수의 쿠키만 저장할 수 있습니다. 웹 스토리지는 클라이언트에서 더 큰 데이터(5MB ~ 10MB)를 저장하고 관리하기 위해 설계되었습니다. 이것은 앱의 상태, 사용자의 이전 활동, 오프라인 용 데이터 등을 저장하는데 유용합니다. 웹 스토리지는 HTTP 요청에 포함되어 서버로 전송되지 않기 때문에 대용량 데이터를 클라이언트에서 안전하게 보관할 수 있게 해주며 네트워크 효율성을 개선시킵니다. 요약하자면 작은 양의 중요한 정보나 서버와 주고받아야 하는 정보에 대해서는 쿠키가 좋은 선택할 수 있으며, 대용량 데이터나 클라이언트 내부에서만 필요한 정보에 대해서는 웹스토리지가 더 나은 선택입니다. ## 🎯 공통 질문: 토큰이란 무엇인가요? @@ -160,7 +160,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 웹에서 사용하는 토큰이란 보안, 인증, 권한 부여 등의 목적으로 사용되는 작은 정보 단위를 말합니다. 웹에서 주로 사용하는 토큰의 종류로는 세션 토큰, JWT, OAuth2 Access Token, CSRF Token, Refresh Token, API Key 등이 있습니다. ## 🔗 꼬리질문: 토큰의 인증 과정에 대해서 설명해주세요. @@ -168,7 +168,9 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 토큰 기반 인증 과정 중 가장 많이 쓰이는 OAuth 2.0 기준으로 설명 드리자면, 사용자가 클라이언트에서 자신의 아이디와 비밀번호를 입력하여 로그인 요청을 합니다. 클라이언트는 사용자의 아이디와 비밀번호를 서버에 전달합니다. 서버는 이 정보를 확인하고 맞다면 Access Token과 Refresh Token을 생성합니다. 생성된 토큰들은 클라이언트에게 반환됩니다. 클라이언트는 이 토큰들을 저장해두었다가 추후 서버에 요청할 때마다 함께 보냅니다. 클라이언트가 서버에 데이터를 요청할 때마다 Access Token을 포함해서 보냅니다. 서버는 받은 Access Token을 검증하고, 유효한 토큰일 경우 해당 사용자에 대한 정보나 권한 등을 확인하여 요청된 데이터를 반환합니다. Access Token은 일정 시간 후에 만료되므로, 만료되기 전에 Refresh Token을 사용해 새로운 Access Token을 발급 받아야합니다. + +인증 요청 => 토큰 발급 => 토큰 반환 => 토큰 활용 => 토큰 갱신 ## 🔗 꼬리질문: Access Token, Refresh Token에 대해서 설명해주세요. @@ -176,7 +178,10 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: Access Token과 Refresh Token은 웹, 모바일 앱, API 등에서 사용자 인증을 위해 주로 사용되는 토큰입니다. 이들은 OAuth2.0, OpenID Connect 등의 프로토콜에서 널리 사용됩니다. Access Token은 클라이언트가 서버에 접근할 수 있는 권한을 부여하는 토큰입니다. 보통 로그인 후에 발급되며, 이후 클라이언트가 서버에 요청을 보낼 때마다 이 access token을 포함하여 전송합니다. 서버는 access token을 확인하여 해당 요청이 유효한지 판단하고 필요한 데이터를 반환하며, access token은 일정 시간 후에 만료되도록 설정되어 있으므로 주기적으로 갱신해야 합니다. Refresh Token은 access token이 만료된 후 새로운 access token을 발급받기 위해 사용하는 특수한 종류의 토큰입니다. Access Token과 달리 Refresh Token은 보통 긴 수명을 가지며, 만료 시간이 더 길거나 없을 수도 있습니다. + +Access Token - 서버에 접근할 수 있는 권한을 부여하는 토큰, 일정 시간 후에 만료되도록 설정 +Refresh Token - Access Token이 만료되면 재발급 받기 위해 사용하는 토큰 ## 🔗 꼬리질문: 토큰 기반 인증에서 토큰의 무효화는 어떻게 처리되나요? @@ -184,7 +189,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 토큰 기반 인증에서 토큰의 무효화는 주요 방법은 두 가지가 있습니다. 첫 번째는 서버 측에서 토큰을 저장하고 검사하는 방법입니다. 서버 측에 모든 발급된 토큰을 저장해두고, 클라이언트의 요청마다 해당 토큰이 유효한지를 확인합니다. 이 경우, 서버는 필요할 때 언제든지 개별 토큰을 무효화할 수 있습니다. 그러나 이 방식은 모든 요청에 대해 데이터베이스 조회를 필요로 하므로 부하가 커질 수 있습니다. 두 번째는 JWT 같은 자체 포함형 토큰을 사용하는 방법입니다. JWT와 같은 자체 포함형 토큰들은 만료 시간을 내장하고 있어서 일정 시간 후 자동으로 만료됩니다. 그러나 한 번 발급된 JWT는 별도의 정보 없이는 중간에 무효화하기 어렵다는 단점이 있습니다. 추가적으로 로그아웃 혹은 세션 종료시 클라이언트 쪽에서도 반드시 해당 사용자의 모든 인증 정보를 삭제해야 합니다. ## 🔗 꼬리질문: OAuth란 무엇인가요? @@ -192,7 +197,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: OAuth는 "Open Authorization"의 약자로, 사용자가 ID와 비밀번호를 직접 사용하지 않고도 다른 웹 사이트나 애플리케이션에서 특정 리소스에 대한 접근 권한을 부여하거나 받을 수 있게 해주는 개방형 표준 프로토콜입니다. 간단한 예로는 Google, Kakao 등 다른 계정으로 로그인하는 기능을 제공하는 소셜 로그인이 있습니다. ## 🔗 꼬리질문: OAuth의 동작 과정을 말해주세요. @@ -200,7 +205,9 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: OAuth의 동작 과정을 순서대로 설명드리겠습니다. 첫 번째로 사용자가 서비스 제공자에게 자신을 인증하거나 특정 작업을 수행하도록 요청합니다. 이때, 서비스 제공자는 사용자를 OAuth를 지원하는 인증 서버로 리다이렉트합니다. 두 번째로 사용자는 인증 서버에서 자신의 아이디와 비밀번호로 로그인하여 본임임을 증명합니다. 세 번째로 로그인 후에, 사용자는 서비스 제공자가 요청한 리소스에 접근하는 것을 허용할지 결정합니다. 이 과정에서 어떤 정보에 대해 접근 권한을 부여할지 설정합니다. 네 번째로 사용자가 권한 부여를 승인하면, 인증 서버는 사용자를 다시 원래의 서비스 제공자 사이트로 리다이렉트하면서 URL에 "인증 코드"라고 불리는 임시 비밀번호를 첨부하여 전송합니다. 다섯 번째로 서비스 제공자는 받은 인증 코드와 함께 보안된 연결을 통해 직접 인증 서버에게 엑세스 토큰을 요청합니다. 엑세스 토큰은 해당 유저가 해당 앱에서 어떤 데이터에 접근할 수 있는지 나타내주는 역할을 합니다. 마지막으로 이 액세스 토큰을 가지고 있는 서비스 제공자는 해당 유저 대신해서 필요한 정보나 기능등에 접근하는 데 활용합니다. + +사용자 인증 요청 => 사용자 로그인 => 권한 부여 => 인증 코드 발급 => 토큰 요청 및 발급 => 리소스 접근 ## 🔗 꼬리질문: OAuth의 장단점에 대해서 설명해주세요. @@ -208,7 +215,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: OAuth의 장점은 사용자 편의성, 보안 강화, 권한 부여와 접근 제어 등이 있습니다. 각 서비스마다 별도의 계정을 생성하고 관리할 필요가 없어 사용자의 편의성이 높아지고, 실제 비밀번호 대신 임시적인 엑세스 토큰을 사용하기 때문에 보안 측면에서 유리합니다. 또한 세부적으로 어떤 리소스에 대해 권한을 부여할지 설정할 수 있기 때문에 유연한 권한 부여와 접근 제어를 할 수 있습니다. 단점으로는 복잡성과 보안 위험, 중개 역할 등이 있습니다. OAuth 프로토콜을 구현하기 위해서는 일반적인 Auth 로직보다 복잡성과 기술적 이해가 필요합니다. 또한 OAuth를 구현할 때 올바른 인증 및 권한 검증 절차를 따르지 않으면 보안이 더 안좋아 질 수 있습니다. 마지막으로 OAuth 프로토콜은 여러 개체 사이의 상호작용으로 이루어져 있는데, 이것은 추가적인 네트워크 오버헤드와 지연 시간을 초래할 수 있다는 단점이 있습니다. ## 🔗 꼬리질문: OAuth2.0과 OAuth1.0의 주요 차이점은 무엇인가요? @@ -216,7 +223,15 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: OAuth 1.0과 OAuth 2.0의 주요 차이점으로는 보안 방식, 사용자 경험, 구현 복잡성, 토큰 관리 등이 있습니다. OAuth 1.0은 클라이언트와 서버 간의 모든 요청에 대해 서명된 요청을 필요로 합니다. 이는 복잡한 암호화 과정을 거치며, HMAC-SHA1 또는 RSA-SHA1 암호화 방식을 사용합니다. 반면에 OAuth 2.0은 SSL/TLS와 같은 전송 계층 보안을 사용하여 전체 통신 채널을 암호화합니다. 이로 인해 구현이 단순해지고, HTTPS 프로토콜 위에서 안전하게 작동하도록 설계되었습니다. 그리고 OAuth 2.0은 다양한 타입의 클라이언트 (웹 애플리케이션, 모바일 애플리케이션, 데스크톱 애플리케이션 등)를 지원하기 위해 설계되었기 때문에 사용자들에게 보다 나은 사용 경험을 제공할 수 있습니다. 또한 OAuth 2.0의 구현 복잡성이 OAuth 1.0보다 낮으며, OAuth 1.0에서는 access token 외에 추가적으로 request token과 verifier가 필요하지만 OAuth 2.0에서는 access token과 선택적인 refresh token만 필요합니다. + +- OAuth 1.0 + - 클라이언트와 서버 간의 모든 요청에 대해 서명된 요청을 필요 + - HMAC-SHA1 또는 RSA-SHA1 등의 암호화 방식을 사용 + - access token 외에 추가적으로 request token 과 verifier가 필요 +- OAuth 2.0 + - SSL/TLS와 같은 전송 계층 보안을 사용하여 전체 통신 채널을 암호화 + - access token 과 선택적인 refresh token 만 필요 ## 🔗 꼬리질문: OAuth에서 리디렉션 URL의 중요성은 무엇인가요? @@ -224,7 +239,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: OAuth에서 리디렉션 URL는 인증 및 권한 부여 과정의 중요한 요소입니다. 애플리케이션이 받는 인증 코드나 엑세스 토큰등의 중요 정보가 안전하게 전달되기 위해서는 올바른 리디렉션 URL이 설정되어야 힙니다. 잘못된 기디렉션 URL로 인해 이러한 정보가 노츨될 수 있기 때문입니다. 또한 사용자 경험(UX)적으로도 사용자가 로그인을 하기 전 작업으로 돌아갈 수 있도록 해주는 것이 좋습니다. ## 🔗 꼬리질문: JWT에 대해 설명해주세요. @@ -232,7 +247,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: JWT는 JSON Web Token의 약자로 웹 표준으로, 두 개체 사이에서 JSON 객체를 안전하게 전송하기 위한 간결하고 독립적인 방법입니다. JWT는 비밀 또는 RSA나 ECDSA와 같은 공개/비공개 키 쌍을 사용하여 서명할 수 있습니다. JWT는 HTTP 요청의 Authorization 헤더나 본문에 넣어서 전달되곤 하며, 주요 용도는 인증과 권한부여입니다. ## 🔗 꼬리질문: JWT는 어떤 구조로 되어 있나요? @@ -240,7 +255,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: JWT는 일반적으로 헤더, 페이로드, 서명 이렇게 세 부분으로 구성됩니다. 헤더는 토큰의 타입과 해싱 알고리즘이 포함되며, 일반적으로 타입은 JWT이며, 해싱 알고리즘은 HS256 또는 RS256입니다. 페이로드는 클레임이라 불리우는 명세가 포함되어 있습니다. 클레임은 엔티티와 추가 데이터에 대한 정보를 포함합니다. 서명은 헤더의 인코딩 값, 페이로드의 인코딩 값, 그리고 비밀 값을 합친 후 주어진 알고리즘이 해당 값을 해싱하는 과정을 거쳐 생성됩니다. ## 🔗 꼬리질문: JWT의 장단점을 설명해주세요. @@ -248,7 +263,10 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: JWT의 장점은 스케일링 및 분산 시스템 지원, 비상태성, 성능 등이 있습니다. JWT는 자체 포함적인 특성 때문에 서버와 클라이언트 사이, 혹은 분산 시스템 간에 쉽게 전달할 수 있습니다. 각 토큰은 필요한 모든 정보를 가지고 있으므로 데이터베이스를 조회할 필요 없이 유효성을 검사하거나 클레임을 읽어낼 수 있습니다. 또한 JWT는 상태를 저장하지 않기 때문에, 서버에서 세션 상태를 유지할 필요가 없습니다. 이는 RESTful 웹 서브시의 "stateless" 원칙을 따르며, 확장성과 관리 용이성 측면에서 이점을 제공합니다. 그리고 앞서 말한 것처럼 데이터베이스 조회 없이 클라이언트의 요청을 인증하거나 권한을 부여할 수 있으므로, 성능 개선에 도움이됩니다. 단점으로는 보안 문제, 무효화 문제, Payload의 크기, 데이터 노출 등이 있습니다. 만약 JWT가 탈취된다면 공격자가 헤당 사용자처럼 시스템 내에서 동작하는 것을 막기 어렵습니다. 따라서 HTTPS와 같은 안전한 연결위에서만 전송되어야 하며, 가능한 민감한 정보는 포함시키지 않아야합니다. 그리고 일단 발급된 후에는 중간에 수정이 불가능하므로 사용자의 권한 변경등을 대응하기 어렵고, 일반적으로 JWT는 만료 시간까지 유효하기 때문에 무효화 시키기 어렵습니다. 또한 JWT는 클레임 세트를 포함하므로, 세션 ID나 기타 간단한 인증 메커니즘에 비해 상대적으로 크기가 크기 때문에 네트워크 부하가 증가할 수 있습니다. 마지막으로 JWT의 페이로드는 Base64로 인코딩되어 전송되므로, 중요한 정보는 페이로드에 포함시키지 않거나 추가적인 암호화를 해야합니다. + +장점 - 분산 시스템 지원, 비상태성, 성능 +단점 - 보안 문제, 무효화 문제, Payload의 크기, 데이터 노출 ## 🔗 꼬리질문: JWT의 페이로드(Payload)에는 어떤 정보들이 담기나요? @@ -256,7 +274,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: JWT의 페이로드는 인련의 클레임을 포함하고 있습니다. 클레임은 엔티티(일반적으로 사용자)와 추가 데이터에 대한 정보를 담고 있습니다. 클레임에는 등록된, 공개, 비공개 세 가지 유형이 있으며, 등록된 클레임은 JWT 스펙에서 사전 정의된 클레임들로, 권장하는 클레임입니다. 토큰을 발행하는 주체를 뜻하는 iss, 토큰의 만료 시간을 뜻하는 exp, 토큰이 어떤 주제에 대한 것인지 (일반적으로는 유저 id)를 뜻하는 sub, 토큰이 어떤 대상을 위한 것인지를 뜻하는 aud 등이 있습니다. 공개 클레임은 임의로 정의할 수 있는 이름이며, 충돌을 방지하기 위해 JWT 스펙에서는 이름을 URI 형식으로 정하는 것을 권장합니다. 비공개 클레임은 두 개체 사이에서 협상하여 사용하는 이름입니다. ## 🔗 꼬리질문: JWT를 사용할 때 토큰의 만료 시간을 어떻게 설정하나요? @@ -264,7 +282,18 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: JWT의 만료 시간은 exp 클레임을 사용하여 설정합니다. 이 클레임은 JWT가 만료되는 시점을 나타내는 유닉스 타임스탬프입니다. 아래와 같은 방식으로 JWT를 생성할 때 exp 필드를 설정하여 토큰의 만료 시간을 지정할 수 있습니다. + +```js +const jwt = require("jsonwebtoken"); +const token = jwt.sign( + { + data: "userdata", + }, + "secret", + { expiresIn: "1h" } +); // 1 hour +``` ## 🔗 꼬리질문: JWT는 Stateless한 특성을 가지는데, 이것의 의미와 장점은 무엇인가요? @@ -272,7 +301,14 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: Stateless란 상태 정보를 저장하지 않는다는 것을 의미합니다. 즉, 서버가 클라이언트의 이전 요청에 대한 저보를 기억하거나 저장하지 않습니다. 각 요청은 독립적으로 처리되며, 모든 필요한 데이터는 요청 자체에 포함되어 있습니다. JWT가 Stateless한 특성으로 인해 가지는 장점은 확장성, 리소스 절약, 단순성, REST 원칙 준수 등이 있습니다. 상태를 유지하지 않기 때문에 어떤 서버에서든 요청을 처리할 수 있습니다. 이는 로드 밸런싱과 같은 분산 시스템에서 중요한 특징입니다. 또 서버가 클라이언트의 상태 정보를 저장할 필요가 없으므로 메모리와 기타 리소스를 절약할 수 있습니다. 그리고 각 요청이 독립적으로 처리되므로 개발과 디버깅이 단순해지며, REST 아키텍처 스타일의 핵심 원칙 중 하나인 stateless 원칙을 준수합니다. + +Stateless - 상태 정보를 저장하지 않는다. + +- 확장성 +- 리소스 절약 +- 단순성 +- REST 원칙 준수 ## 🔗 꼬리질문: 세션 기반 인증 방식과 토큰 기반 인증 방식의 차이에 대해 설명해주세요. @@ -280,7 +316,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 각각의 방식은 사용자의 신원을 확인하고 추적하는 방법에 있어서 차이점을 가지고 있습니다. 세션 기반 인증에서는 사용자가 로그인하면 서버는 해당 사용자의 정보와 연관된 세션을 생성합니다. 이 세션이 서버에 저장되며, 클라이언트에는 해당 세션을 식별할 수 있는 세션 ID가 쿠키로 전달됩니다. 이후 클라이언트는 모든 요청에 쿠키를 포함시켜 서버가 그 요청을 해당 세션과 연결시킬 수 있게 합니다. 토큰 기반 인증에서는 사용자가 로그인하면, 서버는 특정 정보와 함께 디지털 사인된 토큰을 생성하여 클라이언트에 반환합니다. 클라이언트는 이 토큰을 저장하고 모든 요청 시 HTTP 헤더에 포함하여 전송합니다. ## 🔗 꼬리질문: 로그인과 로그인 유지를 할 때 어떤 방식으로 구현했는지 순서대로 설명해주세요. @@ -288,7 +324,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 순서대로 설명드리겠습니다. 첫 번쨰로 사용자가 웹사이트에 방문하여 로그인 페이지로 이동합니다. 두 번째로 사용자는 자신의 아이디와 비밀번호를 입력하고, '로그인 유지' 옵션을 선택할 수 있습니다. 세 번째로 사용자가 로그인 버튼을 클릭하면, 웹 서버는 사용자가 제공한 아이디와 비밀번호를 검증합니다. 네 번째로 아이디와 비밀번호가 올바르면, 서버는 세션을 생성하고 그 세션에 대한 고유한 식별자를 생성합니다. 이 식별자는 보통 쿠키로 브라우저에 전송됩니다. 다섯 번째로 '로그인 유지' 옵션이 선택되었다면, 서버는 '세션 쿠키' 뿐만 아니라 '영구 쿠키'도 생성합니다. 이 영구 쿠키의 만료 시간은 길게 설정되며 이것은 사용자가 브라우저를 닫거나 컴퓨터를 재부팅해도 로그아웃되지 않게 해줍니다. 여섯 번째로 다음번에 사용자가 웹 사이트에 방문할 때, 브라우저는 해당 사이트의 쿠키를 자동으로 서버로 전송합니다. 일곱 번째로 서버에서는 전송된 쿠키의 정보를 확인하여 해당 세숀이 유효한 경우, 그 세션과 연결된 사용자 계정으로 자동으로 로그인 처리 합니다. 만약 영구 쿠키만 남아있고 세션 쿠키가 없다면 서버에서는 영구 쿠키를 통해 복원된 세션 정보로 자동 로그인을 처리합니다. 하지만 쿠키가 만료되었다면 사용자는 다시 로그인해야 합니다. 이 방식 말고도 JWT나 OAuth를 통해 구현할 수도 있습니다. ## 🔗 꼬리질문: 소셜 로그인의 장단점은 무엇인가요? @@ -296,7 +332,10 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 소셜 로그인은 사용자가 새로운 계정을 생성하지 않고도 기존의 소셜 미디어 계정을 이용하여 다른 웹사이트나 앱에 로그인하는 기능을 말하며 이는 사용자에게 많은 편리함을 제공하지만 몇 가지 단점도 있습니다. 사용자는 별도의 회원가입 과정 없이 소셜 미디어 계정 정보를 이용해 즉시 로그인할 수 있기 때문에 서비스를 더욱 빠르게 시작할 수 있다는 장점이 있지만, 소셜 네트워크 서비스에 대한 강한 의존성을 가지기 때문에 만약 해당 계정에 문제가 생긴다면 사이트에 접근하지 못한다는 단점이 있습니다. 간단한 예로는 얼마전 카카오 서비스가 단체로 중단되었을 때 카카오 로그인을 사용하는 많은 사이트들이 피해를 본 사건이 있습니다. 이 사건 이후 많은 사이트에서 소셜 로그인의 의존성을 낮추는 방향을 선택하는 걸로 알고 있습니다. + +장점 - 간편성 +단점 - 종속성, 데이터 연동 문제 ## 🔗 꼬리질문: 비밀번호 기반 인증과 비밀번호 없는 인증의 차이점과 장단점은? @@ -304,7 +343,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 비밀번호 기반 인증 방식은 일반적인 형태의 인증 방식으로, 간단하고 직관적이며 별도의 하드웨워나 소프트웨어가 필요 없다는 장점이 있지만 비밀번호가 유출되거나 해킹당할 위험이 있고, 많은 서비스에 가입하게 되면 다양한 비밀번호를 관리해야하는 단점이 있습니다. 비밀번호가 없는 인증은 비밀번호 대신 생체인식, OTP 등을 사용하여 사용자를 식별하는 방식입니다. 훔쳐내거나 추측하기 어려운 개인 정보 또는 독특한 OTP를 통해 보안을 강화하고 비밀번호를 관리할 필요가 없다는 장점이 있지만, 별도의 하드웨워/소프트웨워가 필요하다는 단점이 있습니다. ## 🔗 꼬리질문: 토큰 기반 인증에서 토큰이 노출되면 어떤 문제가 발생할 수 있나요? @@ -312,7 +351,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 토큰 기반 인증에서 토큰이 노출된다면 무단 접근, 개인정보 유출, 서비스 중단, 데이터 변조 및 삭제 등 다양한 보안 문제가 발생할 수 있습니다. ## 🔗 꼬리질문: 2FA(Two-Factor Authentication) 또는 MFA(Multi-Factor Authentication)의 개념과 필요성은 무엇인가요? @@ -320,7 +359,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: 2FA(Two-Factor Authentication)와 MFA(Multi-Factor Authentication)는 보안 시스템의 일부로 사용되며, 사용자가 자신임을 증명하기 위해 두 가지 이상의 인증 방법을 제공해야 하는 방식입니다. 이러한 방식은 계정의 보안을 강화하고, 무단 접근을 막는 데 도움이 됩니다. 2FA는 두 가지 요소를 통해 사용자의 신원을 확인하는 방식입니다. 일반적으로 첫 번째 요소는 '당신이 알고 있는 것'으로 비밀번호나 PIN과 같은 지식 기반 인증입니다. 두 번째 요소는 '당신이 가진 것'으로 스마트폰에서 받는 OTP, 키 카드, 물리적인 토큰 등이 있습니다. MFA는 2FA를 확장한 개념으로, 세 가지 이상의 인증 요소를 필요로 합니다. 세번째 요소로 '당신이 한 것'인 생체 인증(지문, 얼굴 인식 등)을 추가할 수 있습니다. 이와 같은 방법들은 보안 강화, 무단 접근 예방, 사용자 신원 확인, 데이터 보호 등의 이유로 필요합니다. ## 🔗 꼬리질문: Single Sign-On(SSO)에 대해서 설명해주세요. @@ -328,7 +367,7 @@ ### 슬기's 답변: -### 정호's 답변: +### 정호's 답변: Single Sign-On(SSO)은 사용자가 한 번의 로그인으로 여러 서비스나 애플리케이션에 접근할 수 있게 해주는 인증 방식입니다. SSO를 통해 사용자는 다양한 서비스에 대해 별도로 로그인하는 번거로움 없이, 한 번의 인증 절차를 거친 후 여러 개의 관련 시스템이나 서비스를 이용할 수 있습니다. SSO는 사용자 편의성 증대, 생산성 향상, IT 지원 부담 감소 등의 장점이 있지만 SSO 자체가 노출된다면 모든 애플리케이션이 위험에 노출될 수 있다는 점이 단점입니다. ## 📝 REFERENCE @@ -342,6 +381,16 @@ ### 정호 - +https://velog.io/@rlfrkdms1/%EC%BF%A0%ED%82%A4%EC%99%80-%EC%84%B8%EC%85%98%EC%9D%98-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC%EC%99%80-%EC%84%B8%EC%85%98%EC%9D%98-%EA%B5%AC%EC%A1%B0 +https://velog.io/@software/%EC%84%B8%EC%85%98-%EC%BF%A0%ED%82%A4%EC%99%80-%EC%A7%80%EC%86%8D-%EC%BF%A0%ED%82%A4 +https://velog.io/@woply/spring-%EC%BF%A0%ED%82%A4%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EC%9D%B8%EC%A6%9D%EC%9D%98-%EB%B3%B4%EC%95%88-%EB%AC%B8%EC%A0%9C%EC%99%80-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EC%95%88 +https://blog.rs-team.com/12 +https://thecodinglog.github.io/web/2020/08/11/what-is-session.html +https://ryuhojin.tistory.com/10 +https://han41858.tistory.com/54 +https://velog.io/@negu63/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%97%90-%ED%82%A4%EB%A5%BC-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-%EC%A0%80%EC%9E%A5%ED%95%98%EB%8A%94-%EB%B2%95 +https://hudi.blog/oauth-2.0/ +https://sasca37.tistory.com/261 +https://www.entrust.com/ko/resources/faq/what-is-two-factor-authentication --- diff --git a/Browser/Network.md b/Browser/Network.md index 136a84e..8b92082 100644 --- a/Browser/Network.md +++ b/Browser/Network.md @@ -6,7 +6,7 @@ ### 슬기's 답변: 브라우저와 서버간 통신은 주로 HTTP / HTTPS를 사용하여이루어집니다. 먼저, 사용자가 브라우저에 URL을 입력하면 DNS 조회가 이루어지고, DNS로 부터 IP주소를 확인받게되면, TCP연결로 성공 시 HTTP 요청 메시지를 서버에 전송하여 서버는 요청받은 메시지를 처리 후 HTTP 응답 메시지를 전송하여 그 내용을 토대로 브라우저가 렌더링되며 TCP 연결이 종료됩니다. -### 정호's 답변: 웹 브라우저와 서버 간의 통신은 주로 HTTP를 사용합니다. 이 프로토콜은 클라이언트와 서버 간에 데이터를 주고받는 데 사용됩니다. 브라우저에서 웹 페이지를 열면, 브라우저는 해당 웹 페이지에 대한 서버에 HTTP 요청을 보냅니다. 이 요청에는 페이지를 요청하는 데 필요한 정보가 포함되어 있습니다. 서버는 이 요청을 받고 요청된 페이지 또는 데이터를 찾아서 그에 맞는 HTTP 응답을 생성합니다. 이 응답에는 요청된 데이터와 함께 상태 코드, 헤더 등이 포함되어 있습니다. 그후 서버는 생성된 응답을 브라우저로 다시 보냅니다. 응답이 도착하면 브라우저는 해당 데이터를 해석하고 화면에 표시합니다. +### 정호's 답변: 웹 브라우저와 서버 간의 통신은 주로 HTTP를 사용합니다. 이 프로토콜은 클라이언트와 서버 간에 데이터를 주고받는 데 사용되며 브라우저에서 웹 페이지를 열면, 브라우저는 해당 웹 페이지에 대한 서버에 HTTP 요청을 보냅니다. 이 요청에는 페이지를 요청하는 데 필요한 정보가 포함되어 있습니다. 서버는 이 요청을 받고 요청된 페이지 또는 데이터를 찾아서 그에 맞는 HTTP 응답을 생성합니다. 이 응답에는 요청된 데이터와 함께 상태 코드, 헤더 등이 포함되어 있습니다. 그후 서버는 생성된 응답을 브라우저로 다시 보냅니다. 응답이 도착하면 브라우저는 해당 데이터를 해석하고 화면에 표시합니다. TCP연결 @@ -172,6 +172,8 @@ TCP연결 ### 정호's 답변: OSI 7 layer는 네트워크 프로토콜을 일곱 개의 추상적인 계층으로 나눈 것입니다. 계층 별로 설명드리자면 첫 번째로 물리 계층은 전기적, 기계적 특성을 다룹니다. 비트를 전송하기 위한 물리적 매체와 관련된 것으로 케이블, 허브, 리피터 등이 속합니다. 두 번째로 데이터 링크 계층은 프레임 단위로 데이터를 전송합니다. 물리 계층에서 발생할 수 있는 오류를 감지하고 수정합니다. MAC 주소를 이용하여 데이터를 송수신합니다. 세 번쨰로 네트워크 계층은 경로를 선택하고 패킷을 다른 네트워크로 전송합니다. 라우팅과 논리적인 주소 할당을 담당하며 IP 주소를 사용하여 목적지를 식별합니다. 네 번째로 전송 계층은 데이터의 신뢰성과 흐름 제어를 담당합니다. 에러 복구 및 재전송을 수행하며, 연결 설정과 해제를 관리합니다. 주로 TCP와 UDP 프로토콜을 사용합니다. 다섯 번째로 세션 계층은 데이터 교환의 동기화와 관리를 담당하며 다중 통신 세션을 구성하고 유지합니다. 여섯 번째로 표현 계층은 데이터의 형식을 변환하고 암호화/복호화하여 데이터를 응용 계층이 이해할 수 있는 형태로 변환합니다. 일곱 번째로 응용 계층은 최종 사용자에게 서비스를 제공하며, 프로토콜을 이해하고 사용자 인터페이스와 네트워크 서비스 간의 통신을 담당합니다. +물리 계층 => 데이터 링크 계층 => 네트워크 계층 => 전송 계층 => 세션 계층 => 표현 계층 => 응용 계층 + UDP는 재전송과 연결 설정 및 해제가 없고 흐름 제어도 없다며 근데 어떻게 전송 계층에서 UDP를 사용하는거야? #### 🔗🔗 꼬리의 꼬리질문: TCP/IP란 무엇인가?