[네트워크] application layer!

network layer에서는 프로그래머가 transparent특성으로 밑 layer에 대한 고민이 없이 socket만 보고 짜면 된다.

->socket

• 프로세서 간 통신의 종착점!
• application layer와 transport layer의 interface로, 그 둘을 연결하는 문이라고 생각해도 된다. application 의 message와 transport layer의 segment가 교차하는 지점이다.

-> port

• host 내에도 여러 process가 있기 때문에, IP address로만은 process를 identify할 수 없다! 따라서 그들을 구별해줄 port가 필요하다. process의 identifier은 IP+port 라고 보면 된다.
• HTTP server : 80 / mail server : 25

-application architectures <client-server VS p2p>

->client-server

•  server : always-on host로 permanent IP address를 가진다. 서비스를 제공한다.
• client : 항상 연결되어있진 않으며, dynamic address를 가져도 좋다! 서비스를 요청한다.

->p2p

• peer은 server와 client 둘다 될 수 있다.
• self-scalability특성이 있다. -> peer가 많아질수록 네트워크가 커지고, 그에 따라 성능도 증가할 수 있다. 
• free-ride problem -> 모두가 client만 되려고 하는 free ride problem이 존재함! 

-TCP vs UDP

-> TCP service 

• reliable !!
• flow control을 보장한다. flow control 은 sender가 receiver의 수용능력 만큼만 보내도록 control하는 것을 말한다.<sender<->receiver>
• congestion control을 보장한다.  congestion control은 network내에서의 congestion을 control하는 것을 말한다. <in network!>
• real time을 보장하진 않는다. 아무래도 속도가 느려지겠지.
• 데이터 전송 전 hand shaking을 한다!!
• ex)SMTP(email), HTTP, FTP(file transfer)

-> UDP

• unreliable!! <flow control, congestion control보장하지 않음!>
• real time data service에서 많이 사용!! (좀 틀려도 되지만, timing이 중요한 것들!)
• ex) streaming service, telephony

-WEB<HTTP protocol>

• web page는 objects로 구성되어 있다.
• HTTP 는 TCP기반 client-server 모델로, stateless!!! 하다. 
• stateless : 서버가 현재 상태를 저장하지 않는다.(메모리 overhead피하려고)
• port : 80
• non persistent HTTP -> persistent HTTP 현재는 parallel + persistent HTTP 이다 ! 예제를 보자.

-->문제는 7번에서 8번으로 연결된다고 생각해라. 7번에서 우리는 DNS로 부터 ip를 받아오는데 걸리는 시간이 RTT1+....+RTTn이고,(이건 밑에서 배운다.) 처음에 한번 msg를 전송하였으면, TCP기반이므로 handshaking하느라 RTT0, msg전송하느라 RTT0가 걸리므로, 현재까지 걸린 delay 는 2*RTT0+RTT1+...+RTTn이다. 여기서 8번을 보자.

a.  non-persistent 이면서 no parallel하므로, object를 전송할때마다 handshaking+msg transfer을 수행한다. 8개의 object를 더 전송하므로 16RTT0만큼 추가로 더 걸린다. 따라서 답은, 

18*RTT0+RTT1+...+RTTn

b. non-persistent이면서 5 parallel connection이므로, 8개의 object를 보내기 위해선, 2번의 handshaking+msg transfer이 일어날 것이다. 따라서 4RTT0만큼 추가로 더 걸린다. 따라서 답은,

6*RTT0+RTT1+...+RTTn

c. persistent HTTP 이면서 pipe lining이라면, 한번에 모든 msg를 전송할 수 있다. 따라서 7번에서 handshaking하였으므로 또 다른 handshaking이 필요가 없고 RTT0만큼만 더걸린다. 따라서 답은,

3*RTT0+RTT1+...+RTTn

(여기서 문제가 미흡한게 사실! pipe lining이 msg를 parallel하게 한번에 다보내는 기법을 의미한다고 한다는데, 이게 추가되야 이런 답이 나온다.)

• URL method / POST method
• URL method : GET방식으로써, url을 통해 parameter을 server에 보낸다.
• POST method : parameter 을 message의 entity body에 넣어서 보낸다.

HTTP request message format

-cookies

• HTTP 는 stateless하기 때문에, 이에 state기능을 추가하기 위해 cookie가 생겨났다!
• 쿠키는 아래 그림과 같이 전송된다.
1. client가 최초 request를 amazon server에게 보내면, amazon server은 client에게 unique한 cookie를 할당한다.(1678) 그리고 이를 자체 DB에 저장한다!
2. client는 할당받은 쿠키번호를 file로써 가지고 있으며, 다시 아마존에 접속하면 아마존서버는 쿠키번호를 보고, DB에 저장된 쿠키번호랑 비교하여 정보를 저장 및 이용한다.

• 당연한 얘기이겠지만, 쿠키는 추천시스템, 찜하기 등 다양하게 이용되는 동시에, 사생활 침해의 여징역시 가지고 있다. 

-web cache(proxy server)

• HTTP에서 user가 이용하는 browser은 HTTP requests를 일단 cache 에 먼저 요청한다. 이 때 cache내 object가 있으면 리턴하고, 없으면 origin server에 요청하게 된다.
• 즉 , 이를 담당하는 proxy server은 server이자 client의 역할을 수행하게 된다.
• proxy server은 client입장에서는 object받는 속도를 높이고! network  입장에서는  congestion을 줄여주므로 개이득이라 볼 수 있다. 문제로 살펴보자.

• (a) find the total average response time.
•  초록색으로 필기한 그림을 보자. 문제조건에서 공용 인터넷에서 server로부터 object받아오는 RTT가 3초이다. 
• 공용인터넷의 라우터와 LAN의 라우터 사이의 traffic intensitiy 를 계산해 보면 16*850000 / 15000000 = 0.907이다. <R:1.5MB/s임!> 이는 밑의 함수를 보면, 1에 가까운 숫자니 queueing delay를 상당히 초래하겠지?
• object에 대한 dtrans = L/R = 850000 / 150000000 = 0.0567이다.
• 따라서 average access delay = 0.0567 / 1 - 0.907 = 0.6초이다.
• 정리하자면 , 지금 구하려고하는건 정확히 말해 한 object에 대한 response time 이다. 우선 공용 라우터까지 object가 가는 delay는 현재 라우터의 congestion이 상당히 일어나고 있는 상태 이므로 0.0567초가 아닌 queueing delay로 인해 0.6초로 늘어난다. queueing delay로 인해 10배나 늦어졌다. (여기서 average access delay는 쉽게말해서, traffic이 없을땐(0) 분모가 1이되는데, queueing delay가 전혀 안생기니까 transmission delay그 자체가 되겠지? 또, traffic intensitiy가 1에 가까울수록 delay가 배수로 증가하는 성향을 띤다. ㅇㅋㅇㅋ?? 이런 느낌임 그러다가 1이 되버리면 queueing delay가 무한이 되므로, 즉, packet 오는 속도가 나가는 속도보다 커지거나 같아지므로 delay가 무한이 된다!)
• 따라서 답은 3+0.6 = 3.6초!
• (b) 풀어보자.
• cache miss rate 가 0.4이면, cache server가 LAN에 있으므로 속도가 상대적으로 무한히 빨라진다고 가정하면, (bottle neck안일으킴) 다음과 같이 식을 쓸수 있겠다.
• average access delay = 0.0567 / 1 - (0.907 * 0.4) = 0.089
• 즉, congestion이 줄어들어, delay도 급격히 낮아졌다!!
• 답은 0.6*0 + 0.4*(3+0.089) = 1.24초!
• 엄청난 차이지??

-Electronic mail

• SMTP protocol + user agent + mail server
• mail server에서 user의 mail을 관리한다. 이 mail server간의 message통신이 SMTP프로토콜로 이루어진다.
• TCP방식 ~

-DNS (Domain Name System)

• IP주소와 name을 matching해준다.
• distributed, hierarchial database
• DNS를 찾아가는 과정을 설명해보자면, 우선 ISP옆에 local DNS를 두는데, 이녀석을 먼저 찾아본다. 대부분의 query는 여기서 해결된다. 여기에 원하는 name이 없을 경우 root DNS server로 가서 계층적으로 TLD(Top level domain->.edu, .com) -> Authoratative DNS 순으로 내려오면서 매칭되는 name을 찾아간다. 
• 전세계에 root dns는 약 12개 있다. CNN같은 대형 사이트의 경우 같은 이름을 갖는 server을 여러군대에 두어서 load balancing을 가능토록 한다. 즉 name하나에 (www.cnn.com) 여러 서버의 ip주소가 각기 다른 DNS에 매칭되어 접속 위치에 따라서 다른 서버로 접속하게 된다. 아마 이렇게 되면 전세계 cnn server들이 분산된 형태일듯하다.

-P2P architecture

• P2P에서는 기본적인 특징, peer가 server, client 둘 다 될수 있다는 점, 간헐적으로 연결되며, scalability가 있다는 기본적인 특징이 있다. 이에 추가하여 파일 업로드, 다운로드를 이해하고 계산할 수 있으면 괜찮다.

• 위 그림을 보자. 이 네트워크 아케텍쳐가 client-server라고 해보자. 서버는 Fsize의 파일을 us의 rate로 upload하며 각 client는 di의 속도로 다운로드한다고 치자. 그러면 N명의 client가 다운을 받는데는 얼마나 걸릴까?
• 먼저 server는 n개의 file을 copy하여 upload해야 하므로 NF/us의 시간이 걸린다.
• client중 가장 느린 다운로드 속도 같는 녀석의 다운로드속도를 dmin이라 하면, client가 다운로드 받는 속도는 최대 F/dmin이다.
• 따라서 Delay >= max{ NF/us, F/dim} 이다.
• 여기서 보면 server가 혼자서 n명의 client모두를 위해 file을 upload하는 과정이 굉장히 부담되는 bottle neck이라고 생각 할 수 있다.
• 이번엔 위 그림이 P2P모델이라고 보자. client가 upload하는 속도를 ui라고 보면, N명의 client가 다운로드받는데는 얼마나 걸릴까?
• 먼저 초기에 최초 peer가 upload를 해줘야 하므로 그 delay는 F/us이다.
• N명의 client가 다운로드받기 위해서는 N*F size의 파일이 네트워크에 업로드되야 한다. 이러는 데 걸리는 delay는 NF/(us+u1+u2+...+un)이다.
• 다운로드 받는 delay는 마찬가지로 F/dmin이다.
• 따라서 Delay >= max{ F/us, NF/(us+u1+u2+...+un), F/dmin} 이다. 여기서 server 혼자서 모든 client를 위해 file upload하던 것을, 이제 각 peer가 함께 upload하기에, bottle neck의 부담이 많이 줄어드는 효과가 생길 것이다. 실제로 p2p모델은 peer가 많아질수록 network의 scale이 커지고, 통신이 더욱 효율적으로 일어난다. 다음 그래프처럼.

• BitTorrent <advanced P2P>

• 일단 data를 256kb chunk로 쪼개고, 이 chunk를 수요에 맞게 보내주는 좀더 진전된 방식이다.
• alice가 이 네트워크에 합류하면 tracker로부터 필요한 upload를 해줄 수 있는 4개정도의 provider를 할당받아, 끼리끼리 필요한 data chunk를 주고받게 된다. 30초마다 provider가 바뀐다.
• 이런 방식으로 각 peer은 서로에게 필요한 data chunk를 효율적으로 받을 수 있게된다.

-vedio streaming and CDNs(content provider networks)