✨웹 서비스 구조 기본 이론

참고 자료 : 널널한 개발자님의 외워서 끝내는 네트워크 핵심이론 - 기초

HTTP통신과 JavaScript

 

클라이언트와 서버가 HTTP통신을 하기 위해서는 TCP Connection과 IP 통신이 이루어져야 가능하다.

 

URI를 브라우저 입력하면 클라이언트는 서버로부터 HTTP Request를 보낸다. 맨 처음 사용되었던 메서드는 GET으로 웹 서버에 있는 HTML리소스를 가져오는 용도로 사용되었다. 이 후, 스타일적 보완을 위한 CSS와 여러 파일들을 HTML리소스 안에 함께 불러올 수 있게 되었다. 이렇게 가져온 HTML파일을 구문분석을 한 후에 브라우저에 렌더링하면 사용자가 볼 수 있게 된다.

 

여기까지의 브라우저로 보여지는 문서는 정적인 특징을 가지고 있다. 즉, 사용자와의 인터렉션과 동적인 작업이 불가하다.

 

 

사람들은 정적 페이지가 아닌 동적 페이지를 원하기 시작했다. 이를 위해서 규칙을 지정하게 되고 자바스크립트가 탄생했다.

이제 브라우저는 HTML과 CSS 리소스를 렌더링 엔진에서 처리하고 자바스크립트 코드를 자바스크립트 엔진에서 처리할 수 있게 되었다. 또한 HTML 구문분석과 JS 구문분석을 동기적으로 처리하는 과정에서 비동기적으로 처리할 수 있는 기술로 발전한다.

 

 

이제 사용자는 웹 페이지와 인터렉션을 할 수 있고, 자신이 입력한 정보를 서버에 요청해서 파일을 업로드하거나 로그인을 하는 기능을 구현하게 된다. 이때 사용하는 메서드가 POST이다. 그리고 동적 HTML 문서를 응답받는다.

 

하지만 원격지에서 사용자가 입력한 데이터는 보안상 검증 대상이 된다. 회원가입도 안한 유저가 서비스에 접속하는 상황이 발생하면 안되기 때문이다. 사용자가 입력한 데이터를 검증할 수 있는 "무언가"가 필요한 시점이 온 것이다.

---

Database와 WAS

 

이제 구체적인 사용자의 자료를 관리할 수 있는 데이터베이스가 등장했다. 그리고 WAS도 등장했다.

Web Server가 송/수신을 담당한다면 WAS는 DB와 Server 사이에서 로직 처리를 담당한다.

WAS는 데이터 관리 로직, UI로직, 컨트롤러로 구성되고 이 패턴을 MVC패턴이라고 한다.

MVC 패턴은 데이터 로직과 UI로직을 분리한 패턴이다.

 

클라이언트가 아이디와 패스워드와 함께 로그인 요청을 보내면 웹 서버는 수신하여 WAS로 보낸다. WAS의 데이터 로직에는 "데이터베이스에 id가 'tester', password가 '1234'인 유저가 있다면 데이터를 가져와줘."라고 설정되어있다. 만약 유저를 찾았다면 데이터를 받아와 UI로직에서 동적 HTML을 생성하고 다시 Server에 전달하여 Server가 클라이언트에게 송신하게 된다. 만약 유저를 찾지 못했어도 그에 맞는 동적 HTML을 생성해서 전달해준다. 다만, 유저를 찾았을 때와는 다른 UI로 구현된다.

 

이렇게 클라이언트와 서버 로직의 양방향 상호작용을 통해 클라이언트, 서버의 상태전이가 발생했다.

 

여기서 stateful과 stateless개념을 짚고 넘어가자. sateless는 서버가 클라이언트의 이전 상태를 보존하지 않는다는 의미이다. 반대로 stateful은 서버가 클라이언트의 이전 상태를 유지하고 있어야 하므로 요청을 항상 같은 서버에 보내야한다. 하지만 stateless는 클라이언트 요청에 어느 서버가 응답해도 상관이 없기 때문에 클라이언트 요청이 매우 많아도 서버를 증설해서 해결해주면 된다.

 

HTTP는 stateless하기 때문에 이전 상태가 변경되어도 서버는 이전 상태를 보존하지 않기 때문에 알지 못한다.

이 말은 로그인 전 상태에서 로그인 상태로 변경되어도 마이페이지 같은 기능을 사용하기 위해서 계속해서 내 ID와 Password정보를 서버에게 알려주어서 로그인 상태를 유지해야한다는 것이다. 때문에 변경된 상태에 대해서 클라이언트, 서버 모두 기억할 수 있는 기술이 필요해졌고 이에 따라 탄생한 것이 "Cookie"다.

---

APM과 JVM

 

서버 쪽 로직을 살펴보면 송/수신을 담당하는 서버와 처리를 담당하는 WAS, 자료를 담당하는 DB로 크게 나눌 수 있다.

서버의 성능에서 중요한 것이 DB의 응답시간과 WAS의 로직처리이다. 아무리 네트워크가 빠르다고 해도 DB로부터 응답시간이 느리거나 WAS에서 로직처리시간이 오래 걸린다면 말짱 도루묵이다.

 

그래서 APM을 통해 DB응답시간과 WAS로직을 모니터링한다. 여기서 WAS로직을 모니터링한다는 것은 JVM을 모니터링하는 것이다.

 

JVM은 User Mode 단계에서 구현한 JAVA Virtual Machine이다. 즉, 어플리케이션 단계에서 구현한 CPU라고 생각하면 된다.

이 JVM과 애플리케이션 중간에 middle ware가 존재하게 되는데 middle ware는 다른 S/W가 잘 작동하도록 도와주는 역할이다.

예를 들어 TCP/IP나 DB I/O기능, File I/O기능은 모든 애플리케이션에서 필요로 하는 기능들이다. 이러한 기능들을 middle ware에 미리 다 구현해놓는다. 그리고 개발자들이 JSP나 PHP를 통해 애플리케이션 개발을 하고 middle ware에 집어넣으면 애플리케이션을 작동하도록 구현할 수 있다.

 

결국에 구현한 로직들을 실행시키는 JVM을 모니터링함으로써 WAS로직 처리가 원활한 지 확인할 수 있는 것이다.

---

SSR과 RESTful API

 

그렇다면 다시 클라이언트와 서버와의 관계로 넘어와보자.

이제까지는 클라이언트는 서버 쪽에서 UI와 데이터가 결합된 하나의 HTML문서를 받아왔다. 하지만 핸드폰, 태블릿 등 기기가 다양해지면서 기기에 맞는 UI를 보여주어야한다. 그러기 위해서 서버에 UI와 데이터를 한번에 받아오는 것이 아니라 JSON, XML형식의 데이터만을 받아와 클라이언트 쪽의 자바스크립트 소프트웨어에게 건내주면 HTML을 생성해서 기기에 맞게 뿌려주는 형태로 변화하게 되었다. 이를 CSR(Client Side Rendering)이라고 하며 대표적인 라이브러리로 React.js가 있다. CSR과 반대되는 개념이 SSR인데 요즘은 웹 페이지 로딩, 검색 엔진 최적화의 이유로 SSR을 사용하는 Next.js를 사용해 개발하기도 한다.

 

그리고 클라이언트에 대한 요청을 처리하는 기능을 서버에서 함수의 형태로 구현해두었는데 이를 API라고 부르고, CRUD와 같이 서버의 리소스에 접근하는 방식을 규정한 아키텍처가 REST이다. 그래서 REST 아키텍처 기반으로 API를 구현한 것이 REST API이고, REST API 관련 설계 규칙(표준)을 준수해 만들어진 REST API를 RESTful API라고 부른다. 

---

보안 기술과 SSL

 

보안 관련 기술에서 1차 보안 계층인 IPS와 2차 보안 계층인 WAF가 있다.

보안 관련 수업은 아니여서 깊게 다루진 않았다.

 

살펴보아야할 부분은 SSL인데 보안 소켓 계층으로 웹사이트와 브라우저 사이 또는 두 서버 사이에서 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 기술이다.

IPS와 WAF사이에 SSL이 들어가게 되면 HTTP 프로토콜에서 HTTPS 프로토콜로 작동한다. HTTP는 암호화되지 않은 데이터를 전송하기 때문에 보안에 취약하다. 때문에 SSL 인증서를 통해 브라우저와 해당 인증서를 공유함으로써 서버와 클라이언트가 암호화된 데이터를 교환할 수 있도록 하는 것이다.

 

또한 사용자 입력에 SQL 삽입문이 있는 경우 서버쪽에서 체크해서 접근하지 못하도록 블락킹을 한다.

JS는 파일은 서버에 있지만 실행은 클라이언트에서 실행된다. 때문에 완벽한 조작 방지를 하지 못한다. 그렇기에 원격 사용자 입력에 대한 보안 방지는 서버에서 진행하는 것이 옳다.