땅울림 썸머코딩 Server: Spring 6주차

김수환·2024년 8월 9일

: 프론트엔드의 요청을 받고, 응답을 전달하는 과정

웹브라우저는 도메인주소를 보고 해당 IP 주소로 요청을 보냅니다.
IP 주소에 해당하는 서버와 연결을 합니다.
사용자,보너스 옵션, 금액 을 폼데이터 형태로 body에 담아 해당 엔드포인트로 post 요청을 보냅니다.
서버의 디스패처 서블릿은 요청을 보고 컨트롤러를 찾습니다.
엔드포인트, http 메소드로 매핑되어 있는 컨트롤러 메소드가 호출됩니다.
금액과 보너스 옵션에 따라서 사용자 잔액이 증가합니다.
컨트롤러는 redirect url을 전송합니다.
프론트엔드는 응답을 받고 해당 url 로 redirect 됩니다.

HTTP

: HyperText Transfer Protocol

HTTP 로 전송하는 데이터

HTML, TEXT
IMAGE, 음성, 영상, 파일
JSON, XML (API)
거의 모든 형태의 데이터 전송 가능
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

HTTP 특징

클라이언트 - 서버 구조
무상태 프로토콜(스테이스리스) :
- 서버가 클라이언트의 상태를 저장하지 않음
- 장점: 서버 확장성 높음(스케일 아웃)
- 단점: 클라이언트가 추가 데이터 전송
비연결성 HTTP 메시지
- HTTP는 기본이 연결을 유지하지 않는 모델
- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이 하로 매우 작음
- 서버는 연결 유지X
- 최소한의 자원 유지
단순함, 확장 가능

HTTP Message

start-line 시작 라인
header 헤더
empty line 공백 라인 (CRLF)
message body

이름	요청 예시
start-line	GET /core/members/info?member_id=123 HTTP/1.1
header	Host: www.helloLandVibe.com
	...etc
empty line
message body	{요청메시지 바디에 값 있을수 있음}

이름	응답 예시
start-line	HTTP/1.1 200 OK
header	Content-Type: text/json;
	charset=UTF-8 Content-Length: 85
	Date: Mon, 12 Aug 2024 12:00:00 GMT
	...etc
empty line
message body	{
	"member_id": 123,
	"name": "땅울림",
	"balance": 50000,
	"status": "active"
	}

웹 서버(Web Server)와 WAS(Web Application Server)

웹 서버 (Web Server)

역할: 정적 리소스를 제공
- 정적 리소스: 변하지 않는 파일들
  ex. 미리 저장된 HTML, CSS, JavaScript, 이미지, 영상 파일 등
- 웹 서버는 HTTP(웹 프로토콜)를 기반으로 동작
- 클라이언트(사용자)가 요청한 정적 파일을 반환
예시:
- 사용자가 브라우저에서 www.helloLandVibe.com을 입력
- 웹 서버는 index.html 파일을 찾아서 클라이언트에게 전달
- 클라이언트(브라우저) 서버(웹 서버)
  → HTTP 요청
  ← HTTP 응답: index.html 파일

클라이언트(브라우저)		서버(웹 서버)
	→	HTTP 요청
	←	HTTP 응답: index.html 파일

WAS (Web Application Server)

역할: WAS는 동적 콘텐츠를 생성하고 처리
- 동적 콘텐츠: 사용자 요청에 따라 실시간으로 생성되는 데이터나 페이지를 의미
  ex. 로그인한 사용자 정보, 상품 검색 결과, 게시글 목록 등.
- WAS는 비즈니스 로직을 수행
- 데이터베이스와 상호작용하여 필요한 데이터를 생성
- HTML,JSON 등 으로 변환하여 클라이언트에 반환
예시:
- 사용자가 로그인 버튼을 클릭
- WAS는 사용자 이름과 비밀번호를 데이터베이스에서 확인
- 로그인 결과에 따라 환영 메시지 또는 오류 메시지를 반환
- 클라이언트(브라우저) 서버(WAS)
  → HTTP 요청: 로그인 정보
  ← HTTP 응답: 환영 메시지 또는 오류 메시지

클라이언트(브라우저)		서버(WAS)
	→	HTTP 요청: 로그인 정보
	←	HTTP 응답: 환영 메시지 또는 오류 메시지

웹 서버 vs WAS

웹 서버: 정적 파일을 제공하는 데 집중
WAS : 동적 콘텐츠를 생성하고, 비즈니스 로직을 처리하는 데 집중
웹 서버가 프로그램을 실행하기도, WAS 가 정적 리소스를 제공하기도
실제 웹 애플리케이션 환경에서는, 웹 서버와 WAS가 협력하여 정적 리소스와 동적 콘텐츠를 함께 제공

예시 그림 (개념도)

      ┌───────────┐       ┌────────────┐
      │ 클라이언트   │──────▶│웹 서버 (정적) │
      │           │       └────────────┘
      └───────────┘             │
                                ▼
                         ┌────────────┐
                         │  WAS (동적) │
                         └────────────┘

백엔드의 역할

Front End 가 사용자에게 필요한 데이터를 편하게 받을 수 있게 도와준다면,
Back End 는 사용자가 필요한 데이터를 안전하게 저장하고, 필요한 비즈니스 로직을 통해 가공한 후, 요청에 맞게 제공 할 수 있어야 한다.

Servlet

서블릿이란?

Java를 기반으로 웹 애플리케이션을 개발할 때 사용되는 서버측 컴포넌트
HTTP 요청을 처리하고 그에 대한 응답을 생성

역할: 클라이언트의 요청을 받아 비즈니스 로직을 처리
그 결과를 HTML, JSON 등의 형식의 응답으로 반환
주요 기능: request 파라미터 처리, 세션 관리, 응답 데이터 생성 등

응? 컨트롤러 아니야?

Controller

보통 MVC 패턴에서 사용되는 컴포넌트

클라이언트의 요청을 받아 처리한 후, Model을 통해 데이터를 처리, 뷰(View)를 통해 결과를 사용자에게 전달

Spring 프레임워크 : @Controller 어노테이션을 사용

Servlet VS Controller

서블릿:

더 낮은 레벨에서 동작

요청과 응답을 수동으로 처리

개발자가 모든 작업을 직접 처리해야 하므로, 코드가 복잡하다.

기능 확장이나 재사용이 제한적

컨트롤러:

서블릿을 기반으로 동작하지만, 더 높은 레벨의 추상화를 제공

프레임워크의 도움을 받아 개발이 더 편리

프레임워크가 많은 작업을 자동으로 처리

사실 서블릿이 전달 해주면 컨트롤러가 받는거임

DispatcherServlet

디스패처 서블릿은 스프링 MVC에서 중앙 컨트롤러 역할을 수행하는 서블릿

모든 HTTP 요청이 먼저 디스패처 서블릿으로 전달
디스패처 서블릿은 이 요청을 적절한 컨트롤러로 전달
응답을 처리하여 클라이언트에게 반환
해당 어플리케이션으로 들어오는 모든 요청을 핸들링하고, 공통 작업을 처리 - 개발자는 컨트롤러를 구현해두기만 하면 디스패처 서블릿이 알아서 적합한 컨트롤러로 위임을 해줌

서블릿 컨테이너

서블릿을 관리하고, 생명 주기를 관리하며, 요청을 서블릿으로 전달하고 그 결과를 클라이언트에게 반환하는 역할을 수행하는 서버 환경.

서블릿 객체의 생성, 초기화, 요청 처리, 소멸 등을 관리
HTTP 요청과 응답을 처리하는 데 필요한 여러 가지 기능을 제공

톰캣 (Tomcat)

Apache 재단에서 제공하는 오픈 소스 서블릿 컨테이너이자 WAS
자바 서블릿과 JSP(JavaServer Pages)를 실행할 수 있는 환경을 제공

Spring에는 이녀석이 내장되어 있음 😼

서블릿 컨테이너와 웹 서버의 기능을 모두 제공
JSP 페이지를 웹서버에 요청하면 이 페이지를 해석하고 서블릿으로 바꾸어 실행
Web Server에서 요청한 동적 페이지를 읽어 프로그램을 실행
그 결과를 다시 HTML로 재구성하여 Web Server에게 전달
정적 파일 제공과 동적 웹 애플리케이션 실행을 모두 지원
경량화된 웹 애플리케이션 서버
다양한 운영체제에서 실행 가능

HTTP 요청이 들어와?

WAS(톰캣)가 Request, Response 객체를 만들어서 서블릿 호출
개발자는 Request객체에서 요청 정보를 꺼내서 사용
개발자는 Response객체에 응답 정보를 입력
WAS(톰캣)가 Response 객체에 담아 있는 내용으로 HTTP 응답 정보 생성

서블릿 컨테이너는 서블릿 객체를 싱글톤으로 관리한다.

Client 가 요청할 때 마다 객체를 생성하는 것은 비효율 적이다.
최초 로딩 시점에 만들어서 재활용한다.
여러 Client가 동시에 같은 서블릿 객체에 접근할 수 있다.
공유 변수 사용에 주의 해야 한다.

동시 요청과 Thread Pool

Thread 란?

프로그램 내에서 작업을 처리하는 최소 단위

하나의 프로세스 내에서 여러 개의 쓰레드가 동시에 실행될 수 있음
각 쓰레드는 독립적으로 작업을 수행
웹 애플리케이션에서는 클라이언트의 요청을 처리하기 위해 서버가 여러 개의 쓰레드를 사용

단일 요청

다중 요청 - 단일 쓰레드

쓰레드가 요청 처리중 다른 요청이 들어오면 다른 요청은 쓰레드가 작업이 끝날 때 까지 기다려야한다.

Multi Thread

서버가 여러 클라이언트의 요청을 동시에 처리할 수 있다.
각 요청마다 별도의 쓰레드가 생성되어 작업을 수행
처리 속도가 증가하고, 대기 시간이 감소한다.

다중 요청 - 요청 마다 쓰레드 생성

각 요청이 동시에 처리될 수 있음
BUT, 쓰레드를 생성하는 것은 비싸다.즉, 오래 걸린다.
요청마다 쓰레드를 생성하면 응답이 오래걸린다.

Thread Pool

서버가 미리 일정 수의 쓰레드를 생성, 관리
각 요청에 대해 새로운 쓰레드를 생성하는 것이 아니라 쓰레드 풀에서 기존의 쓰레드를 할당받아 작업을 수행

새로운 쓰레드를 생성하는 비용 절감
자원 사용의 최적화
서버의 안정성 향상
많은 요청에 대한 효율적인 처리
톰캣은 기본 설정이 200개임 (변경 가능)

다중 요청 - Thread Pool 예시

톰캣은 멀티쓰레드를 지원한다.

멀티 쓰레드에 대한 부분은 대부분 WAS가 처리한다.
개발자는 멀티쓰레드 관련 코드를 신경 쓰지 않아도 된다.
멀티쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용하자.

⚠️ 주의 ⚠️
멀티쓰레드 관리와 트랜잭션은 다른 개념입니다. 혼동하지 않도록 주의해야 합니다.
멀티쓰레드 관리와 트랜잭션의 차이

멀티쓰레드 관리:
여러 쓰레드가 동시에 접근할 수 있는 변수에 대한 일관성 보장
메모리 내에서 여러 쓰레드가 동시에 접근할 수 있는 변수에 관한 문제

트랜잭션:
데이터베이스 작업에 대한 일관성, 무결성 보장
데이터베이스 작업에서 여러 작업이 하나의 단위로 묶여서 처리되는 것

두 사용자가 동시에 상품의 재고를 줄이는 요청을 했다?

WAS의 멀티쓰레드 처리:

두 사용자가 동시에 재고를 줄이려는 요청

WAS는 각각의 요청을 별도의 쓰레드에서 처리하며, 이때 각각의 쓰레드는 독립적으로 실행

멀티쓰레드 환경에서 WAS는 쓰레드 간의 데이터 충돌을 방지하기 위해, 공유 변수에 대한 접근 제어

개발자의 트랜잭션 관리:

각 쓰레드는 데이터베이스에서 재고 값을 조회, 이를 수정한 후 다시 저장 하려고 함

개발자는 이 과정에서 트랜잭션을 사용해, 두 쓰레드가 동일한 재고 값을 동시에 수정하지 않도록 해야함

트랜잭션이 적용된 작업이기 때문에, 한 쓰레드가 재고를 줄이는 작업을 완료하기 전까지 다른 쓰레드는 재고를 수정할 수 없습니다.

정적 리소스와 동적 리소스

정적 리소스

서버에 저장된 그대로 클라이언트에게 제공되는 리소스

클라이언트의 요청이 있을 때 서버에서 동일한 콘텐츠를 반환
서버의 부하가 상대적으로 낮음
변경 시 파일을 직접 수정
EX. HTML 파일, CSS 파일, JavaScript 파일, 이미지 등

동적 리소스

클라이언트의 요청에 따라 서버에서 실시간으로 생성되거나 조정되는 리소스

요청마다 다른 콘텐츠가 반환
사용자 또는 요청에 따라 달라지는 내용 제공
서버의 부하가 상대적으로 높을 수 있음
EX. 로그인된 사용자의 개인 정보, 맞춤형 대시보드

인하대학교 컴퓨터공학과/공지사항: 모든 학생에게 일괄적인 HTML 페이지 제공 (정적 리소스)
iClass/수강정보: 학생별, 학기별로 수강하는 수업에 대한 정보 제공 (동적 리소스)

서버사이드 랜더링과 클라이언트 사이드 랜더링

SSR (Server-Side Rendering)

서버사이드 랜더링은 서버에서 HTML을 생성하여 클라이언트에게 제공하는 방식
클라이언트는 서버로부터 완성된 HTML을 받아 브라우저에 표시

장점:

초기 로드 속도가 빠름 (완성된 HTML을 클라이언트에 전달)

단점:

서버의 부하가 증가할 수 있음
페이지가 서버 요청에 의존적임

인하대학교 공식 홈페이지

사용자가 인하대학교 공식 홈페이지의 공지사항 페이지를 요청하면, 서버는 공지사항 HTML을 생성하여 클라이언트에게 전달합
클라이언트는 서버에서 전달된 HTML을 받아 즉시 렌더링

CSR (Client-Side Rendering)

클라이언트 사이드 랜더링은 클라이언트가 브라우저에서 JavaScript를 실행하여 웹 페이지를 생성
서버는 주로 데이터를 제공하고, 클라이언트는 그 데이터를 사용하여 동적으로 콘텐츠를 렌더링

장점:

페이지 간 전환이 빠르고 매끄러움 (JavaScript가 클라이언트에서 렌더링)
사용자 인터랙션이 원활함

단점:

초기 로드 시간이 길어질 수 있음 (JavaScript와 데이터 로드가 필요)

iClass

사용자가 iClass에 로그인하면, 서버는 응답 데이터를 클라이언트에게 전달
클라이언트의 브라우저는 이 데이터로 페이지를 동적으로 렌더링

DispatcherServlet

디스패처 서블릿은 스프링 MVC에서 중앙 컨트롤러 역할을 수행하는 서블릿

모든 HTTP 요청이 먼저 디스패처 서블릿으로 전달
디스패처 서블릿은 이 요청을 적절한 컨트롤러로 전달
응답을 처리하여 클라이언트에게 반환

about Static Resource

모든 요청을 처리하다보니 정적 리소스에 대한 요청마저 모두 가로챔
정적 리소스를 불러오지 못하는 상황도 발생하곤 했음

정적 자원 요청과 애플리케이션 요청을 분리

/apps 의 URL로 접근하면 Dispatcher Servlet이 담당
/resources 의 URL로 접근하면 정적 리소스 반환

모든 요청에 대해서 저런 URL을 붙여주어야 하므로 직관적인 설계가 될 수 없음

애플리케이션 요청을 탐색하고 없으면 정적 자원 요청으로 처리

요청에 대한 컨트롤러를 탐색
2차적으로 설정된 자원(Resource) 경로를 탐색하여 자원을 탐색

Dispatcher Servlet 동작구조

클라이언트의 요청을 디스패처 서블릿이 받음
핸들러 매핑이 요청 정보를 통해 요청을 위임할 컨트롤러 검색
요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아서 전달
핸들러 어댑터가 컨트롤러로 요청을 위임
비지니스 로직 처리
컨트롤러가 반환값 반환
핸들러 어댑터가 반환값 처리
서버의 응답을 클라이언트로 반환

Controller 와 HTTP

결국 Spring 개발자가 요청을 최초에 받는 지점은 Controller.

HTTP 메소드 종류들

GET: 서버에서 정보를 요청. 주로 데이터 조회에 사용
POST: 서버에 데이터를 전송. 새로운 리소스를 생성하거나 기존 리소스를 수정
PUT: 서버의 리소스를 업데이트 일반적으로 전체 리소스를 교체하는 데 사용
DELETE: 서버에서 리소스를 삭제
PATCH: 리소스의 일부를 수정

엔드포인트에 해당하는 Controller메소드를 매핑하는 방법

@RequestMapping

@RequestMapping은 Spring에서 HTTP 요청을 특정 메소드에 매핑하기 위해 사용
URL 패턴, HTTP 메소드, 파라미터 등 다양한 속성을 지정

@RequestMapping(value = "/members/new", method = RequestMethod.GET)
public String joinForm() {
    return "joinform";
}

HTTP메소드와 Mapping

@GetMapping: HTTP GET 요청 처리
@PostMapping: HTTP POST 요청 처리
@PutMapping: HTTP PUT 요청 처리
@DeleteMapping: HTTP DELETE 요청 처리
@PatchMapping: HTTP PATCH 요청 처리

@GetMapping("/members/new")
public String joinForm() {
    return "joinform";
}

@PostMapping("/members/new")
public String handlePostRequest(@RequestBody MyRequestBody requestBody) {
    // 처리 로직
    return "redirect:/";
}

HTTP 요청의 값이 들어 있다면?

path variable

PathVariable은 URL 경로의 일부로 전달된 값을 메소드의 파라미터로 사용
URL 템플릿에서 경로 변수와 메소드 파라미터를 연결
@PathVariable 로 사용

GET /users/123

@GetMapping("/users/{userId}")
public String getUser(@PathVariable String userId) {
    // userId를 사용한 처리 로직
    return "view name";
}

request parameter

쿼리 스트링으로 전달된 파라미터를 메소드의 파라미터로 사용
URL의 ? 뒤에 붙는 파라미터들
@RequestParam 로 사용

GET /search?query=땅울림

@GetMapping("/search")
public String search(@RequestParam String query) {
    // query 파라미터를 사용한 처리 로직
    return "searchResults";
}

form data

HTML 폼을 통해 POST 요청으로 전달된 데이터
@ModelAttribute를 사용하여 폼 데이터를 객체로 사용

POST /submit
name=이승철&email=soohwanZZANG@naver.com

@PostMapping("/submit")
public String submitForm(@ModelAttribute MyFormData formData) {
    // formData를 사용한 처리 로직
    return "resultPage";
}

Request Body (dto)

JSON 또는 XML 형식으로 전달된 데이터를 DTO (Data Transfer Object) 로 매핑
주로 POST 또는 PUT 요청에서 사용

POST /submit HTTP/1.1

{
  "id": 1,
  "name": "이승철",
  "email": "soohwanZZANG@naver.com"
}

@RequestBody

@PostMapping("/submit")
public String submitForm(@RequestBody requestBody) {
    // formData를 사용한 처리 로직
    return "resultPage";
}

응답은?

그동안은 view의 경로명을 return

여러 방법이 있지만 하나만 소개

Response Body

직접 http response body를 만드는 방식

@GetMapping("/users/{userId}")
public ResponseEntity<MemberDTO> getUser(
					@PathVariable String userId) {
    // userId를 사용한 처리 로직
    MemberDTO memberDTO = makeDTO();
    return ResponseEntity.ok(memberDTO);
}

김수환이 한 과제

시나리오 추가 : 테스트 데이터가 아니라 실제 서비스 데이터라면?

1. 웹 브라우저의 DNS 조회 및 서버 연결

도메인 주소 해석
웹 브라우저는 DNS(Domain Name System) 조회를 수행

(사용자가 웹 브라우저에 입력한 도메인 주소를 해석)

이 과정에서 도메인 이름을 기반으로 해당 서버의 IP 주소를 검색
- 로컬 캐시: 브라우저 내부의 캐시에서 최근 방문했던 주소의 IP 먼저 확인
- 운영 체제 캐시: 운영 체제에 저장된 DNS 캐시를 확인
- 라우터의 로컬 네트워크 캐시: 라우터의 캐시 통해 IP 주소를 확인합
- ISP의 DNS 캐시: 인터넷 서비스 제공업체(ISP)의 DNS 서버에 저장된 캐시를 확인
- 상위 DNS 서버로 요청 전달: 서버는 최상위 DNS 서버인 루트 DNS 서버까지 재귀적 DNS 조회나 권한 있는 DNS 서버에 요청을 전달한다.
TCP 연결 설정
DNS 조회가 완료되면, 브라우저는 해당 IP 주소로 웹 서버와의 연결을 시도한다.
- TCP(Transmission Control Protocol) 연결 설정
- 3-way handshake
  TCP 연결이 설정되면, HTTP 프로토콜을 통해 클라이언트(웹 브라우저)와 서버 간의 통신이 시작된다.
HTTP 요청 전송
브라우저는 설정된 TCP 연결을 통해 HTTP 요청을 서버로 전송
사용자가 특정 웹 페이지를 요청 -> 웹 서버(localhost)는 해당 페이지에 대한 HTML 파일을 클라이언트에 응답
이후 브라우저는 이 HTML 파일을 렌더링

2. 클라이언트 요청

사용자가 "입금" 버튼을 클릭
사용자, 보너스 옵션, 입금 금액 등의 데이터를 form-data 형태로 HTTP POST 요청의 body에 담아 서버로 전송

POST /deposit HTTP/1.1 Host: www.example.com

이름=땅울림&보너스선택=정률보너스&입금할_금액=10000

3. 서버에서 요청 처리

1. Dispatcher Servlet이 요청을 받아 Controller 로 위임

클라이언트의 요청을 Dispatcher Servlet이 받음

웹 애플리케이션에서 클라이언트의 모든 HTTP 요청은 가장 먼저 Dispatcher Servlet이 받음(inSpring)
서블릿은 애플리케이션의 프론트 컨트롤러로 작동
들어오는 요청을 처리하기 위한 모든 준비 작업을 수행

핸들러 매핑이 요청 정보를 통해 요청을 위임할 컨트롤러 검색

Dispatcher Servlet은 요청의 URL, HTTP 메소드, 파라미터 등을 분석
적절한 컨트롤러를 찾기 위해 핸들러 매핑(Handler Mapping) 이라는 컴포넌트 사용
핸들러 매핑은 URL 패턴과 일치하는 컨트롤러를 검색

요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아서 전달

컨트롤러가 결정되면, Dispatcher Servlet은 해당 컨트롤러와 상호작용할 수 있는 핸들러 어댑터(Handler Adapter) 를 검색

핸들러 어댑터가 컨트롤러로 요청을 위임

핸들러 어댑터는 요청을 받아서 컨트롤러의 적절한 메소드를 호출
요청된 데이터는 컨트롤러 메소드의 파라미터로 바인딩
만약 파라미터에 대한 유효성 검사가 필요한 경우, 이 과정에서 수행

2. 비즈니스 로직 수행

컨트롤러는 요청된 작업을 처리하기 위해 비즈니스 로직을 수행
일반적으로 service 컴포넌트에 비드니스 로직 위임

비즈니스 로직 처리

서비스는 사용자 정보를 데이터베이스에서 조회하여 해당 사용자 인스턴스를 가져옴
이후 요청된 금액과 보너스 옵션에 따라 사용자의 잔액을 증가
변경된 정보를 다시 데이터베이스에 저장

트랜잭션 처리

동일한 사용자에게 동시에 보너스나 입금 처리가 발생할 수 있음

트랜잭션 처리를 통해 두 개의 요청이 동시에 처리되더라도 데이터의 일관성을 보장
두 사용자가 동시에 동일한 사용자 정보를 수정하려고 할때, 트랜잭션 처리가 올바르게 해야 데이터 충돌을 방지함.

3. 응답 반환

서버는 클라이언트에게 리다이렉트 응답을 반환
클라이언트가 특정 뷰로 다시 요청을 보내도록 안내
응답이 단순 경로가 아니라면?

[예시]
```
{
  "message": "입금이 성공적으로 처리되었습니다.",
  "name": "땅울림",
  "잔액": 20000
}
```
클라이언트에 적당한 반환값을 반환한다.

핸들러 어댑터가 반환값 처리

핸들러 어댑터는 컨트롤러에서 반환 값을 받아 처리

만약 반환값이 뷰 이름이라면(redirect view), 적절한 뷰 리졸버(View Resolver)를 통해 HTML이나 JSP로 렌더링
JSON 같은 데이터는 바로 응답으로 사용

8. 서버의 응답을 클라이언트로 반환

Dispatcher Servlet은 최종적으로 핸들러 어댑터가 처리한 결과를 클라이언트에게 반환

응답은 HTTP 응답 형태로 클라이언트에게 전달
성공적인 경우 (200)
클라이언트는 렌더링 된 HTML이나 JSP를 응답 받음.
JSON 인 경우 바로 받음. (respons body 로)

김수환

hello human

이전 포스트

땅울림 썸머 코딩 서버 스프링 3주차

다음 포스트

땅울림 썸머코딩 Server: Spring 6주차

: 프론트엔드의 요청을 받고, 응답을 전달하는 과정

목차

지난 과제 간단 정리

HTTP

HTTP 로 전송하는 데이터

HTTP 특징

HTTP Message

웹 서버(Web Server)와 WAS(Web Application Server)

웹 서버 (Web Server)

WAS (Web Application Server)

웹 서버 vs WAS

예시 그림 (개념도)

백엔드의 역할

Servlet

서블릿이란?

응? 컨트롤러 아니야?

Controller

Servlet VS Controller

DispatcherServlet

서블릿 컨테이너

톰캣 (Tomcat)

HTTP 요청이 들어와?

서블릿 컨테이너는 서블릿 객체를 싱글톤으로 관리한다.

동시 요청과 Thread Pool

Thread 란?

단일 요청

다중 요청 - 단일 쓰레드

Multi Thread

다중 요청 - 요청 마다 쓰레드 생성

Thread Pool

다중 요청 - Thread Pool 예시

톰캣은 멀티쓰레드를 지원한다.

두 사용자가 동시에 상품의 재고를 줄이는 요청을 했다?

WAS의 멀티쓰레드 처리:

개발자의 트랜잭션 관리:

정적 리소스와 동적 리소스

정적 리소스

동적 리소스

서버사이드 랜더링과 클라이언트 사이드 랜더링

SSR (Server-Side Rendering)

인하대학교 공식 홈페이지

CSR (Client-Side Rendering)

iClass

DispatcherServlet

about Static Resource

Dispatcher Servlet 동작구조

Controller 와 HTTP

HTTP 메소드 종류들

엔드포인트에 해당하는 Controller메소드를 매핑하는 방법

@RequestMapping

HTTP메소드와 Mapping

HTTP 요청의 값이 들어 있다면?

path variable

request parameter

form data

Request Body (dto)

응답은?

Response Body

김수환이 한 과제

1. 웹 브라우저의 DNS 조회 및 서버 연결

2. 클라이언트 요청

3. 서버에서 요청 처리

1. Dispatcher Servlet이 요청을 받아 Controller 로 위임

클라이언트의 요청을 Dispatcher Servlet이 받음

핸들러 매핑이 요청 정보를 통해 요청을 위임할 컨트롤러 검색

요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아서 전달

핸들러 어댑터가 컨트롤러로 요청을 위임

2. 비즈니스 로직 수행

비즈니스 로직 처리

트랜잭션 처리

3. 응답 반환

응답이 단순 경로가 아니라면?

핸들러 어댑터가 반환값 처리

8. 서버의 응답을 클라이언트로 반환

땅울림 썸머 코딩 서버 스프링 3주차

[번외] 넷플릭스가 자체 CDN을 구축한 이유

0개의 댓글