L5 LEVEL

1. DNS

- 여태까지 살펴 본 L2 ~ L4는 인터넷을 지탱하는 인프라 계층이다.

- L5부터는 이러한 인프라를 활용한 애플리케이션의 레벨인데, 이 중에서도 인프라 역할을 하는 것이 대표적으로 DNS이다.

 

 

 

- DNS는 Domain Name Service의 약자이고, 도메인 이름으로 IP 주소를 검색하도록 돕는 서비스다.

- "www.naver.com"이라는 DNS 주소에서 "naver"와 "com"은 도메인 이름을, "www"는 호스트 이름을 담당한다.

    - 참고로, "www"가 더 작은 개념이다.

DNS 주소의 트리 형태 계층

 

 

 

DNS 서비스의 과정

- 모든 클라이언트 PC에는 IP 설정이 있고, 거기에 DNS 서비스를 받을 주소가 적혀 있다.

- PC에서 도메인 이름을 제출하고 접속을 요청하면, 이 도메인 이름을 DNS 서비스에 질의한다.

 

- 이 때 보통 ISP(Internet Service Provider)가 정해준 DNS 서비스로 넘어간다.

- DNS 서비스 DB에서 도메인 이름과 일치하는 IP 주소를 클라이언트에게 돌려주고, 이 IP 주소로 서버에 접속할 수 있게 된다.

 

- 그리고 한 번 질의해서 얻은 도메인 이름은 일정 기간동안 PC의 DNS 캐시에 캐싱된다.

- 이와 비슷한 hosts 파일도 있는데, hosts 파일은 사용자가 직접 업데이트 해야하며 일정 기간이 지나도 내용이 사라지지 않는다.

 

 

 

- 그런데 만약 내가 질의한 DNS 서비스의 DB에 해당 도메인 이름이 저장되어 있지 않다면?

- 그러면 그 DNS 서비스는 Root DNS에 접근하여 자신이 가진 도메인 이름과 관련한 다른 DNS DB를 반환받는다.

- DNS DB들에 질의하면서 서버 IP 정보를 얻고, 서버에 해당 호스트(예를 들면 www)가 존재하는지 확인한 후 클라이언트에게 알린다.

 

 

 

2. URL과 URI

- URL : Unified Resource Locator

- URI : Unified Resource Identifier

- URI는 URL과 같은 위치 개념을 포함해서 이름 개념의 URN도 포괄하는 '식별자' 개념이다.

 

 

 

- Locator가 되었든, Identifier가 되었든, 결국 URL/URI는 리소스를 찾도록 도와주는 정보가 된다.

- 그리고 여기서 리소스는 파일이 된다.

    - 참고로, http 웹에서 파일은 html 파일과 같은 것들을 포함한다.

 

 

 

URL 구조

- 예시 : https://jinkonu.tistory.com/manage/newpost/?type=post&returnURL=%2Fmanage%2Fposts%2F

- Protocol에는 "http"나 "https"가 들어간다.

- Address에는 "www.naver.com"과 같은 주소가 들어간다.

- Port에는 포트 번호가 들어가는데

    - 웹 브라우징은 일관적으로 "http" 프로토콜에 대해 80번을 사용하므로 생략 가능하다.

- Path는 도메인 주소에 일치하는 서버 안에서의 파일 경로가 들어간다.

    - 참고로 파일 경로를 쓰지 않으면, 서버에서 정한 상대적 시작 경로에 있는 "index.html" 파일을 요청하게 된다.

- "?" 이후에는 파라미터와 값이 쌍으로 들어가고, 이는 곧 서버에 요청과 함께 넘어간다.

 

 

 

3. HTTP

- HTTP는 HTML 문서를 주고받기 위한 프로토콜이다.

- 기본적으로 클라이언트의 리소스 요청과 이에 대한 서버의 응답으로 이뤄져 있다.

 

 

 

- L5 이상 레벨에서의 데이터는 스트림으로 표현된다.

- 그런데 스트림에는 데이터 단위의 제한이 없고, 그래서 끝을 알기 어렵다.

- 이에 대해 HTTP 헤더에서 규정하고 있으며, HTTP 헤더는 프레임, 세그먼트 등의 헤더와 달리 문자열로 되어 있다는 특징을 갖는다.

 

 

 

- 위 그림은 http 통신을 추적한 결과다.

- 빨간 글씨는 클라이언트의 GET 요청 내용이고, 파란 글씨는 이에 대한 서버의 응답 내용이다.

 

 

 

HTTP 메서드

- GET : 다운로드 개념

- POST : 업로드 개념

- HEAD

- PUT

- DELETE

- OPTIONS

- CONNECT

 

 

 

- 위와 같은 HTTP 메서드 종류가 있는데, 서버에 어떤 요청을 하는 것인지 알리기 위해 필요하다.

- 참고로, HTTP 메서드 중 GET과 POST를 제외하고는 거의 쓰이지 않는다.

 

 

 

 

HTTP 응답 코드

- 200 OK : 요청을 정상적으로 처리함

- 201 Create : 요청에 대한 새로운 자원을 생성하는 데 성공함

- 400 Bad Request

- 404 NOT FOUND : 웹 개발하다가 자주 발견하는데, 클라이언트 요청 내 경로에 해당하는 리소스가 없을 때 나타난다.

- 500 Internal Server Error : 서버 백엔드 단에서 에러가 발생했을 때

 

 

 

4. 웹 서비스 구조에 대한 전체적인 그림

데이터

- HTTP 세션 이후 넘기는 데이터의 HTTP 단위는 "스트림"

- 즉, 데이터 크기의 끝을 미리 알 수 없이 크다.

- 그러나 "세그먼트"는 1500바이트의 MTU를 가지기 때문에 스트림을 자를 수밖에 없다.

    - 그리고 세그먼트는 다시 "패킷"으로 싸인다.

 

 

 

클라이언트와 웹 사이의 연결

- '연결' 상태의 개념은 TCP에 있을 뿐, HTTP는 stateless하다.

 

 

 

웹 서비스 기본 명령

- 클라이언트에서 HTML 문서 전송요청

- 서버에서 이에 맞는 HTML 문서를 전송

- 수신한 문서를 클라이언트 측 브라우저가 뷰어를 통해 보여준다.

 

 

 

개발 시 설계원칙

- 궁극적 목표는 "유지보수의 편리성"

- 이를 위해 유저 인터페이스, 데이터, 비즈니스 로직을 서로 분리해아 한다.

 

 

 

- 따라서 데이터를 보여주는 유저 인터페이스를 따로 발전시키기 위해 "CSS"가 등장한다.

- 그리고 정적인 문서뷰어를 동적으로 변환하기 위해, "자바스크립트"가 등장한다.

 

 

 

- 결국 HTML "구문 분석"하는 작업과 화면으로 바꾸는 "렌더링" 작업, "JS 엔진" 작업의 단계를 이루게 된다.

- 그리고 웹 서버에서는 HTML + { CSS, Javascript }를 전송하게 된다.

 

 

 

클라이언트와 웹의 상호작용

- 위에서 언급한 연결은 "단방향"의 성격이 강하다.

- 그러나 반대로 클라이언트가 웹에게 정보를 전달하는 방식도 고려해야 한다.

 

 

 

- 이를 구현하기 위해 HTTP의 "POST" 명령어를 대표적으로 활용한다.

- 예를 들어, 사용자가 로그인 폼에 아이디와 비밀번호를 입력하여 웹 서버에 전달한다.

 

 

 

- POST로 전달되는 데이터를 "원격지 사용자 입력"이라고 한다.

- 그리고 원격지 사용자 입력은 반드시 서버 측에서 검증의 대상이 되어야 한다.

- 검증은 "데이터 송수신"을 담당하는 웹 서버가 "데이터를 처리(WAS)"하는 서버를 거쳐 "DB" 서버에서 조회하며 이뤄진다.

- 검증의 부산물로 남은 데이터(예를 들면 회원명)는 새로운 HTML을 동적으로 생성하여 클라이언트에 반환된다.

 

 

 

- 그런데 양방향 상호작용에는 상태전이가 필수적인데, HTTP는 stateless하다.

- 따라서 상태전이를 서로 기억하기 위해 클라이언트와 서버 각각에서 구현하게 된다.

- 이 때, 클라이언트가 상태를 기억하기 위한 부산물로 "쿠키"를 가진다.

- 서버측에서는 여러 클라이언트와의 상태를 기억하기 위해 DB를 따로 가진다.

 

 

 

5. WAS와 RESTful API, JVM

WAS

- 위에서 언급한 웹서버, WAS, DB가 각각 하나의 티어를 담당하여 3 티어 솔루션을 이룬다.

- 그리고 이들간의 데이터 교환이 빠르고 정확하게 이뤄져야 효과적으로 서비스를 운영할 수 있다.

- APM(Application Performance Management)은 WAS와 DB 간의 운영을 감시하고 관리한다.

    - 대표적으로 "스카우터"라고 하는 오픈 소스가 있다.

    - APM은 JVM을 감시하여 현재 상태를 개발자에게 전달해준다.

 

 

 

JVM

- JVM은 유저 모드 레벨에서 운영체제에 독립되어 자바를 위해 구현된 소프트웨어 형태의 CPU다.

- 그 위에는 자바 바이트 코드가 있다.

- 그 위(미들웨어)에는 애플리케이션 작동에 필요한 TCP/IP, DB, File I/O 등의 기능이 구현되어 있다.

 

 

 

- JSP는 위 기능들을 활용하는 애플리케이션으로서 서블릿의 형태로 서블릿 컨테이너에 들어간다.

- 그리고 미들웨어는 서블릿과 기본 기능들을 엮어주는 역할을 하는데, 이를 "WAS"라고 칭한다.

    - 대표적인 WAS는 "톰캣"이 있다.

- 그리고 서블릿 위에 스프링 프레임워크가 올라간다.

 

 

 

RESTful API

- HTML 문서에 남아 있던 UI적 요소를 완전히 배제하고자, 서버에서는 JSON 혹은 XML과 같은 순수 데이터를 보낸다.

- 이를 수신한 클라이언트 측에서 Javascript를 통해 HTML을 생성한다.

    - 덕분에 다양한 스펙을 가진 기기들 사이에서 동일한 화면을 경험할 수 있게 된다.

 

 

 

- 반대로 클라이언트 측에서는 CRUD 명령을 서버 측에 보낸다.

- 서버에는 CRUD에 맞는 함수가 URI로서 존재한다.

    - 이를 RESTful API라고 부른다.