1. Multimedia networking
크게 세가지 응용이 있다.
1. streaming audio, video
ex) netflix, youtube
스트리밍이랑 전체 파일을 다 다운받지 않더라도 play를 할 수 있는 것을 말한다.
piece를 연속적으로 다운 받아 빠른 play가 가능하도록 한다.
네트워크가 많이 바빠서 latency가 크다면 버퍼링 등을 활용하여 더 좋은 품질을 제공할 수 있다.
2. streaming live audio, videa
실시간의 경우는 quality를 희생하더라도 빠른 응답시간이 매우 중요하다.
3. conversational voice/video over ip
ex) skype, kakao audio call
위의 1,2는 단방향 통신이였지만 이 경우는 양방향 통신이 가능해야 한다.
live audio/video, online game처럼 delay에 대해 매우 민감할 것이다.
보통 delay < 150 msec 라면 좋은 환경이라고 한다.
audio,video processing하는데도 시간이 걸리기 때문에 많은 여유분을 delay에 할당해줄수 없다.
2. Server-client vs. P2P
통신이 필요한 서비스를 만들려면 가장 먼저 네크워크 구조를 server-client, p2p로 할건지 결정해야 한다.
고려해야하는 조건들은 다음과 같다.
easy of managment : 보통은 server-client 방식이 관리가 더 쉽다. 하지만 bitcoin같은 경우는 P2P가 훨씬 적합할 수 있다.
point of failure : 서버가 죽으면 아무것도 할 수 없다. P2P는 몇몇 사용자가 죽더라도 계속 돌아갈 수 있다.
scaling : 몇명의 user를 support할 수 있나? 일반적으로 P2P가 훨씬 확장에 용이하다.
security : 모든 보안 알고리즘을 서버에 적용하면 되므로 보통은 client-server 방식이 더 안전하다. 하지만 역시 어떤 측면에서는 bitcoin같은 p2p가 더 안전할 수 있다.
latency, bandwidth :
server-client 모델은 두 hosts가 통신을 할때 반드시 server를 거치게 되어있다. 그에 따른 latency가 있을 수 있다.
하지만 P2P라면 두 Host는 직접적 둘이 통신을 한다. 훨씬 latency가 적다.
3. Skype
skype직원이 아니라면 사실 얘네가 어떻게 동작하는지 알 수는 없다.
하지만 reverse engineering을 통해 추측은 해보자.
skype는 P2P 방식으로 동작한다.
supernode(SN)은 특별한 기능을 수행하는 peer들이다. 이 peer들은 서로 연결되어 overlay network를 구성한다.
P2P지만 login같은 작업을 처리하기 위한 분리된 서버가 존재한다.
-> 주황client는 가장 먼저 supernode와 connection을 만든다. (tcp)
-> 주황client 스카이프 중앙 서버에 login
-> 초록client가 어디 있는지 찾아야 한다. 주황client와 연결된 supernode가 인접한 다른 supernode들에게 초록client위치를 물어본다
-> 초록client와 연결된 supernode가 주황client와 연결된 supernode에게 초록client의 위치를 알려준다.
-> 그럼 초록client는 주황client의 위치를 알게 되고 이제 둘이 직접 통신을 수행한다.
우리는 대부분 NAT뒤에서 private ip를 사용한다.
public ip가 아니므로 NAT가 없다면 인터넷은 나의 위치를 찾지 못한다.
즉 서로 private ip를 사용하고 있다면 "직접" 통신이 불가능하다는 얘기다.
Relay를 사용하면 이 문제를 해결할 수 있다.
내가 private ip를 사용중이고 상대가 public ip를 사용중이라면 나->상대 방향의 통신은 가능하다.
그러니 각 client는 supernode와의 connection을 연결한채로 통신을 해야 한다.
더 이상 direct call은 아니고 2개의 SN에 의존해야 한다.
즉 skype는 완전히 P2P에만 의존하는 방식은 아니다.
'ComputerScience > Network' 카테고리의 다른 글
TCP - 4. congestion control (0) | 2022.05.03 |
---|---|
TCP - 3. flow control, connection management (0) | 2022.05.02 |
TCP - 2. Reliable data transfer (0) | 2022.04.29 |
TCP - 1. connection-oriented-transport (0) | 2022.04.29 |
Transport Layer - 4. Reliable data transfer Design (3) (0) | 2022.04.12 |