03. 개알못을 위한 TCP/IP의 개념
1부 웹의 시작과 현재
그것은 마치 땅 위의 길과 같은 것이다. 사실 땅 위에는 본래 길이 없었다.
걸어가는 사람이 많아지면서 곧 길이 된 것이다.
- 루쉰, 고향
하이퍼텍스트 이야기부터 시작하려다 생각이 좀 바뀌었습니다. 하이퍼텍스트에 대한 역사와 의미만 설명하려다 내친김에 HTTP까지 이야기해보면 좋을 것 같았기 때문입니다. 그러려면 연재의 순서를 좀 바꾸어야 흐름이 자연스럽게 이어질 것 같습니다. 그래서 오늘은 우선 TCP/IP부터 이야기해야 하겠습니다.
TCP/IP 가 뭐죠?
위키 백과는 이렇게 설명하고 있습니다.
"TCP/IP는 패킷 통신 방식의 인터넷 프로토콜인 IP (인터넷 프로토콜)와 전송 조절 프로토콜인 TCP (전송 제어 프로토콜)로 이루어져 있다. IP는 패킷 전달 여부를 보증하지 않고, 패킷을 보낸 순서와 받는 순서가 다를 수 있다.(unreliable datagram service) TCP는 IP 위에서 동작하는 프로토콜로, 데이터의 전달을 보증하고 보낸 순서대로 받게 해준다. HTTP, FTP, SMTP 등 TCP를 기반으로 한 많은 수의 애플리케이션 프로토콜들이 IP 위에서 동작하기 때문에, 묶어서 TCP/IP로 부르기도 한다."
쉽게 풀어쓴 내용이지만 독자에 따라서는 어렵다고 느낄 수 도 있을 것입니다. 하지만 너무 어렵다고 지례 겁을 먹거나 포기할 필요는 없습니다. 우리 주변 개발자들이 아무리 어려운 용어를 쓰더라도 외계어처럼 받아들이지 않아도 됩니다. 세상일이라는 게 양자역학의 세계 정도에 들어가지 않는 이상 대부분은 상식선에서 이해되는 법 이니까요.
김 사장님 댁으로 연결해 주세요
인터넷이 생기고 전 지구적으로 소통이 일어나기 훨씬 전부터 사람들 간의 연결의 시도는 계속되었습니다. 우편이 있었고, 모스부호를 이용한 전보가 있었습니다. 전화기가 발명되어 서로 간 통화가 가능해진 것은 비교적 최근의 역사입니다. 인터넷이 생기기 전까지 통신을 위해서는 양 쪽에서 연결이 필요했습니다.
그림 1. 캐나다 몬트리올의 전화교환소서로 간 연결이 이루어지면 연결이 끊어질 때까지 해당 회선을 온전히 독점하며 사용을 합니다. 기술적으로 이러한 연결 방식을 서킷 통신이라고 부릅니다. 이 통신 방식은 통신을 원하는 양 쪽이 1:1로 연결되어야 합니다. 처음부터 양쪽이 연결되어 있거나 중간에 교환소를 거쳐서 연결이 되겠죠.
그림 2. 서킷통신 예제일단 연결이 된 상태에서는 해당 회선을 완전히 점유하게 됩니다. 다른 쪽에서 연결을 하고 싶으면 연결이 이미 연결된 곳이 끊어지기 전까지 기다려야 합니다.
그림 3. 서킷통신 방식은 회선의 연결을 독점합니다.냉전시대 미국의 고민
냉전시대 미소 양국은 핵무기를 포함하여 치명적인 무기를 경쟁적으로 도입하였고, 전 세계는 서로의 위협에 늘 긴장된 상태였습니다. 공격을 위한 무기와 함께, 공격당했을 때 대비책도 중요한 법입니다. 만일 본토가 핵공격을 받았을 때 통신망이 붕괴되어 아무것도 할 수 없는 상태가 된다면 어떻게 할 것인가도 미국의 고민 중 하나였습니다. 당시 (서킷) 통신 방식은 이러한 회선 단절에 취약합니다. 회선이 끊어지면 다시 연결을 해야 하고, 누군가 선을 사용 중 이면 기다려야 합니다. 긴급한 상황에서 효율적인 통신 방법은 아닐 것입니다.
어떻게 연결해야 할까?
이 고민을 어떻게 해결할 수 있을까요? 망을 여러 개 만들면 일부 선이 끊어지더라도 다시 연결할 수는 있을 것입니다. 하지만 중간에 연결이 끊어지면 처음부터 다시 연결을 해야 하고, 가능한 망 (멀쩡히 살아있고 누군가 사용하지 않는 회선)을 찾아 다시 연결하는 것이 효율적인 방식은 아닙니다.
그림 4. 여러개의 노드로 망을 다중화 시켜도 문제는 여전히 있습니다.다중망 자체만으로는 무엇인가 부족합니다. 회선이 사용 중일 때 마냥 기다리지 않아도 되는 방법은 없을까요? 선이 끊어지더라도 처음부터 연결하여 다시 통신을 하는 것보다 더 좋은 방법은 없을까요? 이 문제를 해결하기 위하여 내용을 작게 잘라서 보내는 방법을 생각해 냈습니다. 잘게 잘라진 조각들은 각각 목적지를 향하여 가장 효율적인 방법으로 이동합니다. 목적지를 향하여 가능한 크고 빠른 길로 달리되, 그 길이 복잡하다면 좀 더 돌아가더라도 우회도로를 찾아가는 것과 비슷한 원리입니다.
그림 5. 패킷통신 예제내용을 잘게 나눠 보내면 뒤섞이거나 빠진 내용이 생길 수도 있습니다. 앞의 내용보다 뒤의 내용이 먼저 전달되어 순서가 뒤죽박죽이 되어버릴지도 모릅니다. 하지만 이건 간단히 해결할 수 있습니다. 목적지에서 점검을 해서 순서대로 정렬을 하고, 빠지거나 잘못된 게 있으면 그것만 다시 받아 합치면 되니까요.
그림 6. 패킷 통신 완료 후 데이터 점검이제 동시에 여러 곳에서 통신을 하더라도 문제가 없어졌습니다. 중간에 내용이 끊어지거나 사라지더라도 그 부분만 다시 요청해서 받으면 됩니다. 하나의 회선에서도 여러 명이 동시에 통신을 할 수도 있습니다.
이러한 연결 방식을 패킷통신이라고 합니다.
TCP/IP
오늘날 인터넷 통신의 대부분은 패킷통신을 기본으로 하고 있습니다. TCP/IP는 이러한 패킷 통신을 위한 인터넷의 규약입니다. IP는 데이터의 조각들을 최대한 빨리 목적지로 보내는 역할을 합니다. 조각들의 순서가 뒤바뀌거나 일부가 누락되더라도 크게 상관하지 않고 보내는 데 집중을 합니다. TCP는 IP보다 느리지만 꼼꼼한 방식을 사용합니다. 도착한 조각을 점검하여 줄을 세우고 망가졌거나 빠진 조각을 다시 요청합니다. 두 방식의 조합을 통하여 인터넷 데이터 통신을 하는 것을 묶어 TCP/IP라고 부르는 것입니다.
다시 앞에 발췌한 위키백과로 돌아가 볼까요?
TCP/IP는 패킷 통신 방식의 인터넷 프로토콜인 IP (인터넷 프로토콜)와 전송 조절 프로토콜인 TCP (전송 제어 프로토콜)로 이루어져 있다.
프로토콜은 이후 연재에서 간간히 설명할 기회가 있겠지만 일단 사전 그대로 규약 정도로 이해를 하시면 됩니다. 인터넷 통신을 하기 위한 표준이자 약속인 거죠. '패킷 통신 방식의 인터넷 프로토콜인 IP'라는 대목에서 패킷 통신이 무엇인지는 위 설명을 통하여 어렴풋이 이해할 수 있을 거라 생각합니다.
IP는 패킷 전달 여부를 보증하지 않고, 패킷을 보낸 순서와 받는 순서가 다를 수 있다.(unreliable datagram service) TCP는 IP 위에서 동작하는 프로토콜로, 데이터의 전달을 보증하고 보낸 순서대로 받게 해준다.
TCP/IP는 두 개의 프로토콜입니다. 그중 IP는 복잡한 네트워크 망을 통하여 가장 효율적은 방법으로 데이터의 작은 조각들을 되도록 빨리 보내는 일을 합니다. TCP는 데이터를 잘게 잘라 보내면서 순서가 맞지 않거나 중간에 빠진 부분을 점검하여 다시 요청하는 일을 담당합니다.
HTTP, FTP, SMTP 등 TCP를 기반으로 한 많은 수의 애플리케이션 프로토콜들이 IP 위에서 동작하기 때문에, 묶어서 TCP/IP로 부르기도 한다.
HTTP는 주소창에서 많이 보셨을 것입니다. FTP도 들어보신 분들이 있을 거라 생각합니다. TCP/IP 기반에서 웹이나 여러 데이터들을 주고받기 위한 프로토콜들입니다. HTTP에 대하여는 다음 연재에서 좀 더 다루도록 하겠습니다. 앞에 위키백과의 설명이 이제 좀 더 이해가 되셨는지 모르겠습니다.
지금까지 간략하게 TCP/IP에 대한 이야기를 해보았습니다. 인터넷 서비스 기획을 하기 위하여 반드시 알아야 하는 이야기는 아니지만 현업에서 가끔 듣게 되는 용어이기도 하고, 오늘날 대부분의 네트워크 통신에 근간을 이루는 기반 기술이기 때문에 간략히 개념 정도는 알아두면 좋을 것 같아 글을 써 보았습니다.
이후 연재에서는 TCP/IP 기반에서 웹을 포함한 인터넷상의 콘텐츠 대부분을 전달하는 HTTP에 대한 개념을 간략히 정리해 볼 생각이고, HTML과 CSS, 자바스크립트 각각의 의미에 대한 글도 연재할 계획을 가지고 있습니다. 서비스 기획을 하시는 분들에게 작은 배움의 기회가 되었으면 하는 바람으로 이번 연재를 마칩니다.
이번을 포함하여 앞으로도 가끔 개발 및 기술에 대한 내용을 연재할 생각이다. 다만 주의할 점이 하나 있다. 저자는 개발자 출신이 아니며 정식으로 개발 교육을 받은 적이 없다. 이번 연재를 포함하여 얖으로의 기술적 내용들은 저자의 개인적 관심으로 학습하고 나름의 이해를 기반으로 정리한 내용이다. 개발자나 관련 전문가의 자문을 받을 기회가 없으며, 이는 본 내용이 잘못되거나 완전한 정답이 아닐 가능성이 늘 존재한다는 것이다. 또한 기술은 늘 변한다. 본 연재의 내용은 비교적 오래전에 학습하고 이해했던 내용으로 오늘날의 기술과 차이가 있을 수 있다. 전문가가 보기에는 틀림없이 부족하고 잘못된 내용들이 많을 것이다. 이러한 부분을 지적해 준다면 저자는 물론이고 독자들에게도 많은 도움이 될 것으로 믿는다. 모쪼록 많은 의견과 지적을 부탁드린다.
TCP/IP에 대한 최초의 개념은 십여 년 전 우연히 읽었던 책에서 접했다. 기억을 더듬어 서가를 찾아봤는데 운 좋게도 그 책이 아직 남아있어 소개한다. "조엘 온 소프트웨어 - 유쾌한 오프라인 블로그"라는 책으로 비개발자가 읽기에는 좀 어려운 부분이 있으나 또 읽고 어렵지 않게 이해할 많한 장도 있어 관심이 간다면 한번 읽어볼 것을 권한다. 오늘 한참이나 그 책을 다시 뒤적이며 해당 내용을 다시 찾아보았다. 구판 기준 '26장 허술한 추상화의 법칙'에 TCP/IP에 대한 내용이 쉽고 재미있게 정리되어 있다.
본 연재에 사용된 출처를 밝힌다.
표지그림 : 미국 국방부 고등 연구 계획국이 최초로 패킷통신 방식을 만들었다. 이를 ARPANET이라 하며 표지 그림은 패킷통신을 통한 첫 번째 메시지 로그이다. (출처)
그림 1 : 몬트리올의 전화 교환소 ( 출처 )
그림 2,3,4,5,6 : 저자가 직접 제작
