이 블로그를 닫지도, 열지도 못하고 방치했던 것은 내가 아물지 않았기 때문이다. 시위를 하는 과정에서 겪었던 감정 폭풍들도, 시위 후에 후폭풍으로 발생했던 일들도, 내게는 일생을 통틀어 겪어보지 못한 감정적인 수난이었다. 

 지금도 나는 그 수난을 묻어두었을 뿐 더 나아가지 못했다. 다만 한 가지 깨달은 것은 그 때 가장 아프고 힘들었던 일의 시작이었던 시위에 대한 기록을 품지 않고서는 나를 있는 그대로 인정하지 않는다는 느낌을 받았다. 그래서 다른 곳에서 기록하던 것들을 옮겨왔다.

 나는 시간이 흘러 흘러 비도덕적인 시장경제를 이해하고, 내게 그토록 이기적으로 굴었던 사람들도 이해하고, 다만 공감하지 못한 채, 그러한 것들을 경계하며 살아가길 바란다. 

저작자표시 비영리 변경금지

'일지라고 쓰고 일기' 카테고리의 다른 글

git alias 설정  (0) 2017.02.18
나는 아직도 그린팩토리 앞, 그 불그스름한 맨홀 위에 서 있다.  (1) 2016.01.22
12월 22일 일지  (0) 2014.12.22
8월 5일  (0) 2014.08.05
8월 4일  (0) 2014.08.04

// 직접 번역한 내용이라 오역 및 의역이 있을 수 있습니다. 다만 각 문장은 RFC 1939문서의 문장을 직역한 것이기 때문에 비교하면서 보면 의미 전달이 더 명확할 것입니다. 



1.Introduction 

 

인터넷의 더 작은 노드들 중 어떤 특정한 타입의 경우, message transport system(MTS)를 유지하는데 비실용적이다. 예를 들어서 workstation에 SMTP 서버를 허용하기 위해서 [RFC821], 혹은 연관되어 있는 로컬 mail delivery system이 계속해서 실행되도록 하기 위해서 필요한 cycle이나 disk space와 같은 충분한 자원이 없을 수도 있다. 비슷하게, 개인 컴퓨터를 IP-style 네트워크로 오랫동안 서로 연결된 상태로 유지하는 것은 비쌀 수도(혹은 불가능할 수도) 있다. (노드-로컬 클라이언트-가 "연결성"으로 알려진 자원을 부족하게 하고 있다)

그럼에도 불구하고 메일을 이러한 작은 노드(로컬 클라이언트)에서 관리하는 것은 매우 유용하고, 그들은 종종 메일을 핸들링하기 위해서 user agent(UA)라고 하는 것도 지원한다. 이러한 문제를 해결하기 위해서 MTS를 지원할 수 있는 로컬 클라이언트들은 maildrop 서비스를 지원한다. POP3는 동적이면서 유용한 방법으로 workstation에 서버에 있는 메일 드롭에 접근하는 것을 허가하기 위해 고안되었다. 보통, 이것은 원래 POP3 프로토콜이 서버에서 가지고 있는 메일을 워크스테이션에 가지고 오는 것을 허용하는 것이었다는 것을 의미한다.

POP3는 서버의 메일을 대량으로 조작하는 운영을 제공하기 위해서 고안되지 않았다; 일반적으로 메일은 다운받은 후에 지워진다. 더 발전한, 그리고 복잡한 프토토콜인 IMAP4는 RFC1730에서 논의되고 있다.

이 문서는 이제부터 "클라이언트 호스트"라는 용어는 POP3 서비스를 사용하는 쪽을 지칭하고, "서버 호스트"는 POP3 서비스를 제공하는 쪽을 지칭할 것이다.

 

2.A Short Digression

 


이 문서는 클라이언트 호스트가 메일을 어떻게 transport system에 보내는지 구체적으로 알아보지 않을 것이다. 하지만 그 방법은 아래와 같이 이 문서의 철학과 맥락을 같이 한다.

 

 user agent가 클라이언트 호스트에서 transport system에서 메세지를 보내면, SMTP 커넥션을 맺고 그것의 relay host에 메일을 보낸다. 이 릴레이 호스트는 클라이언트 호스트를 위한 POP3 서버 호스트일 수 있지만, 반드시 그래야 하는 것은 아니다. 물론, 그 릴레이 호스트는 배달을 위해서 임의의 수신자 주소로 반드시 메일을 받아들여야 하지만 이것은 모든 SMTP 서버에 요구되는 기능은 아니다.

 


3.Basic Operation

  •  최초에, 서버 호스트는 POP3서비스를 TCP 포트 110에서 리스닝하는 것으로 시작한다. 
  •  클라이언트 호스트가 서비스를 사용하려고 할 때, 그것은 서버호스트와 TCP 커넥션을 맺는다.
  •  커넥션이 맺어지고 나면 POP3 서버는 greeting을 보낸다.
  •  그 후에 클라이언트와 POP3서버는 커넥션이 끝나거나 혹은 파기될 때까지 서로 commands 와 responses를 주고 받는다.
  • POP3에서의 command는 대소문자를 구분하지 않으며, 하나 이상의 argument를 받을 수 있다.
  • 모든 커맨드는 CRLF pair에 의해서 끝난다.
  • keyword와 argument는 인쇄 가능한 ASCII 문자로 구성되어 있다.
  • keyword와 arguments는 공백 문자(space)로 각각 구분된다.
  • keyword는 3~4개의 캐릭터 문자이다. 
  • 각각의 argument는 최대 40개의 캐릭터 문자까지 가능하다.
  • POP3에서의 응답은 하나의 상태 지시자와 하나의 keyword, 그리고 뒤에 추가정보를 덧붙일 수 있도록 구성되어 있다.
  • 모든 응답은 CRLF 페어에 의해서 끝난다. 
  • 응답은 제일 끝에 있는 CRLF 문자를 포함해서 최대 512자의 캐릭터 길이가 가능하다.
  • 응답에는 두개의 상태 지시자가 있다. positive:("+OK") / negative: ("-ERR")
  • 서버는 반드시 "+OK"와 "-ERR"를 대문자로 보내야 한다.
  • 어떤 커맨드에 대한 응답은 여러 줄일 수 있다.
  • 첫번째 줄의 응답과 개행문자를 받은 후에도 각각의 개행 문자 페어에 의해서 끝나는 추가된 줄이 더 들어오는 경우와 같이 명확하게 아래를 가리키고 있을 경우에는 응답이 여러줄 일 수 있다.
  • 모든 라인의 응답이 보내지고 난 후, termination 옥텟(decimal code 046, ".")과 CRLF pair를 포함하고 있는 마지막 줄이 보내진다.
  • 만약 여러 줄의 응답이 터미네이션 옥텟(".")으로 시작한다면 그 라인은 미리 해당 라인의 시작 부분에 터미네이션 옥텟을 덧붙여서 보내어 행이 "byte-stuffed" 된다. 
  • 그러므로 여러줄의 응답은 "CRLF.CRLF"로 끝난다.
  • 여러 줄의 응답을 검증해 볼 때 클라이언트는 한 줄의 시작이 터미네이션 옥텟으로 시작하는지 확인한다.
  • 만약 한 줄의 시작이 터미네이션 옥텟으로 시작하고, 옥텟 뒤에 CRLF가 따라붙는다면, 그 줄의 첫번째 옥텟(터미네이션)은 없앨 것이다.
  • 만약 CRLF가 즉시 터미네이션 캐릭터에 따라오면 POP 서버로부터 온 그 응답은 끝난 것이고,".CRLF"를 포함하고 있는 라인은 여러줄로 구성된 응답의 일부로 고려되지 않을 것이다.
  • POP3 세션은 그것의 생명주기 동안 몇 가지의 상태를 통해 진행된다.
  • 일단 TCP 커넥션이 맺어지고 POP3 서버가 greeting을 보내면 세션은 'AUTHORIZATION'상태로 들어간다.
  • 이 상태에서 클라이언트는 반드시 스스로 POP3 서버에 인증을 해야 한다.
  • 일단 클라이언트가 이 과정을 성공적으로 넘어가면, 서버는 클라이언트의 메일드롭과 연관된 자원을 얻고, 세션은 TRANSACTION 상태로 진입한다.
  • 이 상태에서는 클라이언트는 POP3 서버의 일부에 대해서 동작을 요청한다.
  • 클라이언트가 QUIT 커맨드를 보내고 나면 세션은 UPDATE 상태로 진입한다.
  • 이 상태에서 POP3 서버는 TRANSACTION 상태인 동안 얻었던 모든 자원을 release하고 goodbye 하고 말한다.
  • 그 후에 TCP 커넥션은 닫힌다.
  • 서버는 '반드시' 인정되지 않거나, 제대로 실행되지 않거나, 혹은 문법적으로 옳지 않은 커맨드에도 네거티브 상태 지시자와 함께 응답을 보내줘야 한다.
  • 서버는 세션이 옳지 않은 상태에서 발행된 커맨드에도 반드시 네거티브 상태 지시자와 함께 응답해야 한다.
  • 클라이언트는 서버가 추가적인 커맨드를 지원하지 않는 것과 서버가 원하지 않거나 커맨드를 수행할 수 없는 것을 구분할 방법이 없다.
  • POP3 서버는 비활성화된 자동 로그아웃 타이머를 가질 수도 있다.
  • 이러한 타이머는 최소 10분동안 반드시 지속 가능해야 한다.
  • 클라이언트로부터 어떠한 커맨드라도 그 시간 사이에 온 것이 있다면 자동 로그아웃 타이머를 리셋하도록 해야 한다.
  • 타이머가 만료되고 나면, 세션은 UPDATE 상태로 진입하지 않는다.-- 서버는 클라이언트에 어떤 메세지도 지우거나 어떠한 응답도 보내지 않고 TCP커넥션을 닫는다.

4. The AUTHORIZATION state

  • 일단 POP3 클라이언트에 의해서 TCP 커넥션이 맺어지면, pop3 서버는 한 줄의 greeting을 보낸다.
  • 이것은 어떠한 positive 응답이든 상관없다.
  • 예를 들어 아래와 같은 것도 가능하다.
S: +OK POP3 server ready
  • POP3 세션은 이제 AUTHORIZATION 상태이다. 클라이언트는 이제 반드시 POP3 서버에 자신을 밝히고 인증을 받아야 한다.
  • 이 문서에서는 그 인증을 받기 위해 사용 가능한 두가지 매커니즘을 서술하고 있다.
  • User and PASS 커맨드 조합과 APOP command이다.
  • 두 매커니즘 다 이 문서의 아래에 서술되어 있다.
  • 추가적인 인증을 받는 매커니즘은 [RFC1734]에 서술되어 있다.
  • 반면, 모든 POP3 서버에서 필수적인 하나의 인증 매커니즘도 없으므로 POP3 서버는 최소한 하나의 인증 매커니즘을 반드시 제공해야 한다.
  • 일단 POP3서버가 클라이언트가 적절한 메일드랍에 접근하기 위해 받아야 하는 어떠한 인증 커맨드를 사용할 것을 결정하면 그 POP3 서버는 세션이 UPDATE 상태에 들어가기 전에 메세지가 수정되거나 지워지는 것을 막기 위해 그 메일드랍에 대해 배타적 접근 락을 획득한다.
  • 만약 락이 얻는데 성공하면 POP3서버는 positive 상태지시자와 함께 응답을 보낸다.
  • POP3 세션은 이제 어떤 메세지도 deleted 표시가 되지 않은 채로 TRANSACTION 상태에 들어간다.
  • 만약 메일드랍이 어떠한 이유들로 인해 열리지 않는다면(예를 들어 락을 획득하지 못했거나 클라이언트가 적합한 메일드랍에 접근하는 것을 거부당했거나 메일드립을 파싱할 수 없을 때) POP3 서버는 negative 상태 지시자를 이용하여 응답한다.
  • (만약 락을 획득했지만 POP3서버가 negative 상태 지시자를 보내는 것을 의도한다면, POP3 서버는 반드시 커맨드를 거부하기 전에 락을 먼저 해제해야 한다.)
  • negative 상태 지시자를 보낸 후에 서버는 커넥션을 끊을 수 있다.
  • 만약 서버가 커넥션을 끊지 않는다면 클라이언트는 새로은 인증 커맨드를 발행해서 다시 시작할 수 있고, 혹은 클라이언트에서 QUIT 커맨드를 날릴 수도 있다.
  • POP3서버가 메일드랍을 열고 난 후에, 서버는 각각의 메세지에 메세지 넘버를 할당하고 각 메세지의 크기를 옥텟에 기록한다.
  • 메일드랍의 첫번째 메세지에는 "1"을 할당하고, 두번째에는 "2"를 할당하는 식으로, n번째 메세지는 "n"번의 메세지 넘버를 할당한다.
  • POP3 커맨드와 응답에서는 모든 메세지 넘버와 메세지 사이즈가 base-10(i.e., decimal) 형식으로 표현된다.
  • 여기에 AUTHORIZATION 상태일 때 간단한 QUIT 커맨드에 대한 요약이 있다.
QUIT
QUIT
Arguments: none
Restrictions: none
Possible Responses:
 +OK
Examples:
 C: QUIT
 S: +OK dewey POP3 server signing off

 

5. The TRANSACTION State

  • 일단 클라이언트가 성공적으로 POP3서버에서 인증되고 POP3 서버가 적합한 메일드랍을 락을 걸고 열었다면 POP3 세션은 이제 TRANSACTION 상태가 된 것이다. 클라이언트는 이제 아래에 나온 어떠한 POP3 커맨드든 반복적으로 보낼 수 있다.
  • 각각의 커맨드를 보낸 후에는 POP3 서버가 응답을 보낸다.
  • 마침내는 클라이언트는 QUIT 커맨드를 보내고, POP3세션은 UPDATE 상태에 접어든다.
  • 아래에 TRANSACTION 상태에서 사용 가능한 POP3 커맨드가 있다.
STAT

STAT

Arguments: 없음

Restrictions: TRANSACTION 상태에서만 사용할 수 있음

Discussion:
POP3 서버는 메일드랍에 대한 정보를 포함한 라인과 함께 positive 응답을 발행한다.
이 라인은 그 메일드랍에 대한 "drop listing"이라고 부른다.

파싱을 간편하게 하기 위해서 모든 POP3 서버는 drop listing들에 대해서 특정한 포맷을 사용할 것을 요구받는다.positive 응답의 경우 "+OK" 뒤에 스페이스 한칸, 메일드랍의 메세지 개수, 스페이스 한칸, 메일드랍의 사이즈가 들어있는 옥텟들을 포함한다. 이 문서는 메일드롭의 사이즈 뒤에 추가적인 정보가 덧붙여서 와야 할 필요가 없다는 것을 명시한다. 최소한의 완성을 위해서 개행문자 페어가 응답하는 라인의 마지막에 반드시 들어가야 한다. 더 advanced하게 덧붙여온 내용은 다른 정보를 담고 있을 수 있다. 

 NOTE: 이 문서는 drop listing에 추가적인 정보를 넣는 것을 비추한다. 다른 선택적인 편의는 후에 클라이언트가 메일드랍에서 메세지를 파싱하는 것을 허용하는 부분에서 논의된다.

 

지워진 것으로 표시된 메세지들은 전체 개수에 포함되지 않는다는 것을 기억하라.

Possible Responses:
+OK nn mm
+OK (메일 드랍의 메세지 개수) (메일드랍의 사이즈가 들어있는 옥텟)

Examples:
C: STAT
S: +OK 2 320

LIST [msg]

LIST [msg]

Arguments:
만약 존재한다면 메세지 넘버(선택), 삭제된 것으로 표시되어 있을 경우 언급하지 않을 수도 있다.

Restrictions:
TRANSACTION 상태에서만 사용 가능

Discussion:

  • 만약 하나의 인자가 주어질 경우, POP3 서버가 그 메세지에 대한 정보를 포함한 positive 응답을 발행한다.
  • 이 라인은 해당 메세지에 대한 "스캔 리스팅"이라고 한다.
  • 만약 어떤 인자도 주어지지 않을 경우, POP3 서버가 positive 응답을 발행하는데, 이 때의 응답은 여러 줄이다.
  • 최초의 +OK 이후, 메일드랍 안에 있는 각각의 메세지에 대해서 POP3 서버는 그 메세지의 정보를 라인에 포함해서 응답한다.
  • 이 라인 역시 "scan listing"이라고 한다.
  • 만약 메일 드랍 안에 메세지가 하나도 없을 경우, POP3서버는 스캔리스팅 없이 응답한다.
  • 즉, POP3 서버는 positive 응답 뒤에 termination octet과 CRLF 페어를 덧붙여 발행한다.
  • 파싱을 쉽게 하기 위해서, 모든 POP3 서버들은 스캔 리스팅을 위한 특정한 포맷을 사용해야 한다.
  • 스캔 리스팅은 메세지의 메세지 번호(message-number)와 띄어쓰기 한 칸, 그 메세지 사이즈의 정확한 옥텟으로 구성되어있다. (+OK 1 1234)
  • 메세지의 정확한 사이즈 계산 방법은 아래의 "Message Format" 부분에 상술되어 있다.
  • 이 문서는 스캔 리스팅에서 메세지 사이즈에 무엇이 들어가든 요구하지 않는다.
  • 최소한의 실행 조건은 응답의 마지막이 CRLF pair로 이루어져야 한다는 정도이다.
  • 더 advanced한 실행 조건은 그 메세지에서 해석된 다른 정보에 포함되어 있을 것이다.

NOTE: 이 문서는 스캔리스팅에서 추가적인 정보를 제공하는 것을 무척 비추한다. 다른 추가적인 역할은 뒤에 있는 메일드랍에 있는 메세지를 파싱하기 위해 클라이언트에게 허가하는 부분에서 논의된다.

 

  • 삭제 표시가 된 메세지들은 리스트에 올라오지 않는다는 것을 기억하라.

Possible Responses:
+OK (drop listing을 스캔한 결과 출력)
-ERR no such message

Examples:
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120

S: 2 200
S: .
...
C: LIST 2
S: +OK 2 200
...
C: LIST 3
S: -ERR no such message, only 2 messages in maildrop

 

RETR msg

RETR msg

Arguments:
메세지 번호(필수). 그러나 삭제된 것으로 표시되어있는 경우 언급하지 않을 수도 있다.

Restrictions:

TRANSACTION state 에서만 사용 가능

Discussion:
만약 POP3 서버가 positive 응답을 보낸다면 응답은 여러줄이 된다. 최초의 +OK를 보낸 후에 POP3서버는 메세지 번호를 응답으로 보내고, (모든 여러줄의 응답에 있어서 그렇듯)byte-stuff가 되지 않게 조심해서 termination 문자를 보낸다.

Possible Responses:
+OK message follows
-ERR no such message

Examples:
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .

DELE msg

DELE msg

Arguments:
메세지 번호(필수). 그러나 삭제된 것으로 표시될 경우 언급하지 않을 수 있음.

Restrictions:
TRANSACTION state 에서만 사용가능

Discussion:
POP3 서버는 해당 메세지를 지워진 것으로 표시한다. 이후로 이 메세지 번호와 관계가 있는 메세지에 대한 POP3 커맨드에 대한 참조도 에러를 낸다. POP3 서버는 세션이 UPDATE 상태로 진입하기 전까지 실제로 메세지를 지우지 않는다.

Possible Responses:
+OK message deleted
-ERR no such message

Examples:
C: DELE 1
S: +OK message 1 deleted
...
C: DELE 2
S: -ERR message 2 already deleted

NOOP

NOOP

Arguments: none

Restrictions:
TRANSACTION state 에서만 사용가능

Discussion:
POP3 서버는 아무 것도 하지 않는다. 그저 positive 응답을 보낼 뿐.

Possible Responses:
+OK

Examples:
C: NOOP
S: +OK

RSET

RSET

Arguments: none

Restrictions:
TRANSACTION state 에서만 사용가능

Discussion:
만약 어떤 메세지가 POP3 서버에서 삭제된 것으로 표시되었을 경우, 삭제 표시를 지운다. 그 후에 POP3 서버는 positive 응답을 보낸다.

Possible Responses:
+OK

Examples:
C: RSET
S: +OK maildrop has 2 messages (320 octets)

 

6. The UPDATE state

  • 클라이언트가 TRANSACTION 상태에서 QUIT 커맨드를 보내면 POP3 세션은 UPDATE 상태로 진입한다. (만약 클라이언트가 AUTHORIZATION 상태에서 QUIT 커맨드를 발행하면 POP3 세션은 파기되지만 UPDATE 상태로 진입하지는 않는다.)
  • 만약 세션이 QUIT 커맨드를 날리지 않았는데 어떠한 이유에서든 간에 파기되었을 경우, POP3 세션은 UPDATE상태로 진입하지 않고, 메일드랍의 어떤 메세지도 지우지 않아야 한다.

 

QUIT

QUIT

Arguments: none

Restrictions: none

Discussion:
POP3 서버는 메일드랍에서 삭제 표시된 모든 메세지를 삭제하고, 이 작업의 상태를 응답으로 보낸다. 만약 자원 부족이나 메세지를 삭제 중에 요청이 충돌하는 등의 이유로 에러가 발생한다면, 메일드랍은 삭제 표시가 되어있었던 메세지들을 가지고 있거나 그러한 표시가 되지 않은 메일들을 가지고 있어서 그러한 메일을 삭제하는 결과를 낼 수도 있다. 이외에 어떤 케이스에서도 서버는 삭제 표시가 되지 않은 메세지를 삭제하지 않는다.

삭제가 성공적이건 그렇지 않건, 서버는 메일드랍에 대한 배타적 점유 락을 해제하고 TCP 커넥션을 끊는다.

Possible Responses:
+OK
-ERR some deleted messages not removed

Examples:
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
...
C: QUIT
S: +OK dewey POP3 server signing off (2 messages left)
...

 

7. Optional POP3 Commands

  • 위에서 논의된 POP3 커맨드는 POP3서버의 모든 실행에 의해서 지원되어야 한다.
  • 아래에 서술된 선택적인 POP3 커맨드들은 간단한 POP3 서버에 실행을 보류하고 있는 동안 POP3 클라이언트들이 메세지 핸들링에 있어서 더 큰 자유를 누릴 수 있게 허용한다.

NOTE: 이 문서는 이러한 커맨드들을 지원할 것을 강하게 추천한다.

 

  • 즉, 이 메모의 철학은 POP3 클라이언트가 정보를 갖기를 바라는 것이지, 서버가 갖기를 바라는 것이 아니다.

 

TOP msg n

TOP msg n

Arguments:
삭제 표시된 메세지는 표시되지 않을 수 있는(선택) 메세지 넘버(필수), 음수가 아닌 줄의 숫자(필수)

Restrictions:
TRANSACTION 상태에서만 가능

Discussion:
만약 POP3 서버가 positive 응답을 보낸다면, 그 응답은 멀티 라인일 것이다. 최초의 +OK응답 이후에 POP3서버는 빈 줄로 메세지의 바디와 구분되는 그 메세지의 헤더를 보낸다. 그리고 명시된 메세지의 바디의 줄 숫자만큼 종료 캐릭터를 byte-stuff하지 않기 위해 조심하면서 (모든 멀티라인 응답일 경우 그렇듯이)

만약 POP3 클라이언트에 의해 보내진 숫자가 바디에 들어있는 숫자보다 더 크다면 POP3 서버는 전체 메세지를 보낸다는 것을 기억하라.

Possible Responses:
+OK top of message follows
-ERR no such message

Examples:
C: TOP 1 10
S: +OK
S: <the POP3 server sends the headers of the message, a blank line, and the first 10 lines of the body of the message>
S: .
...
C: TOP 100 3
S: -ERR no such message

UIDL [msg]

UIDL [msg]

Arguments:
만약 존재하는 메세지 넘버일 경우(선택), 그러나 삭제 표시가 되어있을 경우에는 참조하지 않는다. 
a message-number (optional), which, if present, may NOT
refer to a message marked as deleted

Restrictions:
TRANSACTION 상태일 때만
may only be given in the TRANSACTION state.

Discussion:

  • 만약 변수가 있다면, POP3 서버가 해당 메세지에 대한 정보를 포함한 라인과 함께 positive 응답을 발행한다.
  • 이 라인은 해당 메세지에 대한 "고유 id listing"이라고 한다.
  • 만약 주어진 변수가 없다면, POP3 서버는 positive응답을 발행한다.
  • 그리고 주어진 그 응답은 멀티라인이다. 최초의 +OK 이후, 메일드랍에 있는 각각의 메세지에 대한 정보를 포함한 라인을 응답으로 전송한다.
  • 이 라인은 해당 메세지에 대한 "unique id listing"이라고 한다.
  • 파싱을 쉽게 하기 위해서 모든 POP3서버들은 고유ID 목록에 대하여 특정한 포맷을 사용해야 한다.
  • 고유 ID목록은 해당 메세지의 메세지 넘버와 그 뒤에 따라오는 공백문자와 메세지의 고유ID로 구성된다.
  • 고유ID 목록에 있는 고유ID 외에 추가 정보는 없다.
  • 메세지의 고유 ID 는 서버에 의해서 임의로 결정된 문자열이다.
  • 이 문자열은 메일드랍 안에 있는 메세지를 고유하게 식별하고, 세션과 관계없이 유지되며, 0x21부터 0x7E사이의 하나에서 70개의 캐릭터들로 구성되어 있다.
  • 이 지속성은 세션이 끝나고 UPDATE state로 진입하더라도 유지되어야 한다.
  • 서버는 특정 고유ID를 사용하고 있는 개체가 있는 한, 절대 메일드랍에 주어진 고유ID를 재사용해서는 안된다.
  • 삭제 표시가 된 메세지는 목록에 들어가지 않는다는 것을 기억하라.
  • 보통 서버가 임의로 메일드랍에 대해 할당된 고유ID를 저장하여 완성하는 것을 선호하는 반면에, 이 명세는 고유 ID를 그 메세지의 계산된 해쉬값을 허가하기 위해서 의도되었다.
  • 클라이언트는 같은 고유ID를 가지고 있는 두개의 동일한 메세지의 복사본이 하나의 메일드랍 안에 있는 상황을 처리할 수 있어야 한다.

Possible Responses:
+OK unique-id listing follows
-ERR no such message

Examples:
C: UIDL
S: +OK
S: 1 whqtswO00WBw418f9t5JxYwZ
S: 2 QhdPYR:00WBw1Ph7x7
S: .
...
C: UIDL 2
S: +OK 2 QhdPYR:00WBw1Ph7x7
...
C: UIDL 3
S: -ERR no such message, only 2 messages in maildrop

USER name

USER name

Arguments:
오직 서버에게만 의미가 있는 메일박스를 식별하는 문자열(필수)

Restrictions:
POP3 greeting을 보내거나 USER 혹은 PASS 커맨드의 실패 후, AUTHORIZATION 상태에서만 사용가능

Discussion:

  • USER와 PASS 커맨드를 사용하는 인증을 하기 위해서, 클라이언트는 반드시 먼저 USER 커맨드를 제일 처음에 보내야 한다.
  • 만약 POP3서버가 positive 상태 지시자 응답("+OK")을 보내오면, 클라이언트는 인증을 마무리 짓기 위해 PASS 커맨드를 발행할 수 있고, 혹은 QUIT 커맨드를 이용해 POP3 세션을 파기할 수도 있다. 
  • 만약 POP3 서버가 negative 상태 지시자("-ERR")를 이용해 응답한다면 클라이언트는 새로운 인증 커맨드를 보내거나 혹은 QUIT 커맨드를 날릴 수 도 있다.
  • 서버는 그런 메일박스가 존재하지 않더라도 positive 응답을 보낼 수도 있다. 서버는 메일박스가 존재하지만 평문(plaintext)를 허용하지 않을 때 negative 응답을 보낼 수도 있다.
  • password 인증방식이다.

Possible Responses:
+OK name is a valid mailbox
-ERR never heard of mailbox name

Examples:
C: USER frated
S: -ERR sorry, no mailbox for frated here
...
C: USER mrose
S: +OK mrose is a real hoopy frood

PASS string

PASS string

Arguments:
서버/메일박스의 구체적인 비밀번호(필수)
a server/mailbox-specific password (required)

Restrictions:
AUTHRIZATION 상태에서 USER 커맨드의 성공 직후에만 가능

Discussion:
- 클라이언트가 PASS 커맨드를 보냈을 때, POP3 서버는 클라이언트가 적합한 메일드랍에 접근할 수 있는지 여부를 결정하기 위해서 USER 와 PASS 커맨드의 변수 짝을 사용한다. 
- PASS 커맨드가 오직 하나의 변수를 가질 수 있기 때문에 POP3 서버는 변수 안에 있는 공백문자(SPACE)들을 변수 분리자로 사용하는 대신 비밀번호의 일부로 처리할 수 있다.

 

Possible Responses:
+OK maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop

Examples:
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: -ERR maildrop already locked
...
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets)

APOP name digest

APOP name digest

Arguments:
메일박스를 식별하는 스트링과 MD5 다이제스트 스트링(둘다 필수)

Restrictions:
POP3 greeting 이나 USER / PASS 커맨드의 실패 후의 AUTHORIZATION 상태에서만 사용가능

Discussion:

  • 일반적으로 각각의 POP3 세션은 USER/PASS 커맨드의 교환으로 시작한다. 
  • (in a server/user-id specific password)하는 이 결과는 평문으로 네트워크에서 보내어진다. 
  • POP3 의 간헐적인 사용은 큰 위험을 초래하지 않는다. 
  • 그러나 많은 POP3 클라이언트들 POP3 서버에 연결하려는 정기적인 기초 작업(새로운 메일을 확인하는 것 같은)을 시도한다. 
  • 게다가 세션 인터벌 초기화는 5분에 한번씩 일어나야 한다. 
  • 그러므로 비밀번호가 유출될 위험은 더 커진다. 
  • 인증 대체 방법은 원래의 인증방식과 보호를 다시 하되(replay), 네트워크 상에 평문으로 비밀번호를 노출하지 않는 방식 두가지 다 제공할 것이 요구된다. APOP 커맨드는 이 기능을 제공한다.

 

  • APOP 커맨드를 수행하는 POP3서버는 그것의 banner greeting에 timestamp를 포함해서 보낸다. ??timestamp의 syntax는 [RFC822]의 'msg-id'와 일치하고 반드시 POP3 서버가 banner greeting에서 발행하는 각 시간과 달라야 한다. 예를 들어 UNIX 에서 실행 했을 때 POP3 서버 인스턴스에 대해 각각 다른 UNIX 프로세스가 사용되므로, timestamp의 형식은 이렇게 될 것이다.

<process-ID.clock@hostname>

 

  • 'process-ID'는 프로세스의 PID로, 십진수이고, clock은 시스템 시간의 십진수이다. 그리고 hostname은 POP3 서버가 실행되고 있는 host의 충분히 적합한 도메인 네임을 의미한다.

 

  • POP3 클라이언트가 이 타임스탬프를 만들면 APOP command를 발행한다. 'name'파라미터에는 USER 커맨드에서 사용하는 인자인 'name'을 보내면 된다. 
  • 'digest' 파라미터에는 그 뒤에 공유된 비밀(shared secret)이 따라오는 timestamp(angle-brackets을 포함하는)를 포함한 문자열이 [RFC1321]의 MD5 알고리즘에 의해서 계산되어있다. 
  • 이 공유된 비밀은 POP3 클라이언트와 서버만이 알고 있는 문자열이다. 
  • 이 비밀의 정보는 어떤 개체로든 성공적으로 고유한 사용자인 척 위장하는 것을 허락할 것이기 때문에 이 비밀의 승인되지 않은 노출을 예방하기 위해서 조심스러운 관리가 필요하다. 
  • 'digest' 파라미터는 16진수 형식의 소문자 ASCII 문자의 16-옥텟으로 구성되어 있다. 
  • POP3 서버가 APOP 커맨드를 받으면 그것은 제공된 digest를 확인한다. 
  • 만약 digest가 맞으면 서버는 positive 응답을 보내고 POP3세션은 TRANSACTION 상태로 진입한다. 
  • 반면, negative 응답이 발행되고, POP3세션은 AUTHORIZATION 상태로 남아있는다.
  • 공유된 비밀의 길이가 길어질 수록 그것을 추론하기 위한 난이도가 높아진다는 것을 기억하라. 
  • 그것으로써 공유된 비밀은 긴 문자열(최소한 아래의 예시와 같이 8 캐릭터 이상의)이어야 한다.

Possible Responses:
+OK maildrop locked and ready
-ERR permission denied

Examples:
S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)

이 예시에서 공유된 비밀은 'tanstaff' 이다. 그러므로 MD5 알고리즘은 아래와 같은 스트링에 적용된다.

<1896.697170952@dbc.mtview.ca.us>tanstaaf

이 결과 값은 이와 같다.

c4c9334bac560ecc979e58001b3e22fb

 

8. Scaling and Operational Considerations

  • 위에 서술된 몇몇의 추가적인 커맨드들이 POP3 프로토콜에 덧붙여졌기 때문에, 대부분의 사용자들이 서로 연결되어 있지 않은 큰 규모의 상업적인 post office operation 상에서 이 추가적인 옵션 커맨드들을 사용하는 과정에서 경험이 축적되어왔다.
  • 이러한 상황들에서, 그리고 사용자와 POP3 클라이언트 공급업체들은 UIDL 커맨드를 사용하는 것과 DELE 커맨드를 발행하지 않는 조합이 IMAP과 공조했을 때 약한 버전의 "mail-drop 을 준영구적인 저장소"의 기능으로 제공할 수 있다는 것을 발견했다.
  • 물론 존재하는 커넥션에 대해 새롭게 도착한 메세지를 당겨오거나 서버에 있는 여러개의 폴더를 지원하는 것과 같은 IMAP의 다른 기능들은 POP3에 존재하지 않는다.
  • 이 기능들이 일상적인 유저에 의해 이러한 방법으로 사용될 때, 서버에서 이미 읽은 메세지가 구분없이 다시 쌓이는 경향이 있어왔다.
  • 이것은 서버운영자의 관점에서 보았을 때 명확하게 부적절한 행동 패턴이다.
  • 이 상황은 POP3의 제한적인 기능이 수백 수천개의 메세지를 가지고 있는 메일드랍의 효율적인 핸들링을 허용하지 않는다는 사실에 의해서 악화된다.
  • 결과적으로, 이것은 특히 사용자가 POP3만 통해서 메일드랍에 접근할 수 있을 경우의 큰 규모의 멀티유저 서버의 운영자에게 추천된다. 이 때 고려되어야 할 옵션은 이러하다:

   <사용자 별 메일드랍 저장 용량과 같은 것을 부과할 때>

  • 이 옵션에 대한 불리한 점은 메세지의 축적이 사용자가 메일드랍에 새로운 메세지를 받지 못하는 결과를 초래할 수 있다는 점이다.
  • 이 옵션을 선택한 사이트는 반드시 사용자에게 사용자의 메일드랍이 적합한 메세지의 수신으로 인해 용량이 거의 다 찼거나 현재 꽉 찼다는 것을 알려줄 것을 보장해야 한다.

<사이트의 정책이 서버에서 메일을 보유하는 것 대하여 고려하도록 강제하라>

  • 사이트들은 서버에서 읽은 혹은 읽지 않은 메세지의 저장과 보유에 대한 local policy를 세우는 것이 자유롭다.
  • 예를 들어서 사이트는 서버에서 읽지 않은 메세지를 60일 이후에 지울수 있고 읽은 메세지를 7일 후에 지울 수도 있다.
  • 이러한 메세지 삭제는 POP3프로토콜의 영역 밖에서 벌어지는 일이고, 프로토콜 위반을 고려하지 않는다.
  • 메세지 삭제 정책을 강제하는 서버 운영자들은 반드시 모든 사용자가 이러한 정책이 유효하다는 것을 잘 알고 있도록 신경을 써야 한다.
  • 클라이언트는 절대로 사이트의 정책이 자동적으로 메세지 삭제를 할 것이라고 가정해서는 안되며, 반드시 필요할 때 DELE 커맨드를 사용해서 명시적으로 메세지를 삭제하는 것을 계속해야한다.
  • 이것은 사이트가 강제하는 메세지 삭제 정책이 사용자 커뮤니티에 혼란을 가져올 수도 있다는 것을 주목해야 한다. 왜냐하면 그들의 POP3클라이언트가 실제로 서버에서는 지원하지 않는데도 메일을 서버에 남기는 configuration 옵션을 포함하고 있을 수도 있기 때문이다.
  • 사이트의 정책이 특별한 경우, 메세지들이 서버에서 단 한번만 다운로드되고 다운로드를 마치면 삭제되는 경우도 있다.
  • 이것은 POP3 서버의 소프트웨어에서 아래와 같은 매커니즘에 의해서 수행될 수 있다. : "클라이언트에 의해서 수행되는 QUIT에 의해서 종료되는 POP3 클라이언트의 로그인은 세션이 유지되는 동안 RETR 커맨드에 의해서 다운로드한 모든 메세지를 삭제한다."
  • 비정상적인 커넥션의 종료(예를 들어 QUIT이 클라이언트로부터 수신되지 않았는데)로 인해 메세지를 삭제하지 않는 것은 중요하다.
  • 왜냐하면 클라이언트는 메세지를 성공적으로 받거나 저장하지 못했을 수도 있기 때문이다.
  • 다운로드 후 삭제 정책을 수행하는 서버는 또한 추가적인 TOP 커맨드를 불가능하게 하거나 혹은 제한하도록 원할 수 있다.
  • 왜냐하면 이것은 모든 메세지를 다운로드하는 것의 대안적인 매커니즘으로 사용될 수 있기 때문이다.

9. POP3 Command 요약

최소한의 POP3 커맨드:

USER name AUTHORIZATION state에서 사용 가능
PASS string
QUIT

STAT TRANSACTION state에서 사용 가능
LIST [msg]
RETR msg
DELE msg
NOOP
RSET
QUIT

 

추가적인 POP3 커맨드:

APOP name digest AUTHORIZATION state에서 사용 가능

TOP msg n TRANSACTION state에서 사용가능
UIDL [msg]

 

POP3 응답:

 

+OK
-ERR

  • STAT, LIST, UIDL 커맨드의 예외성을 기억하라.
  • 모든 커맨드에 대해서 POP3 서버에 의해서 주어진 응답은 반드시 "+OK"와 "-ERR"이 명백히 주어져야 한다. 
  • 이 이후에 나오는 응답은 클라이언트에 의해서 무시될 수도 있다. 

 

 


10. POP3 세션 예시

S: <wait for connection on TCP port 110>
C: <open connection>
S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK mrose's maildrop has 2 messages (320 octets)
C: STAT
S: +OK 2 320
C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends message 1>
S: .
C: DELE 1
S: +OK message 1 deleted
C: RETR 2
S: +OK 200 octets
S: <the POP3 server sends message 2>
S: .
C: DELE 2
S: +OK message 2 deleted
C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
C: <close connection>
S: <wait for next connection>

11. Message 형식

  • POP3 세션 동안 전송된 모든 메세지들은 RFC822에서 규정된 Internet text messages의 표준 형식과 일치하는 것으로 가정한다.
  • 이것은 서버 호스트에 있는 메세지의 옥텟의 count와 해당 메세지에 할당된 실제 옥텟의 count가 end-of-line에 대한 local 컨벤션의 차이로 인해서 다를 수도 있다는 점에서 중요하다.
  • 일반적으로, POP3 세션의 AUTHORIZATION state에 있는 동안, POP3 서버는 메일드랍에서 각 메세지를 열 때, 그 메세지의 사이즈를 옥텟으로 계산할 수 있다.
  • 예를 들어, 만약 POP3 서버 호스트가 내부적으로 end-of-line을 하나의 캐릭터 문자로 나타내면, POP3 서버는 이 메세지에 들어있는 모든 해당 캐릭터 문자에 대해서 2 옥텟으로 카운트할 것이다.
  • 터미네이션 옥텟으로 시작하는 메세지에 들어있는 줄들은 두번 카운트 될 필요가 없다는(그리고 해서도 안된다는) 점에 주목하라.
  • 왜냐하면 POP3 클라이언트는 멀티라인 응답을 받으면 byte-stuffed된 터미네이션 캐릭터를 삭제할 것이기 때문이다.

12. 참고문헌

[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821, USC/Information Sciences Institute, August 1982.

[RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982.

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, April 1992.

[RFC1730] Crispin, M., "Internet Message Access Protocol - Version4", RFC 1730, University of Washington, December 1994.

[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, Carnegie Mellon, December 1994.

 

13. Security Considerations

   It is conjectured that use of the APOP command provides origin
   identification and replay protection for a POP3 session.
   Accordingly, a POP3 server which implements both the PASS and APOP
   commands should not allow both methods of access for a given user;
   that is, for a given mailbox name, either the USER/PASS command
   sequence or the APOP command is allowed, but not both.

   Further, note that as the length of the shared secret increases, so
   does the difficulty of deriving it.

   Servers that answer -ERR to the USER command are giving potential
   attackers clues about which names are valid.

   Use of the PASS command sends passwords in the clear over the
   network.

   Use of the RETR and TOP commands sends mail in the clear over the
   network.

   Otherwise, security issues are not discussed in this memo.

14. Acknowledgements

   The POP family has a long and checkered history.  Although primarily
   a minor revision to RFC 1460, POP3 is based on the ideas presented in
   RFCs 918, 937, and 1081.

   In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
   provided significant comments on the APOP command.

 

15. Authors' Addresses

   John G. Myers
   Carnegie-Mellon University
   5000 Forbes Ave
   Pittsburgh, PA 15213

   EMail: jgm+@cmu.edu


   Marshall T. Rose
   Dover Beach Consulting, Inc.
   420 Whisman Court
   Mountain View, CA  94043-2186

   EMail: mrose@dbc.mtview.ca.us

 

 
 
 
 
 
 
Appendix A. Differences from RFC 1725

   This memo is a revision to RFC 1725, a Draft Standard.  It makes the
   following changes from that document:

      - clarifies that command keywords are case insensitive.

      - specifies that servers must send "+OK" and "-ERR" in
        upper case.

      - specifies that the initial greeting is a positive response,
        instead of any string which should be a positive response.

      - clarifies behavior for unimplemented commands.

      - makes the USER and PASS commands optional.

      - clarified the set of possible responses to the USER command.

      - reverses the order of the examples in the USER and PASS
        commands, to reduce confusion.

      - clarifies that the PASS command may only be given immediately
        after a successful USER command.

      - clarified the persistence requirements of UIDs and added some
        implementation notes.

      - specifies a UID length limitation of one to 70 octets.

      - specifies a status indicator length limitation
        of 512 octets, including the CRLF.

      - clarifies that LIST with no arguments on an empty mailbox
        returns success.

      - adds a reference from the LIST command to the Message Format
        section

      - clarifies the behavior of QUIT upon failure

      - clarifies the security section to not imply the use of the
        USER command with the APOP command.

      - adds references to RFCs 1730 and 1734

      - clarifies the method by which a UA may enter mail into the
        transport system.

      - clarifies that the second argument to the TOP command is a
        number of lines.

      - changes the suggestion in the Security Considerations section
        for a server to not accept both PASS and APOP for a given user
        from a "must" to a "should".

      - adds a section on scaling and operational considerations

Appendix B. Command Index

       APOP .......................................................   15
       DELE .......................................................    8
       LIST .......................................................    6
       NOOP .......................................................    9
       PASS .......................................................   14
       QUIT .......................................................    5
       QUIT .......................................................   10
       RETR .......................................................    8
       RSET .......................................................    9
       STAT .......................................................    6
       TOP ........................................................   11
       UIDL .......................................................   12
       USER .......................................................   13


저작자표시 비영리 변경금지

'읽기' 카테고리의 다른 글

[번역] Understanding node.js  (0) 2017.02.11

원본 글: Understanding node.js

*잘못된 번역이 있을 수 있습니다. 원본 글을 참고해주세요. node.js 를 위한 좋은 입문 글이라고 생각해서 번역해보았습니다.


node.js 이해하기


node.js를 소개하면, 사람들은 보통 두 가지 반응을 보인다. 기본적으로 사람들은 "이해했음" 하고 바로 말하거나, 아니면 엄청 혼란 스러운 상황에 처하고 만다.


 만약 당신이 후자의 경우라면 나는 이렇게 노드를 설명해 보겠다. 


* 이것은  command line tool  이다. 당신이 tarball(tar file)을 다운 받고 컴파일해서 설치하면 된다. 

* 노드는 당신이 'node my_appjs'라고 터미널에서 치면  자바스크립트 프로그램을 실행하도록 한다

* JS는  V8 자바스크립트 엔진(구글 크롬을 엄청 빠르게 해주는)에 의해서 실행된다. 

* 노드는 네트워크와 파일 시스템에 접근하는 자바스크립트 API를 제공한다. 


"그렇지만 나는 내가 필요한걸 루비랑, 파이선이랑, php랑 자바로 다 할 수 있어..!"


무슨 말인지 알겠다ㅇㅇ. 그리고 당신의 말이 옳다. 미안하지만 노드는 당신의 일을 대신 다 해줄 미친 유니콘이 아니다. 이것은 그냥 툴이다. 그리고 최소한 지금 버전으로는 아마도 당신이 사용하던 기존의 툴을 완벽하게 대체하지 못할 것이다. 


"그래서 본론이 뭐야!"


본론으로 들어가겠다. 노드는 기본적으로 당신이 동시에 여러가지 일을 해야할 때 무척 좋다. 코드를 짜고나서 "이게 동시에 동작하면 좋겠다" 하고  말한 적이 있는가? 노드에서는 당신의 코드만 제외하면 동시에모든 것이 동작한다. 


"Huh?"


그렇다. 모든 것은 당신의 코드만 제외하고 동시에 동작한다. 이것을 이해하기 위해서 당신의 코드가 왕이라고 생각하고 노드가 그의 시종들로 이루어진 집단이라고 생각해보라. 


 하루가 시작하면 한 시종이 와서 왕을 깨우고 왕에게 필요한 것이 있느냐고 묻는다. 왕은 자신이 해야할 업무들을 적은 리스트를 주고 조금 더 자러 꿈나라로 떠난다. 시종은 그 업무들을 그의 동료들에게 나누어준후, 각자 일을 하러 간다. 


 일단 한 명의 시종이 업무를 마치면 그는 왕의 숙소 밖에서 보고를 위해 대기한다. 왕은 한 번에 한 명의 시종만 들어오게 해서 시종의 보고를 듣는다. 어떤 경우에는 시종이 나갈 때 왕이 더 많은 업무를 주기도 한다. 


 삶은 좋은 것이라, ? 왕의 시종들은 그의 업무를 동시에 수행하지만, 왕이 집중할 수 있도록 한 번에 하나의 결과만을 보고한다.


"엄청 좋아보이기는 하는데... 이제 시덥잖은 비유는 그만하고 공돌이 답게 설명해줄래?"


물론이다. 여기에 아주 간단한 노드 프로그램이 있다.


코드


당신의 코드는 파일을 읽고 쓰는 두 작업을 노드에게 시킨 후, 자러간다. 일단 노드가작업 하나를 마치면, 그것을 위해 있었던 콜백 함수가 시작된다. 그러나 오직 하나의 콜백 함수만이 동시에 시작할 수 있다. 콜백이 실행을 마칠 때까지, 모든 다른 콜백 함수들은 줄을 서서 기다리고 있다. 거기다가 대기 중인 콜백함수들은 언제 실행될지에 대한 보장이 없다. 


"그래서 나는 코드가 같은 자료구조에 동시에 접근하는 것을 걱정할 필요가 없는건가요?"


그렇습니다! 그것이 바로 자바스크립트 싱글스레드와 이벤트루프 디자인의 아름다움의 전부인 것입니다!

"엄청 좋네요. 그런데 내가 이걸 왜 써야 하죠?"


첫번째 이유는 효율적이기 때문입니다. 웹 어플리케이션에서 당신의 주된 response time 비용은 보통 당신의 데이터베이스 쿼리를 실행하는데 걸리는 시간의 합입니다. 노드를 이용하면 당신은 모든 쿼리들을 한번에 실행할 수 있고, 가장 느린 쿼리를 실행하기 위해 걸리는 response time의  지연 시간을 줄일 수 있습니다. 


또다른 이유는 자바스크립트 입니다. 당신은 브라우저와 당신의 백엔드 사이에서 코드를 공유하기 위해 노드를 사용할 수 있습니다. 또한 자바스크립트는 무척 보편적인 언어가 되어 가고 있습니다. 당신이 과거에파이선, 루비, 자바, php....같은 것들을 했다고 하더라도, 아마 당신은 약간의 JS를 꾸준히 사용해왔을 것입니다. 그렇지 않나요?


그리고 마지막 이유는 빠른 속도 때문입니다. V8은 지구상에서 가장 빠른 동적 언어 interpreter 중 하나로서 꾸준히 선두를 이끌고 있습니다. 나는 다른 언어가 지금의 자바스크립트만큼 공격적으로 이 성장 속도를 이끌어갈 수 있을 것이라고 생각하지 않습니다. 또한, 노드의 I/O 구조들은 정말 가벼워서 당신을 당신의 시스템의 모든 I/O 허용치를 가능한 한 충분히 사용할 수 있도록 도울 것입니다. 


"그러니까 당신 말은 앞으로 내가 모든 앱을 만들 때 노드를 써야 한다는 건가요?"


그에 대한 대답은 예, 그리고 아니오 입니다. 일단 당신이 노드 망치를 휘두르기 시작하면 분명 모든 것이  못으로 보이기 시작할 것입니다. 그러나 당신이 데드라인을 가지고 일하고 있다면 당신은 당신의 결정을 어떠한 기준 위에 두고 싶어할 것입니다. (But if you're working on something with a deadline, you might want to base your decision on:)

- 짧은 response time/ 높은 동시 실행이 중요합니까? 그렇다면 노드는 그에 무척 적합할 것입니다.

 프로젝트가 얼마나 큰가요? 작은 프로젝트는 괜찮습니다. 그러나 큰 프로젝트는 반드시 주의해서 판단해야합니다. (사용 가능한 라이브러리, 버그를 잡기 위한 자원들이나 two upstream 등)


"노드는 윈도우에서도 돌아가나요?"


아니요. 만약 당신이 윈도우를 사용하고 있다면 당신은 리눅스를 사용하는 가상머신(VirtualBox를 추천합니다)을 돌려야 합니다. 윈도우에서 노드를 지원하는 것이 예정되어 있긴 하지만 당신이 unless you want to help with the port 앞으로 몇달 동안 숨을 참지 마세요.


"노드에서 DOM에 접근할 수 있나요?"

"Can I access the DOM in node?"

좋은 질문입니다! 아니오. 돔은 브라우저 거시기한 것이라서(browser thingy), 그리고 노드의 JS엔진(V8) 은 고맙게도 완벽하게 이 모든 엉망진창인 것으로부터 떨어져 있기 때문입니다. 그러나 유닛 테스트를 하는  클라이언트 쪽의 코드와 같은 무척 흥미로운 가능성이 열려 있는 등, DOM을 노드의 모듈로 사용할 수 있는 길이 있긴합니다. 

Excellent question! No, the DOM is a browser thingy, and node's JS engine (V8) is thankfully totally separate from all that mess. However, there are people working on implementing the DOM as a node module, which may open very exciting possibilities such as unit testing client-side code.


"이벤트 드리븐 프로그래밍은 진짜 어렵지 않나요?"


Either way, test driven development can really help you to come up with maintainable designs.

그것은 당신에게 달려있습니다. 만약 당신이 이미  AJAX call을 어떻게 다루는지, 그리고 브라우저에서 유저 이벤트를 어떻게 다루는지 알고 있다면 노드에 적응하는 것은 아무 문제가 되지 않습니다. 마찬가지로 , test driven development 는 당신을 지속 가능한 디자인을 할 수 있도록 도울 것입니다. 



"이런건 누가 쓰고 있나요?"


노드 위키에 보면 아직 완성되지 않은 적은 수의 리스트가 있습니다("Companies Using Node"로 스크롤 하세요). 야후 는 YUI를 위해서 노드를 가지고 실험 중이고 Plurk는 많은 양의 comet을 위해 사용 중이며, Paul Bakaus(jQuery UI 의 유명인사) 는 백엔드에서 노드를 일부 이용해서 엄청나게 재미있는 게임 엔진을 만들고 있습니다. Joyent 는 Ryan Dahl(노드의 창시자)를 고용해서 개발을 힘껏 돕고 있습니다. 


아, 그리고 Heroku 역시 (실험적으로나마) 주도적으로 node.js를 돕겠다고 공언했습니다.


"나는 이제 어디에서 더 배울 수 있죠?"


Tim Caswell은 How To Node라는 아주 좋은 블로그를 운영하고 있습니다. 트위터에서 #nodejs를 팔로잉 하세요 .그 메일링 리스트를 구독하세요. 그리고 IRC 채널의  #node.js(네. 저 점도 이름 안에 포함되어 있는 겁니다)에 와서 둘러보세요. 우리는 이제 200 lurker-mark 를 곧 찍을 예정입니다 :) .

그리고 나는 이 debuggable.com에도 꾸준히 글을 쓸 예정입니다. 

지금으로써는 이 정도가 다네요. 질문이 있다면 댓글을 달아주세요.


--fg


*: 위에 나온 비유는 엄청 단순화한 것입니다. 그렇지만 논블라킹의 개념을 현실세계에서 딱 떨어지게 맞는 것을 찾기가 어려웠네요. 



저작자표시 비영리 변경금지

'읽기' 카테고리의 다른 글

[번역] RFC1939  (0) 2017.02.11

+ Recent posts

티스토리툴바