고정 헤더 영역
상세 컨텐츠
본문
c2.1 principles of network applications
Some network apps
Creating a network app
Application architectures
Client-Server architecture
P2P architecture
Processes communicating
Sockets
Addressing processes
App-layter protocol defines
What transport service does an app need?
Transprot service requirements: common apps
Internet transport protocols services
Internet apps: application, transport protocols
Securing TCP
2.2 Web and HTTP
Web and HTTP
web page consists of objects(text, gif, form, script, audio, video) 여러 개의 object들이 하나의 웹 페이지를 구성
object = HTML file, JPEG image, Java applet, audio file,...
웹 페이지는 여러 referenced(참조) objects를 포함하는 base HTML-file로 구성됩니다.
어떻게 식별?
인터넷 주소창에 우리가 주소를 입력하면 어떤 웹 서버에 어떤 object를 내가 지금 필요로 한다는 것을 웹 서버에 알려줄 수 있음 = url
URL : 인터넷 주소창에 쓰는 주소의 공식적인 이름 = host name + path name
인터넷 주소를 보면 http:// host name + path name
host name : 웹 서버의 이름 port 번호가 필요. 일반적으로 웹 서버의 경우 80번을 쓰기 때문에(default 80) 굳이 쓰지 않음 그 외의 다른 것들은 host name:8080 (:숫자 콜론+숫자) 쓰여 있음 웹 서버가 port number 80번을 쓰지 않는 경우에 어떤 port number를 쓰고 있는지 알려줌
** ip 주소에 해당 port 번호 = process 식별하기 위한 번호 **
path name : 내가 어떠한 object가 필요한지 someDepth 디렉터리 밑 pic.gif 그림 파일을 필요로 한다는 것을 웹 서버에 알려줌 웹서버가 파일 자체를 웹 브라우저에 전달
HTTP overview
HTTP: Hypertext transfer protocol
- Web의 application 계층 프로토콜
- Client - Server 모델
client : Web objects를 요청, 수신(HTTP 프로토콜 사용) 및 "표시"하는 브라우저
server : 웹 서버는 요청(req)에 대한 응답(rsp)으로 (HTTP 프로토콜을 사용하여) objects를 보낸다
request : 어떤 object 필요해!!
response : 필요한 object를 브라우저에 넘겨줌
** Client의 os가 사용자가 브라우저를 쓸때마다 port number를 다를 값으로 랜덤하게 할당을 해준다 ( Server의 port number는 일정 )
이때 변한 port number를 Server가 어떻게 아느냐?(응답하기 위해서는 server가 client의 port number를 알아야 함)
Client- Sever 모델로 구성 -> 처음에 무조건 Client가 Server에게 request를 보내야 Server가 response 하는 순서 그렇기 때문에 Server가 request를 보낼 때 > 목적지 ip + 목적지 port number + 자신의 ip + 자신의 port number 같이 request로 줌 (Server가 Client의 ip, port number를 알 수 있도록) **
HTTP overview (continued)
http - 하부에 수송 계층으로 TCP 사용
Client - Server > TCP 연결
use TCP:
- Client는 Server, port 80에 대한 TCP connection(socket 생성)을 시작
- 서버는 클라이언트의 TCP 연결을 수락
- 브라우저(HTTP Client)와 웹 서버(HTTP Server) 간에 교환되는 HTTP 메시지(Application layer protocol message
- TCP connection 해지
HTTP is "stateless"
- Server는 과거 Client 요청에 대한 정보를 유지하지 않습니다.
** stateless VS stateful
첫번째 연결해서 정보를 주고 받았는데 그 다음에 바로 연결을 한다고 해도 Server가 이전에 나에게 연결했던 Server이고 무엇을 가져갔는지 기억을 안함 항상 새로운 Server로 처리 = stateless
상태를 기억하고 있으면 stateful **
* aside
"state"를 유지하는 프로토콜은 복잡함
HTTP connections
HTTP connections는 두가지가 있음 1. non-persistent HTTP 2. persistent HTTP 차이 > object를 몇 개 보낼 수 있는가
non-persistent HTTP
- TCP 연결을 통해 최대 1개 object 전송
connection then closed 1
** 처음에 Client가 Server에 접속을 하면 하나의 object만이 접속을 통해서 Server로부터 Client에 전달됨
object를 여러개(n개) 갖고 싶다 = n번 * (연결 -> req -> rsp -> 해지) **
- object n개 다운로드하려면 n번 연결이 필요
persistent HTTP
- connection 하나 맺으면 다수의 object를 받고 마지막에 connection을 끊는 방식
** 내가 받아야 할 object의 개수가 많으면 많을수록 non-persistent보다 persistent가 효율적 **
Non-persistent HTTP
contains text, references to 10 jpeg images
1 a. host name 80 접속 시도 (e.g., 식당 예약)
1 b. server 연결 수락 (자리 있으면 수락 없으면 거절)
2/3. server는 request를 보고 client가 무엇을 원하는지 알게 되고 요청 받은 object를 전송
4. 전송되면 연결 해지
5. client 원하는 file 받음
6. 1-5번 과정 10번 반복
> non-persistent HTTP
Non-persistent HTTP: response time
RTT : small packet이 Client에서 Server로 이동하는 데 걸리는 시간
왕복 시간 = RTT
TCP 연결
RTT = 왕복시간
연결 요청 > 연결 수락 > request > response > ....
연결 요청 ~ 연결 수락 : RTT
request ~ response : RTT
time to transmit file - 응답 메시지 뿐만 아니라 요청한 file도 전달되기 때문에 시간이 좀더 걸린다를 표현하기 위해서 굵은 선
HTTP response time:
- TCP 연결을 시작하기 위한 하나의 RTT
- HTTP 요청에 대한 하나의 RTT 및 반환할 HTTP 응답의 처음 몇 바이트
- 파일 전송 시간
- non-persistent HTTP response time = 2RTT + file transmission time (2번의 왕복시간 + 내가 원하는 object를 받기까지 걸리는 시간 file received)
Persistent HTTP
non-persistent HTTP issues: > object마다 2RTT
- requires 2 RTTS per objects (최대 1개의 object를 rsp할 수 있음)
- 각 TCP 연결에 대한 OS 오버헤드 ** TCP connection을 맺고 끊는데 overhead **
- 브라우저는 referenced objects를 가져오기 위해 종종 fetch(병렬) TCP connection을 연다
persistent HTTP: > objects가 많을수록 효율적
- Server는 response을 보낸 후 연결을 열어둠 (한번 rsp 했다고 close하지 않음 > 여러개의 object를 보낼수 있음)
- open connection을 통해 전송된 동일한 Client/Server 간의 후속 HTTP 메시지
- Client는 referenced objects를 만나자마자 요청(req)을 보냅니다.
- 모든 referenced objects에 대해 최소 하나의 RTT
HTTP request message
- two types of HTTP messages : request, response
- HTTP request message: ASCII (human-readable format)
** Client와 Server가 주고 받는 것은 http 입장에서 두가지 > request, response
message type도 request와 response 두 가지로 구분해서 설명 **
request line > GET POST ...
header lines : Server와 내용 공유할 때 쓰는 부분
carriage return character = cr
line-feed character = lf
HTTP/1.1 버전 (1.0 버전도 있음)
Accpet-Language 영어로 인코딩을 어떻게 해야하는지 써있음
HTTP request message: general format
Request 부분
request line + header lines = header 부분
entity body = body 부분
| H | P(M) |
Header 부분에 request line과 header lines가 들어가고 Payload(Message) 부분에 entity body가 들어간다
Header 그리고 Payload를 구분하는 방법은 cr lf
** 구분자 sp = space
동일한 request line에서 character가 쭉 오다가 빈칸이 오게 되면 여기서 method 부분이 끝났구나 space 다음에 오는 문자들은 url에 포함 다음 space까지 그 다음엔 version이 온다
request line = 한 줄 구성 **
** header field name 한 칸 띄고 header field name에 해당되는 값이 온다(value) header field들을 구분하기 위해서 host라는 header user-agent/accept .... 전부 다 header field에 이름을 나타냄 그거에 대한 값을 한 칸 띄우고 쓰게 되어 있음 첫번째 header field와 두번째 header field를 구분하기 위해서 header field가 끝날 때마다 \r\n 각각의 field들을 구분한 header 부분과 payload(message) 부분을 어떻게 구분할 것인가? 마찬가지로 header lines 맨 마지막에 \r\n을 한번 더 씀 cr lf가 두 번 오게 되면 header line이 끝난 것 그 다음부터는 body 부분 **
Uploading form input
** 보통 정보를 수동적으로 받음(Client) 그러나 Server 쪽으로 전송하기도 함 e.g., 내용 입력 **
POST method:
- web page often includes form inout
- input is uploaded to server in entity body
** entity body에 내가 전달할 내용을 써서 전체 전송 method 부분에 post **
URL method:
- uses GET method
- input is uploaded in URL field of request line:
www.~~~/~~?~~&~~ > 어떤 이름에 대한 값으로 내가 무엇을 쓰겠다 라는 것 ?와 &도 구분해서 전달
> get method를 써서 어떠한 정보를 요청한다고 유추할 수 있음
Method types
HTTP/1.0
- GET
- POST
- HEAD
HTTP/1.1
- GET, POST, HEAD
- PUT
- DELETE
HTTP response message
Repsone 부분
Server -> Client
- status line
HTTP/1.1 : 첫번째 protocol version
200 : status code
OK : status pharse
- header lines (앞에서 보았던 request message의 header lines와 가지고 있는 field의 내용이 유사 서로 간의 정보를 공유하기 위해서 씀)
Server : 언제 object가 modified 되었는지 쓰여있음
Content-Length : content = data의 size가 얼마인지
Content-Type : html, Client의 browser는 data를 ISO-8859-1의 charset으로 해석 해야되는 것을 알 수 있음 > 글자 깨지지 않게
- data
data는 실제로 Client가 요청했던 object
있으면 보내고 없으면 안 보냄
HTTP response status codes
200 OK - request 성공 요청한 object가 message(header lines 뒤 data 부분)에 있다
301 Moved Permanetly - ERROR
400 Bad Request - ERROR message 이해 못함 = 버전이 맞지 않기 때문
404 Not Found - ERROR Client가 요구한 document(object)가 이 Server에 없음
505 HTTP Version Not Supported - ERROR
Trying out HTTP (client side) for yourself
User-server state: cookies
Cookies: keeping "status" (cont.)
Cookies (continued)
Web caches (proxy server)
More about Web caching
Caching example
Caching example: fatter access link
Caching example: install local cache
Caching example: install local cache
Conditional GET
2.3 electronic mail - SMTP, POP3, IMAP
2.4 DNS
2.5 P2P applications
Pure P2P architecture
2.2 ~ 2.4까지 모두 Client-Server model에 대해서 배웠다 이번에 배울건 P2P model
- Client-Server model은 always-on server였던 반면에 P2P model은 no always-on server 서버에 항상 상주하고 있지 않다
- arbitrary end systems directly communicate = 임의의 end system 직접 통신
직접적으로 통신하는 end system을 peer 라고 부른다
컴퓨터와 컴퓨터가 서버 없이 직접 통신
- peer가 간헐적으로 연결되어 IP 주소를 변경합니다.
examples:
- file distribution (BitTorrent)
- Streaming (KanKan)
- VoIP (Skype)
한 서버에서 N 피어로 파일(크기 F 비트)을 배포하는 데 걸리는 시간은 얼마입니까?
File distribution: Client-Server vs P2P
- peer upload/download capacity is limited resource
(upload 속도 : 컴퓨터에서 네트워크로 데이터를 보내는 속도 u
download 속도 : 컴퓨터가 인터넷으로부터 데이터를 받아오는 속도 d)
- 가정
- Internet core has abundant resources (i.e., only a network edge is a bottleneck) 병목현상 access link에서만 발생
대역폭은 충분히 커서 병목현상 없음
- All DL and UL bandwidth are used only for this file distribution 모든 컴퓨터에서 동작하고 있는 UL DL는 file 전송에만 사용(가정)
File distribution time: Client-Server
- server transmission: must sequentially send (uplaod) N file copies:
서버 전송: N개의 파일 사본을 순차적으로 보내야 합니다(업로드):
- Client: each client must download file copy
클라이언트: 각 클라이언트는 파일 사본을 다운로드해야 합니다.
d min : min 작은 값이 가장 늦게 받음
N : peer의 개수 -> peer의 개수가 증가할수록 D의 값이 선형적으로 증가
F/us : 고정된 상수값
고정된 상수값
File distribution time: P2P
- server transmission: must upload at least one copy
Server 전송 : 최소 1개 복사본 업로드
1개 file 보내는 시간
- Client: each client must download file copy
각 Client는 file을 다운로드 해야 한다 여러 Client 중 File size가 F인 File을 받는데 걸리는 시간
가장 큰값 (가장 작은 값으로 나눠줘서)
Clients: as aggregate must download NF bits
전체 네트워크의 upload capacity
첫번째 값, 두번째 값 : 고정된 상수 값
세번째 값 : N - peer 개수로 증가하면 선형적으로 증가
확장성을 따지기 때문에 첫번째 두번째 값은 상수이고 peer가 늘어날 때 어떤 것이 늘어날지 생각하면 세번째 값이 늘어날 것
분자에 있는 것이 선형적으로 증가
분모 값도 ui를 n까지 더할 것이니까 n이 증가하면 분모도 증가
Client-Server vs P2P: example
P2P file distribution: BitTorrent
- file은 256Kb chunks로 나뉨
- 각각의 peer들은 file chunk를 주고 받음
tracker: tracks peers participating in torrent 현재 torrent라고 하는 P2P 시스템에 들어와있는 peer들이 누구인지 계속해서 tracking 해주는 server
torrent: group of peers exchanging chunks of a file file chunks를 주고 받는 peer들의 집합
Alice라는 새로운 peer 참여
** 새로운 peer는 자기가 원하는 파일을 기존 peer들로부터 받아와야 한다 > 기존 peer들과 연결해야 됨 새로운 peer는 처음 와서 누가 있는지 모름 > tracker에게 물어본다 > tracker는 peer의 list를 알려줌(일부) > 기존 peer들과 연결 = 이웃 peer **
** 처음 참여해서 연결까지 맺었으면 현재는 chunk를 가지고 있지 않음 그렇지만 시간이 지나면 다른 peer로부터 chunk를 받아서 chunk를 쌓게 됨 각각의 peer들이 결정을 해야 되는 것은 누구한테 내가 원하는 data chunk를 요청할 것인가 누구에게 data chunk를 제공할 것인가를 결정해야 됨
BitTorrent: requesting, sending file chunks
requesting chunks:
** 어떤 시간을 보게 되면 각각의 peer들은 당연히 file chunk의 일부분을 가지고 있음
주기적으로 Alice는 각각의 peer에게 chunk list를 물어봄 리스트를 보고서 내가 필요한 것은 누가 가지고 있느지 알수가 있음 누구에게 해당 chunk를 요청할 것인가ㅏ 결정 방식 = rarest first
내 이웃 peer들에게 chunk list를 가져온다 그 중에서 가장 rare한 것 = 이웅이 가지고 있는 chunk들 중 rare 먼저 요청
시스템 전체로 봤을 때 rare한 것이 줄어듦 **
- 주어진 시간에 다른 peer는 file chunk의 다른 하위 집합을 갖습니다.
- 주기적으로 Alice는 각 peer에게 그들이 가지고 있는 chunk list을 request
- Alice는 peer로부터 누락된 chunk를 req 가장 희귀한 것부터
sending chunks: tit-for-tat
** 눈에는 눈 이에는 이 = tit-for-tat
나에게 많이 보내는 peer에게는 chunk를 보내줌 아닌 peer에게는 안 보내줌 현재 자신에게 보내는 peer가 있음 rate이 가장 높은 4개의 peer에게만 자신의 chunk를 보내줌 top 4 list는 10초마다 갱신
30초마다 랜덤하게 선택한 peer에게는 optimistically unchoke = top 4가 아니더라도 데이터를 보냄
- Alice는 현재 가장 높은 속도로 청크를 보내는 4명의 피어에게 청크를 보냅니다.
- other peers are choked by Alice(do not receive chunks from her)
- 10초마다 상위 4위를 재평가
- 30초마다: 다른 피어를 무작위로 선택하고 청크 전송을 시작합니다.
- "optimistically unchoke" this peer
- newly chosen peer may join top 4
BitTorrent: tit-for-tat
더 높은 업로드 속도: 더 나은 거래 파트너를 찾고 더 빨리 파일을 받으세요!
2.6 video streaming and content distribution networks
Video Streaming and CDNs: context
- video traffic: major consumer of Internet bandwidth
Netflix, YouTube: 37%, 16% of downstream residential ISP traffic
** 인터넷에서 가장 많은 traffic volume을 차지하는 것 = video traffic
전체 ISP traffic의 상당한 부분 차지하고 있음 **
- challenge: scale - how to reach ~1B users?
** 10억명의 사용자가 하나의 server에 접속을 한다? -> service가 제대로 이루어지지 않음 -> 확장성 X
영상을 볼때 시간 관계가 상당히 중요 -> 첫번째 받은 data와 두번째 받은 data의 시간 간격이 일정하기 유지가 중요 **
- challenge: heterogeneity 이질성 처리
different users have different capabilites (e.g., wired(유선) VS mobile(무선) / bandwidth rich VS bandwidth poor)
다른 사용자 다른 용량 존재 > 유선 / 무선에서 쓰는 사람 등 사용자의 환경도 다름 이러한 이질성 처리
- solution: distributed, application-level infrastructure
동일한 영상을 보는 사용자 > 무료? 고화질? 이러한 것을 선택할 수 있음 예) 유선 사용자는 고화질 선택 / 3g 사용자 저화질 동영상 선택 등
사용자마다 접속 환경이 다르기 때문에 이질성을 해결하는 방법이 필요함
이런 것을 해결하기 위해 만들어진 것이 application-level infrastruture = 분산구조를 가진 CDN
Multimedai: video
- video: sequence of images displayed at constant rate 일정한 주기 연속된 imgs
e.g., 24 images/sec 초당 24장 imgs
- digital image: array of pixels
each pixel represented by bits
- coding: use redundancy within and between images to decrease # bits used to encode image
이미지를 인코딩하는 데 사용되는 # 비트를 줄이기 위해 이미지 내부와 이미지 사이에 중복성을 사용
<압축 방법>
spatial (within image)
temporal (from one image to next)
** 1. 이미지 하나 내에서 전송되는 사이즈를 줄이는 방법 2. 연속되는 frame 사이의 특성 이용 **
spatial coding example:
instead of sending N values of same color (all purple), send only two values: color value(purple) and number of repeated valeus (N)
동일한 색상(모두 보라색)의 N 값을 보내는 대신 색상 값(보라색)과 반복 값의 수(N)의 두 가지 값만 보냄
temporal coding example:
instead of sending complete frame at i+1, sending only differences from frame i
i+1에서 완전한 frame을 보내는 대신 frame i와 차이점 보냄
CBR: constant bit rate 일정한 비율로 video encoding
: video encoding rate fixed
VBR: variable bit rate 가변으로 encoding - frame 사이의 변화 없으면 보내는 양 적음 변화 많으면 보내는 양 많음
: video encoding rate changes as amount of spatial, temporal coding changes
Streaming stored video:
** 웹 브라우저를 띄워 놓고 거기에 video content URL을 입력하면 HTTP request 형태로 Client에서 Server로 전송이 됨 Server는 URL을 해석하여 거기에 맞는 content를 HTTP response 형태로 Client에게 전달함 Client는 이것들을 buffer에 쭉 쌓아두었다가 일정 buffer 양이 차게 되면 play를 하기 됨 buffer를 쌓아놓는 이유는 Server가 나에게 보내는 video가 네트워크 시간에 따라서 나말고 다른 사람이 쓸수도 있음 즉 나에게 전달되는 이 속도가 항상 일정하지 않다는 것을 의미함 오는대로 play하게 되면 정상적으로 올때는 문제가 없는데 인터넷을 거쳐 Client로 올때 늦게 오는 경우 buffer가 비는 경우도 있음 이때 play할게 없음 video는 초당 몇 장의 이미지를 play해야 끊기지 않게 동영상을 보여주기 때문 거기에 대한 안정장치로 buffer에 어느정도 데이터를 저장을 해놓고 그때부터 play하기 시작 = 끊기지 않게 영상을 보내기 위해 / buffer 비면 영상 끊김 **
Streaming multimedia: DASH
- DASH: Dynamic, Adaptive Streaming over HTTP
- server:
divides video file into multiple chunks (video file을 여러 chunk로 나눔)
each chunk stored, encoded at different rates (저장된 각 chunk, 서로 다른 속도로 encoding - 저/고화질)
manifest file: provides URLs for different chunks (다른 chunk에 대한 URL 제공)
- Client:
periodically measures server-to-client bandwidth (주기적으로 bandwidth(=download rate) 측정 server-to-client)
consulting manifest, requests one chunk at a time
주어진 현재 bandwidth에서 지속 가능한 최대 coding rate 선택
다른 시점에서 다른 coding rate을 선택할 수 있음 (시간에 따라 사용 가능한 bandwidth에 따라 다름)
** download 속도가 느려지면 buffer가 0에 가까워지는 문제가 생김 >> sol : 화질 낮추기 등 control
video를 보면서 현재 Server로부터 받는 data download 속도가 얼마인지 측정을 하고 문제가 없으면 계속 보게 됨
문제가 생기면 manifest file을 참조해서 어떤 action을 취하게 됨
현재 bandwidth(=download rate)에 가장 근접한 속도를 가진 Server에 요청해서 화질을 높여줄 수 있음 **
- "intelligence" at client: client가 결정
when to request chunk
what encoding rate to request
where to request chunk
Content distribution networks
challenge: how to stream content (selected from millions of videos) to hundreds of thousands of simultalneous users?
content( 수백만 개의 video 중에서 선택)를 수십만 명의 동시 사용자에게 streaming 하는 방법은 무엇?
option 2:
store/serve multiple copies of videos at multiple geographically distributed sites (CDN)
지리적으로 분산된 여러 사이트에서 여러 video 사본 저장 / 제공
** 다수의 Server를 두기
중앙 Server를 두고 다른 Server에 동일한 copy를 저장 Client가 요청하게 되면 중앙 Server가 service를 해주는 것이 아니고 Client와 가장 가까이에 있는 content server가 해당 내용을 제공해줌 = CDN
content server를 어디에 둘 것인가? >> enter deep / bring home **
CDN > enter deep: push CDN servers deep into many access networks
close to users
used by Akamai, 1700 locations
Increase user experience by decreasing the path length ( 경로 길이를 줄여 사용자 경험 향상 )
But, difficult to manage CDN server clusters ( 하지만 CDN 서버 클러스터를 관리하기 어려움 )
** CDN server를 ISP(네트워크 관리)와 협의해서 network edge에 push 그러면 사용자는 server와 가까이 있기 때문에 사용자 경험을 증가시킬 수가 있음 (거리가 줄어들기 때문) = delay를 줄일수가 있음 하지만 network edge는 network 가장자리에 있기 때문에 상당히 많은 주에 포설을 해야 됨 그리고 모두 같은 content를 가지고 있어야 함 관리 비용이 매우 커짐 **
CDN > bring home: smaller number (10's) of larger clusters in POPs near (but not within) access networks
used by Limelight
** bring home edge 말고 core에 하기 IXP라는 교환점에 설치하기 거기에 CDN server를 두자 사용자의 거리는 멀지만 관리해야 할 수가 적어 용이 **
Content distribution networks (CDNs)
** network edge에다가 여러 개의 CDN을 포설 거기에 영화를 저장 e.g., Madmen
manifest이 전달됨 > 그 content가 실제로 CDN server들 중 어디에 저장되어 있는지 알려줌 > 그 중 나와 가장 가까운 것을 선택하여 그 CDN과 연결을 함 > 그러다 그 server가 너무 느려지게 되면 아까 받았던 manifest를 참조해서 두번째로 가까운 CDN을 찾아서 content를 받아옴 manifest는 list 같은거임 **
- CDN: stores copies of content at CDN nodes
- subscriber requests content from CDN ( 구독자 CDN에 content 요청 )
directed to nearby copy, retrieves content
may choose different copy if network path congested
CDN content access: a closer look
** CDN 사업자 = over the top(ott) 이라 부름
e.g., content 사업자들이 network 사업자들에게 망 사용료를 내지 않고 서비스를 한다
이와 같은 streaming service를 제공하는 서업자들은 자체망이 없어도 됨 일반적으로 ISP 망을 사용
거기에 자기 server들만 분산적으로 포설 해두고 사용자들에게 service 제공 **
- OTT challenges: coping with a congested Internet
from which CDN node to retrieve content? 검색
viewer behavior in presence of congestion 혼잡 상황에서의 viewer 행동
what content to place in which CDN node?
Case study: Netflix
Case study: KanKan
