[컴퓨터 네트워크] CH2. 애플리케이션 계층 (1)

이얏호·2025년 10월 3일

2.1 네트워크 애플리케이션의 원리

네트워크 애플리케이션을 만드는 것이란, 네트워크 애플리케이션 개발의 중심의 다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것이다.

ex) 웹 서버 소프트웨어는 브라우저 소프트웨어와 통신

또한 애플리케이션 소프트웨어는 종단 시스템에만 존재하기 때문에, 네트워크 코어 장비에서까지 소프트웨어를 작성할 필요는 없다.
ㄴ> 네트워크 코어 장비는 사용자 애플리케이션을 실행하지 않기 때문이다.
(즉, 애플리케이션 계층에서 기능이 X)
대신에, 네트워크 계층 및 그 하위 계층에서는 기능한다.

네트워크 애플리케이션 구조

Client-server 구조

server : 항상 동작하고 있는 호스트로, 다른 호스트들로부터 호스트 요청을 받으면 요청된 객체를 보낸다.
-고정 IP주소를 가지고 있으며, 주로 data center가 이 역할을 한다

client : 가끔 또는 항상 켜져있는 호스트로, 동적 IP주소를 가지고 있다.
✅ 클라이언트는 서로 직접적으로 통신하지 않음

Peer-peer 구조 (P2P)

항상 켜져 있는 서버에 의존하며, 애플리케이션이 피어라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다.

-peer들은 항상 켜져있지 않고, IP주소가 고정되어 있지 않다

✅ P2P 구조는 보통 상당한 서버 인프라스트럭처와 서버 대역폭을 요구하지않으므로 비용이 효율적 (vs 데이터센터의 clinet-server구조)

⭐이 구조는 자가 확장성 (self-scalability)라는 특성을 가지고 있다.
: 각 피어들이 파일을 다른 피어들에게 분배함으로써 그 시스템에 서비스 능력을 추가하는 특성이다.

프로세스 간 통신

프로세스(process) : 종단 시스템(host)에서 실행되는 프로그램

If 통신 프로세스가 같은 종단 시스템에서 실행될 때는 내부 프로세스 통신 (운영체제)에 의해 좌우된다.

그렇다면 다른 호스트에서 실행되는 프로세스와의 통신은 어떻게 될까?
→ 이런 경우에는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신함

ex) 웹 애플리케이션에서는 ?
: 클라이언트 프로세스와 서버 프로세스가 메시지를 교환한다

➕ 클라이언트 프로세스 - 두 프로세스간의 통신 세션에서 통신을 초기화하는 프로세스
➕ 서버 프로세스 - 새션을 시작하기 위해 접속을 기다리는 프로세스

소켓 (Sockets)

프로세스는 소켓을 통해 네트워크로 메시지를 보내고 받는다.

즉, 프로세스를 집으로 비유하면 소켓은 출입구와 같다.

프로세스가 메시지를 다른 프로세스로 보내고 싶을 때 소켓 바깥으로 메시지를 밀어낸다.
✅ 소켓의 바깥에 다른 프로세스로 소켓 메시지를 보내주는 배달해주는 전송 구조가 있다고 가정한다.

밀어난 메시지가 목적지 호스트에 도착하면 메시지는 그 호스트의 소켓을 거쳐 들어가고, 호스트는 이 메시지를 처리한다.

프로세스 주소 배정

프로세스는 메시지를 받을 때, 반드시 식별자(identifier)를 가지고 있어야한다.

✅ 호스트 장치는 32-bit의 IP 주소를 가지고 있고, 이는 호스트를 유일하게 식별하는 증거다

Q. 프로세스를 식별하는데에 호스트의 IP주소만으로 충분한가?

→ NO, 하나의 호스트에서 여러 개의 프로세스가 동시에 실행될 수도 있으므로 IP주소만으로는 식별이 불가능하다.

식별자는 프로세스에 연결된 호스트이 IP주소와 포트 번호를 가지고 있다.

ex) 포트 넘버? → HTTP서버의 경우 80, 메일 서버의 경우 25
gaia.cs.umass.edu web server에 HTTP 메세지를 보낼 경우..

IP주소는 128.119.245.12이고 포트 넘버는 80이다.

애플리케이션 계층의 프로토콜

애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다. 정의하는 내용은 아래와 같다.

교환 메시지 타입
여러 메시지 타입의 문법
필드에 있는 정보의 의미
언제, 어떻게 프로세스가 메시지를 전송/응답하는지 결정하는 규칙
오픈 프로토콜(->RFCs로 정의되며, 누구나 프로토콜의 정의에 접근가능)
ex. HTTP,SMTP
주요 프로토콜(-> 비개방적으로 공중 도메인에서 구할 수 없다)
ex. Skype, Zoom

애플리케이션이 이용 가능한 트랜스포트(전송) 서비스

data integrity (신뢰적 데이터 전송) 몇몇 app들은 100% 신뢰 가능한 데이터 전송을 필요로 한다. ex) 파일 전송, 웹 문서 전송 등 다른 앱들은 어느 정도의 데이터 손실은 참을 수 있다 ex) 오디오 등

timing (시간) 몇몇 앱들은 효과적으로 작동하기 위해 적은 지연이 필요로 한다. ex) internet telephony, interactive game
throughput (처리율) 몇몇 앱들은 효과적으로 작동하기 위해서는 최소한의 처리량이 필요하다 ex. 멀티미디어 다른 앱들 (탄력적 어플리케이션)은 처리율을 받는 만큼만 쓴다.
security (보안) 데이터 무결성, 암호화 등..

전송 서비스의 요구사항 : common apps

인터넷 전송 프로토콜들이 제공하는 서비스

TCP 서비스
- 신뢰가능한 전송 (in 송신/수신 과정)
- 제어 흐름 : 받는 쪽 버퍼가 넘치지 않게 해준다.
- 혼란 제어 : 손실이 발생하지않도록 해준다.
- 연결 지향 : 클라이언트와 서버 프로세스에 버퍼, 윈도우 크기등을 할당(setup)한다.
  ✅ 시간, 최소 처리량 보장, 보안은 제공하지 않는다.
UDP 서비스
- 비연결형 데이터 전송 (신뢰 X)
  신뢰성, 제어 흐름, 혼란 제어, 시간, 처리량 보장, 보안, 연결 지향은 제공하지 않는다.
Q. 그렇다면 UDP는 왜 존재할까?
→ 효율성으로 따지면 좋다 그래서 인터넷 전화 app 개발자들이 선호한다고 한다.