JWT

: JSON 형식의 데이터를(Claim)  Base64URL 인코딩으로 직렬화한 후 서명해 저장하는 토큰이다. 

     - Base64 URL Encode: URL을 Base64 방식으로 인코딩할 때 오류를 방지하기 위해 '+'와 '/'를 '-'와 '_'로 표현하는 방식이다. 

 

 

JWT 구조

: XXXXXX.YYYYYY.ZZZZZZ (Header.Payload.Signature)

- 예시:

Header와 Payload가 인코딩되고 서명된 JWT

 

1. Header

: 일반적으로 사용한 서명 알고리즘과 토큰 타입으로 구성되어 있다. JSON 형식의 해당 정보를 Base64URL 방식으로 인코딩하여 JWT의 앞 부분을 구성한다.

     - 서명 알고리즘: HMAC SHA256 또는 RSA 등...

     - 토큰 타입: JWT

     - 누구나 읽을 수 있기 때문에 암호화 되지 않은 보안에 민감한 정보를 포함하지 않는다.(암호화가 필요하면 JWE 사용)

{
    "alg": "HS256",
    "typ": "JWT"
}

 

2. Payload

: Claim을 담고 있다. Payload를 Base64Url 방식으로 인코딩하여 JWT의 두 번째 부분을 구성한다.

     - 누구나 읽을 수 있기 때문에 암호화 되지 않은 보안에 민감한 정보를 포함하지 않는다. (암호화가 필요하면 JWE 사용)

     - Claim: key-value로 이뤄진 정보이다.

     - Claim 종류

          1) Registered claims(표준 정의)

               - 선정의된 클레임으로 iss(발급자), exp(만료 시간), sub(제목), iat(발행 시간), aud(토큰 대상자), jti(토큰 고유 식별자)

                    등에 대한 정보이다.

          2) Public claims(사용자 정의 가능)

               - 사용자가 정의할 수 있으나 다른 클레임과의 충돌을 피하기 위해 IANA JSON Web Token Registry에 정의된 이름을                        사용하거나 충돌을 피할 수 있는 네임스페이스를 포함하는 URI로 정의한다. 

               - 공개 목적의 정보 전달을 위해 사용한다.
          3) Private claims(사용자 정의)

               - 당사자 간 정보 공유하기 위해 만들어진 커스텀 claim이다.

               - 사용자에 대한 정보이다.

{
    "sub": "1234567890",     //registered claim
    "name": "John Doe",      //private claim
    "admin": true            //private claim
}

 

3. Signature

: 인코딩된 헤더와 인코딩된 페이로드, 시크릿 키(서버 키)나 개인/공개 키를 헤더에서 정의한 알고리즘을 이용해 서명한다.

- 위변조 검증용이다.

- 예시: HMAC SHA256 알고리즘을 사용

HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret
)

 

 

JWT의 필요

1. 위변조 방지

- 사용자의 데이터는 Payload에 담겨있는데 다른 사람들이 쉽게 디코딩할 수 있기 때문에 누구나 읽을 수 있다. 정보가 쉽게 노출되어버리는 문제 때문에 보안을 장담할 수 없는 우려가 발생하는데 왜 토큰을 사용할까? 

-> 위변조가 발생해도 시크릿 키가 없으면 서명 검증 과정에서 실패하기 때문에 위변조를 방지할 수 있다.

 

2. 확장성 탁월

- DB 조회를 줄일 수 있다.

 

JWT 장점

- 별도의 토큰 저장소가 필요없다.

- Payload를 갖고 생성되기 때문에 db 조회를 하지 않아도 된다.

     - Payload에 인증 인가 정보를 담아두면 db 조회를 해서 사용자의 권한 정보를 파악하는 과정을 생략할 수 있.

- 서버가 클라이언트 인증 정보를 저장할 필요가 없어 무상태가 되기 때문에 탁월한 확장성을 갖는다.

 

 

JWT 단점

- 토큰 길이가 늘어날수록 네트워크 부하의 우려가 있다.

- 토큰을 강제로 만료시키기가 어렵다.

- 토큰이 사용자 정보를 포함해 보안의 우려가 있다. 

- 토큰을 탈취 당했을 때 대처가 어렵다.

 

 

토큰의 보안을 어떻게 강화할까? 

1. 토큰 만료 시간

- 토큰 만료 시간을 짧게 설정하여 해당 시간이 지나면 토큰의 유효성이 사라지도록 한다. 이후 다시 인증 절차를 거쳐야한다.

 

2. Access 토큰과 Refresh 토큰, Refresh Token Rotation

- Access 토큰: 주로 API 통신 시 사용하는 만료 기간이 짧은 토큰이다.

- Refresh 토큰: 주로 토큰 갱신(재발급)을 용도로 사용하는 만료기간이 긴 토큰이다.

1) 인증 과정 후 서버로부터 Access 토큰과 Refresh 토큰을 발급받아 클라이언트의 로컬에 저장한다. 

2) Access 토큰이 만료될 때마다 Refresh 토큰을 사용해 Access Token을 재발급 받는다.

3) Refresh 토큰이 만료되면 인증 과정을 다시 거친다.

 

Refresh 토큰은 Access 토큰 재발급의 용도로만 사용하기 때문에 통신 빈도가 적긴 하지만 여전히 탈취의 위험이 존재한다.

따라서 Access Token 재요청을 할 때마다 Refresh Token도 재발급 받는 Refresh Token Rotation 방식을 사용한다.

Refresh 토큰 또한 만료 기간이 단축되기 때문에 위험을 줄일 수 있다.

 

3. 토큰 블랙리스트

- 토큰 유효 기간이 만료되면 Redis 같은 인메모리 DB에 저장해 해당 토큰을 이용한 인증 요청을 거부하도록 하는 방식이다.

     - 인메모리 데이터베이스: 메모리에 데이터를 저장, 관리하는 DB로 휘발성(전원이 꺼지면 데이터 휘발)과

     빠른 데이터 접근 속도라는 장점을 갖는다.

1) 인증기간 만료 시 Redis에 토큰 고유 식별자를 키로 토큰을 저장한다.

     - TTL 특성을 활용해 일정 시간 후 자동 삭제되도록 한다.

2) 요청 마다 해당 토큰이 블랙리스트에 존재하는지 확인한다.

     - 존재 시 요청을 거부한다.

'CS > Network' 카테고리의 다른 글

Servlet  (1) 2025.05.07
Web Server, WAS  (1) 2025.05.06
HTTP API 설계: RESTful API, Maturity Model  (0) 2025.05.06
HTTP  (1) 2025.05.06
프로토콜과 계층 구조(OSI 7계층 모델)  (0) 2025.05.05

Servlet

: 자바 기반의 웹 애플리케이션 프로그래밍 기술로, 클라이언트의 요청을 처리하고 동적 웹 페이지를 생성하는 서버 측 프로그램

 

- 특징

     - 입출력을 HTTP 프로토콜의 요청, 응답 형태로 다룬다.

     - 서블릿 컨테이너라는 실행 환경에서만 동작 가능하다.

     - 필요에 따라 각각 다른 기능을 담당하는 서블릿이 여러 개 있을 수 있다.(로그인, 회원가입 등...)

 

- 필요성

     - 서블릿 지원하는 WAS 사용 시 비즈니스 로직 실행 작업만 하면 된다.

서블릿 미지원 서버 측 처리 작업 서블릿 지원 서버 측 처리 작업
1. 서버와 TCP/IP 연결 1. 비즈니스 로직 실행
2. HTTP Request Message를 필요한 형태로 변환해 읽기
3. 분석 결과를 통해 프로세스 실행
4.비즈니스 로직 실행
5. HTTP Response Message 생성
6. 응답 전달
7. 연결 종료

 

- 서블릿 생명 주기

     - 서블릿 컨테이너가 서블릿을 생성, 관리한다.

     - WAS 종료 시 서블릿도 함께 종료된다.

// 개발자가 직접 인스턴스화 해서 사용하지 않는다.

 

- 서블릿 컨테이너

1. 서블릿 초기화, 생성, 관리, 호출, 종료 역할을 수행한다.

     - 서블릿 객체를 싱글톤으로 관리

2. 동시 요청 처리를 위해 멀티 스레드를 지원한다.

 

- 서블릿의 동작 원리

1. 사용자의 URL 요청(브라우저에 URL 입력)

     - 웹서버: 정적 리소스는 직접 처리, 서블릿/JSP 처리가 필요한 요청은 WAS로 전달

2. request, response 객체 생성

     - 서블릿 컨테이너(웹 컨테이너):  HTTP 요청 처리 위한 request 객체, HTTP 응답 처리 위한 response 객체 생성

     // 서블릿 컨테이너: 서블릿의 생명주기를 관리하는 WAS의 한 구성요소

3. 서블릿 매핑 확인

     - 서블릿 컨테이너: 배포서술자를 참조해 요청을 처리할 서블릿 클래스 결정 → 요청을 서블릿 컨테이너로 전달

     // 배포서술자: URL과 서블릿 클래스를 미리 매핑시켜 놓은 것(web.xml 또는 애노테이션)

4. 서블릿 인스턴스 확보 및 초기화

     1) 해당 서블릿 클래스가 웹 컨테이너에서 실행된 적 없거나 메모리에 생성된 인스턴스(프로세스) 없음

          => 새로 인스턴스 생성(메모리에 로드), init() 호출해 초기화

     2) 해당 서블릿 클래스의 인스턴스 있음(메모리에 이미 로드되어 있음)

          => 기존 객체 재활용, 요청 처리용 스레드 하나 생성

// init()는 서블릿 당 한 번씩만 호출 ∵ 서블릿 인스턴스는 웹 컨테이너 당 하나만 존재  

5. service() 메서드 호출과 서블릿 클래스 실행

     - 스레드에서 service(request, response) 호출

     // HTTP Method에 따라 다른 함수 호출

          1) GET=> 서블릿 클래스의 doGet(request, response)가 호출

          2) POST=> 서블릿 클래스의 doPost(request, response)가 호출

// 개발자가 doGet(), doPost()에 동적 페이지 생성 로직을 작성(오버라이드)

6. 비즈니스 로직 실행 및 응답 작성

     - doGet() / doPost() 호출돼 사용자 요청에 따른 동적 웹 페이지 생성, DB 조회 등의 로직 수행 후 response 객체에 담음

7. 응답과 스레드의 반환

     → 웹 컨테이너: response 객체를 HTTP 응답 메세지 형태로 변환, 웹서버로 전송 

      → 웹 서버: 전송받은 HTTP 응답 메시지를 브라우저로 전송

      → 사용 끝난 request, response 객체 소멸(GC), 스레드 종료

      → 사용자: 브라우저 통해 동적 생성된 페이지 받아보게 됨

 

 

웹 앱 디렉토리로 인식 되기 위한 구조

     - classes: 실행될 클래스가 존재 // 서블릿 실행에 필수적인 디렉터리

     -  web.xml: 서블릿 배포에 관한 정의 설정 // 서블릿 실행에 필수적인 디렉터리

     -  src: 소스파일 저장 폴더

     -  WEB-INF/lib: WEB-INF 디렉터리 밑에 lib 디렉터리 생성 후 라이브러리 파일을 위치시키면 서블릿에서

해당 라이브러리 파일을 인식 가능

'CS > Network' 카테고리의 다른 글

JWT 토큰이란?  (2) 2025.05.31
Web Server, WAS  (1) 2025.05.06
HTTP API 설계: RESTful API, Maturity Model  (0) 2025.05.06
HTTP  (1) 2025.05.06
프로토콜과 계층 구조(OSI 7계층 모델)  (0) 2025.05.05

Web server

: HTTP를 기반으로 동작하며 정적 리소스를 제공하는 서버이다.

- 예시: NGINX, Apache 등...

// 정적 리소스: img, html, css, js 파일과 같이 컴퓨터에 저장되어 있는 파일로 원본 그대로 응답하는 데이터이다.

 

 

WAS(Web Application Server)

: HTTP 기반으로 동작하며 웹 서버의 기능을 포함하고 추가적으로 코드를 실행해 Application 로직 수행 및 DB와의 상호작용으로 동적 컨텐츠를 생성하는 서버이다.

- 웹 서버에서 요청을 받고 웹 컨테이너로 이를 보내 로직을 수행한 후 결과를 웹 서버로 보낸다. 

//Container: Web Server가 보낸 JSP, PHP 등의 파일을 실행하고 수행결과를 Web Server로 보내주는 역할을 수행한다.

- 예시: Tomcat, Jetty, Undertow 등...

// 동적 리소스: 들어온 요청에 맞게 동적을 만들어진 컨텐츠이다.

 

 

Web System의 효율적인 구성

- WAS만 사용하지 않는 이유

1) WAS 과부하 발생 가능성 상승

2) Application 로직이 정적 리소스로 인해 수행되지 않을 가능성 존재

3) WAS 장애 발생 시 오류 페이지도 응답 불가

 

- 실제 Web System 구성

1) Web Server에서 정적 리소스 처리

2) Application 로직 필요한 요청은 Web Server가 WAS에 전달

=> 효율적 리소스 관리 가능: 정적 자원 과잉 시 Web Server를, Application 관련 자원 과잉 시 WAS를 Scale Out

=> 요류 화면 제공 가능: Web Server는 오류 발생 가능성이 낮고 WAS는 높으며 장애가 자주 발생

     - WAS는 DB에 문제 생겨도 문제 발생

'CS > Network' 카테고리의 다른 글

JWT 토큰이란?  (2) 2025.05.31
Servlet  (1) 2025.05.07
HTTP API 설계: RESTful API, Maturity Model  (0) 2025.05.06
HTTP  (1) 2025.05.06
프로토콜과 계층 구조(OSI 7계층 모델)  (0) 2025.05.05

RESTful API

: REST를 잘 준수하는 API로 HTTP 프로토콜을 사용한 클라이언트와 서버 간 통신을 통해 자원을 관리한다.

- 자원은 고유한 URI로 식별되며 메서드를 통해 사양한 작업을 수행하고, 요청과 응답은 일반적으로 JSON 또는 XML 형식으로 이뤄진다.

 

REST(Respresentational State Transfer)

: 자원을 이름으로 구분해 상태(정보)를 주고받는 것이다.

- URI로 자원 명시

- HTTP Method로 자원에 대한 행위 표시

 

URI 명명 기준

1. 리소스 식별을 기준으로 삼는다.

2. URI에 들어갈 리소스는 복수형 사용을 권장한다.

3. URL에 동사를 사용하지 않는다.

     - REST만으로 해결 어려울 시 동사 허용

4. 자원의 계층 관계를 '/'로 표현한다.

5. 마지막 문자에는 '/'가 있으면 안 된다.

6. '_'가 아니라 '-'를 사용한다.

7. 소문자를 사용한다.

8. URI에 파일 확장자를 포함하면 안 된다.

9. CRUD 함수명을 사용하지 않는다.

10. 정렬, 필터링, 페이징은 신규 API 생성이 아니라 Query Parameter를 사용한다.

 

RESTful API 설계 시 고려사항

1. Consumer first:  API 소비자 입장에서 직관적으로 설계해야 한다.

2. Make best use of HTTP: HTTP의 장점(HTTP Method, Request, Response, Header 등)을 살려 개발해야 한다.

3. Request Method: 최소한 성숙도 모델 Level2로 사용해야한다.

4. Response Status: 각 API 요청에 따라 적절한 HTTP 상태 코드가 절달돼야 한다.(이유 포함)

5. No secure info in URI: URI에는 사용자 정보를 포함해서는 안 된다.

6. Use plurals: 제공하는 데이터를 복수형으로 스는 것이 일반적이다. 

          - 특정 유저 찾고자 한다면 엔드 포인트에 값을 추가한다.

7. User nouns for resources: 모든 리소스는 최대한 직관적으로, 명사형으로 표시한다.

8. For exceptions-define a consistent approach: 일괄적인 엔드포인트 사을 권장한다.

 

 

Maturity Model(성숙도 모델)

: REST의 제약 조건에 따라 API를 등급화한 모델이다.

 

단계

1. Level 0: 웹 서비스 제공 위해 URL만 매핑해 놓은 단계

- 모든 요청을 동일한 엔드포인트를 사용한다.

POST /operation
{
    "operation": "createUser",
    "data": {
        "name": "sparta",
        "password": "codingclub"
    }
}

 

2. Level 1: 외부로 공개하려는 리소스에 대해 의미있는 URL로 표현하기 시작한 단계

- 요청하는 리소스에 따라 다른 엔드포인트로 구분해 사용한다.

- HTTP Methods 별로 서비스 구분을 사용하지 않는다.

//사용자 요청을 GET, POST로 대부분 처리하고 에러를 반환한다.

POST /users
{
    "name": "sparta",
    "password": "codingclub"
}

 

3. Level 2: 제공하려는 리소스를 적절하게 용도, 상태에 따라 HTTP Methods에 맞게 설계하고 서비스하는 단계 

- 조회, 생성, 수정, 삭제 용도에 따라 HTTP Method가 구분되어있다.

// DB에 저장된 리소스 확인하고 데이터 조작을 위해 CRUD와 매칭되는 HTTP Methods를 사용해 서비스한다.

GET /users/123     // 특정 사용자 조회

POST /users        // 사용자 생성
{
    "name": "sparta",
    "password": "codingclub"
}

PUT /users/123     // 사용자 정보 수정
{
    "name": "java",
    "password": "spring"
}

DELETE /users/123  // 사용자 삭제

 

4. Level 3: HATEOAS(Hypermedia As the Engine Of Application State) 기능이 적용된 단계

- 응답에 리소스의 URI를 포함한 링크 요소를 삽입한다.

// 링크 요소는 응답을 받은 다음에 할 수 있는 다양한 액션들을 위한 하이퍼미디어 컨트롤을 포함하고 있다.

{							// 하단은 응답 데이터
    "id": 123,
    "name": "sparta",
    "links": {
        "self": "/users/123",
        "update": "/users/123",
        "delete": "/users/123"
    }
}

 

 

 

 

 

 

'CS > Network' 카테고리의 다른 글

Servlet  (1) 2025.05.07
Web Server, WAS  (1) 2025.05.06
HTTP  (1) 2025.05.06
프로토콜과 계층 구조(OSI 7계층 모델)  (0) 2025.05.05
Connection, Connectionless, HTTP 지속 연결  (0) 2025.05.02

HTTP(HyperText Transfer Protocol)

: 클라이언트와 서버가 서로 통신하는 방법을 표준화하는 통신 프로토콜이다.

// 클라이언트 to 서버, 서버 to 클라이언트, 서버 to 서버 간 데이터 통신에 사용한다.

 

- 동작 순서

1) 클라이언트가 Request를 보내고 응답을 대기한다.

2) 서버가 요청에 대한 처리를 수행한 후 결과를 Response 한다.

 

- 특징

     - 다수의 클라이언트와 상태연결 유지를 위해 많은 서버의 리소스 필요

          - 불특정 다수의 통신 환경을 기반으로 설계되었기 때문이다.

     - 클라이언트와 서버 구조: 클라이언트와 서버 독립적 발전

          - 클라이언트: UI 중점

          - 서버: 데이터, 비즈니스 로직 중점

     - 무상태: 서버는 클라이언트의 상태를 보존하지 않는다.

          (장점)

               - Scale Out 수평 확장성이 높다

               - 갑작스러운 요청량 증가에도 서버 증설이 쉽다

          (단점)

               - 클라이언트가 데이터 추가적으로 전송해야 한다.

          (한계)

               - 무상태로 설계할 수 없는 경우가 있다.(로그인 등)

               => 쿠키, 세션, 토큰 등을 활용해 해결할 수 있다.

     - 비연결: HTTP는 연결을 유지하지 않는다.

          (장점)

               - 효율적인 서버 자원 사용이 가능하다.

          (단점)

               - 추가 요청 발생 시 연결을 새로 해야한다.(3 Way HandShake)

                    => 응답 시간 증가

               - 정적 자원을 모두 다시 다운로드 해야한다.

                    => 캐시, 브라우저 캐싱으로 해결할 수 있다.

                    => HTTP 지속 연결로 해결할 수 있다.

 

- HTTP 메세지 구조

: 메세지 종류 따라 구조가 상이하다.

Start Line
Header
Empty Line
Message Body

 

 

1. 요청 메세지

Get/event HTTP/1.1
Host: spartacodingclub.kr
 
있거나 없으면 비어있다

1) Start Line

: Request의 시작 라인으로 세 부분으로 구성되어 있다(method, path, version)

     (1) HTTP Method: Request의 의도이다. (GET)

 

     (2) path: HTTP Request가 전송되는 목표 주소이다.

               - '/'로 시작하는 경로 (/event)

               - Query Parameter도 포함한다. (/search?keyword=sparta)

     (3) HTTP Version: 버전에 따라 메세지 구조나 데이터가 다를 수 있다. (HTTP/1.1)

 

2) Header

: Request에 대한 추가 정보를 담고 있는 부분이다.

     - Key : Value 형태로 구성

 

3) Empty Line

: 공백 한 줄(필수)

 

4) Body

: 실제 전송하는 데이터가 담긴 부분이다.

     - HTML, img, JSON 등 byte로 표현되는 모든 데이터

     - 없는 경우 비어있다.

 

 

2. 응답 메세지

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
 
있거나 없으면 비어있다

1) Start Line

: Response의 시작 라인으로 세 부분으로 구성되어 있다

     (1) HTTP Version (HTTP/1.1)

     (2) Status Code: HTTP Request의 성공, 실패 여부를 나타내는 코드이다.

     (3) Status Text: 코드와 함께 전달될 메세지이다.(reason phrase)

               - 200 OK

               - 404 Not Found

  클래스 스테이터스 코드 리즌 프레이즈 설명
1xx Informational 100 Continue 클라이언트는 Request를 계속 가능
101 Switching Protocols Upgrade 헤더를 사용해 프로토콜 또는 버전을 변경
2xx Sucess 200 OK 정상적인 처리 종료
3xx Redirection 301 Moved Permanently Location 헤더를 사용해 다른 URI에 리다이렉트 한다. 영구 대응
302 Found Location 헤더를 사용해 다른 URI로 리다이렉트 한다. 임시 대응
304 Not Modified 리소스가 업데이트되지 않음
4xx Client Error 400 Bad Request 리퀘스트 구문에 오류 존재
401 Unauthorized 인증 실패
403 Forbidden 해당 리소스에 대해 액세스가 거부됨
404 Not Found 해당 리소스가 존재하지 않음 
406 Not Acceptable 대응하는 종류의 파일이 없음
412 Precondition Failed 전제 조건을 만족하지 않음
5xx Server Error 500 Internal Server Error 서버가 처리 방법을 모름
502 Bad Gateway 서버가 요청을 처리할때 게이트웨이로 작업하는 동안 장애 발생
503 Service Unavailable 웹서버 애플리케이션에 장애 발생

2) Header

: Response에 대한 추가 정보를 담고 있는 부분이다.

     - Key : Value 형태로 구성

 

3) Empty Line

: 공백 한 줄(필수)

 

4) Body

: 실제 전송하는 데이터가 담긴 부분이다.

     - HTML, img, JSON 등 byte로 표현되는 모든 데이터

     - 없는 경우 비어있다.

 

 

HTTP 메서드

: 요청, 응답 데이터 전송하는 방식이다.

메서드 기능 특징 사용 예시
GET 리소스 조회 - 정적 데이터 조회: Query parameter 미포함
- 동적 데이터 조회: Query parameter 포함
- body 미지원 경우가 많아 사용 비권장
이미지, 정적 텍스트 문서 조회,
검색(검색)
POST 요청 데이터 처리/생성
- body 통해 요청 데이터 전달
- body 통해 요청 데이터 전달 회원가입, 게시글 작성(생성)
PUT 리소스 덮어쓰기 - 기존 리소스 존재: 리소스 전체 수정
- 기존 리소스 미존재: 리소스 생성
(변경)
PATCH 리소스 부분 변경 -  리소스 부분 수정 (변경)
DELETE 리소스 삭제 - 상태코드 대부분 200 사용
- 상황에 따라 204 사용
(삭제)
HEAD GET과 동일하지만 서버에서
Body 제외하고
상태 줄, 헤더만 반환
- 응답의 상태 코드만 확인할 때 사용 검사
OPTION 대상 리소스에 대한
통신 가능 메서드 설명
- CORS 정책 검사 위한 요청 검사

 

- 특징

메서드 요청 메세지에 본문 포함 여부 응답 메세지에 본문 포함 여부 안전성 멱등성 캐시 가능성
GET Optional O O O O
POST O O X X O
PUT O O X O X
PATCH O O X X X
DELETE Optional O X O X
HEAD Optional X O O O
OPTION Optional O O O X

- 안전성: 저장 데이터 변환 여부

- 멱등성: 매 호출마다 결과 동일 여부     //멱등하지 않으면 중복 요청 보내면 안 됨

      - 재요청 중간에 리소스 변경되는 것은 멱등성으로 고려하지 않음

- 캐시 가능성: 재사용 위해 요청에 대한 응답 저장 가능 여부

 

 

헤더 

: 요청 또는 응답으로 부가적인 정보(BODY 크기, 인증 등)를 전송할 수 있도록 만들어준다.

 

- 특징

     - 각 헤더는 하나의 줄로 구분된다.

     - 텍스트로 이뤄져 있다

     - 임의의 헤더를 추가할 수 있으나 서버가 값을 알고 있어야 한다.

 

- HTTP 헤더 확인법

: 개발자 도구 -> Network -> Fetch/XHR -> 우측 Header 정보

 

종류

//참고

     - 요청 헤더 종류

헤더 설명
Host 요청할 서버의 호스트 이름 및 포트
User-Agent 클라이언트 소프트웨어/버전 정보
Accept 클라이언트가 처리 가능한 MIME 타입
Accept-Encoding 클라이언트가 처리 가능한 인코딩 방식
Accept-Language 클라이언트가 선호하는 언어
Authorization 인증된 리소스 요청 시 인증 토큰
Cookie 클라이언트가 서버에 전송하는 쿠키 정보
Referer 요청 직전 머물렀던 URL
Origin POST·CORS 요청 시 출발지(origin)
Upgrade 프로토콜 업그레이드 요청 (예: HTTP → WebSocket)
Expect 특정 동작 기대 (예: 100-continue)
If-Modified-Since 조건부 요청(이후 변경된 경우에만 응답)
If-None-Match 조건부 요청(ETag 비교)
Range 리소스의 부분 범위 요청
X-Forwarded-For 프록시/로드밸런서가 전달하는 원본 클라이언트 IP
X-Requested-With AJAX 요청 식별 (예: XMLHttpRequest)
Accept-Charset 클라이언트가 처리 가능한 문자 집합
Pragma HTTP/1.0 캐시 무효화 지시 (no-cache)
Proxy-Authorization 프록시 서버에 대한 인증 토큰

     

      - 응답 헤더 종류

헤더 설명
Set-Cookie 서버가 클라이언트에 쿠키를 설정하도록 지시
Server 응답을 생성한 서버 소프트웨어 이름 및 버전
WWW-Authenticate 401 Unauthorized 응답 시 인증 방식 안내
Proxy-Authenticate 407 Proxy Authentication Required 응답 시 안내
Location 리다이렉트(3xx) 시 클라이언트가 이동할 URL 지정
Retry-After 429/503 등의 응답에서 재시도까지 대기 시간
Allow 지원되는 HTTP 메서드 목록
ETag 리소스의 엔티티 태그
Last-Modified 리소스 최종 수정 일시
Expires 캐시 만료 일시
Age 캐시된 응답의 경과 시간(초)
Vary 콘텐츠 협상 헤더 필드
Access-Control-Allow-Origin CORS 허용 출처
Access-Control-Allow-Methods CORS 허용 HTTP 메서드
Access-Control-Allow-Headers CORS 허용 요청 헤더
Strict-Transport-Security HSTS 정책
Content-Security-Policy CSP(Content Security Policy)
X-Frame-Options 클릭재킹 방지 (SAMEORIGIN 등)
X-Content-Type-Options MIME 타입 스니핑 방지 (nosniff)
Referrer-Policy 리퍼러 전송 정책
Permissions-Policy 권한(기능) 사용 정책

     

      - 일반 헤더 종류

헤더 설명
Content-Type 본문(body)의 미디어 타입
Content-Length 본문(body)의 길이
Connection 연결 옵션 (keep-alive, close 등)
Cache-Control 캐시 동작 지시자
Date 메시지 생성 또는 전송 일시
Transfer-Encoding 전송 인코딩 방식 (chunked 등)

 

'CS > Network' 카테고리의 다른 글

Web Server, WAS  (1) 2025.05.06
HTTP API 설계: RESTful API, Maturity Model  (0) 2025.05.06
프로토콜과 계층 구조(OSI 7계층 모델)  (0) 2025.05.05
Connection, Connectionless, HTTP 지속 연결  (0) 2025.05.02
Stateful, Stateless  (0) 2025.05.02

프로토콜

: 네트워크 상에서 컴퓨터 간의 통신을 위해 필요한 규칙과 절차의 집합이다.

- 장치 간 교환되는 데이터 형식, 구조부터 송수신 및 처리에 필요한 작업과 동작을 정의한다.

 

 

OSI 7계층 모델

: 데이터의 물리적 전송에서 응용 프로그램의 사용자 인터페이스에 이르기까지 네트워크 통신과 관련된 다양한 단계를 나타내도록 설계한 모델이다.

// 상위 계층은 하위 계층의 인터페이스를 이용해 하위 계층의 서비스를 이용한다.

 

특징

- 통신의 과정단계별로 파악할 수 있다.

- 이상 발생 시 다른 단계를 건들지 않고 이상이 생긴 단계만 고칠 수 있다.

계층 이름 프로토콜 예시 설명
7계층 응용 계층(Application) HTTP, FTP, IRC, SSH, DNS, SMTP 이메일, 파일 전송 등 애플리케이션에 대한 서비스 제공
6계층 표현 계층(Presentation) SSL 응용 계층에 대한 데이터 표현, 암호화 및 압축 처리
5계층 세션 계층(Session) NetBIOS, RPC 세션 체결, 통신 방식 결정
4계층 전송 계층(Transport) TCP, UDP 오류 감지 및 복구를 포함해 안정적인 데이터 전송 제공
3계층 네트워크 계층(Network) IP, ICMP, IGMP 다른 네트워크와 통신을 위한 경로 설정 및 논리 주소 결정
2계층 데이터 링크 계층(Data Link) Ethernet, HDLC, PPP 네트워크 기기 간 데이터 전송 및 물리 주소 결정
1계층 물리 계층(Physical)   시스템 간 물리적 연결과 전기 신호 변환 및 제어

 

1계층: 물리 계층(Physical Layer)

: 물리적 통신 매체와 해당 매체를 통해 데이터를 전송한다.

- PDU(Protocol Data Unit): bit

- 장비: 케이블, 허브, 리피터 등...

- 기능

     - 데이터를 신호로 변환 전송하는 기능을 수행한다.

     - 전기적, 기계적 연결 기능을 수행한다.

- 특징

     - 에러 검출, 수정 기능이 없다.

     - 전송 매체에 따라 신호 변조 방식이 달라질 수 있다.

 

2계층: 데이터 링크 계층(Data Link Layer)

: 물리 계층이 이미 존재하는 네트워크를 통해 두 시스템을 연결한다.

PDU: frame

장비: 브릿지, 스위치 등...

- 프로토콜: Ethernet, PPP 등...

- 기능

     - 오류 검출 및 회복을 위한 오류 제어 기능을 수행한다

     - 송신 측과 수신 측 간 속도 차이 해결을 위한 흐름 제어 기능을 수행한다.

     - 재전송 기능을 수행한다.

     - 프레임의 시작과 끝을 구별하기 위해 프레임 동기화 기능을 수행한다.

- 특징

     - 물리 주소를 결정한다.

 

3계층: 네트워크 계층(Network Layer)

: 다중 네트워크 링크에서 발신지로부터 목적지까지 패킷을 전달하는 기능을 수행한다.

     - 라우팅 기능을 수행한다.

- PDU: packet

- 장비: 라우터 등...

- 프로토콜: IP, ICMP 등...

- 기능

     - 라우팅 기능을 수행한다.

     - 패킷전달한다.

     - 논리 주소(IP 주소 등...)를 사용해 경로를 결정한다.

- 특징

     - 논리 주소를 사용한다.

 

4계층: 전송 계층(Transport Layer)

: 사용자들 간의 신뢰성 있는 데이터를 주고받게 하는 기능을 수행한다.

- PDU: segment(TCP) / datagram(UDP)

- 프로토콜: TCP, UDP 등...

- 기능(프로토콜에 따라 상이)

기능 TCP UDP
오류 검출 체크섬 체크섬
오류 복구 재전송, ACK X
흐름 제어 슬라이딩 윈도우 X
중복 검사 시퀀스 번호로 중복 식별 및 폐기 X

// 체크섬: 헤더 + 페이로드 전체에 대한 검사로 전송 중 발생 가능한 오류 여부를 검출

// 페이로드: 전송 계층에서 실제 애플리케이션 데이터(PDU의 헤더 바로 뒤에 붙음)

- 특징

     - 데이터 전송을 위해Port 번호를 사용한다.

 

5계층: 세션 계층(Session Layer)

: 응용 프로세스가 통신을 관리하기 위한 방법을 정의한다.

- PDU: message(data)

- 프로토콜: NetBIOS, RPC 등...

- 기능

     - 세션(연결) 생성, 유지, 종료 기능을 수행하고 동기화 지점을 관리한다.

     - 대화 제어 기능을 수행한다.

     // 대화: 애플리케이션 간에 이뤄지는 통신 채널의 상호작용

- 특징

     - TCP 세션을 기반으로 한다.

 

6계층: 표현 계층(Presentation Layer)

: 전송하는 데이터의 표현 방식을 결정한다.

- PDU: message(data)

- 표현 방식: , GIF, JPEG, ASCII 등...

- 기능

     - 송신자로부터 온 데이터 해석을 위한 응용 계층 데이터 부호화, 변화 기능을 수행한다.(JSON 파싱 등)

     - 수신자에서 데이터 압축을 풀 수 있는 방식으로 된 데이터 압축 기능을 수행한다.(JPEG 등)

     - 데이터 암호화와 복호화 기능을 수행한다.(SSL 등)

- 특징

     - 서로 다른 데이터 형식 간 호환성을 보장한다.(UTF-8 <-> UCS-2)

 

7계층: 응용 계층(Application Layer)

: 사용자가 사용하는 응용 서비스나 프로세스가 동작하는 계층이다.

- PDU: message

- 프로토콜: HTTP, FTP, SMTP, SSH 등...

- 기능

     - 사용자에게 네트워크 서비스를 제공한다.(웹, 이메일, 파일 등...)

- 특징

     - 사용자 인터페이스로 응용 프로그램 접점이다.

 

 

캡슐화와 역캡슐화

: 네트워크를 통해 데이터를 보낼 때는 캡슐화와 역캡슐화의 과정이 발생한다.

- 캡슐화

: 데이터를 보내기 위해서 데이터의 앞 부분에 필요한 정보를 헤더에 담아 각 계층별로 추가하는 과정을 의미한다.

     - 송신측에서 캡슐화를 통해 데이터를 전송한다.

     - 패킷이 물리 계층에 도달할 때까지 계속된다.

     - 응용 계층에서 하위 계층으로 전달된다.

=> 응용 계층에서 만들어진 요청 데이터가 각 계층을 거치면서 헤더가 추가되고(데이터 링크 계층에서는 헤더와 트레일러가 추가) 물리 계층에서 전기 신호로 변환돼 수신 측에 도착한다.

// 트레일러: 데이터 전달 시 마지막에 추가하는 정보이다.

 

- 역캡슐화

: 수신된 데이터 패킷을 계층 별로 분해해 해당 계층의 헤더 정보를 제거하고 나머지 데이터를 다음 계층으로 전송하는 과정을 의미한다.

     - 수신측에서 역캡슐화를 통해 최초로 보낸 데이터 형태로 받을 수 있다.

     - 패킷이 응용 계층에 도달할 때까지 계속된다.

     - 데이터 링크 계층부터 상위 계층으로 전달한다.

'CS > Network' 카테고리의 다른 글

HTTP API 설계: RESTful API, Maturity Model  (0) 2025.05.06
HTTP  (1) 2025.05.06
Connection, Connectionless, HTTP 지속 연결  (0) 2025.05.02
Stateful, Stateless  (0) 2025.05.02
서버 성능 향상  (0) 2025.05.02

Connection과 Connectionless

: 클라이언트와 서버 간 연결(connection) 유지 여부에 따라 나뉘는 특성이다.

 

 

Connection(연결)

: 클라이언트와 서버가 항상 TCP/IP 연결을 유지하고 있는 상태이다.

- 클라이언트 수만큼 연결 수가 늘어나기 때문에 연결 유지 위해 자원을 소모한다.

     - 요청을 하고 있지 않는 클라이언트와도 연결을 유지 해야한다.

     // 많은 사람들이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청 자체는 많지 않다.

- 장점

1) 새로운 연결 과정 불필요(항상 연결)

2) 요청에 대한 빠른 응답 속도

 

- 단점

1) 연결을 위한 자원 낭비 발생

2) 클라이언트가 지속적으로 요청 보낼거라는 보장 없음

 

 

Connectionless(비연결)

: 클라이언트가 서버에 요청을 하고 응답을 받을 시 바로 TCP/IP 연결을 끊어버리는 것이다.

 

1) 3 Way HandShake 과정으로 TCP/IP 연결을 한다.

2) 연결 후 하나의 요청을 서버로 보내고 서버가 응답을 보내 처리가 끝난다.

3) 연결을 바로 끊는다.

 

- 예시

비연결 방식: 웹페이지 접속한 후 인터넷을 끊어버려도 요청을 통해 노출된 홈페이지는 유지된다.

연결 방식: 웹페이지 접속 후 인터넷을 끊어버리면 에러 페이지가 뜬다. 

 

- 장점

1) 서버 자원 효율적 사용 가능

 

- 단점

1) 요청 추가 발생 시 매번 새로 3 Way HandShake 과정을 통한 연결 필요

     => 요청에 대한 응답 시간 증가

2) 웹사이트의 html, css, img 등의 정적 자원 모두 재다운로드

     => 캐시, 브라우저 캐싱으로 해결

=> 단점을 HTTP 지속 연결로 해결

 

 

HTTP 지속 연결

: 어떤 요청과 연관된 요청들이 모두 응답될 때까지 연결을 유지하는 것이다. 

 

- 장점

1) 연결을 한 번만 맺고 끊기 때문에 Connectionless 방식보다 연결 횟수 적음

     => 속도 빨라짐

'CS > Network' 카테고리의 다른 글

HTTP  (1) 2025.05.06
프로토콜과 계층 구조(OSI 7계층 모델)  (0) 2025.05.05
Stateful, Stateless  (0) 2025.05.02
서버 성능 향상  (0) 2025.05.02
JSON  (1) 2025.05.02

Stateful과 Stateless

: 클라이언트와 서버 간 통신 상태(state) 유지 여부에 따라 나뉘는 특성이다.

 

 

Stateful(상태 유지)

: 서버가 클라이언트의 상태를 유지하는 것을 의미한다.

- 클라이언트와 서버 간에 송수신을 하며 단계별 과정을 진행하는 데 있어 서버가 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태

 

- 예시

: 한 번 로그인을 하면 페이지를 이동 해도 로그인이 풀리지 않고 유지된다.

 

- 장점

: 정보를 어딘가에 저장하고 통신할 때마다 읽기 때문에 정보를 기억할 수 있다.

     - 브라우저 쿠기, 서버의 세션 메모리 등에 저장되어 상태 유지

 

- 단점

1) 같은 서버 유지 필요

     - 해당 서버에 문제가 발생할 시 문제 발생(서버 미동작 원인: 시스템 에러, 비즈니스 로직 문제, 리소스 부족 문제 등...)

     - 다른 서버가 역할을 이어받아도 새 서버로 데이터가 전달된 것이 아니라면 정보가 없기 때문에 문제가 발생한다.

2) 요청 트래픽이 몰리면 상태 유지에 리소스가 많이 소모돼 서버가 종료되거나 다음 요청 처리가 느려지는 문제가 발생한다.

 

 

Stateless(무상태)

: 서버가 클라이언트의 상태를 유지하는 않는 것을 의미한다.

- 서버는 단순히 요청에 대한 응답을 보내는 역할만 수행한다.

- 상태관리는 클라이언트의 책임이다.

 

- 장점

1) 같은 서버 유지 불필요

     - 상태를 보관하지 않기 때문에 해당 서버에 문제가 생겨 다른 서버가 이어받아도 응답하는 데 문제가 발생하지 않는다.

2) 대량 트래픽 발생에도 서버 확장(스케일 아웃 수평 확장성이 높음)으로 대처를 쉽게 할 수 있다.

 

- 단점

1) 클라이언트의 요청에 많은 데이터 소모

     - 매 요청마다 자신의 부가정보를 줘야 한다.

 

- 한계 및 극복

웹 애플리케이션 만들 시 서버 확장성을 고려해 최대한 stateless하게 만들어야 한다.

     - 문제: 로그인 같은 상태 유지가 필요한 경우가 발생한다.

     - 극복: 상태 유지를 최소화 시키되 쿠키, 세션, 토큰 등을 활용하여 한계를 극복한다.

'CS > Network' 카테고리의 다른 글

프로토콜과 계층 구조(OSI 7계층 모델)  (0) 2025.05.05
Connection, Connectionless, HTTP 지속 연결  (0) 2025.05.02
서버 성능 향상  (0) 2025.05.02
JSON  (1) 2025.05.02
DNS, URI(URI, URL)  (1) 2025.05.02

서버 성능 향상 전략

1. Scale Up(스케일 업 = 수직 스케일링)

: 물리적인 성능 향상으로 기존 서버 사양을 업그레이드 해 성능을 향상시키는 방식이다.

// CPU, RAM 등의 자원을 단일 서버에 추가하는 등 하드웨어 장비의 성능 높임 

 

- 장점

     - 상대적으로 쉬운 난이도(사양만 향상시키면 됨)

     - 상대적으로 적은 관리 이슈

     - 요청에 대한 빠른 처리 가능

 

- 단점

     - 성능 향상(확장) 한계 존재

     - 서버 1대 분담 양 증가로 장애 영향도

     - 서버 교체 또는 업그레이드 시 서비스 이용 어려움(다운타임)

     - 성능 증가에 따른 비용 증가폭이 큼

 

- 사용

     1) 데이터 변화가 많은 경우

          - 스케일 아웃은 데이터 정합성 유지 어려움

     2) 의존성이 큰 작업

          - 단일 서버에서 의존성 관리하는 것이 효율적임

2. Scale Out(스케일 아웃 = 수평 스케일링)

: 서버를 여러 대 추가하여 시스템을 확장하는 방식이다.

 

- 장점

     - 지속적 성능 향상(확장) 가능

     - 읽기/ 쓰기가 여러 대의 서버에 분산처리되어 장애 시 전면 장애의 가능성이 적음

     - 스케일 업 방식과 다르게 향후 확장 가능성을 미리 예측, 대비할 필요가 없음

     - 동시에 많은 사용자 요청 처리 가능

 

- 단점

     - 상대적으로 어려운 난이도(아키텍처에 대한 높은 이해도 요구)

     - 서버 수 증가에 따라 관리 어려움 상승

     - 여러 노드에 부하 균등하게 분산시키기 위해 로드 밸런싱 필요

     - 데이터 정합성 이슈(데이터과 일관되게 유지되는 것) 발생 가능성 상승

 

- 사용

     1) 데이터 변화가 적은 웹 서버

          - 상대적으로 낮은 관리 비용, 확장 용이함

     2) 의존성이 없는 작업

'CS > Network' 카테고리의 다른 글

Connection, Connectionless, HTTP 지속 연결  (0) 2025.05.02
Stateful, Stateless  (0) 2025.05.02
JSON  (1) 2025.05.02
DNS, URI(URI, URL)  (1) 2025.05.02
IP, TCP, UDP 프로토콜과 패킷 그리고 PORT  (0) 2025.05.02

JSON(JavaScriptObjectNotation)

: 자바스크립트 객체 표기법으로 데이터를 쉽게 교환, 저장하기 위한 텍스트 기반 데이터 교환 표준이다.

- 클라이언트와 서버가 사용하는 언어에 관계 없이 통일된 데이터를 주고받을 수 있도록 도와준다.

 

- 구조

1. 형식: {key : value}

     - 데이터 이름과 값의 쌍

{"name": "식빵"}

2. 쉼표(',')로 나열

{
	"name" : "식빵",
	"age" : 1,
	"weight" : 2.14
}

 

- 데이터 타입

     - 숫자

     - 문자열

     - 불리언

     - 객체

     - 배열

     - null

//숫자
{ "year" : 2022 }

//문자열
{ "name" : "yeon" }

//불리언
{ "manager" : true }

//객체
{ "code" : { "HTML":"기본틀", "CSS":"디자인", "JS":"동작가능" } }

//배열
{ "number" : ["일", "이", "삼"] }

//null
{ "point" : null }

 

- JSON 배열

: JSON 객체들이 모인 것이다.

     - [ ]로 둘러싼다.

     - 인덱스 별로 나눠 저장 및 접근한다.

[{"id": 0, "name": "철수"},
{"id": 1, "name": "영희"},
{"id": 2, "name": "민지"}]

 

- 명명 규칙

: snake_case, camelCase 모두 사용 가능하다.

'CS > Network' 카테고리의 다른 글

Stateful, Stateless  (0) 2025.05.02
서버 성능 향상  (0) 2025.05.02
DNS, URI(URI, URL)  (1) 2025.05.02
IP, TCP, UDP 프로토콜과 패킷 그리고 PORT  (0) 2025.05.02
컴퓨터 간 네트워크 연결, 인터넷이란  (0) 2025.05.02

+ Recent posts