WAS(Web Application Server)
인터넷 상에서 HTTP 프로토콜을 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어로 주로 동적 서버 컨텐츠를 수행한다. 따라서 사용자의 다양한 요구에 맞춰 웹 서비스를 제공할 수 있다.
*대표적인 웹 애플리케이션 서버: Tomcat
WAS는 웹 서버와 웹 컨테이너가 합쳐진 형태로, 웹 서버 단독으로는 처리할 수 없는 데이터베이스의 조회나 다양한 로직 처리가 필요한 동적 컨텐츠를 제공한다. WAS는 JSP, Servlet 구동환경을 제공해주기 때문에 웹 컨테이너 or 서블릿 컨테이너라고도 불린다.
WS(Web Server)
웹 브라우저 클라이언트로부터 HTTP 요청을 받아 웹페이지를 반환하는 컴퓨터 프로그램
*대표적인 웹 서버: Apache
웹 서버는 클라이언트가 웹 브라우저에서 어떤 페이지 요청을 하면 웹 서버에서 요청을 받아 정적 컨텐츠(HTML 문서, CSS, JavaScript, 이미지 등 즉시 응답 가능한 컨텐츠)를 제공하는 서버이다.
또, 웹 서버가 동적 컨텐츠 요청을 받았을 때 WAS에게 해당 요청을 넘겨 WAS에서 처리한 결과를 클라이언트에게 전달해주는 역할도 한다.

웹 서버는 클라이언트가 HTTP 요청을 보내면 웹 서버에서 요청에 따른 정적 컨텐츠를 제공하는 서버입니다. 여기서 웹 서버가 정적 컨텐츠 뿐만 아니라 동적 컨텐츠 또한 제공하면 웹 애플리케이션 서버라고 할 수 있습니다. 웹 애플리케이션 서버는 HTTP 프로토콜을 통해 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어로 주로 동적 서버 컨텐츠를 수행하며, 이를 통해 사용자의 요구에 맞게 웹 서비스를 제공할 수 있습니다. 대표적인 웹 서버로는 아파치, 웹 애플리케이션 서버로는 톰캣이 있습니다.
MVC: Model, View, Controller
각 레이어간 기능을 구분하는 데에 중점을 둔 디자인 패턴
MVC 패턴은 각 레이어간 기능을 구분하는 데에 중점을 둔 디자인 패턴으로, Model, View, Controller로 구성되어 있습니다. Model은 데이터 관리 및 비즈니스 로직을 처리하고, View는 비즈니스 로직의 처리 결과를 통한 유저 인터페이스를 제공하며, Controller는 사용자의 요청을 처리하고 Model과 View를 연결하는 역할을 합니다.
*MVC 패턴의 요청 처리 흐름

DispatcherServlet: 클라이언트에게 요청을 받아 응답까지의 MVC 처리과정을 통제함HandlerMapping: 클라이언트의 요청 url을 어떤 controller가 처리할지 결정함HandlerAdapter: HandlerMapping에서 결정된 핸들러 정보로 해당 메서드를 직접 호출해주는 역할을 함ViewResolver: controller의 처리 결과(데이터)를 생성할 view를 결정함의존성 주입(DI, Dependency Injection)
의존성 주입은 필요한 객체를 직접 생성하는 것이 아닌 외부로부터 객체를 받아서 사용하는 것이다. 이를 통해 객체간 결합도를 줄이고 코드의 재사용성을 높일 수 있다.
의존성 주입은 필요한 객체를 직접 생성하는 것이 아닌 외부로부터 객체를 받아서 사용하는 것입니다. 이를 통해 객체간 결합도를 줄이고 재사용성을 높일 수 있습니다.
의존성 주입은 생성자 주입, 필드 주입, setter 주입 3가지 방법이 있습니다.
*보충할 내용: 스프링의 의존성 주입 3가지 방법 (생성자 주입, 필드 주입, setter 주입)
서블릿(Servlet)
클라이언트의 요청을 처리하고, 그 결과를 반환하는 서블릿 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍 기술. Spring MVC에서 Controller로 이용되며, 사용자의 요청을 받아 처리한 후 결과를 반환한다. 즉, 자바를 이용한 웹 요청에 대한 결과 반환을 위해 필요한 기술
*서블릿 동작방식

1. 클라이언트가 url을 입력하면 http request가 Servlet Container로 전송된다.
2. Servlet Container는 요청을 받아 HttpServletRequest, HttpServletResponse 객체를 생성한다.
3. web.xml을 기반으로 사용자가 요청한 url이 어느 서블릿에 대한 요청인지 찾는다.
4. 해당 서블릿에서 GET, POST 여부에 따라 doGet() 또는 doPost()를 호출한 후 비즈니스 로직을 수행한다.
5. doGet(), doPost() 메소드는 동적 페이지를 생성한 후 HttpServletResponse 객체에 응답을 보낸다.
6. 응답이 끝나면 HttpServletRequest, HttpServletResponse 두 객체를 소멸시킨다.
서블릿은 클라이언트의 요청을 처리하고 그 결과를 반환하는 서블릿 클래스의 규칙을 지킨 자바 웹 프로그래밍 기술입니다. 서블릿 동작 방식은 크게 5단계로 나눌 수 있습니다.
첫번째, 클라이언트로부터 요청이 들어오면 서블릿 컨테이너로 전송됩니다.
두번째, 서블릿 컨테이너는 요청을 받아 HttpServletRequest, HttpServletResponse 객체를 생성한 후 web.xml을 기반으로 사용자의 요청을 처리할 서블릿을 찾습니다.
세번째, 해당 서블릿에서 GET, POST 여부에 따라 doGet() or doPost() 메소드를 호출합니다.
네번째, doGet() / doPost() 메소드에서 비즈니스 로직을 수행한 후 응답 데이터를 포함한 동적 페이지를 생성한 후 HttpServletResponse 객체에 응답을 보냅니다.
마지막으로 응답이 끝나면 HttpServletRequest, HttpServletResponse 두 객체를 소멸시킵니다.
VO(Value Object): 도메인에서 한개 또는 그 이상의 속성들을 묶어서 특정 값을 나타내는 객체를 의미함. 즉, 변수의 primitive 타입이 도메인 객체를 모델링하기 위해 충분하지 않기 때문에 도메인에서 의미있는 값으로 표현하기 위해 속성들을 묶어 만든 객체이다.
BO(Business Object): 비즈니스 로직을 포함하는 객체로 비즈니스 규칙과 계산 로직을 구현하며 일반적으로 데이터 가공 및 변환 작업을 수행한다. 일반적으로 여러 DAO를 사용해 데이터를 처리함.(Service에 해당하는 객체)
DAO(Data Access Object): 데이터베이스에 접근하는 로직과 비즈니스 로직을 분리하기 위한 객체로 데이터베이스에 접근하여 데이터를 조회하거나 조작하는 기능을 제공한다. 일반적으로 CRUD 작업을 수행하며 Repository에 해당하는 객체이다.
DTO(Data Transfer Object): 데이터 전송을 목적으로 설계된 객체로 주로 네트워크를 통해 데이터를 전송하는 데 사용되며 여러 데이터 항목을 하나의 객체로 그룹화한다. 일반적으로 계층간 데이터 전송(ex. presentation<->business)에 사용된다.
VO는 Value Object의 약자로, 도메인에서 한개 또는 그 이상의 속성들을 묶어 특정 값을 나타내는 객체를 의미합니다. VO는 도메인에서 속성들을 의미있는 값으로 표현하기 위해 만든 속성들의 묶음 객체라고 할 수 있습니다.
BO는 비즈니스 로직을 포함한 객체로 데이터 가공 및 변환 작업을 수행합니다. 일반적으로 여러 DAO를 사용해 데이터를 처리하는 것으로, Service에 해당하는 객체입니다.
DAO는 데이터베이스에 직접적으로 접근하여 데이터를 조회하거나 조작하는 기능을 제공합니다. 일반적으로 데이터의 CRUD 작업을 수행하며 Repository에 해당하는 객체입니다.
DTO는 데이터 전송을 목적으로 설계된 객체로 요청 또는 응답에 필요한 여러 데이터 항목을 하나의 객체로 그룹화합니다. 주로 계층간 데이터 전송에 사용됩니다.
*보충 필요: VO, BO 활용법 / DTO와 VO, Entity의 차이점 정리
인프라 확장을 위한 두가지 방법
Scale-Up: 기존 서버 사양을 업그레이드 해 시스템을 확장하는 것이다. CPU나 RAM 등을 추가하거나 고성능의 부품, 서버로 교환하는 방법이다. 하나의 서버 사양을 업그레이드 하기 때문에 수직 스케일로 불리기도 한다.
Scale-Out: 서버를 여러 대 추가하여 시스템을 확장하는 것이다. 서버가 여러 대로 나뉘기 때문에 각 서버에 걸리는 부하를 균등하게 해주는 '로드밸런싱'일 필수적으로 동반되어야한다. 여러 대의 서버로 나눠 시스템을 확장하는 것이기 때문에 수평 스케일로 불리기도 한다.
두가지 방법으로 트래픽 장애에 대응할 수 있을 것 같습니다.
스케일 업을 통해 하드웨어 스펙을 향상하거나 스케일 아웃을 통해 서버를 여러대 추가하는 방식으로 대응할 것 같습니다. 스케일 아웃으로 대응할 경우 서버를 추가하는 것이기 때문에 부하 균등을 위해 로드밸런싱을 필수로 고려해야할 것 같습니다.
싱글톤 패턴(Singleton Pattern)
싱글톤 패턴은 객체 지향 프로그래밍에서 특정 클래스가 단 하나만의 인스턴스를 생성하여 사용하는 패턴이다. 생성자를 여러번 호출하더라도 인스턴스가 하나만 존재하도록 보장해 애플리케이션에서 동일한 객체 인스턴스에 접근할 수 있도록 한다.
[장점]
[단점]
싱글톤 패턴은 객체지향 프로그래밍에서 특정 클래스가 단 하나의 인스턴스를 생성해 사용하는 패턴입니다. 생성자를 여러번 호출하더라도 인스턴스가 하나만 존재하기 때문에 애플리케이션에서 항상 동일한 객체 인스턴스에 접근하는 것을 보장합니다. 유일한 인스턴스이기 때문에 메모리를 절약할 수 있으며 인스턴스가 실제로 사용되는 시점에 생성해 초기 비용을 줄일 수 있습니다. 그러나 싱글톤 패턴은 전역에서 접근을 허용하므로 해당 인스턴스에 의존하는 결합도가 증가할 수 있고, 전역에서 사용되어 변경될 경우 예상치 못한 동작 발생으로 상태 관리에 어려움이 생길 수 있습니다.
Scope: 범위를 의미, 서블릿에는 4가지 스코프가 존재한다.
1.Page Scope(JSP): 실제 선언된 JSP 페이지 내에서 지역변수처럼 사용한다.
2.Request Scope: 클라이언트로부터 하나의 요청이 들어와서 서버가 일을 수행한 후 응답을 보낼 때까지 계속 사용할 수 있는 scope.
3.Session Scope: session 객체가 생성되고 소멸될 때까지 사용 가능한 scope.
4.Application Scope: 하나의 application이 생성되고 소멸될 때까지 계속 유지하는 scope.
1 < 2 < 3 < 4 순으로 범위가 넓다.
scope는 사용가능한 범위를 의미하며, 서블릿 스코프는 4가지가 존재합니다. 우선 page scope는 실제 선언된 jsp 페이지 내에서 지역변수처럼 사용가능합니다. 그 다음 request scope는 클라이언트로부터 하나의 요청이 들어왔을 때, 서버가 일을 수행한 후 응답하기까지 계속 사용 가능합니다. 그 다음 session scope는 session 객체가 생성되고 소멸될 때까지 사용가능합니다. 마지막으로 application scope는 하나의 application이 생성되고 소멸될 때까지 계속 사용가능합니다. 이 4가지 스코프는 page < request < session < application 순으로 범위가 넓어집니다.
*보충 필요: 각 scope의 특징
프레임워크: 개발자가 소프트웨어를 개발하는 데 구현 시간을 줄이고 코드의 재사용성을 증가시키기 위해 클래스 묶음이나 뼈대, 틀을 라이브러리 형태로 제공되는 것을 말한다.
라이브러리: 개발자가 만든 클래스들의 나열로, 다른 프로그램들에서 사용할 수 있도록 제공하는 방식이다.
라이브러리와 프레임워크의 차이는 제어 흐름에 대한 주도성이 누구에게 있는지에 따라 다릅니다. 즉, 애플리케이션의 흐름을 누가 쥐고 있느냐에 달려있다고 할 수 있습니다. 프레임워크는 스스로 제어 흐름의 주도성을 갖고 있는 반면, 라이브러리는 개발자가 갖고 있습니다. 프레임워크는 라이브러리와 달리 이미 프로그래밍에 대한 규칙을 갖고 있기 때문에 개발자는 이를 따라야만 합니다. 따라서 프레임워크는 그 자체로 제어 흐름을 갖고 있다고 할 수 있고, 이를 제어의 역전(Inversion of Control)이라고 합니다.
동적 쿼리란 실행시에 특정 조건이나 상황에 따라 쿼리 문장이 변경되어 실행되는 쿼리문을 말합니다. 동적 쿼리는 컴파일시에 SQL문을 확정할 수 없는 경우에 사용합니다. 즉, 실행시점에 따라 where절 조건이 달라질 때 사용합니다.
Call By Value(값에 의한 호출): 인자로 받은 값을 복사하여 처리하는 방식. 값을 복사해 처리하기 때문에 원래의 값이 보존된다는 장점이 있으나 복사 때문에 메모리 사용량이 증가한다는 단점이 있다.
Call By Reference(참조에 의한 호출): 인자로 받은 값의 주소를 참조하여 직접 저장해 값에 영향을 주는 방식. 복사하지 않고 직접 참조하기 때문에 빠르다는 장점이 있으나 직접 참조 때문에 원래 값이 영향을 받는다는 단점이 있다.
값에 의한 호출은 인자로 받은 값을 복사하여 처리하는 방식으로, 복사해서 처리하기 때문에 원래의 값이 보존되는 장점이 있으나 복사 때문에 메모리 사용량이 증가하는 단점이 있습니다. 반면, 참조에 의한 호출은 인자로 받은 값의 주소를 참조해 직접 저장하는 방식으로, 복사하지 않고 직접 참조하기 때문에 빠르다는 장점이 있으나 이로 인해 원래 값이 영향을 받는다는 단점이 있습니다.
*꼬리 질문: 그럼 Java에서 어느 부분이 값에 의한 호출이고, 어느 부분이 참조에 의한 호출에 해당하나요?
자바는 기본적으로 모든 전달 방식이 값에 의한 호출이다. 참조형의 경우 객체의 '주소값'을 매개변수로 전달하기 때문에 참조에 의한 호출로 착각할 수 있으나 정확히는 객체의 주소를 가리키는 참조값이다. 또, 주소값 자체를 복사없이 인자로 전달하는 것이 아닌 자기 자신이 갖고 있는 값을 복사해 전달한다. 결국 기본형 변수나 참조형 변수 모두 자신이 갖고 있는 값을 복사해서 전달하기 때문에 값에 의한 호출이다.
CORS(교차 출처 리소스 공유, Cross-Origin Resource Sharing)
CORS란 교차 출처 리소스 공유의 약자로, 서버가 자신의 출처가 아닌 다른 출처로부터 액세스 할 수 있도록 허용해주는 HTTP 헤더 기반 메커니즘이다. 이는 교차 출처 리소스를 호스팅하는 서버가 실제 요청을 허가할 것인지 확인하기 위해 브라우저가 보내는 사전 요청 메커니즘에 의존한다. 이 사전 요청에서 브라우저는 실제 요청에서 사용할 HTTP 메서드와 헤더들에 대한 정보가 표시된 헤더에 담아 보낸다.
CORS는 교차 출처 리소스 공유의 약자로, 브라우저에서 자신의 출처가 아닌 다른 출처로부터 리소스를 로딩하는 것을 허용하도록 서버가 허가해주는 HTTP 헤더 기반 메커니즘입니다. CORS는 교차 출처 리소스를 호스팅하는 서버가 실제 요청을 허가할 것인지 확인하기 위해 브라우저가 보내는 사전 요청 메커니즘에 의존합니다. 이 사전 요청에서 브라우저는 실제 요청에서 사용할 HTTP 메서드와 헤더들에 대한 정보를 헤더에 담아 보냅니다.
*보충 필요: CORS 개념 및 활용 예시
절차지향은 기능 중심으로 바라보는 방식으로 "무엇을 어떠한 절차로 실행할 것인가"가 핵심이 되며 어떤 기능을 어떤 순서로 처리하는지에 초점을 두는 방식입니다.
객체지향은 기능이 아닌 객체 중심으로 바라보는 방식으로 "누가 어떤 일을 할 것인가"가 핵심이 되며, 독립적인 객체를 도출하고 각각의 역할을 정의해 나가는 것에 초점을 두는 방식입니다.
XSS(Cross-site Scripting)크로스 사이트 스크립트
웹사이트에 의도치 않은 스크립트를 넣어 실행시키는 기법
웹 애플리케이션이 사용자로부터 입력받은 값을 제대로 검사하지 않고 사용할 경우 발생
사용자는 의도치 않은 동작을 수행하거나 쿠키, 세션 등의 정보를 탈취 당하게 된다.
CSRF(Cross-site Request Fogery)크로스 사이트 요청 변조
사용자가 자신의 의지와는 무관하게 침입자가 의도한 행위를 서버에 요청하게 하는 공격
XSS와 CSRF 모두 웹 애플리케이션 보안과 관련된 공격 기법입니다.
XSS는 크로스 사이트 스크립트로, 웹사이트에 의도치 않은 스크립트를 넣어 실행시킴으로써 사용자가 의도치 않은 동작을 수행하게 하거나 쿠키, 세션 등의 정보를 탈취하는 기법입니다. CSRF는 크로스 사이트 요청 변조로 사용자가 자신의 의지와는 무관하게 침입자가 의도한 행위를 서버에 요청하게 하는 공격입니다. XSS와 CSRF의 차이는 XSS는 사용자가 특정 사이트를 신뢰함으로써 발생하는 문제인 반면, CSRF는 특정 사이트가 사용자를 신뢰함으로써 발생하는 문제라는 것이 가장 큰 차이점이라고 할 수 있습니다.
CSRF를 막기 위한 방법으로는 첫번째, 사용자 요청에 referer를 확인해 도메인이 일치하는지 확인하는 방법이 있고, 두번째로는 상태를 변화시키는 POST, PUT 등의 요청에 대해 csrf 토큰이 포함되어야만 요청을 처리하는 방법이 있습니다.
쿠키(Cookie): 사용자의 로컬에 저장하는 기록 정보 파일로, HTTP에서 클라이언트의 상태 정보를 PC에 저장했다가 필요시 정보를 참조하거나 재사용 할 수 있다.
세션(Session): 일정 시간 동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지하는 기술. 즉, 사용자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.
쿠키는 사용자의 로컬에 저장하는 기록 정보 파일로, HTTP에서 클라이언트의 상태 정보를 PC에 저장해두어 필요시 정보를 참조하거나 재사용 할 수 있습니다.
세션은 일정 시간 동안 같은 사용자로부터 들어오는 요청을 하나의 상태로 보고, 그 상태를 유지하는 기술입니다.
쿠키는 사용자 로컬에 파일 형태로 저장하기 때문에 문자열로 저장해야하는 반면, 세션은 웹 서버에 저장하기 때문에 객체 형태로도 저장 가능합니다. 쿠키는 쿠키 저장 시에 만료 기간을 설정할 수 있으나 세션은 브라우저 종료 시에 삭제됩니다. (기간 지정도 가능해졌다고 합니다.) 또, 쿠키는 사용자 로컬에 저장해야하기 때문에 용량에 제한이 있는 반면, 세션은 서버가 허용하는 한 용량제한이 없습니다.

1. 사용자가 브라우저에 URL(www.naver.com)을 입력
2. DNS 서버에 도메인 네임으로 서버의 진짜 주소를 찾음
3. IP 주소로 웹 서버에 TCP 3 handshake로 연결 수립
4. 클라이언트는 웹 서버로 HTTP 요청 메시지를 보냄
5. 웹 서버는 HTTP 응답 메시지를 보냄
6. 도착한 HTTP 응답 메세지는 웹 페이지 데이터로 변환되고, 웹 브라우저에 의해 출력
Client Side Rendering: 렌더링이 클라이언트 쪽에서 일어나는 것으로, 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내고, 클라이언트가 웹 문서를 받아 렌더링을 시작하는 것이다. 서버에서 처리없이 클라이언트로 보내주기 때문에 웹 문서가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 볼 수 있는 것이 없다.
Server Side Rendering: 서버쪽에서 렌더링을 마친 상태로 클라이언트에 전달하는 방식으로, 이미 렌더 가능한 상태로 클라이언트에 전달되기 때문에 웹 문서가 다운로드 되는 동안 사용자는 다른 무언가를 보고 있을 수 있다.
CSR vs SSR 차이
1. 웹페이지 로딩 시간: 첫 페이지 로딩 시에 CSR은 모든 웹 문서를 한번에 불러오고, SSR은 필요한 부분의 웹 문서만 불러오므로 평균적으로 SSR이 더 빠르다. 첫 페이지 로딩 이후 다른 페이지로 이동할 때의 로딩은 CSR에서 이미 첫 페이지 로딩할 때에 모든 웹 문서를 불러왔기 때문에 SSR에 비해 빠르다. 그러나 SSR은 첫 페이지 로딩 과정과 동일하게 페이지를 로딩하기 때문에 CSR에 비해 더 느리다.
2. SEO 대응: 검색 엔진은 자동화된 로봇인 '크롤러'로 웹사이트들을 읽는다. CSR은 자바스크립트를 실행시켜 동적으로 컨텐츠가 생성되기 때문에 자바스크립트가 실행되어야 metadata가 바뀌었다. SSR은 애초에 서버 사이드에서 컴파일되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이하다.
3. 서버 자원 사용
SSR이 서버에 매번 요청을 보내기 때문에 서버 자원을 더 많이 사용한다.
CSR은 클라이언트 사이드 렌더링, SSR은 서버 사이드 렌더링입니다. CSR은 첫 페이지를 로딩할 때 웹 애플리케이션의 모든 웹 문서를 한번에 불러와 클라이언트 단에서 문서를 로딩하는 방식입니다. SSR은 매번 서버에 요청할 때마다 필요한 웹 문서를 서버에서 가져오는 것으로, 서버 단에서 렌더링을 마친 상태로 클라이언트에 전달하는 방식입니다. CSR은 첫 페이지 로딩 시에 모든 웹 문서를 가져오기 때문에 처음에는 SSR보다 느릴 수 있으나 이후 페이지 이동 시 리소스 로딩은 이미 첫 페이지 로딩 시에 모두 가져온 상태이기 때문에 상대적으로 더 빠릅니다. SSR은 새로운 요청마다 매번 계속해서 서버에 요청해주어야 하기 때문에 상대적으로 더 느립니다.
https://dev-coco.tistory.com/163
https://codechasseur.tistory.com/25
https://ksh-coding.tistory.com/83
https://velog.io/@haizel/XSS%EC%99%80CSRF-%EC%B0%A8%EC%9D%B4%EC%A0%90-%EB%B0%8F-%EB%8C%80%EC%9D%91-%EB%B0%A9%EC%95%88