HTTP vs SMTP,POP3,NNTP,FTP

HTTP: Hyper Text Transfer Protocol
SMTP: Simple Mail Transfer Protocol
POP3: Post Office Protocol ver 3
NNTP: Network News Transfer Protocol
FTP: File Transfer Protocol

HTTP는 다른 프로토콜보다 상당히 젊다. 만들어진 시기를 RFC 등록일로 조사해보니 다음과 같다.

FTP: RFC 765 - 1980
SMTP: RFC 821 - 1982
POP: RFC 918 - 1984
NNTP: RFC 977 - 1986
HTTP: RFC 1945 - 1996

HTTP의 경우 RFC 1945에서도 기술된 바와 같이 1990년부터 만들어져 사용되어 왔다고 기록되어 있다. 다른 프로토콜도 그정도는 아닐지라도 사용은 먼저되어오다가 RFC 트랙을 밟았으리라 생각되는데, 굳이 연도를 들먹이는 이유는 다름아닌 근대화된 프로토콜의 차이점이 무엇일까를 생각해보고자 한다.

이들은 모두 telnet 명령으로 쉽게 흉내를 낼 수 있는 간단한 줄단위 프로토콜이다. 이 말은 telnet을 네트워크 프로그램의 디버거라고 불러도 좋을 정도로 직관적인 프로토콜들인데, 이들은 다음에서 가장 큰 차이가 난다.

HTTP는 client가 먼저 전송하고 server가 응답을 준다.
FTP,SMTP,POP3,NNTP는 서버가 먼저 자신의 존재를 전송한다.

이 간단한 차이는 다음과 같은 이점이 있다.

1. 포트 스캐너에 의해 정체가 쉽게 드러나지 않는다.

이 얼마나 10년이 지나도록 유지되어왔던 관행을 깬 것인가. 맏형 FTP부터 NNTP들은 접속하자 마자 어서옵쇼하면서 정체를 드러낸다. 정말 보안이 필요없는 정직한 세상에서 태어난 존재들이기 때문에 그렇게 설계되지 않았을까?

2. 서버의 프로토콜 버전을 올리기가 쉽다.

SMTP, POP3, NNTP 등은 서버부터 버전을 말해야하므로, Client와 협상해야하는 과정이 필요하다. SMTP의 경우 EHLO, POP3의 경우 APOP 과 같은 여러가지 확장기능이 있다. 그런데, HTTP의 경우 client 가 어떤 버전인지를 먼저 말해오므로, 그것에 따라 맞춰 반응해주면 되기 때문에, 불필요한 협상과정을 최소화 하여 속도록 높힐 수 있게 된다.

3. 네트웍의 트래픽을 최소화 할 수 있다.

서버란 모름지기 요청에 대한 응답을 주는 것이다. 그말은 가장 최소한의 데이터 교환은 접속후 한 번의 요청과 한 번의 응답으로 구성되는 2 개의 패킷이 필요한 것인데, 서버부터 뭔가가 내려가야한다면 그 과정은 적어도 3 개의 패킷이 필요하게된다. 안된다. 바쁜 세상 줄일 수 있을 때까지 줄여야지.

4. 클라이언트가 눈치 채지 못하게 프락시를 구성하기 쉽다.

자명하지 않은가. 클라이언트가 어딘가로 가는 것을 가로채서 자신이 요청사항을 받고서 적절한 처리를 하고 종료하는 것이 가능해진다. HTTP의 경우 캐시도 가능해진다. 그러나 다른 서비스들도 가로챌 수는 있으나 반드시 그 서버에 접속해서 server hello를 받아서 전달하기 전까지는 눈치 채지 못하게 구성하기란 쉽지 않다.
논리가 쫌 약한가? 하지만 이 기능은 로드밸런서를 생각할 때 자주 고민되는 문제가 될 수 있다. 서버는 하나로 보이게 하나 요청에 의해 분배되는 구조! 클라이언트가 먼저 보내는 것만이 일을 쉽게 할 수 있다.

막내가 제일 똘똘한만큼 거기에는 위와 같은 얘깃거리가 담겨있다.