[CS 기술면접] 자료구조, 알고리즘, 운영체제, 데이터베이스, 네트워크, 디자인 패턴 + Android 질문까지 모아보기

CS 면접 스터디를 진행하면서 공부한 기록을 작성하는 포스팅입니다.

vmkmym

Apr 11, 2024

Contents

CS 기술면접 질문 레퍼런스 운영체제 질문 레퍼런스 네트워크 질문 레퍼런스 Android(Java, Kotlin) 질문 레퍼런스

CS 기술면접 질문 레퍼런스

운영체제 질문 레퍼런스

유은선님의 [CS 정리] 기술 면접 질문 정리 - 운영체제

네트워크 질문 레퍼런스

OSI 7계층
- OSI(Open Systems Interconnection) 모델은 컴퓨터 네트워크에서 표준화된 방법으로 통신을 분류하고 이해하는 데 사용되는 일종의 체계이다. 이 모델은 7개의 계층으로 이루어져 있으며, 각 계층은 특정한 역할과 책임을 담당한다.
- 물리 계층 (Physical Layer): 네트워크의 하드웨어 측면을 다룹니다. 케이블, 허브, 리피터 등과 같은 장치들이 여기에 속합니다. 이 계층에서는 데이터를 전기 신호로 변환하여 전송합니다.
- 데이터 링크 계층 (Data Link Layer): 물리 계층의 오류를 검출하고 수정합니다. 물리적으로 연결된 두 장치 사이의 신뢰성 있는 통신을 제공합니다. 프레임(Frame)이라는 단위로 데이터를 관리합니다.
- 네트워크 계층 (Network Layer): 패킷(Packet)의 라우팅과 전달을 담당합니다. 여러 경로를 통해 패킷을 목적지로 전달하고, 라우터가 이 계층에서 동작합니다.
- 전송 계층 (Transport Layer): 종단 간 통신을 제어하고, 데이터를 정렬하며, 오류를 처리합니다. 주로 TCP(Transmission Control Protocol)와 UDP(User Datagram Protocol)가 사용됩니다.
- 세션 계층 (Session Layer): 세션을 설정, 유지 및 해제합니다. 이 계층은 통신을 위한 세션 관리와 동기화를 담당합니다.
- 표현 계층 (Presentation Layer): 데이터의 형식을 정의하고 압축, 암호화, 인코딩을 수행합니다. 데이터의 구문을 정의하고 애플리케이션 간의 데이터 포맷을 변환합니다.
- 응용 계층 (Application Layer): 사용자와 직접 상호작용하여 응용 프로그램을 지원합니다. 이메일, 웹 브라우저, 파일 전송 등의 서비스가 이 계층에서 동작합니다.

TCP/IP의 개념

TCP와 UDP
- TCP (Transmission Control Protocol):
  - 연결 지향형 프로토콜입니다. 통신을 시작하기 전에 연결을 설정하고, 통신이 완료되면 연결을 해제합니다.
  - 신뢰성이 높습니다. 데이터 전송 중 손실된 패킷을 재전송하고, 순서를 보장합니다.
  - 흐름 제어와 혼잡 제어를 통해 네트워크의 혼잡을 관리합니다.
  - 데이터의 전송 순서를 보장합니다.
  - 대표적으로 웹 브라우징, 파일 전송 등에 사용됩니다.
- UDP (User Datagram Protocol):
  - 비연결형 프로토콜입니다. 통신 시작과 동시에 연결을 설정하지 않고, 각각의 패킷은 독립적으로 처리됩니다.
  - 신뢰성이 낮습니다. 데이터를 보내고 받는 즉시 에러 확인이나 재전송을 하지 않습니다.
  - 헤더가 작아서 오버헤드가 적습니다.
  - 실시간 스트리밍, 온라인 게임, DNS(Domain Name System) 등에 사용됩니다.
TCP와 UDP의 헤더 분석 (네트워크 문제 해결, 보안 문제 탐지, 성능 최적화, 프로토콜 이해, 네트워킹 디버깅)
- TCP 헤더에는 소스 포트 및 목적지 포트, 순서 번호와 확인 응답 번호, 데이터 오프셋 및 플래그(URG, ACK, PSH, RST, SYN, FIN), 윈도우 크기, 체크섬, 긴급 포인터 등의 정보가 포함됩니다. 또한 옵션 필드와 데이터가 있습니다.
- UDP 헤더에는 소스 포트 및 목적지 포트, 길이 및 체크섬이 포함됩니다. 유저 데이터그램의 특성 상, TCP보다 간단한 구조를 가지고 있습니다.
TCP의 3-way-handshake와 4-way-handshake
- TCP의 연결 설정 과정(3단계)과 연결 종료 과정(4단계)이 단계가 차이나는 이유?
  - Client가 데이터 전송을 마쳤다고 하더라도 Server는 아직 보낼 데이터가 남아있을 수 있기 때문에 일단 FIN에 대한 ACK만 보내고, 데이터를 모두 전송한 후에 자신도 FIN 메시지를 보내기 때문이다.
- 만약 Server에서 FIN 플래그를 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN 패킷보다 늦게 도착하는 상황이 발생하면 어떻게 될까?
  - 이러한 현상에 대비하여 Client는 Server로부터 FIN 플래그를 수신하더라도 일정시간(Default: 240sec)동안 세션을 남겨 놓고 잉여 패킷을 기다리는 과정을 거친다. (TIME_WAIT 과정)
- 초기 Sequence Number인 ISN을 0부터 시작하지 않고 난수를 생성해서 설정하는 이유?
  - Connection을 맺을 때 사용하는 포트(Port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 Number가 전송된다면 이전의 Connection으로부터 오는 패킷으로 인식할 수 있다. 이런 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정한다.
HTTP와 HTTPS
- HyperText Transfer Protocol로 웹 상에서 클라이언트와 서버 간에 요청/응답(request/response)으로 정보를 주고 받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고받는 데에 쓰인다. TCP와 UDP를 사용하며, 80번 포트를 사용한다.
  - 비연결(Connectionless) : 클라이언트가 요청을 서버에 보내고 서버가 적절한 응답을 클라이언트에 보내면 바로 연결이 끊긴다.
  - 무상태(Stateless) : 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다.
- HyperText Transfer Protocol over Secure Socket Layer 또는 HTTP over TLS, HTTP over SSL, HTTP Secure이다. 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전의 프로토콜이다. HTTPS의 기본 TCP/IP 포트로 443번 포트를 사용한다. HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, 웹 상에서 정보를 암호화하는 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. TLS(Transport Layer Security) 프로토콜은 SSL(Secure Socket Layer) 프로토콜에서 발전한 것이다.
  - 두 프로토콜의 주요 목표는 기밀성(사생활 보호), 데이터 무결성, ID 및 디지털 인증서를 사용한 인증을 제공하는 것이다.
  - 따라서 데이터의 적절한 보호를 보장한다. 보호의 수준은 웹 브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다. 금융 정보나 메일 등 중요한 정보를 주고받는 것은 HTTPS를, 아무나 봐도 상관 없는 페이지는 HTTP를 사용한다.
- HTTPS가 필요한 이유?
  - 클라이언트인 웹브라우저가 서버에 HTTP를 통해 웹 페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공하게 된다.
  - 웹 페이지(HTML)는 텍스트이고, HTTP를 통해 이런 텍스트 정보를 교환하는 것이다.
  - 이때 주고받는 텍스트 정보에 주민등록번호나 비밀번호와 같이 민감한 정보가 포함된 상태에서 네트워크 상에서 중간에 제3자가 정보를 가로챈다면 보안상 큰 문제가 발생한다.
  - 즉, 중간에서 정보를 볼 수 없도록 주고받는 정보를 암호화하는 방법인 HTTPS를 사용하는 것이다.
- HTTPS의 원리
  - 공개키 알고리즘 방식
  - 암호화, 복호화시킬 수 있는 서로 다른 키(공개키, 개인키)를 이용한 암호화 방법
    - 공개키: 모두에게 공개. 공캐키 저장소에 등록
    - 개인키(비공개키): 개인에게만 공개. 클라이언트-서버 구조에서는 서버가 가지고 있는 비공개키
  - 클라이언트 -> 서버
    - 사용자의 데이터를 공개키로 암호화 (공개키를 얻은 인증된 사용자)
    - 서버로 전송 (데이터를 가로채도 개인키가 없으므로 복호화할 수 없음)
    - 서버의 개인키를 통해 복호화하여 요청 처리
- HTTPS의 장단점
  - 장점
    - 네트워크 상에서 열람, 수정이 불가능하므로 안전하다.
  - 단점
    - 암호화를 하는 과정이 웹 서버에 부하를 준다.
    - HTTPS는 설치 및 인증서를 유지하는데 추가 비용이 발생한다.
    - HTTP에 비해 느리다.
    - 인터넷 연결이 끊긴 경우 재인증 시간이 소요된다.
      - HTTP는 비연결형으로 웹 페이지를 보는 중 인터넷 연결이 끊겼다가 다시 연결되어도 페이지를 계속 볼 수 있다.
      - 그러나 HTTPS의 경우에는 소켓(데이터를 주고 받는 경로) 자체에서 인증을 하기 때문에 인터넷 연결이 끊기면 소켓도 끊어져서 다시 HTTPS 인증이 필요하다.
HTTP 요청/응답 헤더
- HTTP 헤더 내 요청 헤더 (Request Header) 항목
  - 요청 헤더는 HTTP 요청 메시지 내에서만 나타나며 가장 방대하다.
  - 주요 항목들
    - Host: 요청하는 호스트에 대한 호스트명 및 포트번호 (필수)
      - Host 필드에 도메인명 및 호스트명 모두를 포함한 전체 URI(FQDN) 지정 필요
      - 이에 따라 동일 IP 주소를 갖는 단일 서버에 여러 사이트가 구축 가능
    - User-Agent: 클라이언트 소프트웨어(브라우저, OS) 명칭 및 버전 정보
    - From: 클라이언트 사용자 메일 주소
      - 주로 검색엔진 웹 로봇의 연락처 메일 주소를 나타냄
      - 때로는, 이 연락처 메일 주소를 User-Agent 항목에 두는 경우도 있음
    - Cookie: 서버에 의해 Set-Cookie로 클라이언트에게 설정된 쿠키 정보
    - Referer: 바로 직전에 머물었던 웹 링크 주소
    - If-Modified-Since: 제시한 일시 이후로만 변경된 리소스를 취득 요청
    - Authorization: 인증 토큰(JWT/Bearer 토큰)을 서버로 보낼 때 사용하는 헤더
      - 토큰의 종류(Basic, Bearer 등) + 실제 토큰 문자를 전송
    - Origin
      - 서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타냄
      - 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생
      - 응답 헤더의 Access-Control-Allow-Origin와 관련
  - 다음 4개는 주로 HTTP 메세지 Body의 속성 또는 내용 협상용 항목들
    - Accept: 클라이언트 자신이 원하는 미디어 타입 및 우선순위를 알림
      - Accept: */* => 어떤 미디어 타입도 가능
      - Accept: image/* => 모든 이미지 유형
    - Accept-Charset: 클라이언트 자신이 원하는 문자 집합
    - Accept-Encoding: 클라이언트 자신이 원하는 문자 인코딩 방식
    - Accept-Language: 클라이언트 자신이 원하는 가능한 언어
    - 각각이 HTTP Entity Header 항목 중에 Content-Type, Content-Type charset-xxx, Content-Encoding, Content-Language과 일대일로 대응됨
- HTTP 헤더 내 응답 헤더 (Response Header) 항목
  - 특정 유형의 HTTP 요청이나 특정 HTTP 헤더를 수신했을 때, 이에 응답한다.
  - 주요 항목들
    - Server: 서버 소프트웨어 정보
    - Accept-Range
    - Set-Cookie: 서버측에서 클라이언트에게 세션 쿠키 정보를 설정 (RFC 2965에서 규정)
    - Expires: 리소스가 지정된 일시까지 캐시로써 유효함
    - Age: 캐시 응답. max-age 시간 내에서 얼마나 흘렀는지 알려줌(초 단위)
    - ETag: HTTP 컨텐츠가 바뀌었는지를 검사할 수 있는 태그
    - Proxy-authenticate
    - Allow: 해당 엔터티에 대해 서버 측에서 지원 가능한 HTTP 메소드의 리스트를 나타냄
      - 때론, HTTP 요청 메세지의 HTTP 메소드 OPTIONS에 대한 응답용 항목
        OPTIONS: 웹서버측 제공 HTTP 메소드에 대한 질의
      - Allow: GET,HEAD => 웹 서버측이 제공 가능한 HTTP 메서드는 GET,HEAD 뿐임을 알림 (405 Method Not Allowed 에러와 함께)
    - Access-Control-Allow-Origin: 요청을 보내는 프론트 주소와 받는 백엔드 주소가 다르면 CORS 에러가 발생
      - 서버에서 이 헤더에 프론트 주소를 적어주어야 에러가 나지 않는다.
      - Access-Control-Allow-Origin: www.zerocho.com
        프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다.
      - Access-Control-Allow-Origin: *
        만약 주소를 일일이 지정하기 싫다면 *으로 모든 주소에 CORS 요청을 허용되지만 그만큼 보안이 취약해진다.
      - 유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다.
HTTP 동작 과정
- 서버 접속 -> 클라이언트 -> 요청 -> 서버 -> 응답 -> 클라이언트 -> 연결 종료
- 1. 사용자가 웹 브라우저에 URL 주소 입력
- 2. DNS 서버에 웹 서버의 호스트 이름을 IP 주소로 변경 요청
- 3. 웹 서버와 TCP 연결 시도
  - 3way-handshaking
- 4. 클라이언트가 서버에게 요청
  - HTTP Request Message = Request Header + 빈 줄 + Request Body
  - Request Header
    - 요청 메소드 + 요청 URI + HTTP 프로토콜 버전
      - GET /background.png HTTP/1.0 POST / HTTP 1.1
      - Header 정보(key-value 구조)
  - 빈 줄
    - 요청에 대한 모든 메타 정보가 전송되었음을 알리는 용도
  - Request Body
    - GET, HEAD, DELETE, OPTIONS처럼 리소스를 가져오는 요청은 바디 미포함
    - 데이터 업데이트 요청과 관련된 내용 (HTML 폼 콘텐츠 등)
- 5. 서버가 클라이언트에게 데이터 응답
  - HTTP Response Message = Response Header + 빈 줄 + Response Body
  - Response Header
    - HTTP 프로토콜 버전 + 응답 코드 + 응답 메시지
      - ex. HTTP/1.1 404 Not Found.
    - Header 정보(key-value 구조)
  - 빈 줄
    - 요청에 대한 모든 메타 정보가 전송되었음을 알리는 용도
  - Response Body
    - 응답 리소스 데이터
      - 201, 204 상태 코드는 바디 미포함
- 6. 서버 클라이언트 간 연결 종료
  - 4way-handshaking
- 7. 웹 브라우저가 웹 문서 출력

HTTPS(SSL) 동작 과정
- 공개키 암호화 방식과 대칭키 암호화 방식의 장점을 활용해 하이브리드 사용
  - 데이터를 대칭키 방식으로 암복호화하고, 공개키 방식으로 대칭키 전달
1. 1. 클라이언트가 서버 접속하여 Handshaking 과정에서 서로 탐색
  1.1. Client Hello
  - 클라이언트가 서버에게 전송할 데이터
    - 클라이언트 측에서 생성한 랜덤 데이터
    - 클-서 암호화 방식 통일을 위해 클라이언트가 사용할 수 있는 암호화 방식
    - 이전에 이미 Handshaking 기록이 있다면 자원 절약을 위해 기존 세션을 재활용하기 위한 세션 아이디
  1.2. Server Hello
  - Client Hello에 대한 응답으로 전송할 데이터
    - 서버 측에서 생성한 랜덤 데이터
    - 서버가 선택한 클라이언트의 암호화 방식
    - SSL 인증서
  1.3. Client 인증 확인
  - 서버로부터 받은 인증서가 CA에 의해 발급되었는지 본인이 가지고 있는 목록에서 확인하고, 목록에 있다면 CA 공개키로 인증서 복호화
  - 클-서 각각의 랜덤 데이터를 조합하여 pre master secret 값 생성(데이터 송수신 시 대칭키 암호화에 사용할 키)
  - pre master secret 값을 공개키 방식으로 서버 전달(공개키는 서버로부터 받은 인증서에 포함)
  - 일련의 과정을 거쳐 session key 생성
  1.4. Server 인증 확인
  - 서버는 비공개키로 복호화하여 pre master secret 값 취득(대칭키 공유 완료)
  - 일련의 과정을 거쳐 session key 생성
  1.5. Handshaking 종료
2. 2. 데이터 전송
  - 서버와 클라이언트는 session key를 활용해 데이터를 암복호화하여 데이터 송수신
3. 3. 연결 종료 및 session key 폐기

CORS(Cross Origin Resource Sharing)란?
- 웹 서버에게 보안 cross-domain 데이터 전송을 활성화하는 cross-domain 접근 제어권을 부여한다.
- 배경
  - 처음 전송되는 리소스의 도메인과 다른 도메인으로부터 리소스가 요청될 경우 해당 리소스는 cross-origin HTTP 요청에 의해 요청된다.
  - 보안 상의 이유로, 브라우저들은 스크립트 내에서 초기화되는 cross-origin HTTP 요청을 제한한다.
    - 예를 들면, XMLHttpRequest는 same-origin 정책을 따르기에 XMLHttpRequest을 사용하는 웹 애플리케이션은 자신과 동일한 도메인으로 HTTP 요청을 보내는 것만 가능했다.
    - 웹 애플리케이션을 개선시키기 위해, 개발자들은 브라우저 벤더사들에게 XMLHttpRequest가 cross-domain 요청을 할 수 있도록 요청했고 이에 따라 CORS가 생겼다.
- 과정
  - CORS 요청 시에는 미리 OPTIONS 주소로 서버가 CORS를 허용하는지 물어본다.
  - 이때 Access-Control-Request-Method로 실제로 보내고자 하는 메서드를 알리고,
  - Access-Control-Request-Headers로 실제로 보내고자 하는 헤더들을 알린다.
  - Allow 항목들은 Request에 대응되는 것으로, 서버가 허용하는 메서드와 헤더를 응답하는데 사용된다.
  - Request랑 Allow가 일치하면 CORS 요청이 이루어진다.

GET 메서드와 POST 메서드
- HTTP 프로토콜을 이용해서 서버에 데이터(요청 정보)를 전달할 때 사용하는 방식
- GET 메서드 방식
  - 개념
    - 정보를 조회하기 위한 메서드
    - 서버에서 어떤 데이터를 가져와서 보여주기 위한 용도의 메서드
    - 가져오는 것(Select)
  - 사용 방법
    - URL의 끝에 '?'가 붙고, 요청 정보가 (key=value)형태의 쌍을 이루어 ?뒤에 이어서 붙어 서버로 전송한다.
    - 요청 정보가 여러 개일 경우에는 '&'로 구분한다.
    - Ex) www.urladdress.xyz?name1=value1&name2=value2
  - 특징
    - URL에 요청 정보를 붙여서 전송한다.
    - URL에 요청 정보가 이어붙기 때문에 길이 제한이 있어서 대용량의 데이터를 전송하기 어렵다.
      - 한 번 요청 시 전송 데이터(주솟값 + 파라미터)의 양은 255자로 제한된다.(HTTP/1.1은 2048자)
    - 요청 정보를 사용자가 쉽게 눈으로 확인할 수 있다.
      - POST 방식보다 보안상 취약하다.
    - HTTP 패킷의 Body는 비어 있는 상태로 전송한다.
      - 즉, Body의 데이터 타입을 표현하는 'Content-Type' 필드도 HTTP Request Header에 들어가지 않는다.
    - POST 방식보다 빠르다.
      - GET 방식은 캐싱을 사용할 수 있어, GET 요청과 그에 대한 응답이 브라우저에 의해 캐쉬된다.
- POST 메서드 방식
  - 개념
    - 서버의 값이나 상태를 바꾸기 위한 용도의 메서드
    - 수행하는 것(Insert, Update, Delete)
  - 사용 방법
    - 요청 정보를 HTTP 패킷의 Body 안에 숨겨서 서버로 전송한다.
    - Request Header의 Content-Type에 해당 데이터 타입이 표현되며, 전송하고자 하는 데이터 타입을 적어주어야 한다.
      - Default: application/octet-stream
      - 단순 txt의 경우: text/plain
      - 파일의 경우: multipart/form-date
  - 특징
    - Body 안에 숨겨서 요청 정보를 전송하기 때문에 대용량의 데이터를 전송하기에 적합하다.
    - 클라이언트 쪽에서 데이터를 인코딩하여 서버로 전송하고, 이를 받은 서버 쪽이 해당 데이터를 디코딩한다.
    - GET 방식보다 보안상 안전하다.
- Q. 조회하기 위한 용도 POST가 아닌 GET 방식을 사용하는 이유?
  1. 설계 원칙에 따라 GET 방식은 서버에게 여러 번 요청을 하더라도 동일한 응답이 돌아와야 한다. (Idempotent, 멱등)
    - GET 방식은 가져오는 것(Select) 으로, 서버의 데이터나 상태를 변경시키지 않아야 한다.
      - Ex) 게시판의 리스트, 게시글 보기 기능
      - 예외) 방문자의 로그 남기기, 글을 읽은 횟수 증가 기능
    - POST 방식은 수행하는 것 으로, 서버의 값이나 상태를 바꾸기 위한 용도이다.
      - Ex) 게시판에 글쓰기 기능
  2. 웹에서 모든 리소스는 Link할 수 있는 URL을 가지고 있어야 한다.
    - 어떤 웹페이지를 보고 있을 때 다른 사람한테 그 주소를 주기 위해서 주소창의 URL을 복사해서 줄 수 있어야 한다.
    - 즉, 어떤 웹페이지를 조회할 때 원하는 페이지로 바로 이동하거나 이동시키기 위해서는 해당 링크의 정보가 필요하다.
    - 이때 POST 방식을 사용할 경우에 값(링크의 정보)이 Body에 있기 때문에 URL만 전달할 수 없으므로 GET 방식을 사용해야한다. 그러나 글을 저장하는 경우에는 URL을 제공할 필요가 없기 때문에 POST 방식을 사용한다.

쿠키(Cookie)와 세션(Session)
- HTTP 프로토콜의 특징
  - 비연결 지향(Connectionless)
    - 클라이언트가 request를 서버에 보내고, 서버가 클라이언트에 요청에 맞는 response를 보내면 바로 연결을 끊는다.
  - 상태정보 유지 안 함(Stateless)
    - 연결을 끊는 순간 클라이언트와 서버의 통신은 끝나며 상태 정보를 유지하지 않는다.
- 쿠키와 세션의 필요성
  - HTTP 프로토콜은 위와 같은 특징으로 모든 요청 간 의존관계가 없다.
  - 즉, 현재 접속한 사용자가 이전에 접속했던 사용자와 같은 사용자인지 아닌지 알 수 있는 방법이 없다.
  - 계속해서 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것이 큰 장점이지만, 통신할 때마다 새로 연결하기 때문에 클라이언트는 매 요청마다 인증을 해야 한다는 단점이 있다.
  - 이전 요청과 현재 요청이 같은 사용자의 요청인지 알기 위해서는 상태를 유지해야 한다.
  - HTTP 프로토콜에서 상태를 유지하기 위한 기술로 쿠키와 세션이 있다.
- 쿠키(Cookie)란?
  - 개념
    - 클라이언트 로컬에 저장되는 키와 값이 들어있는 파일이다.
    - 이름, 값, 유효 시간, 경로 등을 포함하고 있다.
    - 클라이언트의 상태 정보를 브라우저에 저장하여 참조한다.
  - 구성 요소
    - 쿠키의 이름(name)
    - 쿠키의 값(value)
    - 쿠키의 만료시간(Expires)
    - 쿠키를 전송할 도메인 이름(Domain)
    - 쿠키를 전송할 경로(Path)
    - 보안 연결 여부(Secure)
    - HttpOnly 여부(HttpOnly)
  - 동작 방식
    1. 웹브라우저가 서버에 요청
    2. 상태를 유지하고 싶은 값을 쿠키(cookie)로 생성
    3. 서버가 응답할 때 HTTP 헤더(Set-Cookie)에 쿠키를 포함해서 전송
```
Set−Cookie: id=doy
```
    4. 전달받은 쿠키는 웹브라우저에서 관리하고 있다가, 다음 요청 때 쿠키를 HTTP 헤더에 넣어서 전송
```
cookie: id=doy
```
    5. 서버에서는 쿠키 정보를 읽어 이전 상태 정보를 확인한 후 응답
  - 쿠키 사용 예
    - 아이디, 비밀번호 저장
    - 쇼핑몰 장바구니
- 세션(Session)이란?
  - 개념
    - 일정 시간 동안 같은 브라우저로부터 들어오는 요청을 하나의 상태로 보고 그 상태를 유지하는 기술이다.
    - 즉, 웹 브라우저를 통해 서버에 접속한 이후부터 브라우저를 종료할 때까지 유지되는 상태이다.
  - 동작 방식
    1. 웹브라우저가 서버에 요청
    2. 서버가 해당 웹브라우저(클라이언트)에 유일한 ID(Session ID)를 부여함
    3. 서버가 응답할 때 HTTP 헤더(Set-Cookie)에 Session ID를 포함해서 전송
      쿠키에 Session ID를 JSESSIONID 라는 이름으로 저장
```
Set−Cookie: JSESSIONID=xslei13f
```
    4. 웹브라우저는 이후 웹브라우저를 닫기까지 다음 요청 때 부여된 Session ID가 담겨있는 쿠키를 HTTP 헤더에 넣어서 전송
```
Cookie: JSESSIONID=xslei13f
```
    5. 서버는 세션 ID를 확인하고, 해당 세션에 관련된 정보를 확인한 후 응답
  - 세션 사용 예
    - 로그인
세션도 쿠키를 사용하여 값을 주고받으며 클라이언트의 상태 정보를 유지한다.
즉, 상태 정보를 유지하는 수단은 쿠키 이다.
- 쿠키와 세션의 차이점
  - 저장 위치
    - 쿠키 : 클라이언트
    - 세션 : 서버
  - 보안
    - 쿠키 : 클라이언트에 저장되므로 보안에 취약하다.
    - 세션 : 쿠키를 이용해 Session ID만 저장하고 이 값으로 구분해서 서버에서 처리하므로 비교적 보안성이 좋다.
  - 라이프사이클
    - 쿠키 : 만료시간에 따라 브라우저를 종료해도 계속해서 남아 있을 수 있다.
    - 세션 : 만료시간을 정할 수 있지만 브라우저가 종료되면 만료시간에 상관없이 삭제된다.
  - 속도
    - 쿠키 : 클라이언트에 저장되어서 서버에 요청 시 빠르다.
    - 세션 : 실제 저장된 정보가 서버에 있으므로 서버의 처리가 필요해 쿠키보다 느리다.