application Layer을 5가지 section 에서 논의한다
section 5가지
1. 인터넷에서 제공되는 nature 와 application 의 두가지를 논의한다.
client-server paradigm , peer-to-peer paradigm .
2. client-server paradigm의 개념에대해 논의하고, 이 paradigm 이 internet user에게 어떻게 서비스하는지.
3. predefined 거나 standard application client-server 에 기반한, 유명한 popular applications (웹서핑, 파일 전송, 이메일보내기)
4. concept protocols peer-to-peer 파라다임. chord, pastry,kademlia 또 유명한 application 을 알아볼것이다( protocol 을 사용하는)
5. server 와 client 를 위한 c 언어 프로그램을 작성하는 것을 배울 것이다.
2.1 INTRODUCTION
application layer 는 사용자에게 서비스를 제공한다. logical connection 을 통해서 communication 을 하는데 . 이것은 두개의 application layers 가 마치 직접연결되 있는것처럼 보이게한다. (logical 한 연결! , physical 이 아니라.) - two way
실상은 많은 devices 와 physical channels 에서 일어난다.
2.1.1 Providing Services
Internet 전에 communication network 는 네트워크 유저에게 service하도록 제공되었다 . 대부분 이 네트워크들은 그러나 한가지 특정한 서비스였다. 예를들면 전화기는 목소리서비스만. 제공 , 이러한 네트워크는 그러나 후에 다른 서비스에도 사용되었다 ( fax같이 몇몇의 hardware 를 추가 )
Internet 은 원래 같은 목적으로 designed 됐다. 그러나 TCP/IP protocol 의 layered approach 는 인터넷을 더 flexible 하게 만들었다.(postal 이나 전화기 네트워크보다). 각 층은 한개 이상의 protocol 에 의해서 만들어졌지만, 새로운 protocol 이 추가되거나 삭제 되었다. 그러나 protocol 이 각 층에 더해진다면 lower layer 에 있는것 중 하나가 사용되고, 제거된다면 higher layer 에서 제공되는 protocol 을 수정해야한다. ( 뭔소리?)
application layer 는 다소 highest layer 로써 다른 레이어와 다르다. 이 layer 의 protocol 은 다른 protocol 에게 서비스를 제공하지 않는다. 단지 transport layer의 protocol 로 부터 service를 받는다. 이것은 protocol 이 application layer에서는 쉽게 삭제 될수 있음을 의미한다. 새로운 프로토콜이 전송 계층에서 제공되는 서비스를 사용하는 한 새로운 프로토콜이 application layer 에 적용될 수 있다는것이다.
application layer 는 단지 internet user 에게 서비스를 제공하는 계층이며, 응용계층의 유연성은 새로운 응용프로토콜이 쉽게 인터넷에 추가될 수 있도록하며, 이것은 internet 의 lifetime 동안 흔하게 일어난다. 인터넷이 생성될때, 몇개의 application protocols 만이 유저가 사용가능했지만, 오늘날은 계속 더해져 왔기 때문에 갯수를 셀 수 가없다.
standard and Nonstandard Protocols
smooth operation 을 제공하기 위해서, TCP/IP 의 첫 네가지 계층에서 사용되는 protocol은 standardized 되곡 documented 되어야한다. 그들은 WINDOWS 나 UNIX에 내장된 패키지의 부분이 된다. 그러나 application-layer protocol 은 standard 이기도하며 nonstandard 이기도하다.
standard Apllication-Layer Protocols
인터넷상에는 standardized 되고 문서화 된 프로토콜이 몇가지 존재한다. 우리는 그것을 daily interaction 에서 사용한다. 이러한 standard protocol 은 사용자간에 interact 하는 program 과 사용자에게 특정한 서비스를 제공하는 transport layer 의 쌍이다.우리는 이장의 뒷부분에서 standard application 에 대해서 논의한다. 이러한 유형의 application protocols 은 그들이 제공하는 타입이 뭔지 , 어떻게 작동하는지 알아야한다. (이 application 에서 사용할 수 있는 option 도 존재)
이러한 프로토콜의 공부는 네트워크매니저가 이러한 프로토콜을 사용할떄 일어나는 문제점을 더 잘 해결할 수 있도록 한다. 이러한 프로토콜에 깊은 이해는 또한 nonstadard protocol을 생성하는 idea 를 제공한다.
Nonstadard Application_Layer Protocols
transport layer 와 상호작용함으로써 유저에게 서비스를 제공하는 프로그램을 작성할 수 있다면 nonstard application-layer program 을 작성할 수 있다. 후에 이장에서 우리는 이러한 프로그램을 어떻게 작성하는 지 배울 것이다. 이러한 프로토콜(internet authority 의 찬성을 필요로 하지않는, 사적으로 사용)을 만드는것은 internet 을 더욱 popular 하게 만든다 . private company 는 새로운 customized application protocol 을 만들어 그들의 사무실과 세계와의(앞에 네가지 계층에서 제공되는) 소통을 하도록한다. standard application programs 을 사용하지 않고. 프로그램을 작성하기 위해필요한것은 transport-layer protocols에서 제공되는 능한 서비스를 사용하는 것이다. (computer language 중에 하나로)
2.1.2 Application-Layer Paradigms
internet 을 사용하기 위해서는 두가지 application program (서로 소통하기 위해) 을 필요로한다. (세계의 어떤곳에 있는 컴퓨터의 프로그램과 , 다른 곳에 있는 컴퓨터의 프로그램 간) 두가지 프로그램은 인터넷 인프라스트럭쳐를 통해서 서로간에 메시지 전송을 필요로한다. 그러나 , 우리는 두 프로그램간 어떤 관계인지 생각해본 적이 없다. 두가지 application programs 은 서비스를 요청하고 제공할 수 어야하나 아니면 한가지만 가능해야 하는가? 이 두가지 paradigm 은 인터넷 발생과정동안 발전해왔다. client-server paradigm 과 peer-to-peer paradigm 이다. 우리는 간단하게 이두가지를 여기서 언급하지만 이챕터의 뒷부분에서 자세하게 배울 것이다.
Traditional Paradigm : Client-Server
Traditional paradigm 은 client-server라 불린다. 이것은 몇년 전부터 가장 잘 사용된다. 이 패러다임에서 service 제공자는 server process 라불리는 application program 이다. 이것은 연속적으로 실행중이며 , 다른 application 을 기다린다. (client process 라불림), Internet 을 통하여 연결을 만들고 service 를 요청한다. 평균적으로 특정한 타입의 서비스를 제공하는 서버 프로세스들이 존재하지만, 그러나 많은 서버 프로세스로 부터 서비스를 요청하는 많은 clients 들이 존재한다. 셔벼 프로세스는 반드시 항상 실행중이여야 한다. client process 는 client 가 서비스 받기를 원할 때 시작된다.
client-server paradigm 은 territory internet 에서의 서비스와 비슷하다. 예를들면 전화 연결센터는 서버로 , 전화를 요청하는 구독자는 client 로 여겨진다. directory cent 는 반드시 항상 준비중이여야하고 , 구독자는 잠깐동안 서비스가 필요할때 요청한다.
client-server paradigm은 두 application program 간에 커뮤니케이션이지만, 각 프로그램의 역할은 완전 다르다. 다른말로 , 우리는 client program 을 server 프로그램으로써 사용할 수 없고, 역도 그렇다. 이 장의 뒷부분에서, client-server programming 에 대해서 말할 때, 우리는 각 서비스의 타입으로 작성된 두가지 application program 을 필요로 한다. 한가지 이 패러다임의 문제점은 communication load 의 집중이 서버에게되고 , 이것은 서버는 powerful computer 여야 한다는 것을 의미한다. powerful computer 조차도 많은 고객이 동시에 서버로 연결을 시도한다면 벅차다. 또다른 문제점은 서버제공자는 기꺼이 cost 를 수용하고, powerful server 를 만들어야한다. 이것은 service 가 서버에게 수입의 형태로 돌아와야한다.
WWW 나 HTTP FTP SSH Emai 등이 있다. 우리는 이러한protocol 과 applcation 을 이장에 나중에서 의논할것이다.
New paradigm : peer to peer
p2p 라불리는 패러다임이 새로운 application 의 요구에 응답하기 위해 등장했다. 이 패러다임에서는 항상 실행중이고 , client 를 기다리는 서버프로세스 의 필요가 없다. responsibility 는 두 peers 가 공유한다. 인터넷에 연결된 computer 는 서비스 제공도하고 서비스를 받기도 한다. 심지어 보내는것과 동시에 받을 수도 있다.이 패러다임에 딱맞는 영역은 Internet telephony . phone 에 의한 의사소통은 그대신에 peer-to peer 활동이다. ; 계속 실행중이여야하는 party가 존재하지 않는다. 또다른 p2p paradigm 은 몇몇의 인터넷에 연결된 computer 가 서론간에 공유할필요가 있는경우이다. 예를들면 다른 인터넷유저와 공유할수 있는 파일을 가진 인터넷 유지가있다면 서버같은 파일홀더나 서버 프로세스 가 필요 없다.
p2p 는 쉽게 측정가능하고, 비용면에서 효율적이다 ( 비싼서버의 실행과 유지가 필요없어) 그럼에도불구하고, 몇가지 문제가있다. 주된 문제는 보안이다. 이것은 secure communication (분리된 서비스간) 에 보안을 생성하기가 server 에 의해서 제어된것보다 어렵다. 또다른 문제는applicability 이다. 이것은 모든 응용이 이 패러다임을 사용가능한것이 아니다. 예를들면 많지않은 인터넷 유저는 이것을 포함할 준비가 안되었다. 만약( web이 p2p 라면)
bitTorrent, Skype , IPTV internet 전화, 등등이 사용한다. 이것의 응용에대해서 이 장에서나중에 설명하고, 다른 것은 다른 챕터에서 볼것이다.
Mixed Paradigm
application은 두 가지의 장점을 결합하기도한다. 예를들면, light-load c-s communication 은 peer 의 주소를 찾는데 사용된다. 어드레스를 찾으면 실제 서비스는 p2p 를 이용한다.!
2.2 CLIENT-SERVER PARADIGM
application layer 에서 communication 은 두 proceessr간에 일어난다. cleint 가 요청을 함으로써 communication 을 시작하고 , 서버는 그 요청을 기다리는 또다른 응용 프로그램이다. 서버가 그 요청을 handle 하고, 결과를 준비한 후 결과를 client 에게 보낸다. 이 서버의 정의는 서버는 요청이올때까지 항상실행 중이여야 한다는것이지만, client 는 필요할 때만 실행된다는 것이다. 이것은 우리가 두 컴퓨터를 연결하고 싶다면, 우리는 하나는 client 하나는 server 여야한다. 하지만 우리는 서버프로그램이 client 를 실행하기전에 실행중이여야하는것을 유의해야한다. server 의 lifetime 은 무한한것이다. 항상 실행중이고 client를 기다려야한다. client 의 lifetime 은 유한하다. 유한개의 요청을 보내고, 응답받고, 멈춘다.
2.2.1 Application Programming Interface
client process는 어떻게 server process 와 통신할까? 컴퓨터 프로그램은 보통 미리정의된 명령어(컴퓨터가 뭘하는지 말하는) 의 셋으로 작성된다. 컴퓨터 언어는 수학적 명령어, 문자열조작 명령어, 입출력 등의 명령어의 집합이다. 우리가 만약 다른 프로세스와 통신할필요가 있다면, 우리는 우리는 TCPIP 의 네가지 하위영역에게 연결을 형성하라는 명령어를 필요로한다(, 데이터를 보내고 받고, 연결을 끊으라는. 이러한 명령어는 보통 Application Programming Interface(API) 라고 한다. interface 는 두 개체간의 명령어의 집합이다. 이 경우, 하나의 개체는 Application layer 의 프로세스고, 또다른 하나는 os 이다(4가지 레이어를 캡슐화하는). 컴퓨터 생산자는 4가지 레이어를 os안에 내장시키고 API 도 포함시켜야한다. 이 방법에서, application player 프로세스는 메시지를 주고받을때 os 와 통신 가능하다. 몇몇의 api는 통신을 위해서 디자인 되었다. 3가지가 자주쓰인다. socket interface, transport layer interface, STREAM 등이다. 이 섹션에서 우리는 간단하게 socket interface 에 대해서만 언급한다. application layer 의 일반적인 개념만 주기 위해서.
socket interface 는 버클리에서 유닉스의 환경의 일부로 사용됐다. 소켓 인터페이스는 application layer 와 os 간의 통신을 제공하는 명령어의 집합이다. 또한 이것은 프로세스와 프로세스 간의 통신도 지원한다. 소켓의 개념은 우리가 이미 프로그래밍 언어로 디자인된 명령어들을 사용할수 있도록 해준다. 예를 들면, 대부분의 컴퓨터언어 에서는 데이터를 소스나 싱크로 부터 읽고 쓸수 있다. (keyboard - source, monitor - sink, file - source or sink). 우리는 같은 명령어를 사용하여 소켓을 읽을수도 소켓으로 쓸 수도 있다. 다른말로 우리는 보내거나 데이터를 송수신하는 방법을 바꾸는 대신 그냥 source sink 를 추가하기만 하면된다. 2.5그림은 소켓과 다른 소스싱크를 비교하는 그림이다.
Sockets
소켓은 터미널이나 파일처럼 생각되지만 그것들처럼 물리적 개념은 아니다. 추상적이다. application lprogram 에서 사용되고 생성되는 자료구조이다.
우리는 application layer 가 관련되는 한, client process 와 server process 간의 통신은 두 소켓간에 통신이다. (두 ends 에서 생성된) . client 는 socket 이 요청을 받고 응답을 주는 개체라고 생각한다. 서버는 소켓이 request를 지니고 , response 를 필요로한다. 만약 두 소켓을 만들었다면, 하나에는 각 end , source 와 destination 의 주소를 정확하게,정의하고, data 를 보내고 받는 이용가능한 명령어를 사용할 수 있다. 나머지는 os 의 책임과 TCP/IP protocol 이다.
Sockets Address
client 와 server 는 two-way communication 이다. 우리는 pair of address 를 필요로한다. local(sender) and remote(receiver). local address (한방향의) 는 다른방향으로의 remote address 이다. 역으로도 성립. c-s 패러다임에서 통신은 두 소켓간이므로, 우리는 소켓 address 의 쌍이 필요하다. local socket address 와 remote socket address . 하지만, 우리는 소켓주소를 identifiers 라는 용어로 정의한다
socket address 는 client 나 server 가 실행중인 컴퓨터에서 정의되어야 한다. 챕터 4에서 논의할건데, 인터넷의 컴퓨터는 유일하게 IP address 로 정의되고, 32비트 정수가 사용된다. 하지만 몇몇의 고객과 서버 프로세스는 한 컴퓨터에서 동시에 실행된다. 이것은 우리가 특정한 클라이언트와 서버를 또다른 식별자로 정의할 필요가 있다는 것이다. chapter3 에서는 application program 은 port 번호로 (16bit) 정의된다. 이것은 소켓주소가 IP address 와 port number 의 조합이어야 한다는 것이다!
socketaddress - IP address + port number
socket 은 end-point 의 통신으로 정의되기 때문에 socket 은 local 과 remote 의 쌍이라고 말할 수 있다.
Example 2.1
우리는 two-level 주소를 찾을 수 있다( telephone communication 에서) . 전화번호는 조직을 정의하고, extension은 조직간에 연결을 정의한다. 전화번호는 IP address (조직을 정의) extension 은 port number 와 유사하다. 특정한 연결을 정의한다.
Finding Socket Address
클라이언트나 서버는 어떻게 socket address 를 찾을까? 상황은 각 site 마다 다르다
server site
서버는 local(server) remote( client) 의 소켓어드레스를 필요로한다
local socket Address - local socket address 는 os 에 의해서 제공된다. os 는 그 컴퓨터의 ip 주소를 알고있다( server process 가 실행중인) . 그러나, 서버프로세스의 포트넘버는 할당될 필요가 있다. 만약 서버 프로세스가 인터넷 권한자에 의해 정의되언 표준이라면, 포트 넘버는 이미 할당되어 있다. 예를 들면 할당된 포트번호가 http 를 위한거라면 , 80번이다. 이거은 다른 프로세스로 사용될 수 없다. 우리는 잘알려진 포트번호에 대해서 3장에서 언급할 것이다. 만약 서버 프로세스가 표준이 아니라면 서버 프로세스 디자이너는 포트넘버를 고를 수 있다. 지정 된 범위안에. 서버가 실행되면, local socket address는 알게된다.
Remote Socket Address - 이 주소는 connection 을 만드는client 의 소켓 주소이다. 서버가 많은 클라이언트와 연결하기 떄문에 remote socketaddresss를 미리 알수 없다! 서버는 클라이언트가 서버와 연결하고자 할때 찾을 수 있다. 클라이언트 소켓 주소는 요청 패킷에 들어있고 이주소는 remote socket address가 된다. 다른말로 로컬 소켓주소는 고정되고 lifetime동안 사용되지만 , remote socket address 는 다른 client 마다 각각 바뀐다.
client site
client 는 local ( client) 와 remote( server) socket address 를 필요로한다.
Local socket Address - os 의해 제공된다. ip주소를 알지만 , port number는 프로세스가 통신을 시작해야 할때 할당 받는 16비트 정수이다. 포트넘버는 Inter authority 에 의해서 정의되고, ephemeral(temporary) port number 라 불린다. os는 그러나 새로운 포트넘버가 다른 client process 에서 사용되지는 않는다.
Remote Socket Address
remote socket address 를 찾는것은 더 힘들다. client process 가 시작하면, 연결하고자하는 서버의 소켓주소를 알아야한다. 우리는 두가지 상황을 가진다.
1. 때때로, client process 를 시작하는 사용자는 server port number 와 서버가 실행중인 컴퓨터의 아이피주소를 안다. 이것은 보통 client 와 server application 을 작성하고, 그것을 실행할 때 이다. 예를들면 이장의 마지막에서 우리는 간단한 client 와 server program 을 이 방식으로 테스트한다. 이 상황에서 프로그래머는 두조각의 정보를 제공한다 client program 을 실행할 때.
2. standard application 이 잘 알려진 포트 번호일 지라도, 대부분의 경우 우리는 IP 주소를 모른다. 이것은 어떤 web page 와 연결할때, email 을 보낼때, 파일을 다운받을 때 등등이 있다. 이 상황에서 서버는 이름, 서버 프로세스에서 정의된 식별자를 갖는다. 예를 들면 이 식별자가 URLS www.xx.yyy 나 이메일 주소 이다. client process는 이 식별자(name ) 을 server socket address 에 밪게 변환한다. 이 client process는 보통 oprotnumber 를 안다. 잘알려진 것이므로, 그러나 IP address 는 대부분 또다른 client server application (DNS) 를 이용하여 얻는다. 우리는 나중에 DNS 에 대해서 논의한다. 하지만 인터넷에서 directory 처럼 수행된다 는것은 충분히 알고 있다. telephone directory 와 비교해보자. 우리는 누군가의 이름을 알고있다. 그러나 전화번호를 얻고싶다. 따라서 전화번호부를 통해서 번호를 찾는것이다. DNS map 도 서버 이름을 통해서 서버의 ip 주소를 찾는 것이다.
2.2.2 Using Services of the Transport Layer
process 의 쌍은 internet 사용자, 인간과 프로그램에게 서비스를 제공한다. 그러나 프로세스 쌍은 transport layer 로 부터 제공되는 서비스를 받아야한다. 왜냐하면 application layer 에는 physical communication 이 존재하지 않기 때문에. 우리는 1장에서 간략하게 언급했다. 그리고 3장에서 자세하게 배울 것이다. 3가지 저명한 transport layer protocol 이 TCP/IP 에 있다. UDP, TCP SCTP 이다. 가장 표준 application 은 이 세가지중 하나를 사용하도록 디자인 되었다. 새로운 application을 작성할 때 우리는 어떤 프로토콜을 작성하길 원하는지 결정해야 한다. transport layer protocol 을 선택하는 것은 application process 에 수용성에 엄청난 영향을 미친다. 이 섹션에서 우리는 각 프로토콜에 의해서 제공되는 서비스를 배움으로써 standard application 이 왜 그걸 사용하는지 이해하고, application을 작성할ㄷ 때 어떤것을 써야할지 이해하도록한다.
UDP protocol
UDP 는 connectionless, unreliable, datagram service 이다. 연결이없는 서비스란 말은 logical connection 이 two ends 간에 존재하지 않는다는걸 의미한다. 각 메세지는 datagram 이라 불리는 독립된 개체닌 패킷으로 캡슐화된다. UDP 는 같은 소스에서 같은싱크로 보내는 데이터들간에 관계를 찾아볼 수 없다. UDP 는 reliable protocol 이 아니다. 이것은 데이터가 손상되었는지 전송중에 체크함에도 불구하고, sender 에게 잃어버린 데이터를 다시 보낼것을 요구하지 않는다. udp는 장점을 지닌다 : 메시지 지향형이다. 이것은 전송될 메시지에 경계를 준다.
우리는 연결없고 비신뢰적인 서비스를 보통서비스와 비교할 수있다( 우체국을 통해) . 두 개체는 몇개의 편지를 교환 할 수있지만 우체국은 그 편지간에 아무런 연관관계를 알 수 없다. 우체국에서는 편지는 separate entity 이다(센더와 리시버간에), 만약 편지를 잃어버리거나 손상된다면, 우체국은 책임을 지지않는다 (최선을 다했음에도). application program 은 UDP 를 사용한다 이경우. 작고 간단한 메시지를 보내거나 , 속도가 신뢰성보다 중요한 응용에서. 예를들면 몇몇의 management와 multimedia applications application 이 잘 맞는다.
TCP protocol
TCP 는 connection-oriented, reliable, byte-stream service 이다. TCP 는 두개의 end 가 logical connection 을 생성하는것을 요구한다( 몇몇의 connection 생성 패킷을 통해서) . 이 단계는 handshaking 이라하며, 몇개의 parameter (data packets의 size , chunks of data 를 보관할 size of buffer 전체 메시지가 도착할 떄 까지) 를 설립한다. handshaking process 후에, 두 end 는 데이터의 모음을 보낼 수 있다. 양방향으로.
교환될 바이트에 번호를 부여함 으로 써, 바이트의 연속성이 체크된다. 예를 들면 몇몇의 바이트가 손실되거나 손상되면, 받는사람은 다시 보낼것을 요구한다. 이것은 TCP 를 신뢰성이있는 protocol 로 만든다.TCP 는 또한 flow control 과 congestion constrol 이 가능하다. chapter 3 에서배울것이다. TCP 프로토콜의 문제점은 메시지 지향형이 아니다 . 따라서 교환되는 메시지간에 경계를 넣을 수 없다.
우리는 연결지향형이고 신뢰성있는 서비스를 전화 회사와 비교할 수 있다. 만약 두 집단이 우체국이아닌 전화를 통해서 통신한다면, 그들은 연결을 한번만들고 말을 어떤 기간동안 통신할 수 있다. 전화서비스는 신뢰할수 있다, 만약에 알아들을수 없는말은 다시 해달라고 할 수 있다.
SCTP protocol
SCTP 는 TCP 와 UDP 의 조합이다. tcp 처럼 scp 는 연결지향형, reliable service 이지만 byte-stream 이아니다. 이것은 message oriented protocol 이다. 게다가 , scup 는 multiple stream service 이다 ( connection 으 여려개 세움으로써)
scpt 는 보통 reliabilty 와 비록 failure 가 일어나더라도 연결이 보장된다. 두개의 장점이 혼합
2.3 STANDARD cline-server applications
인터넷의 생애동안, 몇몇의 서버 고객 프로그램은 발전되왔다. 각 application 마다, 이용가능한 옵션에 대해서 알아야한다. 이러한 앱을 사용하는방법을알고, 각각 다른 서비스를 제공하는 방법에 대해서 알게 되면, 미래에 customize app 을 생성하는데 도움을 준다. 우리는 6가지 표준 앱을배운다. http, www, 을배운다. 왜냐하면 가장 많이 쓰이므로 , 우리는 또한file transfer , electronic mail처럼 high traffic 을 갖는 것을 도입한다. 다음 우리는 원격로그인과 이게 어떻게 성립하는지 설명한다.(ㅅTELNET ,SSH 프로토콜을 사용하여) , 마지막으로 DNS 에 대해서 배우고, 이것은 모든 application program 이 application layer 식별자와 상응하는 호스트 아이피주소를 매핑하는데 사용된다. 몇몇 다른 app DHCP,SNMP는 다른 장에서 배울 것이다.
2.3.1 WORLD WIDE WEB, HTTP
우리는 먼저 WWW 에대해서 배운다. 그리고 HTTP 에대해서 배운다. ( 가장 유명한 c-s application program )
World Wide Web
web의 아이디어는 유럽에 떨어져있는 연구자들 끼리 서로의 연구에 접근하기 위하여 도입되었다. 상업적 web은 1990 년에 시작되었다
오늘날의 web 은 문서(web page) 가 전세계에서 분리되고 서로 링크되어있는 정보들의 저장소 이다. 유명함과 웹의 성장은 두가지 용어와 관계된다. Distributed and Linked. Distribution 은 웹을 발전시킨다. 각 웹서버는 새로운 웹페이지에 더해지고, 모든 인터넷 유저에게 알릴 수있다( 서버를 오버로딩 하지않고) , Linking 은 한 웹페이지가 다른 웹페이지(다른서버에 저장된)를 가르킬수 있다는것이다. 웹페이지의 링킹은 hypertext 를 통해서 이어지고 이거ㅅ은 인터넷 도입전에 시작되었다. 이 아이디어는 자동적으로 다른 문서를 검색하는 기계 에서 부터 왔다. 웹은 전자적으로 이 아이디어를 구현하였다. 링크된 문서를 사용자가 링크를 클릭할때 검색되도록 하였다. 오늘날 하이퍼 텍스트는 링크된 텍스트문서를 의미하고, 이건 하이퍼미디어로 바뀌어왔다. 웹페이지는 텍스트 뿐만아니라 이미지, 오디오 , 비디오까지 변화했기떄문
웹의 목적은 링크된 문서를 검색하는것을 뛰어넘는다, 오늘날 웹은 전자쇼핑, 게임도 사용된다, 누군가는 라디오 , 티비,
Architectur
www는 오늘날 distribute client-server service 이고 client는 브라우저를 사용해 서버가 제공하는 서비스에 접근할 수 있다. 그러나 distributed 된 서비스는 sites 라고 불린다. 각 사이트는 한개 이상의 문서( webpage 를 갖는다. 웹페이지는 그러나 어떤 다른 웹페이지로의 링크를 가진다. 다른말로 웹페이지는 간단하거나 복잡하다. 간단한 웹페이지는 다른 웹페이지로의 링크가 없고, 복잡한 웹페이지는 다른 웹페이지로의 링크가 있다. 웹페이지는 이름과 주소를 갖는 파일이다.
Example 2.2
우리가 다른 텍스트를 참조하는 과학문서를 검색해야하고 , 또 어떤 이미지를 레퍼런스하는 문서를 검색해야 한다고하자. 주요 문서와 이미지는 두개의 다른 파일 ( 같은 사이트) 에 존재한다. 참도된 텍스트는 다른 사이트에 존재한다. 우리는 세개의 다른 파일을 다르므로 우리는 세개의 전체 문서를 보기위해선 세개의 transaction 을 필요로한다. 첫 transaction 은 메인 문서의 파일a 를 복사하고, 이 것은 2번쟤 3번째 파일로의 링크를 갖는다 . 메인 문서가 검색될 때, 사용자는 이미지로의 두번째 트랜잭션을 불러일으킬 수 있다. 만약 사용자가 레퍼런스 된 텍스트의 내용을 볼 필요가 있다면, 세번쨰 파일 을 클릭할 수 있다. A b 가 사이트 1에 있어도, 다른이름과 다른 주소를 갖는다. ㅈ
