6 Week

2023-01-19 6 분 소요

Web

아래 내용들을 무엇이다 라고 정의해보려고 했는데 명쾌하게 떠오르지 않았다.
이참에 한번 짚고 넘어가자.

World Wide Web

인터넷에 연결된 사용자들이 서로의 정보를 공유할 수 있는 공간

텍스트, 그림, 소리, 영상 등의 멀티미디어 정보를 하이퍼텍스트 방식으로 연결
- 하이퍼텍스트 : 문서 내부에 또다른 문서가 연결되는 참조를 넣음

웹페이지들은 각각 연결되어 있는데 이로 인해 거미줄처럼 얽혀있는 정보의 모음이라고도 불림

웹페이지

정보제공을 목적으로한 정적인 사이트
수동적으로 정보를 관람함

웹어플리케이션

동적기능을 가진 웹으로 상호작용을 통해 유저가
능동적으로 어플리케이션 상의 서비스를 이용하는것을 목적으로 함

Browser Rendering

SSR

서버사이드 렌더링 - Server Side Rendering
서버로부터 완전하게 만들어진 HTML 파일을 받아오는 방식
렌더링이 서버에서 일어난다.

동작
1. 클라이언트가 요청을 보냄
2. 서버는 HTML 에 데이터, CSS, JS 를 렌더링하여 컴파일 후 보낸다.
3. 클라이언트는 즉시 HTML 을 먼저 렌더링 하고 그 후 JS 코드를 받아 실행한다.
장점
- 빠른 초기 로딩
- HTML 안에 모든 데이터가 포함되어 있어 검색엔진에 노출이 잘됨 (크롤링)
단점
- 요청시마다 새로고침 (깜빡임)
- 서버부하 (작은 변경이라도 서버에서 모든걸 다시 받아옴)

CSR

클라이언트 사이드 렌더링 - Client Side Rendering
사용자에 요청에 따라 필요한 부분만 응답받아 렌더링 하는 방식
렌더링이 클라이언트 쪽에서 일어난다.

동작
1. 클라이언트에서 초기화면을 로드하기 위해 서버에 요청을 보냄
2. 서버는 화면에 표시하는데 필요한 완전한 리소스 응답
장점
- 빠른속도 (초기화면 렌더링X)
- 서버부하 감소 (클라이언트에서 변경부분만 요청)
- 유저경험 증가 (깜빡임)
단점
- 초기화면 로딩 느림 (JS포함 모든 파일을 받아야 함)
- 검색엔진에 노출이 잘 안됨 (HTML 자체는 깡통이므로)

HTTP의 전송방식

GET, POST 등의 전송방식이 있지만 모두 텍스트 형식이다.
HTTP 전송방식에 왜 텍스트를 사용했을까?

다양한 환경에 맞는 (범용적, 유연함) 규약이 필요했다.
왜나햐면 Web은 말그대로 전세계 모든 사람이 이용하는, 엄창나게 많은 곳에서 쓰인다.
일단 텍스트는 눈으로 보고 어느정도 의미를 유추할 수 있고
클라이언트에 상황에 구애받지 않는 텍스트가 가장 보편적이었다.
따라서 바이트코드나 비트같이 가볍지만 제약이 따르는 것들 대신 보편적인 텍스트를 쓰는것이다.

그렇다면 HTTPS는?

하이퍼 텍스트 전송 프로토콜 즉, HTTP는 HTML을 전송하기 위한 통신 규약이다.
하지만 암호화 되지 않은 방법으로 데이터를 전송하기 때문에 보안에 취약하다.
그래서 이를 보완한 것이 SSL 또는 TLS 사용해 암호화된 HTTPS 이다.
SSL, TLS 는 응용계층(HTTP) 과 전송계층(TCP) 사이에 위치해 있다.

SSL : 서버와 브라우저 사이에 전송되는 데이터를 암호화 함
TSL : SSL의 향상된 버전, 통신하는 대상간의 데이터의 무결성을 제공하는걸 목표로 함

인증서 동작

SSL/TSL 세션은 핸드셰이크라는 과정을 통해 클라이언트-서버 간에 암호화 된 연결을 수립한다.

인증
- 클라이언트가 시작하는 모든 신규 세션에 대해 서버는 각각 다른 SSL 인증서를 교환하고 검증한다.
암호화
- 서버는 클라이언트와 공개 키를 공유하고 클라이언트는 이 키를 사용해 프리마스터 키를 생성해 암호화한다. 이를 키교환이라고 한다.
복호화
- 서버는 개인 키를 사용해 프리마스터 키를 복호화 하고, 세션기간동안 사용되는 암호화된 보안연결을 수립한다.

Base64

Binary Data 를 Text로 바꾸는 인코딩 의 하나로써 Binary Data 를 Character set에 영향을 받지 않는 공통 ASCII 영역의 문자로만 이루어진 문자열로 바꾸는 인코딩이다.
Base64는 직역하면 64진법인데, 64진법은 2의 제곱수에 기반한 진법 중 화면에 표시되는 ASCII 문자들로 표시할 수 있는 가장큰 진법이다.

인코딩 : 정보의 형태나 형식을 표준화, 보안, 처리속도향상 등을위해 다른 형태나 형식으로 변환하는 처리

왜쓰는데?

Base64로 인코딩하면 데이터양이 약 33% 늘어나고 다시 디코딩하는 추가연산도 필요하다. 근데 왜쓸까?
HTTP로 Binary Data(이미지, 오디오 등)를 전송하면 문제가 발생하는데, 대표적으로

ASCII는 7bits 인코딩 인데 나머지 1bit 를 처리하는 방식이 시스템 별로 상이하다.
일부 제어문자 (e.g. Line ending)의 경우 시스템 별로 다른 코드값을 갖는다.

즉,Binary Data의 손실이 일어나기 때문에, ASCII는 시스템간 데이터를 전달하기에 안전하지가 않다.
그래서 ASCII 중 제어문자와 일부 특수문자를 제외한 64개의 안전한 출력 문자만 사용하는 Base64를 사용한다.

Bulk 처리

대량의 데이터를 한번의 트랜잭션으로 삽입하는 방법이다.

insert 로 예를들면
MyBatis 기준 insert 구문 수행 시 values 리스트를 다중으로 사용한다.

insert into A values(a, b, c), (a, b, c), (a, b, c) ...


insert into A(a, b, c) values
<foreach collection="list" item="item" separator=",">
	#{item}
</foreach>

왜쓰는데?

DB와의 트랜잭션은 커넥션을 열고 닫는 등의 생각보다 복잡하고 리소스가 큰데 10000건의 데이터를
저장하는 경우를 생각해 보면 데이터를 저장하는데 10000번의 트랜잭션이 일어나게 된다.

하지만 bulk insert 의 경우 단 한번의 트랜잭션으로 처리를 할 수 있기 때문에
데이터 수가 많을수록 비약적으로 성능이 향상된다.

실제로도 예전에 거의 안쓰이는 스케쥴러 처리한 insert 용도의 API 가 있는데 어느순간
급격히 사용량이 많아져서 데이터 처리에 딜레이가 발생하는 상황이 생긴적이 있는데
이때 bulk 처리 하나로 비약적인 성능향상과 이슈를 해결한 적이 있었다.

단점

bulk insert 로 10000건의 데이터를 insert 하던 중 마지막 low 에서 에러가 발생한다면?
이럴경우 모두 롤백된다.

10000번의 트랜잭션을 1번의 트랜잭션으로 해결해서 비약적인 성능향상을 가져올 수 있지만 하나라도
실패하는 순간 트랜잭션은 롤백되고 그 트랜잭션 안에 10000건이 있기 때문에 이렇게 되면 매우 비효율적이다.
그래서 너무 대량의 데이터를 bulk 처리 하는건 좋지않고,
실패할 경우를 대비해 retry 하는 코드도 별도로 짜주는게 좋다.
제일 좋은건 정합성이 뛰어난 데이터여서 실패할 가능성이 거의 없을때 사용하는게 좋겠다.

To Do

세션이 왜필요할까?

HTTP프로토콜은 비연결 지향이기 때문에 세션과 쿠키를 사용하는데
세션은 서버에서 관리하고 프론트에선 그 키를 받아서 내가 누구인지 알려준다.
이런식으로 인증에 대한 세션과 쿠키의 협업이 일어난다.

Apache Tomcat

가장 범용적인 WAS 중 하나이며, Apache 재단 에서 개발한 HTTP Web Application Server이다.
오픈소스이기 때문에 무료이고 구축이 쉽다는 이유로 전세계에서 매우 많이 사용되고 있다.
기본적으로 Apache 와 Tomcat 의 기능은 나뉘어져 있지만, Tomcat 안에 컨테이너를 통해
일부 Apache 기능을 발휘하기 때문에 보통 Apache Tomcat 으로 부른다.

Apache
- 웹서버이며, 80포트로 클라이언트 요청(GET, POST 등)이 왔을때만 응답한다.
- 정적인 데이터만 처리한다 (HTML, CSS, 이미지 등)
  - 웹서버 : HTTP 프로토콜 요청을 처리하는 서버
Tomcat
- 동적인 웹을 만들기 위한 Web Container, Servlet Container 로도 불림
- Servlet 을 실행키고 JSP 코드가 포함되어 있는 웹 페이지를 만들어준다.
- DB, 로직처리 등을 요구하는 동적타입을 제공하는 소프트웨어
- 프로그램 실행환경과 DB 접속 기능 등을 제공한다.
- 여러개의 트랜잭션을 관리한다.
- 비즈니스 로직을 수행한다.
Sevrlet
- 동적인 처리를 하는 역할을 담당하는 자바 기반 기술
- WAS에서 동작하는 Java 클래스이며, HttpServlet 을 상속받는다.
- Request / Response 흐름을 간단한 메서드 호출로 다룰 수 있게 해준다.
Sevrlet Container
- Sevrlet 을 담고 관리하는 컨테이너
- 새로운 요청이 들어올 때 마다 스레드를 생성
- 작업이 끝난 서블릿 스레드를 제거

정리하면

Apache Tomcat != Apache

Apache 만 사용하면?
- 구조가 단순하여 트래픽 과부하에 장점이 있다.
- 정적인 웹페이지만 처리가 가능하다.
Tomcat 만 사용하면?
- 동적인 웹페이지 처리가 가능하지만 Apache 에서 필요한 기능을 가져오지 못한다.
- Apache 에 비해 속도가 느려 트래픽 과부하에 단점이 있다.
둘을 같이쓰면?
- Apache 는 정적인 데이터만 처리하고, JSP 처리는 Web Container(Tomcat의 일부)로 보낸다.
  결국 분산처리가 가능하다.

Servlet Filter

J2EE 표준 스펙을 구현한 기술이다. Tomcat과 같은 Web Container에 의해 관리된다.
Servlet으로 전달되는 클라이언트의 request 혹은 Servlet에서 클라이언트로 전달되는 response를
중간에 가로채서 request / response 객체 자체를 조작할 수 있다.

사용자인증, 로깅, 인코딩 같은 기능들은 모든 Servlet이나 JSP가 공통적으로 필요로 하기 때문에 공통적인
기능들을 Servlet 이 호출되기 전에 전처리 혹은 후처리 하고 싶을 때 Servlet Filter로 구현한다.
클라이언트 요청을 Servlet 이 받기전에 먼저 가로채서 서버컴포넌트의 공통적인 기능을 수행시킬 수 있다.

예를들어 모든 페이지에서 로그인 유무를 확인해야 할 경우 각 Controller 마다 로그인 유무를 체크하는 로직을
작성하면 추후 로그인 관련 로직이 변경될 경우 모든 로직을 바꿔야 하기 때문에 매우 비효율 적일 것이다.
그렇다면 이 공통관심사 를 분리해서 필터에 위임하면 유지보수가 훨씬 용이해 질 것이다.
Servlet Filter 는 Servlet과 비슷한 LifeCycle을 가진다. (생성 - 초기화 - 필터 - 종료)

필터로 구현하면 좋은 기능들
- 인증(사용자 인증) 필터
- 로깅 및 감시 필터
- 이미지 변환 및 데이터 압축 필터
- 암호화 필터
- XML 컨텐츠를 변형하는 XSLT 필터
- URL 및 기타 정보들을 캐싱하는 필터

관심사의 분리?

Filter를 공부하다가 관심사의 분리 라는 키워드를 보게 되었다.
Filter는 무슨 행동을 하기전에 먼저 실행하거나, 실행한 후 추가적인 행동을 할 때 사용하는데
스프링에는 공통처리 를 위해 활용할 수 있는 Interceptor와 AOP 가 더 있다.
Interceptor와 Filter는 Servlet단위에서 실행되지만 AOP는 메소드 앞에 Proxy패턴의 형태로 실행된다.
실행순서는 Filter가 가장 밖에 있고 그안에 Interceptor, 그안에 AOP가 있는 형태이다.
따라서 요청이 들어오면 Filter → Interceptor → AOP → Interceptor → Filter 순으로 거치게 된다.

Interceptor

스프링에서 제공하는 기술이다.
DistpatcherServlet이 Controller를 호출하기 전과 후에 응답을 참조하거나 가공한다.
Filter는 스프링 컨텍스트 외부에 존재하여 스프링과 무관한 자원에 대해 동작하지만
Interceptor는 스프링의 DistpatcherServlet이 Controller를 호출하기 전, 후로 끼어들기 때문에
스프링 컨텍스트(Context, 영역) 내부에서 Controller(Handler)에 관한 요청과 응답에 대해 처리한다.

스프링의 모든 빈 객체에 접근할 수 있다.
Interceptor는 여러개를 사용할 수 있고 다음과 같은 작업을 수행한다.
- 로그인 체크
- 권한 체크
- 프로그램 실행시간 계산작업
- API 호출에 대한 로깅

AOP

OOP를 보완하기 위해 나온 개념
객체지향 프로그래밍을 했을 때 중복을 줄일 수 없는 부분을 줄이기 위해 종단면(관점)에서 바라보고 처리한다.
주로 비즈니스단의 메서드에서 로깅, 트랜잭션, 에러처리 등을 조금 더 세밀하게 조정하고 싶을 때 사용한다.
Interceptor와 Filter 와 다르게 메서드 전후의 지점에 자유롭게 설정이 가능하고
Interceptor와 Filter는 주소로 대상을 구분해서 걸러내지만 AOP는 주소, 파라미터, 어노테이션 등 다양하게 대상을 지정할 수 있다.

메서드 단위 공통로직 에 적합 예를들면, 각 메서드가 얼마나 걸리는지 시간측정하는 로그를 뿌리는 작업

ServletContextListener

TCP / UDP

배치시스템 vs 스트리밍 시스템

OSI 7 계층

계층이 올라간다는건 무슨 의미일까?

TCP 기반의 HTTP가 UDP통신을 도입하고 있는데 과연 데이터 정합성의 문제는?

데이터 정합성의 검증을 한 계층 더 올려서 거기서 한다는데?
그러니까 TCP를 사용하는 계층에선 정합성의 문제에서 자유로우니 UDP 통신을 이용한다?

Twitter Facebook LinkedIn