띠용

JWT

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

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

JWT 구조

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

- 예시:

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) 요청 마다 해당 토큰이 블랙리스트에 존재하는지 확인한다.

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

Servlet

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

- 특징

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

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

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

- 필요성

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

- 서블릿 생명 주기

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

     - 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 디렉터리 생성 후 라이브러리 파일을 위치시키면 서블릿에서

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

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에 문제 생겨도 문제 발생

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"
    }
}

HTTP(HyperText Transfer Protocol)

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

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

- 동작 순서

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

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

- 특징

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

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

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

          - 클라이언트: UI 중점

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

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

          (장점)

               - Scale Out 수평 확장성이 높다

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

          (단점)

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

          (한계)

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

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

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

          (장점)

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

          (단점)

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

                    => 응답 시간 증가

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

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

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

- HTTP 메세지 구조

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

1. 요청 메세지

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. 응답 메세지

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

2) Header

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

     - Key : Value 형태로 구성

3) Empty Line

: 공백 한 줄(필수)

4) Body

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

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

     - 없는 경우 비어있다.

HTTP 메서드

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

- 특징

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

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

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

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

헤더 

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

- 특징

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

     - 텍스트로 이뤄져 있다

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

- HTTP 헤더 확인법

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

종류

//참고

     - 요청 헤더 종류

      - 응답 헤더 종류

      - 일반 헤더 종류

프로토콜

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

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

OSI 7계층 모델

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

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

특징

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

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

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 등...

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

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

// 페이로드: 전송 계층에서 실제 애플리케이션 데이터(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 등...

- 기능

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

- 특징

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

캡슐화와 역캡슐화

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

- 캡슐화

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

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

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

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

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

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

- 역캡슐화

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

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

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

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

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 방식보다 연결 횟수 적음

     => 속도 빨라짐

Stateful과 Stateless

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

Stateful(상태 유지)

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

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

- 예시

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

- 장점

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

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

- 단점

1) 같은 서버 유지 필요

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

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

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

Stateless(무상태)

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

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

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

- 장점

1) 같은 서버 유지 불필요

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

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

- 단점

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

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

- 한계 및 극복

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

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

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

서버 성능 향상 전략

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

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

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

- 장점

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

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

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

- 단점

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

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

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

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

- 사용

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

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

     2) 의존성이 큰 작업

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

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

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

- 장점

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

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

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

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

- 단점

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

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

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

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

- 사용

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

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

     2) 의존성이 없는 작업

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 모두 사용 가능하다.