2. Application Layer (3)

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)을 한다.

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