초기의 웹

Web 서비스를 창안한 티모시 버너스리가 HTML 이라는 문서구조를 만들고 이걸 송수신할 수 있는 HTTP 통신프로토콜을 고안해냈다. 이 연결고리가 마치 거미줄과 같다고해서 Web 서비스라고 한다.

기본적으로 프로그래밍 특히 문서를 다루는 프로그래밍의 경우 유지보수의 편의성을 위해

자료구조
UI
제어체계

3가지 요소로 구분해 놓는다.

기억할 점은 이 3가지 구분은 Web도 예외가 아니란 것이다.

HTTP 통신프로토콜은 초기 1.0 에서 1.1 → 2.0 → 3.0까지 발전해왔다.

초기에 티모시가 고안해냈을 당시 고가의 워크스테이션으로 개발한 Web에는 Client(Browser)가 있고 Internet 이라는 public한 NetWork 에 연결했다. 그리고 이는 Web Server에 연결되어있다.

티모시가 처음 Web을 설계할 때 TCP/IP 통신을 전제로 했다. 즉 Web client와 Web server사이에 TCP/IP 연결을 기초로 HTTP 통신이 된다고 가정하고 시작했다.

이때, HTTP 통신프로토콜의 큰 특징중 하나로 “Stateless”가 있다. 근데 TCP/IP 연결에서 ‘연결’이라는 단어는 항상 [상태]의 개념을 포함하는데, 그 위에서 작동하는 HTTP에는 Stateless, 즉 상태가 없다고 했지않은가? 이는 훗날 문제를 만들어낸다.

티모시께서 처음 설계한 웹시스템으로 들어가보자,

네이버나 구글 주소창에 URL(Uniform Resource Location)형식의 주소를 입력했다고 상상해보자.

그럼 Web client와 Web server 이 두 host놈들도 각자 고유의 IP주소가 있을 것이고, 이 고유 IP주소를 알아내면서 TCP/IP 연결을 한 후 ‘Resource 주세요~’라고 연결이 간다.

실제 접속할 때는 IP 주소로 한다. 근데 주소창에 치는건 URL 이다. 이는 URL을 주소창에 치면 DNS(도메인 네임서비스)라는 서버에 URL을 던져주면 DNS가 IP주소를 알려주기 때문이다. (DNS cache, hostfile 이런게 있긴하지만 이 주제에서 다루는 메인요소는 아니니 대략적으로 이렇게만 알아두자.

다시 이어서 TCP/IP 연결이된 순간 HTTP 프로토콜이 작동하기 시작하는데, 기본적으로 Request가 날라간다. HTTP는 구조상 그에 따른 Response 가 오게 되는 Protocol(형식)이다. 이때 request에는 method가 있는데 가장흔한게 Get이다. Get이라는 방법론으로 리소스(HTML파일) 주세요~ 하면 HTML이 날라오는거다. (HTML라는 문서는 하드디스크 같은 저장장치에 존재함)

여기서 문제는 HTML 이라는 문서는 기존의 텍스트와 달리 태그가 들어가있다. 문서를 가져와서 화면이 전환되며 HTML을 읽어야하는데, 이때 태그도 있고 다양한게 있다보니 처음에 문서를 가져오자마자 Web Client(브라우저)가 하는 것이 1. 구문분석(Parsing)이다. 이 파싱으로 분석된 결과를 가지고 자료구조를 생성한다. (자료구조 형태는 비선형 트리구조로 되어있다) 그렇게해서 만들어진 구조를 화면에다가 2. 렌더링하게 되어있다.(화면출력이라 생각하면 이해하기 편함)

그래서 Web client를 이루는 핵심요소는

구문분석을 해줄 수 있는 분석기
렌더링해줄 수 있는 렌더링엔진이다.

여기까지가 HTTP 1.0 수준정도가 되는데, 이 당시 브라우저가 뭐하는 프로그램이었을까 생각해보면 마치 [문서뷰어]와 같다. 기존의 문서뷰어와 다른점이라하면 [원격지]라는 차이점이 있다.

웹 서비스 3대요소 이야기

위의 내용을 잠시 정리하자면, 문서를 가져와서 보여주고 문서속에 또다른 하이퍼링크를 클릭해서 연결하고 request보내고 문서읽어다가 받아오고 등등 의 과정이였다.

중요한건 이 과정까지는 Web server에서 Web Client로 보내는 [단방향 작용]이라는 점이다.

문서(HTML)라는게 색깔도 들어가야하고 이뻐야하고해서 HTML 성격이 많이 바뀐다. 예쁘게 화면에 보이기 위해, 자료구조에 해당하는 HTML의 내용은 ok, 근데 UI와 섞어놓으면 유지보수하기가 어렵다.

그래서 HTML 문법 중에 렌더링에 개입하게되는 부분만 따로 떼내게 된다. 이걸 CSS라 한다.

(현재 CSS3까지 나옴.) 또 CSS는 예쁘기 보이기 위함이고, 웹이라는게 글씨만 있나? NO! 사진같은것도 당연히 포함된다.

그래서 일단 Server에 한번 연결하게 되면 HTML 만 달라고하는게 아니라 CSS파일, 사진도 같이 달라고한다. (날라오는순서도 HTML → CSS → 사진 순서임을 기억.) 차례대로 Client는 들어오는 순서대로 HTML을 처음 파싱해서 보고 이런내용이구만~ 하고 렌더링, 이후 CSS가 날라오면 그걸로 더 이쁘게 렌더링하고 , CSS가 사용하는 사진을 가져다가 렌더링해준다.

HTML 이라는 것에 대해 명심할 것은 HTML은 [문서]이다. 반면 CSS는 좌표체계가 아니라 CSS에서 기술하는거는 문장을 중앙정렬, 가운데 정렬 뭐 이런식이다..(찾아보세요)

지금까지의 흐름에서 HDD에 HTML, CSS, 사진 등의 리소스들이 저장되어있다.

이를 [정적]이라고 표현한다. 그러면 이러한 정적 리소스들을 가져오기만 하냐?

필요에 따라서 리소스를 갱신하고 바꿔야하는 경우도 있을 것이고, Web Client에서 server로 정보가 넘어가는 경우도 필요하다. 이를 위해 웹이 더 발전하게 된다.

자, 로그인 했을 경우를 생각해보자. 로그인 id를 입력하고 password를 입력하고 로그인버튼을 눌러서 로그인한다. 이때 로그인 버튼을 클릭하게 되면 사용자의 입력이다. 이 이벤트에 따라서 request가 server쪽으로 가게된다.

이처럼 http.request.method가 날라가게 되는데 이때 ‘Post’가 날라간다고 생각해보자. 이때 id입력창에 tester라고 입력을 했다고 치면, 이에 따라 Post가 가게되는 것이 그냥 가는게 아니라 id = tester 식으로 가게된다.

이때 중요한 것은 위의 ‘tester’라는 문자열이 Server입장에서 Client로부터 날라왔다는 것이다. 기본적으로 Web Server의 역할은 [송/수신 담당]이다. 즉, 네트워크를 주고 받는 담당이다. 옛날에는 ‘처리’하는 것까지 다했었지만, 최근에는 이런것들만 전문적으로 해주는 구성요소인 WAS가 웹에 추가되었다.

따라서 이 WAS는 ‘처리 담당’ 으로 tester라는 문자열을 Web server가 수신하자마자 WAS에 넘겨버리고 WAS는 처리한다. (WAS는 ‘xxx 님, 안녕하세요’라는 문서를 가지고 있다고 생각하면 이해하기 편함)

여기서 생각해볼 것이, Get을 써서 Read를 할때만해도 [단방향 작용]으로 서버에서 클라이언트로 내려오기만 했는데 이번에는 클라이언트에서 서버에서 올라간 것으로 [양방향 상호 작용]이 된 것이다. 여기서 양방향 상호 작용이 되버리면 이때 부터 문맥이(상태→전이) 나와버리는 문제가 생긴다. (예를들어 로그인하기전 전, 로그인하는 중, 로그인 됨 등의 변화 발생)

근데 문제가 있어.. HTTP 프로토콜은 Stateless라서 이 문맥(상태전이)를 기록할 방법이 없네?

그럼 어딘가에는 기억(기록)을 해야하는데, 이 역할을 해주는게 Database이다. 그래서 처리 주체인 WAS와 자료를 담당하는 DB는 항상 연결되어있다. 이 둘의 연결의 방법에는 여러가지가 있지만, 어찌됐건 연결을 전제로 DB를 통제할 때는 SQL(Structure Query Language)을 사용한다.

아까 tester라는 문자열이 클라이언트에서 서버로 정보가 날라온것을 기억할 것이다. 이를 DB에 물어본다. (select * from table \ where id = ‘tester’;)

만약 찾았으면 WAS의 ‘xxx 님, 안녕하세요’라는 문서에 xxx 대신 tester를 집어넣게된다. 이는 새로운 문서인 ‘tester님, 안녕하세요’가 [생성]된 것이다.

즉, [동적]으로 생성된 문서가 response로 날라간다.

이를 통해 ‘tester님, 안녕하세요’라는 화면이 바뀜을 알 수 있다.

여기서 생각을 해볼 것이 tester라는 데이터를 뒤졌을 때 그게 없으면 어떡할까? WAS에서 그에 맞는 다른 문서를 보낼 수도 있을 것이다.

또 다른 문제가 하나있는데, 이렇게 웹서비스가 복잡해지기 시작하면서 [제어]라는 개념이 포함되고 렌더링했는데 화면이 정적이네? → “그럼 여기다가 움직임을 주자 즉, 제어체계를 집어넣자 !”

이로인해 1. 구문분석 2. 렌더링에 이어 3. 연산을 넣게된다. 즉, Client에 연산 엔진에 해당하는 소프트웨어를 때려넣게 되는데 첫번째로 나온것이 Mocha, 이후 Live라고 변경 되었다가 마지막으로 바뀐이름이 JAVA Script이다.

JAVA Script는 어디서 실행되는가? → 브라우저에서 실행됨을 기억하자.

(이는 보안과 연결되는 중요한 사안이다.)

그렇다면 JAVA Script는 어디에 있는가?

웹 시스템이 개발 될때 [정적]이라고 표현되는 HDD,SSD 등 저정장치 안 HTML + CSS +사진에 더불어 ‘JAVA Script’가 위치한다.

이로하여금 날라오는 순서도 HTML → CSS → 사진 → JAVA Script임을 알 수있다.

정리) Client(browser)를 이루는 3대요소는 1. 구문분석 2. 렌더링 3. 연산 주체가 되는 Script 엔진이다. 따라서 브라우저(client)의 성능을 얘기할 때 이 3가지를 가지고 얘기한다. 그렇다면 앞서 ‘기억’이라는 것을 서버는 DB로 구현했는데, 클라이언트는 어떤형태로 구현할까? 그게바로 Cookie이다 (’기억’이라는 것을 양쪽에서 다르게 구현함)

WAS, JVM, RESTful API

WAS 는 웹시스템에서 처리주체로서 연산을 수행해나간다. 이 WAS는 리소스를 송수신하는 Web server와 자료를 기억하는 DB와 연결되어있음을 앞서 얘기했다. 또한 WAS 자신은 프로세스 로직을 가지고 있는 Service임을 기억하자.

WAS와 관련되서 알아두어야할 것이 있는데

Web Server가 정적데이터를 가지고있는걸 처리한다 (View)
Database 즉 자료구조와 관련 (Model)
Web Server가 송수신할 때 리소스에 URL을 사용하는데 그것과 관련된 제어체계(Control)

앞자만 따서 ‘MVC’의 형태로 비지니스 로직을 구현하는데 이를 분야별로 쪼개서 프로그램을 더 쓰기좋게 만드는 모델이 MVC 모델이다. (MVC 아키텍쳐)

WAS는 무슨 언어를 쓸까? 생각해보자.

컴퓨터라는 세상은 User mode/ kennel mode/ 하드웨어(H/w) 3개의 영역으로 나뉜다.

하드웨어 영역의 컴퓨터를 이루는 핵심적인 요소 중 하나가 cpu이다.

(cpu를 다른말로 Machine으로도 부른다.)

기본적으로 자바라는 프로그래밍언어는 ‘Platform independent’하다.

(여기서 플랫폼이라고 하면 운영체제와 Cpu를 말한다.)

즉, 운영체제와 Cpu가 뭐가되었든 상관없이 작동한다는 것이다. 이는 Cpu를 user모드에다가 소프트웨어로 구현했기 때문이다.

user모드에 구현된 Cpu는 Machine인데 소프트웨어로 구현되서 Virtual Machine, 또 자바라는 언어에 대해서만 작동하는 Cpu이기에 Java Virtual Machine(JVM)라고 부른다.

(JVM이 작동할 때는 JVM이 인식할 수 있는 JAVA byte code라는 기계어로 작동한다.)

프로그램을 개발할 때 JVM에서 작동할 수 있는 모듈들이 많아진다. (DB, 입출력 관련.. 등등) 이런것들을 다 모아서 하나의 새로운 소프트웨어를 만드는데, 이 자체로서 의미를 갖는게 아니라 이렇게 새로 만들어진 소프트웨어를 작동하게 만드는 또다른 소프트웨어가 존재한다. 소프트웨어를 위한 또다른 소프트웨어 이른바 Middleware라고 한다. (소프트웨어와 하드웨어의 중간고리)

이 Middleware 역할을 해주는 것중 하나가 WAS인 것이다.

이때 프로그래밍할때 초짜들이 수월하게 할 수 있도록 Middleware와 새로 만들어진 소프트웨어 사이에 Framework라는 것을 집어넣게 되는데, 이는 Framework에 의해서 개발이 이루어지도록 강제하여 개발을 수월하게 하기위함이다. 이 Framework 중 가장 많이 쓰는게 널리 알려진 Spring boot이다. 자바공화국인 대한민국에서 소위 웹에서 back 단위 서버개발을 하게되면 흔히 이수준에서 개발하게 되는 것이다. 동시에 이러한 것들과 함께 움직이는것으로 JSP, PHP, ASP 등이 있다. 또한 WAS 쪽에서 JAVA Script로 작동하는 것이 Node.js 이다. (Script만으로 해낼 수도 있다로 이해하면됨)

이로써 웹서비스를 이루는 구성요소 3가지가 있음을 알 수 있다.

Web Server (1- Tier)
WAS (1- Tier)
Database (1- Tier)

이 Tier 들이 힘을 합쳐 3-Tier Web Solution이라고 한다.

그럼 웹서비스의 성능이라고 하는 것이 어떻게 결정날까?

앞서 말했듯 어디서 누가 자료를 달라고하든지 처리를 해달라고 하든지 요청을 하면 Web Server가 수신했다가 WAS에 넘겨서 DB에서 처리한 후 Web Server 입장에서 응답이 와야 송/수신을 할 수 있다. 그러다보니 지연이 나거나 장애가 발생한다면 DB를 볼 필요가 있다. DB가 반응을 늦게한다면 즉, 응답속도가 얼마냐가 되느냐에 따라서 서비스 처리속도가 바뀐다.

이 성능 높일려고 허구헌날 해대는게 DB튜닝이다.

이외에 WAS 쪽에서도 처리연산을 오래해버리면 문제가 된다.

따라서 성능을 논하면 크게 두가지로 볼수 있다.바로 ‘DB와 WAS’

그래서 이 두가지를 열심히 모니터링하는게 있는데 바로 APM이다.

#APM: Application Performance Management/Monitoring

대표적으로 Scouter APM가 있고 그외 프로메테우스 등이 있다.

성능 얘기를 조금 더 첨언하자면, Request를 날렸을 때의 응답시간도 성능하고 관련있다. 이는 주로 네트워크 속도와 관련되어 있다.

틈새 용어정리

Web server의 경우 client을 맞이하는 경계에 있다고해서 Front-end라고 하고 DB의 경우 비슷한 이유로 뒷편에 있어서 Back-end라고 한다. 그래서 서버라고 하면 Front-end에서 Banck-end 사이에 서버들을 말하고 이것들을 모아둔 것을 서버 팜이라 한다.

최근의 웹은 이런 형태로만 가지않는다.

클라이언트에서 뭔가 요청해서 request가 가고 response가 오는 것은 예나지금이나 똑같지만, 달라진 점은 Get, POST, PUT, DELETE 등으로 request를 보내 Read 하던지 Write하던지 즉 입출력을 하면 옛날에는 HTML이 날라왔지만 요즘에는 단순히 [데이터]만 날라온다. 또한 이 데이터는 JSON형태로 날라온다. 진짜 자료만 덜렁오는거다.

왜그럴까?

최근에는 UI가 매우 다양해졌다. 애플, 안드로이드, PC, IOS PC 등등 그러다보니까 HTML 라는게 환경의 특수성의 영향을 많이받기때문에 서버쪽에서 UI별로 준비할게 아니라, 데이터만 덜렁 보내고 그 데이터를 가지고 클라이언트에서 자신에게 알맞은 HTML을 스스로 생성하는 것이다.

이렇게 생성할 때 프로그래밍 언어로 Java Script를 쓴다. 근데 또 JS로 코딩하다보면 코드가 길어지므로 여기도 Framework가 들어가는데 가장 대표적인 것이 React.js, Vue.js 등이 있다. 그러니까 브라우저가 뭐가 됐든 각자 생성되니 굉장히 좋아졌다 보면된다.

서버쪽에서 get이든 post 든 request가 날라오면 데이터를 어떤 웹시스템의 하나의 기능요소로서 CRUD 기능을 제공하면 클라이언트 입장에서는 쓰는 언어가 js가 됐든 뭐가됐든 CRUD가 수행되는 기능을 함수형태로 Call(호출)하면된다.

생성하던지 → CREATE
읽던지 → READ
쓸건지(덮어쓰거나 수정) → UPDATE
삭제 → DELETE

그래서 CRUD가 되는 RESTful API가 강조된다. API 형태로 만들고 그거에 따른 자료만 넘겨받는 방식으로써, 필요한 HTML은 스스로 생성하는 방식으로 웹이 발전했다.