2. application layer

본 내용은 Computer networking : a top-down approach 책을 바탕으로 정리하였습니다.

 

Index

• 0. 애플리케이션 계층이란?
• 1. 네트워크 애플리케이션의 원칙
• 2. TCP, UDP
• 3. WEB, HTTP
• 4. 쿠키와 캐시

 

0. 애플리케이션 계층이란?

 

애플리케이션 계층은 컴퓨터 네트워크에서 인터넷 프로토콜 컴퓨터 네트워크를 통하는 프로세스 간 통신 접속을 위해 설계되어 통신 프로토콜과 방식을 위해 보유된 추상 계층이다. 

* host(end systems)에서만 작동하는 계층이다.

출처 : https://ko.wikipedia.org/wiki/응용_계층

응용 계층 - 위키백과, 우리 모두의 백과사전

 

1. principles of network applications

 

1.1 네트워크 app 종류

 

네트워크 app은 단순하게 네트워크를 사용하는 애플리케이션이라고 보면 된다.

예를 들어, 우리가 자주 사용하는 이메일, 웹 브라우저, sns, 게임, 유튜브 등이 네트워크 app에 해당한다.

 

 

1.2 인터넷 프로토콜 스택

위 그림과 같이 인터넷 프로토콜 스택은 5개의 계층으로 이루어져 있다. 

이 그림은 저번장에서도 살펴보았지만, 이번엔 좀 더 자세히 보도록하자.

 

• application layer : 이번 장에서 가장 집중적으로 공부할 계층이다. 애플리케이션 계층은 프로그램이 실제로 구현할 수 있는 프로토콜을 제공하며, 그림처럼 인터넷 프로토콜 스택의 최상위 개념이다. FTP, SMTP, HTTP가 있다.
• transport layer : 실제로 데이터를 전송시키는 기능을 한다. TCP, UDP가 이 부분에 해당한다. 
• network layer : 데이터그램을 출발지 -> 목적지로 라우팅 하는 부분이다. IP, 라우팅 프로토콜이 있다.
• link layer : 이웃 네트워크끼리 데이터를 전송하는 역할을 한다. 이더넷, 와이파이가 있다.
• physical : 선으로 비트들을 연결해준다. copper, fiber coax 등이 있다.

 

1.3 캡슐화와 역 캡슐화

 

이 부분 또한 저번장에서 보았지만, 좀 더 자세히 살펴보도록 하자.

 

1) 캡슐화

 

애플리케이션 계층에 있는 메시지(정확히는 원본 메시지를 보내기 쉽게 쪼갠 메시지이다)를 각 계층을 거치면서 헤더를 붙이는 과정이다. 이때 중요한 것은 아무 헤더나 갖다 붙이는 게 아니라 각 계층마다 정해진 헤더를 붙이게 된다.

 

각 계층별 헤더

• application layer -> message
• transport layer -> segment
• network layer -> datagram
• link layer -> frame

이렇게 분류된 헤더를 PDU(Protocol Data Unit)이라고 한다.

 

2) 역 캡슐화

 

캡슐화 과정에서 붙인 헤더들을 토대로한 데이터 분류 및 헤더 제거 과정을 거친다.

 

 

1.4 애플리케이션 구조

 

가능한 애플리케이션 구조는 두 가지로 client-server와 peer-to-peer(P2P)가 존재한다.

 

1) Client-server 구조

클라이언트 - 서버 구조는 이름처럼 클라이언트와 서버로 나뉜다.

각 특성을 살펴보자.

 

서버

• 항상 연결되어있어야 한다("always-on")
• IP주소를 영구적으로 가져야 한다.
• 규모에 따라 바뀌는 데이터 센터

클라이언트

• 서버를 통해서만 소통한다(다른 클라이언트끼리 연결 불가)
• 가끔 연결된다(항상 켜져있지 않다)
• 유동적인 IP 주소를 갖는다.

 

2) P2P 구조

peer-to-peer 구조는 복합적인 시스템으로 사용자가 모두 peer인 구조이며

peer가 서버, 클라이언트의 역할을 모두 한다.

 

특성은 다음과 같다.

• 항상 켜져 있을 필요가 없다.
• 소통 시 무작위로 연결된다.
• 자가 확장성(self-scalability) - 각 피어들이 파일을 요구하지만, 각 피어들이 다른 피어에게 파일을 분배함으로써 새로운 피어가 추가 될수록 성능이 좋아진다.
• IP가 바뀔 수 있다.

 

1.5 프로세스

 

프로세스는 호스트(end system) 내에서 애플리케이션 레이어를 작동시키는 것을 의미한다.
즉, "실행되는 프로그램"을 프로세스라고 한다.

프로세스는 어디서 작동되느냐에 따라서 단어가 조금씩 바뀐다.

 

• client process : 클라이언트의 프로세스로 주로 서버에 무언가를 요청하는 것을 말한다.
• server process : 서버 내의 프로세스로 주로 클라이언트의 요청을 기다리는 것을 말한다.

* p2p process는 둘의 역할을 같이한다.

 

추가로 프로세스는 같은 호스트 내에서 통신할 수도 있고(inter-process communication),
각각 서로 다른 호스트 내부의 프로세스에서 메시지를 주고받을 수도 있다.

 

서로 다른 프로세스끼리 데이터를 전달하기 위해 우리는 소켓이란걸 이용하게 된다.

 

1.6 소켓

위 그림은 소켓의 위치를 표현한 그림으로, 애플리케이션과 트랜스포트 계층 사이에 있고, OS에 의해 컨트롤된다.

 

방금 언급한 프로세스들의 메시지(요청 또는 응답) 전송을 위해서

네트워크 통신을 위한 프로그램들은 소켓을 생성하고, 이 소켓을 통해서 서로 데이터를 교환한다. (창구 역할)

 

즉, 우체통처럼 데이터를 소켓에 넣으면 우체부가 소켓에 있는 데이터를 가져간다고 보면 된다.

 

 

 

1.7 주소 처리법

 

메시지를 받기 위해선 프로세스는 반드시 각자의 id를 가지고 있어야 한다.

이 id는 IP의 주소와 포트 번호로 구분하게 된다.

 

IP

먼저 IP는 호스트 디바이스가 갖는 32 비트짜리 주소로 127.124.313.255 이런 식으로 되어있는 주소를 본 적이 있을 것이다. 이 3자리 4개는 각각 8비트 숫자로 4개가 모여 32비트 IP 주소가 된다.

 

그럼 각 프로세스마다 IP주소가 다 다르나요?

아니다. 많은 프로세스는 같은 호스트 내에서 동작하기 때문에 IP 주소가 같은 경우가 많다.

 

포트 번호

포트 번호는 데이터를 받을 프로세스를 식별하게 해주는 역할을 하며 16비트짜리 정수이다.

보통 HTTP 서버는 80번, 메일 서버는 25번 고유 번호를 가지고 있다.

 

 

1.8 애플리케이션 레이어 프로토콜

 

애플리케이션 레이어 프로토콜은 다음과 같은 정보들을 담고 있다.

• 무슨 명령? (요청, 응답)
• 문법 (메시지 안에 어떤 필드가 있는가?)
• 의미 (출발 및 도착지 ip, 포트 번호)

 

1.9 애플리케이션 레이어가 기대하는 트랜스포트 레이어의 역할

 

애플리케이션과 트랜스포트 레이어는 서로 붙어있고 상호작용하기 때문에 서로 돕고 살아야 한다.

따라서 애플리케이션 레이어가 기대하는 트랜스포트 레이어의 역할들이 있는데 다음과 같다.

 

1) 데이터 보전(data integrity)

 

데이터의 손실 없이 전송하기를 바란다는 것이다.

 

하지만 이는 애플리케이션의 종류에 따라 나뉘는데

메일이나 웹 통신은 100%의 신뢰성을 요구하는 반면, 오디오는 어느 정도의 손실을 허용한다.

 

왜냐하면, 메일의 경우 만약 중요한 문서를 보낼 때 어느 부분이라도 손실되면 타격이 큰 반면

오디오는 가끔 끊겨도 어느정도 방송 내용을 이해할 수 있기 때문이다.

 

2) 타이밍

 

타이밍은 딜레이의 반대말로 트랜스포트 레이어가 데이터를 적은 딜레이로 주고받아 주길 원하는 부분이다.

 

3) 처리량

 

간단히 전송량으로 생각하면 되고, 이 분야도 멀티미디어 같은 경우 전송량의 최소 조건이 있는 반면에

문서 전송 같은 경우는 조금 천천히 전송되어도 타격이 적다.

 

4) 보안

 

이 4가지는 이후 다른 계층에서 꾸준히 등장하기 때문에 매우 중요하다!

모든 애플리케이션이 이 4가지를 완전히 만족시키지는 못하기 때문에 확실히 필요한 것과 필요하지 않은 것을 선별해서 설정하여야 한다.

 

 

 

2. TCP와 UDP

인터넷 트랜스포트 프로토콜 서비스에는 두 가지가 있다.

 

2.1 TCP

 

Transmission control protocol의 약자로 신뢰적인 전송을 추구한다.

TCP의 특징은 다음과 같다.

 

• 송수신자 간의 신뢰적인 전송
• 흐름 제어 : 송신측과 수신측의 데이터 처리 속도 차이 해결 방식
• 혼잡 제어 : 송신측의 데이터 전송과 네트워크의 데이터 처리 속도 차이 해결 방식
• 데이터 보전 (타이밍, 처리량, 보안은 제공하지 않는다)
• 서버 - 클라이언트 간 연결 설정 단계를 거친다.

 

흐름 제어와 혼잡 제어는 용어가 조금 헷갈릴 수 있는데, 이 둘의 처리 방식을 생각하면 외우기 쉽다.

 

흐름제어는 송신자의 데이터 처리 속도를 수신자의 데이터 처리 속도보다 낮추면 해결할 수 있고,

혼잡제어는 라우터의 버퍼(저장 공간)을 키우거나, 버퍼가 넘치지 않도록 네트워크의 데이터 처리 속도에 맞춰 송신자의 전송 속도를 낮추면 해결 가능하다.

 

2.2 UDP

 

User Datagram protocol의 약자로 단순한 전송 방식을 갖는다.

UDP의 특징은 다음과 같다.

 

• 비신뢰적인 데이터 전송
• 모두 안 해줌 (시간, 처리량, 보안, 신뢰적 전송 등 ..)
• 사실 데이터 전송만 해도 빡빡하다.
• 오직 데이터를 빠르게 보내는 것에 초점을 맞춘다. (real-time streaming)

 

2.3 각 프로토콜의 범용성

 

 

2.4 보안 TCP

 

TCP와 UDP는 암호화를 제공하지 않기 때문에 TCP를 강화한 SSL을 개발하였다.

 

SSL

Secure Sockets Layer의 약자로, SSL로 강화된 TCP는 TCP가 하는 모든 것을 할 뿐만 아니라

암호화, 데이터 무결성, 종단 인증을 포함하는 프로세스 보안 서비스를 제공한다.

SSL은 애플리케이션 계층에서 구현된 것으로서 SSL 서비스를 이용하고자 한다면 인증키를 가지고 해독하여야만 한다.

 

 

3. Web and HTTP

 

3.1 웹에 대한 기본적인 이해

 

• 웹 페이지는 객체(글, 그림, 동영상 등)로 구성된다.
• 객체들은 HTML 파일, JPEG 이미지, 오디오 파일 등이 있다.
• 웹 페이지는 HTML 파일 기반으로 구성되어 있다.
• 각각의 객체들은 URL 주소를 갖고 있다.

 

3.2 HTTP의 기본

 

HTTP는 hypertext transfer protocol의 약자로 HTML 문서를 주고받는 규약을 의미한다.

 

웹의 애플리케이션 레이어의 프로토콜이며, HTTP 프로토콜을 사용하여 클라이언트와 서버 간의 요청, 응답을 주고받는다.

 

HTTP는 호환성을 가지고 있는데, 이는 우리가 웹페이지에 접속할 때 어떤 디바이스나 OS에 상관없이 HTTP 규약만 맞추면 접속 가능하게 해 준다.

 

 

3.3 Transport layer 관점에서의 HTTP

 

Transport layer에서 HTTP는 TCP를 사용하게 된다.

 

TCP 사용 과정은 다음과 같다.

• 클라이언트가 TCP 연결을 서버에 요청
• 서버는 클라이언트에게 받은 TCP 연결을 수락
• HTTP 메시지가 브라우저와 웹 서버 사이에서 교환(전송)
• TCP 연결 종료

HTTP는 "stateless"

말 그대로 상태가 없는 것을 의미하는데, 이는 서버가 각각의 클라이언트 요청에 대한 정보를 유지하지 않는 것을 의미한다. 만약 HTTP가 "state" 한 상태라면 매우 복잡해지기 때문이다.

 

 

 

3.4 HTTP 연결

 

HTTP는 지속성에 따라 분류될 수 있다.

 

우선 Non-persistent HTTP는 초기의 HTTP로 현재는 사용하지 않는다. 왜냐하면 이 HTTP는 객체를 가져올 때마다 연결 설정을 다시 해야 하기 때문에 다양한 객체를 다운로드할 때 너무 많은 연결이 필요하기 때문이다.

 

따라서 이후에 나온 것이 persistent HTTP인데 이것은 단일 TCP 연결에 대해 많은 객체들을 보낼 수 있게 한다.

 

 

3.5 소요 시간 비교

 

Non-persistent HTTP와 persistent HTTP의 소요 시간을 비교해보자.

 

그전에 RTT라는 개념 하나를 알아야 하는데 RTT는 작은 패킷이 클라이언트에서 서버로 갔다가 다시 서버에서 클라이언트로 왕복 한 번 이동할 때 걸리는 시간을 의미한다.

 

위 그림은 HTTP의 요청, 응답 과정을 보여준다.

 

한 번 주고받는 주기를 RTT로 보며, 굵은 선은 파일을 전송하는 시간이 포함되어있다는 것을 의미한다.

 

1) Non-persistent HTTP

 

non-persistent의 HTTP 요청 응답 소요 시간은 2 RTT + file transmission time 이 되고

이 시간은 하나의 파일에 대한 시간에 해당한다. 이 과정을 거치면 연결은 종료되기 때문에 다른 파일을 보낼 때 동일한 과정을 거친다. 즉 10개의 파일을 보내려면 20 RTT + 각 파일의 전송 시간이 되겠다.

 

2) persistent HTTP

 

persistent HTTP는 보낸 후 연결이 유지되어 있기 때문에 한 번 전송하고 나서는 파일의 전송 시간만 쭉 더해주면 된다. 

따라서 10개의 파일을 보내려면 2 RTT + 각 파일의 전송 시간이 걸린다.

 

 

3.6 HTTP 메시지

 

HTTP 메시지에는 두 가지 종류가 있는데 바로 요청과 응답 메시지이다.

 

1) 요청 메시지

위 그림은 요청 메시지의 내용이다.

 

요청 명령에는 GET, POST, HEAD commands 총 3가지가 있다.

• GET : 위 그림처럼 얻고자 하는 파일과 HTTP 버전, 제어 문자를 뒤에 적는다.
• POST : 특정 Form을 적고 이 틀에 맞춰 채워달라는 의미이다. GET과 달리 Form 내부 내용만 받아온다.
• HEAD commands : 특정 헤더를 적고 그에 해당하는 헤더만 달라는 명령이다.
• PUT : 특정 object를 서버에 저장하고 싶을 때 사용
• DELETE : 특정 object가 서버에 저장되어있다면 지움

 

이 명령들을 보면 뒤에 제어 문자들이 있는데 각각 \r은 carriage return, \n은 line-feed라고 한다.

이 명령들을 아무것도 치지 않은 채 마지막에 입력하면 위에서 요구한 data들을 리턴하게 된다.

 

 

2) 응답 메시지

 

위 그림은 HTTP 응답 메시지로 서버가 보내는 메시지에 해당한다.

 

맨 윗줄은 버전과 "200 OK"라는 제대로 명령이 accept 되었다는 표시를 하고

이후 헤더 라인을 거친 후 요청한 데이터를 쭉 보내게 된다.

 

 

3.7 HTTP 상태 코드

 

응답 메시지의 상태 코드는 요청 결과를 의미하게 된다.

 

• 200 OK : 요청이 성공되었고, 정보가 응답으로 보내졌다.
• 301 Moved Permanently : 요청 객체가 영원히 이동되었다. 새로운 URL은 응답 메시지의 location 헤더에 나와있다.
• 400 Bad Request : 서버가 요청을 이해할 수 없다는 일반 오류 코드이다.
• 404 Not Found : 요청 문서가 서버에 존재하지 않는다.(URL이 없다)
• 505 HTTP Version Not Suppoerted : 요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.

 

4. 쿠키와 웹 캐시

 

4.1 쿠키 : 사용자와 서버 간의 상호작용

 

위에서 HTTP 서버는 상태를 유지하지 않는다고 했다. 이는 서버 설계를 간편하게 하고, 동시에 여러 개의 TCP 연결을 다룰 수 있는 고성능의 웹 서버를 개발하도록 해 주었다.

 

하지만 서버는 사용자 접속을 제한하거나, 사용자에 따라 적절한 콘텐츠를 제공하기 원하므로

웹 사이트가 사용자를 확인하는 것이 바람직할 때가 있는데, 이 목적으로 HTTP는 쿠키를 사용한다.

 

쿠키의 4가지 구성 요소

• HTTP 응답 메시지 쿠키 헤더 라인
• HTTP 요청 메시지 쿠키 헤더 라인
• 사용자와 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
• 웹 사이트의 벡엔드 데이터베이스

서버와 클라이언트는 모두 쿠키를 저장하는 장치가 있는데, 서버는 벡엔드 데이터베이스, 클라이언트는 쿠키 파일이 있다.

 

쿠키 사용 예시

 

예를 들어 우리가 학교 홈페이지에 로그인할 때 로그인이 성공하면 우측 상단에 "아이디와 비밀번호를 저장하시겠습니까?"라는 메시지가 팝업 되는 경우가 있는데, 만약 여기서 확인을 누르고 다음 날 다시 학교 홈페이지에 들어가면 자동으로 로그인되는 경우가 있다.

이 경우 사용자 사이드에 쿠키가 저장되는데, 대표적으로 크롬을 사용하면 다음과 같은 위치에 저장된다고 한다.

C:\Users\suhwanc\AppData\Local\Google\Chrome\User Data\Default\Local Storage

 

4.2 웹 캐싱(proxy server)

웹 캐시는 기점 웹 서버(origin)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체이며, 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존한다.

 

웹 캐싱 과정은 다음과 같다.

 

• 웹 브라우저는 웹 캐시와 TCP 연결을 설정하고, 웹 캐시에 있는 객체에 대한 HTTP 요청을 보냄
• 웹 캐시는 그 객체의 사본이 지역적으로 저장되어있는지 확인하고, 만약 저장되어있다면 유저에게 HTTP 응답 메시지와 함께 객체를 전송
• 만약 저장되어있지 않다면, 웹 캐시는 기점 서버로 TCP 연결을 설정하고나서 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 이러한 요청을 받은 후에 기점 서버는 웹 캐시고 HTTP 응답 메시지와 함께 객체를 보낸다.
• 웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본을 보낸다.

웹 캐시는 서버와 클라이언트 모두 존재한다는 것을 유념하자!

 

웹 캐싱의 장점

• 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다.
• 트래픽이 낮아지기 때문에 서버 증설에 따른 비용을 줄일 수 있다.
• 느린 서버더라도 웹 캐시를 사용하면 빠른 콘텐츠 분배를 제공할 수 있다.

 

캐싱 예시 : install local cache

로컬 웹에 캐시를 적용하게 되면 기존 네트워크에서 origin 서버로 이동할 때 소요되는 access link 전송 시간을 매우 크게 줄일 수가 있다.

 

이제 웹 캐싱을 이용해 소요되는 총 딜레이 시간을 구해볼 텐데, 그전에 알아두어야 할 용어가 하나 있다.

• Hit ratio : 원하는 데이터가 cache에 있을 확률

hit rate를 구하면, 웹 캐싱을 사용해서 얼마만큼의 이득을 볼 수 있는지 알 수 있다.

 

만약 hit rate가 0.4라고 하자. 그러면 데이터 요청 시 그 데이터가 캐시에 있을 확률이 40%이고, 캐시에 없어서 origin server로 이동해야 할 확률이 60%가 된다.

 

따라서 총 딜레이 시간은 0.6 x (origin 서버 전송 딜레이) + 0.4 x (캐시 전송 딜레이)가 되고

캐시가 없을 때는 항상 origin 서버에서 데이터를 꺼내오게 된다.

 

이 차이는 생각보다 어마어마한데, origin 서버에 접근 링크를 통해 이동할 때 걸리는 시간이 캐시를 이용할 때보다 매우 오래 걸리기 때문이다. 그렇다고 접근 링크의 속도를 향상하기엔 너무 값이 비싸며, 총 딜레이가 눈에 보일만큼 줄지 않기 때문에 보통 캐싱을 이용하게 된다.

 

 

4.3 조건부 GET

 

웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 새로운 문제를 야기하게된다.

문제는 캐시 내부에 있는 객체의 복사본이 새것이 아닐 수도 있다는 것인데, 다행히도 HTTP는 객체의 갱신 상태를 확인하면서 캐싱하도록 해주는 방식을 갖고 있다. 이러한 방식을 조건부 GET이라고 한다.

 

위 그림은 조건부 GET이 동작하는 과정이다.

과정을 살펴보면, 처음에 http는 요청 메시지에 "if-modified-since: <date>"라는 것을 보내는데, 이는 date 이후로 캐시가 변경된 적이 있는가?라는 질문을 서버에 하는 것이다. 

 

만약 변경되지 않았다면 304 Not Modified 메시지를 보내고, 이는 클라이언트에게 요청 객체의 캐시 된 복사본을 사용하라는 것을 의미한다.

반대로 변경되었다면 HTTP 응답으로 200 ok와 함께 요청한 데이터를 보내준다.