[네트워크] 컴퓨터 네트워크(2) - 애플리케이션 계층 Application Layer

<애플리케이션의 구조>

클라이언트-서버 구조

클라이언트-서버 구조

애플리케이션 계층은 클라이언트 - 서버의 구조를 갖는다.

클라이언트는 요청하고, 서버는 응답한다.

 

서버:

• 24시간 켜져 있음.
• 영구적인 IP 주소
• 확장을 위한 데이터 센터가 있음

클라이언트:

• 서버와 통신
• 항상 켜져있지 않고, 간헐적으로 통신
• 동적인 IP 주소
• 클라이언트와 클라이언트가 직접적으로 통신하지 않는다. (이것은 P2P)

P2P 구조

P2P 구조

서버가 항상 켜져있을 필요는 없다.

임의의 엔드 시스템(peer)끼리 직접 통신한다.

중앙 서버가 없기 때문에 확장이 더 쉽다. 중앙 서버의 장애가 전체 시스템에 영향을 끼치지 않는다.

반대로 중앙 집중 관리를 하지 않기에, 보안 문제가 발생하기 쉽다.

 

<애플리케이션 계층의 통신 방식>

통신 방식

프로세스 간의 통신은 Socket을 통해 이루어진다.

프로세스: 하나의 호스트 내에서 실행 중인 프로그램

 

하나의 호스트 내에서, 프로세스 간에 통신하는 것을 Inter Process Communication, IPC라고 한다.

다른 호스트 간에, 통신을 하는 것은 message를 주고 받음으로써 이루어진다.

이때 OS가 제공하는 인터페이스인 Socket을 통해 통신한다.

 

하나의 기기는 여러 개의 소켓을 가질 수 있다.

하나의 소켓은 여러 개의 프로세스를 가질 수 있다.

 

기기 간의 통신은 반드시 소켓에서 일어난다. 이 연결은 유일하다.

따라서 대략적인 통신 과정은 다음과 같다.

[출발 프로세스a ---> 출발 소켓A] ===> [목적지 소켓B ---> 목적지 프로세스b]

 

출발 소켓이 목적지 소켓을 찾기 위해서는 Socket 인터페이스 주소 == IP 주소가 필요하다.

목적지 소켓 내에서 목적지 프로세스를 찾기 위해서는 포트 번호가 필요하다.

 

어떤 기기든, 웹 서버 프로세스의 포트 번호는 80번이다.

 

애플리케이션 계층의 요구사항

애플리케이션 별 요구사항

 

애플리케이션은 데이터 무결성, 빠른 응답 속도, 많은 처리량, 보안성을 요구한다.

그러나 이 모든 것을 맞춰줄 수는 없다.

 

예컨대 e-mail 앱은 데이터 무결성이 중요하다. 그러나 반드시 응답 속도가 빠를 필요는 없다.

반면 실시간 영상은 데이터가 몇 프레임 정도 손상되어도 크게 지장 없다. 하지만 응답 속도는 가능한 한 빨라야 한다.

 

TCP / UDP

기능	TCP	UDP
연결 형태	연결형 서비스. 송신자와 수신자 간에 연결 설정 후 통신	비연결형 서비스. 연결 설정 없이 데이터 그램을 직접 전송
reliable	높음. 중복 제거, 오류 검출 및 재전송 메커니즘 제공	낮음. 중복 제거 없음, 오류 검출 및 재전송 없음
in-order	데이터의 순서가 보장됨. 송신된 순서대로 데이터가 도착.	데이터의 순서가 보장되지 않음.
flow-control	있음. 네트워크 혼잡 시 데이터 전송 속도 조절	없음. 어떠한 흐름 제어도 적용되지 않음
congestion-control	있음. 네트워크의 혼잡 상태를 감지하고 데이터 전송량을 조절	없음. 네트워크 혼잡에 대응하지 않음
속도	UDP보다 느림. 연결 설정, 오류 검사 및 제어 메커니즘 때문	TCP보다 빠름. 최소한의 오버헤드만을 가짐
사용 사례	신뢰성 있는 데이터 전송이 필요한 경우 (웹 페이지 로딩, 이메일, 파일 전송 등)	실시간 통신이 필요한 경우 (스트리밍, 온라인 게임, VoIP 등)
헤더 크기	20바이트 기본. 옵션에 따라 더 길어질 수 있음	8바이트. 고정된 크기로 매우 경량
오류 검사	헤더와 데이터 모두에 대한 체크섬을 통한 오류 검사 및 수정 가능	헤더와 데이터에 대한 체크섬을 통해 오류 검사만 제공. 오류 수정은 제공하지 않음

 

TCP / UDP는 Transport 계층 프로토콜이 제공하는 서비스이다.

현재는 애플리케이션 계층에 대해 배우고 있지만, 후술한 HTTP에 대해서 설명하기 위해 간단하게 짚고 넘어가자.

 

TCP는 reliable, in-order, flow-control, congestion-control의 특징을 갖고 있다. 기능이 많은 대신 무겁고 느리다.

UDP는 그런 거 없다. 대신 가볍고 빠르다.

애플리케이션 별 사용하는 프로토콜

 

상술했듯이 애플리케이션마다 요구 사항이 다르다.

따라서 사용하는 전송 계층의 프로토콜도 다르다.

 

Web

사용자가 보는 웹 페이지는 object로 구성되어 있다.

object는 HTML 파일, JPEG 이미지, Audio 파일 등이 될 수 있다.

 

개발자가 보는 웹 페이지는 base HTML-file로 되어있다.

HTML은 referenced objects(객체의 주소)를 포함하고 있다.

따라서 주소(URL)를 통해 객체를 연결하고, 연결된 객체를 가져와서 보여주는 것이다.

 

HTTP

HTTP의 구조

HTTP의 통신 과정

Hyper Text Transfet Protocol.

이 프로토콜은 클라이언트의 request와 서버의 response로 이루어진다.

 

HTTP는 TCP를 기반으로 동작한다.

데이터의 reliability를 보장할 수 있지만, UDP에 비해 비싼 비용을 내야한다.

 

TCP로 통신을 하기 위해서는, 최초 request 메시지 이전에 TCP Connection이 이루어져야 한다.

이때 request & response 이후 Connection의 연결 지속 여부에 따라, Persistent와 Non-Persistent로 나뉜다.

 

HTTP는 Stateless한 특징을 갖는다.

request & response 이후에, 클라이언트와 서버는 서로에 대한 어떤 정보도 기억하지 않는다.

 

 HTTP 통신 소요 시간

HTTP 통신에 소요되는 시간

 

RTT는 Round Trip Time의 약자로, request & response가 한번 이루어지는 시간을 뜻한다.

1. TCP 통신을 위해서는 최초 TCP Connection 과정이 필요하다. (1 RTT)

2. request & response가 이루어진다. (1 RTT)

2-1. 데이터를 전송하는 시간이 소요된다. (transmission time)

 

Non-persistent의 경우, 데이터 전송 시마다 2 RTT + transmission time이 소요된다.

Persistent의 경우, 데이터 전송 시마다 1 RTT + transmission time이 소요된다.

 

HTTP 메시지의 구조

1. request / 2. response

HTTP request / response 메시지의 구조는 위와 같다.

위는 데이터를 제외한 헤더에 대한 내용이다.

 

response message에서 status line을 주목할 만하다.

응답의 상태를 나타낸다.

 

쿠키

서버가 만든 쿠키~ 클라이언트 위해 구웠지~

 

1. 웹 브라우저가 아마존에 접속하려고 함

2. http request를 생성하기 전에, 클라이언트의 로컬 디스크에서 아마존에 대한 쿠키가 있는지 살펴봄

3. 없으면 평범한 request를 생성해서 요청. 있으면 해당 정보를 포함해서 요청.

4. 아마존은 데이터베이스에서 클라이언트의 쿠키 정보를 확인함. 없으면 새로 생성해서 set-cookie: 일련번호 형태로 전송. 있으면 해당 상태에 적절한 응답.

5. 클라이언트는 이것을 로컬에 저장

6. 2~4의 과정을 반복

 

쿠키는 HTTP의 stateless 특징이 갖는 약점을 보완한다.

 

캐시 (proxy server)

프록시 서버의 구조

프록시 서버는 클라이언트와 원천 서버 사이에 위치하는 또다른 서버이다.

클라이언트의 요청을 대신하여 원천 서버의 리소스에 접근한다.

 

1. 캐싱

• 프록시 서버는 자주 요청되는 웹 페이지나 파일을 로컬에 저장(캐싱)한다.
• 이후 같은 요청이 들어올 경우, 프록시 서버는 인터넷에 다시 접속하지 않고 캐시된 데이터를 제공함으로써 응답 속도를 향상.

2. 보안

• 프록시 서버는 내부 네트워크와 인터넷 사이의 중간자 역할을 하며, 외부의 불법적인 접근으로부터 내부 네트워크를 보호.
• 또한, 내부 네트워크의 IP 주소를 숨기고 프록시 서버의 IP 주소로 대체하여 보안성을 높임.

3. 접근 제어

• 프록시 서버를 통해 특정 웹 사이트나 서비스에 대한 접근을 제어.
• 예를 들어, 관리자는 특정 사이트에 대한 접근을 차단하거나, 사용자 권한에 따라 인터넷 사용을 제한할 수 있음.

4. 익명성

• 사용자가 프록시 서버를 통해 인터넷에 접속하면, 사용자의 실제 IP 주소가 숨겨지고 프록시 서버의 IP 주소가 사용됨.
• 이를 통해 사용자의 익명성을 보장할 수 있습니다.

5. 로드 밸런싱

• 여러 대의 프록시 서버를 사용하여 네트워크 트래픽을 분산시킬 수 있음.
• 이는 서버에 대한 부하를 줄이고, 서비스의 가용성과 성능을 향상.

장점

빠르다. 행복한 클라이언트.

할 일이 줄어든다. 행복한 서버.

외부 네트워크로 나가는 트래픽이 줄어든다. 행복한 로컬 네트워크.

받는 돈이 줄어든다. 슬픈 KT.

받는 돈이 줄어든다. 슬픈 AT&T.

 

단점

캐싱의 근본은 자주 참조되는 데이터의 복사본을 프록시 서버에 두는 것.

원본이 바뀌었을 때는 일관성 문제가 발생.

 

캐싱의 예 (링크의 이용률이 오버 되는 상황)

로컬 웹 캐시(프록시 서버)를 설치하면 해결

 

LAN의 가용량에는 여유가 있고, 링크의 가용량이 부족한 상황

1. 케이블을 확장 설치

2. 캐싱 서버를 설치 (일반적으로 더 저렴한 해결책, 효과도 좋다.)

Conditional GET

Conditional GET의 예시

 

요청을 보낼 때 Conditional GET을 사용하면, 캐싱의 데이터 일관성 문제를 해결할 수 있다.

if-modified-since: <date> 이후로 수정이 되었는지 묻는 파라미터를 추가하여,

수정이 되지 않았다면 Not Modified를, 수정이 되었다면 새로운 데이터를 전달함으로써, 프록시 서버의 데이터를 갱신한다.

 

DNS

DNS란?

Domain Name System.

인터넷에서 도메인 이름을 IP 주소로 변환하는 시스템.

본격적인 HTTP 통신 이전에 준비 작업이다.

사용자가 웹 브라우저에 도메인 이름을 입력하면, DNS는 그것을 IP 주소로 변환하여 웹 서버에 접근할 수 있게 한다.

 

DNS의 계층화

DNS의 구조

 

DNS 테이블을 끝도 없이 채워나가다 보면 2가지 문제점을 만난다.

1. 중앙 집중으로 single point of failure 발생

2. 무거워져서 느려짐.

 

따라서 그림과 같이 분산화와 계층화를 한다.

다음과 같은 구성 요소로 이루어져 있다.

 

1. Root Name Server

• 인터넷의 DNS 시스템에서 최상위에 위치
• 전 세계에 걸쳐 13개의 루트 네임 서버가 존재
• 이 서버들은 전체 DNS 조회 과정의 시작점 역할
• 최상위 도메인(TLD)에 대한 요청을 받으면, 해당 TLD를 관리하는 네임 서버의 주소를 제공.

2. TLD (Top-Level Domain) Server

• TLD 서버는 도메인 이름의 최상위 부분(예: .com, .net, .org 등)을 관리.
• 각 TLD는 자신의 네임 서버를 가지며, 이 네임 서버는 해당 TLD에 등록된 모든 도메인의 정보를 관리.
• 특정 도메인 이름에 대한 조회를 받으면, 그 도메인 이름을 관리하는 권한 있는(Authoritative) 네임 서버의 주소를 제공.

3. Authoritative Name Server

• 권한 있는 네임 서버는 특정 도메인에 대한 최종적인 권한을 갖는다.
• 해당 도메인의 모든 서브 도메인을 포함한 상세한 DNS 정보(예: IP 주소, 메일 서버)를 제공.

 

DNS 조회 과정

1. iterated query / 2. recursive query

1. 사용자가 웹 브라우저에 도메인 이름을 입력.
2. 사용자의 컴퓨터는 로컬 DNS 서버에 도메인 이름에 대한 IP 주소를 요청.
3. 로컬 DNS 서버가 해당 정보를 캐시에 가지고 있지 않은 경우, 루트 네임 서버에 조회를 요청.
4. 루트 네임 서버는 해당 도메인의 TLD 서버 주소를 제공.
5. TLD 서버는 도메인의 권한 있는 네임 서버 주소를 제공.
6. 권한 있는 네임 서버는 최종적으로 도메인 이름에 대한 IP 주소를 제공.
7. IP 주소 정보는 로컬 DNS 서버를 거쳐 사용자의 컴퓨터에 전달되고, 이를 통해 사용자의 컴퓨터는 웹 서버에 접속한다.

도메인 레코드

도메인 레코드

A타입과 NS타입이 중요하다.

DNS 데이터를 관리하기 위해서 보통 A, NS 타입의 데이터를 관리한다.

타입	name	value
A타입	호스트 이름	IP 주소
NS타입	도메인	호스트 이름(해당 도메인을 관리하는 authoritative server)

 

DNS의 프로토콜

DNS는 UDP를 사용한다.

1. 데이터의 크기가 매우 작다. 따라서 에러 발생 가능성도 작고, 손실의 리스크가 적다.

2. DNS는 본격적인 HTTP 통신 이전에 준비 과정이다. 따라서 간단할수록 좋다.

 

Socket 프로그래밍

소켓이란?

소켓의 구조

상술하였듯이, 소켓은 OS에서 제공하는 인터페이스이다.

애플리케이션 계층의 프로세스와, 통신 계층을 연결한다.

프로세스 간의 통신은 소켓을 통해서 이루어진다. (내부는 IPC 소켓, 외부는 네트워크 소켓)

 

하나의 기기는 여러 개의 소켓을 갖는다. (IP 주소로 찾는다.)

하나의 소켓은 여러 개의 프로세스를 갖는다. (포트 번호로 찾는다.

소켓은 특정 IP 주소 & 포트 번호의 조합에 바인딩 되어 있다.

 

소켓의 분류

타입에 따라 다른 소켓의 구조 (1. TCP: SOCK_STREAM / 2. UDP: SOCK_DGRAM)

 

소켓은 전송 계층의 프로토콜에 따라 2개의 분류로 나뉜다.

TCP는 SOCK_STREAM, UDP는 SOCK_DGRAM이다.

각 특징은 프로토콜의 그것을 따른다.

 

TCP: Socket 함수의 구조

TCP 소켓을 통해 통신이 이루어지는 과정

socket()

int socket(int domain, int type, int protocol);

소켓을 생성하는 함수.

type 파라미터를 통해 SOCK_STERAM / SOCK_DGRAM을 정한다.

socket file descriptor(일종의 id) or -1를 리턴한다.

bind()

IP 주소와 포트 번호를 바인딩하는 함수.

int bind(int sockfd, struct sockaddr* myaddr, int addrlen);

myaddr: 서버의 IP 주소와 포트 번호

listen()

해당 소켓으로 request를 받을 수 있도록, 연결에 대한 준비 상태로 만드는 함수

int listen(int sockfd, int backlog);

backlog: request 데이터를 담을 buffer의 사이즈를 결정한다.

accept()

해당 소켓으로 연결 준비를 마치는 함수. 이때부터 연결까지 blocking.

int accept (int sockfd, struct sockaddr* cliaddr, int* addrlen);

cliaddr: 클라이언트의 IP 주소와 포트 번호

 

새로운 소켓 id를 return한다.

이것을 이후 write(), read() 통신에서 사용한다.

connect()

연결을 시작하는 함수.

클라이언트 측에서 요청한다.

close()

연결을 종료하는 함수.

클라이언트와 서버 양측에서 종료해야 연결이 끊긴다.

 

UDP: 소켓 함수의 구조

UDP: 소켓 함수의 구조

상대적으로 단순한 구조를 갖고 있다.

따로 Connection 과정이 없는 것이 특징이다.

 

 

 

 

 

 

참조

컴퓨터네트워크 - 이석복, 한양대학교, 2018-1: http://www.kocw.net/home/search/kemView.do?kemId=1312397

자료: https://gaia.cs.umass.edu/kurose_ross/ppt.php