SpringBoot Part 3-1

 

1. 웹 

WEB이란?

 

World Wide Web의 줄임말로, 인터넷상에서 정보를 공유하고 검색할 수 있는 하이퍼텍스트 시스템이다.

웹페이지, 웹사이트, 웹앱 등 다양한 형태의 디지털 콘텐츠를 포함하며, 이러한 콘텐츠는 웹 브라우저를 통해 접근하고 검색할 수 있다.

 

WEB의 구성

 

 

URI (Uniform Resource Identifier)

리소스를 고유하게 식별하기 위해 통합된 표기법

 

URL (Uniform Resource Locator)과 URN (Uniform Resource Name)의 개념을 포함한다.

URL은 리소스의 위치를 지정하고, URN은 리소스의 이름을 지정한다. 

 

예시

http://oasis@www.blog.com:8080/search/1?debug=true&limit=10

URI Scheme: http -> URI 프로토콜 지정

사용자: oasis

호스트명: www.blog.com -> URI에서 접속하려는 서버 주소

포트번호: 8080

패스: /search/1 -> 서버에서 요청된 리소스 경로

쿼리 파라미터(쿼리 문자열): debug=true&limit=10 -> URI에 추가적인 매개변수 전달

 

상대경로에서 절대 경로로의 변환

 

상대경로: 현재 작업 디렉터리를 기준으로 파일이나 디렉토리의 위치를 표현하는 방식 

절대경로: 파일이나 디렉토리의 위치를 루트 디렉토리부터 전체 경로로 표현하는 방식

 

📌 시작점은 /foo/bar

상대 경로	절대 경로
hoge	/foo/bar/hoge
hoge/fuga	/foo/bar/hoge/fuga
./hoge	/foo/bar/hoge
../hoge	/foo/hoge
../hoge/fuga	/foo/hoge/fuga
../../foge	/foge

./: 현재 디렉토리

../: 상위 디렉터리

 

URI에서 사용할 수 있는 문자

 

알파벳 (대소문자): A-Z, a-z
숫자: 0-9
일부 특수문자: - (하이픈), _ (밑줄), . (마침표), ~ (물결표시)
예약 문자: ! $ & ' ( ) * + , ; = : @
URI 이스케이프 문자: %를 사용한 이스케이프 시퀀스 (%HH 형식)

---

HTTP (Hypertext Transfer Protocol)

웹 상에서 클라이언트와 서버 간에 데이터를 주고받기 위한 프로토콜

 

클라이언트의 요청과 서버의 응답으로 구성되며, 웹 브라우저가 웹 서버에게 웹 페이지나 리소스를 요청할 때 사용된다.

HTTP는 보안을 위한 HTTPS로 확장될 수도 있다.

 

클라이언트(Client): 웹 브라우저, 모바일 앱 또는 다른 HTTP를 지원하는 애플리케이션 등의 엔드 유저 기기

- URL을 사용하여 요청을 서버로 보낸다.

- 호스트 서버로부터 받은 HTML문서를 렌더링 하여 사용자에게 보여준다.

호스트 서버(Host Server): 웹 리소스를 제공하는 컴퓨터 시스템 또는 서버

- 클라이언트의 요청을 받아들이고, 해당 요청에 따라 적절한 응답(ex. HTML)을 생성하여 클라이언트에게 반환한다.

요청(Request): 클라이언트가 호스트 서버로 보내는 동작

- 보통 URL을 통해 목적 리소스를 지정하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 요청의 종류를 정의한다.

* 목적 리소스: HTTP요청을 통해 접근하려는 대상 리소스

응답(Response): 호스트 서버가 클라이언트에게 보내는 결과

- 클라이언트의 요청에 따라 생성되며, HTTP 상태 코드(200 OK, 404 Not Found 등)와 함께 응답 헤더 및 본문 데이터로 구성된다.

 

HTTP의 주요 특징

 

- TCP/IP 기반

- 요청/응답형 프로토콜

- 동기형 프로토콜 -> 클라이언트는 서버에 요청을 보내고, 해당 요청이 처리되어 응답이 도착할 때까지 대기한다.

- Stateless ->  각각의 요청이 독립적으로 처리되고, 서버는 클라이언트의 이전 상태를 저장하지 않는다.

* 이전 상태를 유지하기 위한 방법: 쿠키, 토큰

 

 

HTTP Message Format

 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

보통 Header와 Body로 구성되어있다고 한다.

 

📢 HTTP 헤더 종류

Request Headers: 클라이언트가 서버에게 요청을 보낼 때 요청에 관한 부가적인 정보 전달

Response Headers: 특정 응답에 대한 부가적인 정보 전달

General Headers: 요청과 응답 모두에 적용되는 헤더, 일반적 메시지 속성에 관련된 정보 전달

Representation Headers: 응답의 표현과 관련된 정보 전달

 

👆 Request Header

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

👆 Response Header

https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

HTTP Method

 

메서드	의미
GET	리소스 취득
POST	리소스의 작성, 리소스 데이터 추가, 기타 처
PUT	리소스 갱신, 리소스 작성
DELETE	리소스 삭제
HEAD	리소스의 헤더 취득
OPTIONS	리소스가 지원하는 메서드의 취득
TRACE	자기 자신으로 요청된 메시지를 반환하여 테스트
CONNECT	프록시 동작을 통해 터널 접속 설정

 

HTTP 메서드와 CRUD

 

CRUD명	의미	메서드
Create	작성	POST/PUT
Read	읽기	GET
Update	갱신	PUT
Delete	삭제	DELETE

---

HTML (Hypertext Markup Language)

웹 페이지를 작성하기 위한 마크업 언어

 

웹 페이지의 구조, 내용, 서식을 정의하기 위해 사용되며, 웹 브라우저는 HTML 문서를 해석하여 웹 페이지를 표시한다.

웹의 기본적인 구성 요소로, 텍스트, 이미지, 링크, 테이블 등 다양한 요소를 포함할 수 있다.

---

웹의 기술적 특징 2가지

 

👆 Hypermedia System (하이퍼미디어 시스템)

 

- 웹을 구성하는 리소스들이 하이퍼링크(Hyperlink)를 통해 서로 연결되어 있고, 다양한 미디어 타입의 리소스를 포함하고 있다.

- 정보의 구조와 관계를 표현하고, 사용자가 리소스 사이를 탐색하며 상호작용할 수 있도록 한다.

 

👆 Distributed System (분산 시스템)

 

- 웹은 매우 큰 규모의 네트워크이며, 수많은 사용자와 리소스가 동시에 존재하고 상호작용한다.

- 웹은 분산 시스템의 기술과 아키텍처를 활용하여 확장 가능한 서버 구조, 네트워크 통신 및 분산 데이터베이스 등을 구성한다.

-  웹은 많은 수의 사용자에 대한 처리를 수행하고 대규모 데이터를 관리할 수 있다.

---

2. Web Application

Web Application Architecture

 

https://litslink.com/blog/web-application-architecture

 

전체 흐름

https://litslink.com/blog/web-application-architecture (firehouse오타 -> firehose)

 

1. DNS(Domain Name System)

- 도메인 이름과 IP 주소 간의 매핑을 담당하는 시스템

- 사용자가 도메인 이름을 입력하면 DNS는 해당 도메인의 IP 주소를 찾아서 사용자의 요청을 해당 IP 주소로 전달한다.

- 도메인 이름을 IP 주소로 변환하여 인터넷에서 특정 서버를 찾는 데 사용된다.

2. 로드 밸런서(Load Balancer)

- 주로 수평적 확장을 다룬다.

- 여러 대의 서버 사이에 들어오는 트래픽을 균형 있게 분산시키는 역할을 한다.

- 일반적으로 웹 애플리케이션 서버는 서로를 미러링 하는 여러 개의 복사본 형태로 존재하며, 각 서버는 동일한 방식으로 요청을 처리하고 로드 밸런서가 작업을 분산시킴으로써 과부하를 방지한다.

3. 웹 애플리케이션 서버(Web App Servers)
- 사용자의 요청을 처리하고 해당 요청에 대한 응답을 생성하여 클라이언트에게 반환한다.

- 이를 수행하기 위해 일반적으로 데이터베이스, 캐시 서버, 작업 큐 등과 같은 백엔드 인프라를 참조한다.

- 로드 밸런서에 연결된 최소한 두 개의 서버가 사용자의 요청을 처리하는 역할을 한다.

4. 데이터베이스(Databases)
- 구성, 추가, 검색, 업데이트, 삭제 및 연산 수행을 위한 도구를 제공한다.

- 대부분의 경우, 웹 애플리케이션 서버는 직접 작업 서버와 상호작용한다.

5. 캐싱 서비스(Caching Service)
- 데이터의 저장과 검색을 가능하게 하는 저장소를 제공한다.

- 사용자가 서버에서 일부 정보를 가져올 때, 이 작업의 결과는 캐시로 저장된다. 따라서 이후의 요청은 더 빠르게 처리된다.

- 이전 결과를 참조하여 연산을 훨씬 빠르게 수행할 수 있게 해 준다. 

 

+) 해당 서비스가 효과적인 경우
- 연산이 느린 경우
- 연산이 여러 번 발생할 가능성이 있는 경우
- 특정 요청에 대한 결과가 동일한 경우

6a. 작업 큐(Job Queue, 선택 사항)
- 작업을 일시적으로 저장하고 순차적으로 처리한다.

- 비동기적으로 동작된다.

- 오랜 시간이 걸리거나 높은 리소스를 요구하는 즉시 처리하기 어려운 작업일 경우, 작업을 작업 큐에 추가하고 가능한 상황이 오면 작업을 처리한다.

 

6b. 작업 서버(Job servers)

- 웹 애플리케이션의 특정 작업을 처리하기 위해 사용되는 서버입니다.

- 웹 애플리케이션의 특정 작업을 담당하며, 웹 애플리케이션 서버와 함께 작동하여 전체 애플리케이션의 기능을 구현한다.

- ex) 데이터베이스 서버, 캐시 서버, 외부 API 서버

7. 전체 텍스트 검색 서비스(Full-Text Search Service, 선택 사항)

- 텍스트 기반의 데이터에서 효과적인 검색을 제공하는 서비스
- 많은 웹 애플리케이션은 텍스트 검색 기능 또는 요청을 지원하고 가장 관련성 높은 결과를 사용자에게 전송한다. 이를 더 효과적으로 처리하기 위해 대량의 텍스트 데이터를 색인화하고, 검색어에 대해 빠르게 매칭되는 결과를 반환한다.

8. 서비스(Services)
- 웹 애플리케이션이 특정 수준에 도달하면 별도의 앱 형태로 서비스가 생성된다.

- 웹 애플리케이션과 다른 서비스 간에 상호작용이 이루어진다.

9c. 데이터 웨어하우스(Data Warehouse)

 

- 여러 소스에서 추출한 데이터를 통합하고 저장하여 분석과 의사 결정에 활용하는 데이터 저장 및 관리 시스템
- 주로 비즈니스 인텔리전스와 데이터 분석에 사용되며, 대규모의 데이터를 저장하고 정형화하여 사용자에게 쉽게 접근 가능하도록 한다.

 

대부분의의 애플리케이션은 데이터 수집, 저장 및 분석과 같은 데이터 작업을 포함한다.

이러한 과정은 세 가지 단계로 이루어진다.

1) 데이터는 데이터의 흡수와 처리를 위한 스트리밍 인터페이스를 제공하는 Data "firehose"로 전송된다.
2) 가공된 원본 데이터와 추가 데이터는 클라우드 스토리지로 전송된다.
3) 가공된 데이터와 추가 데이터는 데이터 웨어하우스로 전송된다.

 

* 비즈니스 인텔리전스(Business Intelligence, BI): 조직이 내부 및 외부 데이터를 수집, 분석하여 의사 결정에 도움을 주는 프로세스와 도구

 

10. Cloud Storage

- 인터넷을 통해 데이터를 저장, 관리 및 백업하는 서비스

- 클라우드 기반의 데이터 센터에 데이터를 저장하며, 사용자는 인터넷을 통해 언제든지 필요한 데이터에 액세스 할 수 있다.

11. CDN(Content Delivery Network)
- 전 세계적으로 분산된 서버 네트워크.

- HTML 파일, CSS 파일, JavaScript 파일 및 이미지를 전송한다. (원래는 웹서버에서 제공)

- 전 세계에 분산된 여러 서버를 가지고 있으며, 이러한 서버는 콘텐츠의 복사본을 저장하고 유지한다.

- CDN은 사용자의 지리적 위치를 고려하여 가장 가까운 서버에서 콘텐츠를 제공함으로써 지연을 최소화한다.
- 웹 콘텐츠를 최종 사용자에게 빠르고 효율적으로 제공하기 위해 사용된다.

---

3. Servlet

Web Server, Web Application Server

 

👆 Web Server

https://mossgreen.github.io/Servlet-Containers-and-Spring-Framework/

클라이언트로부터 HTTP 요청을 받아들이고, 해당 요청에 대한 응답으로 웹 페이지, 파일, 데이터 등을 제공하는 소프트웨어나 시스템

 

- 인터넷상에서 웹 페이지를 호스팅 하고, 웹 애플리케이션을 실행하기 위해 사용된다.
- HTTP 프로토콜을 사용하여 클라이언트와 통신하며, 주로 HTML, CSS, JavaScript, 이미지, 동영상 등의 정적인 웹 콘텐츠를 제공한다.

 

📌 기능

1. 정적인 콘텐츠 제공

WAS를 거치지 않고 바로 자원을 제공한다.

 

2. 동적인 콘텐츠 제공을 위한 요청 전달

클라이언트의 요청(Request)을 WAS에 보내고, WAS가 처리한 결과를 클라이언트에게 전달(응답, Response)한다.
클라이언트는 일반적으로 웹 브라우저를 의미한다.

 

📌 예시

Apache Server, Nginx

 

 

👆 Web Application Server (WAS)

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

DB 조회나 다양한 로직 처리를 요구하는 동적인 콘텐츠를 제공하기 위해 만들어진 Application Server

 

- 웹 컨테이너, 서블릿 컨테이너라고 불린다.

 

📌 기능

1. 웹 애플리케이션 실행 환경과 DB 접속 기능 제공

서블릿 컨테이너와 JSP 컨테이너를 포함하여 웹 애플리케이션의 실행을 지원한다.

서블릿 컨테이너는 서블릿의 생명주기 관리와 HTTP 요청 처리를 담당하고, JSP 컨테이너는 JSP 페이지의 실행과 동적인 HTML 생성을 처리한다.

2. 여러 개의 트랜잭션(논리적인 작업 단위) 관리 기능

트랜잭션의 시작, 커밋(확정), 롤백(취소)과 같은 관리 작업을 수행하여 데이터의 일관성과 안전성을 유지다

3. 업무를 처리하는 비즈니스 로직 수행
비즈니스 로직을 처리하기 위해 실행 환경을 제공하고, 데이터베이스와의 연결을 통해 데이터를 조작하고 처리 결과를 반환한다.

비즈니스 로직의 수행은 웹 애플리케이션의 요청에 따라 이루어진다.

 

📌 예시

Tomcat, Jeus

 

http://setgetweb.com/p/WAS9/ae/was3532.html

Web Server를 Client와 소통하는 앞단에 배치하여 빠르게 정적 콘텐츠를 처리한다. (노출되는 데이터)

그 뒤에 WAS를 배치하여 DB와 연결된 동적 콘텐츠를 처리한다. (노출되지 않는 데이터)

=> WAS가 실제 Web Server를 포함하는 것이 아니라 웹 서버와 협업하며 기능을 제공하거나 웹 서버 기능을 수행하는 플러그인, 모듈 등을 포함하여 사용한다는 의미이다.

 

Servlet이란?

 

Java 언어를 기반으로 웹 애플리케이션을 개발하기 위한 서버 측 컴포넌트

 

https://codeburst.io/understanding-java-servlet-architecture-b74f5ea64bf4

- 웹 컨테이너에 존재하며, 클라이언트의 요청을 받아들이고, 처리한 후에 응답을 생성하여 클라이언트에게 전송한다.

 

MVC Pattern in Servlet

 

Model - 모델은 자바 객체 또는 Pojo로 데이터를 담고 있다.
View - 모델이 담고 있는 데이터를 시각적으로 보여주는 역할을 한다. (JSP)
Controller - 모델과 뷰를 연결하기 위한 매개체입니다. 사용자의 입력/요청을 받아 모델의 상태를 변경해 주고 그에 따른 뷰를 업데이트한다. (Servlet)

 

Servlet의 Life Cycle

 

https://gmlwjd9405.github.io/2018/10/27/webserver-vs-was.html

 

1. Web Server는 웹 브라우저 클라이언트로부터 HTTP 요청을 받는다.
2. Web Server는 클라이언트의 요청(Request)을 WAS에 보낸다.
3. WAS는 관련된 Servlet을 메모리에 올린다.
4. WAS는 web.xml을 참조하여 해당 Servlet에 대한 Thread를 생성한다. (Thread Pool 이용)

-> 매 요청은 별개의 스레드에서 동작한다. 
5. HttpServletRequest와 HttpServletResponse 객체를 생성하여 Servlet에 전달한다.
    5-1. Thread는 Servlet의 service() 메서드를 호출한다. (매번 새로운 Servlet 객체가 만들어지는 것 X)
    5-2. service() 메서드는 요청에 맞게 doGet() 또는 doPost() 메서드를 호출한다.
    - protected doGet(HttpServletRequest request, HttpServletResponse response)
6. doGet() 또는 doPost() 메서드는 인자에 맞게 생성된 적절한 동적 페이지를 Response 객체에 담아 WAS에 전달한다.
7. WAS는 Response 객체를 HttpResponse 형태로 바꾸어 Web Server에 전달한다.
8. 생성된 Thread를 종료하고, HttpServletRequest와 HttpServletResponse 객체를 제거한다.

SpringBoot에서 Servlet을 설정하는 방법

 

👆 web.xml 사용

 

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
         http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
    <servlet>
        <servlet-name>comingsoon</servlet-name>
        <servlet-class>mysite.server.ComingSoonServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>comingsoon</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
</web-app>

src/main/webapp/ 디렉터리에 web.xml파일을 추가하여, 필요한 Servlet, Filter, Listener 등을 설정한다.

 

👆 어노테이션 사용

 

@WebServlet, @WebFilter, @WebListener 등의 어노테이션을 사용하여 Servlet, Filter, Listener를 설정할 수 있다.

해당 어노테이션을 사용하여 Servlet 클래스에 직접 어노테이션을 추가한다.

@WebServlet(value = "/*", loadOnStartup = 1)
public class TestServlet extends HttpServlet {
    ....
}

 

👆WebApplicationInitializer 사용

 

public class KdtWebApplicationInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext servletContext) throws ServletException {
        ServletRegistration.Dynamic servletRegistration = servletContext.addServlet("test", new TestServlet());
        servletRegistration.addMapping("/*");
        servletRegistration.setLoadOnStartup(1);
    }
}