2. Application Layer (3)

728x90
반응형

5. P2P applications

1장에 설명했듯이 P2P는 서버 클라이언트 방식이 아닌 클라이언트들끼리 직접 통신하는 방식이다.

대표적으로 비트토렌트나 스카이프 등이 있다.

클라이언트-서버 방식이 있는데 왜 P2P 방식을 사용해야 할까?

바로 다수의 사용자가 어떤 파일을 다운로드 받을 때, P2P 방식이 더 유리하기 때문이다.(시간이 적게 걸린다.)

클라이언트-서버 방식은 사용자가 증가할수록 파일의 업로드/다운로드 시간이 선형적으로 증가하는데 반해, P2P 방식은 로그 함수로 증가한다.

즉, 다수의 사용자가 파일을 공유하는데 있어서, P2P 방식이 훨씬 더 적은 시간을 소모한다.

P2P의 대표적인 프로토콜인 비트토렌트 프로토콜에 대해서 알아보자.

비트 토렌트 프로토콜은 파일을 256Kb의 정크로 나눈다. 그 뒤, 그 정크들을 가지고 피어들이 서로 커뮤니케이션 하는 것이다.

예를 들어, 앨리스가 어떤 파일을 얻고 싶으면 먼저 트랙커에게 접속해서 나 이런 파일을 가지고 싶어요 라고 요청하면 트랙커가 해당 파일을 가지고 있는 피어 명단을 리턴해준다. 그러면 앨리스는 그 리스트를 기반으로 가장 좋은 피어들을 뽑아서 파일을 받는다.

6. video streaming and content distribution networks(CDNs)

유튜브나 넷플릭스 등으로 인해 많은 사람들이 인터넷을 사용하게 된다.

그런데 사용자마다 네트워크 환경이 다 다르다(누구는 대역폭이 풍부하고, 누구는 부족하고, 누구는 유선, 누구는 무선을 사용한다).

그래서 어떻게 하느냐. 맞춤 서비스를 제공한다.

그래서 나온 것이 DASH(Dynamic, Adaptive Streaming over HTTP) 프로토콜이다.

HTTP 프로토콜을 이용해서 내가 어플리케이션을 제공하는데,

서버는 굉장히 다양한 버전의 어플리케이션을 준비해둔다. 영화를 보내는데도 인코딩하는 속도가 다 다르다(어떤 것은 저화질, 어떤 것은 고화질).

그리고 manifest 파일을 유지한다.

여기서 manifest 파일이란, 영상이 업로드 될 때, 영상전체가 올라가는 것이 아닌 256Kb의 정크로 분할되서 저장된다. 또한 동일한 정크에 대해서 여러개의 coding rate version이 생성된다(128Kbps, 256Kbps, 1Mbps 등).

이 manifest 파일을 받아서 네트워크 환경에 따라 다른 버전의 정크를 요청해서 가져온다. 이 때문에 영상 중간 중간에 네트워크 환경에 따라 화질이 바뀌는 것이다.

클라이언트가 서버에게 보고싶은 영상을 요청하면, 서버가 해당 클라이언트의 네트워크 환경에 따라 manifest 파일을 보고 화질을 결정한다. 그래서 해당 클라이언트에게 베스트의 서비스를 제공하는 것이 DASH 프로토콜의 목적이다.

DASH 프로토콜은 클라이언트가 아주 지능적으로 결정을 한다.

내가 이 요청을 언제할지, 어떤 인코딩 레이트로 요청할지, 어느 서버에 요청할지를 결정한다.

엄청나게 많은 사용자들에게 스트리밍 서비스를 동시에 제공해야하는데, 단일의 굉장한 메가 서버를 통해서 제공한다?

네트워크 혼잡도 문제나 서버 고장 문제 등 으로 인해 이는 불가능하다.

그래서 CDN 시스템을 구축한다.

이 CDN 시스템을 구축하는 방법은 2가지가 있다.

· enter deep : 최대한 많은 서버를 각 지역마다 배치해둔다.

굉장히 딜레이가 작지만 돈이 많이 든다.

· bring home : 적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축하자.

약간 느리지만 돈이 좀 적게 든다.

7. socket programming with UDP and TCP

소켓 프로그램이란 클라이언트와 서버 간의 커뮤니케이션을 하는데 소켓으로 하자라는 거다.

소켓이란 application process와 transport layer 이후의 모든 영역과 연결시켜주는 문이다.

이 소켓을 통해서 정보가 들어오고 나간다. transport layer부터는 OS 가 전부 담당하기 때문에 어플리케이션 개발자는 application layer만 집중하면 된다.

소켓 프로그래밍에서 2가지가 존재한다.

· UDP 프로토콜

· TCP 프로토콜

이 두 프로토콜은 Transport Layer의 가장 중요한 프로토콜이여서 다음 장에서 자세히 설명할테니 여기서는 맛보기만 봐보자.

만약에 우리가 소문자로 문장을 작성해서 보내면 서버가 이를 대문자로 바꿔주는 어플리케이션을 만들었다고 해보자.

이런 간단한 프로그램을 만들려고 해도 클라이언트가 서버에게 메시지를 보내고, 서버가 변환해준 다음에 다시 클라이언트에게 보내줘야 하므로 커뮤니케이션이 일어나야 한다.

이를 UDP로 했을 때를 알아보자.

먼저 UDP란 connection part 가 없는 프로토콜이다. 즉, 공식적으로 connection이 확립(established)되지 않고 바로 패킷을 보내고 받는다.

그렇기 때문에, 패킷 손실이 일어날 수도 있고, 패킷이 순서대로 들어온다는 보장이 없다.

순서대로 들어온다는 보장이 없으므로 Application Layer에서 ordering을 해줘야한다.

UDP는 위 사진과 같은 방식으로 동작한다.

클라이언트가 서버에게 소켓을 통해서 바로 패킷을 보내면, 서버는 이를 읽고 응답(response) 해준다.

TCP는 UDP와 약간 다르다.

바로 커뮤니케이션 하기 전에 connection establishment(handshaking)가 일어난다.

즉, 공식적으로 커넥션을 한 뒤에 패킷을 전송한다.

서버가 기다리고 있으면, 클라이언트가 소켓을 만든 뒤에, 커넥션 셋업(connection setup, connection establish, handshaking)을 한다.

그 뒤에, 메시지를 보내고 리스폰스를 받는다.

728x90
반응형

'Study > 네트워크' 카테고리의 다른 글

3. Transport Layer (2)  (0) 2023.06.14
3. Transport Layer (1)  (0) 2023.06.14
2. Application Layer (2)  (0) 2023.06.14
2. Application Layer (1)  (0) 2023.06.14
1. Introduction  (0) 2023.06.14