네트워크: Application layer 정리(HTTP, Proxy, SMTP, POP, IMAP)

이번 포스팅은 어플리케이션 레이어(Application layer)에 대해 알아본다.

 

어플리케이션이라 함은 현재 우리가 사용하고 있는 서비스를 가르킨다..

 

이메일, 웹, 텍스트 메시지, 유튜브, 넷플릭스등 우리로부터 떼어낼 수 없는 것들을 말한다.

 

이러한 서비스들을 제공하는 계층을 어플리케이션 레이어라고 한다.

 

어플리케이션 레이어는 end system에서 동작하며 네트워크 코어를 통해

 

다른 end system과 메세지를 주고 받는다.

 

 

 

 

< 어플리케이션의 구조 >

 

1. Client-server

1) server 

 

- 서버는 always-on 상태를 유지한다.

- 영구적인 IP 주소를 갖는다.

- 데이터 센터에 위치

 

2) client 

 

- 서버를 이용해서 통신한다.

- 간헐적으로 연결되기도 한다.

- 동적 IP주소를 갖는다.

 

 

2. peer-to-peer(P2P)

- 서버는 no always-on 상태(항상 서버에 접속해 있을 필요가 없다)

- peer와 peer끼리 서비스를 요청하고 제공한다.(self scalability를 갖는다)

- 간헐적으로 연결되며 동적 IP주소를 갖는다.

 

 

 

 

<App-layer protocol>

 

Application layer는 다음과 같은 규칙들을 따른다.

 

- 요청, 응답 메시지 교환

- 메시지 syntax

- 전달하는 메시지의 의미

- 언제 어떻게 프로세스가 메시지를 보낼지

 

application layer protocol은 오픈 프로토콜과 사설 프로토콜이 있는데

현재 많이 사용되는 HTTP, SMTP는 오픈 프로토콜이고 

Skype와 같이 다른 기업들과 차별화하기 위해 만들어진 사설 프로토콜이 있다. 

 

 

 

 

< Process communicating >

 

프로세스(process)란 호스트안에서 동작하는 프로그램을 의미한다.

 

프로세스들간의 통신은 크게 두가지로 나뉘는데 

 

1. 하나의 호스트 내부에서 두개이상의 프로세스가 통신하는 것

 

2. 다른 호스트간의 프로세스 통신이다. 

 

1번을 가능하게 하는 것은 호스트 inter-process communication(운영체제)라 한다.

 

2번의 경우는 메시지를 통해 통신한다.

 

 

 

프로세스는 크게 client process, server process로 나뉜다.

 

- client process: 통신을 시작하는 프로세스

- server process: 접속을 기다리는 프로세스

 

그리고 p2p구조의 경우 두 프로세스를 모두 가지고 통신한다.

 

 

 

 

 

<Sockets>

프로세스는 소켓을 통해 메시지를 주고 받으며 

 

프로세스들끼리 통신하기 위해서는 각각 그에 대한 주소와 포트넘버가 필요하다.

 

IP주소 하나만으로 많은 프로세스를 구별하기 힘들기 때문에 

 

Identifier로 host의 IP주소와 port number로 통신한다.

 

 

 

 

<What transport service does an app need?>

 

호스트들은 어플리케이션을 통해 데이터를 주고 받으며 통신한다.

 

신뢰성있는 통신을 하려면 다음과 같은 것들이 요구된다.

 

- Data Integrity

  100 % 신뢰성 있는 데이터가 필요하다(하지만 종종 오디오 같은 app들은 손실이 조금 생겨도 괜찮다)

 

- Timing

  낮은 딜레이, 즉 빨라야 한다. 

 

- Throughput

  요구되는 최소 전송속도를 지켜야 한다.

 

- Security

  보안 문제

 

 

 

 

application layer protocol의 동작에 대해서 알려면

transport layer protocol에 대해서도 알아야하니 간단하게 알아본다.

 

< Internet transport protocols services >

 

1. TCP

 

- 프로세스를 주고 받는데 신뢰성있는 전송 방법

- sender는 receiver에게 100% 모두 전송한다.

- 네트워크가 오버로드 될때 sender가 조절한다.

- 속도가 느려 guarantee가 떨어진다. 

- 연결 지향적이다(클라이언트와 서버 사이의 필수조건)

 

 

2. UDP

 

- 속도가 빨라 guarantee가 높다

- 신뢰성이 떨어지는 전송 방법

 

 

 

 

<Web과 HTTP>

 

1. Web

 

네이버 웹사이트에 들어갔을 때 HTML 파일, JPEG 이미지, 오디오 파일등

다양한 오브젝트들로 구성되어 있는 것을 본적 있을 것이다. 

 

우리는 다음과 같은 URL을 통해서 웹 사이트를 볼 수 있고  

 

 

 

이는 http 프로토콜을 이용하여 요청을 보내 웹 서버로부터 응답을 받은 것이다. 

 

 

 

2. HTTP(Hypertext transfer protocol)

 

Application layer protocol로써 웹 상에서 클라이언트는 HTTP프로토콜을 이용하여

웹에 있는 object들을 볼 수 있고 필요한 동작들을 요청할 수 있다.

 

요청을 받은 서버는 HTTP프로토콜을 이용해서 클라이언트의 요청에 대해 응답한다. 

 

요청을 주고 받을 때 HTTP은 TCP와 함께 사용되며 다음과 같은 과정으로 통신한다.

 

1) 클라이언트는 서버에 대한 TCP connection(port 80)을 열어 놓는다.

2) 서버는 클라이언트로부터 TCP커넥션을 받는다.

3) 웹(서버)과 브라우저(클라이언트)는 HTTP메세지를 교환한다.

4) TCP커넥션을 닫는다.

 

Http is "stateless"!

HTTP로 정보를 주고 받은 후, 서버는 클라이언트의 예전 정보에 대해서는 기억하지 못한다. 

 

 

 

 

<HTTP connections>

 

1. non-persistent HTTP

 

하나의 오브젝트당 한번의 TCP connection이 필요하다.

 

예를 들자면, 웹 페이지 하나를 보기 위해서 웹 페이지 안의 모든 오브젝트에 대해

TCP connection이 필요하다. 

 

오브젝트가 10개인 경우, 10번의 connection이 필요하다.

 

요청하고 응답하기까지 걸리는 시간은 다음의 과정을 통해.

하나의 object를 얻을때까지 걸리는 시간은 2 RTT + 파일 전송에 필요한 시간 이다.

 

RTT: 클라이언트에서 서버로 돌아오는데 걸리는 시간 

 

Response time = 2 RTT + 파일 전송에 필요한 시간

 

 

 

2. persistent HTTP

 

한번의 TCP 커넥션을 통해 여러개의 오브젝트를 얻어올 수 있다.

 

서버는 리스폰스를 보낸 이후에도 connection을 열어 놓는다. 

 

열어 놓은 커넥션을 통해 클라이언트는 계속 요청을 보내고 

서버는 들어온 요청에 맞게  오브젝트를 전송한다. 

 

이후 응답을 마친 서버는 TCP connection을 닫는다.

 

 

다음은 http rerquest message로 connection상태가 keep-alive임을 알 수 있다. 

 

 

 

 

<쿠키(cookies)>

 

네이버에 접속하면 네이버는 접속한 클라이언트의 정보를 저장한다.

저장한 정보를 이용하여 네이버는 클라이언트에게 네이버 쇼핑몰 카트, 추천 품목등의 서비스를 제공한다.

 

이와 같은 방식은 쿠키를 이용하는 것인데

 

처음 인터넷에 엑세스할때 클라이언트는 HTTP를 통해 사이트에 request를 보내고,

웹 사이트는 접속한 클라이언트에 대한 unique ID를 만들어 데이터베이스에 기입해 놓는다. 

 

쿠키는 이렇게 state를 저장해 놓음으로써 

웹에서 authorization, shopping cart, recommendation, web-email과 같은 서비스를

이용할 수 있게 해준다. 

 

 

 

 

 

<Web Caches(Proxy server)>

 

중간에 프록시 서버(proxy server)를 서버와 직접적으로 통신 없이 통신할 수 있다.  

 

또한 IP를 노출을 꺼리는 클라이언트는 프록시를 이용하여 서버에 접근할 수 있다. 

 

이전의 클라이언트 요청에 대한 캐쉬가 프록시 서버에 존재한다면, 프록시는 이를 바로 클라이언트에게 리턴해주고

 

만약 캐시가 존재하지 않는다면, 프록시는 http요청을 origin 서버에게 보내 응답을 받은 후, 클라이언트에 리턴해준다.  

 

프록시 서버는 이렇게 클라이언트와 서버로써 동작하며,

거리적 이점까지 확보해 클라이언트의 요청에 더 빠르게 응할 수 있다.

 

미국에 있는 서버를 왔다갔다 하는 것 보다 중간에 프록시를 두어 통신하면 더 빠른 것처럼 

 

 

 

 

< Electronic mail >

 

다음, 네이버, 구글과 같은 플랫폼들에서 전자 메일 서비스를 이용한 경험이 있을 것이다.

 

이러한 플랫폼들은 각자 mail server를 따로 가지고 있는데 

mail server들은 SMTP(Simple mail transfer protocol)방식으로 통신한다.

 

 

 SMTP는 다음과 같은 특징을 갖는다.

 

- 신뢰성 있는 메시지 전송을 위해 TCP를 사용한다. (port 25를 사용)

- 서버에서 서버로 바로 전송한다.

- 메세지는 아스키코드 형태로 전송된다.

 

 

 

- 엘리스 agent에서 엘리스의 mail server로 메일 전송시 SMTP 사용

- 엘리스의 mail server에서 밥의 mail server로 메일을 전송할 때, SMTP를 사용

- 밥의 mail server 에서 bob agent로 메일 전송시, pop imap등을 사용 

 

 

 

※ POP3

 

- 메일을 다운로드하고 지우며 클라이언트가 바뀌면 메일은 지워지기 때문에 다시 읽을 수 없다.

- session 사이에 stateless 를 유지한다.

 

 

※ IMAP

 

- 서버의 한 곳에 모든 메시지를 모아둔다. 즉 다시 읽기가 가능하다. 

- state를 유지한다.

 

 

※ HTTP vs SMTP

 

- HTTP가 pull이라면 SMTP는 push

- 아스키커맨드와 응답 상호작용이 있다.

- HTTP는 각각의 object들이 캡슐화되어 그차체의 메시지로 보내지는 반면

  SMTP는 여러개의 object들이 여러개의 메시지 형태로 보내진다.

 

 

 

 

 

 

 

 

 

 

※전공 공부용을 작성했습니다.

출처: computer networking a top down approach