Computer Network (2) : Application
1. Internet Protocol Stack
1) Application : FTP / SMTP / HTTP
2) Transport : TCP / UDP (ip address의 프로세스 식별, 어플리케이션간 연결 유지)
3) Network : IP (routing forwarding, end to end 연결, IP레이어에서 확인하고 destination 확인)
4) Data Link : 피지컬 받아서 이웃한 노드/접속가능한노드/지역근접노드 사이 연결
5) Physical : 피지컬한 미디어에 맞게 기계/전기/물리적 특징
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
2. Application Architecture
소캣 프로그래밍
네트워크 어플리케이션 짜는 것
해당 어플리케이션 통해 TCP 접속해서 데이터 보냄
중간 라우터,스위치 통해 상대방 end system 연결 , 리눅스 커널 위 소프트웨어 플랫폼 제공
네트워크가 하드웨어 고려하지 않도록 프로토콜 돼있음
소캣
OS 커널 내 IP STACK으로 ACCESS하기 위한 커널에 대한 API
Application Architecture
1) Client Server Architecture
클라이언트: 서버와 반대기능, 필요에따라 온오프, 각 아이피 다름, 클라이언트 장소 상관X
서버: ip거의 안바뀜, DNS 통해 바꾸더라도 유저 체감X AWS (링크 빌려 서버구축)도메인과 아이피 맵핑하는 서비스 = DNS필요
2) Peer to Peer (P2P) Architecture
Hierarchical network에서 logical netwrok 만듦
각자 동등한 기능 가지는 peer사이의 네트워크 구성
클라이언트와 서버 기능 모두 O
DNS 필요X
‘KEY’라는 식별자 통해 hashing, hashing된 장소에 커넥션, 필요데이터 확인, 하나가 고장나도 계속 connection유지, 여러명의 피어들이 한 서버의 요구 들어줄 수 있음
Scalable
도메인을 아이피 바꾸거나 피어의 주소(찾고자하는 정보에 해쉬된 정보)를 아이피로 바꾸는 과정 필요
엔드, 프로세스, 어플리케이션 간 연결 통해 프로토콜에 정의된 메시지 보내는 것 가능
- TCP UDP – UDP 비디오 데이터 전송 중심 / + FTP 거의사용하지않음, 보안문제
- TCP 바이트 스트림 만듦, server-client & peer 연결도 저장장치에서 데이터 엑세스 (reliable transmission – byte stream service
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
3. Applications
IETF – 어플리케이션 정의
FTP (file trasnfer protocol)
security X (아스키)
FTP user interface (유저와 interaction) / FTP client module (서버와 interaciton)
원격 파일시스템 읽어오거나 내가 가진 데이터 원격 서버 저장
포트넘버 21 -> 대체 : SCP, SFTP
Separate control & data connections
채널 포트 21번
명령 -> 디렉토리 읽거나 파일 가져옴 -> 결과물 -> 포트 21 통해 전송 -> 끝나면 TCP connection 끊어짐 (컨트롤 채널은 열려있지만 데이터 채널은 끊어짐) – 모두 TCP임
HTTP (hypertext transfer protocol)
텍스트로 구현된 데이터를 전달하기위한 프로토콜
HTML : 데이터 표현 방법 규정
Web browser : 전달된 데이터 화면 노출
Web site : 웹브라우저가 클라이언트라면 서버는 웹사이트
SGML > HTML / XML, CSS, JSON
Method (GET, POST, HEAD) 로 Resource 표현
URL: 접속하고자하는 대상, 사용하고자하는 데이터를 동일한 형태로 표현
= uniformed resource locator
URL -> DONMAIN -> DNS -> IP -> 서버접속
TCP 3-way handshake -> connection -> HTTP request -> 서버 response
동일한 커넥션에 여러 오브젝트 사용
stateless : 서버는 클라이언트 트래킹 X, 그냥 response messgae만 보내면됨, state저장X
HTTPS – 금융/ HTTP2 – 구글 / HTTP3 – UDP 구글
시나리오 socket VS server-socket / HTTP connection
여러 개 오브젝트 독립된 TCP?
1) persistent HTTP
하나의 HTML 내 오브젝트가 독립된 TCP 커넥션 통해 전송, 끝나면 끊음
여러 오브젝트가 하나의 TCP 통해 전달
2) non-persistent HTTP
사용자가 웹브라우저 실행 후 특정 URL 집어넣으면 커넥션 열림
TCP열고 포트80 서버 접속 서버 소캣 레이어 accept system call TCP 같이 엶
a. syn : 이제부터 TCP 커넥션 + index정보
b. syn에 대한 ack (포트넘버)
c. URL보냄
d. 서버가 메시지 분석 후 해당 URL찾고 response메세지 보내고 TCP닫음
e. HTML 문서 받 (object10개)
f. a~e 반복
3) delay
TCP delay + HTML delay
RTT (round trip time) : 데이터 리퀘스트 메시지 보내서 서버에서 받을때까지 왕복시간
a. TCP 첨에 syn 보내고 서버가 syn ack보냄
b. syn ack 받자마자 syn ack에 대한 ack + request message
c. 서버는 response message + tcp 닫
2RTT + file transmission (HTML) 매 오브젝트마다 해당 딜레이 필요
-> OS부담 (메모리 CPU)
request line (GET method + url + version) / header line (host(domain), browsertype, language) / return + 헤드 끝 빈라인
body(PUT method) / MIM headers – media / SMTP – 여러 개 연결 , HTTP – TCP하나
User Server State : COOKIES
본인 데이터베이스 서버에 유지 + 데이터베이스 인덱스 웹브라우저 유지
서버는 웹브라우저 인덱스 정보 읽고 suggest / 해당 웹사이트 행동 트래킹
authorization (=! authentication)
HTTP overload -> Web Cashes (proxy server)
ISP 서버가 내 정보 O -> 원격 서버 접속X -> Local ISP 캐쉬정보 ACCESS -> 트래픽집중 막고 condensing문제 해결, delay줄임 (RTT 줄이는 것)
아카마이
웹캐쉬 = 클라이언트와 서버 역할
<가정>
1) 초당 15개 request (하나의 object 100KB) = 1.5Mbps, 서버-라우터 시간 2초
1.5/1.54 , load 1가깝 = delay 수 분
2) 엑세스 링크를 좋게하면 되지만 특정시간에만 몰리면 필요없음, 2초
0.6 X 1.5Mbps -> 0.9 / 1.54 = 0.58
0.4 X cache
- conditional GET -> 헤더에 날짜지정 -> modify response
SMTP(simple mail transfer protocol)
- 메일 서버 메일 주고받기 위한 프로토콜
- 서로 IP주소 알고 포트넘버도 25 지정
- 포털: 팝3 (로컬에 메일저장 ), 아이맵(스마트폰 서버에 저장, 원격엑세스, 동기화)
- 메일서버 / 관리자
- 아스키코드, 여러 명령어,
1) direct mode
사요자가 이메일 서버 접속해 상대방 이메일 서버 접속 후 메시지 보냄
메일 서버 로그인 상대방 메일서버 TCP 메시지 보내고 상대 메일박스 저장
2) relay mode
outgoing server, incoming server지정
이메일 작성 후 센드 이멜 서버 큐에 집어넣고 상대방 메일 TCP 이메일 서버가 나 대신 사용자가 제공한 메시지 보고 전송 상대방이 들어오는 메시지 받고 메일박스에 메시지 집어넣음
- 읽어오는 프로토콜이 팝3 아이맵 (셋업할 때 지정 – access protocol)
Format
Structure / MIME
MIME
기본적인 형식 / 인코딩 / 컨텐트 타입 / ~
MIME RFC에 저장
HTTP 하나의 웹페이지 여러 개 오브젝트 각 오브젝트 로지컬 별개 TCP 커넥션
SMTP 사용자 보낸 전체 메일 보내 한 메일 안 이미지 비디오 각 파트 구분 이유: 특정 이미지 비디오 처리할 수 없을 수도 있어 표현할 수 있는 부분만 표현 + security
POP3 protocol : 다운 후 딜리트 / 공유 X /
아이맵 : 모든 메시지 서버에 두고 사용자가 필용에따라 가져옴, 킵트랙킹
SMTP는 기본적으로 TCP 유지, 메일 여러 개 object면 하나의 TCP에 다 전송 / 헤더와 바디 / 메시지 마지막 라인 점 / 모든 내용 escape명령어 = 메일임을 알 수 있게
HTTP는 pull (persis, non-persis) / SMTP 는 push (persis)
DNS (7digits – 12 digits)
name resolution
address solution
address resolution
Application layer 에서 한 번
IP – Data link Layer 사이에서 IP를 데이터링크 어드레스 (맥 어드레스) 로 바꿔주는 name reolution
alphanumeric / 4X3 -> 16X8 (ver6)
일반적 도메인 – 국가별 도메인
default gateway : 모든 데이터가 특정한 곳으로 가야함
domain -> ip 해야 TCP 가능
DNS 여러 개 ( DDoS방지)
권한 없는 응답: cacehd mappings . name resolution
name resolution
클릭 -> 도메인네임 획득 -> ip로 변환 -> TCP 커넥션 -> SMTP, HTTP기반 웹브라우징
기본적으로 hierarchical ( root domain server – top name domain server )
각 기관마다 도메인네임 따로 관리하기도
authoritative mapping: 해당 도메인 네임 관리하는 서버가 제공하는 mapping정보
나머지는 cached mapping
-> 외부 노출 도메인 + 내부 도메인 + 실제 ip 분리해서 자유자재 이용가능 (보안문제)
ip 모르고 캐쉬 X / 오랫동안 접속 X -> root DNS -> mapping된 정보 제공
클라이언트 ip 얻기 위해 도메인 네임 받았을 때 DNS query를 로컬네임서버에 물어봄 -> 로컬네임서버 캐쉬 맵핑 ip return / otherwise 루트네임서버 접속
1) recursive query
ip어드레스 할당 -> default gate way 설정 -> 캐쉬있다면 ns.korea -> 없다면 root name server -> edu TLD 접속 -> 위에서 아래로 -> 캐쉬하여 정보 return
2) iterative query
NS 물어보고 캐시된 맵핑정보 return -> 아니면 다시 root server
DNS records
= DNS가 관리하는 records / resource records(RR)을 저장하는 distributed db
type에 따라 다른 정보들
type = A 해당 네임에 대한 ip
type = NS 네임: 도메인 네임 벨류: ip / 도메인네임에 대응되는 네임서버의 ip를 세팅
type = CNAME 외부 알려진 도메인네임과 내부 사용 서버 맵핑, (end to end delay줄어듬)
-> 로드 밸런싱 (여러 개 서버가 동일 노 드 받으면 각 서버 수용 사용자수 고르게 만듦
type = MX 해당 도메인 네임에 해당되는 메일서버의 ip mx값을 줌
도메인네임서버에 (도메인네임, 실제 서버의 도메인 네임, ip address, type정보)
루트네임서버와 TLD 모두 도메인서버 맵핑정보 유지 , 길게 유지 빈번 access / 고장X
Default domains / Reverse DNS / Attacking DNS
response 인터셉트 or 가짜메세지 or DNS쿼리 트래픽 집중
P2P
기존 클라이언트 서버 : 클라이언트보다 각 클라이언트 다운 capacity 중요
p2p : 각 클라이언트 공유하고자 하는 파일 일부 가지고있으면 공유 서비스
file distribution time
1) client – server
D >= max {NF/us, F/d_min}
2) p2p
D >= max {NF/us, F/d_min, NF/(us + 시그마 ui}
피스 : 피어들 사이 공유 단위
peers = swarm
meta information
key, value, hash value (key – value 연결)
tracker address
peer
seeder : 공유하고자하는 파일 전체 가진 peer
leecher : 전체 파일 가지지 않은 peer
DHT (data가진 peer 찾는 방법) = (distributed hash table)
토렌트 파일 -> 트랙커 -> 정보 -> swarm -> 일부 swarm선택 or 새로운 swarm -> 클라이언트에게 seeder leecher정보 전송 -> 그들의 ip 전송 (소캣, TCP) -> 클라이언트 peer정보로 connection시도 -> 데이터 piece화 해서 보냄 -> 트랙커 정보로 다른 peer접속해서 piece정보 요청받음 -> seeder
‘churn’ 단골 X / sefish
Distributed DB = logical 하게는 하나의 DB이지만 physical하게 각 peer에 저장 후 access
key-value hashing 값과 peed id 매칭?
특정 범위 내 값을 각 peer 할당 (0~2^n) 데이터 저장할때도 데이터의 primary key값 hash 범위 내 값 가지도록 mapping
tit for tat
나에게 데이터 많이 보낸 4명 peer 골라 데이터 보내고 매 10초마다 4명이 바뀜
처음이라면 ? 어떤 peer든 30초마다 peer 랜덤하게 선택하여 파일 전송 (unchoke가능)
주고 받다가 파일 수신 status 동일해지면 데이터 못받고 또 다른 3자에 의해 unchoke top4계속 바뀜
Video Streaming & content distribution
heterogeneity -> cash적극 사용
DASH (dynamic adaptive streaming over HTTP)
많은 동영상 스트리밍 트래픽 요구 -> 엠펙데이터 잘 전달 위한 표준
엠펙 1, 2 동일한 인코딩
파일복사하여 서로 다른 인코딩 웨이트로 복사
resolution을 버전별로 각기 저장 / 인코딩 웨이트에대한 description file (manifest file) 만들어 사용자에게 줌 -> 네트워크 환경에 따라 다양한 품질
클라이언트 : 서버 접속할 때 manifest file 가져오고 default weight로 인코딩된 파일 가져옴, 네트워크 환경에 따라 파일 참고해서 적합한 인코딩정보 가져옴 -> 이때 클라이언트-서버 주기적 확인 (서버는 무식하기 때문에 클라이언트가 버퍼 확인하면서 요청)
CDNs (Content distribution Networks)
1) enter deep : 오리지널 서버의 캐쉬 access net에 (아카마이)
2) bring home : 스위치에 캐쉬 두는 것 / IXP에 작은형태로 작은개수의 큰 캐쉬
-> access net이든 IXP든 캐쉬들 사이 별도의 logical net 구축 표현
