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

애플리케이션 계층 프로토콜은 네트워크 프로그램이 메시지를 교환하는 방식, 즉 메시지 형식, 요청 및 응답의 순서, 각 필드의 의미를 정의하여 원시 전송 연결을 웹 및 이메일과 같은 유용한 서비스로 전환합니다.

Definition

애플리케이션 계층 프로토콜은 TCP 또는 UDP와 같은 전송 계층 서비스 위에 구축되어 서로 다른 호스트의 애플리케이션 프로세스가 통신하는 메시지 형식, 교환 패턴 및 의미론을 정의하는 규칙 집합입니다.

Scope

이 주제는 전송 서비스를 기반으로 구축된 애플리케이션 프로토콜의 설계 및 작동을 다룹니다. 애플리케이션 아키텍처(클라이언트-서버 및 P2P), 프로토콜에 공통적인 요소(메시지 유형, 구문, 의미론 및 규칙), 그리고 대표적인 예시인 웹용 HTTP, 이메일용 SMTP 및 IMAP, 파일 전송을 포함합니다. 또한 프로토콜이 TCP 또는 UDP를 사용하는 방식, 영구적 연결과 비영구적 연결, 요청-응답 패턴을 다룹니다. 별도의 주제에서 다루는 명명 및 콘텐츠 전송 인프라와 하위 전송 메커니즘은 제외합니다.

Core questions

• 모든 애플리케이션 계층 프로토콜을 정의하는 공통 요소는 무엇입니까?
• 클라이언트-서버 및 P2P 애플리케이션 아키텍처는 어떻게 다릅니까?
• HTTP는 웹을 위한 요청과 응답을 어떻게 구성합니까?
• SMTP 및 IMAP과 같은 이메일 프로토콜은 메일을 어떻게 이동하고 액세스합니까?
• 애플리케이션 프로토콜은 TCP 및 UDP와 같은 전송 서비스를 어떻게 선택하고 사용합니까?

Key concepts

• 클라이언트-서버 및 P2P 아키텍처
• 메시지 형식, 구문 및 의미론
• HTTP 요청 및 응답
• HTTP 메서드 및 상태 코드
• 영구적 연결 대 비영구적 연결
• SMTP 및 이메일 전송
• IMAP 및 메일 액세스
• 애플리케이션의 TCP 및 UDP 사용

Key theories

TCP를 통한 요청-응답 프로토콜

많은 애플리케이션 프로토콜은 신뢰할 수 있는 TCP 연결을 통해 요청-응답 패턴을 따릅니다. 클라이언트가 구조화된 요청을 보내면 서버가 응답을 반환하며, HTTP에서 예시된 바와 같이 메서드, 상태 코드 및 헤더에 대한 규칙이 있습니다.

애플리케이션 아키텍처

애플리케이션은 클라이언트가 항상 켜져 있는 서버에 접속하는 클라이언트-서버 방식 또는 호스트가 서비스를 요청하고 제공하는 P2P 방식으로 구성됩니다. 이러한 선택은 확장성, 관리 및 프로토콜 설계 방식에 영향을 미칩니다.

저장-전달 메시징

이메일은 다중 프로토콜 서비스를 보여줍니다. SMTP는 저장-전달 방식으로 서버 간에 메일을 푸시하는 반면, 검색 프로토콜은 사용자가 사서함에 액세스하도록 하여 메시지 전송과 메시지 액세스를 분리합니다.

Clinical relevance

애플리케이션 계층 프로토콜은 소프트웨어와 네트워크 간의 직접적인 인터페이스입니다. HTTP는 웹과 대부분의 최신 애플리케이션 프로그래밍 인터페이스의 기반이며, 이메일 프로토콜은 전 세계적인 메시징을 전달하고, 요청-응답 및 아키텍처 패턴은 수많은 서비스에서 반복적으로 나타납니다. 이러한 프로토콜을 이해하는 것은 네트워크 애플리케이션 구축, API 설계, 느린 페이지 로드부터 메일 전송 실패에 이르는 문제 해결에 필수적입니다.

History

초기 인터넷 애플리케이션은 이메일(SMTP 사용)과 파일 전송이었습니다. 팀 버너스 리가 1990년경에 만든 웹은 HTTP를 도입했으며, 이는 단순한 문서 검색 프로토콜에서 현대 웹 애플리케이션 및 API의 기반으로 성장했습니다. HTTP/1.1, HTTP/2, HTTP/3은 성능을 향상시켰고, RFC 9110 (2022)에서 의미론이 통합되었습니다.

Key figures

• Tim Berners-Lee
• Roy Fielding
• Jon Postel
• John Klensin

Seminal works

• rfc9110
• rfc5321
• kurose2021

Frequently asked questions

애플리케이션 계층 프로토콜은 실제로 무엇을 지정합니까?

교환되는 메시지 유형(예: 요청 및 응답), 해당 메시지의 정확한 구문(필드 및 인코딩 방식), 각 필드의 의미, 그리고 메시지가 언제 어떻게 전송되는지에 대한 규칙을 지정합니다. 예를 들어 HTTP는 메서드, 헤더, 상태 코드 및 요청-응답 흐름을 정의합니다.

웹은 왜 UDP 대신 TCP를 사용합니까?

웹 페이지와 API는 일반적으로 잠재적으로 큰 응답의 신뢰할 수 있고 순서 있는 전달이 필요하며, TCP는 이를 제공하고 네트워크 공유를 위한 혼잡 제어도 제공합니다. HTTP는 이러한 이유로 전통적으로 TCP 위에서 실행되지만, HTTP/3은 UDP 위에 구축되었지만 자체적으로 신뢰성과 혼잡 제어를 다시 도입한 QUIC 위에서 실행됩니다.