HTTP & Web Application

림민지·2025년 3월 17일

Today I Learn

목록 보기
27/62


📌 HTTP

0️⃣ HTTP란?

: HyperText Transfer Protocol
→ 다양한 형태의 데이터(텍스트, 이미지, JSON)가 HTTP를 통해 전송됨.

HTTP는 클라이언트와 서버 사이의 요청과 응답에 사용되고, 서버 간의 데이터 통신에도 사용된다.

클라이언트는 Request를 보내고 서버는 이 요청에 대한 처리 수행 후 결과를 Response한다.

✔️ 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되어, 다수의 클라이언트와 상태/연결을 계속 유지해야하면 이에 따른 많은 서버의 리소스가 필요해진다.

1️⃣ HTTP Message

기본적인 구성은 다음과 같다
(1) Start Line
(2) Header
(3) Empty Line
(4) Message Body

1. 요청 메세지

(1) Start Line

ex) GET/event HTTP/1.1

  • Http Method 작성 (요청의 의도를 가진 CRUD )
    Create → POST
    Read → GET
    Update → PUT PATCH
    Delete → DELETE
    Request Target

  • path 작성하기
    ex) /search?keyword=home
    : HTTP request가 전송되는 대상! (절대경로로 작성하기) + Query String에 해당하는 값도 포함해서

  • HTTP Version 작성하기
    : 1.1 -> HTTP 버전 작성해주기

(2) Header

ex) Host : spartacodingclub.kr
: Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등

(3) Empty Line

필수적으로 공백 한 줄을 둔다.

(4) Message Body

실제 전송할 데이터가 담긴 부분
→ HTML, 이미지, JSON 등등 모든 데이터 전송 가능

2. 응답 메세지

(1) Start Line
- HTTP Version 1.1
- Status Code
: 요청이 성공했는지, 실패했는지
- Status Text
: 코드와 함께 전달될 메세지

(2) Header
- Response에서만 사용되는 Header 값들이 따로 존재한다.

(3) Empty Line
필수로 공백 한 줄

(4) Message Body
실제 전송하는 데이터가 담겨 있는 부분
만약 전송할 데이터가 없다면, Body가 공백

2️⃣ HTTP Method

✅ 클라이언트와 서버 사이에 이루어지는 요청, 응답 데이터를 전송하는 방식!

1. POST - 리소스 생성
: 주로 HTML FORM에 사용 (회원가입, 게시글 작성)
Message Body를 통해 요청 데이터를 전달함

2. GET - 리소스 조회

3. PUT - 리소스 덮어쓰기
: POST랑 다르게, 클라이언트에서 리소스를 식별해 URI 지정함
기존 리소스가 있을때 → 리소스의 전체 수정
기존 리소스가 존재하고, 일부만 변경할 때 → 상관없이 완전히 덮어쓰기 된다
기존 리소스 없을 때 → 생성됨

4. PATCH - 리소스 부분 수정
부분만 수정하고 싶을 때 사용하자 (기존 리소스가 존재하고, 일부만 변경할 때 요런경우)

5. DELETE - 리소스 삭제

3️⃣ 상태 코드

= HTTP Response Message의 Start LIne에 속해있던 Status Code

앞번호를 잘 알아두었다가, 이 앞자리 숫자들이 어떤 의미를 가지고 있는지만 알면 장떙이다^^

[1xx - 정보]

요청 수신 후 처리중인 상태(잘 안씀)

[2xx - 성공]

: 정상 처리 완료된 상태
< 대표 상태코드 >
(1) 200 OK
: 요청 성공
(2) 201 Created
: 새로운 리소스 생성
(3) 202 Accepted
: 요청이 수신되었으나 처리가 완료되지 않음
(4) 204 No Content
: 요청은 성공했지만, 응답 데이터가 없음

[3xx - 리다이렉션]

: 요청을 완료하려면 추가 행동이 필요한 상태

[4xx - 클라이언트 에러]

400 Bad Request
: 클라이언트가 HTTP 요청 내용을 수정 후 보내야 한다.
ex) API 스펙과 일치하지 않을 때, 숫자를 문자로, 문자를 숫자로 등

401 Unauthorized
: 클라이언트가 리소스에 대한 인증(Authentication)이 필요하다.
응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명한다.
ex) 로그인

403 Forbidden
: 서버가 요청을 받았지만 승인 거부
주로 인가(Authorization) 관련문제

404 Not Found
: 요청한 리소스가 서버에 없다.

[5xx - 서버 에러]

: 서버 오류, 요청은 정상이지만 서버가 처리하지 못함 (재시도하면 성공할 수 있다.)
500 Internal Server Error
- 대부분 500으로 처리한다.
503 Service Unavailable
- 서비스 이용 불가

4️⃣ HTTP API 설계

📌 HTTP API 설계 방법
1. 리소스 식별 기준으로 설계
2. URL은 리소스를 식별하는 데 사용, 동사 사용x(행위는 HTTP Method로)
3. 리소스 이름은 복수형
4. HTTP method의 역할을 URL에 포함하지 않기

성공 - 상태 코드 2xx
실패 - 상태 코드 4xx 또는 5xx

기능MethodURL
생성POST/boards
게시글 조회GET/boards/{id}
게시글 목록 조회GET/boards
게시글 수정PUT or PATCH(일부만 수정)/boards/{id}
게시글 삭제DELETE/boards/{id}

5️⃣ Restful API

REST 기반으로 서비스 API를 구현한 것
→ HTTP API를 잘 설계하는 규칙이라고 정리!

1. Restful

📌 REST란?
Representational State Transfer
: 자원을 이름으로 구분해 해당 자원의 상태를 주고받는 것

→ URI를 통해 자원(Resource)을 명시하고, HTTP Method를 통해 해당 자원에 대한 CRUD를 적용!

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

2. Maturity Model (성숙도 모델)

: level0부터 level3까지 REST의 제약 조건에 따라 API를 등급화하는 것
(1) Level 0
웹 서비스를 제공하기 위해 URL만 매핑해 놓은 상태
-모든 요청이 단일 URI로 전송된다

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

(2) Level1
외부로 공개하려는 리소스에 대해서 의미있는 URL로 표현하기 시작한 단계
→ 서비스 형태나 작업의 종류에 맞추어 적절한 HTTP 메소드를 지정x
→ 사용자의 요청을 GET, POST로 대부분 처리하고 에러를 반환한다.
-리소스에 대해 분리된 엔드포인트를 가진다

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

⭐️ (3) Level2
: 우리가 제공하고자 하는 리소스를 적절하게 용도와 상태에 따라서 HTTP Methods에 맞게 설계하고 서비스하는 단계.
→ CRUD와 매칭되는 HTTP Methods를 이용하여 서비스
- 읽기 용도 : GET Method
- 새로운 리소스 추가 : POST Method
- 기존 리소스 상태 변경 : PUT, PATCH Method
- 리소스 삭제 : Delete Method

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

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

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

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

(4) Level3

HATEOAS(Hypermedia As The Engine Of Application State)
: 하나의 동작에 대해, 1가지만 알려주는게 아니라 관련된 모든 정보를 같이 알려주는 기능

→ 데이터를 가지고 그 다음 작업에서 어떠한 작업을 할 수 있는지 상태 정보를 함께 넘겨줌
⭐️ 클라이언트 측에서는 서버가 제공하는 서비스를 일일이 찾지 않아도 됨
→ 엔드포인트만 가지고 있으면 서버가 제공할 수 있는 다음 URI값을 알 수 있음!!

GET /users/123
{
    "id": 123,
    "name": "sparta",
    "links": {
        "self": "/users/123",
        "update": "/users/123",
        "delete": "/users/123"
    }
}

📌 Web Application

1️⃣ Web System

1. Web Server

: 웹 서버는 HTTP 기반으로 동작하며 정적 리소스를 제공
✔️ 정적 리소스란?
리소스가 이미 완성된 채로 서버에 존재하여 원본 그대로 응답하는 데이터
(HTML, CSS, JS, 이미지 등)

ex) NGINX, Apache,

2. WAS

: Web Application Server
웹 서버의 기능을 포함하되, 추가적으로 코드를 실행해서 Application 로직을 수행하고 DB와 상호작용하여 동적 컨텐츠를 생성한다.
→ WAS는 Application 코드를 실행하는 것에 더욱 특화되어 있다.

ex) Tomcat(Spring Boot 내장), Jetty 등

3. Web system의 동작

WAS만 사용하면?
-서버 과부하 발생 가능성 ↑
-WAS에 장애가 생기면 아무런 화면도 안보임

=> 그래서 적절히 섞어 사용해야함!!

  1. 정적 리소스는 Web Server에서 처리한다.
  2. Web Server는 Application 로직이 필요한 요청만을 WAS에 전달한다.

같이 사용하면 좋은 점

  1. 효율적으로 리소스를 관리할 수 있다.
    • 정적 자원이 많이 사용된다면 Web Server를 ScaleOut 한다.
    • Application 관련 자원이 많이 사용된다면 WAS를 ScaleOut 한다.
  2. 오류 화면을 제공할 수 있다.
    • Web Server는 오류가 발생할 확률이 아주 낮다.
    • WAS는 오류가 발생할 확률이 아주 높고, 장애가 자주 발생한다.
    • WAS는 DB와 상호작용 하기 때문에 DB에 문제가 생겨도 문제가 발생한다.

2️⃣ Servlet

: HTTP 프로토콜을 기반으로한 요청과 응답을 처리하는데 사용!
→ HttpServlet 클래스를 상속해 구현된다.

예를 들어, 회원가입 로직을 구현할 때 POST요청을 보내서 회원이 입력한 값을 전송하려는 상황이 있다고 해보자.
원래대로라면,

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을 활용하면 오직 "비즈니스 로직"만 실행하면 된다!! 나머지는 서블릿이 다 처리해준다!!! (개뀰)

Servlet 컨테이너

Servlet은 서블릿 컨테이너가 생성하고 관리한다.
-> WAS가 종료되면 서블릿도 함께 종료

  • 서블릿을 초기화, 생성, 관리, 호출, 종료하는 역할
    ➡️ 싱글톤으로 관리한다
  • 동시 요청에 대한 처리를 위해 Multi Thread를 지원한다.

✅ 싱글톤이란?
객체를 하나만 생성해서 그 인스턴스를 공유해 사용하는것.
특정 인스턴스를 여러개 생성하지 않아서 자원 낭비가 안되고, 상태를 일관되게 유지할 수 있다. (공유 변수 사용할 때 항상 주의해야함)

Multi Thread

Single Thread를 사용하면, 동시 요청이 왔을때 실행되는 요청 이외의 요청들은 그 전 요청이 끝날 때까지 무한 대기를 할 수 밖에 없다...
→ 멀티 스레드를 통해 해결가능!

요청이 들어올 때마다 스레드를 생성하고, 요청이 끝나면 스레드를 종료한다.

📌 장점

  • 동시 요청 처리 가능
  • 하나의 스레드에서 문제가 생겨도, 나머지 스레드는 정상 작동 가능

📌 단점

  • 스레드 생성에 제한이 없고, 비용도 많이 든다.
    너무 많이 생성하면 과부화 걸려서 서버가 죽어버릴 수도 있다 !
  • Context Switching 비용이 발생

Thread Pool

: 스레드는 Thread Pool이라는 곳에 보관하고 관리된다.
여기서 생성 사능한 스레드의 최대치를 관리하게 되는데, Tomcat은 최대 200개 설정되어있다(변경해서 사용 가능!)

→ 요청마다 스레드 생성 안해서 (미리 생성되어있어서) 비용 ↓ & 응답 속도 ↑
하지만, 최대 스레드 수를 너무 적거나 많이 설정하면 응답이 지연되거나 서버가 다운될 수 있다(성능 테스트를 통해 적정 스레드 수를 찾는 것이 중요)

3️⃣ SSR vs CSR

기능SSRCSR
초기 로딩 속도빠름 (초기 HTML이 완성된 상태로 전달되니까)느림 (javascript 로딩 후 렌더링)
갱신전체 페이지 새로고침부분 새로고침
SEO크롤링에 유리불리
서버 부하높음 (모든 요청을 서버가 함)낮음 (API호출로 데이터만 쑉)
ex블로그, 뉴스 등구글맵, 웹애플리케이션 등

🛒 정리

(1) 네트워크 통신은 HTTP로!
→ HTTP : 무상태 프로토콜 & 비연결성
(2) HTTP는 Restful하게 설계해야함 (최소 level2)
(3) Servlet은 자바에서 GOAT이다(요청 응답을 쉽게 받을 수 있다)
(4) Servlet Container는 서블릿 객체를 *싱글톤으로 관리
(5) WAS는 Multi Thread!

profile
림민지
@lim_128
이전 포스트

[JAVA] 키오스크 만들기 회고

다음 포스트

[SPRING] Annotation & Mapping

0개의 댓글