[네트워크] 1장

1장 웹 브라우저가 메시지를 만든다

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

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

• 브라우저는 몇 개의 클라이언트 기능(웹, 메일 등)을 겸비한 복합적인 클라이언트 소프트웨어
• 따라서, 어느 기능을 사용할 것인지 프로토콜을 통해 제시해주어야 함

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

• 브라우저는 각 프로토콜의 형식에 따라 URL을 해독

3. 파일명을 생략한 경우

• 생략될 경우에 접근할 디폴트 파일을 서버에 미리 설정
• 주로 index.html이나 default.html
• 끝에 / 이 생략될 경우, 우선 이름이 같은 파일 탐색하고 없으면 폴더 탐색

4. HTTP의 기본개념

• 클라이언트와 서버가 주고받는 메시지의 내용과 순서를 정의
• 요청 메시지(Request) : 무엇을 + 어떻게 해서
  • 무엇을 : uri를 사용해 전달
  • 어떻게 해서 : 메소드
• 응답 메시지 (Response) : Status 코드 + 결과 데이터

5. HTTP 리퀘스트 메시지를 만든다.

• URL을 해독하여 웹서버와 파일명을 판단하고 이를 바탕으로 HTTP 리퀘스트 메시지를 만든다.

• 헤더에는 부가적인 자세한 정보를 담는다

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

• 리퀘스트 메시지에 쓰는 URI는 한 개의 파일만 읽을 수 있기 때문에 파일당 하나의 요청메시지
• 한 개의 리퀘스트에 한 개의 응답 메시지 반환

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

1. IP 주소의 기본

• 브라우저는 URL을 해독하거나 HTTP 메시지는 만드는 기능을 하고, 네트워크에 송출할 때는 OS에 의뢰한다.
• 이때, OS에 송신을 의뢰할 때는 도메인이름이 아니라 IP주소를 조사해서 넘겨주어야 한다.
• 서브넷이라는 작은 네트워크(하나의 네트워크는 여러개의 서브넷으로 쪼갤 수 있다)를 라우터로 접속
• 하나의 서브넷에는 여러 개의 PC가 허브로 연결되어 있음
• IP 주소 : 네트워크 번호 + 호스트 번호
  • 네트워크 번호 : 기존 네트워크 번호 + 추가 네트워크 비트(서브넷) ← 총 자리 수를 넷마스크로 표기
• 호스트 번호가 모두 0인 IP는 네트워크 자체를 표현
• 호스트 번호가 모두 1인 IP는 브로드캐스트를 표현

1-1. TCP/IP 네트워크 동작 방식

송신측에서 메세지를 보내면 서브넷 안의 허브가 운반하고, 가장 가까운 라우터로 보낸다. 라우터가 수신측과 가장 가까운 라우터까지 이동시키켜서 또 허브로 운반해서 PC로!

실제 IP주소는 32비트, 8비트씩 4개의 숫자로 되어있다.

단, 어디까지가 네트워크 번호, 호스트 인지는 정해져있지 않고 네트워크 구축 시에 사용자가 설정 가능

이 내역을 필요에 따라 IP주소에 덧붙이는데 이를 넷마스크라고 함.

넷마스크 : 1인 부분은 네트워크 번호, 0인 부분은 호스트 번호

---

IP 주소에서

호스트 번호가 모두 0인 주소 : 서브넷 자체를 가르킴

호스트 번호가 모두 1인 주소 : 서브넷 안의 모든 기기에 패킷을 보내는 브로드 캐스트

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

1. IP주소는 사람이 기억하기 어렵기 때문에 도메인명 사용
2. 도메인명만 쓰면 경우의 수가 너무 많음 → 라우터의 부하 → 네트워크 속도가 느려짐 → IP 주소 사용

인터넷 내부의 다수의 규칙이 있고 그것들이 연대하여 IP 주소에 의해 목적지를 판단

고성능이어도 한계가 있으며, 한계에 다다르면 방대한 양의 데이터가 인터넷 내부에 정체되어 있을 수 있다.

DNS : 이름을 알면 IP 주소를 알 수 있고, IP 주소를 알면 이름을 알 수 있다는 원리

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

DNS 서버를 조회한다 : DNS 서버에 조회 메시지를 보내고 응답을 받는다.

DNS 리졸버 (리졸버) : 네임 리졸루션을 수행

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

라이브러리 : 부품화한 프로그램. 모아서 애플리케이션을 만들 수 있다.표준화 가능

Socket 라이브러리 : OS에 포함되어 있는 네트워크의 기능을 애플리케이션에서 호출하기 위한 부품을 모아놓은 것

리졸버의 실체는 Socket 라이브러리에 들어있는 부품화한 프로그램

4. 리졸버를 이용하여 DNS 서버를 조회한다. & 리졸버 내부의 작동

1. 네트워크 애플리케이션에서 리졸버 프로그램명(웹서버의 이름) 을 통해 리졸버 호출 → 제어가 리졸버로 넘어간다
2. DNS 서버에 문의하기 위한 메시지 만들고 OS 프로토콜 스택을 호출
3. LAN 어댑터를 사용해서 UDP 메시지를 DNS 서버로 송신
4. 액세스 대상의 웹 서버가 DNS 서버에 등록되어 있으면 응답
5. 프로토콜 스택을 경유하여 리졸버에 건네져서 리졸버는 IP 추출하여 애플리케이션이 지정한 메모리에 반환

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

1. DNS 서버의 기본 동작

클라이언트에서 조회 메시지를 받고 조회의 내용에 응답하는 형태로 정보를 회답

조회 메시지에는 이름, 클래스, 타입 세 가지 정보가 포함

1. 이름
   • 서버나 메일 배송 목적지
2. 클래스
   • DNS의 구조를 고안했을 때는 인터넷 이외의 네트워크 이용까지 있었는데 이를 식별하기 위함
   • 지금은 인터넷 이외의 네트워크는 소멸되었으므로 그냥 ‘IN’값
3. 타입
   • 회답 타입
   • A : IP 주소(Address)
   • MX : 메일 배송 목적지
4. 클라이언트가 위의 세 가지 정보를 포함한 조회 메시지를 보냄
5. DNS 서버는 등록된 정보를 찾아서 세 가지가 일치하는 레코드를 찾음
6. 등록되어있는 정보(IP주소, 메일 목적지)를 회답

www는 웹서버임을 의미(구냥 서버이름)

---

메일 배송 목적지가 타입일 때

MX 타입

그러면 DNS 서버는

1. 우선순위
2. 메일 서버의 이름
3. 2번의 메일 서버의 이름으로 조회한 IP 주소

3가지를 회답

---

이 외에도 PTR, CNAME, NS, SOA 등이 있다.

설정 파일 (표)의 정보에 해당하는 맨 위의 줄을 리소스 레코드

---

2. 도메인의 계층

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

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

www.lab.cyber.co.kr

오른쪽이 최상위 계층

점으로 나눠진 것 각각이 하나의 도메인

하나의 도메인 정보는 일괄적으로 취급됨(하나를 여러개로 분산은 불가능)

한 대의 DNS에 서버에 여러개의 도메인 정보를 가짐

필요하면, 하위 도메인을 만들어서 사업부마다 DNS 서버를 두는 것도 가능하다!

sub1.example.co.kr

sub2.example.co.kr 등

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

하위 도메인이 들어있는 DNS 주소를 상위 도메인의 DNS에서 저장해놓기

lab.glasscom.com이라는 도메인을 담당하는 DNS 서버의 주소를 glasscom.com이라는 도메인을 담당하는 DNS 서버가 가지고 있기

맨뒤의 도메인(최상위 도메인) 의 상위의 도메인을 루트 도메인이라고 한다.

이름이 없기 때문에 생략하지만 맨끝에 점을 찍어 나타내기도(잘안함)

루트 도메인의 DNS 서버는 com이나 kr 등의 도메인을 담당하는 DNS의 주소를 가진다.

모든 DNS 서버는 루트 도메인의 DNS 서버를 가진다.

어디서든지 루트 도메인에 액세스할 수 있다.

클라이언트에서 어딘가의 DNS 서버에 액세스하면(가장 가까운 DNS, 클라이언트의 TCP/IP 설정 항목에 등록되어 있는 DNS 서버) 이 곳에서 루트 도메인을 경유하여 목적지 도메인 DNS 서버로 간다.

루트 도메인에 할당된 IP 주소는 13개 밖에 없기 때문에 다른 DNS에서 이를 저장하는 것은 어렵지 않음.

DNS 서버 소프트웨어 깔면 자동으로 등록됨

 

클라이언트와 가장 가까운 DNS와 각 계층의 DNS가 IP 주소 회답 과정을 거쳐서 원하는 IP를 찾음

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

조사한 정보는 캐시에 저장할 수 있다(도메인 이름 or 도메인 이름이 없다는 정보)

이때 Data의 정합성에 주의할 것.

→ 캐시 TTL 설정 & 캐시에서 가져온 정보인지 DNS 서버에서 회답한 정보인지 알려주어야 함.

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

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

• IP주소와 함께 프로토콜 스택에 의뢰

파이프를 연결하는 과정 (이는 OS의 프로토콜 스택이 수행하는 것)

1. 소켓 작성 단계 : 서버와 클라이언트가 각각 소켓 만들기
2. 접속 단계 : 클라이언트가 파이프 연결(소켓 만들고 이를 늘려서 파이프로)
3. 송수신 단계: 데이터를 쏟아부음
4. 연결 끊기 단계 : 데이터 모두 보내면 파이프 분리(어느쪽에서 하든 상관없음)

주의

Socket 라이브러리의 프로그램 부품은 프로토콜 스택에 전달하는 중개역을 수행할 뿐 실질적인 작업은 하지 않는다.

2. 소켓의 작성단계

• 클라이언트 소켓 생성: 어플리케이션에서 Socket 라이브러리 내의 프로그램을 호출하면 디스크립터 반환 (메모리에 저장해두기)
  • 디스크립터 : 소켓을 식별하기 위해 사용하는 것 (한번에 여러개의 송수신 동작하기도 함. 해당 송수신 동작에 해당하는 소켓인지 식별하기 위함)

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

• connect 호출
• connect(디스크립터, 서버 IP 주소, 포트번호)
  • 디스크립터로 사용할 소켓 식별
  • 송수신하는 상대의 IP 주소
  • IP 번호와 포트번호를 조합하여야 상대 서버의 소켓을 식별 가능
    • 서버의 포트번호는 애플리케이션의 종류에 따라 미리 결정되어 있음
    • 클라이언트 소켓의 포트 번호는 리퀘스트 생성 시 OS(프로토콜 스택)가 임의로 정하고 이를 서버에 접속 시도할 때 전송
  • 연결 되면 IP 번호와 포트번호를 소켓에 저장

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

• 송신
  • 송신 데이터를 준비(메모리의 송신 데이터)
  • write 호출(프로토콜 스택 호출)하면서 디스크립터와 송신 데이터 지정
  • 프로토콜 스택이 송신데이터를 서버에 전송
• 수신
  • read 호출, 수신 버퍼도 함께 전달(응답 메시지를 저장할 메모리 주소)

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

• 응답 메시지를 송신 완료한 서버는 close를 호출하여 연결을 끊는다.
• 클라이언트 측도 이를 전송받아 소켓 연결 끊기
• 브라우저는 모든 데이터를 받았는지 read를 계속 호출하는데, read를 호출했을 때, 응답 데이터 대신 연결이 끊겼음을 통보 → 브라우저도 close
  • 보통의 경우, HTTP 헤더의 'Content-Length' 필드로 응답 본문의 크기를 알 수 있기 때문에 모든 데이터를 다 받았다고 판단한 브라우저가 자체적으로 close함

•