유닉스와 인터넷의 기초 (The Unix and Internet Fundamentals HOWTO) by Eric S. Raymond 번역 : 김한배, Anglahel@mail.hitel.net, hitel ID : Anglahel 번역본 v1.1, 1 July 1999 이 문서는 PC급 컴퓨터, Unix 계열의 운영체제, 인터넷의 기초 동작에 대해 비전문적인(non-technical) 용어로 설명하고 있다. ______________________________________________________________________ 목 차 (Table of Contents) 1. 소 개 (Introduction) 1.1 이 문서의 목적 (Purpose of this document) 1.2 연관된 자료 (Related resources) 1.3 이 글의 새 버전 (New versions of this document) 1.4 피드백과 교정 (Feedback and corrections) 2. 기초 컴퓨터 해부학 (Basic anatomy of your computer) 3. 컴퓨터의 스위치를 켜먼 무슨일이 일어나는가? (What happens when you switch on a computer?) 4. 쉘에서 프로그램을 실행하면 무슨일이 일어나는가? (What happens when you run programs from the shell?) 5. 어떻게 장치에 입력을 하며 작업을 중단하는가? (How do input devices and interrupts work?) 6. 컴퓨터는 어떻게 한번에 여러 가지 일을 할 수 있나? (How does my computer do several things at once?) 7. 컴퓨터는 어떻게 각 프로세스간에 방해를 받지 않을 수 있는가? (How does my computer keep processes from stepping on each other?) 8. 컴퓨터는 어떻게 디스크에 저장을 하는가? (How does my computer store things on disk?) 8.1 저수준(low-level)의 디스크와 파일구조 (Low-level disk and file system structure) 8.2 파일이름과 디렉토리 (File names and directories) 8.3 마운트 포인트 (Mount points) 8.4 어떻게 파일을 살펴볼 수 있나 (How a file gets looked up) 8.5 어떻게 파일 시스템이 잘못될 수 있는가? (How things can go wrong) 9. 컴퓨터 언어는 어떻게 작동하는가? (How do computer languages work?) 9.1 컴파일 언어 (Compiled languages) 9.2 인터프리티드 언어 (Interpreted languages) 9.3 P코드 언어 (P-code languages) 10. 인터넷은 어떻게 작동하는가? (How does the Internet work?) 10.1 이름과 위치 (Names and locations) 10.2 패킷과 라우터 (Packets and routers) 10.3 TCP/IP (TCP and IP) 10.4 HTTP, 응용프로그램의 프로토콜 (HTTP, an application protocol) ______________________________________________________________________ 1. 소 개 (Introduction) 1.1. 이 문서의 목적 (Purpose of this document) 이 문서는 리눅스와 인터넷을 직접 해보면서(doing) 배운 사람들에게 도움을 주기 위한 것이다. 이는 기술을 얻기 위한 좋은 방법이지만, 각자가 가지고 있는 기초 지식의 차이(이 차이는 무엇이 어떻게 돌아가는지에 대한 명확한 개념의 부족에서 비롯되는데, 따라서 창의적인 생각이나 효과적인 문제해결을 어렵게 만든다)로 인해 특정한 차이를 보일 수도 있다. 나는 될 수 있는 한 모든 부분에서 단순하고 이해하기 쉬운 언어를 쓸 것 이다. 이 글은 PC급 하드웨어에서 Unix 또는 리눅스를 사용하는 사람들 을 위한 것이다. 그럼에도 불구하고, 내가 이 글에서 다루고 있는 'Unix'에 관한 내용은 여러 플랫폼과 다양한 종류의 Unix에 모두 적용되는 것이다. 나는 당신이 인텔(Intel)의 PC를 쓴다고 가정하겠다. 만약 당신이 알파(Alpha) 나 파워PC(PowerPC) 또는 다른 Unix 박스를 쓴다면 세부적인 내용은 다르겠지만 기본개념은 같다는 것을 알아두기 바란다. 나는 반복해서 설명하지 않으므로 당신은 집중해서 읽어야 하지만, 이는 당신이 읽는 하나 하나의 글자에서 배울 수 있다는 것을 의미한다. 처음에는 그냥 대충 훑어보고 여러번 더 읽어서 이 내용을 완전히 당신의 것으로 만드는 것도 좋은 생각이다. 이것은 진화하는(evolving) 문서이다. 나는 독자들과의 피드백을 통해서 내용을 추가시킬 것이므로, 정기적으로 돌아와서 이 문서를 보길 바란다. 1.2. 연관된 자료 (Related resources) 만약 당신이 해킹기법을 배우기 위해 이 글을 읽는다면, 'How To Become A Hacker FAQ'을 읽어 보라. . 이 곳에는 다른 유용한 자료들도 링크되어 있다. 1.3. 이 글의 새 버전 (New versions of this document) 새 버전의 'Unix와 인터넷의 기초 HOWTO'는 [comp.os.linux.help] 와 [news.answers or news:answers]에 정기적으로 게시된다. 이들은 또한 LDP 홈페이지를 포함한 여러 리눅스 WWW나 FTP사이트에 업로드된다. 가장 최근의 글은 아래의 WWW 주소에서 찾을 수 있다 URL . 1.4. 피드백과 교정 (Feedback and corrections) 만약 이 글에 대한 질문이나 의견이 있다면 부담없이 esr@thyrsus.com {Eric S. Raymond}에게 메일을 보내기 바란다. (참고로 한국에 계신 분은 저에게 메일을 주셔도 되지요. 한배한테..) 나는 어떤 제안이나 비판 이라도 환영한다. 특히 더 자세한 설명이나 독특한 개념과 결합된 것에 대해서는 더욱 그렇다. 그리고 이 글에서 잘못된 부분을 찾는다면 다음 버전에서는 고칠 수 있도록 알려주길 바란다. Thanks. 2. 기초 컴퓨터 해부학 (Basic anatomy of your computer) 당신의 컴퓨터에는 프로세서 칩이 들어있고 이것이 실제적인 컴퓨팅(연산) 을 수행한다. 또한 내부(internal) 메모리를 가지고 있다(DOS/Windows 환경에서는 'RAM'이라 부르고 Unix 환경에서는 core라고 부른다). 마더보드(또는 메인보드)에 장착되있는 프로세서와 메모리는 컴퓨터의 핵심이다. 컴퓨터는 스크린과 키보드를 가지고 있다. 또 하드 드라이브와 플로피 디스크도 가지고 있다. 스크린과 디스크는 마더보드에 컴퓨터가 외부기기(outboard)들을 제어할 수 있는 콘트롤 카드를 가지고 있다. (키보드는 너무나 단순해서 별도의 카드를 필요로 하지 않는다; 콘트롤러는 키보드 동체에 내장되어있다) 더 자세한 내용에 대해서는 나중에 다루기로 한다. 지금은 그것들이 어떻게 함께 동작하는가에 대한 기초적인 것들만 생각하기로 하자. 모든 컴퓨터의 내부기기들(inboard)은 버스(bus)로 연결되어 있다. 외형상 버스는 콘트롤러는 카드를 끼우는 곳이다.(비디오 카드, 디스크 콘트롤러, 사운드카드 등) 버스는 데이터(data)를 프로세서, 스크린, 디스크, 기타 모든 곳으로 연결해주는 고속도로이다. 모든 것을 동작시키는 프로세서는, 혼자서는 다른 어떤 것도 알 수 없다. ; 얘는 버스를 통해서 다른 것들과 대화한다. 프로세서가 빠르고 직접적인 접근을 할 수 있는 유일한 부속품(subsystem)은 메모리(core)이다. 프로그램이 실행되기 위해서는 프로그램이 코어안에 있어야 한다. 컴퓨터가 디스크로부터 프로그램이나 데이터를 읽는 것은 사실 프로세서가 버스를 통해 디스크를 읽으라는 요청을 디스크 콘트롤러에게 하는 것이다. 얼마 후에 디스크 콘트롤러는 버스를 통해 데이터를 읽어들였고 데이터를 코어의 특정한 위치로 보냈다는(put) 신호를 보내게 된다. 그러면 프로세서는 메모리에 있는 내용을 볼 수 있게 된다. 키보드와 스크린 역시 버스를 통해 프로세서와 대화를 하지만, 보다 단순한 방법을 사용한다. 이건 다음에 얘기하도록 하자. 이제 당신은 컴퓨터에 전원을 켰을 때 무슨 일이 벌어지는가를 이해하기에 충분한 지식을 갖고 있다. 3. 컴퓨터의 스위치를 켜면 무슨 일이 벌어지는가? (What happens when you switch on a computer?) 실행되는 프로그램이 없는 컴퓨터는 무의미한 전자들의 덩어리에 불과하다. 전원이 켜졌을 때 컴퓨터가 처음으로 하는 일은 운영체계(OS)라고 불리는 특별한 프로그램을 구동시키는 것이다. 운영체계의 임무는 컴퓨터 하드웨어 의 잡다한 사항들을 제어해서 다른 컴퓨터 프로그램이 동작하도록 도와주는 것이다. 운영체계를 불러오는 과정을 일컬어 '부팅'이라고 한다. (원래 이것은 부트스트래핑[bootstrapping] 과 부트스트랩의 발음상 어려움 때문에 줄여 부르는 것이다) 컴퓨터는 어떻게 부트할 것인가 대한 명령을 하나의 칩, 바이오스(BIOS - Basic Input/Output System)라는 칩에 담고 있기 때문에 부팅하는 방법을 알고 있다. 바이오스 칩은 가장 낮은 번호의(lowest-numbered) 하드디스크(부트 디스크)에서 부트로더(리눅스에서는 LILO)라는 특별한 프로그램을 위한 고정된 장소를 찾는다. 부트로더는 코어안으로 들여지고 구동된다. 부트로더의 임무는 진짜 운영체계를 구동시키는 것이다. 이 일은 로더가 커널을 찾고, 코어 안으로 로딩해서, 운영체계를 가동시킴으로써 이뤄진다. 리눅스가 부팅할 때 화면상의 "LILO"를 보면 여러개의 점들이 이어져 나타나는데 이것이 커널을 로딩하는 것이다.(각 점들은 커널 코드의 다른 디스크 블럭들이 로딩되는 것을 나타낸다.) (여러분은 여기서 왜 바이오스가 커널을 직접 로드하지 않는지 -- 왜 부트로더를 사용하는 두가지 단계를 거쳐 작동하는지 궁금할 것이다. 자, 바이오스는 똑똑하지 못하다. 사실은 무척이나 멍청하고, 부팅 후 리눅스는 전 혀 이를 사용하지 않는다. 원래 바이오스는 아주 작은 디스크를 가진 원시적인 8비 트 PC를 위해 만들어졌고, 사실상 커널을 직접 로드할 정도 크기의 디스크에 대한 충분한 접근을 하지 못한다. 또한 부트로더의 이런 과정은, 물론 그럴리야 없겠지만 당신이 Unix의 성능에 충분히 만족하지 못할 경우 디스크의 다른 장소에 있는 여러 운영체계들을 사용할 수 있게 해준다.) 일단 커널이 구동되면, 그것은 환경을 살펴보고, 나머지 하드웨어들을 찾은 다음, 프로그램을 실행시킬 준비를 한다. 이 동작은 일반적인 메모리 장소보다는 오히려 I/O포트 -- 마치 장치 콘트롤러가 명령을 내리기만을 기다리고 있는듯한 특별한 버스 어드레스(adresses) -- 를 건드림으로써 이뤄진다. 커널은 닥치는 대로 건드리는 것이 아니다; 이는 장치가 어디에 있음직하고, 만약 있다면 어떻게 해야 응답을 하는지에 대해 많은 정형화된 지식을 바탕으로 한다. 이러한 과정을 자동검색(autoprobeing)이라고 한다. 부팅시에 당신이 보는 대부분의 메시지들은 커널이 I/O포트를 통해 당신의 하드웨어를 자동검색하고, 사용 가능한지와 당신의 머신에 적합한지를 계산 해내는 과정이다. 리눅스의 커널은 이에 대해서는 다른 어떤 Unix보다 뛰어나며, 도스나 윈도우보다는 월등히 뛰어나다. 사실, 오랫동안 리눅스를 사용해온 사람들은 리눅스 부팅시 검색(이는 상대적으로 쉽게 설치할 수 있도록 해준다)의 똑똑함이 실험적이던 free-UNIX가 충분히 많은 사용자를 확보할 수 있게 이끌어준 중요한 이유라고 생각하고 있다. 하지만 커널이 완전이 로드되고 실행되는 것이 부트 프로세스의 끝이 아니다. ; 단지 첫번째 단계일 뿐이다(때때로 런레벨 1 [run level 1]이라 불린다) 커널의 다음 단계는 디스크에 이상이 없는지를 확인하는 것이다. 디스크 파일 시스템은 깨지기 쉽다; 하드웨어적 오류나 갑작스런 정전으로 인해 손상을 입었다면 Unix가 더 많은 일들을 하기 전에 복구과정을 거치는 것이 타당하다. 이에 대해서는 나중에 "파일 시스템이 잘못될 수 있는가"란 단락에서 더 얘기하도록 하겠다. 커널의 다음 단계는 여러 데몬(daemons)을 구동하는 것이다. 데몬은 프린터 스풀러나 메일 청취 또는 WWW 서버같이 눈에 띄지 않는 곳 에 숨어서 실행되기를 기다리는 프로그램이다. 이 특별한 프로그램들은 때때로 대등한 권한을 가진 여러 요청들로 인해 충돌이 일어날 수도 있다. 항상 실행되면서 모든 요청들에 대해 알고 있는 프로그램을 만드는 것이 여러 프로그램들이(각 프로세싱은 하나의 요청만을 처리하고, 동시에 처리되는) 서로 충돌이 없도록 신경을 쓰면서 만드는 것보다 쉬울 수도 있다. 시스템이 시작될 때 사용되는 특별한 데몬들의 묶음은 매우 다양하지만 거의 대부분은 프린터 스풀러(프린터의 입구를 지키는 데몬)를 포함하고 있다 일단 모든 데몬들이 구동되면, 런레벨 2에 진입하게 된다. 다음 단계는 사용자를 위한 준비다. 커널은 콘솔을 감시하기 위해 getty라는 프로그램을 실행한다. (그리고 dial-in serial ports를 감시하기 위해서는 보다 많은 getty를 실행한다.) 이 프로그램은 콘솔에 login 프롬프트를 내놓는다. 이제 우리는 런레벨 3에 있고 사용자 login과 프로그램들을 실행할 준비가 되어있다. login할 때(ID와 패스워드를 입력해서) 당신은 getty와 컴퓨터에 자신을 확인시킨다. 그러면 getty는 login(그렇게 불릴만 하다)을 실행하는데, 이 놈은 시스템 운용에 직접 관여하지는 않으며 명령 해석기인 쉘(shell)을 구동한다. (어쩌면 getty와 login은 한가지 프로그램으로 볼 수도 있다. 여기선 다루지 않겠지만 그들이 나눠진 데에는 역사적인 사연이 있다.) 다음 장에서는 쉘에서 프로그램을 실행시킬 때 어떤 일이 일어나는지 알아보도록 하자. 4. 쉘에서 프로그램을 실행하면 무슨 일이 생기는가? (What happens when you run programs from the shell?) 일반적인 쉘은 당신이 login한 후에 '$'모양의 프롬프트를 보여준다.(당신이 그것을 입맛에 맞게 수정하기 전에는) 나는 여기서 쉘 구문과 스크린에서 알 수 있는 쉬운 것들에 대해서는 얘기하지 않겠다; 대신 눈에 보이는 것 뒤에서 벌어지는 것에 대해 컴퓨터의 관점에서 살펴보도록 하겠다. 부팅후 프로그램을 실행시키기 전에, 당신의 컴퓨터를, 뭔가 할 일을 기다 리고 있는 프로세스들을 가득 담은 동물원(zoo)이라고 생각하기 바란다. 그들은 어떤 이벤트(events)가 일어나기를 기다린다. 이벤트는 키의 누름이나 마우스의 움직임 등이다. 또 당신의 머신이 네트웍과 맞물려 있다면, 네트웍을 통해 전해지는 데이터 패킷들도 이벤트가 될 수 있다. 커널은 이 프로세스중의 하나이다. 이것은 보통 다른 사용자(user) 프로세스들이 구동될 수 있도록 제어하며, 일반적으로 머신의 하드웨어에 직접 접근할 수 있는 특별하고도, 유일한 프로세스이다. 사실, 사용자 프로세스들은 키보드의 입력을 받거나, 화면을 그리거나, 디스크를 읽거나 쓸 때, 또는 단순히 메모리의 비트를 읽을때도 커널에게 요청(request)을 한다. 이 요청이 이른바 시스템콜(system call)이라는 것이다. 보통 모든 I/O는 커널을 통해 이뤄지므로 커널은 작업을 계획할 수 있고 각 프로세스들이 서로 침범하는 것을 것을 막을 수 있다. 일반적으로 커널을 통과할 수 있도록 허락을 받은 몇몇의 특별한 유저 프로세스는 I/O포트에 직접적인 접근을 할 수 있다. X서버(대부분의 Unix 박스에서 다른 프로그램들의 요청을 화면에 그리게끔 제어하는 프로그램)는 이 대표적인 예이다. 하지만 아직 우리에게 X서버는 이르다; 우리는 문자 콘솔에서의 쉘 프롬프트를 배우고 있다. 쉘은 단지 사용자 프로세스일 뿐, 특별한 것은 아니다. 이 놈은 키 입력을 기다리고, I/O포트에 주의를 기울인다(커널을 통해). 커널의 관점에서 이것은 키 입력들을 화면에 되풀이한 다음 쉘로 보내는 것에 지나지 않는다. 커널이 'Enter'를 만나게 되면 화면에 있는 텍스트 라인을 쉘로 보내게 된다. 쉘은 이 키 입력들을 명령으로 해석하려 할 것이다. Unix 디렉토리를 보기 위해 'ls'를 친 후 엔터를 눌러 보자. 쉘은 정형화된 규칙(built-in rules)을 적용시켜 당신이 '/bin/ls'라는 프로그램을 실행하기 원한다는 것을 알아낼 것이다. 이는 시스템 콜로 하여금 커널에게 /bin/ls를 새로운 하위 프로세스로 구동해 달라고 요청하게 하고, 커널을 통해 키보드 와 화면에 대한 접근권을 얻어낸다. 그다음 쉘은 자면서(sleep), ls가 종료되기를 기다린다. /bin/ls가 종료되면, 종료 시스템 콜(exit system call)을 보냄으로 커널에게 작업이 끝났다는 것을 알린다. 그러면 커널은 쉘을 깨우고 계속해서 일을 할 수 있음을 알려준다. 쉘은 다른 프롬프트를 보내고 또다른 입력을 기다린다. 하지만 'ls'가 실행되는 동안에도 다른 일을 할 수 있다(여기서는 디렉토리 의 리스트가 아주 길다는 가정이 필요하다). 가상 콘솔(virtual console)을 열고 login해서 Quake같은 게임을 즐길 수도 있고, 또는 인터넷에 연결되 있다면 /bin/ls가 실행되는 동안에도 메일을 받거나 보낼 수도 있다. 5. 어떻게 장치에 입력을 하며 작업을 중단하는가? (How do input devices and interrupts work?) 키보드는 아주 단순한 입력장치이다; 이 놈은 아주 작은 양의 데이터를 무척이나 느린 속도로 생산하기 때문에 그렇다.(컴퓨터의 관점에서). 키를 누르거나 손을 띄면, 이 이벤트는 신호화되서 키보드 케이블을 타고 하드웨어 인터럽트를 발생시킨다. 이런 인터럽트를 감시하는 것은 운영체계의 임무이다. 각각의 발생 가능한 인터럽트에는 운영체계의 한 부분으로, 그것이 처리될 수 있을때까지 인터럽트와 연관된 데이터(키보드의 누름 등)를 숨기는 인터럽트 핸들러가 존재한다. 실질적으로 인터럽트 핸들러가 키보드에 하는 일은 코어의 하부에 있는 시스템 구역에 키의 값을 알려주는 것이다. 어떤 것이든지 현재 키보드로부터 입력을 받고 있다고 추정되는 프로그램에게, 운영체계가 제어권을 넘기는 것을 검사할 수 있다. 디스크나 네트웍카드같이 보다 복잡한 입력장치도 이와 비슷한 방식으로 작동한다. 위에서, 우리는 디스크 콘트롤러가 버스를 이용해서 디스크의 요청을 들어주는 것에 대해 언급했었다. 사실 이 작업은 디스크가 인터럽트를 발생시키는 것이다. 그러면 디스크 인터럽트 핸들러는 요청을 생성한 프로그램이 나중에 사용 할 수 있도록 다시 불려진 데이터를 메모리 안에 복사해 놓는다. 모든 종류의 인터럽트는 우선순위를 갖는다. 낮은 순위의 인터럽트는 (키보드같은) 높은 순위의 인터럽트를(clock나 디스크 같은)기다려야만 한다. Unix는 머신의 원활한 응답을 위해 빨리 진행되야 하는 프로세스에 우선순위 를 부여하도록 디자인되어 있다. OS의 부팅 메시지에서 IRQ번호에 관한 언급을 볼 수 있을 것이다. 가장 일반적인 하드웨어 설정의 오류는, 정확한 이해없이 다른 두 개의 장치가 하나의 IRQ를 사용토록 하는 것이다. 여기 그 해답이 있다. IRQ는 "Interrupt Request"의 약자이다. 운영체계는 구동시 각각에 맞는 적절한 핸들러가 사용될 수 있도록 하드웨어장치가 어떤 인터럽트 번호를 쓸 것인지 알아야 한다. 만약 두 개의 다른 장치가 같은 IRQ를 쓰고자 한다면, 인터럽트는 종종 잘못된 핸들러를 없애버기리도 한다. 이것은 장치에 대한 최소한의 안전장치이고, 때때로는 OS의 혼동으로 인해 다운되거나 기능이 멈춰버릴 수도 있다. 6. 컴퓨터는 어떻게 한번에 여러 가지 일을 할 수 있나? (How does my computer do several things at once?) 사실은 그렇지 않다. 컴퓨터는 한번에 한가지 일(또는 프로세스)만 할 수 있다. 하지만 컴퓨터는 작업전환을 매우 빠르게 할 수 있고, 바보스럽게 느린 인간의 생각으로는 그것이 한번에 여러 가지 일을 하는것처럼 보이는 것이다. 이것을 시분할(timesharing)이라고 부른다. 커널의 중요한 임무중 하나는 시분할을 관리하는 것이다. 커널에는 스케줄러 라고 불리는 부분이 있는데, 이놈은 당신의 동물원(zoo)안의 다른(커널은 빼고) 모든 프로세스들의 내부정보를 갖고 있다. 커널 안에서 시계(timer)는 1/60초마다 정지하고, 클럭(clock) 인터럽트를 생성한다. 스케줄러는 현재 진행되는 프로세스가 무엇이건 중단시키고, 한곳에 놓은 다음 다른 프로세스를 다룬다. 1/60초는 별로 길지 않은 시간처럼 보인다. 하지만 오늘날의 마이크로프로세서는 한번에 수만개의 머신을 다룸으로써 일의 능률을 극대화한다. 그러므로 여러 가지 프로세스가 있더라도 각각의 것들은 극히 짧은 시간안에 완수될 수 있다. 실제로, 프로그램은 완전한 시간의 조각(timeslice)을 갖지 못한다. 만약 I/O 장치로부터 인터럽트가 발생되면, 커널은 효과적으로 현재의 작업을 중지하고, 인터럽트 핸들러를 실행시킨 후, 다시 하던 작업으로 돌아온다. 빗발치는 우선순위의 인터럽트는 보통의 프로세스를 중단시킨다; 이런 오동작을 thrashing이라고 부르며, 다행히도 현대의 Unix에서는 아주 드믄 일이다. 사실, 프로그램의 속도는 머신이 사용할 수 있는 시간의 양에는 거의 제한을 받지 않는 듯 하다(사운드나 3D 그래픽 생성은 예외가 될 수 있다) 그보다 더 자주 생기는, 지연(delays)은 프로그램이 디스크 드라이브나 네트웍에서 데이터를 받을 때 기다리는 시간에 의해 발생된다. 운영체계는 관례적으로 동시에 여러프로세스를 지원하는 이른바 "멀티태스킹" 을 지원한다. Unix계열의 운영체계는 기초부터 멀티테스킹에 맞게 디자인되어 있고 또한 그것에 매우 능하다. -- 뒤늦게 멀티테스킹 기능을 추가하고 더우기 서툰 방식으로 그것을 하는 윈도우나 맥OS보다 훨씬 더 효과적이다 -- 효과적이고 믿을 수 있는 멀티테스킹은 리눅스가 네트웍, 통신, 웹 서비스에서 우월성을 갖게 하는 큰 요인중 하나이다. 7. 컴퓨터는 어떻게 각 프로세스간에 방해를 받지 않을 수 있는가? (How does my computer keep processes from stepping on each other?) 커널의 스케줄러는 시간속에서 프로세스를 나누는 일을 한다. 또한 운영체계는 프로세스를 공간적으로도 나눔으로써, 작업중인 다른 메모리 공간을 침범하지 않게 한다. 이 문제를 해결하기 위한 운영체계의 일을 메모리 관리라고 한다. 동물원 안의 각 프로세스들은 코드와 변수, 결과를 실행할 수 있는 고유한 코어 기억 장소를 필요로 한다. 이러한 세트(set)는 읽기 전용으로 이루어진 코드 조각(프로세스의 명령을 담고 있는)과 쓸 수 있는(writeable) 데이터의 조각(프로세스의 변하기 쉬운 정보를 담고 있는)으로 생각해 볼 수 있다. 실제로 데이터의 조각은 각 프로세스에는 유일한 것이지만, 두 개의 프로세스 가 동일한 하나의 코드를 사용할 경우 Unix는 자동적으로 효율을 측정하여 하나의 코드조각을 공유하도록 정렬해(arranges) 준다. 코어 메모리는 비싸기 때문에 효율성이 매우 중요하다. 가끔씩 프로그램 전체를. 특히 X서버같은 큰 프로그램을 실행하기에는 메모리가 부족할 경우도 있는데, 이럴경우, Unix는 가상 메모리(virtual memory)라는 전략을 사용한다. 이 놈은 모든 코드와 데이터를 코어안에 잡아 넣으려 하지 않는다. 그 대신, 상대적으로 작은 작업세트에 그것들을 보관한다; 남아있는 상태의 프로세스들은 하드디스크의 특별한 스왑(swap) 공간에 보관된다. 프로세스가 진행되는 동안, Unix는 작업 세트가 어떻게 바뀔지 예상하고 필요로 하는 최소한의 조각을 코어안에 둔다. 효율적으로 이렇게 하는 것은 복잡하고도 까다롭기 때문에 여기서 전부 설명하지는 않겠다; 하지만 코드와 데이터는 클러스터에서 발생하며, 새로 생기는 것은 가까이에 있는 오래된 것을 따르려는 경향이 있다. 따라서 Unix는 자주 사용되는 코드와 데이터를 저장하여, 당신의 시간을 절약해준다. 전에도 언급한 적이 있지만 "때때로"의 두 구절 앞은 "거의 언제나"이다; 전형적으로 코어의 크기는 실행되는 프로그램의 크기와 관계가 적으므로, 스와핑이 자주 사용된다. 최근에는 메모리의 값이 그다지 비싸지는 않으며 심지어는 저가형 머신도 꽤나 많은 메모리를 가지고 있다. 64MB이상의 코어를 가진 최신의 싱글유저 머신은 X를 실행시키고 일반적인 여러 가지 작업을 스와핑 없이 할 수 있다. 이런 좋은 여건에도 불구하고, 운영체계의 메모리 관리는 아직까지 중요한 일이다. 프로그램은 반드시 그 자신의 데이터 조각만을 변경할 수 있어야 한다 -- 실수나 악의로 다른 프로그램의 데이터를 긁어 모으는 코드를 막기 위해서. 이를 위해서는 데이터 테이블과 코드 조각을 유지해야 한다. 테이블은 프로세스가 보다 많은 메모리를 요구하든 메모리 반환을 요구하던간에 갱신(update)된다. (후자는 보통 종료할 때 이뤄진다) 이 테이블은 MMU또는 메모리 관리 유닛(Memory Management Unit)라고 불리는 특정화된 하드웨어의 내부에 명령을 전달하기도 한다. 현대의 프로세서 칩은 생산될 때부터 그 내부에 MMU를 포함하고 있다. MMU는 메모리 구역에 방벽(fence)을 만들 수 있는 특수한 능력을 가지고 있으므로, 한도(bound)를 넘어선 간섭은 거부하고, 그에 따른 특정한 인터럽트를 발생시킨다. Unix에서 "Segmentation fault", "core dumped"란 메시지나 그와 비슷한 것을 본 적이 있다면, 정확히 이런 일이 벌어진 것이다; 실행중인 프로그램이 그것의 외부에 있는 메모리 조각에 접근하려 시도하다가 치명적인 인터럽트를 발생시킨 것이다. 이것은 프로그램 안의 버그를 보여준다; 코어 덤프의 뒤에는 진단에 도움이 되는 정보들이 남겨지는데 이는 프로그래머가 그 버그를 추적 해서 없애는 데 도움이 된다. 8. 컴퓨터는 어떻게 디스크에 저장을 하는가? (How does my computer store things on disk?) Unix에서 하드디스크를 보면, 여러 디렉토리와 파일로 이뤄진 tree를 볼 수 있다. 일반적으로는 그것보다 더 깊은 내용을 알 필요가 없지만, 만약 당신의 디스크가 고장이 나서 파일들을 살려내고 싶다면, 그 내부에서 어떤 일이 벌어지고 있는가에 대해 아는 것이 도움이 된다. 불행히도, 디스크 구조를 파일 수준(file level)으로 설명하는 좋은 방법이 없기 때문에 하드웨어부터 점차 올라가는 방법(hardware up)으로 설명하겠다. 8.1. 저수준의 디스크와 파일구조 (Low-level disk and file system structure) 데이터를 저장하는 디스크의 표면은 다트판(dartboard)처럼 생겼다 -- 잘린 파이모양으로 된 섹터들이 원형의 트랙을 구성하고 있다. 바깥쪽의 트랙이 안쪽의 트랙보다 보다 많은 섹터 조각을 가지고 있기 때문에 바깥쪽의 트랙이 디스크의 가운데 축 주변의 트랙보다 많은 공간을 보유할 수 있다. 각 섹터(또는 디스크 블럭)는 같은 크기(size)를 가지고 있고, 현대의 Unix에서 섹터는 일반적으로 1 binary K(1024 8-bit words)이다. 각 디스크 블럭은 유일한 주소(address)나 디스크 블럭 번호를 가지고 있다. Unix는 디스크를 디스크 파티션으로 나눈다. 각 파티션은 어떤 다른 파티션과도 독립적으로 사용되는 블럭의 연결로 이뤄졌으며, 이것은 파일 시스템이나 스왑 공간에서도 마찬가지이다. 가장 낮은 번호의 파티션은 때때로 부팅을 위한 커널을 사용하는, 부트 파티션으로 특별하게 취급된다. 각 파티션은 스왑 공간이거나(가상 메모리로 쓰이는) 파일 시스템이거나, 파일을 저장한다. 스왑 파티션은 단지 블럭으로 길게 이어진 선처럼 여겨지게 된다. 파일은 시간이 지남에 따라 커지거나 작아지는 등 변하기 때문에 파일의 데이터 블럭은 연속적으로 이어지지 못하고 그 파티션의 여러곳으로 뿔뿔이 흩어지게 된다.(운영체계가 찾을 수 있는 빈 블럭이 필요할 때마다 쓰이게 된다.) 8.2. 파일 이름과 디렉토리 (File names and directories) 각 파일시스템 내부는, i-node라고 불리는 구조를 통해 블럭의 이름으로 매핑(mapping)되어 다뤄진다. 각 파일시스템의 "바닥(bottom-가장 작은 번호의 블럭)" 근처에는 pool이 있다. 각 i-node는 하나의 파일을 나타낸다. 파일테이터 블럭은 i-node위에 존재한다. 모든 i-node는 그것이 나타내는 파일마다의 디스크 블럭 번호를 담고 있다. (사실 이것은 절반만 맞는 얘기이다. 단지 작은 파일들에만 해당이 되며 나머지 더 자세한 내용은 여기에서 별로 중요하지 않다.) 알아둘 것은 i-node 는 파일 이름을 담고 있지는 않다는 것이다. 파일의 이름은 디렉토리 구조안에 존재한다. 디렉토리 구조는 i-node번호에 맞춰 파일 이름을 매핑한다.(매핑을 궂이 번역하자면 자세하게 그린다 정도?) 이것이 Unix에서 파일이 실제 이름을 여러개 가질 수 있는 이유다.(또는 하드 링크[hard link]); 이것들은 단지 같은 i-node에 맞춰 여러 디렉토리를 등록하는 것이다. 8.3. 마운트 포인트 (Mount points) 가장 단순한 경우, 모든 Unix 파일 시스템을 하나의 디스크 파티션에 넣을 수 있다. 당신이 이런 배열을 어떤 개인의 Unix 시스템에서 볼 수 있다 하더라고, 꽤나 드믄 일일 것이다. 보다 전형적인 경우는 여러개의 디스크 파티션에, 어쩌면 여러개의 물리적 디스크에 나눠 설치하는 것이다. 따라서, 예를 들자면 당신의 시스템은 커널이 있는 작은 파티션과 OS의 유틸리티들을 담은 조금 더 큰 파티션과, 사용자들이 사용하는 /home 디렉토리를 담은 무척이나 큰 파티션으로 구성될 수 있다. 시스템이 부팅된 후 유일하게 즉시 접근할 수 있는 파티션은 당신이 (거의 항상)부팅을 하는 루트 파티션 뿐이다. 여기에는 파일 시스템의 루트 디렉토리가 있고, 다른 모든 것들이 달려있는 최상위 노드이다 여러개의 파티션을 가진 파일 시스템 모두에 접근하려면, 다른 파티션들은 루트 파티션에 소속[attached]되어 있어야 한다. 부트 프로세스의 중간쯤에서, Unix는 루트 파티션이 아닌 것들에 대해 접근을 가능토록 한다. 각 파티션을 루트 파티션의 디렉토리로 마운트(mount)하는 것이다. 예를 들자면, /usr라는 Unix 디렉토리가 있다면, 그건 아마도 Unix에는 필요하지만, 부팅시에는 필요치 않는 여러 가지 프로그램들을 설치해 놓은 파티션일 것이다. 8.4. 어떻게 파일을 살펴볼 수 있나? (How a file gets looked up) 자, 이제 우리는 파일 시스템을 자세히 살펴볼 수 있다. 당신이 파일을 열면(open) (예로 /home/esr/WWW/ldp/fundamentals.sgml를 열었다고 하자) 다음과 같은 일이 벌어진다: 커널은 Unix 파일 시스템의 루트에서 시작한다(루트 파티션에서). 그리고 'home'이라고 불리는 디렉토리가 있는지 살펴본다. 보통 'home'은 어떤 경우라도 사용자들이 쓰는 커다란 파티션의 마운트 포인트이므로, 그쪽으로 이동할 것이다. 사용자 파티션의 최상위 레벨 디렉토리 구조에서 'esr'이라고 불리는 것을 찾고는 inode 번호를 추출한다. 해당 i-node로 가서, 그것이 디렉토리 구조임을 알아내고는, 'WWW'을 찾는다. 그 i-node를 추출하고, 이와 일치하는 하위 디렉토리로 이동한 후 'ldp'를 찾는다. 그리고는 그것이 또다른 디렉토리 inode임을 알 것이다. 그 안으로 들어가서, `fundamentals.sgml'의 inode번호를 찾아낼 것이다. 그 inode번호는 디렉 토리가 아니므로, 대신에 그 파일과 연관된 디스크 블럭의 리스트를 남길 것이다. 8.5. 뭔가 잘못될 수도 있나? (How things can go wrong) 앞에서 우리는 파일 시스템은 깨지기 쉬운 것이란 걸 알았다. 이제 우리는 디렉토리와 i-node로 제 멋대로 길게 연결된 디렉토리를 어떻게 다뤄야 하는지도 알고 있다. 자, 이제 당신의 하드디스크에 잘못된 부분이 생겼다고 가정해보자. 운이 좋다면, 약간의 파일 데이터만 손상됐을 것이다. 운이 따르지 않는다면, 디렉토리 구조나 i-node 번호가 잘못되거나 그 하위 디렉토리들이 사라질 수도 있다 -- 또, 최악의 경우에는 손상의 결과로 인해 여러개의 파일 구조가 같은 디스크 블럭이나 inode를 가르키게 될 수도 있다. 이런 손상은 평범한 파일의 동작에서도 비롯될 수 있는데, 디스크의 손상된 곳에 있는 데이터는 망가질 수도 있다. 다행히도, 이런 우발적인 사고는 하드웨어가 보다 안정되어 가면서 아주 드믄 일이 되었다. 하지만, 이건 아직까지 Unix는 뭔가 잘못되는 것을 예방하기위해 주기적으로 시스템의 안정성 검사(integrity-check)를 필요로 한다는 말이다. 따라서 가끔씩 재부팅할 때 시간이 더 걸리는 정밀한 검사를 실시할 것이다. 어쩌면 이 모든 얘기들이 Unix는 몹시도 복잡하고 고장나기 쉽다는 소리처럼 들릴지도 모르겠는데, 부팅시 하는 이런 검사들은 보다 큰 재앙이 닥치기 전에 대수롭지 않은 문제들을 찾고 해결하는 의례적인 것이다. 다른 운영체계들은 보다 빠른 부팅을 위해 이런 기능을 갖고 있지 않은데, 따라서 나중에 수동으로 복구하고자할 때는 이미 엉망진창이 되어버린 후 일 수도 있다(당신이 노턴 유틸리티나 그 비슷한 것을 가지고 있다면 몰라도...) 9. 컴퓨터 언어는 어떻게 작동하는가? (How do computer languages work?) 우리는 이미 "어떻게 프로그램이 실행되는가"에 대해 알아보았다. 모든 프로그램은 궁극적으로 컴퓨터의 기계어를 지시하는 바이트들의 흐름을 실행시켜야만 한다. 하지만 인간은 기계어를 다루는데 별 소질이 없다; 해커라고 할 지라도 기계어를 잘 다루는 것은 아주 드믈고, 요술을 부리는 것처럼 여겨진다. 대부분의 Unix코드는 커널 자체에서 하드웨어에 직접적인 접근을 하기 위한 경우를 제외하고는 고수준의 언어(high-level language)가 쓰인다(요즘의 고수준 언어란 것은 역사적 풍습의 잔재로 원래는 기계 코드를 얇게 감싸는 저수준의 어셈블러 언어와 구별되기 위한 것이다.). 고수준의 언어에는 여러 가지 다른 종류가 있다. 이것들에 대해 얘기하기 전에 프로그램의 소스코드(인간이 만든, 수정이 가능한 놈으로)가 머신에서 실질적으로 작동하기 위해서는 기계어로의 번역과정을 거쳐야만 한다는 것을 항상 기억해 두는 것이 도움이 될 것이다. 9.1. 컴파일 언어 (Compiled languages) 가장 전통적인 종류의 언어는 컴파일 언어이다. 컴파일 언어는 컴파일러라는 (충분히 그렇게 불릴 만 하다)특별한 프로그램을 통해 실행 가능한 이진 기계코드를 생성해낸다. 한번 이진코드가 생성되면, 다시 소스 코드를 볼 필요없이 즉시 실행시킬 수 있다.(대부분의 소프트웨어는 당신이 볼 수 없도록 컴파일된 이진코드로 인도된다) 컴파일 언어는 뛰어난 성능과 OS에 접근이 가장 용이하지만 프로그램 하기가 어렵다는 단점이 있다. Unix 자체를 만든(written) C언어는 컴파일 언어중 가장 중요한 위치에 있다 (그것의 변종인 C++과 함께). FORTRAN은 엔지니어와 과학자들 사이에 아직도 쓰이고 있지만 너무나 오래됐고 원시적이다. Unix의 세계에서 다른 컴파일 언어는 대중적으로 사용되지 않는다. Unix의 외부에서는 COBOL이 재무와 상업적인 소프트웨어로 많이 사용된다. 이들 말고도 많은 컴파일 언어가 있었지만, 대부분의 것들은 사라지거나 제한적인 연구용 도구로 사용되고 있다. 만약 컴파일 언어로 Unix 프로그래밍을 하고 싶다면 C나 C++을 하는 것이 압도적인 추세이다. 9.2. 인터프리티드 언어 (Interpreted languages) 인터프리티드 언어는 소스코드를 읽고 그것을 계산해서 시스템콜로 보내는 인터프리터에 달려있다. 소스코드가 실행될 때마다 소스는 재해석(re-interpreted) 된다. 인터프리트드 언어는 컴파일 언어보다 느린 경향이 있고, 운영체계의 깊숙한 부분의 하드웨어에 접근이 제한된다. 장점은, 컴파일러 언어보다 프로그래밍이 쉽고 코딩 에러(coding errors)에 대해 보다 너그럽다. 많은 Unix 유틸리티 중에 쉘(shell)과 bc(1), sed(1) 그리고 awk(1)등은 효과적이면서도 작은 용량의 인터프리티드 언어이다. 일반적으로 BASIC은 인터프리티드 언어에 속하며, Tcl도 마찬가지이다. 역사적으로 가장 중요한 인터프리티드 언어는 LISP였다.(인터프리티드 언어의 후계자 중 가장 두드러진 발전을 했다) 요즘은 Perl이 널리 쓰이고 꾸준히 사용자가 늘고 있다. 9.3. P-코드 언어 (P-code languages) 1990년부터 컴파일러와 인터프리티드 언어로 함께 쓰일수 있는 잡종의 언어가 그 중요성을 더해갔다. P-코드 언어는 소스가 실질적으로 실행되는 작은 이진 코드 형태로 번역되는 점은 컴파일러 언어와 비슷하지만, 그 형태는 기계어가 아니다. 대신에 무척이나 단순하지만 실제 기계어보다 더 강력한 의사코드(pseudocode)(or p-code)를 사용한다. 프로그램을 실행시키면, p-코드를 해석하게 된다. P-코드는 컴파일된 이진코드만큼 빠르게 실행될 수 있다(p-코드 인터프리터 는 아주 단순하게, 빠르고 작게 만들어질 수 있다). 하지만 p-코드 언어는 인터프리터 언어의 뛰어난 유연성과 힘을 유지할 수 있다. 중요한 p-코드 언어로는 파이톤(Python)과 자바(Java)가 있다 10. 인터넷은 어떻게 작동하는가? (How does the Internet work?) 인터넷 작동원리의 이해를 돕기위해, 인터넷 동작시 일어나는 대표적인 일들에 대해 살펴보자. -- 앞서 언급된 이 문서의 홈페이지인 the Linux Documentation Project로 가보도록 하자. http://sunsite.unc.edu/LDP/HOWTO/Fundamentals.html는 sunsite.unc.edu란 호스트 안에 있는 WWW외부 디렉토리안에 LDP/HOWTO/Fundamentals.html 이란 곳에 있다는 뜻이다. 10.1. 이름과 위치 (Names and locations) 맨처음 웹 브라우저가 해야 할 일은 문서가 있는 네트웍 머신에 접속하는 것이다. 이를 위해서는 먼저 sunsite.unc.edu라는 호스트의 네트웍 위치를 찾아야 한다.('호스트'는 '호스트 머신' 또는 '네트웍 호스트'의 약자이다; sunsite.unc.edu는 전형적인 호스트 이름이다.) 사실 이와 일치하는 위치는 IP 주소(IP address)라고 불리는 숫자이다.(IP에 대해서는 잠시 후에 설명 하겠다.) 이를 위해, 브라우저는 네임서버(name server)라는 프로그램에 질문을 한다. 네임서버는 당신의 머신에도 있을 수 있지만, 아마도 대부분은 당신이 접속 하고자 하는 머신에서 동작하고 있을 것이다. 당신이 ISP(Internet Service Provider -- 하이텔이나 채널i 같은)에 가입할 때 셋업 절차 중 하나는 아마도 인터넷 소프트웨어에 ISP 네트웍 네임서버의 IP주소를 기입하는 일일 것이다. 다른 머신의 네임서버들은 각각에게 대화를 하며 호스트네임을 해석하기 위해 필요한 모든 정보들을 교환하고 유지할 것이다. (IP주소를 안내해준다) 당신의 네임서버는 sunsite.unc.edu를 해석하기 위해 네트웍을 따라 서너개의 다른 사이트들에게 질문을 하지만, 이 일들은 보통 아주 빨리 일어난다(최소한 1초보다 더 빨리) 네임서버는 당신의 브라우저에 선사이트(Sunsite)의 IP주소는 152.2.22.81라고 알려줄 것이다; 이를 앎으로 당신의 머신은 선사이트의 디렉토리와 비트를 교환할 수 있게 된다. 10.2. 패킷과 라우터 (Packets and routers) 브라우저가 원하는 일은 선사이트의 웹서버에 다음과 같은 명령을 보내는 것이다. GET /LDP/HOWTO/Fundamentals.html HTTP/1.0 자, 무슨 일이 벌어졌는지 살펴보자. 이 명령은 패킷, 즉 세가지 중요한 정보를 가진 전보(telegram) 비슷한 비트의 블럭들 안으로 전달된다; 세가지 중요한 정보는 소스 주소(당신이 가진 머신의 IP주소), 목적지 주소(152.2.22.81), 그리고 WWW 요청을 가르키는 서비스 번호 혹은 포트 번호이다(이 경우에는 80이다). 그 후 당신의 머신은 라우터라고 불리는 전문화된(specialize) 머신에 도달할 때까지 전선을 통해(근거리의 네트웍이나 모뎀을 통한 ISP 접속) 패킷을 보낸다. 라우터는 메모리 에 인터넷의 지도를 가지고 있다 -- 항상 완벽한 것은 아니지만, 인접 네트웍을 정확히 설명해주고 인터넷의 다른 이웃들을 라우터로 보내야 할지 알고 있다. 패킷은 목적지까지 여러개의 라우터를 거치게 된다. 라우터는 영리하다. 이 놈은 다른 라우터들이 패킷이 받아들여졌음을 알아채는데 걸리는 시간을 주시한다. 그리고는 그 정보를 체증(traffic)이 없는 빠른 연결을 위해 쓴다. 또 어떤 라우터가 네트웍에서 사라지면 가능한 다른 라우터를 찾아 이에 대한 보상을 한다. 인터넷은 핵전쟁에서 살아남기 위해 디자인되었다는 속설이 있다. 이것은 사실이 아니지만, 인터넷은 변덕스러운 세상의 열악한 하드웨어에서도 믿을만한 성능을 발휘할 수 있도록 디자인되어있다. 이는 인터넷의 지능이 거대한 소수의 스위치보다는(전화 네트웍 같은) 수천개의 라우터를 통해 분포 되어 있기 때문에 가능하다. 만일 고장이 나더라도 어느 지역에만 제한이 되며 네트웍은 다른 길을 통해 라우팅이 가능하다. 패킷이 목적지의 머신에 도달하면, 머신은 패킷에게 웹서버로의 서비스 번호를 부여한다. 웹서버는 패킷의 소스 IP 주소의 명령을 살핌으로서 어디로 응답을 해야 하는지 알 수 있다. 웹서버가 이 문서를 반환하면, 문서는 패킷의 번호로 분해된다. 패킷의 크기는 서비스의 종류와 변환되는 매체에 따라 유동적이다. 10.3. TCP/IP (TCP and IP) 다중 패킷변환이 어떻게 처리되는가를 이해하기 위해서는, 실제로는 인터넷이 상위와 하위의 두가지 프로토콜을 사용한다는 것을 알아야 한다. 저수준의 IP(Internet Protocol)는 소스 주소로부터 목적지 주소까지 어떻게 각각의 패킷을 얻을 수 있는지 알고 있다(이것이 IP주소라고 불리는 이유이다). 하지만, IP는 안정적이지 못하다; 만약 패킷이 실종되거나 다운되어 버리면 소스와 목적지의 머신은 전혀 알 길이 없다. 네트웍에 떠도는 속설로, IP는 연결없는 프로토콜이라고 한다; 발송인(sender)은 수취인(receiver)에게 패킷을 발 사할 뿐이며, 무사히 받았다는 통지를 받는건 기대할 수 없다. 그럼에도 IP는 빠르고, 저렴하다. 때로는 안정적이지 못해도 빠르고, 저렴하면 그만일 때도 있다. 당신이 둠이나 퀘이크같은 네트웍 게임을 할 때, 각각 총알들은 IP 패킷으로 나타내진다. 이들중 약간이 사라진다고 해도 별 문제가 되지 않는다. 상위수준의 TCP(Transmission Control Protocol)는 믿을만하다. 두 개의 머신이 TCP로 연결이 이뤄지면(which they do using IP), 수취인은 발송인에게 잘 받았다는 통보를 보낼 수 있다. 만약 발송인이 휴식중이어서 잘 받았다는 통보를 받지 못하면, 다시 패킷을 보낸다. 더욱이, 발송인은 각각의 TCP패킷에게 수취인이 연속적인 번호를 부여하고, 또한 TCP/IP 패킷은 연결 불량으로 인한 데이터 손상을 발견할 수 있는 checksum을 포함하고 있다. 그러므로 TCP/IP와 네임서버를 사용하는 사람의 관점에 따라 바이트의 흐름을 호스트네임/서비스 번호의 한쌍 사이로 보낼 수 있는 안정적인 방법으로 보일 수 있다. 네트웍 프로토콜을 만드는 사람들은 패킷화, 패킷의 재조립, 에러 점검, 체크서밍, 재전송등에 대해서는 생각도 해보지 않은 사람들인 경우가 대부분이다. 10.4. HTTP, 응용프로그램의 프로토콜 (HTTP, an application protocol) 다시 예전의 예로 돌아가보자. 웹브라우저와 서버는 TCP/IP의 위에서 돌아가는 응용프로그램의 프로토콜만 다룬다. (TCP/IP는 단순히 바이트를 앞뒤로 보내는 단순한 수단으로만 사용한다) 이 프로토콜은 HTTP(Hyper-Text Transfer Protocol) 이라고 불리는데 우리는 이미 그중 한가지 명령을 보았다 -- 위에 보면 GET이란 놈이 있을 것이다. GET이란 명령이 sunsite.unc.edu로 전해지면 서비스 번호 80을 가진 웹서버는 재빨리 서버 데몬에게 포트 80에 귀를 귀울이라고 명령한다. 대부분의 인터넷 서비스는 단지 포트를 기다리고, 감시하고, 들어오는 명령어들을 실행하기 위한 서버 데몬에 의해 권한을 갖는다. 인터넷의 디자인이 한가지 포괄적인 규칙을 가지고 있자면, 모든 부분들은 가능하다면 단순하고 인간의 접근이 가능해야만 한다. HTTP, 그리고 그것의 친척들(relatives -- Simple Mail Transfer Protocol, SMTP, 즉 호스트간에 전자메일을 전달할 때 쓰인다)은 프린트 가능한 carriage-return/line feed로 끝나는 단순한 명령을 사용한다. 이것은 가장자리의 처리가 비효율적이다; 어떤 환경에서는 보다 꽉 코딩된 이진(binary) 프로토콜을 사용해 속도를 높일 수 있다. 하지만 인간에게 설명하고 이해하기 쉬운 명령어들을 사용할 때의 이득이 가장자리 처리의 효율성을 위해 까다롭고도 명확하지 않은 명령어를 쓸 때보다 훨씬 크다는 사실은 이미 증명되어 있다. 그러므로, 서버데몬이 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 These headers will be followed by a blank line and the text of the web page (after which the connection is dropped). Your browser just displays that page. The headers tell it how (in particular, the Content-Type header tells it the returned data is really HTML).