한 번에 끝내는 DNS
DNS
- 도메인 네임으로 IPv4 주소를 검색해서 그 결과(IP 주소)를 알려주는 서비스를 제공한다.
- 도메인 네임:
www.naver.com
과 같은 이름
- 분산 구조형 데이터베이스
- 데이터베이스 시스템(DNS 네임서버)의 분산 구성
- 데이터 영역별 구분(Domain Zone) 및 분산관리
- 도메인의 네임서버 및 도메인 데이터는 해당 관리주체에 의해 독립적으로 관리됨
- 트리(tree) 구조의 도메인 네임(Domain Name) 체계
- Domain: 영역, 영토를 의미
- 도메인 네임의 자율적 생성
- 생성된 도메인 네임은 언제나 유일(Unique)하도록 네임 체계 구성
도메인 네임
www.naver.com
- 뒤로 갈수록 큰 개념이 된다.
- www은 naver에 속한 것이고, naver는 com에 속한 것이다.
www
는 호스트 네임이다.
naver.com
은 도메인 네임이다.
분산구조형
인터넷을 사용하는데 ISP(Internet Service Provider)는 KT를 사용하고 있다고 가정하자.
- 주소창에
www.naver.com
를 입력한다.
- 컴퓨터의 IP 설정에 포함된 DNS 서버 주소로 질의를 보낸다.
- 운영체제 내부에서 “
www.naver.com
로 접속하려고 하는데 IP 주소를 알려줘”라고 질의를 보낸다.
- 컴퓨터의 IP 설정에는 반드시 DNS 서버 주소가 포함되어 있다.
- DNS 서버가 IP 주소와 유효기간을 반환한다.
- IP 주소를 보고 접속한다.
DNS 주소
- 보통 ISP에서 정해준 것을 사용한다.
- DNS가 응답이 느려지면 인터넷 전체가 느려지는 일이 벌어진다.
- 사용하는 ISP의 DNS에 속한 게 아니라 다른 ISP에 세팅을 했다면, 접속할 때 다른 ISP에 가서 응답을 받아오기 때문에 내가 사용하는 주소에서 응답받는 것이 더 빠르다.
- 예를 들어, 구글 DNS(8.8.8.8)에 세팅을 했는데 네이버에 접속하려고 한다면…
DNS Cache
- 질의해서 IP 주소를 반환받으면, PC에서 IP 주소를 메모리에 저장해서 가지고 있다.
ipconfig/displaydns
로 확인 가능
- 다음에 똑같은 질의를 하면 DNS 캐시에서 읽어서 접속한다.
유효기간
- DNS는 IP 주소와 함께 유효기간을 반환한다.
DNS가 거짓말을 한다면?
- 큰 일이 날 것이다.
- 따라서 DNS는 강력한 보안이 적용되어 있다.
정리
- PC에는 다음 것들이 있다.
- DNS Cache는 유효기간이 만료될 때까지 메모리에 상주한다.
- 여기 들어있는 정보가 있다면 DNS에게 묻지 않는다.
- hosts 파일은 IP 주소와 URL을 써놓은 것이다.
- 여기 써져 있다면 DNS에게 묻지 않고, 여기 써진 대로 움직인다.
- 만약 DNS와 공유기 주소가 같다면, 공유기가 DNS 포워딩 기능을 해서 공유기가 DNS 역할을 약간 대행해주는 식으로 작동하기도 한다.
계층 구조
만약 아무도 www.naver.com의 주소를 물은 적이 없다면 어떻게 될까?
- DNS가 어떻게 작동하도록 설정했느냐에 따르기는 하지만 보편적으로
- Cache DNS에게 질의??
- Cache DNS가 RootDNS에게
com
을 담당하는 DNS를 알려달라고 요청한다.
- RootDNS는 DNS IP 목록을 반환한다.
- 목록 중 하나에게 naver 주소를 질의하고, 네이버 네임 서버를 응답받는다.
- 네이버 서버에게 이름이
www
인 컴퓨터가 있는지 물어보고, 네이버 서버는 IP 주소를 알려준다.
- Cache DNS는 IP와 도메인을 쌍으로 저장한다.
- 누군가 www.naver.com 주소로 접속하면 캐시된 걸로 접속한다.
트리 구조
- 정점에 있는 것이 RootDNS이다.
- 전세계에 13대 정도가 있다.
- 13대는 서로 동기화를 하고 있다.
- IANA.org에 가면 RootDNS를 알아낼 수 있다.
- DNS를 위한 DNS이다.
com
만 담당하는 DNS들이 여러 개 존재한다.
참고 사이트
우리가 주소창에 naver.com을 쳤을 때 일어나는 일
웹 기술 창시자와 대한민국 인터넷
웹 기술의 창시자
티모씨 버너스리
- CERN(입자물리연구소)에서 컨설턴트로 근무
- 정보검색 시스템 구축
- 이를 바탕으로 현재의 웹 기술을 창안
- HTML, HTTP의 창시자
HTML
- 연구소에서 논문을 읽어야 했다.
- 논문에는 참고문원(Reference)가 있다.
- 참고문원을 보고 다른 논문을 읽고, 그 논문의 참고문원을 보고 다시 다른 논문으로 가는 등의 작업을 한다.
- 문서 하나를 보고 다음 문서를 볼 때 쉽게 가기 위해, ‘문서 간 연결’을 고민했다.
- 이렇게 탄생한 것이 HTML이다.
- HTML의 정체성은 ‘문서’이다.
HTTP
- HTTP는 HTML 문서를 실어 나르기 위해 만들어졌다.
- 현재는 복잡해졌지만.
- 웹 기술의 본질은 HTML 문서를 잘 전달하는 것
- 인프라 스트럭처로 TCP/IP 즉 인터넷 기술을 활용했다.
- “HTTP://” 에서 “//”는 사실은 쓸모없는 것이며 큰 실수였다고 인터뷰했다.
대한민국 인터넷
- 대한민국 인터넷의 아버지, 전길남 박사님
- 아시아에서 최초이자 세계에서 두 번째로 인터넷을 구축했다.
URL과 URI
- Uniform Resource Locator (위치)
- Uniform Resource Identifier (식별자)
Resource
웹 기술에 한정지어서 생각해보자.
- Resource의 본질은 “파일”이다.
- 파일이 저장된 위치를 Resource Locator라고 본다.
- 웹에서 이 파일은 HTML, CSS, JS, Image 등이다.
URI 구조
- URI = scheme “:” [”//” authority] path [”?” query][”#” fragment]
URI와 URL
- Protocol://Address:Port number/Path(or filename)?Parameter=value
- Path는 디렉토리의 경로 개념을 생각하자.
- 특정 기준점(C://Program Files)을 기준으로 잡고, 그 하위의 어떤 파일에 접속한다.
- 파라미터가 하나 더 있으면 &Parameter=value로 덧붙인다.
- web은 보통 TCP 80번을 사용한다.
굵고 짧게 살펴보는 HTTP
HTTP
- HTTP는 HTML 문서를 전송 받기 위해 만들어진 응용 프로그램 계층 통신 프로토콜이다.
- L7에 속한 프로토콜
- L7(L5 이상)은 소켓 통신이고, 스트림 데이터이다. 즉, 시작은 확실하지만 끝이 어딘지는 해석해봐야 한다. → 해석하는 규정이 HTTP에 있다.
- 1996년에 1.0 스펙이 발표됐으며 1999년 6월에 1.1이 발표됐다.
- 기본적으로 클라이언트의 요청에 대응하는 응답형식으로 작동한다.
- 헤더는 다음과 같이 분류된다.
- 문자열로 되어 있어서 내용을 이해하기가 생각보다 쉽다.
- 요청에 사용되는 메서드는 주로 GET, POST이다.
HTTP 응답 코드
- 200 OK
- 201 Create
- 301 Moved permanently
- 302 Found
- 400 Bad request
- 403 Forbidden
- 404 Not found
- 500 Internal server error
HTTP method
- GET
- POST
- HEAD
- TRACE
- PUT
- DELETE
- OPTIONS
- CONNECT
그림 한 장으로 외워서 끝내는 웹 서비스 구조 기본이론
웹 서비스 기본 구조
- HTTP는 TCP 연결 그 다음에 존재한다.
- HTTP 트래픽은 소켓 수준에서 만들어지는 거고, 스트림(끝을 알기 어려운 데이터)가 나열된다.
- 따라서 웹에 대한 이야기를 할 때 기본적으로 패킷이나 세그먼트 등의 이야기는 나오지 않는다.
웹 통신
- 웹을 이루고 있는 가장 근간이 되는 두 축의 기술은 HTML과 HTTP이다.
- 웹 서버의 앞에는 보통 라우터 같은 기본적인 장비를 제외하고서 항상 거의 3개 정도가 있다.
- 클라이언트와 웹 서버는 TCP/IP 기반에서 연결하고, 이 연결을 기반으로 HTTP 통신이 이루어진다.
초창기 웹 통신
- 초창기 클라이언트는 ‘문서뷰어’였다.
- HTML 문서 속의 링크가 있어서, 링크를 클릭하면 아래 과정을 거친다.
- HTTP request GET으로 요청
- HTML 문서 반환
- HTML 문서를 화면에 표시한다.
개발 시 설계 원칙
- 아래 영역들의 세계를 구분하라
- 좋은 설계 원칙은 유지 보수 문제를 따진다.
- 구분하지 않으면, 자료구조(Data) 변경하면 UI도 고쳐야 하게 된다.
변천사
- HTML 문서를 예쁘게 꾸미고 싶어서 문법을 집어넣으려 하는데, 둘을 섞으면 나쁘므로 분리했다.
- 화면을 꾸미자고 논문을 뜯어 고치면 안되므로.
- 이렇게 분리한 화면을 예쁘게 꾸미기 위한 요소가 CSS(스타일 시트)이다.
- HTML이 Data에 해당
- 넷스케이프 내비게이터(Netscape Navigator)
- 정적인 문서에 움직임을 넣거나 동적인 제어가 가능한 무언가를 만들려 했다.
- 이 동적 움직임에는 규칙이 따르기 마련이고, 이러한 규칙을 스크립트 형태로 기술하게 된다.
- 이렇게 탄생한 것이 Mocha script이다. 모카 스크립트는 이후 Live script → JavaScript 순서로 이름을 바꾸었다.
- HTML 문서가 오면 화면에 렌더링했는데, 렌더링하기 전 구문 분석부터 해야 한다.
- Text와 Tag를 분리한 후, 태그를 해석해서 그에 맞게 렌더링해야 한다.
- 브라우저를 이루는 구성 요소
- 구문 분석기 (파서)
- 렌더링
- 핵심적인 역할을 하는 엔진
- JS 엔진
- 즉, CSS도 나오고 JS도 추가되고 그랬다. → 움직임(동적) 추가됨.
POST의 등장
- GET은 단방향이어서 적극적인 상호작용을 할 수 없었다.
- POST가 포함되면서 양방향 상호작용을 할 수 있게 됐다.
- 양방향 상호작용이 되면서 ‘상태 전이’가 필요해졌다.
- HTTP는 Stateless(무상태)이므로 저장을 안했다.
- 상호작용 과정에서 전이 과정을 어딘가에 기억(저장)해야 했다.
- 양방향이므로 서버와 클라이언트 모두 ‘기억’하는 것을 구현했다.
- 클라이언트에서는 쿠키의 형태로 구현되었다.
- 서버는 기억해야 할 것이 많아서(사용자 별로 기억해야 함) 아카이브 형태로 Database로 만들게 된다.
💡 쿠키
key와 value 형태로 되어 있다.
WAS
- 예를 들어 로그인을 한다면, POST에서는
id="tester"&password="1234"
를 보내야 한다.
- 이렇게 전송하는 것들은 서버 관점에서 “원격지 사용자 입력”이 된다.
- 원격지 사용자 입력은 서버 관점에서는 신뢰해서는 안 된다.
- 반드시 검증해야 한다.
- 즉, 원격지 사용자 입력은 검증 대상이다.
- 데이터베이스와 연동하는 것은 웹 서버가 하지 않고, 중간에 중개해주는 역할을 담당하는 서버가 하나 더 들어가게 된다.
- 보통 웹 서비스는 “웹 서버 - 중개 서버 - 데이터베이스”로 연결이 되어 있다.
- 웹 서버는 기본적으로 송수신 담당이다. → 리소스를 보내고 받는다.
- 데이터베이스의 역할은 자료 담당이다. → 기억
- 중개 서버는 연산을 담당하는 요소로 작용한다. → 동적인 HTML이 생성된다.
- 중개 서버는 ODBC, JDBC 같은 인터페이스로 DB에 연결해서 조회한다.
- 조회 결과가 있으면(Found) 정보를 화면에 보여주고, 조회 결과가 없으면(Not Found) 정보를 보여주지 않는 등의 결과가 나온다.
- 이렇게 중간에서 처리를 담당하는 서버를 WAS(Web Application Server)라고 한다.
- WAS에서…
- 눈에 보이는 역할(HTML 문서 등)을 하는 View
- 자료를 결합해서 최종적인 View를 생성하는 Model
- 네트워크 상에서 어떤 리퀘스트에 대한 제어 체계를 포함하는 Controll 이라는 제어 체계
- 합쳐서 MVC 아키텍처가 된다.
WAS와 RESTful API 그리고 JVM
WAS
- 웹 서비스 시스템이 얼마나 잘 작동하고 있는가를 항상 모니터링 해야 한다.
- 네트워크가 아무리 빨라도 DB가 응답을 안하면 굉장히 느려진다.
- 응답 시간은 서비스의 어떤 품질을 확인하는데 매우 중대한 역할을 한다.
- WAS와 Databasae 장치를 모니터링해서 DB 응답 시간과 WAS 상태를 모니터링해서 웹 어플리케이션이 잘 작동하는지 관리하는 시스템을 APM라고 한다.
- 모니터링
- 응답 시간
- JVM
JVM
- Java를 위해서 소프트웨어로 구현된 CPU라고 생각하면 된다.
- 이 CPU가 인식할 수 있는 명령체계는 Java ByteCode이다.
서블릿과 WAS
- 미들웨어
- Java byte code를 아래에 깔고 어플리케이션을 작동시켜주는 소프트웨어
- 또 다른 소프트웨어가 잘 작동할 수 있도록 도와주는 소프트웨어
- 모든 프로그램들이 공통으로 필요한 TCP/IP 통신, DB 입출력, 파일 입출력 등 기본 기능을 가지고 있다.
- 미들웨어가 이러한 기본 기능을 제공하므로 소프트웨어는 뭐… 필요한 것만 개발하면 된다.
- JSP는 서블릿이라는 형태로 들어간다.
- JSP를 활용하면 몇 개는 가져다 쓰면 되고… 함수 하나만 짜면 되고… 알아서 번역해서 들어가고….
- 이런 애들(JSP, PHP, ASP)을 감싸 안아주고 연동시켜주는 미들웨어를 서블릿(Suvlet)이라고 한다.
- 전체를 서블릿 컨테이너라고 부른다.
- 이런 미들웨어(서블릿 컨테이너?)를 다른 말로 WAS라고 한다.
- 스프링도 컨테이너.
API
- 서버에서 HTML을 만들어서 보내는데, 클라이언트 쪽 사용자 환경이 다양해졌다.
- HTML 문서는 결국 UI와 Data 분리가 안된다는 단점이 있다.
- 일정 수준의 UI 적 요소를 갖고 있다.
- 사용자 환경마다 UI를 따로 만들어야 하는 문제 발생
- 따라서 UI와 데이터를 분리하자는 시도가 일어난다.
- 요청 시, 응답 값이 Data(자료)만 날아오게 변경했다.
- XML, JSON 형태로 온다.
- JavaScript 기반의 소프트웨어가 실행되어서(클라이언트 사이드에서) 데이터를 받아서 그 자리에서 HTML을 생성한다.
- JavaScript가 사용자 환경에 따라 UI를 생성해준다.
- JavaScript Framework로 React, Vue 등이 있다.
RESTful API
- 리퀘스트는 어떤 처리에 대한 리퀘스트가 되었다.
- CRUD를 각각 함수 형태(객체든 뭐든 기능 요소 단위)로 만들고, 사용자가 이 함수를 호출하게 한다.
- 함수를 사용자가 호출하는 것이 리퀘스트의 또 다른 형태가 된다.
- 이 함수 자체를 URI로 만든다. → URI로 기술
- 이 함수를 다른 말로 API라고 부른다.
- 웹에서 이런 걸 구현한 함수를 RESTful API라고 부른다.
보안
보안 시스템
백엔드 개발하면 보안도 신경 써야 한다.
웹 서버 앞단에는 항상 순서대로 아래 것들이 들어간다. (앞에서 미리 언급했던 라우터 같은 장비 외에 들어가는 것들)
- IPS 보안 장치
- 1차 방어체계
- Intrusion Prevention System
- IPS는 기본적으로 패킷단위 데이터를 처리하면서 공격을 방어합니다. DPI(Deep Packet Inspection)를 실시합니다만 응용 프로그램 수준 스트림 데이터를 정밀하게 관찰하기에는 부족함이 있습니다. 이 때문에 웹 서비스를 보호하기 위해서는 WAF(Web Application Firewall, 웹 방화벽) 시스템을 운영하는 것이 일반적입니다.
- SSL 처리를 담당하는 가속기
- 이게 중간에 있으면 HTTPS 통신이 된다.
- 이걸 지나면 HTTP 평문으로 바뀐다.
- 웹 서버를 보호하는 웹 어플리케이션 파이어월
- 2차 방어체계
- 가끔 웹 서버와 WAS 사이에 들어가 있을 수도 있다.
SQL Injection
- 원격지 사용자 입력은 신뢰하지 말아야 한다.
- 사용자 입력 속에 SQL 문에 있는지 조사한다.
- 있으면 SQL Injection 공격이 되는지 검증한다.
추가로
- 자바스크립트는 클라이언트에서 실행이 이루어진다.
- 검증은 서버에서 해야 한다.
Reference
참고 강의
외워서 끝내는 네트워크 핵심이론 - 기초 강의 - 인프런
참고 사이트
Apache HTTP Server? Apache Tomcat? 서버 바로 알기