[네트워크] Application Layer

 

최상단 레이어인 application layer에 대해서 정리하겠습니다.

 

Application Layer

Application layer에서는 network application이 실행되고 있습니다.

※ Network Application: OS 위에서 실행되는 프로세스로, 다른 컴퓨터에 메시지를 주고 받을 수 있습니다.

 

사용자들은 보통 application layer에서 앱을 만드는데요. 예: 클라이언트/서버

클라이언트 프로세스(앱)와 서버 프로세스(앱) 간의 inter-process communication을 한다고 생각하면 됩니다.

생각할 내용: IP, port, socket

• IP: 컴퓨터 주소
• port: 컴퓨터 내 실행되는 프로세스 번호
• socket: OS가 제공하는 일종의 API로 socket을 통해 inter-process communication을 함

 

일반적으로 앱을 제작할 때 패킷 유실, 데이터 전송 방법 등 디테일한 것들에 대해서 신경쓰지는 않습니다.

이런 부분들은 하위 레이어에서 신경씁니다.

예: TCP → reliable 제공 

 

어쨌든 Application Layer에서 지원하는 여러가지 프로토콜이 있는데

그 중에 제일 대표적인 것이 HTTP 그리고 DNS 입니다.

 

1. HTTP (HyperText Transfer Protocol)

• Web 브라우징에서 사용되는 프로토콜로, 하이퍼텍스트를 전달할 때 사용됩니다.
• 요청/응답으로 이루어져 있습니다.
• Stateless: 과거의 요청/응답을 저장하고 있지 않습니다.

1.1 HTTP → TCP

HTTP는 transport layer의 TCP를 사용합니다.

TCP를 사용하겠다는 시그널을 보내야지만 TCP를 사용하게 되는데,

이 방법은 두가지가 있습니다.

• Non-persistent HTTP
• Persistent HTTP

1.1.1 Non-persistent HTTP

1) TCP 연결을 맺고 2) 데이터 요청/응답을 받고 3) Close 하는 방식입니다.

HTTP 1.0에서만 쓰이는 방식으로 현재는 더이상 쓰이지 않습니다. (비효율적이기 때문에)

 

클라이언트 요청을 서버로, 그리고 서버의 응답을 클라이언트로 보낼 때 걸리는 시간을 RTT(Round Trip Delay)라고 합니다.

Non-persistent HTTP의 경우, 한 데이터를 받을 때 최소한 2RTT가 걸립니다. (close 제외)

만약 하이퍼텍스트 안에 N 개의 reference가 있을 경우,

총 (1 + N) × 2 RTT가 걸립니다. (하이퍼텍스트 1개 + 레퍼런스 N개)

 

 

1.1.2 Persistent HTTP

1) TCP 연결을 맺고 2) 데이터 요청/응답을 전부 받은 다음 3) Close 합니다.

현재 HTTP에서 사용하고 있는 방식입니다.

 

Non-persistent HTTP의 경우 데이터를 요청할 때마다 매번 TCP 연결을 맺어야 하는데요.

Persistent HTTP의 경우 처음 한 번만 TCP 연결을 맺고,

그 이후로는 모든 데이터를 받을 때까지 TCP 연결을 끊지 않고 있다가,

모든 데이터가 전송이 완료되면 최종적으로 TCP를 close 합니다.

 

만약 하이퍼텍스트 안에 N 개의 reference가 있을 경우,

• 처음 TCP 연결을 맺기 위한 1RTT
• 1개의 하이퍼텍스트 + N개의 레퍼런스를 받기 위한 (N + 1) RTT

→ 총 (N + 2) RTT만에 데이터를 전부 받아올 수 있습니다.

 

생각해볼 문제?

What's end-to-end delay using persistent HTTP? (What if pipelining?)

• Control messages = K bits (TCP handshake, HTTP request)
• Base HTML object = L bits
• N reference objects, each L bits
• Link bandwidth R bps
• Propagation delay = d seconds

 

1. 2 HTTP 요청/응답

이정도까지만 해도 HTTP의 80%는 알았다고 보시면 됩니다.

다음으로는 간단하게 HTTP 요청과 응답이 어떻게 생겼는지 보겠습니다.

1.2.1 HTTP 요청

여기서 중요한 건 HTTP method 입니다. GET, POST, PUT, DELETE 등 몇 가지가 있는데요.

이는 클라이언트/서버 모델에서 요청과 응답이 이루어지는 방식을 뜻하는 것으로

예를 들어 GET으로 요청을 보냈다고 하면 서버의 특정 내용을 읽게 되는 것입니다.

POST로 요청을 보내면, 서버에 특정 내용을 쓰게 됩니다.

 

HTTP 요청에서는 HTTP method 뿐만 아니라 헤더(header)도 같이 보내집니다.

헤더는 요청과 관련한 metadata가 저장된다고 생각하시면 됩니다.

1.2.2 HTTP 응답

HTTP 응답에서는 반드시 제일 앞에 1) HTTP 버전과 2) HTTP status code가 있어야 합니다.

HTTP status code는 응답의 상태를 뜻하는 것으로

만약 200이라면 정상적으로 페이지를 전달하는 것이고

404라면 요청한 페이지가 없다는 것을 뜻합니다.

 

1. 3 쿠키 (Cookie)

앞에서 HTTP의 특징 중 하나가 stateless라고 했는데요.

이렇게 된다면 서버는 클라이언트가 이전에 어떤 요청을 보냈는지에 대한 히스토리를 저장하고 있지 않습니다.

이를 해결하기 위해서 쿠키가 등장합니다.

 

쿠키는 클라이언트와 서버사이의 상태를 저장하고 있는 것입니다.

쉽게 말해서 요청/응답에서 쓸모 있는 정보들을 저장하고 있는 것이라고 생각하면 됩니다.

쿠키는 웹 브라우저의 작은 스토리지에 저장되어 있습니다.

 

아래 예시를 보면 좀 더 이해가 잘 될 것 같은데요.

1. 최초의 요청에는 쿠키가 없기 때문에, 쿠키없이 서버에 요청을 보냅니다.
2. 서버는 Set-cookie: <cookie ID>와 함께 쿠키 ID를 클라이언트에게 보냅니다.
   그리고 서버는 이 쿠키를 서버의 스토리지에 저장합니다.
3. 앞으로 클라이언트는 서버에 요청을 보낼 때 마다 쿠키를 포함해서 보냅니다.
4. 서버는 쿠키에 저장되어 있는 정보에 따라서 클라이언트에게 커스텀(custom)한 응답을 보내줍니다. 

서버가 쿠키에 저장되어 있는 정보에 따라서 클라이언트에게 응답을 내려준다고 이야기를 했는데요.

만약 클라이언트가 키보드를 사기위해 인터넷 서핑을 했을 경우

서버는 이 정보를 쿠키에 메모해두고

클라이언트에게 키보드와 관련된 내용들을 인터넷에 더 자주 띄우게끔 하는거죠!

 

1.4 웹 캐싱(Web Caching): 프록시 서버(Proxy server)

자, 제주도에 살고 있는 클라이언트가

티스토리의 경쟁사인 네이버 블로그(blog.naver.com)에 접근을 하고 싶다고 가정합시다.

 

네이버 블로그의 서버는 아마

수도권 어딘가의 데이터센터에 있을텐데요.

 

매번 네이버 블로그에 들어가기 위해서는 제주도에서 수도권까지 서버 요청을 해야한다는 겁니다.

제주도와 수도권은 꽤 거리가 있기 때문에

서버에서 요청을 받는 시간이 꽤나 오래 걸릴 수 있겠죠?

 

이를 해결하기 위해서 웹 캐싱이 등장합니다.

네이버 블로그의 내용을 가지고 오기 위해 매번 수도권까지 가지 않고

제주도 어딘가에 웹 캐시인 프록시 서버를 둬서

프록시 서버에서 우리가 원하는 내용을 빠르게 찾아서 사용하는 것이죠.

 

예시를 살펴봅시다.

Public Internet 공간에서 turnaround time은 대략 2초라고 가정합니다.

Institutional network 공간은 100Mbps LAN이기 때문에

해당 네트워크 공간에서만큼은 빠르게 웹 서핑이 가능하겠지만 (n millisecond라 가정)

만약 public internet까지 뻗어서 웹 서핑을 하고 싶다면 어떻게 될까요?

 

평균 15 Mbps 만큼 public internet으로의 데이터 요청/응답이 온다고 가정했을 때

access link의 bandwidth는 15 Mbps 밖에 안되기 때문에

access link는 거의 항상 과부하 상태일겁니다.

이렇게 되면 institutional network에 있는 학생이 public internet 쪽의 내용을 검색했을 때

2초 + access link에서 걸리는 delay + n millisecond 정도의 시간이 걸리겠죠?

 

 

이를 막기 위해서 프록시 서버를 institutional network 내부에 두는 겁니다.

프록시 서버는 캐시이기 때문에,

캐시에 내용이 있다면 빠르게 접근이 가능할 것이고

원하는 내용이 없다면 public internet까지 갔다와야겠죠?

 

만약 hit ratio가 70% 정도 된다면,

access link를 통한 요청/응답이 30%로 줄어들기 때문에

빠르게 웹 서핑을 할 수 있게 됩니다.

 

캐시를 공부하게 되면 뒤따라오는 문제가 바로

캐시 일관성 문제 인데요.

프록시 서버가 실제 서버 내용의 복사본을 들고 있다보니

원본 내용이 수정이 되면

프록시 서버도 덩달아서 수정이 되어야 하는데

이게 자동으로 되지 않기 때문에

프록시 서버 내용과 실제 서버 내용이 다를 수도 있다는 겁니다.

 

일관성 문제를 어떻게 해결할 것이냐?

Conditional GET을 사용합니다!

 

header에 If-modified-since 값을 추가해두고

이 값이 last modified 값과 같다면

304 not modified를 리턴받는 겁니다.

 

그렇다면 일정 주기로 프록시 서버가 실제 서버에게 Conditional GET을 날려서

프록시 서버가 들고 있는 내용과

실제 서버가 들고 있는 내용이 같은지 확인해야 하는데요...

이것도 로드가 너무 많이 들지 않냐? 라고 생각할 수 있습니다.

 

하지만, Conditional GET을 통해서 얻는 응답은

수정됨 또는 수정 안됨 둘 중 하나이기 때문에

수정이 되지 않았을 때는

'수정되지 않았다'라는 자그마한 정보만 가지고 오면 되기 때문에

네트워크 트래픽에 큰 문제가 생기지는 않는겁니다!

 

2. DNS (Domain Name System)

2.1 DNS... 넌 뭐냐?

HTTP 다음으로 너무나도 중요한 DNS!

사람이 알아듣기 쉬운 언어로 웹을 방문하는데요.

예를 들어서 duam.net 또는 naver.com 이런 식으로요.

 

하지만 사실... 이거는 별칭일 뿐

실제로 웹 서버에 knock knock 하기 위해서는 

IP 주소로 탐색해야 합니다. XXX.XXX.XXX.XXX

 

그런데 여러분...

IP 주소로 웹 서핑을 하시나요...?

전 한 번도 그런 적이 없습니다^0^

 

IP 주소는 직관적이지 않기 때문에 외우기가 어렵다구요ㅠ

그래서 이 IP 주소를 별칭(=도메인)으로 매핑을 해놓는 것이 DNS라는 겁니다.

 

긍데...

세상에는 수많은 웹 사이트가 있고...

DNS가 하나 뿐인 경우

웹 사이트를 방문할 때마다

전세계 사람들이 이 DNS에 knock knock해서

웹사이트의 별칭(예: daum.net)을 입력하면 매핑된 IP로 변환해주는 작업을 해야할텐데

이렇게 되면 DNS가 하는 일이 너무 많고...

모든 사람들의 요청에 대한 응답을 해줘야하기 때문에 엄청 오래걸리겠죠?

 

그!래!서!

DNS는 일반적으로 분산되어 있고 계층화되어 있습니다.

바로 아래처럼 말이죠!

 

 

2.2 DNS의 종류

DNS는 계층화되어 있다고 말씀드렸는데요.

크게 4개가 있다고 생각하면 됩니다.

사실은 3개 + 1개 라고 생각하면 좀 더 좋습니다...

3개는 Figure 2.17의 DNS 계층 구조에 포함되는 것이고

나머지 1개는 포함이 안되거덩요.

2.2.1 Root DNS 서버

• 최상단 DNS 서버입니다.
• 전세계에 400개가 넘는 root DNS 서버가 존재합니다.
• TLD DNS 서버의 IP 주소를 가지고 있습니다.

2.2.2 TLD(Top-Level Domain) 서버

• .com, .org, .edu 등의 탑 레벨 도메인과 .kr, .uk, .fr 등의 국가 도메인을 관리하는 서버입니다.
• 해당 도메인을 가지고 있는 네트워크의 authoritative 서버 IP 주소를 가지고 있습니다.

2.2.3 Authoritative 서버

• 호스트와 IP를 매핑해놓은 서버입니다.
• 네트워크를 운영하는 모든 기관은 각자의 authoritative 서버를 보유하고 있어야 합니다.

여기서 호스트가 어떤 것이냐?

Happy University의 사이트에 접근을 한다고 가정합시다.

그렇다면 www.happyuniversity.edu로  접근을 하게 될텐데요.

이 때 www가 호스트가 되는겁니다.

portal.happyuniversity.edu에서의 호스트는 portal이 되는거구요!

2.2.4 Local DNS 서버

각 네트워크 안에 구현되어 있는 일종의 DNS 캐시라고 생각하시면 됩니다.

사용자는 제일 먼저 Local DNS 서버에서 내가 찾고자하는 웹사이트의 IP 주소를 찾구요.

Local DNS에 원하는 IP 주소가 없다면 Root DNS 서버에 쿼리를 해서

원하는 IP 주소를 찾아나가는 겁니다.

 

2.3 DNS 예제

1. cse.nyu.edu에서의 클라이언트는 gaia.cs.umass.edu의 IP 주소를 얻기 위해 local DNS 서버인 dns.nyu.edu에게 묻습니다.
2. Local DNS 서버는 gaia.cs.umass.edu IP 주소를 갖고 있지 않아서 Root DNS 서버에 쿼리합니다.
3. Root DNS 서버는 .edu 도메인에 대한 정보를 가지고 있는 TLD 서버의 IP 주소를 보냅니다.
4. Local DNS는 TLD 서버에게 gaia.cs.umass.edu의 IP 주소를 묻습니다.
5. TLD 서버는 gaia.cs.umass.edu의 IP 주소를 갖고 있는 Authoritative DNS IP 주소를 보냅니다.
6. TLD 서버에게 받은 Authoritative DNS(dns.umass.edu)에 gaia.cs.umass.edu의 IP 주소를 질문합니다.
7. Authoritative DNS는 local DNS에게 원하는 정보를 줍니다.
8. 클라이언트는 gaia.cs.umass.edu의 IP 주소를 받아서 웹사이트에 접속합니다.

 

2.4 캐시 일관성 문제?

만약 갑자기 웹 서버를 운영하고 있는 IP 주소가 바뀌게 되면 어떤 일이 벌어질까요?

daum.net은 원래 XXX.XXX.XXX.XXX IP를 쓰고 있었기 때문에

해당 authoritative DNS에는 XXX.XXX.XXX.XXX와 daum.net을 매핑하고 있을 겁니다.

근데 갑자기 IP 주소가 ZZZ.XXX.XXX.XXX로 바뀌었다면

사용자는 IP 주소를 잘못 찾아서

웹 서핑하는데 문제를 겪게 될겁니다.

 

그래서 DNS는 TTL 이라는 것을 함께 들고 있는데요.

이 TTL 시간이 지나면 IP 주소가 업데이트 되었는지 확인하기 위해서

점검을 하는 시간을 가집니다!

이렇게 TTL이 지나면 캐시 일관성 문제를 해결할 수 있게 되는 것이죠.

 

2.5 DNS records

이때까지 DNS는 IP 주소와 도메인 이름을 매핑하고 있다고 했는데요.

사실은 이보다 많은 데이터를 들고 있습니다.

바로 RR format이라는 형식으로 데이터를 가지고 있는데요.

RR format: (name, value, type, ttl)

여기서 type이 제일 중요합니다.

Case 1: type=A

A는 address를 뜻하는 것으로

name은 호스트 이름을 갖고 있고, 예: relay.bar.foo.com

value는 IP 주소를 갖고 있습니다. 예: 145.37.93.126

Case 2:  type=NS

NS는 name server를 뜻하는 것으로

이 경우 name은 도메인을 갖고 있고, 예: foo.com

value는 이 도메인의 authoritative 서버의 호스트 이름을 갖고 있습니다. 예: dns.foo.com