[컴퓨터 네트워킹]2장 애플리케이션 정리 - 2

2장 애플리케이션 계층
2.5 P2P 파일 분배
P2P 아키텍처
- P2P는 always-on 서버가 없다.
==> 서버 사용하는 P2P도 있긴 한데 서버의 역할이 서버와 클라이언트 사이의 통신이 아닌 peer들을 관리하기 위한 서버이다.
- 임의의 end system(클라이언트들, peer들) 끼리 직접적으로 소통한다.
- peer들은 항상 켜져있지 않고, IP주소가 고정되어 있지 않다. P2P 구조 확장성 : 분배 시간 client-server vs P2P

"F 사이즈의 파일을 한 서버로 부터 N개의 peer들에게 distribute 하는데 얼마나 시간이 걸릴까?"
-> peer의 업로드/다운로드 용량은 정해져 있다.

+ us : 서버의 파일을 네트워크로 업로드 하는데 걸리는 전송 속도(업로드 속도)
+ di : 네트워크에서 클라이언트로 파일을 보내는 속도(다운로드 속도)
-> 전송속도가 더 낮은 쪽(bottleneck이 걸리는 쪽)이 파일을 다운받는 전송 속도를 결정한다.

File distribution time : client-server
- 서버 전송 시간 : N개의 파일 복사본들을 순차적으로 send(upload) 해야 한다.
+ 한 카피당 서버에서 네트워크로 업로드 하는데 걸리는 시간 : F/us
+ N 개의 카피들을 보내기 위해서는 N번 업로드 해야한다 : NF/us

- 클라이언트 다운받는 시간
+ 클라이언트들이 동시에 다운받으려 할 때 가장 다운 속도가 느린 곳에서 bottleneck이 발 생하기 때문에 다운로드 속도가 가장 느린 곳이 전체 속도를 결정한다. : F/dmin

- 전체시간
+ 파일 업로드 시간과 파일 다운로드 시간 중 오래 걸리는 시간이 파일을 distribute 할 때 걸리는 시간

-> 클라이언트의 수가 늘어나면 N이 증가한다. -> N에 따라 linear 하게 속도 증가

File distribution time : P2P
- 서버 전송 시간
+ 처음에는 서버에만 파일이 존재하고 네트워크 상에는 파일이 없다.(파일을 가지고 있는 서버일 뿐).
+ 클라이언트들이 파일을 요청하는 상황에서 일단 한번은 서버에서 업로드를 해야 한다.
+ F/us

- 클라이언트 다운받는 시간
+ 모든 클라이언트들이 다운받아야 하므로 가장 다운속도가 느린곳에 의해 결정
+ F/dmin

- 한번 파일을 다운로드 한 후로는 클라이언트들의 업로드 bandwidth를 사용 가능하다.
+ 클라이언트가 서버 역할을 하는 것.
+ 한 파일을 다 다운로드 한 후 전달이 가능한 것이 아니라 어느 정도(chunk) 다운로드 하면 그때부터는 다운받은 부분들을 전달 할 수 있게 된다.
+ 즉 원래 서버의 업로드 속도 + 클라이언트들의 업로드 속도의 합 = 전체 업로드 속도
+ 이 때 N개의 클라이언트가 모두 파일을 다운받아야 하므로 총 필요한 비트 수는 NF 비트
+ 이 때 걸리는 시간 = NF/(서버 업로드 속도 + 클라이언트들의 업로드 속도의 합)

- 전체 시간
+ (한 파일에 대한)서버 업로드 시간, 클라이언트 다운받는 시간, 전체 파일에 대한 업로드 시간 중 가장 큰 시간이 파일을 distribute 하는데 걸리는 시간이다.

-> 클라이언트가 늘어나면 N이 커지지만, 그만큼 업로드 해주는 클라이언트 역시 많아지므로 linear 하게 증가가 아닌 낮은 속도로 증가한다.

-> 클라이언트가 많을수록 P2P 구조가 효율적

-> 안정성 문제 : 서버는 24시간 열려 있기 때문에 시간이 소모되더라도 안정적이지만 P2P의 경우 파일을 제공하는 클라이언트들이 꺼져 있으면 파일을 다운받지 못한다.

P2P file distribution : BitTorrent
- 파일이 256kb의 청크로 나누어 진다.(크기는 설정에 따라 달라질 수 있음)

- 토렌트(torrent) : 파일을 주고받는 peer들
+ 토렌트의 peer들이 파일 chunk들을 주고받는다.

- 트래커(tracker) : 일종의 서버 역할 - 어떤 피어들이 파일 distribution에 참여하고 있는지 트래킹(추적) 한다.
+ 트래커를 통해 peer들의 리스트를 받고, 토렌트의 peer들과 파일을 주고 받는다.

- 토렌트에 peer들이 참여하는 과정
+ 처음에는 chunk가 없다. 하지만 시간이 지나면서 다른 peer들로부터 축적된다.
+ 트래커에 등록 되고 주변 peer들(neighbor)과 커넥션을 맺어서 파일을 다운로드 한다.

- 다운로드 받는 동안에도 chunk들을 다른 Peer들에게 업로드 해 줄 수 있다.

- 파일을 다운로드 하는 중에 다운받는 peer를 바꿀 수도 있다.
+ churn : 다이나믹하게 peer가 바뀌는것.

- peer가 파일 전체를 갖게 되면 떠나거나(이기적, 받을거 받고 안준다는 마인드) 토렌트에 남아(남아서 파일 제공)있을 수 있다.

BitTorrent : requesting, sending file chunks

- chunk 요청
+ peer들이 가지고 있는 chunk들이 다를 수 있다.

+ 주기적으로 각각의 peer들에게 어떤 chunk를 가지고 있는지 물어본다.(chunk list 요청)

+ 요청 방식 : rarest first -> 희귀한 chunk 부터 먼저 요청한다. (가지고 있는 peer가 적은 chunk 먼저 요청, peer들이 떠날수도 있으니까)

- chunk 보내기(tit-for-tat)
+ 요청 받으면 보내줘야 한다.(우선순위를 갖고 보내줌)

+ 자기한테 가장 높은 속도로 chunk를 보내주고 있는 peer들(많은 데이터를 주는 peer들)이 우선순위가 높다.

+ 그 중 상위 네명의 peer에게 보내준다.

+ 다른 peer들은 자신으로 부터 데이터를 못받는다.(choked 상태)

+ 10초 마다 상위 네 peer를 갱신한다.

+ 30초 마다 랜덤으로 peer를 고르고 chunk를 보내준다.(ooptimistically unchoked - 상위 네명 말고 다른 애를 랜덤으로 골라줌)

+ 새롭게 선택된 peer가 상위 네 peer에 들어올 수도 있다.

+ 자신도 랜덤으로 받아서 누군가의 상위 네 peer가 될 수도 있다.

2.6 비디오 스트리밍과 컨텐츠 분배 네트워크
2.6.1 인터넷 비디오
+비디오 : 일정한 비율로 보여지는 이미지들의 sequence(순열)

+디지털 이미지 : 픽셀 array(배열) -> 각각의 픽셀들은 비트로 표현된다.

+코딩 : 중복(redundancy)을 사용해 이미지의 비트수를 줄인다.
-> spatial : 한 이미지 내의 같은(비슷한) 부분에 대한 정보를 줄임(압축)
-> temporal : 이전 이미지와 달라지지 않은 부분을 줄임(압축)

2.6.2 HTTP 스트리밍 및 대쉬(DASH)
DASH : Dynamic Adaptive Streaming over HTTP
-> 멀티미디어 스트리밍을 http 위에서 함
-> 서로 다른 인코딩률을 같는 비디오를 선택할 수 있도록 허용
-> 각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다. HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 매니패스트(manifest) 파일을 가지고 있다.

2.6.3 콘텐츠 분배 네트워크(CDN)
문제점 : 수많은 시청자가 있으면 어떻게 서비스 할 것인가?
해결책
1. 서버 하나를 엄청 크게
- 서버가 터지면 문제
- 트래픽이 커지면 congestion 발생
- 서버가 멀리 있으면 딜레이 증가
- 한 영화를 여러 사람이 다운받는 상황-> 같은 링크로 여러번 전송

2. 서버를 분산시킴(CDN : contents distribution network)
-> 다수의 지점에 분산된 서버들을 운영하며, 비디오 및 다른 형태의 웹 콘텐츠 데이터의 복사본을 이들 분산 서버에 저장한다.
- enter deep : 엑세스 망 안쪽에 CDN 서버를 놓음(더 유저에 가깝게)
- bring home : 엑세스 망 바깥쪽에 CDN 서버를 놓음(개수는 적고 딜레이는 크지만 더 넓은 지역 커버 가능)

CDN 동작

CDN 동작

1. 사용자가 NetCinema의 웹페이지를 방문한다.

2. 사용자가 http://video.netcinema.com/6Y7B23V 링크를 클릭하면, 사용자의 호스트는 video.netcinema.com에 대한 DNS query를 보낸다.

3. 사용자의 지역 DNS서버(LDNS)는 호스트이름의 "video"문자열을 감지하고는, 해당 query를 Netcinema의 책임 DNS 서버로 전달한다. Netcinema 책임 DNS 서버는 해당 DNS query를 KingCDN으로 연결하기 위해 IP주소 대신에 KingCDN의 호스트 이름(예 : a1105.kingcdn.com)을 LDNS에게 알려준다.

4. 이 시점부터 DNS query는 KingCDN의 사설 DNS 구조로 들어가게 된다. 사용자의 LDNS는 a1105.kingcdn.com에 대한 두 번째 query를 보내고 이는 KingCDN의 DNS에 의해 KingCDN 콘텐츠 서버의 IP 주소로 변환되어 LDNS에게 응답된다. 이때, 클라이언트가 콘텐츠를 전송받게 될 서버가 결정된다.

5. LDNS는 콘텐츠를 제공할 CDN 서버의 IP주소를 사용자 호스트에게 알려준다.

6. 클라이언트는 KingCDN 서버의 IP주소를 얻고 나면, 해당 IP주소로 직접 TCP연결을 설정하고 비디오에 대한 HTTP Get 요청을 전송한다. 만약 DASH가 사용된다면 서버는 먼저 서로 다른 버전의 비디오에 대한 URL 목록을 포함하는 manifest 파일을 클라이언트에게 전송하고 클라이언트는 동적으로 서로 다른 버전의 비디오 조각 단위 데이터를 선택할 수 있다.

클러스터 선택 정책
1. 지리적으로 가장 가까운 클러스터를 할당하는 기법

2. 현재의 네트워크 트래픽 상황을 반영한 최선의 클러스터를 선택하기 위해 CDN은 주기적으로 클러스터와 클라이언트 간의 지연 및 손실 성능에 대한 실시간 측정을 통한 선택 기법

출처 : https://velog.io/@kms9887/%EC%BB%B4%ED%93%A8%ED%84%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-2.-Application-Layer5