Chap01.웹 브라우저가 메시지를 만든다

성공과 실패를 결정하는 1%의 네트워크 원리 책을 읽고 정리한 글입니다.

허브, 라우터는 패킷을 중계하는 장치의 일종이다.

서브넷은 허브에 몇 대의 PC가 묶인 네트워크 단위라고 이해하자.

TCP/IP 네트워크는 결국 이 서브넷 들을 라우터로 묶고, 그 묶은 단위를 또 다시 허브로 묶고, 라우터로 반복 중계하는 형태를 띈다.

서브넷과 허브의 관계 (출처: https://nolzaheo.tistory.com/37)

IP주소(네트워크 번호 + 호스트 번호)를 통해 데이터를 보내는데, 라우터가 그 방향 쪽 라우터에 점점 가까워지게 중계를 반복한다. 이를 통해 최종 액세스 대상에 데이터가 도착한다.

그런데, 브라우저는 메시지를 네트워크에 송출하는 기능은 없다. 그래서 OS에 의뢰해서 이를 송신한다.

참고)

IP 주소는 4바이트, 도메인명은 최대 255바이트까지 취급한다.

효율적이지 않은데, 왜 도메인명을 사용할 수 있는걸까?

답은 DNS(Domain Name System).

도메인명을 DNS 서버에 전송하면, 해당하는 IP 주소를 알려준다.

이 과정을 세부적으로 쪼개면, DNS 서버에게 IP 주소를 알려달라고 도메인명을 전송하는 주체는 DNS 클라이언트(Resolver) 이다.

Resolver는 Socket 라이브러리 안에 있다. (OS의 네트워크 기능을 애플리케이션 단에서 호출하기 위함)

브라우저가 Resolver를 호출하면, 제어권이 넘어가게 된다.

Resolver는 DNS 서버에 요청할 때 보낼 메시지를 생성하고, DNS 서버 요청을 OS 내부에 있는 프로토콜 스택에 요청(호출)한다.

(데이터를 송 수신 하는 기능은 OS에 있다는 것을 명심하자. LAN 어댑터를 통해서 요청이 전달된다.)

프로토콜 스택이 DNS 서버로 부터 IP 주소를 받아와서 Resolver에게 전해주면, Resolver는 IP 주소를 메모리 영역에 저장한다.

DNS 서버는 기본적으로 도메인과 IP 주소에 대한 Name, Class, Type 등을 Resource Record에 등록해놓는다.

그리고 DNS 서버는 수만 대 이상 존재하는데, 루트 도메인의 DNS 서버로 부터 하위 DNS 서버를 계속해서 등록되어있다.

클라이언트가 특정 도메인을 조회하고자 요청하면, 가장 가까운 DNS 서버에 요청을 하게 된다.

그래서 해당 DNS 서버에 정보가 없다면 루트 도메인으로, 그 이후 하위 DNS 서버를 타고 타고 조회 메시지를 계속 보내서 원하는 DNS 서버까지 가게 된다.

DNS 서버는 캐시에 기록하여 응답 속도를 빠르게 한다.

(출처: https://jayyhkwon.github.io/blog/page22/)

소켓을 생성하면 Descriptor가 반환된다. 이건 소켓을 식별하는데 사용된다. (번호표 같은 존재)

애플리케이션(브라우저)은 이를 메모리에 기록해둔다.

소켓에 접속하는 과정에서는 Descriptor, 서버 IP 주소, Port 번호가 필요하다.

데이터 송 수신 단계에서는 애플리케이션이 전송할 데이터를 메모리에 올려둔다.

Descriptor, 송신할 데이터를 지정해서 프로토콜 스택이 write()하고,

프로토콜 스택이 read()해서 수신한 응답 메시지는 수신 버퍼(메모리 영역) 에 저장한다.