다음은 성공과 실패를 결정하는 1%의 네트워크 원리 를 읽고 정리한 내용입니다. 본 글은 CH1. 웹 브라우저가 메시지를 만든다 입니다 🙌


🛺 [Story3] 전 세계의 DNS 서버가 연대한다.

DNS 서버의 기본 동작

  • DNS 서버는 조회 메세지를 받고 그것에 대해 응답을 한다.
  • 조회 메세지 내용
    • 이름: 서버나 메일 배송 목적지 (@뒤 호스트)
    • 클래스: 이전에 필요했으나 요즘에는 항상 인터넷을 나타내는 클래스 ‘IN’으로 표기됨
    • 타입: 다음마다 응답 형태가 바뀐다.
      • A: 이름에 지원되는 IP 주소
      • MX: 메일 배송 목적지
  • DNS 서버에서 위 3가지가 일치하는 응답 정보를 찾아서 등록된 IP 주소 등을 회신한다.
  • MX, 메일 서버에 대한 응답인 경우
    • 메일 서버의 우선순위 + 메일 서버의 이름, 해당 메일 서버의 IP 주소를 함께 회신한다.
  • DNS 서버에서 취급하는 타입은 여러개가 있다.
    • PTR, NS, SOA, CNAME 등등

도메인의 계층

  • 정말 많은 서버의 수가 존재하기 때문에 한대의 DNS 서버에 모든 정보를 등록할 수 없다. 정보를 분산시켜 여러대의 DNS 서버에 등록해놓고 조회하는 정보를 찾아서 응답하는 구조로 되어있다.

도메인명

  • DNS 서버에 등록되어 있는 도메인명은 계층적 구조를 가지고 있다.
  • 도메인의 계층은 .점으로 구분되어 있다. (ex. www.example.com 각각의 www, example, com 이 계층을 나타냄)
    • 위의 경우 com 도메인 하위에 example 도메인 하위에 www 도메인이 있는 것 (서브 도메인)
  • 하나의 도메인에 대한 정보들은 하나의 DNS 서버에서 모두 관리한다.
    • DNS 서버는 다수의 도메인을 관리할 수 있지만 같은 도메인인 정보들은 모두 한대의 DNS 서버에 존재한다.
  • 가장 먼저 출연하는 도메인이 서버의 이름, 최하위 서브 도메인이다 (예, www, api, dev 같은 경우)

담당 DNS 서버를 찾아 IP 주소를 가져온다

  • 여러 DNS 서버가 존재하기 때문에 중요한 것은 어느 DNS 서버에 원하는 정보가 있는지 판단하는 것이다.

  • 그 방법으로 상위 도메인에 하위 도메인을 등록하여 찾아갈 수 있는 구조로 설계했다.

    • com 도메인에 example.com 도메인이 등록되어 있는 구조

  • com, kr 등등은 최상위 도메인이 아니다 → root 도메인이 존재하여 거기에 com, kr 등등의 도메인이 등록되어 있다.


    출처: 상위 1% 네트워크

루트 도메인

  • 최상위 도메인으로 할당된 IP 주소는 13개 뿐이다.
  • 그렇기 때문에 루트 도메인의 정보를 모든 DNS 서버에 등록할 수 있다 → 기본으로 DNS 서버 설정 파일에 등록되어 있다.
  • 그 어떤 DNS 서버에서도 루트 도메인 DNS 서버로 이동할 수 있는 주소를 확보한다.

클라이언트가 www.example.com의 IP 주소를 구하는 방법

  • 컴퓨터에 설정되어 있는 가장 가까운 DNS 서버로 조회를 요청 → 없으면 루트 도메인 서버로 메세지 전송

  • (존재하지 않는 경우) 루트 도메인으로 이동 → 없으면 com 도메인 주소 반송

  • 루트 도메인에 등록된 com 도메인 서버로 이동 → 없으면 example.com 도메인 주소 반송

  • com 도메인 서버에 등록된 example.com 도메인 서버로 이동 → 반복

  • 원하는 도메인 IP 주소를 응답

  • 그것을 가장 가까운 DNS 서버에서 클라이언트에게 응답

  • 도메인이 같은 DNS 서버에 존재할 수 있으므로 도메인 개수만큼 서버를 꼭 이동하는 것은 아니다.

DNS 서버는 캐시 기능으로 빠르게 회답할 수 있다

  • DNS 서버에서 한번 조사한 이름을 캐시에 저장한다.
  • 이후에 저장할 경우 루트 도메인애서부터 찾는 것이 아니라 캐싱된 도메인의 하위 도메인부터 찾을 수 있다.
  • 존재하지 않은 도메인인 경우도 캐싱하여 빠르게 응답한다.
  • 유효기간에 따라서 정보를 삭제하고 캐시 응답인지 서버 응답인지 알려준다. (정보 업데이트 고려)

🛺 [Story4] 프로토콜 스택에 메시지 송신을 의뢰한다.

데이터 송수신 동작의 개요

  • 메세지 전송을 OS 내의 프로토콜 스택에 위임한다.
  • 반드시 웹 요청 메세지 뿐 아니라 컴퓨터의 모든 네트워크 관련 동작에 공통인 부분이다.
    • 디지털 데이터 송수신이 필요한 부분은 모두 할당된다.
  • 프로토콜 스택에 의뢰하여 메세지를 전송할 때도 Socket 라이브러리를 사용한다.

소켓을 활용한 데이터 송수신 기본 동작 - 프로토콜 스택 담당

  1. 소켓을 생성 (서버와 클라이언트가 각각 소켓을 생성)
  • 소켓은 데이터가 흐르는 통로의 입구와 같은 것이다.
  1. 서버측의 소켓에 클라이언트 소켓 접속
  2. 데이터 송 수신
  3. 완료 후 파이프 분리 후 소켓 말소 (close는 어느 측에 해도 무방)
  • 소켓 라이브러리는 어플리케이션으로부터 위 단계를 실행하도록 의뢰받고 그대로 프로토콜 스택에 중계하는 역할을 한다.

소켓의 작성 단계 - 소켓 라이브러리 메서드 활용

  • 디스크립터 = socket을 생성
    • 디스크립터로 소켓을 식별
  • connect 메서드로 (소켓 디스크립터, 대상 서버 IP 주소 및 포트번호 필요) 로 대상 서버와 접속
  • write 메서드로 데이터 송신
  • read 메서드로 데이터 수신
  • close 메서드로 소켓 말소

파이프 연결하는 접속 단계

  • connect 라는 메서드에 인자로 소켓 디스크립터 + 서버 IP 주소 + 서버 포트 번호 가 필요하다.
  • 프로토콜 스택은 connect에서 중계한 디스크립터로 데이터 송수신을 담당할 소켓을 판별한다.
  • IP 주소는 컴퓨터를 식별할 수 있지만, 컴퓨터에 존재하는 여러 소켓 중 어느 것에 연결할지 알기 위해서는 포트 번호가 필요하다.
    • 포트 번호는 상대 소켓을 식별 !!
    • 왜 소켓을 식별할 수 있는 디스크립터를 사용하지 않을까 ?
      • 디스크립터는 소켓을 생성한 어플리케이션에서 프로토콜 스택에 의뢰하도록 주는 것이다.
      • 상대에게 소켓 디스크립터를 넘겨주어도 정보가 없으므로 식별할 수 없다.
    • 포트 번호는 미리 지정한 규칙에 따라서 서로 알고있는 값이다. (웹 서버는 80, 메일은 25 등등)
    • 포트 번호도 충돌할 수 있기 때문에 중복되지 않도록 IANA에서 일괄 관리한다.
    • 클라이언트의 소켓 번호는 알아서 할당 후 접속 동작에서 서버에 통지한다. (이후 추가 설명)

메세지를 주고받는 송수신 단계

  • 송신측에서 메모리에 송신 데이터를 준비한다. (HTTP request 메세지)
  • write를 호출하며 소켓 디스크립터와 송신 데이터를 지정한다.
  • 디스크립터로 지정된 소켓에 연결대상이 이미 접속 단계에서 지정이 되어있다. 목적지로 데이터를 송신한다.
  • 이후 응답 메세지를 수신할 때는 read를 통해 수신 버퍼에 응답 메세지를 저장한다.
    • 수신 버퍼는 어플리케이션의 메모리 영역

연결 끊기 단계에서 송수신이 종료된다

웹 서비스와 같은 경우 웹 서버에서 먼저 close를 호출한다. (어느측에서 먼저해도 상관없다)

  • 웹 서버에서 close()를 호출
  • 클라이언트가 close() 호출 여부를 응답받으면, 클라이언트도 close()를 호출하여 연결 끊기를 진행
  • HTTP 프로토콜은 하나하나의 데이터를 별도의 것으로 취급하기 때문에 위 단계를 모든 데이터를 송수신 할때마다 반복하는 것이다.
    • 이것이 비효율적이라고 생각하여 나온것이 HTTP 1.1의 keep-alive
    • 더 이상 송수신할 데이터가 없는 경우에만 소켓을 말소하는 단계에 들어간다.

이 이후에 데이터에 네트워크가 흘러가기 전까지 프로토콜 스택, LAN 드라이버, LAN 어댑터가 연동하여 실행된다. (다음 챕터)



[용어]

MX - Mail eXchange

캐시 - 한 번 사용한 데이터를 데이터의 이용 장소와 가까운 곳에 있는 고속의 기억 장치에 저장하여 두 번째 이후 고속화 하는 것