[CS공부] 네트워크 구조(2)-OSI 7계층 구조 1) 응용계층(Application Layer)

Min Kim·2023년 2월 10일

CS 공부

목록 보기

3/15

들어가기 전에

OSI 7계층에 대해 알아봅시다.
OSI 7계층은 네트워크 통신이 일어나는 과정을 7단계로 나눈 것을 말합니다.

이렇게 계층을 나누면 통신이 일어나는 과정을 단계별로 파악하기 쉽기 때문입니다.
그래서 7단계 중 특정한 단계에 이상이 있다면 다른 단계의 장비나 소프트웨어를 건드리지 않고 이상이 생긴 단계의 문제를 해결할 수 있습니다!

그 중 최상위 계층인 어플리케이션 계층부터 알아보겠습니다.

1. Application Layer

애플리케이션 계층은 컴퓨터 네트워크의 존재 이유입니다.
인터넷 도입 이래로 많은 독창적이고 훌륭한 어플레이케이션 들이 개발되었고 ( 인터넷 익스플로어, 크롬 등 ) 이러한 것들이 인터넷의 성공을 뒷바침하는 원동력입니다.
endSystem 에서만 존재합니다.
사용자에게 보이는 유일한 계층이고 사용자를 위한 인터페이스를 제공합니다.

😜 추가 지식
endSystem : 종단 시스템. 흔히 호스트라고 합니다. ex)PC,프린터,핸드폰 등등등

2. 애플리케이션 구조

애플리케이션 구조는 애플리케이션 개발자에 의해 설계되고 애플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 지시합니다.
크게 두가지로 분류되는데

클라이언트-서버 구조
P2P 구조

로 나뉩니다.

1) 클라이언트-서버 구조

클라이언트-서버 구조에서 항상 켜져 있는 호스트를 서버라고 합니다.
이 서비스(서버)는 클라이언트라는 다른 많의 호스트의 요청을 받습니다.
클라이언트 호스트는 가끔 혹은 항상 켜져 있을 수 있습니다.
대표적인 예는 클라이언트 호스트에서 실행되는 브라우저가, 항상 켜진 웹 서버로 서비스를 요청하는 웹 애플리케이션입니다. 웹 서버가 클라이언트 호스트로부터 객체를 요청받으면 웹 서버는 클라이언트 호스트로 요청된 객체를 보내어 응답합니다.

😜 추가 지식
이 때 클라이언트-서버 구조에서 클라이언트는 서로 직접적으로 통신하지 않으며, 서버는 고정 IP 주소를 갖는 것이 특징이다.

이러한 구조를 가진 애플리케이션의 예는 [웹, 파일 전송, 원격 로그인, 전자메일]입니다.

😜 추가 지식

그런데, 하나의 서버에서 너무 많은 클라이언트 요청에 응답하는 게 부담스럽거나 불가능할 때가 있습니다. 이런 경우를 대비하여 많은 수의 호스트를 갖춘 데이터 센터가 가상의 서버를 생성하여 응답 처리를 하는 것을 도와줍니다. 데이터 센터를 사용하는 예로는 [구글, 아마존, 지메일, 페이스북] 등이 있습니다.

2) P2P(peer-to-peer) 구조

P2P 구조에서는 항상 켜져 있는 기반구조 서버에 최소로 의존하거나 전혀 의존하지 않습니다. 대신 애플리케이션은 피어(peer)라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하도록 합니다. 피어는 사용자들이 제어하는 데스크톱과 랩톱입니다. P2P 구조에 기반을 둔 애플리케이션 예로는 [쉰레이(다운로드 가속기), 비트토렌트, 스카이프] 등이 있습니다.
P2P구조는 자가 확장성이라는 특성을 가지고 있습니다. 예를 들어, P2P 파일 공유 애플리케이션에서 각 피어들이 파일을 요구함으로써 작업 부하를 만들어 내지만, 각 피어들은 파일을 다른 피어들에게 분배함으로써 시스템에 서비스 능력을 추가합니다.
또한, P2P구조는 비용이 효율적이라는 특성을 가지고 있습니다. 데이터 센터의 클라이언트-서버 설계와는 대조적으로 P2P 구조는 서버 기반구조와 서버 대역폭을 요구하지 않기 때문에 비용이 효율적입니다.

😜 추가 지식
P2P 구조는 고도의 분산 구조 특성으로 인해 보안, 성능, 신뢰성이 좋지 않은 평가를 받고 있기도 합니다.

구조	특징
클라이언트 - 서버	- 클라이언트는 서로 직접적으로 통신하지 않는다. - 서버는 고정 IP 주소라는 잘 알려진 주소를 갖는다. - 서버는 항상 동작하므로 클라이언트는 서버 주소로 패킷을 보내서 항상 서버에 연결할 수 있다. - 서버가 부족할 경우 많은 수의 호스트를 갖춘 데이터 센터(data center)를 운영한다. - 구글, 빙, 아마존 등 - 웹, 파일 전송, 원격 로그인, 전자메일 등이 있다.
P2P	- 항상 켜져 있는 서버에 최소로 의존하거나 아예 의존하지 않는다. - 애플리케이션은 피어(peer)라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하도록 한다. - 클라이언트-서버와 P2P 요소들을 결합한 하이브리드 구조를 가질 수도 있다. - 자가 확장성(self-scalability)을 가지고 있어, 부하의 분배가 가능하다. - 토렌트, 스카이프 등이 있다.

구조

특징

클라이언트 - 서버

- 클라이언트는 서로 직접적으로 통신하지 않는다.
- 서버는 고정 IP 주소라는 잘 알려진 주소를 갖는다.
- 서버는 항상 동작하므로 클라이언트는 서버 주소로 패킷을 보내서 항상 서버에 연결할 수 있다.
- 서버가 부족할 경우 많은 수의 호스트를 갖춘 데이터 센터(data center)를 운영한다. - 구글, 빙, 아마존 등
- 웹, 파일 전송, 원격 로그인, 전자메일 등이 있다.

P2P

- 항상 켜져 있는 서버에 최소로 의존하거나 아예 의존하지 않는다.
- 애플리케이션은 피어(peer)라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하도록 한다.
- 클라이언트-서버와 P2P 요소들을 결합한 하이브리드 구조를 가질 수도 있다.
- 자가 확장성(self-scalability)을 가지고 있어, 부하의 분배가 가능하다.
- 토렌트, 스카이프 등이 있다.

3. 소켓

대부분의 애플리케이션은 두 프로세스가 메시지를 서로에게 보내는 통신 프로세스 쌍으로 구성됩니다. 하나의 프로세스로부터 다른 프로세스로 보내는 메시지는 네트워크를 통해 움직입니다. 프로세스는 소켓(socket)을 통해 네트워크로 메시지를 보내고 받습니다.

위 이미지는 인터넷에서 통신하는 두 프로세스 사이의 소켓 통신을 보여줍니다.
프로세스가 사용하는 하위 전송 프로토콜이 인터넷의 TCP 프로토콜이라고 가정합시다.
소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스입니다.
또한 소켓은 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API(Application Programming Interface)라고도 합니다.

애플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 갖지만 소켓의 트랜스포트 계층에 대한 통제권은 거의 갖지 못합니다.

트랜스포트 계층에 대한 애플리케이션 개발자의 통제는 아래와 같습니다.

트랜스포트 프로토콜의 선택
최대 버퍼와 최대 세그먼트와 같은 약간의 트랜스포트 계층 매개변수의 설정

애플리케이션 개발자가 트랜스포트 프로토콜을 선택하면, 애플리케이션은 프로토콜이 제공하는 전송 서비스를 사용하여 구성됩니다.

😜 추가 지식
소켓이 프로세스 사이의 인터페이스라는 건 소켓으로 정보를 주고 받는다는 뜻입니다.

🎁소켓에 대한 깊은 내용은 여기에 따로 정리했습니다.

4.프로토콜 종류

1) 사용자가 사용하는 프로토콜

프로토콜	동작 방식
HTTP	웹 클라이언트와 웹 서버 사이에서 웹 페이지 데이터를 주고 받는다.
POP, SMTP, IMAP	메일을 송수신하고 보관한다.
SMP,AFP	LAN 안에서 파일을 공유한다.

2) 사용자가 간접적으로 사용하는 프로토콜

프로토콜	동작 방식
DNS	도메인명과 IP어드레스의 정보를 서로 변환할떄 사용한다.
DHCP	LAN 내의 컴퓨터에게 IP 어드레스를 할당할 때 사용한다
SSL/TLS	통신 데이터를 암호화하여 주요 정보를 안전하게 주고받을 때 사용한다

3) FTP

파일 전송 프로토콜
인터넷을 통해 컴퓨터와 서버 간에 파일을 전송하기 위한 간단한 통신 프로토콜입니다.
두개의 포트 번호가 있는데 21번은 클라이언트와 서버 사이의 명령, 제어 등을 송수신하는 제어 포트이고 20번은 클라이언트와 서버 사이의 직접적인 파일 송 수신을 담당하는 데이터 포트입니다.
연결 방식으로는 passive 모드, active 모드, SFTP 연결 모드가 있습니다.

😜 추가 지식

active 모드 (서버가 클라이언트에게 요청, 방화벽 등으로 막힐 시 사용)

FTP 클라이언트에서 FTP 서버의 21번 포트에 접근 인증을 요청한다.
-> FTP 클라이언트 자신의 Data 전송 포트 번호 57775를 서버에게 전송한다.

FTP 서버에서는 FTP 클라이언트에게 "OK" 응답을 보낸다.

FTP 서버에서 생성한 20번 포트에서 FTP 클라이언트의 57775 포트로 데이터 채널 연결을 요청한다.
( Active Mode에서 Data Port는 Command Port + 1 이다 )

FTP 클라이언트는 FTP 서버에게 "OK" 응답을 보내고 데이터 채널 연결이 완료된다.

passive 모드 (클라이언트가 서버에게 요청)

FTP 클라이언트에서 FTP 서버의 21 포트로 접근 인증을 요청한다.
-> 이 때 Passive Mode를 사용할 것이라는 것도 알린다.

FTP 서버는 FTP 클라이언트에게 "OK"라는 응답을 보내면서
데이터 채널 포트번호 59175를 클라이언트에게 알려준다.

FTP 클라이언트에서 생성한 52757번 포트에서 서버의 59175포트로 데이터 채널 연결을 요청한다.

FTP 서버는 FTP 클라이언트에게 "OK"라는 응답을 보내고 채널 연결을 진행한다.

SFTP 연결

일반 FTP연결에서 보안성을 강화한 것으로 서버와 클라이언트 간의 데이터 전송 시 계정 정보 등을 암호화하여 해킹이나 보안 상의 문제를 사전에 방지할 수 있다.

4) SMTP

전자 메일 전송을 위한 표준 프로토콜 (Simple Mail Transfer Protocol)
이메일을 송수신하는 서버를 SMTP 서버라고 합니다.
SMTP 서버에는 다음과 같은 프로그램들이 실행됩니다.
- 메일 제출 에이전트(MSA): MSA는 이메일 클라이언트로부터 이메일을 수신합니다.
- 메일 전송 에이전트(MTA): MTA는 전달망의 다음 서버로 이메일을 전송합니다.
- 메일 전달 에이전트(MDA): MDA는 MTA에서 이메일을 수신해서 수신자의 받은메일함에 보관합니다.
SMTP에서 사용되는 포트는 다음과 같습니다.
- 포트 25 : 가장 기본 포트. 그래서 스팸 발송자가 많이 애용하는 포트이기에 차단될 때가 많습니다.
- 포트 465 : 보안 소켓 계층(SSL) 암호화로 잘 사용되었지만 TLS가 나오면서 이전 시스템에서만 나타납니다.
- 포트 587 : 이메일 제출용 기본 포트. 이 포트를 통과하는 SMTP 통신은 TLS 암호화를 이용합니다.
- 포트 2525 : SMTP와 공식적으로 연결되어 있지는 않지만, 일부 이메일 서비스에서는 앞서 언급한 포트가 차단되었을 경우 이 포트로 SMTP 전송이 제공됩니다.
동작 원리 (메일을 주고 받을 때)
😜 추가 지식
- 예시
  내 메일 : abc@naver.com
  상대방 메일 : def@daum.net
상대방에게 메일을 보낸다고 가정해봅시다.
naver 메일 서버와 daum 메일 서버가 각각 존재합니다.
저는 naver 의 메일서버에 보낼데이터를 전송합니다. (SMTP)

naver 메일 서버는 daum 메일 서버에게 메일을 보냅니다. (SMTP)
그러면 그 메일 정보는 daum 메일 서버 보관함에 저장되고,
상대방은 daum 메일 서버 보관함에서 메일을 가져오게 됩니다. (SMTP가 아님)
- 왜 메일을 가져올 때는 SMTP를 이용하지 않을까?
  SMTP는 심플하기 때문에 Mail Box (Po box) 까지만 갈 수 있습니다.
  수신자는 태블릿, 컴퓨터, 휴대폰 등등에서 모두 메일을 확인할 수 있기 때문에,
  SMTP는 메일 서버 보관함까지만 작용하고, 수신자는 위 3가지 옵션을 통해 직접적으로 메일을 가져오게 됩니다.

5) POP3

받는 메일이라고 불리는 POP 서버(version3) 이메일을 받아오는 표준 프로토콜
TCP포트번호는 110번입니다.
POP3는 메일을 서버에서 다운로드를 받는 프로토콜입니다.
pop3는 서버에서 메일을 받아오는 즉시 삭제되는 것이 디폴트이지만 서버저장 설정은 가능합니다.
스토리지 용량에 제한있는 경우 유리합니다.

6) IMAP

인터넷 메시지 액세스 프로토콜 (Internet Message Access protocol)
메일 서버 또는 서비스에서 전자메일 혹은 메시지를 읽어오는 클라이언트/서버 프로토콜입니다.
TCP포트번호는 143번입니다.
POP와는 달리 중앙 서버에서 동기화가 이뤄지기 때문에 모든 장치에서 동일한 이메일 폴더를 확인할 수 있습니다.

차이점 정리

POP3	IMAP
- 메일 서버에서 로컬장치로 이메일을 다운로드 받음. - 수신함 즉, 받은 메일만을 다운로드 하여 조회 가능. - 로컬장치로 다운로드 시, 서버에서는 이메일 삭제 -오프라인 지원	- 메일 서버에서 동기화가 이루어짐. - 수신함 뿐만 아니라 모든 메일함을 조회 가능. - 서버에 이메일 실시간 존재. -온/오프 모두 지원

5. HTTP

웹의 애플리케이션 계층 프로토콜인 HTTP(HyperText Transfer Protocol)는 웹의 중심입니다.
웹 페이지(web page, 문서라고도 한다)는 객체들로 구성됩니다.
객체(object)는 단순히 URL로 지정할 수 있는 하나의 파일(HTML 파일, JPEG 이미지, GIF 이미지, 자바 애플릿, 오디오 클립)등 입니다.
대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성됩니다.
예시) 웹페이지가 HTML 텍스트와 5개의 JPEG 이미지로 구성되어 있으면, 이 웹 페이지는 6개의 객체를 갖고 있는 것입니다(기본 HTML 파일과 5개의 이미지).)
기본 HTML 파일은 페이지 내부의 다른 객체를 그 객체의 URL로 참조합니다.
각 URL은 2개의 요소, 즉 객체를 갖고 있는 서버의 호스트 네임과 객체의 경로 이름을 갖고 있습니다.

예시)

http://www.naver.com/test/picture.gif

www.naver.com은 호스트 네임이고, /test/picture.gif는 경로 이름입니다. 브라우저는 요구한 웹 페이지를 보여 주고 여러 가지 인터넷 구성 특성을 제공합니다. HTTP의 서버 측을 구현하는 웹 서버(Web server)는 URL로 각각을 지정할 수 있는 웹 객체를 갖고 있습니다.

🎁HTTP에 대한 깊은 내용은 여기에 따로 정리했습니다.

지속연결과 비지속연결

1) 비지속 연결

페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되고, 이 11개의 객체가 같은 서버에 있다고 가정해 봅시다. 기본 HTML 파일의 URL은 다음과 같습니다.

http://www.someschool.edu/someDepartment/home.index

연결 수행 과정은 다음과 같습니다.

HTTP 클라이언트는 HTTP의 기본 포트 번호 80을 통해 www.someschool.edu 서버로 TCP 연결을 시도한다. TCP 연결과 관련하여 클라이언트와 서버에 각각 소켓이 있게 된다.
HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 이 요청 메시지는 /someDepartment/home.index 경로 이름을 포함한다.
HTTP 서버는 1단계에서 설정된 연결 소켓을 통하여 요청 메시지를 받는다. 저장장치로부터 /someDepartment/home.index 객체를 추출한다. HTTP 응답 메시지에 그 객체를 캡슐화한다. 그리고 응답 메시지를 소켓을 통해 클라이언트로 보낸다.
HTTP 서버는 TCP에게 연결을 끊으라고 한다.(그러나 실제로 TCP 클라이언트가 응답 메시지를 올바로 받을 때까지 연결을 끊지 않는다.)
HTTP 클라이언트가 응답 메시지를 받으면, TCP 연결이 중단된다. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다. 클라이언트는 응답 메시지로부터 파일을 추출하고 HTML 파일을 조사하고 10개의 JPEG 객체에 대한 참조를 찾는다.
그 이후에 참조되는 각 JPEG 객체에 대하여 처음 네 단계를 반복한다.

😜 추가 지식
RTT는 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 데 걸리는 시간을 뜻합니다. 패킷 전파 지연, 중간 라우터와 스위치에서의 패킷 큐잉 지연, 패킷 처리 지연 등을 포함합니다.

위 하이퍼 링크를 클릭하면 다음 그림과 같이 연결이 됩니다.

이 클릭은 브라우저가 웹 서버 사이에서 TCP 연결을 시도하게 됩니다. 이는 "3-Way Handshake"를 포함합니다.

😜 추가 지식

3-Way Handshake는

Client > Server : TCP SYN
Server > Client : TCP SYN ACK
Client > Server : TCP ACK

의 과정을 이루는 TCP 통신방법이다.

1) 지속 연결

비지속 연결은 몇 가지 단점이 있습니다.

첫째, 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 합니다.

TCP 버퍼가 할당되어야 하고 TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 합니다.
이는 수많은 다른 클라이언트의 요청을 동시에 서비스하는 웹 서버에게 심각한 부담을 줄 수 있습니다.

둘째, 앞서 언급한 대로 각 객체는 2 RTT를 필요로 했습니다.

TCP 연결 설정에 1 RTT
객체를 요청하고 받는데 1 RTT

HTTP1.1 지속 연결에서 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지합니다.

같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내집니다.
특히, 전체 웹 페이지(앞 예에서 기본 HTML 파일과 10개 이미지)를 하나의 지속 TCP 연결을 통해 보낼 수 있습니다.
또한 같은 서버에 있는 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 보낼 수 있습니다.
이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있습니다.(파이프라이닝)

6. DNS

DNS 서버 계층구조의 일부

호스트 네임에 해당하는 IP 주소를 저장해놓은 것을 DNS라 합니다.
사람이 읽을 수 있는 도메인 이름을 머신이 읽을 수 있는 주소로 변환합니다.
하나의 서버에 저장하면 검색 시간이 오래 걸리고, 서버가 다운되면 웹 브라우징 전체가 무너지기 때문에 분산화, 계층화 구조로 이루어집니다.

위 이미지를 보면 세 유형의 DNS 서버로 구성되는데 그 세가지는 아래와 같습니다.

루트(root) DNS 서버
최상위 레벨 도메인(TLD, top-level domain) DNS 서버
책임(authoritative) DNS 서버

위 세분류의 상호작용을 어떤 DNS 클라이언트가 호스트 네임 www.amazon.com의 IP 주소를 얻기 원한다는 예시로 확인해 보겠습니다.

먼저 이 클라이언트는 루트 서버 중 하나에 접속합니다.
루트 서버는 최상위 레벨 도메인 com을 갖는 TLD 서버 IP 주소를 보냅니다.
그다음 클라이언트는 이 TLD 서버 중 하나에 접속하고, 서버는 도메인 amazon.com을 가진 책임 서버의 IP 주소를 보냅니다.
클라이언트는 amazon.com의 책임 서버 중에서 하나로 접속합니다.
서버는 호스트 네임 www.amazon.com의 IP주소를 보냅니다.

😜 추가 지식
간단히 말하자면 최상위부터 해서 재귀적으로 순환하며 찾을 때 까지 반복한다는 말입니다.

다양한 DNS 서버들의 상호작용
위 그림을 한번 살펴봅시다.

1. cse.nyu.edu가 먼저 자신의 로컬 DNS 서버 dns.nyu.edu에게 DNS 질의 메시지를 보냅니다.
2. 질의에는 변환되어야 하는 호스트 네임, 즉 gaia.cs.umass.edu가 포함됩니다.
3. 로컬 DNS 서버는 edu를 인식하고, edu에 대한 책임을 가진 TLD 서버의 IP 주소 리스트를 로컬 DNS 서버에게 보냅니다.
4. 로컬 DNS 서버는 질의 메시지를 TLD 서버로 보냅니다.
5. 그다음 TLD 서버는 umass.edu를 인식하고 dns.umass.edu로 이름 지어진 책임 DNS 서버의 IP 주소를 응답합니다.
6. 마지막으로 로컬 DNS 서버는 직접 dns.umass.edu로 질의 메시지를 다시 보내고, gaia.cs.umass.edu의 IP 주소로 응답합니다.

이 예에서 하나의 호스트 네임 매핑을 얻기 위해 질의 메시지 네 번과 응답 메시지 네 번, 총 8번 DNS 메시지가 보내졌음에 주목해야 합니다.

DNS 캐싱

DNS는 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱을 사용합니다.
DNS 캐싱은 DNS 네임서버가 한번 요청된 DNS 질의를, TTL 만큼 메모리에 저장하여 뒀다가, 똑같은 질의에 대해 신속히 처리할 수 있도록 하는 기능입니다.
호스트 DNS와 IP주소 사이의 매핑과 호스트는 영구적인 것이 아니기 때문에 DNS 서버는 어떤 기간(흔히 2일로 설정) 이후에 저장된 정보를 제거합니다.

예시)

호스트 apricot.nyu.edu가 cnn.com에 대한 IP 주소를 dns.nyu.edu에게 질의한다고 생각해 봅시다.

또한 몇 시간 후에 NYU의 다른 호스트 kiwi.nyu.edu가 dns.nyu.edu에게 같은 호스트 네임을 질의한다고 가정해 봅시다.

캐싱으로 인해 로컬 DNS 서버는 두 번째로 질의한 호스트에게 다른 DNS 서버로의 질의 없이 즉시 cnn.com의 IP 주소를 보낼 수 있습니다. 로컬 DNS 서버는 또한 TLD 서버의 IP 주소를 저장할 수 있습니다. 그러므로 로컬 DNS 서버가 질의 사슬에서 루트 DNS 서버를 우회하도록 합니다.