모두의 네트워크
[모두의 네트워크]는 이제 막 네트워크를 공부하기 시작했거나 공부해야겠다고 마음먹은 초급자를 대상으로 한 입문서다. 네트워크의 개념, 비트, 바이트부터 OSI 계층, 무선 랜 구조까지 160개의 일러스트와 유쾌한 캐릭터들의 대화로 설명해 그림책을 읽듯 쉽고 재미있게 네트워크 관련 지식을 익힐 수 있다. [모두의 네트워크]로 누구나 쉽게 네트워크를 익혀 보자!
저자
미즈구치 카츠야
출판
길벗
출판일
2018.06.30

본 글은 위의 책을 바탕으로 학습한 내용을 정리하고, 그에 대한 개인적인 생각을 함께 기록한 글입니다.

 

 

응용 계층의 역할

응용 계층은 App(응용 프로그램) 간 통신을 하기 위한 규칙이 정의 된 계층이다.

나는 여기서 "응용 계층 외에도 계층이 많은데 이 계층들도 모두 응용 프로그램을 위한 통신 아닌가?"라는 의문이 들었었다.

생각하면서 유레카마냥 깨달은 것이 캡슐화였다.

 

응용 계층에서 다루어지는 데이터는 다른 계층에서 알 필요가 없고, 그 반대도 마찬가지다.

따라서 실제로는 각 계층을 통과해서 다른 기기로 통신하지만, 다른 관점으로 보면 응용 계층끼리만 대화한다고 볼 수 있다.

이 점 때문에 응용 프로그램 간 통신을 한다고 설명할 수 있다고 생각한다..!

 

각설하고, 응용 계층에서 사용하는 프로토콜은 다양하다.

왜냐하면 App에서 서비스하는 종류가 많듯이, 각 프로토콜도 그에 맞는 서비스로 특화된 종류가 다양하기 때문이다.

프로토콜 내용 포트 번호
HTTP 웹 사이트 접속 80
DNS IP주소를 문자열화 53
FTP 파일 전송 20 (데이터 전송)
21(명령과 응답 제어)

 

HTTP (Hypertext Transfer Protocol)

웹 사이트 접속을 위한 프로토콜이다.

클라이언트는 URL을 입력하여 서버에 서비스 요청(Request)을 하고,

서버는 그에 대한 응답(Response)으로 서비스에 맞는 데이터를 처리 및 반환한다.

 

예를 들어 주소창에 www.google.com 을 입력하면,

브라우저는 HTTP 프로토콜을 사용해 서버에 페이지를 요청하고 응답을 받아 화면에 표시한다.

이렇게 웹 사이트 접속에 대한 요청과 응답을 위해 HTTP 프로토콜이라는 데이터 교환 규칙을 사용한다.

 

HTTP의 메서드

이 메서드는 클라이언트가 서버에게 어떤 작업을 요청하는지를 표현한다. 예시로 보는 게 빠르다!

메소드 설명 예시
GET 서버에 데이터를 요청하는 의미의 메세지 캐릭터 정보 조회, 게시글 읽기
POST 서버에 데이터를 보내 처리를 요청하는 메시지 계정 생성, 로그인, 아이템 강화
PUT 서버에 받은 데이터 전체를 갱신한다는 의미의 메세지 설정 파일 덮어쓰기
PATCH 서버에 받은 데이터 일부를 갱신한다는 의미의 메세지 닉네임 변경, 옵션 하나만 수정
DELETE 서버에 있는 데이터를 삭제 계정 삭제, 친구 목록에서 친구 삭제

 

내가 글을 작성하는 주소에서도 post라는 메서드를 찾아볼 수 있다.

글의 저장도 어떤 처리 요청이기 때문에 post를 사용한 게 아닐까?

 

HTTP 경로

HTTP 경로는 서버 내부에서 요청 대상이 되는 자원, 데이터를 의미한다.

예를 들자면 구글 서버 컴퓨터에 아래와 같은 파일 구조가 있다고 가정한다.

여기서 html와 png 같은 파일 자원이라고 볼 수 있고,

각 자원에 접근하기 위해서는 이런 링크로 접근을 한다.

  • http://www.google.com/A/index.html
  • http://www.google.com/A/B/icon.png

이때 http://www.google.com/은 이전에 배운 도메인이며,

노란 배경으로 된 부분이 바로 HTTP 경로다.

현재의 HTTP경로
이전 과거의 정적 웹에서는 위와 같이 HTTP 경로 = 서버 내부 파일 경로 가 맞았지만,
현재는 서버 코드가 동적으로 HTMl을 생성하여 응답하는 경우가 많기 때문에 보통 저렇게 1:1 대응이 되지는 않는다.
위의 예시는 대강 느낌을 파악하는 예시로 생각하면 좋다.

정리하면, HTTP 경로는 서버가 관리하는 자원을 식별하기 위한 논리적 주소라고 할 수 있다.

 

HTTP 데이터 구조

HTTP 프로토콜의 데이터 구조는 대략 아래와 같다.

시작 라인
헤더
1줄의 공백
바디
  1. 시작 라인
    요청에서의 구조와 응답에서의 형식이 다르다.
    • 요청(Request) 시작 라인
      메서드 : 무엇을 할지
      경로 : 서버 안에서의 어떤 자원인지
      HTTP 버전 : 규칙의 버전
      시작 라인 한 줄만 보더라도 어떤 방식으로 어떤 자원을 어떤 규칙으로 요청하는지 알 수 있다.

    • 응답(Response) 시작 라인
      각 3가지의 데이터는 서버의 처리 결과를 한눈에 알 수 있다.
  1.  
  2. 헤더
    헤더는 [Key: Value]의 형태를 가진 메타데이터다.
    헤더의 역할은 본문을 어떻게 해석해야 하는지, 누가 보냈는지, 연결을 유지할지, 이런 추가적인 정보를 담는다.

    예시로 이런 식으로 사용된다.
    • 어떤 도메인에 대한 요청인지
      Host: www.google.com
    • 요청한 클라이언트의 정보
      User-Agent: Chrome/143
    • 바디의 형식
      Content-Type: text/html

  3. 한 줄의 공백
    해당 공백의 의미는 헤더의 끝과 바디의 시작을 의미하는 구분자 역할을 한다.

  4. 바디
    바디가 바로 우리가 실제 전달하고 싶은 데이터다.
    형태는 html 뿐만 아니라  json, xml, binary 등이 가능하다.

 

포트

인터넷을 하다 보면 수많은 사이트에 들어가게 되는데, 각 사이트의 서버 컴퓨터에 접속하기 위한 포트번호는 어떻게 알았을까?
바로 각 응용계층의 프로토콜마다 기본적으로 사용하기로 약속한 포트 번호를 가지고 있기 때문에, 어느 포트로 전송해야 하는지 알 수 있던 것이다. 이런 약속된 포트 번호를 Well known port라고 한다.

 

각 프로토콜의 Well known port은 아래와 같다.

  • HTTP : 80
  • HTTPS : 443
  • DNS : 53
  • FTP : 20 or 21

하지만 강제가 아닌 약속이다 보니까, 다른 포트 번호를 얼마든지 사용할 수도 있다.

이때, 중요한 건 약속을 어기게 되면 클라이언트가 어느 포트인지 명시를 해야 한다.

 

 

DNS

네트워크에서는 IP 주소와 MAC 주소를 이용해 통신을 한다.

그런데 우리가 각 사이트에 접속하면서, 각 사이트에 해당하는 IP 주소는 어떻게 알았을까?

그래서 IP 주소를 파악하기 쉬운 형태인 문자열로 다뤄보자 라는 게 바로 우리가 알고 있는 www.naver.com 같은  도메인 주소다.

 

근데 DNS는 프로토콜인 규칙일 뿐인데 누가 도메인 주소를 IP 주소로 변경해 줄까?

이것도 당연히 어딘가에 있는 컴퓨터의 서버가 해주는 것이다. 이렇게 DNS프로토콜을 이용해 서비스를 제공해주는 서버를 DNS서버라 부른다.

우리가 사용하는 DNS 서버의 IP는 공개되어 있어 우리가 사용할 수 있는 것이다.

3, 4번의 경우 HTTP 프로토콜을 이용한다.

근데 해당 DNS 서버가 우리가 요청한 도메인에 대해 잘 모를 수도 있다.

그럼 DNS가 또 다른 DNS 서버에게 질의하여 물어보는 식으로 IP 주소를 찾아준다.

 

해당 과정은 먼저 이렇다.

  1. 내 컴퓨터에 저장된 캐시에서 찾아보기
  2. 로컬 메모리 같은 Recursive 서버에서 찾아본다.
  3. Recursive 서버가 못 찾으면 다른 dns에 물어본다.

 

DHCP

그럼 IP 주소를 할당하는 관리자는 어떻게 내 컴퓨터에 IP주소를 할당했을까?

더 나아가서 더 많은 사람들의 IP 주소는 어떻게 관리할까?

이에 대한 답이 DHCP에 들어있다.

 

IP 주소를 자동으로 관리하기 위해 등장한 것이 DHCP 서버로,

사용자들에게 IP 주소를 할당하거나 회수하는 것을 자동으로 해주는 서버다.

여기서 DHCP에 연결할 때, DHCP의 IP주소를 모르는데 어떻게 연결하지?라는 의문이 있었다.

이를 가능케 하는 건 브로드캐스트 + 특별한 IP 주소 규칙이다.

 

정확한 예시로 로컬 네트워크 안에 DHCP 서버 있!나!!요!!!!!!! 라고 전체에 외치는 것이다.

이게 바로 브로드 캐스트다.

여기서 로컬 네트워크라고 명시한 이유는, 아직 IP주소가 없고 가진 게 MAC주소뿐이기 때문이다.

 

이 외침을 DHCP서버가 듣게 되면 응답하게 되는 방식으로 통신을 한다.

DHCP서버가 응답할 때는 아래와 같은 제안을 한다.

 

  • 이 IP 어때? 이 서브넷 마스크 써, 게이트웨이는 여기야, DNS는 이거야

이 응답 역시 브로드 캐스트로 보내게 되는데, 이유는 아직 클라이언트의 IP가 없기 때문이다.

 

여기서 궁금한 게 또 생겼다. 그럼 로컬 네트워크마다 DHCP 서버가 있는 건가?

해답은 있을 수도 있고 아닐 수도 있다 다.

 

IP 주소를 자동으로 할당받고 있다면, 어딘가에는 DHCP 역할을 수행하는 서버가 분명 존재한다.

근데 로컬 네트워크는 굉장히 많은데, 그 네트워크마다 DHCP 서버가 존재할 수 있을까?

할 수 있다. 바로 공유기가 DHCP 서버의 역할을 수행할 수 있기 때문이다. 

 

다만 다음과 같은 경우에는 DHCP가 없다.

  • IP를 수동으로 설정하는 네트워크
  • 폐쇄망 / 테스트용 네트워크

이 경우 각 장비에 IP, 게이트웨이, DNS를 직접 설정해야 한다.

 

SMTP와 POP3 프로토콜

해당 프로토콜은 이메일을 주고받을 때 사용하는 프로토콜이다.

송신자가 사용하는 프로토콜이 SMTP이고,

수신자가 사용하는 프로토콜이 POP3다.

 

 

로드 밸런서

전송 계층뿐만 아니라, 응용 계층에도 로드 밸런서가 존재한다.

응용 계층의 로드 밸런서는 전송 계층의 로드 밸런서 기능까지 포함하고 있다.

즉, IP주소나 포트 외에도 URI, HTTP 헤더 쿠키 등의 내용을 기준으로 부하를 분산시켜 주는 것이 응용 계층의 로드 밸런서다.

 

 

용어 정리

  • 파싱
    어떤 페이지에서 내가 원하는 데이터를 추출하는 것.

  • Keepalive
    연결이 됐을 때, 데이터 교환이 끝나면 바로 연결을 끊는 구조

  • DNS 서버
    IP 주소를 도메인 주소로 변경해 주는 서버

  • DHCP 서버
    사용자들에게 IP 주소를 자동으로 관리해 주는 서버

  • HTTP
    웹 사이트 접속을 위한 프로토콜

+ Recent posts