---

▪️ HTTP ▪️

---

📖 HTTP(HyperText Transfer Protocol)

💡 JSON 같은 다양한 형태의 데이터가 HTTP를 통해 전송
주로 HTML/1.1 TCP를 사용 / 최근 HTML/2, HTML/3 UDP의 사용량도 증가중

📌 동작 순서

• 클라이언트 : 요청을 보내고 응답을 기다린다

• 서버 : 요청을 수행하고 결과를 응답한다

  ---

📌 특징

• HTTP는 인터넷 상에서 불특정 다수의 통신환경을 고려하여 설계되었다
  (다수의 클라이언트와 상태나 연결을 유지해야한다면 - 많은 서버의 리소스가 필요하다)

1️⃣ 클라이언트 - 서버 각각 독립적 구성

2️⃣ 무상태 Stateless

- 서버는 클라이언트의 상태를 보존하지 않으므로 수평 확장성 높다
- 한계 : 무상태의 한계 ( = 전부 Stateless하게 설계할 수는 없다)
➡︎ 캐시, 세션, 토큰으로 해결

3️⃣ 비연결connectionless

- 연결을 유지하지 않으므로 자원 효율적 사용
- 한계 : 비연결의 한계 ( = 매 요청마다 연결하고 정적자원 다운로드 )
➡︎ HTTP 지속연결로 해결

🌟기억 안나면 용어모음집 살펴보자🌟

---

📖 HTTP Message 구조

💡요청메세지 응답메세지 두가지가 있다

• <기본 구조>
  

📌 구조 분석하기

	요청 메세지(Request Message)	응답 메세지(Response Message)
	HTTP Method - GET, POST, PUT, PATCH, DELETE 등	HTTP Version
Start Line	path - 전송되는 대상의 절대 경로(쿼리포함)	Status Code-요청 성공여부 나타내는 코드
	HTTP Version	Status Text-코드와 함께 전달될 메세지
Header	- 요청의 추가 정보들을 가지고 있다.	- 응답에 쓰는 Header 값 따로 존재
Empty Line	- 공백 한 줄	- 공백 한 줄
Message Body	- 실제 전송하는 데이터가 담겨 있는 부분	- 실제 전송하는 데이터가 담겨 있는 부분

* OWS : 띄어쓰기 허용
* field-name은 대소문자 구분을 하지 않는다.
* 서버가 값을알고 있어야 한다

---

📖 HTTP Method

📌 주요 메서드 (CRUD)

1️⃣ POST - 리소스 생성

• 보통 생성될 때 데이터를 식별하기위해서 id값(식별자) 생김

• html form에 사용

• 데이터를 처리하는 방식(리소스)에 정해진 것은 없다

• message body를 통해 요청 데이터를 전달한다

  ---

2️⃣ GET - 리소스 조회

• ❶ Query String 미포함시
  : message body가 지원되지 않는 경우가 많아 권장안한다

• ❷ Query String 포함인 경우
  : 서버에 추가적인 데이터 전송이 필요하면 query string 을 사용!

  ---

3️⃣ PUT - 리소스 덮어쓰기

• 클라이언트가 항상 리소스를 식별해야한다 (post와 다름)

❶	❷	❸

• ❶ 기존 리소스 존재한다면 ➝ 리소스 전체 수정

• ❷ 기존 리소스에서 일부만 변경하고 싶은데? ➝ 그래도 리소스 완전히 덮어씌워짐

• ❸ 기존 리소스가 없는 경우 ➝ 리소스 생성

  ---

4️⃣ PATCH - 리소스 부분 수정

• put이랑 다르다, 필요한 부분만 수정할 수 있다

  ---

5️⃣ DELETE - 리소스 삭제

📍 HTTP Method 속성

💡 속성표
*optional : 있을수도 없을수도

💡 안전성 (Safe)

• 🌟 데이터 변경되면 안전하지 않다
  - 안정 : GET (조회만 하니까)
  - 불안정 : POST, DELETE, PUT, PATCH

💡 멱등성 (Idempotent)

• 🌟 한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다(요청이 실패한 경우 재시도 하기위해 필요)
  - ⭕️ 멱등성 보장
  GET → 같은 결과가 계속 조회된다. (리소스 조회 재요청중 수정요청이 추가된다면? 멱등성 고려X)
  PUT → 수정해서 대체된 후의 결과는 계속 같다.
  DELETE → 같은 요청을 여러번해도 삭제된 결과는 같다.
  - ❌ 멱등성 보장 안함
  POST → 계좌 송금을 두번한다면?, 게시판 글쓰기, 회원가입
  

💡 캐시가능성 (Cacheable)

• 🌟 재사용을 위해 요청에 대한 응답을 저장할 수 있는가
  - 캐시(Cache) : 매번 요청때마다 데이터를 다시 전송할 필요가 없도록 웹브라우저가 임시보관하는 장소
  - 변경 가능성이 적은 정적자원을 주로 캐싱
  - 캐시 가능 : GET, HEAD, POST

---

📖 HTTP 상태 코드

아까 응답 메세지의 200 ok 부분 , 모두 외울필요 없음 백단위로 알고 있으셈

📌 1xx (정보)

• 🌟 요청 수신 후 처리중 (잘 사용 안함)

📌 2xx (성공)

• 🌟 정상 처리 완료

  대표코드
  200 OK	요청 성공
  201 Created	새로운 리소스 생성
  202 Accepted	요청이 수신되었으나 처리가 완료되지 않음 (주로 Batch 처리에서 사용)
  204 No Content	요청은 성공했지만, 응답 데이터가 없음 (저장 버튼, 작성 버튼 )

📌 3xx (리다이렉션)

• 🌟 요청을 완료하려면 추가 행동이 필요한 상태 (+ 서버가 너 이거 해바방! 알려줌)

• 리다이렉션의 종류

  • 영구 리다이렉션
    url이 영구적으로 변경된 경우 - 기존 url 사용 안함

    301 Moved Permanently	메서드 변경(get), 메세지 변경될 수도
    308 Permanent Redirect	메서드와 본문 유지

  • 일시 리다이렉션
    url이 일시적으로 변경된 경우

    302 Found	메서드 변경(get)
    303 See Other	메서드 변경(get)
    307 Temporary Redirect	메서드와 본문 유지

    💡 URL이 일시적으로 변경된 경우 예시 
    -- PRG 패턴 : 게시글 작성(Post) → 응답(Redirect) → 리다이렉트 요청(Get)
    -- 이 패턴이 없으면 새로고침을 할때마다 요청이 중복 처리(post는 멱등성이 없으므로)
    -- 적용하면 새로고침 할때 get 요청을 한다

  • 기타 리다이렉션
    캐시를 활용할 것인지에 대한 여부

    304 Not Modified	캐시 목적으로 사용, 리소스가 수정되지 않았다 -> 클라이언트가 캐시 데이터를 조회하도록 유도

📌 4xx (클라이언트 에러)

• 🌟 잘못된 문법 등으로 서버가 요청 수행 불가 (재시도 해봤자 실패)

  대표코드
  400 Bad Request	요청 내용을 수정해야한다
  401 Unauthorized	리소스에 대한 인증이 필요하다 (로그인같은)
  403 Forbidden	승인 거부, 주로 인가 문제 (권한 없음)
  404 Not Found	요청 리소스가 서버에 없다

📌 5xx (서버 에러)

• 🌟 서버 오류, 요청은 정상이지만 서버가 처리하지 못함 (재시도시 성공할 수도)
• 대표코드
  • 500 Internal Server Error 대부분 이거임
  • 503 Service Unavailable 서비스 이용 불가

---

📖 HTTP header

💡 부가적인 정보 전달에 쓰임 (Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등)

• field-name: OWS field-value OWS (OWS : 띄어쓰기 허용)
• field-name은 대소문자 구분을 하지 않는다.
• HTTP 전송에 필요한 모든 부가정보를 표현할 수 있다.
• 임의의 Header를 추가할 수 있다. 단, 서버가 값을 알고있어야 함
• 텍스트 (plain text)로 이루어져 있다.
• 각각의 헤더는 하나의 줄로 구분된다.

✔️실제 Header 확인하는 법

• 개발자도구(F12) → Network 탭 클릭 → Fetch/XHR 탭 클릭 → 우측 Header 정보

📌 HTTP Header 모음

✔️ 표준 Header

• 외우기보다 찾아서 사용하자 !

✔️ 대표적인 Header

1️⃣ 표현 헤더

📎리소스에 대한 표현 정보 (우리 데이터는 이런 형식이에요 ~)
📎 요청과 응답에서 모두 사용

• Content-Type : 형식
  - 데이터의 미디어 타입이나 문자 인코딩을 나타냄
• Content-Encoding : 압축 방식
  - 데이터를 압축 후 Encoding 헤더를 추가하면, 읽는 쪽에서 해당 정보로 이동
• Content-Language : 언어
• Content-Length : 길이
  - byte 단위로 나타냄

2️⃣ 컨텐츠 협상

📎 클라이언트가 선호하는 표현을 요청
📎 우선순위가 존재 (1에 가까울 수록 우선순위 높다, 1인경우 숫자 생략 가능)

• Accept : 선호하는 미디어 타입
• Accept-Charset : 선호하는 문자 인코딩
• Accept-Encoding : 선호하는 압축 인코딩
• Accept-Language : 선호하는 언어

3️⃣ 일반 정보

• From : 클라이언트 이메일 정보 - 잘 사용 안함
• Referer : 현재 요청된 페이지의 이전 웹 페이지 주소 - 유입 경로 파악 가능
• User-Agent : 클라이언트 애플리케이션 정보(PC, Mobile)- 어떤 환경에서 주로 접속하는지 통계
• Server : 요청을 처리하는 ORIGIN 서버의 Software 정보
• Date : HTTP 요청이 발생한 날짜와 시간

4️⃣ 특별 정보

• Host : 요청한 도메인 정보 (필수)

• Location : 생성된 리소스 URI, 리다이렉트 주소

  • 응답코드 3xx와 함께 응답되면 리다이렉트 주소
  • 응답코드 201(Created)와 함께 응답되면 생성된 리소스의 URI

• Allow : 허용 가능한 HTTP Method

  • 405 (Method Not Allowed)와 함께 응답

• Retry-After : 다음 요청까지 대기 해야하는 시간

  • 503 (Service Unavailable)와 함께 서비스가 언제까지 사용이 불가한지 알려줌

5️⃣ 인증

• Authorization : 클라이언트 인증 정보

• WWW-Authenticate : 리소스에 필요한 인증 방법

  • 401 (Unauthorized) 응답과 함께 사용된다.

6️⃣ Cookie

📎 Cookie를 사용해 요청마다 상태를 전달한다 (세션관리나 광고 트래킹에 주로 사용)

• Set-Cookie : 서버에서 응답시 클라이언트로 Cookie 값 전달

  • 만료기간(expire, max-age), 사용될 위치(domain, path) 설정
  • 주의 ❌
    항상 서버에 전달되니 최소한의 정보만 사용하여 트래픽을 최적화 시켜야 한다
    탈취 당하기 쉬우니 보안에 민감한 개인정보 등은 저장하지 않는다

• Cookie : 클라이언트가 서버에서 받은 쿠키를 Cookie 헤더를 통해 전송한다.

• Secure : 해당 헤더가 적용되면 https인 경우에만 쿠키를 전송한다.

• HttpOnly : http 전송에만 사용한다.

  • 자바스크립트에서 쿠키를 접근하지 못하게 만든다.

• SameSite : 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다.

7️⃣ cache

• Cache-Control : 응답시 사용

  • Cache-Control: max-age
    • 캐시 유효 시간이 지나면 다시 서버를 통해 데이터를 응답받고 캐시를 갱신
  • Cache-Control: no-cache
    • 캐시 가능한 데이터지만, 서버에 검증하고 사용
  • Cache-Control: no-store
    • 보안에 민감한 데이터, 캐시하지 않는다

• if-modified-since : 캐시로 저장된 데이터 최종 수정일

• Last-Modified : 데이터가 마지막으로 수정된 시간

• ETag : 캐시용 데이터에 날짜, 시간이 아닌 이름을 지정

---

📖 Restful API

💡 REST를 잘 준수하는 API , HTTP API를 잘 설계하는 규칙

✔️ REST(Representational State Transfer) ?

• 자원을 이름으로 구분해서 자원의 상태를 주고 받는 것
• URL로 자원 명시, 메서드를 통해 CRUD를 구현하는 것

✔️ 설계 원칙

1. 리소스는 명사를 사용해야 한다.
2. 단수가 아닌 복수 형태를 사용해야 한다.
3. 만약, REST만으로 해결하기 어려운 경우라면 동사를 허용한다.
4. 자원의 계층 관계를 슬래시(/)로 표현한다.
5. 마지막 문자에는 슬래시(/)가 있으면 안된다.
6. 언더바(_)가 아닌 하이픈(-)을 사용해야 한다.
7. 소문자를 사용해야 한다.
8. URI에 파일 확장자를 포함하면 안된다.
9. CRUD 함수명은 사용하지 않고, HTTP Method를 활용해야 한다.
10. 정렬, 필터링, 페이징은 신규 API를 만드는것이 아닌 Query Parameter를 사용해야 한다.

📌 Maturity Model (성숙도 모델)

REST의 제약 조건에 따라 API를 등급화하는 방법

level 0 - URL만 만듦
level 1 - 의미있는 URL, but http 메서드 사용 부적절
level 2 (최소 권장 레벨) - crud와 매칭되는 메서드를 이용하는것
level 3 - 어떤 작업을 할 수 있는지 상태정보를 함께 넘겨준다

---

▪️ Web Application ▪️

---

📖 Web Server

💡 HTTP 기반으로 동작, 정적 리소스 제공
*정적리소스 : 이미 완성된 채로 서버에 존재하는 리소스, 원본 그대로 대답하는 데이터

---

📖 WAS (Web Application Server)

💡 HTTP 기반으로 동작, 웹서버의 기능을 포함
(추가적으로 코드를 실행 ➝ 로직 수행 ➝ 데이터와 상호작용 후(CRUD) 동적 컨텐츠 생성)

• 대표적인 WAS : Tomcat - spring boot에 내장되어있다

✔️ Web Server 🆚 WAS

1. 실제로는 웹서버에서도 애플리케이션 로직을 포함할 수는 있다
2. 와스는 애플리케이션 코드를 실행하는데 더욱 특화되어 있다
3. 자바에서는 Servlet Container 기능을 제공하면 와스이다

---

📖 Web System 구성

📌 WAS만 사용하는 경우

(WAS 안에 로직 정적리소스 다 넣고 쓰기)

1️⃣ WAS가 너무 많은 역할을 하게된다 -> 서버 과부하
2️⃣ WAS에서는 애플리케이션 로직이 가장 중요한데 정적 리소스 때문에 로직 수행 불가할 수도
3️⃣ WAS에 장애가 생기면 화면 출력 불가 (+ 클라이언트에게 오류임을 응답할 수 없다)

📌 실제 웹시스템 구성

• 웹서버는 정적자원 처리 와스는 로직만! 분업을 시키자
  

✔️ 장점

• 효율적인 관리 : 자원 늘어나면 서버를 추가해서 수평적 확장 가능
  ( 정적 자원이 많이 쓰이면 Web Server / App관련 자원이 증가되면 WAS를 스케일 아웃 )
• WAS가 다운되어도 Web Server는 정상 동작 (+ 에러페이지 전달 가능)

---

📖 Servlet

• 💡 HTTP 통신에서 요청과 응답을 처리하는데 사용된다
  자바에서는 Http servlet을 상속받아 구현

📌 역할

📎 원래 서버에서 데이터 처리하는 과정

1. 서버와 TCP/IP 연결
2. HTTP Request Message 필요한 형태로 변환하여 읽기
    1. HTTP Method 및 URL 분석
    2. HTTP Header 분석
    3. HTTP Message Body 읽기 및 변환
3. 분석한 결과를 통해 프로세스 실행
🌟4. 비지니스 로직 실행
5. HTTP Response Message 생성
    1. HTTP Start Line 생성
    2. Header 생성
    3. HTTP Message Body에 응답 데이터를 요청한 형식에 맞춰 응답
    4. 처리가 불가하다면 예외처리
6. 응답 전달
7. 연결 종료

🌟 Servlet이 4번빼고 다해줌, 개발자는 개발만 하면된다

📌 동작 순서

• 개발자가 하는 일
  1. Request 객체에 담겨져있는 HTTP 요청 정보를 꺼내서 사용
     • 요청 정보(URL, Method, Message Body)를 통해 필요한 기능(비지니스 로직)을 수행
  2. 생선된 Response 객체에 HTTP 응답 정보를 입력

---

📖 Servlet Container

Servlet을 지원하는 WAS 내부에 존재한다
💡Servlet을 초기화, 생성, 관리, 호출, 종료하는 역할을 수행한다

• 생명주기
  개발자가 직접 객체화 안해도, 코드만 작성하면 알아서 컨테이너가 알아서 Servlet을 생성한다
  WAS가 종료될때 Servlet도 함께 종료

• Servlet Container가 하는일
  Servlet을 생성, 관리, 호출, 종료하는 역할 - 싱글톤으로 관리
  동시 요청 처리를 위해 멀티 스레드를 지원

*싱글톤? 객체를 하나만 생성하여 생성된 인스턴스를 공유하며 사용하는것

---

📖 Thread

코드를 하나하나 순차적으로 실행하는 것
한번에 하나만 가능하기에 동시에 여러개를 처리하려면 Thread를 추가 생성해야한다

📌 싱글 스레드 - 단일 요청

• Thread가 하나 / 요청도 하나
  요청이 종료되면 원래위치로 돌려놓는다

📌 싱글 스레드 - 동시 요청

• Thread가 하나 / 요청이 여러개
  두번째 요청이오면 Thread를 할당받기위해 대기한다
  첫번째 요청이 끝나고 Thread가 반환되면 그때 다시 할당받고,,,반복

---

📖 Multi Thread

💡 여러개의 스래드를 만들자! WAS는 멀티스레드를 지원한다

📌 1. 요청이 올때마다 새로운 Thread를 생성하기

✔️ 장점

• 동시요청을 처리할 수 있다
• 하나에 문제가 발생해도 나머지 Thread는 정상적으로 동작한다

✔️ 단점

• Thread드 생성수에 제한이 없고 생성 비용이 높다
  (동시요청이 많이 발생하면 리소스 부족으로 서버 다운)
• Thread를 사용하면 context switching 비용이 발생한다

*context switching ?
윈도우의 작업관리자 - 백그라운드 프로세스(순차적으로 실행되는 것)
1번 프로그램을 실행하다 2번으로 스위칭 할때 이 사이에 생기는 것 !

📌 2. Thread Pool을 이용하기

🌟 미리 Thread를 여러개 만들어 두고 요청이 발생할 때 사용, 요청 종료시 반납

• 모든 Thread가 사용중이라면?
  일을 마친 Thread가 생길때까지 대기하거나 거절할 수 있다 (예시 - 대기번호)

💡 정리하기

1️⃣ WAS는 Multi Thread를 지원

• 개발자는 멀티스레드 관련코드 고려하지 않아도된다
• 멀티 스레드 환경에서는 싱글톤 객체 사용 → 공유변수 조심

---

2️⃣ Thread Pool

• 생성가능한 스레드의 최대갯수를 관리 (tomcat? 기본 200개 설정, 갯수 변경가능)

• 장점
  - 요청마다 생성하는 단점 보완
  - 미리 Thread를 생성해두었기 때문에 생성하거나 종료하는 비용 절약 + 응답이 빠르다
  - Thread의 최대갯수가 제한되어 있기때문에 초과 요청이 와도 안전하게 처리

• 단점
  - 최대 Thread 수를 너무 낮게 한다면 응답 지연
  - 최대 Thread 수가 높으면 요청 증가시 리소스 부족으로 서버 다운

---

▪️ SSR, CSR ▪️

---

📖 SSR (Server Side Rendering)

💡 서버에서 화면을 그려준다! 동적으로 html을 만들어서 클라이언트에게 제공하는 기술
*Java에서 대표적으로 사용되는 것 : JSP, Thymeleaf

📌 동작 흐름

✔️ 장점

• 초기 페이지 로드시 완전하게 랜더링된 html을 반환하기 때문에 로딩이 빠르다
• SEO에 유리

*SEO?
검색 엔진에서 상위 노출될 수있도록 최적화하는 과정

✔️ 단점

• 모든 요청에 대해 페이지를 렌더링해야함
• 만들어 진 채로 응답해야하기 때문에 느리다

---

📖 CSR

💡 클라이언트가 화면을 그린다! 자바스크립트로 html을 생성

📌 동작 흐름

• 클라이언트- html을 서버로 요청
• 서버 - 비어있는 html + js 링크 ( 클라이언트 로직, 렌더링 포함 )
• 동작하는 요청에 따라 필요한 형태(json 등)로 응답받는다
• 이 응답 데이터로 html을 동적으로 그린다

✔️ 장점

• 클라이언트가 렌더링을 하므로 사용자의 상호작용에 대한 반응이 빠르다
  (구글맵 기억 - 사용자가 바로바로 움직인당)
• 초기 로딩(모든 로직과 js 링크 전달) 후에는 서버와 통신없이 바로 전환 가능

✔️ 단점

• 초기로딩 시간이 길다
• 검색엔진이 js를 실행하지 못하면 SEO에 불리