[네트워크] 2-1. 네트워크의 구조, Application Layer

kkado·2023년 4월 9일
0

네트워크

목록 보기
5/49

⚠️ 들어가기 앞서
경북대학교 컴퓨터학부 COMP0414-001 컴퓨터망 과목을 공부하며 정리한 글입니다.


네트워크의 구조

네트워크는 그 구조에 따라 크게 서버-클라이언트 구조와 피어 구조 로 나눌 수 있다.

Client-Server

역할에 따라 서버와 클라이언트로 나뉜다. 우리에게 이미 익숙한 구조라고 할 수 있다.
웹 서버, DNS 서버 등 흔히 '서버' 가 사용된다고 하면 이름에서 알 수 있듯 모두 이 구조이다.

서버

서버는 클라이언트가 보낸 요청을 받아서 적절한 응답을 되돌려준다.

  • 항상 접근 가능 (always on-host)
  • 영구적인 IP 주소를 가지고 있음

클라이언트

클라이언트는 자신이 필요한 데이터를 서버에 요청하고, 응답을 받는다.

  • 서버와 연결되어 통신을 주고받는다.
  • 간헐적으로 연결되며, 동적 IP 주소를 가진다.
  • 클라이언트끼리 직접 통신하지 않으며 항상 서버를 거친다.

장단점

클라이언트-서버 모델은 중앙화된 방식으로, 서버가 모든 접근과 데이터를 제어하므로 보안성이 우수하다. 그러나 여러 클라이언트로부터 너무 많은 요청을 받으면 서버가 먹통이 돼버릴 수 있다.

Peer to peer

흔히들 P2P라고 하는 피어 투 피어 네트워크의 경우, 서버와 클라이언트의 개념이 존재하지 않으며, 모든 컴퓨터가 동등하게 직접 통신한다. 두 컴퓨터가 서버를 거치지 않고 다이렉트로 연결하여 데이터를 주고받는다고 생각하면 될 것 같다.

온디스크, 파일조 등 여러 P2P 자료공유 사이트나 토렌트 등이 여기에 해당한다.


소켓이란

먼저 프로세스에 대한 이해가 필요할 것이다.
프로세스란 호스트 안에서 실행되는 프로그램 이다. '프로그램 = 프로세스' 라고 봐도 무방하다.

같은 호스트 내에서 프로세스간 통신은 OS가 제공하는 Inter-Process Communication IPC 를 통해 이루어진다.
호스트와 호스트는 IP 주소를 통해 서로를 식별하고 통신을 주고받는다.

그러나, IP 주소만 가지고서는 프로세스를 특정할 수는 없다. 컴퓨터가 데이터를 받았는데 이 데이터를 요청한 프로세스가 어떤 프로세스인지는 알 수 없다.
그래서, 각 프로세스는 메시지를 받기 위해 어떤 식별자가 필요하다.

프로세스는 식별자를 가지고 있는데, IP 주소와 포트 번호를 포함한다.

각각의 프로세스는 포트 번호를 통해 다른 프로세스와 데이터를 주고받을 수 있다. 그리고 여기서 소켓이 사용된다.

소켓이란 프로세스가 메시지를 주고받는 곳이다.

마치 문을 통해 사람이 들락날락 하는 것처럼 소켓도 프로세스에 데이터가 들락날락 하는 문과 같은 역할을 한다.

Application Layer

이전 글에서 살펴본 계층 중 응용 계층에 해당하는 프로토콜이 정의하는 것들에는 다음과 같은 것들이 있다.

  • types of message : 응답인지, 요청인지 등
  • message syntax : 메시지 안에 어떤 필드가 있고 각 필드는 어떤 역할을 하는지
  • message semantics : 각 필드의 정보
  • 프로세스가 메시지를 주고받는 방법과 타이밍 등에 대한 규칙

어플리케이션이 요구하는 4가지 조건

어플리케이션은 데이터를 주고받을 때 다음과 같은 4가지 조건을 따져본다.
물론 어플리케이션의 특성과, 주고받는 데이터의 특성에 따라 요구사항들은 어플리케이션마다 다르다.

Data integrity

파일 공유 서비스 등에서는 100% 신뢰할 수 있는 데이터의 송수신이 필수적이다. 내가 데이터를 다운로드받는 동안 데이터가 손실되거나 깨져버리면 안 될 것이다.

그러나, 개중에는 100% 완전한 데이터가 필요하지 않은 프로그램도 있다. 예컨대 음성(오디오) 파일의 송수신 같은 경우에는 조금의 노이즈가 발생한다고 해서 큰 지장이 없기 때문이다.

throughput

어떤 프로그램들은 효율적이다 라고 하기 위한 성능의 마지노선 (minimum amount of throughput)이 존재한다. 이 때 '성능' 이라 함은 데이터를 처리할 수 있는 '용량' 에 좀 더 포커스를 둔다. 주로 대용량의 동영상을 안정적으로 스트리밍해야 하는 프로그램 등이 스루풋에 민감할 것이다.

그러나 성능에 크게 구애받지 않는 'elastic' 한 앱도 있다.

timing

요청한 데이터를 얼마나 빨리 받을 수 있는가 에 민감한 프로그램도 있을 것이다. 실시간으로 상황이 빨리빨리 변하는 게임을 예로 들 수 있겠다.

security

사용자의 비밀번호와 같이 개인정보 등에 대한 암호화 여부도 응용 프로그램이 꼭 따져봐야 할 부분이다. 만약 누군가의 비밀번호가 1234 라고 하면, 1234 라는 데이터가 그대로 인터넷 망에서 돌아다니면 개인정보를 갈취당할 위험이 높다.

profile
베이비 게임 개발자

0개의 댓글