Application Layer: 구조, 프로토콜 그리고 보안을 중심으로

Top-Down Approach

위에서 아래로, Application -> Transport -> Network -> Link -> Physical (Layer) 순으로 배워보자.

 

Network Apps

네트워크를 사용하는 대표적인 어플리케이션들을 생각해보자.

• Social networking(Instagram, Twitter, Facebook)
• Web
• text messaging
• e-mail
• multi-user network games
• streaming stored video(YouTube, Hulu, Netflix)
• P2P file sharing
• Voice over IP (Skype)
• real-time video conferencing(Zoom)
• Internet Search(Google)
• remote login

정말 많다. 각각의 어플리케이션들은 다른 요구사항들과 다른 특징들을 가진다.

네트워크 앱을 만들 때,

• 앱은 서로 다른 엔드 시스템들에서 동작해야 한다.
• 앱은 네트워크를 통해 통신할 수 있어야 한다.
• Network-core devices를 위한 별도의 소프트웨어를 만들 필요는 없다.
  • 엔드 시스템의 어플리케이션들은 빠르게 개발이 가능하고, 전파가 가능하다(Rapid app development, propagation)

 

Client-Server Architecture

• server
  • always-on host
    • 클라이언트 연결을 위한 항시 대기
  • Permanent IP address
    • 영구적인 IP 주소
  • often in data centers, for scaling
    • Scale-out이 가능하다.

• Clients
  • 서버에 연결 및 통신한다.
  • 보통 간헐적으로(Intermittenly) 연결된다.
  • 보통 동적인 IP 주소를 가진다.
  • 클라이언트 간에 직접 통신하지 않는다. 서버를 거쳐서 간접적으로 통신한다.
    • 대표적으로 HTTP, IMAP, FTP

 

Peer-peer Architecture

• no always-on server
  • 항시 대기중인 서버가 없다.
• arbitrary end systems directly communicate
  • 임의의 엔드시스템 간에 직접적으로 통신한다.
• peers는 다른 peers에게 서비스를 요청하고, 그 결과 다른 peers로부터 서비스를 제공받는다.
  • Self scalability: 새로운 피어들이 새로운 서비스 수요와 함께 새로운 서비스 가용 능력(capacity)을 가져온다.

• 피어들은 간헐적으로 연결되어 있으며 IP address는 동적으로 변화한다.
  • complex management: 보안 이슈(클라이언트 - 서버 구조보다 악의적인 유저를 막기가 상대적으로 어려움), 서버를 통한 서비스 퀄리티 향상이 어려움
  • P2P file sharing이 대표적인 예시이다.

 

Process communicating

• process: 호스트 내부에서 실행되는 프로그램
• 동일한 호스트 내부에서 두 프로세스는 inter-process communication한다. (OS에서 정의된 방식)
• 다른 호스트들 간에 프로세스들은 메시지를 교환하며 communication한다.
  • Client: communication을 시작하는 프로세스(initiate)
  • Server: 통신(contac)을 대기하는 프로세스(wait)

 

Socket

그렇다면, 어떻게 서로 다른 프로세스 간에 메시지 교환이 가능할까? -> Socket이라는 인터페이스를 통해 가능하다.

즉, 프로세스는 socket을 이용해 메시지를 보내고, socket을 이용해 메시지를 받는다.

Application Layer은 앱 개발자에 의해 제어되고, 그 아래 transport layer부터 physical layer까지는 OS에 의해 제어된다.

소켓은 Application Layer(응용 계층)과 그 아래 계층을 이어주는 중간 다리 역할을 하며, 따라서 응용 계층 하위 단계의 자세한 내용을 모른다 하더라도 소켓을 이용하면 응용 계층만 신경쓰고 네트워크 프로그램을 개발할 수 있다.

 

Addressing processes

메시지를 주고받으려면, 프로세스는 식별자(Identifier)를 가져야 한다. Host Device는 고유의 32비트 IP 주소를 가진다.

Q: Host의 IP address가 프로세스를 식별하는데 충분한 정보일까?

A: 아니다. 호스트에는 여러 프로세스가 실행될 수 있다. IP Address는 호스트를 식별하고, 호스트 내부의 프로세스를 식별하기 위해서는 Port가 필요하다.

프로세스의 식별자(Indetifier)는 IP address와 port 번호를 모두 포함한다.

• 포트 번호 예시
  • HTTP server: 80
  • Mail server: 25

 

Application-layer protocol define

응용 계층 프로토콜이 정의하는 바는 아래와 같다.

• types of messages exchanged(교환하는 메시지 타입)
  • request, response
• message syntax(메시지 문법)
  • 메시지 안의 필드 형식
• message semantics(메시지 의미론적 요소)
  • 필드에 담을 정보의 의미
• rules for when and how process send / response to messages
  • 프로세스가 언제 어떻게 메시지를 주고 받을지에 대한 규칙

 

open protocol

• 개방형 프로토콜

• RFCs에 정의되어있고, 누구든 프로토콜의 정의(definition)에 액세스할 수 있다.
• 상호운용성을 지닌다.
  • 하나의 시스템이 동일 또는 이기종의 다른 시스템과 아무런 제약이 없이 서로 호환되어 사용할 수 있는 성질
• HTTP, SMTP가 대표적인 예시다.

 

proprietary protocol

• 독점 프로토콜
• 단일 조직이나 개인이 소유한 통신 프로토콜이다.
• Skype나 zoom

 

네트워크 어플리케이션의 요구사항

Data integrity (or Tolerance about Data loss)

• 데이터의 정확성과 일관성을 유지하고 보증하는 것
• 어떤 앱들(파일 전송, 웹 트랜잭션과 같은)은 100% reliable data transfer(완전히 신뢰할 수 있는 데이터 전송)를 요구한다
• 또 어떤 앱들은 몇몇 손실(some loss)을 용인할 수도 있다.

timing

• 어떤 앱들(인터넷 통화, interactive games 등)은 앱의 효율을 위해 낮은 지연(delay)를 요구한다.

throughput

• 어떤 앱들(멀티미디어 등)은 앱의 효율을 위해 일정 수준의 처리율을 필요로 한다.
• 또 어떤 앱들(elastic apps) 처리율에 크게 연연하지 않는다.

 

Internet transport protocols services

TCP service

• reliable data transfer
  • 전송 프로세스와 수신 프로세스 간의 reliable transport(신뢰할 수 있는 전송)
  • TCP protocol을 사용한다면 Data Integrity가 보장된다.
• Flow Control(흐름 제어)
  • sender won't overwhelm receiver(송신 측이 수신 측의 가용량을 압도하지 않도록 조절)
  • 호스트(Network Edge)와 호스트(Network Edge) 간, 송신 측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법이다. 즉, 수신 측에서 수신된 데이터를 처리해서 윗 계층으로 서비스하는 속도보다 송신 측에서 보내는 데이터 속도가 더 빠르다면 수신 측에서 제한된 저장용량(보통 큐)을 초과하여 이후에 도착하는 데이터의 손실을 가져올 수 있다. 이를 제어한다.
• Congestion Control(혼잡제어)
  • throttle sender when network overloaded(네트워크에 과부하가 발생했을 때 송신자를 통제한다.)
  • 호스트(Network Edge)와 네트워크(Network Core) 상의 데이터 처리를 효율적으로 하기 위한, 즉, 송신 측의 데이터 전달과 네트워크의 처리 속도 차이를 해결하기 위한 기법이다.
• Connection-oriented: setup required between client and server processes(클라이언트와 서버 프로세스 간의 연결 설정 과정을 필요로 한다.)
• does not provide(제공되지 않는 것)
  • timing
  • minimum throughput guarantee
  • security

UDP service

• unreliable data transfer
  • data integrity를 보장하지 않음
• does not provide(제공되지 않는 것)
  • 거의 모든 것.. UDP는 마치 하얀 도화지다.
  • reliability
  • Flow control
  • Congestion control
  • Timing
  • Throughput guarantee
  • security
  • connection setup

Q: UDP는 이렇게 거의 아무것도 제공하지 않는데, 왜 사용할까?(HTTP/3는 UDP를 사용한다.)

A: 구현의 자유 때문이다. UDP를 사용하며 제공되지 않는 위 요소들이 필요하면 구현한다. 실제로 TCP에 의존할 필요가 없는 앱들(TCP가 제공하는 복잡한 기능들이 필요가 없는)은 UDP를 사용할 수 있다. Performance Issue도 UDP를 사용하는데 한 몫을 한다.

 

Security에 관해

Vanilla TCP & UDP socket은

• no encryption(암호화되지 않는다.)
  • Cleartext passwords sent into socket traverse internet in cleartext(암호화되지 않은 비밀번호를 소켓으로 전송하면 보안에 치명적이다.)

Transport Layer Security (TLS)

• 암호화된 TCP 연결을 제공한다.
• Data integrity(데이터 무결성)
• end-point authentication
• TLS는 응용 계층에서 구현된다.
  • 앱들은 TLS library를 사용한다.
  • TLS socket에 cleartext를 보내면 암호화되어 인터넷을 경유한다.

 

Reference

https://jsonsang2.tistory.com/17