It is just my opinion, so don't you attack me. please!
But if this posting has some incorrect informations, you comment about that
Please!!
TCP vs. UDP
· TCP
✔︎ TCP는 reliable data transfer를 보장함.
✔︎ Flow control(sender가 데이터를 너무 빨리 보내는 것을 제어)
✔︎ Congestion control을 해줌.
✔︎ timing, throughput, 보안을 보장해주지는 않는다.
✔︎ 연결 지향적이다.
✔︎ 알아서 순서를 맞춰줌.
· UDP
✔︎ 위의 어떤 것도 보장해주지 않는다.
✔︎ 그렇다면 UDP는 언제 사용하는가? 동영상이나 VoIP를 생각해보자. 이야기를 하다가 잡음이 들리면 우리는 깨끗한 음성으로 다시 들어야하는가? 아니다. 이런 경우에 UDP를 사용한다.즉, 재전송이 필요 없는 경우에 사용한다.
WEB & HTTP
· HTTP
서버로부터 html 파일을 받아서 client에게 제공해주는 프로토콜로 특징은 Client의 요청을 기억하지 않는다.
· Non-Persistent HTTP - 한 번에 하나의 Object를 전송함.
· Persistent HTTP - 여러 개의 Objects를 한 번의 연결로 전송할 할 수 있음. 대략 2배정도 빠름
· cookies - 웹 브라우저에 저장되며, Server가 가지는 것이 아니라 support를 할 뿐이다. 또한 HTTP response의 Cookie header line이 존재한다.
✔︎ 처음 어떤 사이트에 들어가면 HTTP requst를 요청하게 된다. 이후 server에서는 response를 통해 데이터를 전송하고 필요한 정보를 client측 웹 브라우저에 저장하게 됨.
✔︎ 그리고 나중에 Client가 다시 접속을 하면 request에 cookie header line이 존재하게 된다.
· Web caches - proxy server라고도 하며, client와 물리적거리가 짧은 곳에 server를 두어 캐시로서의 역할을 하도록 함. 일반적으로 ISP에서 설치한다.
✔︎ 99%의 이용률을 가지고 있다면? 아주 심각한 상태임, bursty traffic 상황이 발생한다면 터질 수 있음.
✔︎ 해결 방법1 - Access link capacity를 100배 상승 시킨다면? 이용률이 9.9%까지 떨어지지만 경제적인 문제가 발생한다.
✔︎ 해결 방법2 - local에 web cache를 둔다. server를 한 번 사기만 하면 되므로 경제적으로 저렴하고 이용률도 상당히 줄일 수 있다.
Electronic mail
· SMTP(메일 전송 프로토콜)
HTTP가 Pull 방식이었다고 한다면, SMTP는 Push 방식이다.
Mail server는 User에게서 오는 메일를 저장한다.
✔︎ A는 mail server1에 메일을 전송한다.
✔︎ mail server1은 mail server2와 TCP로 3hand-shaking을 하고 세션을 생성하고 메일을 Push한다.
✔︎ B는 mail access protocol를 통해서 mail server2로부터 메일을 Push 받는다.
✔︎ 세션의 유효성이 확인되면 mail server2가 B에게 메일함에 있는 메일을 전송한다.
DNS(Domain Name System)
✔︎ DNS가 필요한 이유는 IP와 인간 친화적인 주소를 매핑하기 위해서이다.
✔︎ DNS server의 종류로는 root, TLD(org, com, edu), authoritative name server들이 있다.
✔︎ Root의 역할은 authoritative name server에 접근하여 적절한 매핑을 얻는 것이고, 매핑을 local name server에 반환 해준다.(보통은 보안적인 문제로 하지 않는다)
✔︎ local name server(보통 residential ISP, 회사, 대학들이 가지고 있고, default name server라고 불린다)의 역할은 end-host들이 요청한 DNS query를 받고 해석하여 해당 매핑을 찾는다. 없으면 TLD로 가는 것이 보통이고, TLD에도 없으면 root로 root에도 없는 경우는 root에서 authoritative DNS server의 IP를 알려준다.
✔︎ 위와 식으로 iterated하게 하는 것이 일반적이고 recursive적인 방법도 있지만 overhead가 크다.
✔︎ 업데이트를 위한 TTL이 존재 함. DNS는 application layer에 속하고, 또 Best effort인 특징을 갖는다. 즉, 최선은 다하지만 보장은 할 수 없음.
Client - Server 구조
· Server는 항상 켜져 있고, 고정 IP를 갖는다.
· 많은 경우 데이터 센터에 Server들을 설치한다.
· Client끼리 직접소통은 할 수 없고, Server를 통해 통신해야 한다.
P2P 구조
· 직접 end-host끼리 통신을 할 수 있다.
· P2P를 사용하는 컴퓨터가 켜지면 Server capacity가 증가하며, client로서의 수요또한 증가한다.
· 동적 IP를 사용한다.
· 제공과 수요를 동시에 한다. Server, Client 두 가지 역할을 동시에 수행한다.
· P2P를 사용할 경우, Client process와 Server process 둘 다 설정해야한다.
File sharing in environment of Client-Server OR P2P
· Client-Server
✔︎ Server가 각 Client에게 따로 N번의 업로드를 하여 전송해야 한다.
✔︎ N개의 파일 카피가 지나가야하기 때문에 NF / Us의 시간이 걸림
✔︎ Client는 다운로드만 하면 됨. F/d(min)의 시간이 걸림.
Dc-s >= max{NF / Us, F/d(min)}
· Client-Server
✔︎ 최소 하나의 카피만 있으면 된다.
✔︎ 다운로드 속도는 F/d(i), N명이 전부 받아야 함.
✔︎ 최대 업로드 속도는 Us + sigma(1~i) {Ui}, 이런 업로드 속도로 NF의 양을 다운 받으면 최소로 전부 받는 시간이 정해진다.
Video Streaming and CDNs
· Video & CDNs
✔︎ 비디오는 html 요청보다 용량이 크며, 지속성을 요구한다. 하나의 서버로는 절대로 감당할 수 없다. 따라서 분산을 시키고 용량을 줄여서 보낼 수 있는 방안들을 찾아 적용시킨 뒤 전송하는 방식을 사용하고 있다.
✔︎ 용량을 줄이기 위한 노력으로 Encoding을 하는 방식이 있다. 예를 들면 같은 공간에서 같은 값을 갖는 pixel을 압축하는 방법과 프레임간의 차이만 보내는 방식이 있다.
✔︎ 또한 reliable을 위해서 server에 3가지의 resolution을 갖는 각 파일을 저장한다. 이후 네트웍 환경에 맞게 resolution을 선택하여 reliable을 유지한다.
✔︎ 영상을 여러 서버에 분할 저장한 뒤, menifest를 이용하여 각 청크를 마치 P2P처럼 불러와 성능을 높이는 방법도 있다. (이런 것을 CDNs)
Socket Programming
· Socket - app단에서 transport layer와 연결될 때의 매개체 역할, app의 특성에 따라 transport layer를 결정해야 한다.(TCP, UDP)
