client-server architecture
- server
- always-on server
- 영구적인 IP를 가짐
- data가 군집되어 있는 center
- client
- server와 소통, 서로 직접적으로 소통하지 않음
- 동적으로 IP를 할당받음
P2P architecture
- always-on server는 존재하지 않음
- peer-peer간 소통함
- self scalability의 특징을 가짐 => service에 peer가 증가하면 자가확장적인 특성을 띔
- peer의 IP는 동적으로 할당되기 때문에 관리가 매우 복잡함
processes communicating
- 같은 host 내의 process는 IPC를 통해 소통
- 다른 host 내의 process는 message 교환을 통해 소통
- peer to peer, client to server 의 소통은 사실 process 간의 소통임
server process
: 소통을 대기하는 process
client process
: 소통을 시작하는 process
Socket
- socket은 문으로 비유할 수 있음
- process는 socket을 통해 message를 보내고/받음
addressing process
- host 간의 소통은 process 간의 소통임. 따라서 host별로, process별로 서로 식별하는 값이 필요함
- host는
IP
라는 32bit의 고유한 주소를 가지게 되고, process는 port number
라는 고유한 주소를 가지게 됨
- e.g) HTTP server의 port#는 80, mail server는 25임
- e.g) 128.119.254.12:80
app이 필요로 하는 transport service 의 종류
1. data integrity
- file transfer, web transactions 같은 app들은 100% 안정적인 data transfer을 필요로 함
- audio 같은 app은 어느정도의 loss를 감안함
2. timing
- internet telephony, interactive games 는 낮은 delay를 필요로 함
3. throughput
- multimedia 같은 app들은 최소한의 throughput을 보장받길 원함
4. security
- encrpytion, data intergrity, ...
=> app이 필요로 하는 transport service에 따라서 TCP or UDP
를 결정하게 됨
app-layer에서 정의하는 것들
- types of messages exchanged
- message syntax
- message에 어떤 field가 있고, 어떻게 표시되어야 하냐
- message semantics
- 언제 어떻게 보내고 받아야 하냐
- app-layer protocol에는 두가지 종류가 있음
- open protocols
- internet protocol의 표준을 나타내는 RFC에 공개되어 있는 protocols
- e.g) HTTP, SMTP
- proprietary protocols
WEB
HTTP
- web page는 HTML 파일로 이루어져 있고, HTML 파일들은 object들의 reference(URL)를 담고 있음
- server-clinet 모델로 이루어져 있음
TCP
방식을 이용함
- HTML file을 주고 받기 전에 handshaking이 이루어짐
- stateless 하게 동작함
non-persistnet HTTP (= 1.0 HTTP)
- 한번의 connection에 하나의 object만을 보냄
- multiple objects를 다운로드하기 위해선 multiple connections이 필요함
- TCP connection이 맺어졌다는 것은 두 process 간에 socket이 만들어졌다는 것을 의미함
- 이렇게 만들어진 socket을 통해서 object를 주고/받게 됨
response time
- user가 요청을 시작하고 file을 응답받을 때까지 걸린 시간
RTT(Round Trip Time)
: 작은 패킷이 clinet에서 출발해서 다시 돌아오는데 걸린 시간
- non-persistent HTTP response time = 2RTT + file transmission time
- 하나의 object마다 2RTT가 필요함 => 너무 오래 걸려서 브라우저가 TCP 연결을 병렬적으로 연결하기도 함
persistnet HTTP
- 한번의 connection에 여러개의 object를 보낼 수 있음
- connection을 닫지 않고 열어둔 채로 file을 request/response를 함
- 1RTT에 모든 파일들을 보내고/받을 수 있음
HTTP request message
- HTTP message는 request/response 2가지 type으로 나뉨
- Method types
- GET, POST, PUT, DELETE
- HEAD: request에 대한 response 메세지에 object를 담지 말라고 요청 (개발 단계에서 사용)
Cookie
- stateless한 HTTP를 stateful 하게 사용하기 위한 방법
- 동작 방법
- clinet가 최초 접속 시 server는 response message header에
set-cookie
값으로 cookie 값을 보냄
- client의 browser는 cookie 값을 보관
- 다음 request 시에 request header에 cookie 값을 보냄
- server는 cookie 값을 이용해서 해당 DB entry에 저장된 값들을 가져와서 response
Web caches(proxy server)
- origin server 의 내용을 proxy server에 copy 해두고, web access를 항상 proxy server를 통하도록 함
- web cache는 client 이자 server 임
- response time을 줄이고자 ISP가 web cache를 설치함
- access link의 traffic을 분산시켜서 response time을 줄일 수 있음
- 지리적으로 먼 경우 가까운 곳에 설치해 response time을 줄일 수 있음
- connection을 제공하는 ISP들을 많이 거칠수록 많은 비용이 드는데 content가 web cache에 퍼지면 비용을 줄일 수 있음
- 동작 방법
- client가 object를 request하면 proxy server는 해당 object를 대신 origin server에 request함
- proxy server는 client에게 response해주고 해당 object를 저장하고 있음
- 다른 client가 동일한 object를 request하면 proxy server가 바로 response 해줌
Conditional GET
- web cache가 자신이 가지고 있는 object의 정확성을 위해 사용하는 method
- web cache가 origin server로 requst를 보낼 때 해당 object를 copy한 날짜를
If-modified-since
값으로 header에 집어넣음
- 2-1. 만약 수정이 되지 않았다면 origin server가
304 Not Modified
를 response함
- 2-2. 만약 수정이 되었다면 origin server가
200 OK
와 함께 새로운 object를 보내줌
Electronic mail
- user agent와 mail server로 이루어져 있음
- user agent: 메일의 작성/수정/읽기/보내기 등의 작업을 수행
- mail server: 나가거나 들어오는 메일들을 보관하는 서버
- mailbox: 유저마다 들어오는 메일들을 보관함(유저마다 하나씩 있음)
- message queue: 유저가 보내는 메일들이 들어감(서버마다 하나)
SMTP
- user agent가 mail server로 메일을 보내거나 mail server가 mail server로 메일을 보낼 때 사용하는 mail protocol을 말함
- SMTP protocol은
TCP
위에서 사용하기 때문에 mail server로 보내기 전에 TCP connection이 맺어져야 함
- persistent connection을 사용함 (한번의 connection으로 여러 개의 object를 보낼 수 있음)
- port 25 번을 사용함
- 작동 순서
- handshaking
- transfer of messages
- closure
mail access protocol
- user 는 mail server로 부터 mail을 받아올 때 mail access protocol을 이용해서 메일을 가져오게 된다
POP3
- 세션 간 stateless 하다는 특징이 있음
- mailbox에서 mail들을 download 하는 방식 (download n keep mode, download n delete mode 두 가지 방식이 있음)
IMAP
- POP3의 단점을 보완하고자 나옴
- POP3에서 client의 작업은 local에서 이루어지지만 IMAP에서는 서버에서 이루어짐
- 세션 간 user state가 유지됨
DNS(Domain Name System)
- host name를 IP address에 매핑해줌
- host aliasing (=> host naem의 별칭(alias)를 실제의 host name에 매핑해주는 기능)
- mail server (=> 메일 서버에 대한 주소를 알려줌)
- load distribution
- 규모가 큰 web server의 경우 여러 개의 replica(ws1, ws2, ws3)를 가지고 있고 특정한 alias로 오는 request들을 여러개의 replica들로 매핑해줌
why not centralize
- single point of failure
- traffic volume
- DNS server로 traffic이 몰릴 수 있음
- distant centralized database
- 지리적으로 멀면 response time이 길어짐
- maintenance
distributed, hierarchcal DB
root name server
: 계층의 최상위에 존재하며 어떤 TLD server들이 존재하는지 알고 있고 요청 시 해당 TLD server로 매핑해줌
- local DNS server와 contact함
TLD(Top level Domain)Server
: .com, .org, .edu, .kr, .jp level의 DNS server들
- 기관별 authoritative DNS server 를 알고 있음
authoritative DNS server
: TLD 아래의 DNS Server들
- 서비스 제공자가 자신의 DNS Server를 관리함(e.g amazon.com => 아마존이 관리)
- 요청으로 들어온 hostname의 IP에 대한 정보를 갖고 있음
- ``에 대한 매핑 정보를 caching 하고 있음
local DNS Server
- 위의 hierarchy 구조에 속하지 않는 DNS Server, proxy server 라고도 불림
- ISP가 local site 내에 설치하게 됨
- 매핑 정보를 갖고 있으면서 client 들의 요청을 1차적으로 처리(=> web caching과 비슷)
- 없는 내용에 대해서 request가 들어오면
root name server
로 query
TLD Server
에 대한 매핑 정보를 caching 하고 있어서 보통은 root name server
를 거치는 일이 적음
- out-of-date 방지를 위해 TTL(time to live)를 포함하고 있음
DNS Server의 query 해결 방법
- DNS는 query와 reply 두 가지 type으로 메세지를 주고 받음
1. iterated query
- query가 들어왔을 때 contact한 DNS Server는 어떤 server에 contact해야 하는지만 알려줌
"난 모르는데 쟤가 알고 있어"
2. recursive query
- query가 들어왔을 때 contact한 DNS server가 답을 찾아서 응답해줌
- 계층구조의 상위계층에 많은 부하가 몰릴 수 있음
DNS Server에 records를 넣는 example
- 'network utopia'라는 회사가 등장
- network utopia는
authoritative server
를 구입
- .com 의 TLD Server를 관리하는 회사(network solutions)에 자신의
authoritative server
IP 주소와 이름을 제공
- network solutions는 .com TLD Server에 이를 등록함
P2P Application
- 이전까지는 Client to Server 구조였음
- P2P 구조는 확장성의 장점을 가짐
File distribution time
파일의 크기를 F, 서버의 업로드 속도 u(s), peer의 업로드 속도와 다운로드 속도를 u(i), d(i) 라고 했을 때 N 명에게 파일을 distribution 하는 시간은 max( NF/u(s), NF/(u(s)+u(0)+u(1)+..+u(n-1)), F/d(min)) 이다.
Socket programming
- 두 가지 transport service에 따라 두 가지 socket type으로 나뉜다
- TDP: reliable & byte stream-oriented 인 특징을 지님
- UDP: unreliable
UDP Socket Programming
- client & server 간 connection이 없음
- data를 보내기 전 handshaking 과정 없음
- 각 패킷(=> datagram)마다 IP 주소와 port#를 붙여서 보냄
- 수신 측은 전달된 packet 으로 부터 송신 측의 IP 주소와 port#를 알아냄
- 전달한 data가 순서가 뒤죽박죽으로 오거나 손실될 가능성이 있음
- 동작과정
TCP Socket Programming
- client는 server와 connection을 맺어야 함
- server는 contact를 위한 socket을 열어두고 request를 대기함
- client가 contact하면 client는 TCP socket 을 만들고, socket에게 contact할 IP주소와 port#를 명시하고 connection을 맺음
- server는 접촉한 client 만을 위한 새로운 socket을 만듦
- byte stream order를 제공해야 하기 때문에 client별로 별도의 socket을 만들어야 하는 것
- 동작과정
출처: http://www.kocw.net/home/search/kemView.do?kemId=1046412