히말라야 현자의 모래시계와 시간 다스리기

난 시간이 모래처럼 손에서 빠져나가 되돌아오지 않는다는 것을 배웠지. 시간을 현명하게 쓰는 사람은 풍성하고 생산적이고 만족스러운 삶을 보상받네.
'시간을 다스리는 것은 삶을 다스리는 것'이라는 원칙을 배우지 못하면, 자신의 엄청난 잠재력을 깨닫지 못하지.

시간은 멋진 잣대야. 특권을 가졌든 아니든, 텍사스에 살든 도쿄에 살든 우리는 모두 하루 24시간을 사네. 이 시간을 이용하는 방식에 따라 '행복한 삶을 일구는 사람들'과 '그냥 하루하루 사는 사람들'로 나뉘게 되지.
로빈 샤르마의 '나를 발견한 하룻밤 인생수업' 중에서 (더난출판, 190p)



시간을 다스리는 삶.
누구에게나 공평하게 주어진 '하루 24시간'의 시간을 제대로 다스리는 사람만이 행복한 삶을 살아갈 수 있다.
시간을 현명하게 다스리기 위해서는 우선 시간의 '소중함'을 명확히 인식해야 한다. 히말라야의 깊은 산중에 사는 수도자들이 지니고 있다는 모래시계. 그 현자들은 어릴 때부터 모래시계를 지니고 살아간다고 한다.
"우리는 무소유의 청빈하고 소박한 삶을 살지만, 시간을 존중하며 시간이 흐르는 것을 인식한답니다. 이 작은 모래시계는 우리가 언젠가는 죽는 존재임을 매일 일깨워주지요. 우리에게 목적을 향해 나아가되, 온전하고 생산적인 나날을 살아가라고 말해주지요."

우리가 모래시계를 바라보며 모래처럼 손에서 빠져나가 되돌아오지 않는 시간의 소중함을 인식한다면, 하루 하루, 한 시간 한 시간을 바라보는 생각이 바뀔 것이다.

시간의 소중함을 인식했다면 이제 시간을 '계획'해야한다. 하루의 계획을, 일주일의 계획을, 한 달의 계획을 미리 세워놓는 것. 한 시간 일찍 출근해 그날의 계획을 짜고, 일요일 저녁에 한 시간을 내서 다음주의 계획을 정리해보는 것. 이렇게 계획에 시간을 '투자'하는 것이 반드시 필요하다.

시간을 현명하게 다스리는 사람은 시간계획을 통해 무엇이 중요한지, 무엇이 중요하지 않은지 인식하고, 주체적으로 '선택'할 수 있게 된다. 그리고 이런 과정을 통해 하고 싶고 또 해야하는 일을 할 수 있는 시간을 '만들어 낼' 수 있다.
그래서 항상 정신없이 바쁜 모습이 아니라 '여유'있는 모습 속에서 시간을 생산적으로, 의미있게 사용할 수 있게 된다. 행복한 삶으로 가는 길은 바로 여기에 있다.

"예병일의 경제노트(2007/05/15)" 의 것을 마치 내것인냥 ... 써본다.

HTTP/1.0 vs. 1.1

HTTP는 사용자에게 보다 좋은 Internet을 서비스하기 위해 제정이 되었다. 특히 사용자나 서버 모두에게 성능의 향상과 요구되는 시간의 최소화에 중점을 두고 있다. HTTP/1.0에서는 없거나 미약하여 HTTP/1.1에서 향상된 기능은 우선 지속적인 연결을 해 주는 persistent connection의 특징과 pipeline의 기능 및 전송하는 데이터의 양을 줄이는 데이터의 압축방식과 proxy server와 cache의 사용을 둘 수 있다.

HTTP의 기본구조와 1.0의 문제점과 이를 1.1에서 해결하는 방식에 대해서 살펴보자. HTTP는 기본적으로 MIME 형태로 이루어지며 request/response의 방식에 기반을 두고 있다. HTTP 1.0의 구조 및 문제점을 살펴보면, HTTP 1.0은 단순하게 open/operation/close의 방식을 취하고 있어서 단순하다. TCP connection당 하나의 URL만 fetch하며 매번의 request/response가 끝나면 연결이 끊기므로 매 번 필요할 때 마다 다시 연결을 해야 하므로 속도가 떨어진다. 그리고 한번에 얻어서 가져올 수 있는 데이터의 양이 제한되어 있다. 나아가 URL의 크기도 작다.

HTTP/1.0에서는 connection은 TCP의 open/close을 위한 flow의 제한으로 인해서 bandwidth가 적게 할당되어 연결된다. 그래서 congestion information의 손실로 인해서 disconnect가 될 수 있다. 계속되는 disconnection현상으로 인해서 한 서버에 계속에서 접속을 시도하게 되어서 과부하가 걸리게 되고 결국에는 성능이 떨어지게 된다. 이러한 문제점을 해결하기 위해서 HTTP/1.1에서는 multiple request에 대한 처리를 가능하게 해준다. 즉, request가 많이 서버에 전달되면 서버에서는 serial하게 response을 해 주어 해결을 하고 있다. 즉, request/response가 pipeline의 방식으로 진행이 가능하다.

HTTP/1.0에서는 client가 IP address와 서버가 1:1관계에 있다고 가정을 두고 있다. 그래서 request와 response는 직접 전달되고 있다고 인식한다. 하지만 HTTP/1.1에서는 하나의 IP address로 multiple web site를 지원이 가능하다. 즉 한 인터넷 주소로 여러 web site의 연결이 가능하다. 이때 client와 server는 Host request-header를 반드시 포함하고 있어야 하며 이 header를 주고 받아야 한다.

HTTP/1.1은 HTTP의 Internet에서의 impact를 줄이고 HTTP를 Internet Protocol에 잘 적용이 되도록 해주고 빨리 수행이 되도록 cache를 두어 성능을 향상하고 있다. 그리고 HTTP/1.0과 호환이 가능하다. 과거의 HTTP/1.0에서는 request와 response 메시지 모두에 적용되며 메시지의 body에는 영향을 주지 않는다. 기본적으로 HTTP/1.0에서는 Date와 Pragma를 사용하는데 이는 서버와 클라이언트의 현재시간을 알려주고 cache를 제어하기 위해 사용되는 method였으나 HTTP/1.1에서는 Pragma가 사용되지 않는다. 이 cache의 사용으로 인해 해결해야 할 부분이 있다.

즉 cache를 이용하여 어떻게 semantic하게 transparency를 제공하고 어느 적정한 수준이상의 cache가 사용되어 data가 저장되어 있는 경우 cache의 내용을 비워 주어야 한다. 이 과정은 reliable한 cache의 사용과 cache의 burst해지는 현상 등을 해결하기 위해 도입되었다.

그리고 HTTP/1.0에서는 주로 Last-Modified, 즉 Dates에만 의존해서 cache를 다루었지만 HTTP/1.1에서는 1.0에서 지원해 주는 기능 이외에 client에서 사용 가능한 미디어 타입을 명시하여 지원을 해 주고 있으며 또한 사용가능한 character set, 제공되는 encoding 방식과 인식 가능한 언어 등을 request header에 명시하여 메시지를 전달한다. 그리고 cache의 내용이 적절한지의 여부를 판단하기위해 If-Match, If-None-Match를 사용하고 있다.

또한 If-Range및 If-Unmodified-Since등을 비교하여 method를 수행할 수 있도록 하고 있다. 이 cache는 서버에 노출되어 있으므로 불필요한 자료를 막거나 주의를 요하는 자료 등은 저장하지 말아야 한다. 따라서 cache의 control에 주의를 요해야 한다. 특히 cache의 재사용을 하거나 하는 경우에는 proxy를 두어서 cache를 control하고 있다.

이때 물론 개인적인 data의 경우에는 이 proxy를 사용하지 말아야 한다. 이때 Max-Forwards를 두어서 거쳐 갈 수 있는 최대 proxy의 수를 제한할 수 있고, Proxy-Authentication을 두어 proxy server가 비공개인경우 사용자 인증을 위해 사용이 된다. Resource의 일부만을 받고 이어받기의 기능을 지원하기 위해서 Range의 새로운 header가 추가 되었다.

이제 response의 header의 내용을 살펴보면, 우선 HTTP/1.0에서는 location과 server및 WWW-Authenticate을 이용하고 있다. HTTP/1.1에서는 client에서 request를 보낸 이후 server에서 응답 메시지를 생성하기까지의 시간을 나타내는 age가 도입되었고, 만약 서버가 proxy server인 경우 사용자 인증을 요구하는 Proxy-Authenticate라는 헤더필드를 지원하고 있다. 그 이외에 Public, Retry-After, Warning 등의 정보가 추가되었다.

HTTP method는 우선 HTTP/1.0에서는 GET, HEAD, POST의 method가 사용되고 있는데 GET은 Request-URI에서 지정한 어떤 정보이든 Entity Body로 전달해 달라는 요청으로 이 Request-URI가 어떤 실행프로그램을 명시한 경우에는 이 프로그램의 실행결과를 전달하라는 의미이다. HAED의 경우는 Header의 정보만 요구하는 method이고 POST는 Request 메시지의 body에 포함된 자원을 Request-URI로 넘겨주는 경우 사용한다.

HTTP/1.1에서는 통신과 관련된 선택사항들에 대한 정보를 요구하는 경우 OPTION의 method를 지원하고 있으며, Request 메시에 포함되어 있는 data를 지정한 Request-URI로 저장하기 위한 PUT을 두고 있다. 또 특정한 resource를 지우기 위해 DELETE를 두고 있으며 최종 destination까지의 Loopback을 테스트하기 위한 TRACE method가 있다.

앞에서도 언급했지만 HTTP/1.0에서 매번 필요시에만 connection을 open하고 close하는 기능을 해결하기 위해서 HTTP/1.1에서는 multiple connection을 open할 수 있도록 하고 있다. 뿐만 아니라 몇몇 entity의 경우에는 그 길이를 모르므로 이를 해결하기 위해서 chunked encoding을 도입하여서 해결하고 있다. 그리고 전송한 data를 압축해서 전달이 가능하도록 하고 있어서 전달하고자 하는 data의 양을 줄인다.

이상에서 살펴보았듯 HTTP/1.0에서 HTTP/1.1로의 성능적인 면과 시간의 최소화에 중점을 두고 있다.

출처 : [직접 서술] RFC 1945 - Hypertext Transfer Protocol -- HTTP1.0 RFC 2616 - Hypertext Transfer Protocol -- HTTP1.1

참고 : 상혁아빠 블로그 - HTTP Status Code

참고 : TONG - HTTP Status Code