웹과 인터넷, DNS

 

 

웹의 본질이란 무엇인가 

웹의 본질은 요청을 주고 결과를 받는 그 사이의 모든 것을 의미한다. 

그 요청 - 반환이란 무엇일까? 그 주체는 웹 브라우저와 웹 서버 2개로 구성된다. 웹 브라우저와 웹 서버의 요청과 반환은, 일반적으로 우리가 생각하는 프론트엔드와 백엔드 사이의 데이터나 웹 페이지 교환을 의미한다. 

 

웹 서버와 웹 서버 간의 요청 반환은, Open API 등이 있다. 예를 들면, AWS의 감성 분석 모델인 Comprehend를 사용하려면 AWS Comprehend API를 요청해야 한다. 이는 프론트엔드가 아닌 백엔드에서 요청하기 때문에, 웹 서버간의 요청과 반환이 되겠다. 

 

1. Monolithic 모놀리딕

하나의 서버가 모든 서비스를 관장하는 것을 의미한다. 하지만, 만약 한쪽 서비스가 문제가 생겨 모든 서버에 영향을 준다면 기타 서비스들을 전부 사용 불가하게 될 것이다. 이를 SPOF(Single Point of Failure)라고 하는데, 단일 이슈가 전체 이슈로 퍼지는 경우다. 

 

2. MAS(Microservice Architecture)

하나의 서버는 하나의 서비스만 관장한다. MSA를 사용하는 곳이라면 각자 담당한 서비스를 갖는 수많은 서버가 있기 때문에 서버간 교환이 필요하다.  앞선 모놀리딕 보다 서비스 마다 서버를 가지고 있기 때문에 SPOF를 피할 수 있다. 하지만 서비스가 많아지면 서버도 수백개가 되기 때문에, 어떤 서버의 어떤 API를 사용해야 할지 정리정돈과 버전관리가 어려워진다. 

 

3. REST API 

Method + URI라는 2가지 요소로 구성되며, RESTful API는 REST 철학을 적용한 방식을 이야기한다. 

Method = 동사, 어떤 행위(method)를 할 것인지, URI(URL) = 명사, 어떤 자원(Resource)에 대한 것을 의미.

HTTP 상에서 요청과 반환을 위해 기본적으로 REST API를 사용한다. 

URL(Location): https://naver.com -> 장소
URI(Indicator): https://naver.com/favorite/food -> 장소 내 지정 
food는 Path Variable, Query Parameter는 /search?page=4 2가지의 변수가 있다.

 

4. GraphQL

REST API는 각 비지니스 도메인마다 수많은 API들을 일일히 만들어야하는 단점이 있다. 예를 들어, 유저 도메인에 대한 단순 API를 만든다하더라도, GET, POST, DELETE, PUT, PATCH 5개를 유저 도메인/결제 도메인으로 합치게 되면 아마 수백개의 API를 만들어야 할지도 모른다. 이를 Query 형태로 만들 수 있도록 하는 것이 GraphQL이다.

 

//schema.graphqls

type Query {
    allBooks: [Book]
    book(id: String!): Book
}

type Book {
    id: String
    title: String
    author: String
    pageCount: Int
}

//Graph Resolver

@Component
public class Query implements GraphQLQueryResolver {
    private final BookRepository bookRepository;

    public Query(BookRepository bookRepository) {
        this.bookRepository = bookRepository;
    }

    public List<Book> allBooks() {
        return bookRepository.getAllBooks();
    }

    public Book book(String id) {
        return bookRepository.getBookById(id);
    }
}

//http://localhost:8080/graphql에 다음과 같은 GraphQL 쿼리를 보낸다.

query {
  allBooks {
    id
    title
    author
    pageCount
  }
}
//또는
query {
  book(id: "1") {
    title
    author
  }
}

//그러면, Resolver에서 실행된다.

 

웹의 등장 

초기에는 세계의 여러 대학과 연구 기관에서 일하는 물리학자들의 상호간 신속한 정보 교환과 공동 연구를 위해 웹이 개발 되었다. 여러 컴퓨터에 저장된 논문, 실험 결과 등의 문서들을 공유하기 위한 기술로써 사용한 것이다.

논문, 실험결과 등의 문서는 웹 페이지가 되었다. 이 때, 웹 페이지는 HTML(Hypertext Markup Language)의 특수한 언어로 제작되어 인간이 바로 읽을 수가 없었다. 때문에 웹 페이지 리더기인 웹 브라우저가 필요하게 된 것이다. 웹 서버는 각 컴퓨터가 된다. 

 

1. 웹 페이지

구성 1: HTML 

구성 2: CSS 

구성 3: JS

JS는 유저와 웹 페이지 사이의 모든 상호작용을 담당한다. 

CSS Cascading

1. Specificity 명시도에 따라 명료하게 정의될수록 우선순위가 높다.
2. 아래 정의된 것이 최종적으로 적용된다.

아래는 CSS 사용 시 적용하는 방법 3가지를 작성했다.
1. .이면 class
2. #이면 id
3. 개발자 도구에서 JS를 disable하면 복사 가능하다

 

 

인터넷

앞서 웹 서버를 내부 네트워크에서 사용했다고 언급했다. 하지만, 논문과 연구 결과를 세상에 알리고 또 다른 연구들에 접근하기 위해 외부 네트워크와 연결이 필요했다.

 

Intranet(사내망) 

대학, 연구기관, 집과 같이 갇힌 공간에 국한된 네트워크다. 외부로 트래픽이 나가지 않아 보안을 위해, 혹은 개인/단체적 활동을 위해 사용한다. 

대표적으로 LAN이 있는데, MineCraft와 같이 온라인 서비스가 불가능한 경우 친구와 단둘이 방을 만들어 플레이 하는 것과 같은 의미다. 그러나 만약 연결되고자 하는 서로가 다른 국가에 있다면 어떻게 할까? 그럴 때는 가상 인트라넷인 VPN을 사용한다. 

VPN(Virtual Private Network)은 우회 프로그램으로 이해하고 있지만 정확한 원리로는 현재 A 국가에 있는 사람을 B 국가에 있는 사람으로 가장하는 원리다. 

 

인터넷 

외부와 연결되고자하는 인트라넷들을 외부로 모두 연결한 네트워크를 말한다. 이때, 외부와 연결되는 톨게이트와 같은 연결을 하는 게이트웨이를 사용한다.

API GateWay(GW)

그래서 등장한 것이 API GW다. 모든 서버에 대한 모든 API 호출을 중앙화 한다.각 서버마다 어떤 API를 제공하는지 Swagger를 통해 버전을 관리하며, 어떤 서버의 API를 어떤 서버가 사용할지 Consumer - Producer 관리가 가능하다. 

 

IP주소와 도메인 네임

각 학자들의 컴퓨터는 웹 서버라고 칭했는데, 모든 웹 서버는 주소를 갖는다. 

이 주소들의 정식 명칭은 IP 주소라고 한다. 또는 네트워크 주소라고도 부른다. 하지만, 이런 IP 주소들을 외워가면서 사이트에 접속하기는 어렵기 때문에 도메인 네임을 사용한다.(naver.com)

 

따라서 모든 웹 서버는 주소가 아닌 이름(별칭)을 사용하는데, 그 말은 웹 서버와의 통신을 위해서는 이름(별칭)을 실제 IP 주소 기반으로 진행되어야 한다. 이를 Map 매핑이라고 하는데, 쉽게 말해 key(도메인 네임) - Value(웹 서버 IP 주소)다. 

도메인 네임은 웹 서버 IP 매핑 정보로, DNS(Domain Name Server)로 불리며 전화번호부라고 생각하면 편할듯.

 

 

DNS

어떤 도메인 네임이 어떤 IP 주소인지 검색 및 변환 과정을 의미한다. 우리는 naver에 접속할 때 naver.com을 입력하면 네이버에 쉽게 접근할 수 있지만, 실제로는 naver.com을 일일히 분석해 DNS 절차를 거쳐 네이버의 IP 주소인 125.209.222.141을 알아내어 접속하도록 보여주는 것이다. 

 

출처: https://velog.io/@chun_gil/DNS-%EC%84%9C%EB%B2%84-%EC%A0%95%EC%9D%98%EC%99%80-%EC%A2%85%EB%A5%98

1. 로컬 DNS 

어느 도메인으로 접속하고자 하는 요청이 들어오면, 그림에는 표기되어 있지 않지만 사용자의 컴퓨터나 브라우저가 자체적으로 DNS 정보를 캐시(임시 저장)해둔다. 때문에 먼저 이 로컬 캐시를 확인하여 요청한 도메인의 IP주소가 있는지 확인한다. 만약 있으면 이 정보를 사용하고 프로세스를 종료한다.

 

2. ISP의 DNS 서버

로컬 캐시에서 IP 주소를 찾지 못했다면, 요청은 사용자의 인터넷 서비스 제공자인 ISP(KT, SKT, LG 등)의 DNS 서버로 전송된다. ISP DNS 서버도 일정 시간 동안 많이 사용되는 도메인 정보를 캐시에 저장하는데, 여기서 정보를 찾으면 반환하고 그렇지 않으면 다음 단계로 진행한다. 

 

3. 루트 DNS 서버

ISP DNS 서버 에서도 정보가 없으면, 루트 DNS 서버로 보내진다. 루트 서버는 전 세계에 13개가 존재하는데 이 서버들은 모든 최상위 도메인(TLD) 서버의 주소를 알고 있다. 해당 도메인의 TLD에 해당하는 서버 주소를 반환한다.

 

4. TLD 서버

루트 서버로부터 받은 TLD 서버 주소로 요청이 전송된다. 예를 들어 ".com", ".net", ".org"와 같은 최상위 도메인을 관리하는 서버다. TLD 서버는 해당 도메인의 권한 있는 네임 서버의 주소를 알려 줍니다.

예를 들어, naver.com이라면 '. 중 .com 은 A TLD 서버로 가라', '.net은 B TLD 서버로 가라' 등 정보를 제공해준다.

 

5. Authoritative Server

TLD 서버가 제공한 Authoritative Server서버의 주소로 요청이 이동한다. 이 네임 서버는 해당 도메인의 상세한 DNS 레코드를 관리하는데, 여기서 요청한 도메인의 IP 주소와 관련된 정보(A 레코드)를 찾아 ISP DNS 서버로 반환한다.

Non-Authoritative 의 의미는 캐싱되어있는 DNS 를 반환했다는 뜻
Authoritative 의 의미는 캐싱되어있지 않은 실제 NS 에 저장된 실시간 DNS 를 반환

 

최종적으로 Authoritative 서버가 제공한 IP 주소를 ISP에서 브라우저로 전달해 그 IP 주소로 접속하면 우리가 원하는 곳으로 이동이 가능한 것이다!