🌲 GET, POST의 개념과 함께 데이터 흐름에 대해서 설명해주세요.
GET 방식
- 개념: GET은 요청하는 데이터가 HTTP URL의 일부로 포함되어 전송됩니다. 일반적으로 조회 작업에 사용됩니다.
- 데이터 흐름:
- 사용자가 브라우저에서 URL을 입력하거나 링크를 클릭합니다.
- 브라우저가 해당 URL에 포함된 파라미터와 함께 서버에 요청을 보냅니다.
- 서버가 요청을 처리하고 필요한 정보를 응답으로 보냅니다.
- 브라우저가 응답을 받아 사용자에게 표시합니다.
POST 방식
- 개념: POST는 요청 데이터를 HTTP 메시지 본문에 담아 전송하며, 서버의 상태를 변경하거나 데이터를 추가하는 작업에 사용됩니다.
- 데이터 흐름:
- 사용자가 웹 폼에 데이터를 입력하고 제출 버튼을 클릭합니다.
- 브라우저가 데이터를 HTTP 본문에 담아 서버에 요청을 전송합니다.
- 서버가 요청을 처리하고, 결과를 확인하거나 필요한 정보를 응답으로 보냅니다.
- 브라우저가 응답을 받아 사용자에게 표시하거나 다른 동작을 수행합니다.
요약
- GET은 주로 데이터 조회에 사용되며, URL에 파라미터를 포함합니다.
- POST는 데이터를 생성하거나 변경하는 데 사용되며, HTTP 본문에 데이터를 포함합니다.
- 두 방식 모두 클라이언트에서 서버로 요청을 보내고 응답을 받는 과정을 거칩니다. 하지만 데이터의 위치와 사용 목적이 다릅니다.
포인트
두메서드간 데이터 전송방식과 데이터 흐름의 차이를 기준으로 설명한다.
면접에서 할 대답
- GET은 URL에 데이터를 포함하여 조회를 위한 요청을 하며, 주로 읽기 작업에 사용됩니다.
- POST는 HTTP 본문에 데이터를 담아 서버의 상태를 변경하거나 추가하는데 사용되며, 쓰기 작업에 적합합니다.
- GET은 브라우저 주소창에 파라미터가 노출되지만, POST는 숨겨집니다.
- GET은 길이 제한이 있으며 민감한 정보에 적합하지 않고, POST는 길이 제한이 없으며 보안이 더 강화됩니다.
- 두 방식은 클라이언트와 서버 간의 데이터 교환을 위한 HTTP 메서드로 사용되지만, 데이터의 위치와 사용 목적에서 차이가 있습니다.
🌲 쿠키, 세션, 웹스토리지의 차이에 대해 설명해주세요.
프로젝트를 해봤다면 자주 접하게되는 쿠키, 세션, 웹스토리지에 대해 알아볼 것이다.
그 전에, HTTP 프로토콜이란 것을 알아야 더 이해하기 쉽기에 간략히 알아보자.
🟡 HTTP 프로토콜이란?
HTTP는 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.
기본적으로 HTTP 프로토콜의 환경은 비연결성지향(connectionless), 무상태(stateless)한 특성을 가지기 때문에 요청만으로는 서버는 클라이언트를 구별할 수 없다.
비연결성지향(connectionless)
HTTP 는 먼저 클라이언트가 요청을 서버에 보내면, 서버는 클라이언트에게 요청에 맞는 응답을 보내고 TCP/IP 연결을 끊는 특성이다.
무상태(stateless)
연결을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보를 유지하지 않는 특성이다.
즉, 클라이언트의 로그인 정보나 브라우저에서 입력한 값 등이 페이지를 이동할 때마다 초기화되는 것이다.
이러한 문제점을 해결하기 위해 데이터 저장에 사용되는 것이 쿠키,세션,웹스토리지 이다.
1. 쿠키(Cookie)
- 클라이언트(브라우저) 로컬에 저장되는 키와 값 형태의 작은 파일로, 이름, 값, 만료시간, 경로정보가 들어있다.
- 클라이언트의 상태 정보를 로컬에 저장했다가 참조한다.
- 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있으며, 하나의 쿠키 값은 4KB 까지 저장이 가능하다.
- Response Header 에 set-cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있다.
- 만들어진 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request 사이에 Request Header 를 넣어서 자동으로 서버에 전송한다.
주로 아래 세 가지 목적을 위해 사용된다.
- 세션관리: 서버에 저장해야할 로그인, 장바구니, 게임 스코어 등의 정보 관리
- 사용자 맞춤: 사용자가 선호하는 옵션이나 테마 등의 세팅
- 사용자 추적: 사용자의 행동을 분석하고 기록하는 용도
2. 세션(Session)
- 사용자 정보를 파일 브라우저에 저장하는 쿠키와 달리, 세션은 서버측에서 관리한다.
- 서버에서 클라이언트를 구분하기 위해 세션 ID 를 부여하며, 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때까지 인증상태를 유지한다.
- 접속 시간에 제한을 두어 일정 시간 응답이 없다면 정보가 유지되지 않게 설정 가능하다.
- 데이터를 서버에 두기 때문에 쿠키보다 보안에 좋지만, 사용자가 많아질 수록 서버 메모리를 많이 차지하게 된다.
- 클라이언트가 Request 를 보내면 Response에 set-cookie 를 통해 클라이언트의 유일한 ID 값을 생성해 부여하고, 이를 통해 사용자 정보는 안전한 서버에 존재하며 클라이언트와 서버간에는 id 값만을 전달해 보안 위협을 감소시켜 준다.
쿠키와 세션의 차이점?
데이터 저장 위치
보안
- 쿠키: 저장 위치 때문에 스니핑에 당할 우려가 있음
- 세션: 쿠키를 이용해 세션 아이디만 저장하고 서버에서 처리
쿠키<세션
라이프사이클
- 쿠키: 브라우저를 종료해도 만료기간이 남아있으면 존재
- 세션: 브라우저 종료 시 만료기간에 상관없이 종료
속도
쿠키>세션
3. 웹 스토리지(Web Storage)
- 클라이언트(브라우저)에 데이터를 저장할 수 있도록 HTML5 부터 추가된 저장소
- 간단한 Key-Value 스토리지 형태
- 쿠키와 달리 자동 전송 위험성이 없다.
- 오리진(Origin)(도메인, 프로토콜, 포트) 단위로 접근이 제한되는 특성 덕분에 CSRF 로부터 안전
- 쿠키보다 큰 저장 용량 지원(모바일 2.5MB, 데스크탑 5~10MB)
- 서버가 HTTP 헤더를 통해 스토리지 객체를 조작할 수 없음(자바스크립트 내에서만 수행가능)
- 오직 문자형(String) 데이터 타입만 지원
- 로컬스토리지, 세션스토리지가 있으며 같은 스토리지 객체를 상속하기 때문에 메서드가 동일
3.1 로컬 스토리지(localStorage)
- 사용자가 데이터를 지우지 않는 이상 브라우저나 OS를 종료해도 계속 브라우저에 남아있다
- 영구성
- 단, 동일한 브라우저를 사용할때만 해당
- 지속적으로 필요한 데이터 저장(자동 로그인 등)
localStorage.setItem('test', 1);
- 설정 후 브라우저를 닫고 열어보자.
- 다른 창에서도 본 페이지를 열어봐도 된다.
- 그럼 아래와 같은 결과가 나온다.
alert( localStorage.getItem('test') ); // 1
- 오리진(도메인, 포트, 프로토콜)만 같다면 URL 경로는 달라도 동일한 결과를 볼 수 있다.
- localStorage는 동일한 오리진을 가진 모든 창에서 공유되기 때문입니다.
- 따라서 한 창에 데이터를 설정하면 다른 창에서 변동 사항을 볼 수 있습니다.
3.2. 세션 스토리지(sessionStorage)
- 데이터가 오리진 뿐만 아니라 브라우저 탭에도 종속되기 때문에 윈도우나 브라우저 탭을 닫을 경우 제거된다. (현재 떠 있는 탭 내에서만 유지된다)
- 따라서 페이지를 새로 고침할 때 sessionStorage에 저장된 데이터는 사라지지 않는다.
- 일시적으로 필요한 데이터 저장(일회성 로그인 정보, 입력폼 저장 등)
예시
sessionStorage.setItem('test', 1);
이제 페이지를 새로 고침 해봐도 데이터가 여전히 남아있는 것을 볼 수 있다.
alert( sessionStorage.getItem('test') ); // 새로 고침 후: 1
하지만 다른 탭에서 본 페이지를 열고 바로 위 예시만 실행해보면 '아무것도 찾을 수 없다’는 뜻을 가진 null이 반환된다.
- 이렇게 sessionStorage는 오리진뿐만 아니라 브라우저 탭에도 종속되어 있다.
- 이런 제약 때문에 sessionStorage는 잘 사용되지 않는다.
3.3 왜 사용할까?
- 쿠키를 사용하면 브라우저에 데이터를 저장할 수 있는데, 왜 또 다른 객체를 사용해 데이터를 저장하는걸까?
- 쿠키와 다르게 웹 스토리지 객체는 네트워크 요청 시 서버로 전송되지 않는다.
- 이러한 특징 때문에 쿠키보다 더 많은 자료를 보관할 수 있으며 개발자는 브라우저 내 웹 스토리지 구성 방식을 설정할 수 있다.
- 쿠키와 또 다른 점은 위에 적혀있 듯 서버가 HTTP 헤더를 통해 스토리지 객체를 조작할 수 없다는 것이다.
- 웹 스토리지 객체 조작은 모두 자바스크립트 내에서만 수행된다.
🌲 클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)의 개념과 장/단점을 설명해주세요.
클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)은 웹 페이지를 구성하는 방식의 차이를 나타냅니다.
클라이언트 사이드 렌더링 (CSR)
- 개념: CSR에서는 브라우저에서 HTML을 직접 렌더링합니다. JavaScript가 브라우저에서 실행되어 페이지를 구성하며, 초기 로드 후 추가 데이터는 AJAX 요청을 통해 받습니다.
- 장점:
사용자와의 상호작용이 빠르고 매끄럽습니다.
서버 부하가 적으며, 캐싱이 용이합니다.
- 단점:
초기 로딩 속도가 느릴 수 있습니다.
검색 엔진 최적화(SEO)가 어려울 수 있습니다.
서버 사이드 렌더링 (SSR)
- 개념: SSR에서는 서버에서 HTML을 렌더링하고 완성된 페이지를 클라이언트로 전송합니다. 클라이언트는 렌더링된 HTML을 받아 브라우저에서 표시합니다.
- 장점:
초기 로딩 속도가 빠릅니다.
SEO에 유리합니다.
JavaScript를 지원하지 않는 환경에서도 페이지가 표시됩니다.
- 단점:
서버에 부하가 더 많이 가해질 수 있습니다.
사용자와의 상호작용이 CSR에 비해 다소 느릴 수 있습니다.
- 요약
CSR은 브라우저에서 동적 렌더링으로 상호작용이 좋지만 초기 로딩과 SEO 문제가 있을 수 있습니다.
SSR은 초기 로딩과 SEO에 유리하나, 서버 부하와 사용자 상호작용에서 CSR보다 느릴 수 있습니다.
포인트
아마 nextjs를 왜 사용했냐는 질문에 주니어분들이 대부분 ssr/csr때문에 사용했다고 잘못대답하는 경우가 많고, 애초에 왜 사용해야 하는지도 모른다.
이걸 잘 명심하고 두 개념을 설명할 것
면접에서 할 대답
- 클라이언트 사이드 렌더링(CSR)은 브라우저에서 HTML 렌더링, 상호작용이 좋으나 초기 로딩과 SEO가 어려울 수 있습니다.
- 서버 사이드 렌더링(SSR)은 서버에서 HTML 렌더링, 초기 로딩과 SEO에 유리하나 서버 부하와 상호작용이 느릴 수 있습니다.
CSR 장점: 상호작용 빠름, 서버 부하 적음.
CSR 단점: 초기 로딩 느림, SEO 어려움.
SSR 장점: 초기 로딩 빠름, SEO 유리.
SSR 단점: 서버 부하 많음, 상호작용 느림.
🌲 TCP/UDP에 대해서 설명해주세요.
Transmission Control Protocol (TCP)와 User Datagram Protocol (UDP)은 인터넷 프로토콜 스택의 전송 계층에 해당하는 프로토콜로, 데이터를 전송하는 방법에 차이가 있습니다.
TCP (Transmission Control Protocol)
- 연결 지향: TCP는 통신을 시작하기 전에 연결을 설정하고 종료 시 연결을 종료합니다.
- 데이터 신뢰성: 패킷 손실 시 재전송을 수행하여 신뢰성 있는 데이터 전송이 가능합니다.
- 순서 보장: 패킷들은 정확한 순서로 도착하게 됩니다.
- 흐름 제어 및 혼잡 제어: 네트워크 상황에 따라 데이터 전송 속도를 조절합니다.
- 비교적 느림: 상기 기능들로 인해 처리가 복잡하고 상대적으로 느릴 수 있습니다.
UDP (User Datagram Protocol)
- 연결 비지향: 통신을 시작하기 전에 연결을 설정하지 않으며, 종료도 없습니다.
- 데이터 신뢰성 없음: 패킷 손실 시 재전송을 하지 않으므로 신뢰성이 없을 수 있습니다.
- 순서 보장 없음: 패킷들이 순서대로 도착한다는 보장이 없습니다.
- 흐름 제어 및 혼잡 제어 없음: 데이터 전송 속도 조절이 없습니다.
- 비교적 빠름: 처리가 단순하므로 상대적으로 빠르며, 실시간 스트리밍 등에 적합합니다.
포인트
둘중 하나만 질문하더라도 tcp/udp를 같이 열거하며 설명할 것
면접에서 할 대답
- TCP: 신뢰성과 순서 보장이 필요한 경우에 사용 (예: 웹 페이지, 이메일)
- UDP: 빠른 전송이 중요하고, 일부 패킷 손실이 허용되는 경우에 사용 (예: 음성 및 비디오 스트리밍)