Application layer.
따라서, 실제로 developer는 socket의 application에 대한 설정만 할 뿐이지, socket의 transport layer에 대한 제어를 할수 있는 것은 아니다.
transport layer에 할 수 있는 제어(설정)은 transport의 protocol 설정, max buffer size, max segment size, parameters 설정이 뿐이다.
transport layer protocol이 이것을 사용하는 applications에게 제공할 수 있는 서비스는 transmission, throughput, time, security 같은 것들이다.
- reliable data transmission
router의 buffer가 overflow, packet의 오류 등과 같은 경우 packet loss가 발생하는데, email, file transmission, financial application 등의 application에서는 이러한 loss가 치명적일 수 있다. 따라서, 전송되는 data의 loss를 막고, 정상적인 전달을 보장하기 위한 방법이 필요하다. - throughput
source host에서 전송하는 data는 network path를 따라 이동하는데, 이러한 path는 다른 hosts가 전송하는 data들과 공유도기 때문에, 사용가능한 throughput이 시간에 따라 변동한다. 따라서, 어떠한 application은 항상 적어도 r (bits/sec) 정도의 throughput을 요청한다면 이러한 것을 보장하기 우한 수단이 필요하다. - time
Internet phone, teleconferencing(원격회의), online game 같은 경우 packet이 전송되는 시간이 중요하다. 예를 들면 적어도 100msec 안에 도착해야 service가 원활하게 이루어 지는 경우가 있을 것이다. 그렇지 않으면, game에서 렉걸리는 걸 볼수도 있을 것이다. - security
전송되는 모든 data를 암호화하고, 복호화 할수 있다.
위에 나열된 것들은 일반적으로 제공 가능한 transport layer의 service들이다.
인터넷이 application에 제공하는 두 개의 transmission protocol은 UDP(User Datagram Protocol)과 TCP(Transmission Control Protocol)이 있다.
- TCP (Transmission Control Protocol) service
connection-oriented service :
application layer의 message를 전송하기 전에 TCP는 client와 server가 hand shaking 과정을 통해 서로 전송 제어 정보를 교환하게한다.
이 과정이 끝나면, 서로에게 동시에 message를 전송할 수 있는 full-duplex 상태가 된다.
application이 message transmission이 끝나면 connection을 끊어야 하므로, 느슨한 연결관계라 할 수 있다.
reliable data transmission service :
모든 data들이 오류 와 중복 없이 올바른 순서로 전달 가능.
congestion control :
Internet 전체의 성능 향상을 위해 network가 혼잡한 상태가 되면 client 또는 server는 전송하는 속도를 낮춘다. (실시간 application에게는 치명적이 될수 있으므로, 보통 이러한 application은 UDP를 사용.) - UDP (User Datagram Protocol) service
connectioniess service :
hand shaking을 하지 않음.
non-reliable data transmission.
전송하는 data packet에 대한 수신 순서를 보장하지 않음.
congestion control을 제공하지 않음.
* 단, Internet transport layer의 경우 암호화를 제공하지 않는다.
따라서, application layer에서 개발된 SSL service를 이용하여 암호화를 수행한다.
따라서, application layer에서 개발된 SSL service를 이용하여 암호화를 수행한다.
SSL service는 내부 코드에 자신의 socket API를 가지고 있다.
application이 SSL을 사용하면 송신 process는 data를 SSL socket에 전달하고, 이것은 암호화 되어 TCP socket을 통해 전달된다. destination에서의 SSL은 복호화를 한수 SSL socket을 통해 data를 수신 process에게 전달한다.
* 전자메일(SMTP protocol 사용), 원격터미널 접속(Telnet), 웹(HTTP), 원격 파일 서버(FTP)같은 application에서 TCP를 사용.
* YouTube(HTTP), 인터넷전화(RTP)같은 application에서 UDP 또는 TCP를 사용.
* How to communicate between two hosts?
두 가지의 정보가 필요.
(1) Host의 name 또는 address, (2) destination host의 address and port.
* application layer protocol의 fields
- 교환 message의 type. (reply message or request message)
- message의 문법. (message 내부의 field간 구별 방법)
- fields의 의미. (fields의 data의 의미)
- message를 주소 받는 규칙
* Web and HTTP
- Web의 application layer protocol인 HTTP(Hyper Text Transfer Protocol).
HTTP는 Client program과 Server program으로 구성.
HTTP는 message의 구조 및 어떻게 message를 교환하는지에 대해 정의한다.
"http://www.OOOXXX.ac.kr/CS/pricture.gif"와 같은 URL에서,
"http" 는 http protocol이라는 의미.
"www.OOOXXX.ac.kr" 은 host name.
"CS/pricture.gif" 는 path name 이다.
Web browser(chrom, explorer...)는 HTTP의 client 부분을 구현함.
Web server(apache, IIS...)는 HTTP의 server 부분을 구현함. - User가 web page를 요청하면, browser는 HTTP request message를 server로 전송하고, server는 request를 수신하고, reply object를 포함하는 HTTP reply message를 client에게 보낸다.
HTTP는 TCP transport protocol을 사용하는데, HTTP client는 server에 TCP 연결을 요청하면(hand shaking), server가 이 요청을 수락, full-duplex 상태가 된다.
server가 client가 request한 file을 보낼 때, server는 client의 state를 저장하지 않는다. 만약, 몇초뒤 client가 같은 request를 보내면 server는 이 request가 이전에 왔던것과 같은 것인지 알 수 없다. 따라서, HTTP를 stateless protocol 이라고 한다. - client-server 의 communication에서 application developer는 request/reply pair가 같은 TCP connection 상에서 이루어져야 하는지, 아니면 분리된,(즉, request 할때마다 새로운 TCP 요청을 만드는 것) TCP connection 상에서 이루어져야 하는지 결정 해야함.
* Non-persistent connection :
HTTP client는 basic port 80을 통해 Server로 TCP connection을 시도하는 request message를 보낸다. HTTP server는 request message를 socket을 통해 받으면, 적절한 응답을 위한 object를 추출하고, HTTP reply message에 그 object를 캡슐화하고, reply message를 client에게 보낸다.
그런 후, server는 client가 reply message를 올바로 받았다는 message를 받으면, TCP connection을 해제한다.
client는 reply message를 받고, TCP connection이 중단되며, 받은 message에게 file을 추출하고, THML 파일을 파싱하고, object를 사용한다.
RTT(Round Trip Time): packet이 client에서 server까지 가서, 다시 client로 되돌아보는데 걸리는 시간으로, propagation delay, queuing delay, processing delay 등을 포함한다.
<source: Computer Networking a top down approach>
drawback : (1) each request object에 대한 새로운 connection 설정이 필요하다. TCP buffer allocation, TCP variables 등을 준비해야한다. 따라서 server에게 부담이 된다. (2) TCP connection 설정에는 RTT가 필요한다. 매 요청마다 RTT가 소요된다.
* Persistent connection :
Server는 client에게 reply를 보낸 후에 TCP connection을 유지한다. 같은 client와 server 간의 communication 후, HTTP server는 일정 기간(timeout) connection이 사용되지 않으면, connection을 해제한다. 보통 default로 이 방식을 사용한다. - HTTP message format (request, reply)
* request message
request line: method filed, URL field, HTTP version field 로 구성.
header line: request 대상이 되는 host의 name field, stateless connection인지 statefull connection인지 결정하는 field, server에게 request하는 browser의 type을 의미하는 User-agent field, 요청하는 object의 language를 의미하는 Accept-language field.
* reply message
state line: protocol version field, state code field, state message field.
Connection, Data, Server, Last-Modified, Content-Length, Content-Type field.
* state code field values
200 OK: request success. data가 reply message로 보내져 옴.
301 Moved Permanently : request가 이동됨. 새로운 URL이 reply message의 location field에 포하되어 있음.
400 Bad Request : server가 request를 이해하지 못함.
404 Not Found : request한 document가 server에 존재 안함. - cookie
HTTP server는 state를 유지 하지 않음. 이것은 서버의 설계를 단순화하고, 동시에 많은 수의 TCP 연결을 다룰수 있는 Web server를 만들수 있게 함.
하지만, user에 따른 service를 제공할 때, user의 information을 알아야 한다. 때문에 HTTP는 cookie를 제공한다.
cookie는 (1)reply message cookie header line, (2) HTTP request message cookie header line, (3) user의 browser에 user host와 management를 지속시키는 cookie file, (4) web site의 back end DB를 갖는다.
<source: Computer Networking a top down approach> - Web caching
Web cache(=Proxy server)는 자체에 disk를 가지고 있어, 최근 요청있던 object의 사본을 저장 밑 보존함.
browser가 user의 모든 HTTP request을 proxy server에 먼저 request하고, proxy server는 저장되어 있는 object의 사본을 client browser에게 HTTP reply message와 함께 보냄. 만약, object의 사본이 없다면 proxy server는 원본이 있는 server에 TCP connection을 요청함. 이 요청을 받은 server는 HTTP reply message에 object를 포함해서 proxy server에 보낸다.
proxy server는 HTTP reply message에서 object를 추출하고, 자신의 disk에 copy한 후 client browser에게 HTTP reply message와 함께 object를 보낸다.
보통 ISP가 proxy server를 운용한다. 이러한 proxy server의 운용은 client request에 대한 reply time을 줄이며, web traffic을 줄일수 있다.
* DNS
- Host name: "www.google.com"과 같은 가변길이의 alphanumeric character로 구성됨.
이것을 IP address로 mapping 해주는 것이 필요.
IP address는 4byte로 구성됨. (e.g. 123.100.3.24) - Host name을 IP address로 변환해주는 것이 Domain Name System(DNS)이다.
DNS server들은 계층구조로 구현된 distributed DB이며, host가 distributed DB로 질의할 수 있는 application layer protocol 이다.
DNS protocol은 UDP로 수행되며, port 53을 사용한다. - user가 "www.OOO.ac.kr"을 요청할 시, 먼저 이에 mapping 되는 IP address를 얻어야 한다.
user의 computer는 DNS application의 client가 됨.
browser는 URL에서 host name을 추출하고, 그 host name을 DNS application에 넘김.
DNS client는 DNS server로 host name을 포함한 질의를 보냄.
DNS client는 host name에 대한 IP address를 server의 reply message로 부터 얻음.
browser가 DNS로부터 IP address를 받으면, browser는 그 IP address의 80번 port에서 운영되는 HTTP server process에 TCP 연결을 요청하고, 설정함. - DNS server를 운영하므로서, load distribution을 수행 할 수 있다. DNS 는 분산된 형태의 계층적 구조로 존재하므로, user의 요청에 대해서 효과적으로 빠르게 응답할 수 있다.
- scalability problem으로 인해 집중형 DB보다는 distributed hierarchy DB 형태가 사용됨.
DNS server는 세가지 유형이 있음: root DNS server, TLD(top-level domain, 최상위 레벨 도메인 네임) DNS server, authoritative(책임) DNS server.
예: "www.amazon.com"의 IP address를 원한다면, client는 먼저 root servers 중에 하나에 접속을한다. 이 root server(전세계에 13대?)는 최상위 레벨 도메인 "com"을 갖는 TLD server의 IP address를 보내준다. client는 이 TLD server들 중 한곳에 접속하고, TLD server는 도메인 "amazon.com"을 가진 authoritative server의 IP address를 보내준다. 다시 client는 authoritative server 중 하나로 접속하고, server는 host name "www.amazon.com"의 IP address를 보낸다.
TLD server: com, org, net, edu 같은 상위 레벨 도메인과 kr, uk, fr 같은 모든 국가의 상위 레벨 도메인에 대한 것을 담당한다.
Local DNS server: DNS server들은 hierarchical 구조를 가지고 있지만, Local DNS server는 별도로 존재한다.
대학, 학과, 회사, 지역의 ISP 같은 곳들은 local DNS server를 갖는다.
local DNS server는 host에 가깝게 존재한다. host가 ISP에 연결될떄, ISP는 local DNS server로 부터 IP address를 host에게 제공한다. - 정리
user가 browser에서 "www.amazon.com"을 입력 후 enter. (IP address를 바로 입력하면 좋겠지만..) user는 DNS client가 되어 DNS server로 설정된 server에 질의를 함.
이 질의는 "recursive query"라고 함. "recursive query"의 의미는 어떤 요청에 대한 응답으로 바로 해를 주는 것으로 생각된다.(IP address를 return 해주던지, 없다고 하던지..)
질의를 받은 local DNS server가 이 요청에 대한 답을 가지고 있지 않으면, 다른 DNS server에게 요청을 다시 한다. DNS server로 동작할시 해당 서버는 한가지 목록을 갖는데, 이것이 root DNS server의 list 이다. root DNS server에게 "www.amazon.com"에 대한 질의를 다시 보낸다. 이러한 질의를 "iterative query"라고 한다.
root DNS server는 받은 요청에 대해, "com"을 관리하는 TLD DNS server에 대한 IP address를 알려준다. local DNS server는 다시 "www.amazon.com"을 "com"을 관리하는 TLD DNS server에게 요청을 하고, TLD DNS server는 "www.amazon.com"을 관리하는 authoritative server의 IP address를 알려준다.
local DNS server는 다시 authoritative server로 "www.amazon.com"을 요청하면, authoritative server는 요청한 host name에 대한 IP 정보를 알려준다.
local DNS server가 IP address를 알게 되면 이것을 browser에게 알려주고, browser는 그 IP address를 가지고 TCP/IP communication을 할수 있게 되어, HTTP protocol로 web server에게 service를 요청하고, 응답을 받게 된다. - authoritative server: host의 domain name을 등록기관에 등록하면, 이 기관에게 일정 비용을 제공하게된다. 이 기관의 DNS server는 host의 domain name과 IP address를 mapping하는 역할을 할 것이다. 등록 기관에 host name을 등록할때는 primary authoritative server와 secondary authoritative server의 name과 IP address를 등록기관에 제공해야 하며, 등록기관은 이 authoritative server가 TLD DNS server에 등록되도록 한다.
* P2P application
- Data sharing을 위해 최소한의 서버 의존도를 가지면서, peer pair가 서로 직접 통신하는 구조.
P2P 구조는 self-scalability를 잘 보여주며, BitTorrent protocol, Skype가 그 예다. - Client-Server vs P2P
server의 connection link의 upload speed를 Us, i-th peer의 connection link의 upload speed를 Ui, i-th peer의 connection link의 down speed를 Di , 분배되는 파일의 크기를
F bit, 다운 받는 peer들의 수는 N. Distribution time(Dt)은 모든 N개의 peer들이 파일의 복사본을 얻는데 걸리는 시간.
대역폭은 풍부하다고 가정할때,
Client-Server 구조에서, server는 FN bit를 전송해야 하고, server의 upload speed가 Us이므로, Dt는 적어도 NF/Us 이다.
또는 Dmin이 가장 낮은 다운 로드 속도를 가진 peer의 다운로드 속도라고 할때, F/Dmin보다 적은 시간안에 모든 peer들은 F bit를 얻을수 있다. Dt = F/Dmin.
따라서, Dt의 하한값은 max(NF/Us, F/Dmin) 이 된다. N이 증가할 수록 Dt는 선형적으로 증가하게 된다.
P2P 구조는 각 peer들은 분배받은 file data의 일부분을 다른 peer들에게 재분배 할수 있다. peer들에게 F bit의 file을 주기 위해 최소 한번만 전송하면 되므로, Dt=F/Us.
또는 가장 낮은 다운로드 속도를 가진 피어에 의해 F/Dmin.
또는 시스템의 전체 upload 용량은 전체적으로 server의 upload 속도와 각 peer의 upload 속도를 더한 것으로, Utotal = Us + U1 + ... Un 이 된다.
따라서, P2P의 최소 분배시간에 대한 하한값은 max(F/Us, F/Dmin, NF/Utotal)이다.
N의 수가 증가함에 따라, Client-Server의 Dt의 값이 선형적으로 증가하지만, P2P에서는 Dt가 Client-Server구조보다 거의 작다. (증명 안함.) - BitTorrent
파일 분배에 참여하는 모든 peer들의 모임을 torrent라고 함.
torrent에 참여하는 peer들은 서로에게 같은 크기의 chunk를 download 함.
보통 chunk size는 258kb 임.
torrent는 tracker라고하는 node를 가지고 있다. 한 peer가 torrent에 접속하면, tracker에 자신을 등록하고, 주기적으로 자신이 torrent에 아직 있음을 알림.
tracker는 이것을 이용하여 torrent에 참여하는 peer들을 추적함.
새로운 peer가 오면 tracker는 peer list에서 임의의 peer를 50개 선택하여 그들의 IP주소를 새로운 peer에게 보냄.
50개의 peer의 IP를 받은 peer는 동시에 TCP connection을 설정한다.
시간이 지나면서 어떤 peer는 torrent을 나가기도하고, 새로 들어오기도 한다.
임의의 시간에 각각의 peer들은 가지고 있는 파일의 chunk list를 가지고 있다. 각 peer들은 이웃 peer들에게 chunk list를 요구하고, 이 list를 받으면, 자신이 가지고 있지 않은 chunk에 대해 요청을 한다.
- 어느 chunk를 먼저 요청할 것인가? , 어느 peer에게 chunk를 요청할 것인가?
rarest first policy를 사용한다. 즉, 이웃들이 가진 chunk들 중에서 가장 드물게 있는
chunk부터 요청한다.
- 어느 요청에 대해 요청받은 peer는 어떻게 응답하는가?
이웃들 중에서 가장 빠른 속도로 자신에게 chunk를 제공해 주는 peer에게 우선순위를
준다.
free-riding: 한 peer가 파일을 upload하지 않고, file sharing system에서 file을 download하는 것. 이러한 것은 BitTorrent에서는 허용되지 않는다. file을 download 하기 위해서는 동시에 적정한 속도로 upload 해야 하기 때문이다. - P2P community에서의 information retrieval
P2P application에서의 한가지 주요 요소는 information index이다.
이것을 통해 data를 host로 mapping 시킬수가 있는 것이다.
한 peer가 특정 file에 대해 요청을 하기위해서는 해당 file의 chunk를 가진 peer에 대한 list가 필요하다. 이 리스트에 대한 정보를 관리하는 것이 색인이다.
색인안에는 peer community가 공유하는 각각의 file에 대한 복사본을 어느 peer가 가지고 있는지 IP와 함께 기록되어 있다.
색인은 information index는 peer가 torrent에 들어오고 나감에 따라 동적으로 갱신된다.
한 peer가 torrent에 들어오면 자신이 가진 file의 색인을 system에게 보낸다. 한 peer가 특정 파일을 요청할때, system의 index를 검색하고, 파일의 사본을 가진 peer들을 찾은 후 해당 파일을 download 하게 된다. - centralized index
index service는 대게 server에서 제공된다. user가 P2P file sharing application을 이용할때, 해당 application은 자신의 IP와 공유를 위해 제공하는 file의 이름을 색인 서버에게 알린다. 서버는 이러한 정보를 모아서 IP address set과 file의 복사본을 mapping하는 동적 색인을 한다.
이러한 색인 방법을 centralized index 라고하며, 식제로 P2P file sharing system은 P2P와 client-server 구조의 혼합형이다.
- 고장 문제: 색인 서버의 동작에 문제가 생기면 전체 시스템에 문제가 생김.
- 병목 문제와 기반 주고 비용: P2P 사용자가 많을 수록 매우 큰 색인을 유지관리 해야함.
- 저작권 침해: 허가되지 않은 콘텐츠를 무료로 쉽게 공유 할 수 있다. - query flooding
색인은 peer community상에 완전히 분산되어 있다. 각 peer는 공유하려는 file에 대한 색인을 한다.
query flooding에서 peer들은 overlay network이라는 추상적인 논리적 network를 형성한다.
peer X와 peer Y가 TCP 연결을 유지하면, X와 Y 사이에 edge가 존재하게 된다.
모든 활동중인 peer들과 연결된 links는 overlay network를 형성한다. 물리적인 communication link가 아닌 logical link이다.
전체적으로는 overlay network에 참여하는 peer가 굉장히 많지만, 특정 peer의 기준에서 보면 보통 10개 정도의 network을 형성한다.
peer들은 이 overlay network에서 이미 존재하는 TCP connection을 통해 이웃 peer들에게 message를 보낸다. 이 message를 받은 peer들은 만약 일치하는 것이 있으면, query-hit message를 역으로 전송한다. 만약 없으면 다시 message를 연결된 peer들에게 보낸다. 이러한 과정은 hit가 될때까지 이루어지며, 최초 요청을 보낸 peer에게 hit message가 가면, 이 정보를 이용하여 원하는 file의 사본을 갖는 peer를 찾아 낼수 있다.
- 문제는 query flooding이 굉장한 traffic을 초래한다는 것이다.
따라서, limited-scope query flooding 기법이 제시되었다. 초기 query 를 보낼때, message에 있는 peer-count field에 제한값(예:7)을 설정하고, 한번 peer에 도착할때마다, 그 field의 값을 줄인다. '0'이 되는 순간 더이상 query를 전달하는 것을 멈춘다.
댓글 없음:
댓글 쓰기