인터넷이 어떻게 작동하는지 이해를 돕기 위해서 당신이 보통 쓰는 인터넷 기능들이 실행될 때 일어나는 일을 살펴볼 것이다 -- 문서의 맨 앞에 있는 LDP(Linux Documentation Project) 홈페이지의 이 문서 홈페이지를 살펴보자. 이 문서가
http://sunsite.unc.edu/LDP/HOWTO/Fundamentals.html에 위치하고 있다고 써있다면, 이것은 호스트 sunsite.unc.edu 아래의 웹 디렉토리 가운데 /LDP/HOWTH/Fundamentals.html 파일로 존재한다는 것을 의미한다.
먼저 당신의 브라우저가 해야 할 일은 보고자 하는 문서가 존재하는 컴퓨터와 네트워크를 통해 연결하는 것이다. 이것을 하기 위해서는 우선 sunsite.unc.edu라는 호스트('호스트'는 '호스트 머신' 또는 '네트워크 호스트'의 약자이다; sunsite.unc.edu는 보통 호스트네임이라 부른다)가 네트워크 상의 어느 위치에 존재하는지를 알아야 한다. 이 위치에 대응하는 것은 보통 숫자로 이루어져 있는데, 이것을 IP 어드레스라 한다('IP'라는 것에 대해서는 후에 다시 설명할 것이다).
이런 작업을 수행하기 위해서 브라우저는 네임서버라는 프로그램에 질문을 하게 된다. 네임 서버이 당신 서버에 존재하는 경우도 있지만, 보통은 네임서버 기능을 수행하는 특별한 머신이 존재하고 그곳에 질문을 하게 된다. 만약 당신이 ISP로부터 인터넷 서비스를 받게 되었을 때 설정 과정 가운데 하나는 ISP의 네트워크에 존재하는 네임서버의 IP 어드레스를 인터넷 소프트웨어에 알려주는 것이 될 것이다.
서로 다른 머신에 있는 네임서버들은 상호간에 통신을 하며, 호스트네임을 풀어내기 위한 정보들을 교환하고 새로운 데이타를 갱신한다. 당신의 네임서버는 sunsite.unc.edu라는 이름을 풀기 위해 네트워크 상에 존재하는 서너 군데 다른 사이트에 질문을 하게 되는데, 이 일련의 과정은 매우 빠르게 (보통 1초도 걸리지 않는다) 진행된다.
네임서버는 당신의 브라우저에게 sunsite의 IP 어드레스가 152.2.22.81이라는 것을 알려주게 될 것이다; 이것을 알면 당신의 머신은 sunsite와 정보를 직접 교환할 수 있게 된다.
브라우저로 Sunsite의 웹서버에 어떤 명령을 보내고자 한다면 다음과 같이 하면 된다:
GET /LDP/HOWTO/Fundamentals.html HTTP/1.0
이제 실제 어떻게 이것이 동작하는지 살펴보자. 일단 이 명령은 패킷으로 만들어진다. 패킷은 전보와 같이 정보의 묶음이라 생각할 수 있는데, 보통 이것은 중요한 세가지 정보로 포장되어 있다; 발송지 주소 (source address) (당신 컴퓨터의 주소), 목적지 주소(destination address) (152.2.22.81), 그리고 이것이 월드 와이드 웹의 요청이라는 것을 나타내는 서비스 번호(service number) 혹은 포트 번호(port number) (이경우 웹서비스의 요청이므로 80)가 그 세가지 이다.
그러면 당신 머신은 만들어진 패킷을 라우터라 불리는 특별한 기계에 도착할 때까지 통신선(ISP와 연결된 모뎀선 혹은 지역 네트워크)을 떠돌아다니게 한다. 라우터는 자신의 메모리에 인터넷의 지도를 가지고 있다 -- 항상 모든 지도를 메모리에 가지고 있지는 않지만, 당신의 네트워크 주위에 대한 것과 인터넷에 존재하는 다른 이웃의 라우터를 사용할 수 있는 방법을 알고 있다.
당신의 패킷은 목적지에 도달하기 위해 몇몇의 라우터를 거치게 될 것이다. 라우터는 매우 똑똑해서 다른 라우터가 패킷을 받아서 처리하는 데 얼마나 걸리는지를 관찰한다. 그리고는 가장 빠르게 목적지에 도달할 수 있는 연결을 설정하게 된다. 만약 다른 라우터(혹은 케이블)가 사용할 수 없게 되었을 때에도 이 정보를 이용하여 다른 경로를 찾아 패킷을 전송할 수 있다.
일설에 의하면 인터넷이 핵전쟁에도 견딜 수 있도록 설계되었다고 한다. 이것은 사실이 아니지만, 인터넷의 설계는 미지의 장소에서 정상적으로 동작하지 못하는 하드웨어가 있을 때에도 안정적인 성능을 낼 수 있도록 매우 훌륭하게 설계되었다. 이것은 몇개의 집중적인 스위치(전화망처럼)에 의한 것이 아니라 연결에 대한 정보를 수천개의 라우터에 분산시켜 놓았기 때문에 가능한 일이다. 이런 설계는 어떤 문제가 발생했을 때 그 영향을 국지적으로 만들 수 있고, 그 주위의 네트워크는 안전하게 유지될 수 있게 한다.
한번 당신이 보낸 패킷의 목적지까지 도달하게 되면, 목적지의 머신은 서비스 번호를 보고 패킷을 웹서버에 넘기게 된다. 웹서버는 명령 패킷의 발송지 주소 (IP 어드레스)를 보고 어디로 응답을 보내야 할지를 판단한다. 웹서버가 명령에서 요청한 내용을 돌려줄 때, 그 내용은 여러개의 패킷으로 나누어 보내게 된다. 패킷의 크기는 서비스의 종류와 네트워크의 전송 매체의 종류에 따라 다르게 바뀐다.
어떻게 여러 개의 패킷 전송이 관리되는지를 이해하기 위해서, 당신은 인터넷이 실제 두 개의 프로토콜을 이용하며, 그것은 하나가 다른 하나의 상위에 존재하는 구조라는 것을 알 필요가 있다.
아래쪽 단계인 IP(Internet Protocol)은 발송지에서 목적지로 보내는 각각의 패킷을 어떻게 취할 것인지에 대한 정보를 담고 있다 (위에서 말한 IP 어드레스를 왜 그렇게 부르는지 이해가 될 것이다.) 하지만, IP는 믿을만 한 것은 아니다; 만약 패킷이 분실되었을 경우 발송지나 목적지의 머신 모두 그 사실을 알 수 없다. 전문적인 네트워크 용어로 IP를 연결이 없는(connectionless) 프로토콜이라 한다; 보내는 쪽은 단지 패킷을 받는 쪽을 향해 보내지만 그 승인 여부를 확인할 수는 없다.
IP는 하지만 빠르고 경제적이다. 때때로는 신뢰도가 좀 떨어지더라도 빠르고 경제적이라는 것만으로도 충분하다. 만약 당신이 네트워크를 이용해 Doom이나 Quake와 같은 게임을 한다면, 당신이 쏜 총알은 IP 패킷을 통해 표현이 된다. 만약 그 일부가 사라지더라도 그렇게 심각한 문제는 아닐 것이다.
상위 단계인 TCP(Transmission Control Protocol)은 이에 비해서 믿을만하다. 두 머신이 TCP로 연결되어 있을 때(TCP 연결은 IP를 이용하여 이루어진다), 수신하는 쪽은 자신이 받은 패킷들에 대한 확인을 송신한 쪽에 보내준다. 만약 송신한 쪽에서 그 확인을 지정된 시간동안 받지 못하면, 그 패킷을 다시 보내게 된다. 게다가 송신하는 쪽은 각각의 TCP 패킷에 일련 번호를 부여하는데, 이것은 수신하는 곳에서 패킷을 정해진 순서로 다시 구성할 수 있게 한다. (만약 연결되어 있는 중에 네트워크가 불안해지면 패킷의 일련번호가 뒤바뀌어 수신될 수 있다.)
TCP/IP 패킷은 또한 잘못된 연결을 통해 발생할 수 있는 데이터의 손상을 확인하기 위해서 체크섬(checksum)을 가지고 있다. 따라서, TCP/IP와 네임서버를 사용하는 사람의 시점에서 보면, 정보가 두 개의 호스트네임/서비스-번호 사이에서 통신되는 것을 신뢰할 수 있다. 내트워크 프로토콜을 제작하는 사람들은 패킷을 만드는 일과, 그 패킷을 다시 구성하는 일, 에러 확인, checksum을 확인하는 일, 그리고 그 아래 단계로 계속 재전달되는 모든 일을 다 고려할 필요가 없다.
아까 살펴본 예제로 되돌아가 보자. 웹 브라우저와 서버는 TCP/IP의 최상위에서 정보 교환이 이루어지는 응용 프로토콜을 이용하여 대화하게 된다. 응용 프로토콜은 TCP/IP를 이용하여 일련의 정보를 서로 교환하게 된다. 이런 프로토콜을 HTTP(Hyper-Text Transfer Protocol)이라 하고, 위에서 살펴본 GET이란 명령어는 프로토콜에서 사용되는 명령어의 한 예라 할 수 있다.
GET 명령어가 sunsite.unc.edu의 웹서버에 서비스 번호 80과 함께 전달되면, 이것은 80번 포트를 관찰하고 있던 서버 데몬에 의해 재빨리 처리된다. 이 데몬은 보통 때에는 단지 포트만을 관찰하고 있다가 어떤 명령이 들어오는 경우에만 그 명령을 수행한다.
만약 인터넷이 하나의 전체적인 규칙을 갖도록 설계되었다면, 모든 부분은 매우 간단하고 인간이 쉽게 접근할 수 있었을 것이다. HTTP와 그 비슷한 프로토콜 (호스트 사이에 메일을 주고받게 해주는 Simple Mail Transfer Protocol, SMTP도 그 가운데 하나이다.) 은 carriage-return/ line feed로 끝나는 출력 가능한 간단한 텍스트 명령을 이용하는 것이 일반적이다.
하지만 이것은 매우 비효율적이다; 어떤 환경에서는 융통성이 없이 견고하게 짜여진 바이너리 프로토콜이 보다 빠른 성능을 보일 수 있다. 하지만, 실험적으로 인간이 기술하고 이해하기 쉬운 명령어로 이루여졌다는 데에서 오는 장점이 효율성을 높이기 위해 만들어진 까다롭고 복잡한 명령 체계가 가져다 주는 어떤 장점보다 가치있다는 것이 알려져 있다.
따라서, 서버 데몬이 당신에게 TCP/IP를 통해 돌려주는 것 역시 텍스트이다. 그 응답의 시작은 보통 아래와 같이 이루어져 있을 것이다. (몇몇 헤더는 생략되었다):
HTTP/1.1 200 OK Date: Sat, 10 Oct 1998 18:43:35 GMT Server: Apache/1.2.6 Red Hat Last-Modified: Thu, 27 Aug 1998 17:55:15 GMT Content-Length: 2982 Content-Type: text/html
이들 해더 뒤에는 빈줄과 웹페이지의 텍스트가 따라올 것이다(연결이 끊어진 후). 당신의 브라우저는 단지 그 페이지를 화면에 보여주기만 한다. 헤더는 그 문서의 상태를 말해준다. (특별히 Content-Type 헤더는 응답으로 돌아온 자료가 HTML인지 말해준다.)