성공과 실패를 결정하는 1%의 네트워크 원리 - 1. Web Browser

---

title: 성공과 실패를 결정하는 1%의 네트워크 원리 - 1. Web Browser
date: 2022-10-20
tags:

• Network

---

Introduction

성공과 실패를 결정하는 1%의 네트워크 원리

네트워크에 대한 이해도를 높이기 위하여 네트워크 전반에 대한 지식을 얻고자한다.
처음부터 끝까지 깊게 배우기보다는 전체적인 흐름을 파악하고 필요한 부분을 깊게 배우고 싶었으며, 이 서적이 해당 목적에 가장 잘 어울린다고 판단하였다.
이번 Chapter는 1장 Web Browser 이다.

Purpose

Web Browser에 URL을 입력한 후 발생하는 동작을 통해 Network에 대해 이해한다.

HTTP Request Message

URL 입력 - 해독 후 정확한 주소로 변환 - Request Message 작성 - Response까지의 과정에 대한 내용이다.
이 부분은 HTTP The Definitive Guide의 Chapter 1과 Chapter 2에서 이미 공부하였기에 자세한 내용은 생략한다.

Get IP Address using DNS

Internet이나 사내 LAN은 TCP/IP 기반으로 만들어졌다.
여러 컴퓨터들이 연결이 되어 이루어진 작은 Network를 Subnet이라 하며, Subnet에는 여러 컴퓨터의 한 대의 Hub에 연결되어 있다.
Hub에 대한 자세한 내용은 3장에서 자세히 다룬다.
이러한 Subnet간 연결을 가능하게 하는 것은 Router로, 이 덕분에 전세계에서 사용하는 Network 구성까지 가능해진다.

Configuration of IP Address

IP Address는 Network 번호와 Host 번호로 구성된다.
Router는 IP Address의 Host를 확인하여 어느 방향으로 데이터를 보내야할지 결정하고 전송하며, 이러한 작업이 반복되어 수신자의 컴퓨터에 데이터가 전송이 되는 것이다.
IP Address는 총 32bits로, 8bits씩 끊어서 10진수로 나타낸다. Network 번호와 Host 번호는 뒤에 붙는 Netmask에 의해 결정된다.
Netmask 또한 32bits로, Bitwise AND 연산을 통해 또 다른 32bits가 나온다.
Netmask의 1로 이루어진 bits가 Network 번호이며, 그 뒤에 오는 0으로 이루어진 bits가 Host 번호이다.
AND 연산의 결과로 나온 Host의 bit가 모두 0이면 해당 Subnet을 가리키며, 모두 1이면 Subnet 전체에 Packet을 전송하는 Broadcast를 가리킨다.

Why use Domain?

IP Address를 직접 이용하기에는 어려움이 따른다. IP Address는 32bits로 구성되었으며, Netmask까지 포함한다면 총 64bits의 정보에 대해 미리 알고 있어야 한다.
유저들이 방문하는 사이트가 여러개인데, 이것을 전부 외워야 한다면 더 편한 방식으로 대체되었을 것이다.
그렇기에 일반적으로 URL을 입력하여 Web에 접속한다. 하지만 URL을 이용하는 것은 효율적이지 않다.
IP Address 없이 URL만 이용한다면 긴 문자열을 계속 비교하면서 목적 대상을 찾아야 하는데, 이 방식은 Overhead가 크다.
그렇다고 IP Address로 변환을 해야 한다면 Router를 거칠때마다 변환해주는 작업이 계속 이루어져야 하기에 이 또한 Overhead가 크다.
이러한 Overhead를 줄이고 URL을 편하게 사용하고자 DNS를 이용한다.

Get IP Address with Resolver

가장 가까운 DNS Server에 www.google.com이라는 Domain을 이용하여 IP Address를 요청하고, Response로 IP Address를 받으면 된다.
Web Browser의 측면에서 이 과정을 더 자세하게 살펴본다.
DNS Server에 Domain의 IP Address를 Request하는 것은 결국 통신이 일어나는 것이다. 이를 Resolver 혹은 DNS Resolver가 담당한다.
DNS Server를 이용하여 IP Address를 조사하는 것을 Name Resolution이라고 한다.
Resolver는 Socket Library에 들어있는 하나의 부품화한 Program이다.
C의 경우 Resolver의 gethostbyname 함수(Program)에 Domain을 넘겨주며, return되는 Response Message에 IP Address가 포함된다.
Resolver는 이를 추출하여 Browser의 특정 Memory 영역에 작성한다.

Details of Resolver

위에 작성한 Resolver의 동작은 매우 간단하게 표현한 것이다.
함수 호출로 Domain을 넘겨준 이후, Resolver와 DNS 내부적으로 많은 동작이 숨어있다.
Resolver는 데이터 전송 기능이 없기에 Domain의 IP Address를 요청하는 UDP Message를 작성한다.
이 때 HTTP는 Message가 문자로 작성되나, DNS의 Message는 Binary로 표현된다.
OS의 Protocol Stack에서 UDP Message를 송신해준다. Protocol Stack은 Network 제어용 S/W로 Protocol Driver, TCP/IP S/W라고도 불린다.
UDP Message는 LAN Adapter를 통해 DNS Serevr로 송신된다.
DNS Server는 IP Address를 찾는데, 이 과정은 복잡하기에 뒤에서 자세히 다룬다.
찾은 IP Address를 Client에게 Response하며, Lan Adapter와 Protocol Stack을 거쳐 Resolver로 넘어오고 이를 해독하여 IP Address를 추출한다.
최종적으로 추출한 IP Address는 주어진 특정 Memory에 작성하여 Resolver의 역할이 끝난다.
DNS Server와 통신한다고 하였는데, DNS Server의 IP Address는 TCP/IP 설정의 하나로 컴퓨터에 미리 설정이 되어 있다.

DNS Server

DNS Server의 상세 동작에 대해 알아본다.

Basic of DNS Server

DNS Server로 Request된 Message는 세 가지 정보를 포함한다.
Domain 이름, Internet 이외의 Network 식별을 위한 Class(다른 Network는 모두 사라졌기에 현재는 Internet을 나타내는 IN만 존재), Domain에 어떤 Type의 정보가 지원되는지를 명시해주는 Type이 존재한다.
DNS Server는 세 가지 모두 일치하는 항목을 찾아 대응되는 값을 Response한다.
IP Address만 Response한다고 생각할 수 있으나, Type은 매우 다양하다.
그 중 IP Address 요청시에는 A Type을 사용하며 A Type에 등록된 Domain이 해당 Web Server의 이름이 된다.
이메일을 보낼때는 MX (Mail Exchange) Type을 사용하여 Mail Server의 우선순위, Mail Server Domain, IP Address를 모두 Response로 넘겨준다.
DNS Server는 내부적으로 Resource Record를 비교하며 Request 정보와 일치하는 항목을 찾는 것이다.

Layers of Domain

DNS Server가 하나의 큰 Server라고 생각할 수 있으나, 무수히 많은 Domain이 존재하기에 이를 모두 가지고 있을 수 없다.
DNS Server 또한 Internet처럼 여러 DNS Server끼리 연결되어 하나의 Network를 형성한다.
DNS Server는 자체적인 Domain의 정보를 이용하여 구분하며, www.google.com은 www, google, com 이라는 Domain으로 구분이 된다.
이러한 계층 구조로 이루어져 DNS Server는 URL을 이용하여 Domain을 하나씩 거치며 최종적으로 Request와 대응되는 정보를 찾을 수 있는 것이다.

How to get IP Address using DNS Server

DNS Server는 무수히 많기에 모든 DNS Server를 거치며 원하는 정보를 찾기는 어렵기에 계층 구조로 구성이 된다.
Root Domain이라는 DNS Server에서 URL의 뒤쪽 Domain부터 탐색하는 구조이다.
Root Domain은 하나의 DNS Server가 아닌, 여러 Server로 구성이 되어 있으나 하나로 보이게 구성되어 있다.
Root Domain에 할당된 IP Address는 전 세계에 13개밖에 없으며, 거의 변경되지 않는다.
www.google.com의 경우 우선 가장 가까운 DNS Server에 Request를 보내며, 관련된 정보가 없을 경우 상위 Domain으로 이동을 하다가 Root Domain에 도달한다.
다시 Root Domain -> com의 Domain -> google의 Domain 순서로 거치며 google Domain이 Request에 대한 Response를 보내준다.
이후 유저가 이를 이용하여 연결할 경우, google의 Domain 바로 밑에 있는 www라는 Server와 연결이 된다.

Cache

설명은 매우 간소화하였으나, 실제로는 하나의 DNS Server에 여러 Domain이 존재할 수 있다.
여러 계층의 Domain이 하나의 DNS Server에 존재할 수도 있는 것이다.
또한 DNS Server는 Cache를 두어 조회한 정보를 저장하며, Cache에 Request한 정보가 있다면 탐색 과정 없이 바로 Response한다.
다만 Cache의 정보가 최신의 정보가 아닐 수도 있으며, 하나의 IP Address만 Response할 수 있기에 Load Balancing 측면에서 문제가 발생할 수 있다.
전자의 경우 Cache에 유효 기간을 설정하여 해결하며, 후자의 경우 DNS와 비슷한 GSLB(Global Server Load Balancing)를 이용하여 이를 해결한다.

Protocol Stack

Overview of Trasmission and Receiving Data

IP Address를 알아내기까지의 동작은 Web Browser에만 해당하는 것이 아닌, 모든 Network Application에 해당된다.
알아낸 IP Address를 이용하여 OS의 Protocol Stack에 Message 송신을 요청하며, 이 동작에 대해 더욱 자세하게 알아보도록 한다.
Socket을 이용한 Network 통신은 내부적으로 TCP Protocol을 이용한다. Client와 Server를 연결해야 통신이 가능하며, 연결을 하는 과정을 알아본다.
간단하게 Client와 Server 사이에 연결된 파이프를 설치하는 과정이며, 파이프의 출입구를 Socket이라고 한다.
Server는 보통 파이프를 먼저 만들어놓는다. Client가 파이프를 설치하고, 두 파이프를 이으면 연결이 된다고 볼 수 있다.

Configure Socket

Socket의 생성 과정은 내부적으로 많은 작업이 이루어지나, 우선 Socket Library 호출을 통해 Socket이 생성된다고 보면 된다. 자세한 내용은 2장에서 더 알아본다.
Socket이 생성되면 Server에서 Descriptor를 넘겨주며, 이를 Memory에 기록한다. 하나의 연결만 생각할 수 있으나, 실제로는 많은 연결이 이루어지고 유지된다.
이것들을 식별하기 위해 Descriptor를 기록하는 것이다.

Connect Socket

이후 Socket Library의 connect 함수를 호출하여 Socket을 연결한다. 이 때 Descriptor, IP Address, Port가 사용된다.
Protocol Stack은 Descriptor를 통해 Client의 어떠한 Socket을 연결해야 하는지 식별하며, Server와 연결할 때 IP Address와 Port가 모두 필요하다.
IP Address를 통해 Server를 특정하며, Port를 이용하여 Server의 Socket중 어떠한 Socket과 연결하는지 특정한다.
Port의 경우 전 세계적으로 통일된 규칙이 존재한다. Protocol에 따라 Port가 정해져 있기에 이 정보를 이용하여 Port를 알아서 지정한다.
또한 Server가 먼저 데이터를 보낼 수 있기에 연결 과정에서 Protocol Stack이 적절한 Port를 선정하여 함께 넘겨주고, Server는 이를 기억한다.

Exchange Message

연결이 완료되었기에 데이터의 송수신을 Protocol Stack에 요청하며, 이 때 Socket Library의 write 함수를 이용한다.
HTTP를 사용하는 Web Browser는 HTTP Request Message를 작성한 후, 이 Message와 Descriptor를 이용하여 write함수를 호출한다.
Socket은 이미 연결이 완료되었기에 Descriptor로 Socket을 특정하면 Message를 송신한다.
Server는 이에 대해 적절한 처리를 한 후 Response를 한다. 이를 Socket Library의 read 함수를 이용하여 Response를 받는다.
Response를 저장하기 위해 Receive Buffer라는 Memory 영역을 지정하여 저장한다. 이 영역은 Application의 Memory에서 지정하기에 저장과 동시에 Application에 Response가 넘어간 것이다.

Cut the Connection

모든 통신이 종료되면 Socket Library의 close 함수를 호출하여 Socket 연결을 끊는다.
Web은 Server에서 Response가 완료되면 먼저 close를 하며, 이는 Application에 따라 다르다.
다른 쪽에는 이러한 정보가 전달이 되며, 이 정보는 Receive Buffer에 작성되지 않고 Application에 전달이 되어 연결을 끊는다.
본 서적의 초판은 2003년이며, 개정판의 경우 2009년에 발행되었다. HTTP 1.1을 이용하지만 Persistent Connection을 사용하지 않는 동작이다.
데이터를 실제로 송수신하는 장치는 Protocol Stack, LAN Driver, LAN Adapter 3가지이다. 다음 장에서 이에 대한 내용에 깊게 다룬다.

Conclusion

Web Browser에 URL을 입력한 후, Message를 보내도록 Protocol Stack에 의뢰하는 과정을 알아보았다.
2장부터는 데이터가 실제로 운반되는 과정에 대해 알아본다.
모호하게 알거나 대략적으로 알던 개념과 동작을 깊게 알아볼 수 있었다.