[컴퓨터 네트워크] chap2. 애플리케이션 계층

2.1 네트워크 애플리케이션의 원리

[네트워크 apps]

• loss sensitive applications(절대 loss 발생하면 안됨): email, web, text messaging, remote login, P2P file sharing
• delay sensiitive applications(loss에는 그다지 sensitive X, delay에 민감): 멀티유저 네트워크 게임, IP너머 통화(skype같은), [스트리밍 저장 비디오(유튜브, 넷플릭스 등), 실시간비디오회의]->bandwidth-sensitive(+용량에도 민감) 이기도 함.
• +social metworking, internet search ...

[네트워크 앱 만들기]

• 다른 end system에서 계속됨 , 네트워크 통신(web server 소프트웨어가 브라우저 software 과 통신)
• network-core device를 위한 software을 작성할 필요 x <  network-core device는 사용자 애플리케이션을 실행 x
• end system에 애플리케이션을 사용하면 신속한 앱 개발, 전파 가능. (application은 end system에만 존재> 번성> internet service 가속

 

[Application architectures]

• Client-Server ex. HTTP, SMTP, DNS (80년대의 application server 다 이 구조 택함), 특정 host들이 server역할, 나머지 user들이 client역할.
  • Server: 항상 켜져 있는 호스트. 모든 서버는 host but 모든 host가 server는 아님 -> 네트워크에 연결이 확립된 모든 장치는 호스트의 자격 O,  다른 장치(클라이언트)로부터의 연결을 수락하는 호스트만 서버가 될 수 O.                        영구적으로 고정된 IP주소 가짐(사람 너무 많으면 run out)/ server가 모든 request reserve 해주는 역할 담당. server demand(서버에 접속하려는 data 많아지면 server capacity 제한적> 확장성 문제: server farm 만들기도 함( expensive...) >  확장을 위한 data center 
  • client: 언제나 서버 통해서 통신(서로 직접 통신하지 않음), 간헐적으로 연결됨(connect 됐다가 꺼졌다가..), dynamic IP주소가 있을 수 있음(남이 접속할 일 별로 없어서 절약하기 위해) ex. HTTP, IMAP, FTP

 

• Peer-to-Peer (P2P)

• ex. BitTorrent(file sharing), Internet Telephony(Skype), p2p file sharing
• 각 peer들이 어느날은 client- call 보냄, 어느날은  server-call 받음. 다른 peer에게 service 요청, 다른 peer에게 서비스 제공(demand 갖고 들어오지만 sevice capability도 제공) - self-scalability: new peers는 새로운 서비스 capacity와 new service demand를 가져옴
• 중요한 server인프라 및 대역폭 요구하지 않음.
• server 통하지 않고 유저끼리 공유, 직접 communicate> 저작권문제
• 항상 켜져있는 server X.
• 임의의 end-system들이 직접적으로 통신
• 관리 복잡하고 어려움 < peer들 간헐적으로 연결되고 IP주소도 변경-peer들이 영구적인 IP주소 갖지 않은 일반적인 user host들이기 때문
• infrastructure (도입)비용 x

[Process Communicating_사실상 프로그램끼리 대화]

 

- process: 호스트 내에서 실행중인 프로그램,

• 동일 호스트 내에서 두 프로세스가 OS에서 정의한 IPC(inter-process communication) 이용해 통신 (한 컴퓨터 내에서 들고있는 process끼리도 data 주고받음)
• 서로 다른 host들의 프로세스는 message 교환으로 통신. (다른 end system에 존재하는 process 간에 얘기를 하려면 entwork application protocal에 따라 데이터 주고받아야 함.)
• Clients-Servers : 브라우저 프로그램이 Web 프로그램을 contact.
  • client process : 통신 시작하는 process/ server process : 세션 시작 위해 접속(contacted) 기다리는 process
• P2P구조의 가진 application 에는 client&server process 모두 있음.

[sockets]

 

process는 socket을 통해 네트워크로 메시지를 주고받는다. host의 application-layer과 transport-layer간의 인터페이스!

 

(1) sending process 는 application developer가 만든 메시지를 out door로 밀어낸다. (운영체제로 전달) 

(2) sending process 는 receiving process의 socket에 메시지를 전달하기 위해 door의 반대편에 있는 전송 infrastructure에 의존

(3) 2개의 socket이 관련된다.(보내는 쪽, 받는 쪽 둘 다 socket이 있어야 함) 

*운영체제에게 심부름 해달라하는 중간역할(=변수)

 

[Addressing process]

메시지를 수신하기 위해서는 process에 식별자가 있어야 한다. 프로세스가 실행되는 호스트의 IP주소만으로는 충분하지 않다. (많은 process들은 same host에서 실행될 수 있음)

 

-identifier: IP address + port number 

  ㄴ IP주소: host 장치가 가진 unique 32-bit IP adress 

  ㄴ port 번호: host의 process와 연결됨  ex. HTTP server: 80, mail server: 25 (server 주소 정해져있음)

>> like: IP address: company address / port name: worker's name

 

[application 계층 프로토콜이 정의하는 것]

• 교환된 메시지 type(요청, 응답)
• 메시지 구문(메시지에 어떤 fields가 있는지 & 어떻게 field 가 묘사되는지 (delineated_구문)
• 메시지 의미론 (field의 정보의 의미_어떤 정보 포함)
• process가 메시지를 보내고 응답하는 시기 및 방법에 대한 규칙(메시지 주고받는 순서, 메시지 받았을 떄 어떤 응답 해야하는지)
• open protocals: RFCs에 의해 정의> 누구나 프로토콜 정의에 access 가능, 누구나 이 절차 따라 만들면 web server, client program 할 수 있음.  상호 운용성 서용(누구나 가능) ex. HTTP, SMTP
• 독점 protocals : ex. Skype(다른 일반인이 사용 불가_대략 짐작)

 

[App에게 필요한 transport service]

 

1. data integrity(데이터 무결성_loss) 

• 완전한 수명 주기를 거치며 데이터의 정확성과 일관성을 유지하고 보증하는 것.
• File transfer, Web transactions.. 과 같은 몇몇 app들은 100% 신뢰되는(reliable) 데이터 전송(loss x)을 요구. → TCP
  • TCP를 사용하면 시간은 늘어나지만, data가 더 정확
• 다른 app들(ex. audio)은 약간의 손실(loss)을 용인한다. → UDP

2. Timing

• 인터넷 전화, 멀티플레이 게임...과 같은 app들은 지연시간(delay)이 거의 없어야 효과적.
  • 속도는 네트워크의 상황에 따라 다르기 때문에, 제어(control)할 수 없음
  • delay 간 차이도 중요. interpacket delay가 smooth해야 함.

3. Throughput(처리량_단위 시간당 처리할 수 있는 업무 단위량)

• multimedia와 같은 앱은 최소한의 처리량이어야 효과적.
• 주어진 시간에 얼마나 많은 data를 수신할 수 있는가? 에 대한 문제
• 기타 탄력적인 앱(email, FTP, 웹 전송) 은 어떤 처리량을 사용하든 상관 x)

4. Security

-암호화, 데이터 무결성 등...

 

[일반적인 app에서의 transprot service 요구사항]

 

[인터넷 전송 protocal service_ 현실에 존재하는 2종류의 tr]

• TCP :
  • 송신과 수신 프로세스 간 안정적 전송
  • 연결지향(중간에 어떤 게 빠졌는지, 잘 흘러가고 있는지 알 수 O): 메시지 주고받기 전에 client와 server process 간9en end 간) connection setup.
  • flow control : sender가 receiver overwhelm하지 x ( network의 어떤 노드가 일시적으로 몰리는 traffic 많으면 buffer 발생. )
  • congestion control: 네트워크 과부하시 sender조정
  • 제공하지 않는 것: timing, 최소 처리량 보장, 보안
  •  application에서 요구하는 throughput 상관없이 '네트워크 혼잡 -> buffer receive -> 자기가 내보내는 속도 확 낮춤 -> application 입장에서 throughput 확 낮아짐.

 

• UDP : 

• 송신과 수신 간 unreliable data transfer(신뢰불가)-되는대로 보내기
• 제공하지 않는 것: reliability, 연결 setup, flow control, congestion control
• 무조건 내보냄> 중간에 congestion&buffer overflow로 drop될 수 o>  but transprot 계층에서 transport service가 surprise x_먼소리야, network에서 만들어지는 속도로 deliver된다.

그럼 왜 UDP가 있느냐 ? 

>> one time transfer: server에게 한 번 물어보고 server가 바로 답 주고 끝! overhead 커지는 거 방지. 

>> smart application: 진짜 application에서 reliability 가 너무 중요하다면 스스로 구현 ->delievery 부탁하는 transfer가 뭐던간에 own reliable transfer을 보장 가능 메커니즘을 자기 application에 넣을거임 ->그냥 UDP로 보내기

 

application, transport protocals

Q. DNS(네트워크에서 도메인이나 호스트 이름을 숫자로 된 IP주소로 해석해주는 TCP/IP 네트워크 서비스) 는 언제 TCP로 변할까요? (원래 대부분 UDP 사용: one time transaction)
A. DNS 메시지가 길어져서 하나의 UDP segment에 다 담지 못하는 경우(UDP는 분류하고 순서 정렬하는 기능 X)

2.2 웹과 HTTP

-review: 웹페이지는 object(HTML파일, jpeg 이미지, java applet_큰 application안에서(위젯내에서)동작하는 작은 app들, 오디오파일...)로 구성, 여러 참조object(다 URL로 표현)를 포함하는 base HTML file로 구성, 각 object는 서로다른 웹서버에 저장가능, 각 object는 URL로 주소 지정 가능,

host name-pathname으로 구성

-> web page = HTML + object

 

-HTTP overview:  web의 application 계층 프로토콜, client/server 모델.

• client: 웹 object 요청, 수신(http protocal 이용) 및 'display'하는 브라우저
• server: 요청에 대한 응답으로 object 전송(http protocal 이용)하는 웹 서버

TCP 사용!

1. TCP connection set-up: 영원히 ON으로 대기하고 있는 server가 port 80 기다림 > client는 server와 port# 80 으로 TCP 연결 시작(socket 생성) -요청보냄
2.  server은 client로부터 온 TCP 연결 수락
3. 브라우저(web client)와 웹 서버(web server) 사이에서 HTTP 메시지(application-layer protocol msg)를 교환한다.
4. 모두 수행했으면, TCP 연결을 종료(close)한다. 

HTTP는 "stateless" protocol.(상태 비저장 protocol)

여기서 stateless라는 것은 history(이전에 수행했던 것)가 지금 상황에 영향을 끼치지 않는 것을 뜻한다. (independent)

만약 서버가 클라이언트에 대한 정보를 유지하게 된다면, 수많은 클라이언트의 정보를 관리하기가 매우 복잡하고 이로 인해 유지보수가 매우 어려워지게 된다. 여러 서버에 걸쳐 요청을 동적으로  load balancing하기 위해 많은 구현이 HTTP의 상태 비저장 상태에 의존. 또한 보안 문제도 증가할 수 있음> 따로 과거 클라이언트의(요청에 대한) 정보를 저장하지 않는다. > 각 요청 메시지 개별 이해 가능 >>보완 위해 쿠키 등장(COOKIE)

 

[HTTP connections : two types]

 

1. non persistent HTTP (1.0) :  Object 하나당 한 개의 TCP 연결을 하는 연결 방식. 여러 object를 다운로드하기 위해서는 여러 번의 TCP 연결 필요. 'TCP 연결 열림> 한 object sent> 닫힘' 반복

2. persistent HTTP (1.1) : TCP 단일 TCP 연결에 여러 개의 object가 전달될 수 있는 연결 방식. '서버와의 TCP 연결 열림-여러개의 object가 client와 server 사이의 한개의 TCP연결로 보내짐-닫힘' 

 

1. non persistent HTTP (1.0)

RTT(Round Trip Time) = 패킷 하나가 클라이언트에서 서버로 갔다가 다시 클라이언트로 돌아오는 시간.

RTT를 이용하여 두 방식의 response time(하나의 webpage를 fully display 해줄때까지 필요한)을 비교해보자. 

* RTT : small packet이 client->server & back to the client 하기까지의 4 delays를 포함하는 시간 첫 번째 RTT는 TCP 연결에 걸리는 시간이고, 두 번째 RTT는 HTTP 요청을 하고 HTTP 응답으로 처음 몇 바이트를 받는데 걸리는 시간이다. 여기에 파일을 전송하는 데 걸리는 시간도 더해야 한다. 따라서 다음과 같은 식이 나온다.

>> 단일 object당 최소 2RTT 소요. (transmission time은 보통 무시), 몇 개의 object, 추가적 URL이 webpage에 들어앉아있냐에 따라 달라짐.

 

 

*non persistent parallel TCP connection 이면 connection 을 back to back으로 내가 원하는 object 개수만큼 동시에 엶. (문제에서 최대 한 번에 얼마나 열 수 있는가 주의해서 보기) 

ㄴ각 connection 마다 운영체제가 필요한 resource 할당해줘야 함.- 대부분의 운영체제가 parallel하게 맺을 수 있는 TCP connection 제한 , 제한 없다면 몇 개의 object 들어있던 4번의 RTT면 됨.

각 TCP 연결에 대한 OS 오버헤드 발생(특정 목표를 달성하기 위해 간접적 혹은 추가적으로 요구되는 시간, 메모리, 혹은 다른 컴퓨터자원): 하나의 브라우저 process당 여러 개의 TCP 연결

non persistent non parallel VS parallel

*non-persistent 애들은 server측에서 request한 object 보내준 후 무조건 connection 닫음

* non persistent parallel TCP connection 에서 한 base html file에 들어있는 object개수가 운체에서 허용하는 maximum parallel의 TCP connection보다 크다면 다시 해야 함.

 

2. persistent HTTP (1.1)

-응답을 보낸 후 서버가 TCP 연결 그대로 열어둠. 열린 연결을 통해 동일한 client-server 사이에서 후속 HTTP 메시지 전송(맺어진 client로부터 더 이상 http request가 안 올 떄까지 server가 open 유지> 참조된 모든 객체에 발견하는 즉시 요청 보냄> 참조된 모든 객체에 대해 1RTT 소요. 

->n개의 object를 검색하는 데 걸리는 총 3 RTT 

 

[RTT 개수 계산 총정리]

1. non-persistent : 2RTT + n*2RTT2. parallel TCP connection : 2RTT + RTT + RTT =4RTT3. persistent: 2RTT+ RTT = 3RTT

-HTTP에는 요청-응답의 2가지 type의 메시지가 있다.

 

[HTTP request msg]

 

*아스키코드로 encoding 

1. request line(server로부터 뭔가를 request, URL에 관한 Webpage 줘!)

• GET : URL에 해당하는 웹페이지 줘!(request에서 하고자 하는 일),제일 빈번하게 쓰임, URL 확장하여 page specific하게 지정
• POST : formfeed 내용이 entity body에 들어감
• HEAD : web server 잘 가져왔는지 test. 제대로 file이 있는지만 check, 실제로 보내지x
• *delete, put: client가 server에 contact 해서 delete 등 web server 내용 update.

2. header lines: client > server로 알려주고 싶은 정보(web page 에 대한 추가정보)

 

 

 

 

 

 

 

 

 

 

Q. 이 GET 메시지에서 검색되는 파일의 이름은 무엇인가요?

A. index.html

 

Q. 클라이언트가 실행 중인 HTTP 버전은 무엇인가요?

A. 1.1

 

Q. 클라이언트에 요청된 파일의 (오래된) 복사본이 이미 있나요? 설명하세요.

A. X / http msg엔 필드를 얼마든지 추가할 수 있음. If-Modifed-Since라는 필드가 있다면 이미 받은 적이 있는 파일이      update되었는지 다시 한 번 request를 보낸 것. 서버는 updated 되지 않았다면 not-modified res를 보낼 것

 

[HTTP response msg]

 

Q. 다른 응답 메시지가 HTTP1.0 또는 HTTP1.1을 사용하나요? 설명하세요.
Q.  문서를 성공적으로 전송할 수 있는 서버를 사용했나요? 설명하세요.
Q. 응답을 받은 날짜와 시간은 언제인가요?
Q. 서버가 반환한 문서의 바이트 수는 몇 바이트인가요?
Q. 서버에서 반환되는 문서에 몇 바이트가 있나요?

Q. HTTP 프로토콜의 기본 연결 모드는 무엇입니까?
Q. 연결 응답이 영구적인가요 아니면 영구적이지 않은가요? 설명하세요.
Q. 서버의 이름과 버전은 무엇인가요?

(마지막에 풀게염..^^)

 

 

[HTTP 응답 상태 코드]

상태코드는 서버와 클라이언트 간 응답 메시지의 첫번째 줄에 표시. 

-headerline for web cache : Not Modified + if modified since + last modified

 

[user, server 상태 유지: 쿠키]

*HTTP protocal : state less(상태저장 x, request에 response 보내고 잊어버림.) , state full이면 복잡(crash 벌어지면 consistent하게 만들기 어려움)

웹 사이트와 클라이언트 브라우저는 쿠키를 사용하여 state less 상태 보완, transaction 상태 유지. (상태유지, tracking 위해)

• 4가지 구성요소 :

1. HTTP 응답 메시지의 set-cookie header line [cookie headerline에 id 달아서 보냄(protocal 외부에 data 달고 옴)->아까 그 사용자군!]
2. 다음 HTTP 요청 메시지의 쿠키헤더라인
3. 사용자 호스트에 보관되고 사용자 브라우저에서 관리하는 cookie파일(client 측에서 cookie file에 어떤 번호 사용했는지 적어놓음, 각 web server별로 어떤 cookie 번호 써야 하는지)
4. 웹사이트의 back-end database(protocal이 refer할 수 있는 external database -내가 어떤 일 했는지)

* 예시 : 수잔이 브라우저로 사이트 처음 방문, 이때는 cookie header line이 없는 상태이다. > 사이트에 첫 HTTP request가 도착하면 site가 unique ID (cookie) 만들고 ID를 위ㅎ나 backend database entry를 만들어준다. > 수잔이 이 사이트에 보낸 후속 HTTP request는 cookie ID 값을 포함하고 site가 수잔을 알아볼 수 있게 한다. (계속 모니터링 하면서 log 남겨놓음)

 

 

• cookie를 사용할 수 있는 용도: 인증(매번 로그인 귀찮을 때), 쇼핑카트, 추천(behavior 습득, 빅데이터 분석을 통해 추천), 사용자 세션 상태(연결유지, 쿠키 달고 가면 훨씬 긴 시간동안 로그인상태 maintain. 몇 달 뒤에 웹사이트 들어가도 header에 쿠키 달고가면 유저 알아봄)
• state 유지하는 방법 : 프로토콜 endpoint: 여러 transaction에 걸친 발신자, 수신자의 상태 유지 / 쿠키: http msg가 상태 carry
• cookie와 privacy : 쿠키는 사이트가 사용자에 대한 많은 정보 얻을 수 있게 함. 제 3자 쿠키(추적 쿠키)를 사용하면 여러 웹사이트에서 공동 ID(cookie)값 추적 가능
•  

[web caches(proxy server: 대행 서버)]

 

*caches : institution(대부분 전용회선 통해서 인터넷 연결,  왔다갔다하는 traffic 많으면 굵은 거 사야됨 but 전용회선 비쌈)이 자신의 local site에 둠 ->웹 캐시에 있는 웹페이지는 바로바로 줌 > 왔다갔다 하는 거 줄여서 값 절약, 빠름 (origin server까지 안 가고 local site에서 web cache 가져올 수 있음.)

 

*last modified, if modified since, not modified >> web cache 위해 사용

• 목표: 원본 서버의 개입 없이 클라이언트 요청 충족
• 사용자가 웹 캐시 가리키도록 브라우저 구성
• 브라우저가 모든 HTTP request 요청을 캐시로 전송
  • 캐시에 object가 있는 경우: 캐시가 object를 client에 반환 (Or, 캐시는 원본 서버에서 object요청, 수신된 object 캐시한다음 object client에 반환)

[

[More about Web caching]

• 웹캐시는 클라이언트와 서버 역할 모두 수행 (original 요청 클라이언트를 위한 서버, origin 서버에 대한 클라이언트)
• 일반적으로 캐시는 ISP(대학, 회사, 주거용 ISP)에서 설치

 

• 웹 캐싱의 장점 : 클라이언트 요청에 대한 응답시간 단축(캐시가 클라이언트와 더 가까움), 기관의 access link의 traffic 줄임, 인터넷의 전체 성능 향상, 캐시가 밀집한 인터넷-poor(powerful server가 global하게 퍼져있지 않음: 기관들이 웹캐시 많이 설치해서 콘텐츠 popular) 콘텐츠 제공자가 보다 효과적으로 콘텐츠 제공 가능 (P2P 파일 공유도 마찬가지)
• 웹 캐싱의 단점: 캐시 불일치- original server의 웹페이지:내용변경가능 VS 현재 webpage에 inconsistent 발생가능

[Caching Example]

[계산]

LAN의 이용: 0.0015(0.15%) = 브라우저의 평균 데이터속도/LAN의 총바이트수= 1.5Mbps/1000Mbps
Access link 활용(traffic 강도와 똑같은 방식으로 계산-delay 0.7넘어가면 급속도 증가. delay엄청나게 길어서 webpage가져오는 데 few mimutes 걸릴수도 있음)= 0.97 (97%) = (액세스 링크를 통해 브라우저에 전송되는 데이터 속도)/(액세스 링크 전송 속도) = 1.5 Mbps / 1.54 Mbps

end-to-end delay=인터넷 delay(대부분의 경우 2s)+ 액세스 링크 delay(얼마나 걸릴지 모름. few minute)+ Lan delay(거의 없음-microsecond- Lan 안에서 utilization이 0.0015이기 때문에)

 

*활용도 높을수록 delay 커짐!

 

• 해결책 1 : 빠른 access link 구매( access link 속도 100배 늘리기)- 값 비쌈(100배로 비싸짐)
• 해결책 2 : web cache 설치-값 저렴

cache hit 40% -> 40%의 requests가 cache에서 만족

cache miss 60% -> 60%의 requests가 origin에서 만족 - access link 사용 

>> Total delay : 0.6 * (origin servers의 delay(end-to-end delay) + 0.4 * (cache에서 만족됐을 때의 delay) = 0.6(2.01) + 0.4(~msecs)=~1.2secs >> 값싼 webcache가 들어와서 평균응답시간 줄여줌 (but inconsistency 해결해야함)

 

Conditional GET

목표: 캐시에 최신 캐시 버전이 있는 경우 서버는 object 전송하지 않기 -> object transmission delay x, 링크 사용률 감소

cache(의 inconsistency 해결: last modified, If-modified since, not modified) -용량 매우 낮아서 utility에 영향 x: http 요청에서 캐시한 사본의 지정 날짜, If- modified-since: <date> server : 캐시된 복사본이 최신 상태인 경우 응답은 객체를 포함하지 않음. 304 Not Modified (실제로 webpage 안 실어서 보냄)

HTTP/2

• 주요 목표: multi-object  HTTP 요청의 지연 감소

 

• HTTP1.1: 단일 TCP 연결 통한 Multiple 파이프라인 GET 도입, 1.0보다 method 종류 많음(새로운 내용 upload, delete 가능) -단일 TCP연결 통한 다중 파이프라인 GET 도입 . 서버는 GET 요청에 순서대로(get request가 온 순서대로 object를 그대로 보내줌) 응답.[FCFS: 선착순 스케줄링-작은 개체는 큰 개체 뒤에서 전송 기다려야 함.(Head Of Line-큰 object가 먼저 가서 막혀버리면 작은 object 여러 개가 기다려야 함. 차단)] , 손실 복구(손실된 TCP segment 재전송)> object 전송 지연

>> HTTP 2: 서버에서 클라이언트로 객체 전송할 때 유연성 향상.

* HOL 해결: object를 단위 크기인 frame으로 자름 > persistant request에서 object 연속으로 쭉 들어옴 > request에서 요구하는 object들을 round robin(프로세스 사이에 우선순위 두지 않고 순서대로 시간단위 CPU 할당하는 방식)으로 번갈아가면서 보냄.

-메소드, 상태코드, 대부분의 헤더 필드가 HTTP 1.1에서 변경 X. client-specified object priority(request에 priority 명시했다면 priority 따라서 보내줌(선착순일 필요 x)

-요청되지 않은 object client에 push.

-object를 frame으로 나누고 HOL 차단 완화하기 위해 frame 예약

* HTTP 2 mitigating HOL blocking: HTTP 1.1에서 client는 1개의 large object 요청. HTTP2에서 object는 frame으로 나눠져서 frame을 번갈아가며 섞어 전송

 

HTTP 2에서 HTTP3으로

- Key goal : multi-object HTTP 요청 delay 감소

- 단일 TCP connection을 통한 HTTP2의 의미: 패킷 손실로부터의 복구는 여전히 모든 object 전송 지연(HTTP 1.1과 마찬가지로 브라우저는 지연 감소와 전체 처리량 증가를 위한 multiple 병렬 TCP 연결을 가질 보상 O) , vanilla TCP connection에 대한 보안 x - socket에 데이터 집어넣을 때 incrute x -> 보안문제

HTTP3 : UDP통해 object 별 오류 및 혼잡 제어(더 많은 파이프라이닝)을 위한 보안 추가, 전송

ㄴ전송계층의 HTTP 3에 대한 자세한 내용 : 보안 추가, TCP 대신 UDP(오류제한 x, reliable x-보안하기 위해 HTTP 자체에서 오류검증) 사용 -> 각 object 독립적으로(병렬 사용했을때처럼 pipeline 더 강력하게) 내보냄

2.3 인터넷 전자메일

세가지 주요 구성요소:

• mail user agent(MUA)- 이메일 메시지 작성, MTA로 전송, outlook iphone 메일 클라이언트, web 기반 MUA (ex. gmail.com, outlook.com)에서 email 검색 
• mail servers or mail transfer agent(MTA) : 서버에 저장된 발신, 수신 메시지/ 이메일 전송(송신/수신)
• simple mail transfer protocol : SMTP 

메일 서버 :

mailbox: 사용자에 대한 수신 메시지 포함.  발신 메일 메시지의 message queue, 이메일 메시지를 보내기 위한 mail server간의 SMTP 프로토콜(SMTP client :sending mail server, SMTP server: receiving mail server)

SMTP: TCP를 사용(HTTP 2까지)하여(TCP에게 전송 부탁) 클라이언트에서 서버로 이메일 메시지 안정적으로 전송, port 25, HTTP는 80.

• 직접전송 : sending 서버에서 receiving 서버까지 중간 이메일 서버 없이 직접 전송. -end-to-end direct. 
• 3단계 전송 : 1. handshaking(인사) 2. message 전송 3. 종료
• 명령/응답 상호작용(HTTP처럼) : 명령-ASCll 문자 , 응답- 상태 code 및 문구 (메시지는7bit ASCll 여야 함)
• 시나리오: 1. 앨리스가 UA 사용해서 to msg 작성(밥의 메일로-domain name: 인간을 위해 IP주소대신 사용) 2. 앨리스의 UA가 자신의 메일서버(캠퍼스에 있음)로 메시지 보내고 메시지는 메시지큐에 배치됨 3. SMTP의 클라이언트 측이 밥의 메일서버와 TCP연결 엶 4.SMTP 클라이언트가 TCP연결 통해 앨리스의 메시지 보냄 5. 밥 메일서버가 밥 메일함에 메시지 배치 6. 밥이 자신의 사용자 에이전트 호출하여 메시지 읽음
•  

 

Q. 밥의 UA는 밥의 받은 편지함에 접근하기 위해 SMTP를 사용하나요? (SMTP는 PUSH 프로토콜)

A. 아뇨. msg를 push하는 것이 아닌 pull하는 것이기 때문에 별도 프로토콜 필요)

Q. 앨리스의 UA가 밥의 메일 서버로 이메일 직접 보내지 않고, 앨리스의 메일서버 거치는 이유? (밥의 메일 서버에 장애가 발생할수도 !)

A.바로 인터넷 꺼버리면 msg 증발 가능, 내 mail server -> 상대방 mail server 갈 때까지 delivery 계속 try해야 함. 

Q. 밥의 메일 서버에 대한 DNS(도메인 주소>IP주소 번역) 확인은 누가 하나요?(앨리스의 UA? 아니면 앨리스의 메일서버?)

A. 앨리스의 UA 가 함-UA가 서버로 보내기 전에 도메인 IP주소를 번역해서 보내줌 -> 메시지 큐로 들어간 애들은 다 IP주소로 돼 있음, 동일한 IP주소로 가는 애 많음-> TCP  connection 맺은 후 하나씩 다 보내줌.

 

SMTP	HTTP
push 프로토콜(보내는 메일 서버가 TCP 연결 시작하여 받는 메일 서버에 데이터 PUSH)	pull 프로토콜(클라이언트가 TCP 연결 시작하여 서버에서 사용 가능한 정보 가져옴)
persistent 연결 - message 계속 보낼 수 있음	HTTP는 persistent 연결, non-persistent 연결 둘 다 사용 가능
기본적으로 port 25	기본적으로 port 80 - 유명한 application 지원해야 하기 때문에 well known이어야 함, client가 누구라도 contect 가능하게.
바이너리 멀티미디어 데이터를 7bit ASCll로 인코딩해야 함(받는쪽에서 다시 decoding)	바이너리 멀티미디어 데이터를  7bit ASCll로 인코딩할 필요 없음.
모든 object를 단일메시지에 넣음(1개의 msg에 여러 object O)	각 object를 자체 HTTP 메시지에 배치(object별로 별도의 HTTP 메시지 사용해서 보냄)

 

[메일 액세스 프로토콜]

• SMTP (얘도 프로토콜) : 수신자의 서버로부터 배달, 저장
• 메일 액세스 프로토콜 : 서버로부터 검색
  • POP (post office protocal): 인증, 다운로드
  • IMAP(internet mail process protocal) : 서버에 저장된 메시지 조작을 포함한 추가기능-mail box에 폴더 만들고 메시지 보관할 수 있게 함.
  • HTTP: gmail, hotmail, yahoo!, mail... -receive server로부터 밥이 자신의 메일 pull할 때 HTTP 사용.

[ POP3 protocol ]

 

 

1. 인증단계( mail server가 client의 username이나 password 확인 -> 인증끝) : 클라이언트 명령 (user: 사용자이름 선언, pass: 비밀번호) -> 서버응답(+OK, -ERR)

 

 

2. transaction 단계

클라이언트 : list - 메시지번호 리스트매김, retr: 번호로 메시지 검색, dele : 삭제, quit

 

 

 

 

 

 

 

ㄴ

• POP3 : "download and delete" 모드 사용 - 밥은 그가 client 바꾸면 email을 다시 읽을 수 x "download and keep" 모드 사용하면 다른 클라이언트에 메시지 사본 보관 -> 내 메시지가 이 컴퓨터 저 컴퓨터에 분산돼있어서 읽어간 메시지 또 읽어갔는지 모름(그 전 세션에서 무슨 일 했는지 몰라서-stateless)
  • 밥의 user agent가 다운로드-> delete모드로 동작
  • 서버에서는 밥의 메시지 1,2가 다 사라지고 없음(밥의 컴퓨터로 다 들어옴)-> 다시 pop3로 학교메일서버 연결해서 list 해보면 남아있지 x.
• IMAP: 모든 메시지를 한 공간(서버)에만 보관, 유저가 폴더에서 메시지 정리 허용, 여러 세션에 걸쳐 사용자 상태 유지> 폴더 이름 및 메시지 ID와 폴더 이름 간 매핑(어떤 작업 했는지 기억 O

 

2.4 DNS: 인터넷의 디렉터리 서비스

• DNS: 도메인 네임 시스템
• Internet hosts, routers의 식별자:
  • IP adress(32bit) : 데이터그램 주소지정에 사용 (주민번호같은거임!) - 실제로 delievery 일어날 때 찾아가기 위해 IP주소 사용)
  • name (ex. www.yahoo.com-domain name) : 사람에 의해 사용
  • Q. IP주소와 이름을 어떻게 매치시킬까?
• DNS
  • email, webpage 사용 등에 무조건 사용
  • 데이터베이스 분산 : 많은 네임서버의 계층구조로 구현. 
  • application 계층 프로토콜 : application 이라기보다는 Network core service이지만 인터넷에서는 application 계층 프로토콜로 구현(complexity는 다 edge로 몰아냄-> 서비스의 deployment가 용이) 호스트, 네임서버가 통신하여 이름 확인(주소, 이름 변환)
    • 참고: 애플리케이션 계층 프로토콜로 구현된 핵심 인터넷 기능 - 공통적으로 필요한 service임에도 application protocal로 구현, 기관에서 내놓을 때 그대로 내놓으면 이상하니까 application protocal로 내놓음 > 네트워크의 기술적 세부사항으로만 제공되면 일반 사용자와 개발자에겐 어렵고 사용할 수 없는 형태가 됨> 애플리케이션 계층에서 다루는 프로토콜로 개발되어 사용자들이 쉽게 접근할 수 있도록 만듦
  • service:
    • hostname->IP adress 로 번역.
    • host aliasing(host 에게 짧은 대체 이름 부여)-canonical->aliasing
    • load 분배 : 복제된 웹 서버-많은 IP주소가 하나의 이름에 대응(인기있는 웹서버에 접속하려는 사용자 많을 때 server farm(여러개의 서버가 담당)에서 분배해서 나눠줌-web server 접속하려는 request 들어왔을 때 다 같은 hostname으로 들어옴(사용자에겐 동일한 web server 이름)(DNS server가 동일한 서비스 제공하는 여러 서버들에게 node 분배해줌)
      • 그러면 왜 중앙집중화하지 않는가? : 단일지점장애(host name-IP adress translation이 일어나야 그 application 동작. 하지만 하나의 server에서 다 제공하면 확장성없이 failure 발생), 트래픽양(모든 application이 이용하기 때문에), 거리도 centralized 됨(지역적으로 떨어져 있는 user 커버불가), 유지성문제
  •  DNS는 분배되고 계층적인 database이다.

 

[EXAMPLE] 클라이언트가 www.amazon.com의 의 IP주소 원할 때: 첫번째 근사치

: 클라이언트가 루트 서버를 쿼리(정보요청)> .com DNS서버를 찾음

==> .com DNS서버 쿼리>amazon.com DNS 서버 가져옴

==> 클라이언트가 amazon.com DNS서버 쿼리> www.amazon.com의 의 IP주소 얻음

 

*TLD(최상위도메인)는 끝에 붙는 .com같은건가보다. authoritative domain server가 되려면 앞에 naver이나 amazon붙여서 naver.com이나 amazon.com 

 

• DNS: root name server - 이름을 확인할 수 없는 name server의 공식적인 최후의 수단, 매우 중요한 인터넷 기능-인터넷은 이거 없으면 작동할 수 없음.
  • DNSSEC- 보안(인증 및 메시지 무결성)제공(서버 관리기관)
• ICANN-root DNS 도메인 관리
• 전 세계 13개의 논리적 root name server는 여러 번 복제됨.
• 미국은 국가최상위도메인 없이 일반 최상위도메인 바로.

TLD:

• authoritative(권한있는) servers - 일반 도메인 및 모든 최상위 국가 도메인 담당
• 네트워크 솔루션 은 .com, .net TLD에 대해 authoritative registry(특정 데이터에 대한 권위있는 정보를 제공하는 데이터베이스)
• .edu TLD를 위한 교육기관(.kr: 한국인터넷정보센터-KRNIC)

Authoritative(권한) DNS servers:

• 조직 자체 DNS 서버로, 조직의 네임드 호스트에 대한 IP mapping에 권한 있는 hostname 제공
• 조직 또는 서비스 제공자에 의해 유지관리됨.

Local DNS name servers(DNS system에 속하지 x. proxy(중개) server):

• 계층구조에 엄격하게 속하지 x,
• 각 ISP(주거용,회사,대학)에 하나씩 있음
  • 'default name server' 라고도 함-host가 default로 contact
• 호스트가 DNS쿼리를 할 때 쿼리는 local DNS server로 보내짐
• 최근 name-to-address 변환 쌍의 로컬 캐시가 있을 수 있음(오래됐을수도)-mapping 정보 caching
• proxy(caching server 처럼 각 기관별로, residential IP마다 local DNS server 두고 있음, user host 대신해서 DNS에 체계적으로 query 던져주기도 함)역할을 하며 쿼리를 계층 구조로 전달. residential ISP 밑의 host가 DNS 쿼리 발생하면 root가 아닌 local DNS name server 과 연결

• Window에서 내 DNS server의 IP주소 찾는 법? : "inconfig /all " 이나 "nslookup" 사용
• 내 hostname 찾는 방법 : "hostname"

[DNS name 확인: iterated (반복)쿼리]

*어떤 application 이름을 IP주소로 translate해야 할 때 DNS 구동 -> DNS가 DNS server로 쿼리 내보냄, 쿼리에 대해 응답 받음

• 예시 :cis.poly.edu의 호스트가 gaia.cs.umass.edu의 IP주소 원할 때
• 반복쿼리: 연락할 서버의 이름으로 응답, "이 이름 모르지만 이 서버에 문의해봐~"(책임돌리기)
• 책임회피과정 ...: IP주소 알고싶어하는 요청 호스트가 local DNS server(local site 에 있는 proxy)에 물어봄 > 자기가 캐싱하고 있으면 바로 알려주고 모르면 root에게 물어봄 > root는 TLD 알려줌 > TLD 도 모르면 authoritative DNS server 알려줌 > 답 얻어서 요청호스트에게 알려줌~~ 
• ==> 질의하는 쪽(여기에 node 많음!) 에 further 쿼리 할 수 있는 정보 주고 책임 넘김

 

 

[DNS name 확인: recursive(재귀)쿼리]

 

예시: cis.poly.edu의 호스트는 gaia.cs.umass.edu의 IP주소 원함

• 이름 resolution name의 짐을 연결된 이름서버에 놓음
• 계층 구조의 무거운 부하 수준?

 

caching, DNS record 업데이트

• 모든 name server가 mapping학습하면 mapping cache
  • 일정 시간이 지나면 캐시 항목이 타임아웃(사라짐)됨(TTL)
  • TLD server은 일반적으로 로컬 네임서버에 캐시됨( > 따라서 루트네임서버는 자주 방문하지 않음.)
• 캐시된 항목이 오래됐을 수 있음(최선을 다해 name-to-address 변환!) - time to leave 설정
  • 만약 name host가 IP주소 변경하면 모든 TTL만료될때까지 인터넷 전체에 알려지지 않을 수 있음
• 업데이트/알림 메커니즘은 IETF 표준이 제안됨- 어떤 기관에서 내 host의 매핑정보 바뀜-> 명시적으로 업데이트, notify

DNS records

DNS: resource record를 저장하는 분산데이터(계층이 있는)(RR)-4개의 특성

ㄴRR 형식: (name, value, type(name값과 value값이 무엇인지 지정), ttl(mapping정보 캐싱-> 캐싱정보가 얼마동안 유효한지)

*type field 에 따라 DNS 맵핑 다르게 해야 함

• type=A 
  • name: hostname
  • value: IP address
  • authoritative server 에 많음 (root 나 TDL 서버도 갖고있긴함)
• type=NS
  • name : domain
  • value : 이 도메인의 authoritative name server의 hostname
• type=CNAME
  • name: 진짜 name에 대한 alias name (진짜 이름과 별명 짝지음)
  • value: canonical name
• type=MX
  • value : name(domain)과 연관된 maliserver의 이름

*ROOT - TLD - authoritative - IP

 

[DNS protocol, messages]

 

DNS 쿼리와 응답메시지는 둘 다 같은 메시지 포맷 가짐.

 

• message header: 식별-쿼리의 경우 16비트 # , 쿼리에 대한 응답은 같은 # 사용 - 쿼리에 대한 응답 보낼때 똑같은 번호 적어서 보냄 -> 어느 쿼리에 대한 응답인지 맵핑할 수 있게.
• flags :
  • query or reply- 쿼리 또는 응답 (동일한 메시지 타입 사용) 
  • recursion desired -재귀 필요(쿼리 내보낼 때 재귀 가능하면 해줘!, 쿼리를 받은 서버가 자기가 책임지고 맵핑정보 알아서 대답해줌)
  • recursion available - 재귀 사용 가능 (응답 보낼 때 서버->쿼리한 client쪽으로 재귀 가능하다고 알려줌) 
  • reply is authoritative answer-응답이 권위있는 답변임

 

[DNS에 record 삽입]

예 : 신규 스타트업 "네트워크 유토피아"-email server와 web server 구입

• DNS register(ex. network solution-일반적으로 .com 담당, .com TLD마다 두가지 정보 쭉 넣어줌)에서 nu.com이라는 이름 등록 : 우리 기관 domain 담당하는 authoritative name server 이름(NS record)+IP주소
  • 이름, 권한 있는 네임서버(기본과 보조)의 IP주소 제공
  • 등록기관이 .com TLD 서버(각 기관별 authoritative server 정보 가짐)에 두 개의 RR(NS, A) 삽입 
  • IP주소 21.21.21.2 (자기 회사 담당하는 authoritative server(_IP주소저장)구비해야 함)로 로컬 권한 서버 만들기 
    • A 레코드 유형-> www.nu.com > mail sever 이름에 대한 IP주소 매핑 -> A type record 에 기록 -> 권위서버에 저장
    • MX 레코드유형-> nu.com (도메인 해당하는 authoritative server 사 놓음->회사 도메인 담당하는 mail server의 이름->MX저장->권위서버에 IP주소 저장)

[시나리오]

1. 앨리스의 호스트가 앨리스의 LDNS(local dns name system)에 DNS 쿼리를 보냅니다(4).
2. Alice의 LDNS는 .com TLD 서버에 연결합니다(5).
3. .com TLD 서버에는 등록기관이 모든 TLD com 서버에 삽입했기 때문에 네트워크 유토피아의 권한 있는 서버에 대한 NS 및 A RR 유형이 포함되어 있습니다. (2)
4. . com TLD 서버가 네트워크 유토피아에 대한 권한 있는 서버의 NS 유형과 A RR이 포함된 DNS 응답을 앨리스의 LDNS로 보냅니다(6).
5. Alice의 LDNS는 21.21.21.2(네트워크 유토피아의 권한 있는 서버의 권한 서버)에 웹 서버 http://www.nu.com 의 IP 주소를 요청합니다.  (7)
6. 네트워크 유토피아의 권한 DNS는 21.21.21.4(http://www.nu.com의 IP 주소) 를 포함하는 DNS 응답을 Alice의 LDNS로 전송합니다. (8).
7. 앨리스의 LDNS는 앨리스의 호스트에게 21.21.21.4( http://www.nu.com 의 IP 주소)를 돌려줍니다.(9)
8. 이제 Alice의 브라우저는 21.21.21.4에 대한 TCP 연결을 시작하고 HTTP 요청을 보낼 수 있습니다! (10)

 

ㄴ어우 나중에 볼래 킵!

 

 

2.5 P2P 파일 분배

[파일 배포(delay 어떻게 되나 초점): cilent-server VS P2P]_성능 비교하기

Q. 파일(size F)을 한 서버에서 N개의 호스트로 배포하는 데 걸리는 시간은?
* 호스트(peer) upload/download capacity는 제한된 resource(자원)

-중간의 core network 가 bottleneck 이 된다면 모든 capacity가 network에 의해 결정 -> 이런상황 배제하기 위해.(뭐말하려했던겨)
*정확히 비교하려면 core network 에서의 delay 무시

 

[client-server 의 파일분배시간]

• 서버 전송 : 파일 사본 N개를 순차적으로 전송(업로드)해야함 -server가 각 peer에게 하나씩 파일 업로드
  
  • 파일크기 / (server의 up link bandwidth=R bps)

• 클라이언트 : 각각 클라이언트마다 파일 사본 다운로드 해야 함
  • 파일크기 / 가장 낮은 down link bandwodth -> bottleneck

• client-server 방식을 이용해서 F를 N개의 클라이언트에게 배포하는 시간

[P2P의 파일분배시간]

• 서버전송: 사본 하나 이상 업로드해야 함(최초 transmission은 반드시 1번 일어나야 함) 
  • 하나의 사본을 보내는 시간 ; F/Us
• file copy는 server 안에 있음 -> 서버가 최소한 1번은 네트워크에 업로드 해 줘야 어느 peer가 받아서 service 참여 -> 받고 딴 peer에게 전달 (server과 peer 같이 service 에 참여)
• client or peer : file copy를 다운로드해야 함. 
  • max download time : F/dmin

 

2.6 비디오 스트리밍과 콘텐츠 분배 네트워크

[multimedia : video]

• 디지털 이미지: 픽셀배열
  • 각 픽셀을 비트단위로 표시 - 8비트의 픽셀이면 픽셀 하나가 표현할 수 있는 값이 2^8가지.(0 ~ 2^8-1)
• 비디오: 일정 속도로 표시되는 이미지 연속 ex. 초당 24개 이미지
• 코딩: 이미지 인코딩에 사용되는 비트 수 줄이기 위해 이미지 내 및 이미지 간 중복성 사용
  • > 공간코딩(이미지 내) : 같은 색의 값을 n개 보내는 대신 색상 값, 반복되는 값의 개수(n) 두 값만 보냄 > 정보양 감소
  • 시간적 코딩(한 이미지에서 다른 이미지로) : i+1에서 완전한 frame을 보내기보다는 frame 1과의 차이점(변화된 정보)만 보냄
• Streaming stored video
  • 주요 과제: server-to-client 대역폭은 네트워크 혼잡 수준(집, 액세스 네트워크, 네트워크 코어, 비디오 서버)의 변화에 따라 시간이 지남에 따라 달라진다. client 별로 deliver available정도도 다름: 거쳐오는 네트워크 경로 다름, 나의 액세스 네트워크 capacity도 다름, 액세스 네트워크 상황도 바뀜, 서버,인터넷 상황도... >> 패킷 loss와 delay로 재생이 지연되거나 비디오 품질이 저하될 수 있다.

- 이 때 클라이언트는 비디오 초반부분 재생, 서버는 비디오 후반부분 계속 전송

 

• 해결과제 : 
  • 연속 재생 제약 : 클라이언트 재생 시작되면 재생이 원본타이밍과 일치해야 하는데 네트워크 지연은 가변적 (jitter : 하나의 frame이 경험한 delay와 다음 frame이 경험한 delay가 다름) > client-side buffer로 재생요구사항 충족해야 함
  • 기타 : 클라잉언트 상호작용 : 일시정지, 빨리감기, 되감기, 동영상 건너뛰기 > 비디오 패킷 손실 or 재전송될 수 있음

-처음 버퍼링을 넣어서 delay 있어도 극복하게 만듦.

-클라이언트 측 버퍼링과 재생지연 : 네트워크 추가지연, 지연 지터 완충

 

[비디오 스트리밍과 CDNs : context]

• 스트리밍 비디오 traffic : 인터넷 대역폭의 주요 소비층
• 과제1 : 크기 (어떻게 많은 유저 받아들일것인가) - 하나의 겁나 큰 비디오서버는 소용이 없다.(왜?)
• 과제2: 다양성(서로 다른 유저는 다른 가능성을 갖고 있음)
• >>해결 : 분배, application 레벨의 인프라(구성요소)

[DASH]

• DASH: (dynamic, adaptive streaming over HTTP) -HTTP를 통한 동적 적응형 스트리밍
• client에서 많은 intellignecy 가짐. server측에서는 client가 지식 잘 활용할 수있는 준비만 해줌.
• 서버 : 
  • 2. 비디오 파일 여러 덩어리로 나눔 각 덩어리는 1.서로 다른 속도로 인코딩되어 저장-어떤 건 퀄리티 높게, 어떤 건 낮게
  • manifest(나타나다) file: 여러 덩어리에 대한 URL제공
  •  
• 클라이언트:
  • 주기적으로 서버와 클라이언트 간 대역폭 측정(지금 server로부터 나에게 오는 bandwidth가 얼마나 되는지)
  • manifest 컨설팅, 한 번에 하나의 덩어리 요청(덩어리별로 URL 제공)
  • 현재 대역폭에서 지속 가능한 최대 코딩 속도(자기에게 현재 가능한 bandwidth를 최대로 활용할 수 있는) 선택- coding rate의 덩어리를 찾아 manifiest file에서 찾아서(어느 URL에 박혀있는지) 덩어리단위로 요청
  • 유저별로 capacity 다름, 같은 user이어도 시간이 감에 따라 capacity 달라짐 -> 그럴 때 user가 자기의 available 대역폭 측정하면서 다음 덩어리 요청할 때 본인이 현재 가능한 대역폭에 맞춰서 그 코딩 속도로 encoding 된 덩어리 요청
  • 시점에 따라 다른 코딩속도 선택(시점의 사용 가능 대역폭 따라 다름)- 좋은 파일 다운로드받던 사용자가 diverse하게 받기는 힘듦
  • chunk(덩어리)로 나눈 이유 : file 통째로 하면 powerful한 client가 높은 퀄리티 제공 비디오 요청 > 시간이 가며 available 자원 변하면 첫 시점의 상황에만 맞춘 file deliver될 때 문제.
• 클라이언트의 intellegence :
  • 덩어리를 언제 요청할 건지 : 버퍼 고갈(미리 자신의 상황에 맞춰서 요청해야 함) 또는 오버플로우가 발생하지 않도록
  • 인코딩 속도를 어떻게 요청할건지 : 더 많은 대역폭을 사용할 수 있을 때 더 높은 품질
  • 어디에서 덩어리를 요청할건지 : 클라이언트와 가깝거나 사용가능대역폭이 많은 url 서버에서 요청가능 
• streaming video= encoding(파일 덩어리로 나눠서 여러가지 level 퀄리티로) + DASH(클라이언트가 dynamic adaptive 하게 요청) + playout buffering(지속적인 재생)
• 과제 ; 수백만개의 동영상에서 선택한 콘텐츠를 수십만명의 동시 사용자에게 스트리밍하는 방법?
  
  • obtion 1 : 단일 대형 유지되는  "mega-server"
    • 단일장애지점 - 한번 업데이트나 유지 하려하면 전체가 shut down
    • 네트워크 혼잡지점 - 서버에서는 어마어마한 사용자에게 reach 하기 위해 많은 video traffic이 나가야 함
    • 멀리 떨어진 클라이언트에 대한 긴 경로-클라이언트 입장에서 나에게서부터 너무 멀리 있음
    • 발신 링크를 통해 전송되는 여러 개의 비디오 사본-local한 지역에 있는 2명의 클라이언트가 동일한 시간에 동일한 비디오 요구 , 하지만 메가서버는 처음부터 2개의 part 내보내야 함 -> 확장성 x
    • 결론 : 확장성 없음~탈락 ! 
  • obtion 2: 콘텐츠 배포 네트워크 (CDNs_content distribution networks))-지리적으로 분산된 여러 사이트(CDN)에 여러 개의 동영상 사본을 저장/제공함
    
    • 깊이 들어가기 : CDN 서버를 여러 액세스 네트워크에 깊숙히 밀어 넣음-네트워크 개수 어마어마하게 많으므로 CDN 서버의 개수도 매우 많음.
      •  사용자와 가까운 위치
      • Akamai 사용 : 120개국 이상에 배치된 240,000대의 서버(2015년)-유지 힘듦
    • 집으로 가져오기 : 소규모(10대)의 대규모 cluster(여러 대의 서버를 묶어서 하나의 시스템처럼 운영하는 것)들을 접속 네트워크 근처(접속 네트워크 내에는 없음)의 POP(point of presence)에 배치 - 접속 네트워크가 자기에게 해당하는 ISP(인터넷 access 서비스 제공)에 접속할 때 붙는 route group
      • Limelight에 의해 사용
    • 서비스로서의 internet host-host communication (자신의 content제공)
    • OTT(over the top)전 세계에 CDN server을 두고) 과제  : 혼잡한 인터넷에 대처하기
      • 어느 CDN 노드에서 콘텐츠를 검색할 것인가? 
      • 혼잡 시 시청자 행동은?
      • 어떤 콘텐츠를 어떤 CDN 노드에 배치할 것인가?(각 나라마다 content 다르게 배치)
    • CDN : CDN 노드에 콘텐츠 사본 저장 ex. 넷플릭스는 매드맨의 사본 저장
    • 구독자가 CDN에 콘텐츠 요청 -> 가까운 사본으로 이동하여 콘텐츠 검색, 네트워크 경로 혼잡할 경우 다른 사본을 선택할 수 있음. (content 제공자의 website에 들어가서 요청 : 거기에 대한 manifest 파일 옴 -> 나의 host에 돌아가고 있는 client가 그 manifest 파일 참고해서 적절한 CDN 서버로부터 내가 필요한 content 갖고 옴.)

 

 

(1) Bob이 영화보려고 netcinema.com에 영화 파일 주소를 요청함. netcinema.com/@#R*@#에)(url:hostname/filename)에 있다고 답변

(2) Bob의 Local DNS(LDNS)에게 파일 주소(url)인 netcinema.com/@#R*@#에)를 요청.

(3) LDNS는 .com DNS 서버에게 요청. .com은 netcinema.com의 Authoratative DNS Server의 hostname을 답변. Authoratative DNS Server는 KingCDN.com/23483r29를 답변 (CNAME)

(4) 해당 도메인을 관장하는 DNS 서버에게 다시 요청. KingCDN.com의 주소를 받음

(5) LDNS가 해당 주소를 Bob에게 돌려줌

video는 HTTP를 이용해 KingCDN.com에서 오더라.

⇒ CNAME을 이용한 DNS redirection을 통해 server distribution

 

• 사례연구 : 넷플릭스
  • 넷플릭스 웹사이트 : 사용자 등록 및 로그인, 청구, 영화 목록 탐색 및 검색
  • 아마존 클라우드 : 웹사이트 실행, 콘텐츠 수집: 영화 최종편집본 받아온 후 자신의 클라우드에 업로드, 콘텐츠 처리: 다양한 클라이언트 비디오 플레이어에 적합한 다양한 형식과 각 형식에 대한 여러 비트 전송률로 다양한 버전 생성(chunk를 나누고 chunk를 여러 encoding rate로 encoding)
  • private CDN 인프라 : 200개 이상의 IXP위치 및 ISP 파트너에 서버 rack(ex. 넷플릭스 서버 렉)설치. 사용량이 많지 않은 시간에 동영상을 CDN으로 push(인기있을거같은거, 인기있는 거. own CDN 갖고 있지 않으면 어려움). 사용자를 CDN 서버로 연결하기 위해 DNS 사용할 필요 X.
  • 버전 업로드 CDN(진행된 비디오 다 업로드) 
    • Bob이 넷플릭스의 영화를 보려고 함 
      • (1) Bob은 Netflix 계정을 관리하는 서버에 접속, 인증
      • (2) (3) Bob은 Netflix가 대여한 Amazon cloud에서 Manifest file을 받아옴
      • (4) DASH streaming. 가장 가까운 CDN server들에서 영화 streaming
    • Push Caching 사용

 

2.7 소켓 프로그래밍: 네트워크 애플리케이션 생성

• 목표: 소켓을 사용하여 통신하는 클라이언트/서버 애플리케이션을 구축하는 방법 배우기
• 소켓 : 애플리케이션 프로세스와 종단 간 전송 프로토콜 사이의 문

 

• 두가지 전송 서비스를 위한 두가지 소켓 유형
  • UDP : 신뢰할 수 없는 데이터그램 - application에서 메시지 내려보내면 메시지 boundary 인식, 하나의 UDP segment로 만들어서 deliever
  • TCP : 안정적인 byte steram-oriented - application에서 내려보낸 메시지의 boundary 인식 못함 -> 메시지를 TCP 버퍼에 받아서 버퍼에서 적당한 양을 떠서 TCP segment를 만들어서 쭉 보내줌.

UDP 를 사용한 socket programming

• 클라이언트와 서버 간 연결 없음
• 데이터 전송 전 handshaking x
• 송신자는 각 패킷에 IP대상 주소, port번호 명시적으로 첨부
• 수신자는 수신된 패킷에서 발신자 주소, 포트번호 추출

• 전송된 데이터 손실되거나 정상적으로 수신되지 않을 수 있음
• application 관점 : UDP는 클라이언트와 서버 간 신뢰할 수 없는 bytes의 그룹('datagrams') 전송 제공

• client/server socket interaction : UDP

또 다른 UDP 연결을 위해 UDP 서버소켓 닫지 않고 기다림, connection 별도로 맺지 않기 떄문에 connection setup과정 필요 x, port번호 항상 들고있어야 하고 server은 port닫지 않음.

 

-client 먼저 본다고 client가 먼저 socket만들어서 running 하고 있는 거 x, server가 running하고 있어야 함.

 

TCP를 활용한 socket programming

• 클라이언트가 서버와 연결돼야 함
  • 서버프로세스가 먼저 실행중이어야 함
  • 서버가 클라이언트의 contact를 환영하는 socket(door) 생성해야 함.
• 클라이언트는 다음을 통해 서버와 접속
  • TCP socket 생성, 서버 프로세스의 IP주소, port 번호 지정
  • 클라이언트가 socket 생성할 때 : 클라이언트 TCP가 서버 TCP에 연결 설정(welcome socket)
• 클라이언트와 연결됐을 때, 서버 TCP는 그 특정 클라이언트와 통신할 수 있도록 서버 프로세스에 대한 새 socket을 만든다.
  • 서버가 여러 클라이언트와 통신할 수 있도록 허용
  • 클라이언트를 구분하는 데 사용되는 source port 번호
• 애플리케이션 관점 : TCP는 클라이언트와 서버 간에 안정적인(reliable), 정렬된(in-order) bite stream 전송("pipe") 제공 , 각 클라이언트별로 별도의 응대하는 socket 만들어줌 -> 동시에 여러 client와 얘기하고 있을 수 있음(동시에 여러 cilent mapping 가능)
  • * TCP connection 만들어진 후에는 목적지 주소 안 달아도 됨.
• door socket과 dedicated된 socket 두 가지를 열고 관리→ socket이 dedicated 되었기 때문에 end가 port 번호를 함께 전송할 필요 없음  
  • • dedicated 된 socket을 생성하고 여는 과정이 UDP에는 없는 TCP connection setup 과정, connection이 끝나면 close

TCP vs UDP 소켓 프로그래밍 비교

          특징                                         TCP                                                                     UDP

연결 방식	연결 지향 (3-way 핸드셰이크)	비연결 지향 (연결 없이 바로 데이터 전송)
데이터 신뢰성	신뢰성 보장 (데이터 손실 시 재전송)	신뢰성 보장하지 않음 (패킷 손실, 순서 변경 가능)
속도	느림 (연결 설정, 흐름 제어 등 오버헤드)	빠름 (연결 설정 및 재전송 없음)
사용 예시	웹 브라우징, 파일 전송, 이메일	실시간 스트리밍, 온라인 게임, VoIP
통신 방식	양방향 통신 가능	주로 일방향 통신 (멀티캐스트, 브로드캐스트 지원)

 

+데이터 전송방식  :

• TCP-연속적인 스트림(byte흐름)으로 전송- > 수신자가 스트림의 시작부터 순서대로 데이터 받아야 함. 데이터 경계 유지하지 않으며 보낸 패킷의 크기나 경계는 중요하지 않음.
• UDP - 데이터를 개별 데이터그램으로 전송하고 각 데이터그램은 독립적이며, 수신자는 보낸 데이터그램 하나하나를 별도로 처리. 데이터는 송신된 그대로 하나의 데이터그램으로 수신되며 데이터 경계가 명확

+네트워크 상에서 서버를 식별하는 방식의 차이:

• TCP는 연결 설정과 신뢰성이 중요하기 때문에, 호스트 이름을 사용해 DNS를 통해 IP 주소로 변환하여 서버에 연결하는 방식이 더 일반적이야. 사용자는 호스트 이름으로 기억하고 접근할 수 있기 때문에, 웹 서비스나 대규모 서버 기반 애플리케이션에서 많이 사용돼.
• UDP는 빠르고 간단한 데이터 전송이 중요하며, DNS 조회로 인한 추가 지연이 없는 것이 더 유리해. 따라서 실시간 애플리케이션이나 단순한 데이터그램 전송의 경우, 직접 IP 주소를 사용하는 경향이 더 강해.

결론적으로, TCP와 UDP 모두 IP 주소와 호스트 이름을 사용할 수 있지만, 각 프로토콜의 사용 목적과 네트워크 특성에 따라 더 자주 사용되는 방식이 달라지는 거야.

 

[ chap 2 summary ]

• 애플리케이션 서비스 요구사항: 애플리케이션의 종류에 따라 달라짐, transport에 요구 (reliability, bandwidth, delay, security)
• TCP, UDP는 위 서비스 요구사항 중 reliability 에 대해서만 차별점
•  전통적인 protocol 모델 , client-server model  
  • HTTP, HTTP/2 
  • SMTP( 이메일 전송을 담당하는 프로토콜 ),IMAP( 이메일 읽기 및 관리를 담당하는 프로토콜. 여러 장치에서 이메일 관리하기에 적합->이메일을 서버에 저장하고 클라이언트가 이메일 상태와 서버 동기화 한다는 점에서 한 장치에서 관리함에 적합한 POP3(이메일을 클라이언트로 다운로드하고 서버에서 삭제)와 구분됨. ) 
  • DNS 

비디오 스트리밍 ; CDN(여러지역에 분산된 server ->콘텐츠 전 세계 사용자에게 빠르고 안정적으로 배포하기 위한 네트워크 인프라), DASH(네트워크 상태에 맞춰 비디오 스트리밍의 화질과 전송속도 동적 조정)