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

이 포스팅은 아래 링크의 책을 읽고 정리한 포스팅이다.

https://kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788931553482

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

 

서문 

- 브라우저와 웹 서버간에 대화하는 요청, 응답을 상대에게 운반하는 구조가 필요하다. (요청과 응답의 실제는 전기나 빛의 신호이다.)

- 디지털 데이터를 어떻게 운반할 것인가

- 이 구조는 OS에 내장된 네트워크 제어용 소프트웨어나 스위치, 라우터라는 기기가 역할을 분담하면서 실현한다.

- 디지털 데이터를 작은 덩어리로 나눠 '패킷' 이라는 그릇에 넣어 운반한다. 원리는 우편이나 택배와 비슷하다. 패킷은 소포이고, 스우치나 라우터는 우체국 또는 택배 집하장에 해당한다.

- 네트워크는 디지털 데이터를 운반하는 원리와 브라우저나 웹 서버 (네트워크 애플리케이션)의 결합이다.

 

순서

1장: 브라우저가 요청을 의뢰하는 동작에 대한 설명

2장: 데이터를 운반하는 구조 설명. OS에 내장된 프로토콜 스택이 하는 일 설명

3장: LAN 어댑터가 송신한 패킷을 전송하는 과정 (스위칭 허브, 라우터)

4장: 인터넷 접속용 라우터의 앞부분, 인터넷 내부에 대한 구조 설명

5장: 웹 서버측의 LAN에 방화벽, 캐시 서버에 대한 설명

6장: 프로토콜 스택이 패킷의 메시지를 복원하고 서버에 넘기는 과정 설명

 

1장

개요

- 브라우저의 동작을 처음 추적함

- 브라우저는 OS에 의뢰하여 네트워크를 제어한다.

 

동작순서

1. HTTP 리퀘스트 메시지를 작성한다.

2. 웹 서버의 IP 주소를 DNS 서버에 조회한다.

3. 전 세계의 DNS 서버가 연대한다.

4. 프로토콜 스택에 메시지 송신을 의뢰한다.

 

1. HTTP 리퀘스트 메시지를 작성한다.

1. 탐험 여행은 URL 입력부터 시작한다.

- URL은 여러 종류가 있다.

- 브라우저는 웹 서버 액세스 용이 아니라 FTP, 메일의 클라이언트 기능도 한다.

- 프로토콜이란 통신 동작의 규칙을 정한 것

 

2. 브라우저는 먼저 URL을 해독한다.

- 브라우저가 처음 하는 일은 웹 서버에 보내는 요청의 메시지를 작성하기 위해서 URI를 해독하는 것이다.

- URL의 요소를 따로따로 분리한다.

  ex) www.lab.cyber.co.kr/dir/file1.html => 서버 주소인 www.lab.cyber.co.kr에 가서 dir/file1.html 파일에 액세스한다.

 

3. 파일명을 생략한 경우

- 대부분 서버가 index.html이나 default.htm이라는 것을 설정해 둔다.

 

4. HTTP의 기본 개념 (HTTP 프로토콜이란)

- URL을 해독하면 어디에 액세스 할 지 판단된다.

- URI: 요청 메시지의 '무엇을'에 해당한다. 액세스 대상을 통칭하는 말

- 메서드: 요청 메시지의 '어떻게 해서'에 해당한다. 웹 서버에 어떤 동작을 하고 싶은지 전달한다.

- GET: URI를 읽으라는 메시지. 서버는 이 메시지를 받으면 해당 URI가 가르키는 데이터를 추출하여 응답 메시지에 포함해서 보내고 클라이언트는 이것을 받아 화면에 표시한다.

- POST: 메시지가 서버에 도착하면 URI에 지정된 프로그램에게 리퀘스트 메시지 안에 쓰여있는 데이터를 건네준다. 그리고 해당 프로그램이 출력하는 데이터를 받아서 응답 메시지에 포함 시킨 후 클라이언트에게 반송한다.

 

5. HTTP 리퀘스트를 만든다

- 요청 메시지 포맷에 맞게 메시지를 만듦

- 요청 메시지 예시

요청 메시지의 예시 (출처: https://images.app.goo.gl/z89SC2hKxgVFFuH89)

6. 리퀘스트 메시지를 보내면 응답이 되돌아온다

- 자세한 내용은 6장에서 설명

응답 메시지의 예시 (출처: https://images.app.goo.gl/xjjhX86kL9k5qNVS7)

- 페이지가 영상을 포함하거나 다른 태그가 있다면 해당 태그를 비워두고 다른 문장들을 표시함. 이후 다시 한 번 웹 서버에 태그에 쓰여있는 파일을 읽어와서 비워둔 공백에 표시한다.

- 여러가지 요청을 보내는데, 웹 서버 측에서는 이게 한 개의 페이지인지, 아니면 각각 별도의 페이지인지 신경쓰지 않음. 단순히 한 개의 요청에 대해 한 개의 응답을 보내는 것 뿐이다.

 

2. 웹 서버의 IP 주소를 DNS 서버에 조회한다.

1. IP 주소의 기본

- HTTP 메시지를 만들고 이것을 OS에 의뢰하여 웹 서버에게 송신함.

- 브라우저는 메시지를 네트워크에 송출하는 기능이 없어서 OS에 송신한다.

- OS에 송신을 의뢰할 때는 IP 주소로 상대를 지정해야 한다.

- 도메인 명에서 IP주소를 조사해야 한다.

 

TCP/ IP의 개념

- 서브넷이라는 작은 네트워크를 라우터로 접속하여 전체 네트워크가 만들어진다.

- 서브넷: 허브에 몇 대의 PC가 접속된 것

- IP 주소: 네트워크 번호 (~동) + 호스트 번호 (~번지)

- 송신 측 메시지 보냄 -> 서브넷 안에 있는 허브가 운반 -> 가장 가까운 라우터까지 도착 -> 라우터가 메시지 상태를 확인하여 다음 라우터 판단

- 실제 IP 주소는 32비트의 디지털 데이터. 8비트씩 점으로 구분하여 10진수로 표기함

- IP 주소의 규칙에서는 네트워크 번호와 호스트 번호 두 가지를 합쳐서 32비트로 한다는 것만 결정되고 내용은 결정되어 있지 않음

- 사용자가 이 내용을 직접 결정할 수 있는데 그것을 넷마스크라고 한다.

- 넷마스크: 넷마스크가 1인 부분은 네트워크 번호를 나타내고, 넷마스크가 0인 부분은 호스트 번호를 나타낸다. IP 주소와 같이 8비트씩 구분하여 표기할 수도 있는데 너무 길어져서 한 부분의 비트 수를 10진수로 나타내고 IP 주소의 오른쪽에 병기할 수도 있다.

- 호스트 번호 부분이 모두 0인 IP 주소는 각각의 기기를 나타내는 것이 아니라 서브넷 자체를 나타낸다.

- 호스트 번호 부분이 모두 1이면 (255) 서브넷에 있는 기기 전체에 패킷을 보내는 브로드캐스트를 나타낸다.

 

2. 도메인명과 IP 주소 구분하여 사용하는 이유

- 그냥 IP 주소를 기억하고 브라우저에서 입력을 해도 동작은 됨. 하지만 기억하기 어려움

- 숫자 말고 이름으로 상대를 지정하여 통신을 하는 방법도 있지만 IP 주소는 32비트로 고정이 되어있지만 도메인명은 일정한 길이가 아니라 최대 255바이트 내에서 랜덤의 문자를 취급해야 하기 때문에 라우터가 부하되어 네트워크의 속도가 느려진다.

 

3. Socket 라이브러리가 IP 주소를 찾는 기능을 제공한다

- IP 주소를 조사하는 방법 자체는 간단하다. 가장 가까운 DNS 서버에 도메인 네임을 넘기고 그 IP를 알려달라고 하면 된다.

 

브라우저가 DNS 서버를 조회하는 방법

- DNS 리졸버 (리졸버): DNS 서버에 대해서 클라이언트로 동작하는 것. DNS 클라이언트

- 네임 리졸루션: DNS의 원리를 사용하여 IP 주소를 조사하는 것

- 리졸버는 Socket 라이브러리에 들어있는 부품화한 프로그렘이다.

- Socket 라이브러리: OS에 포함되어 있는 네트워크의 기능을 애플리케이션에서 호출하기 위한 라이브러리.

 

4. 리졸버를 이용하여 DNS 서버를 조회한다

- 브라우저 등의 애플리케이션을 만들 때 리졸버의 프로그램 (gethostbyname)을 사용하면 리졸버를 호출할 수 있음

- 리졸버를 호출하면 리졸버가 DNS 서버에 조회 메시지를 보내고, DNS 서버에서 응답 메시지가 돌아온다. 리졸버는 여기서 IP 주소를 추출하여 브라우저에서 지정한 메모리 영역에 넣어준다.

 

5. 리졸버 내부의 작동

- 네트워크 애플리케이션 (현재 단계에서는 브라우저)이 리졸버를 호출하면 제어가 리졸버로 넘어간다.

- DNS 서버에 문의하기 위한 메시지를 만든다. (메시지는 바이너리 데이터로 표현)

- 메시지 송신 동작은 리졸버가 스스로 실행하는 것이 아니라 OS의 내부에 포함된 프로토콜 스택을 호출하여 실행을 의뢰한다. (리졸버도 브라우저와 마찬가지로 네트워크에 대해 데이터를 송/수신하는 기능이 없기 때문)

- 프로토콜 스택에서 메시지를 보내는 동작을 실행하여 LAN 어댑터를 통해 메시지가 DNS 서버를 향해 송신된다.

- 메시지가 DNS 서버에 도착하고 DNS 서버는 해당 서버를 찾아서 응답 메시지에 써서 반환을 한다.

- 메시지 송신의 역순으로 메시지를 받아오고, 애플리케이션에 지정된 메모리 주소에 해당 IP 주소를 할당한다.

- DNS 서버에 메시지를 송신할 때도 DNS 서버의 IP 주소가 필요하다. 단 이것은 컴퓨터에 미리 설정되어 있다.

 

3. 전 세계의 DNS 서버가 연대한다.

1. DNS 서버의 기본 동작

- DNS 서버의 기본 동작은 클라이언트에서 조회 메시지를 받고 조회의 내용에 응답하는 형태로 정보를 회답하는 일

- 조회 메시지에 포함되어 있는 정보 3가지

  1. 이름: 서버나 메일 배송 목적지와 같은 이름

  2. 클래스: DNS 구조를 고안했을 때 인터넷 이외의 네트워크에서도 사용을 검토하여 이것을 식별하기 위해 준비함. 하지만 인터넷 이외의 네트워크가 소멸되어서 항상 인터넷을 나타내는 'IN' 이라고 사용함

  3. 타입: 이름에 어떤 타입의 정보가 지원되는지를 나타냄. 이 타입에 따라 클라이언트에 회답하는 정보의 내용이 달라짐.

  ex) 타입이 A인 경우: 이름에 IP 주소가 지원이 됨

        타입이 MX인 경우: 이름에 메일 배송 목적지가 지원됨.

- 예를 들어 이름이 www.lab.cyber.co.kr 인 경우는

  이름: www.lab.cyber.co.kr

  클래스: IN

  타입: A

 

2. 도메인의 계층

- 인터넷에는 막대한 수의 서버가 있으므로 이것을 전부 1대의 DNS 서버에 등록하는 것은 불가능하다. 그렇기에 조회 메시지를 받은 DNS 서버에 정보가 등록되지 않은 경우를 설명한다.

- 정보를 분산시켜서 다수의 DNS 서버에 등록하고, 다수의 DNS 서버가 연대하여 어디에 정보가 등록되어 있는지를 찾아내는 구조이다.

- DNS 서버에 등록한 정보에는 도메인명이라는 계층적 구조를 가진 이름이 붙여져 있다.

 

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

- DNS 서버에 등록한 정보를 찾아내는 방법. 액세스 대상의 웹 서버가 어느 DNS 서버에 등록되어 있는지 찾아내는 방법

- 먼저 하위의 도메인을 담당하는 DNS 서버의 IP 주소를 그 상위의 DNS 서버에 등록한다. 그리고 상위의 DNS 서버를 그 상위의 DNS 서버에 등록하는 식으로 차례대로 등록한다.

ex ) lab.glasscom.com이라는 도메인을 담당하는 DNS 서버를 glasscom.com의 DNS 서버에 등록하고, glasscom.com의 DNS 서버를 com 도메인의 DNS 서버에 등록하는 식. 결과적으로 상위의 DNS 서버에 가면 하위의 DNS 서버의 IP 주소를 알 수 있고, 거기에서 조회 메시지를 보낼 수 있다.

- 루트 도메인이라는 것이 존재하고, DNS 서버에 com이나 co의 DNS 서버를 등록한다.

- 루트 도메인의 DNS 서버를 인터넷이 존재하는 DNS 서버에 모두 등록해야 한다. 그 결과 어느 DNS 서버에서든 루트 도메인에 액세스할 수 있게 된다. 이것은 DNS 서버 소프트웨어를 설치하면 자동으로 등록이 완료된다.

 

DNS가 원하는 DNS 서버를 찾아내는 방법

1. 클라이언트의 가장 가까이에 있는 DNS 서버에 웹 서버에 관한 정보를 조회한다.

2. 정보가 존재하지 않은 경우 루트 도메인에게 클라이언트로 부터 받은 조회 메시지를 전송한다.

3. 루트 도메인에는 www.lab.glasscom.com 이라는 이름이 등록되어 있지 않지만 com 도메인의 아래에 있다는 것을 알 수 있다. 그래서 루트 도메인은 com 도메인의 DNS 서버의 IP 주소를 반송한다.

4. 가장 가까운 DNS 서버는 다시 com 도메인 서버에게 클라이언트로부터 받은 조회 메시지를 전송한다.

5. com 도메인에도 해당 정보가 등록되어 있지 않기 때문에 glasscom.com 이라는 도메인의 IP 주소를 반송한다.

6. 이렇게 해서 결국 www.lab.glasscom.com 의 IP 주소를 알 수 있다. 

7. 정보를 받은 DNS 서버는 이 정보를 클라이언트에 회답하고 클라이언트는 웹 서버의 IP 주소를 알고 거기에 액세스가 가능해진다.

 

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

- DNS 서버는 한 번 조사한 이름을 캐시에 기록할 수 있는데, 조회한 이름에 해당하는 정보가 캐시에 있으면 그 정보를 회답한다.

- 캐시에 정보를 저장 후 등록 정보가 변경되는 경우도 있으므로 DNS 서버에 등록하는 정보에는 유효 기한을 설정하고, 캐시에 저장한 데이터의 유효 기간이 지나면 캐시에서 삭제한다. 조회에 회답할 때 캐시에 저장된 것인지, 등록된 DNS 서버에서 회답한 것인지 알려준다.

 

캐시

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

 

4. 프로토콜 스택에 메시지 송신을 의뢰한다

1. 데이터 송/수신 동작의 개요

- DNS 서버에 IP 주소를 조회할 때와 같이 Socket 라이브러리에 들어있는 프로그램 부품을 이용한다. 복수의 부품을 결정된 순번대로 호출해야 하므로 조금 복잡하다.

- 데이터를 송/수신하는 컴퓨터 사이에 데이터의 통로 같은 것이 있고, 한쪽 끝에서 파이프에 데이터를 쏟아부으면 파이프 안을 통해 반대쪽 끝까지 도착하고, 거기에서 데이터를 추출할 수 있다. 데이터는 양방향이다.

- 사실 송/수신 동작을 하기 전에 송/수신하는 양자 사이를 파이프로 연결하는 동작이 필요하다.

- 소켓은 파이프의 양 끝에 있는 데이터의 출입구이다. 우선 이 소켓을 만들고 연결한다. 실제로는 서버측에서 소켓을 만들고, 소켓에 클라이언트가 파이프를 연결하기를 기다린다.

- 데이터를 전부 보내고나면 연결했던 파이프가 분리된다. 분리할때는 어느 쪽에서 분리해도 상관없다.

- 데이터 송/수신 동작 단계

  1. 소켓을 만든다. ( 소켓 작성 단계 )

  2. 서버측의 소켓에 파이프를 연결 ( 접속 단계 )

  3. 데이터를 송/수신한다. ( 송/수신 단계 )

  4. 파이프를 분리하고 소켓을 말소한다 ( 연결 끊기 단계 )

- 위 네 가지 동작을 실행하는 것은 OS 내부의 프로토콜 스택이다. 브라우저 등의 애플리케이션은 프로토콜 스택에 의뢰해서 파이프를 연결하거나 데이터를 쏟아붓는다.

 

2. 소켓의 작성 단계

- 소켓 라이브러리의 socket이라는 프로그램 부품을 호출하면 끝이다.

- 소켓이 생기면 디스크립터라는 것을 리턴한다. 이것을 애플리케이션의 메모리에 기록한다. 디스크립터는 소켓을 식별하기 위한것이다. 컴퓨터의 내부에서는 복수의 데이터 송/수신 동작이 동시에 진행되는 경우가 있는데, 이 경우 소켓을 하나하나 식별해야 하기 때문에 디스크립터가 필요하다.

 

3. 파이프를 연결하는 접속 단계

- Socket 라이브러리의 connect 함수를 호출하여 실행한다. 호출할 때 인자로는 디스크립터, 서버의 IP 주소, 포트 번호 세가지 값이다.

- 프로토콜 스택이 통지받은 디스크립터를 보고 어느 소켓을 서버측의 소켓에 접속할 지 판단하여 접속 동작을 실행한다.

- IP 주소는 DNS 서버에 조회하여 조사한 액세스 대상 서버의 IP 주소이다. 접속 동작은 상대측의 소켓에 대해 이루어지므로 소켓을 지정해야 하는데, IP 주소로는 소켓까지 알 수 없다. 포트 번호까지 지정해야 어느 컴퓨터의 어느 소켓과 접속할지를 분명히 지정할 수 있다.

- 디스크립터는 컴퓨터 한 대의 내부에서 소켓을 식별하기 위해 사용하지만, 포트 번호는 접속 상대측에서 소켓을 식별하기 위해 사용한다.

- 클라이언트측의 소켓의 포트 번호는 소켓을 만들 때 프로토콜 스택이 적당한 값을 골라서 할당한다. 이 값을 프로토콜 스택이 접속 동작을 실행할 때 서버측에 통지한다.

- 상대와 연결되면 프로토콜 스택은 연결된 상대의 IP 주소나 포트 번호 등의 정보를 소켓에 기록한다. 이러면 데이터 송/수신이 가능한 상태가 된다.

 

4. 메시지를 주고받는 송/수신 단계

- 애플리케이션은 송신 데이터를 메모리에 준비한다. 웹으로 말하면 요청 메시지가 송신 데이터이다.

- 소켓 라이브러리의 write 함수를 호출할 때 디스크립터와 송신 데이터를 지정한다. 그럼 프로토콜 스택이 송신 데이터를 서버에게 송신한다.

- 서버는 수신 동작을 실행하여 받은 데이터의 내용을 조사하고 적절한 처리를 실행하여 응답 메시지를 반송한다. (자세한 내용은 6장에서)

- 서버의 메시지를 수신할 때는 소켓 라이브러리의 read라는 프로그램을 통해 프로토콜 스택에 수신 동작을 의뢰한다. 이때 수신한 응답 메시지를 저장하기 위한 메모리 영역을 지정하는 데, 이 메모리 영역을 수신 버퍼라고 한다.

 

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

- 브라우저가 데이터 수신을 완료하면 송/수신 동작은 끝난다.

- 웹에서 사용하는 HTTP 프로토콜에서는 응답 메시지의 송신을 완료했을 때 웹 서버측에서 연결 끊기 동작을 실행한다. 이것이 클라이언트 측에 전달되면 클라이언트의 소켓은 연결 끊기 단계로 들어간다. 그리고 브라우저가 read로 수신 동작을 의뢰하면 수신한 데이터를 건네주는 대신 송/수신 동작이 완료되어 연결이 끊겼다는 사실을 브라우저에 통지한다.

- 원래 메시지 하나마다 위의 동작을 계속 실행해야 하지만, 같은 서버에서 복수의 데이터를 읽을 때 접속과 연결 끊기를 반복하는 것은 비효율적이므로 한 번 접속한 후 연결을 끊지 않고 복수의 리퀘스트와 응답 주고받기를 실행하는 방법도 나중에 마련되었다. (HTTP 1.1버전 이후) 이 경우에는 요청 메시지가 없는 상태에서 브라우저에서 연결 끊기 동작에 들어갈 수 있다.