네트워크 원리 - 웹 브라우저가 메시지를 만든다

1. 네트워크란?

❓ 네트워크란?

• 네트워크를 한 마디로 요약하자면 브라우저의 요청으로 웹서버에 액세스하여 해당 응답을 브라우저에 표현하는 브라우저와 웹서버가 대화하는 동작이라고 정의할 수 있습니다.
  

⭐ 네트워크 전체 모습

• 네트워크는 사용자측(브라우저)부터의 요구(리퀘스트)를 서버에 보냅니다.
• 웹서버는 요구에 따라 움직이고 결과(응답)을 브라우저에 돌려보냅니다.
• 웹 브라우저, 프로토콜 스택(TCP/IP), LAN 드라이버부터 시작해 허브를 포함한 서브넷부터 라우터, 액세스 회선, 라우터, 통신사를 통해 웹서버에 도착하게 됩니다.
• 이번 포스팅은 웹브라우저에서 메시지를 만드는 것을 위주로 포스팅하겠습니다.
  

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

✏️ 2-1. HTTP 리퀘스트 메세지를 작성한다.

• 🍀 1. HTTP 탐험 여행은 URL 입력부터 시작한다.
  • URL은 http:// 뿐만 아니라 ftp:, file:, mailto:, news: 등의 url이 있다.
  • URL은 http와 ftp를 보면 프로토콜을 나타내는구나 생각할 수 있는데 file 같이 네트워크를 사용하지 않는 것도 있으므로 프로토콜이라고 단언할 수는 없다.
  • '액세스 방법'이라는 식으로 생각하는 것이좋다.

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

  • URL 해독
    • http: + // + (웹서버명) + / + (디렉토리명) + / + ... + (파일명)
  
  

• 🍀 3. 파일 명을 생략한 경우

  • 파일명 생략
    • EX) http://www.lab.cyber.co.kr/dir/
    • 하지만 파일명을 쓰지 않으면 어느 파일에 액세스해야 할지 모른다.
    • 이럴 경우 보통, 대부분의 서버가 /dir/index.html, /dir/default.html로 설정해둔다

• 🍀 4. HTTP의 기본 개념
  • HTTP 프로토콜
    • 클라이언트와 서버가 주고 받는 메시지의 내용이나 순서를 정한 것
    • 보통 클라이언트가 서버에게 "무엇을" "어떻게 해서" 하겠다는 내용을 요청한다.
    • URI : "무엇을" / 메서드 : "어떻게 해서"
      

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

- HTTP의 메세지를 만들면 다음에는 이것을 OS에 의뢰하여 액세스 대상의 웹서버에게 송신한다.
- HTTP의 메세지를 만들기 위해 HTTP의 많은 헤더 필드 종류가 있으니 확인해 보시길 바랍니다.

• 📌 서브넷

  • TCP/IP는 서브넷이라는 작은 네트워크를 라우터로 접속해서 전체 네트워크가 만들어진다고 생각할 수 있다.
  • 허브에 몇대의 PC가 접속된 것이라고 생각하고 이것을 한 개의 단위로 생각하여 서브넷이라고 부르고, 라우터에서 연결하면 네트워크 전체가 완성된다.
    

• 📌 IP

  • 🍀 IP란?

    • 집주소처럼 'ㅇㅇ동 ㅇㅇ번지'라는 형태로 네트워크의 주소를 할당한다.
    • 네트워크 번호 : 동에 해당하는 번호를 서브넷에 할당
    • 호스트 번호 : 번지에 해당하는 번호를 컴퓨터에 할당한 것이 네트워크 주소
    • IP 주소 : 네트워크 번호 + 호스트 번호
      
      

  • 🍀 IP 주소 본체의 표기 방법
    10.11.12.13

    • IP주소는 32비트의 디지털 데이터로, 8비트(1바이트)씩 점으로 구분하여 10진수로 표기한다.
      
      

  • 🍀 IP 주소 본체와 같은 방법으로 네트워크를 표기하는 방법
    10.11.12.13/255.255.255.0

    • IP만으로 어느 부분이 네트워크 번호인지, 호스트 부분인지 알 수 없다.
    • 그렇기 때문에 IP주소 뒤에 255.255.255.0을 붙이게 되는데 이것을 넷마스크라고 부른다.
    • 넷마스크는 앞 3자리 255.255.255는 네트워크 번호를 나타내고, 뒤 .0은 호스트 번호를 나타낸다.
      
      
      

  • 🍀 네트워크 번호의 비트 수로 넷마스크 표기하는 방법
    10.11.12.13/24

    • 10.11.12.13/255.255.255.0처럼 표기하면 너무 길어지기 때문에 이를 10진수로 나타낸 표기법
      
      

  • 🍀 서브넷을 나타내는 주소
    10.11.12.0/24

    • 호스트 번호의 부분의 비트가 모두 0인 것은 각 컴퓨터가 아니라 서브넷 자체를 나타낸다.
    
    

  • 🍀 서브넷의 브로드캐스트를 나타내는 주소
    10.11.12.255/24

    • 호스트 번호의 부분의 비트가 모두 1인 것은 서브넷 전체에 대한 브로드캐스트를 나타낸다.
    • 브로드캐스트 : 서브넷에 있는 기기 전체에 패킷을 보냄

• 📌 DNS

  • 🍀 DNS & DNS 리졸버란?
    

    • 사용자가 브라우저에 www.google.com을 치면 브라우저는 DNS서버에서 www.google.com의 IP주소를 찾아서 요청하고 응답 받을 수 있다.
    • 사용자 브라우저측은 DNS 서버의 클라이언트로 동작한다고 말할 수 있고, 이는 DNS 리졸버 또는 리졸버라고 부른다.
    • DNS의 원리를 사용하여 IP주소를 조사하는 것을 네임 리졸루션(name resolution, 이름확인)이라고 부른다.
    • 이 리졸루션을 사용하는 것이 리졸버이다.
    
    

  • 🍀 DNS 설정

    • DNS 서버에 메세지를 송신할 때도 DNS 서버의 IP주소가 필요하다.
    • 단, 이것은 TCP/IP 설정 항목의 하나로, 초기에 컴퓨터에 미리 설정되어 있으므로 다시 조사할 필요는 없다.
    • 사용자가 다시 DNS서버 IP를 변경할 수 있다.

• 📌 Socket 라이브러리

  • 🍀 Socket 라이브러리란?

    • OS에 포함되어 있는 네트워크 기능을 애플리케이션에서 호출하기 위한 라이브러리
    • 도메인명에서 IP 주소를 조사할 때 브라우저는 Socket 라이브러리의 리졸버를 사용

  • 🍀 Socket 리졸버 동작
    

    1. [애플리케이션(브라우저)] gethostbyname(URL) 메서드 호출
       • 애플리케이션에서 Socket 라이브러리의 IP가져오는 메서드 호출
    2. [Socket] 조회 메세지(URL)을 OS 내부의 프로토콜 스택에 보낸다
       • URL을 해당 메서드를 타서 OS의 프로토콜 스택으로 전송
    3. [프로토콜 스택] UDP 메시지 송신
       • 프로토콜 스택은 UDP 메세지를 송신하여 LAN 어댑터로 전송
    4. [프로토콜 스택] LAN 어댑터
       • LAN 어댑터는 DNS 서버로 IP 요청
    5. [프로토콜 스택] DNS 서버
       • 요청 받은 URL의 IP를 응답
    6. [프로토콜 스택] LAN 어댑터
       • IP를 다시 프로토콜 스택에 전송
    7. [프로토콜 스택] UDP메세지 수신
       • IP를 Socket에 전송
    8. [Socket] 응답 메세지를 메모리(변수)에 저장
       • IP를 메모리에 저장
    9. [애플리케이션(브라우저)] 도착
       • 제어가 다시 애플리케이션으로 돌아간다.

✏️ 2-3. 전 세계의 DNS 서버가 연대한다.

• 📌 DNS 서버의 기본 동작

  • 클라이언트에서 조회 메세지를 받고 조회의 내용에 응답하는 형태로 정보를 회답한다.
  • 조회 메세지에는 세 가지 정보가 포함되어있다.
    • 이름
      • 서버나 메일 배송 목적지(메일주소에서 @ 뒷부분의 이름)와 같은 이름
    • 클래스
      • DNS의 구조를 고안했을 때 인터넷 이외에도 네트워크에서의 이용까지 검토하여 이것을 클래스라는 정보를 준비했지만 현재는 인터넷 외의 네트워크는 없기 때문에 클래스는 항상 인터넷을 나타내는 'IN'을 사용한다.
    • 타입
      • 이름에 어떤 타입(종류)가 지원되는지 나타낸다. 예를 들어 타입이 A이면 이름에 IP주소가 지원되는 것을 나타내며, MX이면 이름에 메일 배송 목적지가 지원된다는 것

• 📌 도메인의 계층 + 여러 데이터 분산

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

  • 🍀 계층적으로 도메인을 DNS서버에 저장한다

    • www.hgsssss.co.kr일 경우
      • 최상위 kr : 대한민국
      • co : 회사
      • cyber : 회사 도메인명
      • kr -> co -> cyber로 갈수록 하위도메인
    
    

  • 🍀 하위 도메인을 담당하는 DNS서버의 IP주소를 그 상위의 DNS서버에 등록한다.
    

    • www.zum.hgsssss.com을 찾아야하는 경우
      1. 가장 가까운 DNS서버를 통해 루트 도메인으로 올라간다.
      2. 루트 도메인 서버에 www.zum.hgsssss.com의 IP주소를 물어보면, com도메인(123.123.123.123)가서 물어보라고 한다.
      3. com 서버(123.123.123.123)에 물어보면, hgsssss도메인(234.234.234.234)가서 물어보라고 한다.
      4. hgsssss 서버(234.234.234.234)에 물어보면, zum도메인(456.456.456.456)가서 물어보라고 한다.
      5. zum 서버(456.456.456.456)에 물어보면, www.zum.hgsssss.com의 IP주소는 789.789.789.789라고 응답한다.
      6. 사용자(브라우저는) www.zum.hgsssss.com(789.789.789.789)에 응답 요청한다.
      
      ⭐ 루트 도메인부터 상위 도메인이 하위 도메인의 IP주소를 저장하기 때문에 com -> hgssss -> zum -> www 하위 도메인서버로 계층적으로 DNS서버부터 원하는 서버 IP를 찾아갈 수 있다.
      
      

  • 🍀 DNS 서버 캐시 사용

    • DNS 서버는 한 번 조사한 이름을 캐시에 기록할 수 있는데, 조회한 이름에 해당하는 정보가 캐시에 있으면 그 정보를 회답하기 때문
    • 캐시한 위치에서 계층 구조를 아래로 향하여 찾을 수 있다.
    • ❗️ 주의점 : 캐시에 정보를 저장한 후 등록 정보가 변경되는 경우도 있으므로 캐시 안에 저장된 정보는 올바르다고 단언할 수 없다.
    
    

✏️ 2-4. 프로토콜 스택에 메세지 송신을 의뢰한다.

• 📌 데이터 송 수신 동작

  • OS 내부의 프로토콜 스택에 메세지 송신 동작을 의뢰할 때는 Socket 라이브러리 프로그램 부품을 결정된 순번대로 호출한다.
  • 실제로는 먼저 서버측에서 소켓을 만들고, 소켓에 클라이언트가 파이프를 연결하기 기다립니다.

  

  • 🍀 OS 내부의 프로토콜 스택이 하는 역할

    1. 소켓을 만듭니다 (소켓 작성 단계)
    2. 서버측의 소켓에 파이프를 연결합니다. (접속 단계)
    3. 데이터 송수신합니다. (송수신단계)
    4. 파이프를 분리하고 소켓을 말소합니다 (연결 끊기 단계)
       
       

  • 💡 1. 소켓 작성 단계, 디스크립터

    • 소켓은 애플리케이션과 프로토콜 스택 사이에서 네트워크 송수신을 호출합니다.
    • 소켓이 생기면 디스크립터라는 것이 돌아오므로 애플리케이션은 이것을 받아서 메모리에 기록합니다.
    • 예를 들어 창을 2개 열어서 웹서버에 동시에 액세스하면 소켓이 2개가 생기고 이 2개의 소켓을 식별해야하는데 이 소켓 하나하나에 할당한 번호를 디스크립터라고 합니다.
    • 소켓을 만든 후 디스크립터를 이용하여 접속 동작이나 데이터 송수신 동작을 실행하는데 이때 디스크립터를 보여주면 프로토콜 스택이 어느 소켓을 사용하여 접속할지 또는 데이터를 송수신할지 금방 알 수 있습니다.
      
      

  • 💡 2. 파이프를 연결하는 접속 단계

    • 소켓의 connect를 호출하면 프로토콜 스택이 접속하는 동작 실행
    • 접속할떄 디스크립터(소켓), ip주소, 포트번호가 필요하다
    
    

  • 💡 3. 메세지를 주고 받는 송 수신 단계

    • 소켓이 상대측과 연결되면 데이터를 쏟아부으면 상대측 소켓에 데이터가 도착한다.
    • socket의 write 호출
      • write를 호출할 때는 디스크립터와 송신 데이터를 지정 -> 프로토콜 스택이 송신 데이터를 서버에 송신
    • socket의 read 호출
      • 메세지가 돌아오면 수신한 응답 메세지를 저장하기 위한 메모리 영역을 지정하는데 이 메모리 영역을 수신 버퍼라고 부른다.
      • 그러면 read가 받아서 수신버퍼에 응답 메세지를 저장한다.
    
    

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

    • socket의 close 호출
    • 브라우저가 데이터 송수신을 완료하면 socket의 close를 호출
    • 소켓 사이를 연결한 파이프와 같은 것은 분리되고 소켓도 말소된다.
    • HTTP프로토콜에서 응답 메세지의 송신을 완료했을 때 웹서버측에서 연결 끊기 동작을 실행하므로 먼저 웹서버측에서 close를 호출하여 끊는다.
      • HTTP 프로토콜은 HTML문서나 영상 데이터를 별도의 것으로 취급하여 하나하나 데이터를 읽을 때마다 "접속"-> "리퀘스트 메세지 송신" -> "응답 메세지 수신" -> "연결끊기"라는 동작을 반복한다.
    • 하지만 이것은 비효율이기 때문에 HTTP 1.1에서는 리퀘스트해야할 데이터가 없어진 상태에서 연결 끊기를 사용할 수 있다.

---

정리

💡 www.zum.hgsssss.com으로 가는 법

1. 웹브라우저에서 www.zum.hgsssss.com을 친다.
2. socket 라이브러리에서 DNS에 보내는 조회 메세지를 만든다.
3. OS 내부의 프로토콜 스택에 메세지를 보낸다.
4. 프로토콜 스택은 LAN 어댑터로 메세지를 준다.
5. LAN 어댑터는 가장 가까운 DNS서버에 메세지를 준다.
6. 가장 가까운 DNS 서버는 메세지를 루트 도메인 서버에 전송한다.
7. 루트 도메인 서버는 com DNS서버(하위) IP를 알려준다.
8. com DNS서버는 hgsssss DNS서버(하위) IP를 알려준다.
9. hgsssss DNS서버는 zum DNS서버(하위) IP를 알려준다.
10. zum DNS서버는 www.zum.hgsssss.com IP를 알려준다.
11. www.zum.hgsssss.com 의 IP주소를 가장 가까운 DNS서버에 전송하여 클라이언트에게 회답한다.
12. 클라이언트는 www.zum.hgsssss.com에 요청한다.

---

느낀 점

💡

계속 미루고 미뤘던 CS공부, 네트워크를 처음 공부해봤는데 평소에 웹을 개발한다고 하는 웹개발자로서, API요청할 때 어떤 흐름인지도 모르고 개발했다는 것이 부끄러웠고 많이 부족하다고 느꼈습니다. 네트워크 공부를 이제 시작했지만 공부하는 내내 재밌었고 '소켓과 OS 프로토콜 스택'이 존재하기 때문에 애플리케이션에서 네트워크를 통해 요청/응답 받을 수 있구나를 알 수 있었습니다. 앞으로 더 공부하면서 어떤 디테일한 요소들이 숨어있을지 기대됩니다.