Protocol
프로토콜이란 비-IT 분야에서도 범용적으로 사용되는 단어다. 프로토콜은 합의된 약속을 뜻한다. 관련된 단어로는 협약, 협의, 규약 등등이 있겠다. 원래는 외교 분야에서 사용되는 용어이다. 가령 1992년 지구 온난화 방지를 위해 여러 국가가 체결한 교토 의정서 Kyoto Protocol에 바로 프로토콜이라는 단어가 사용된다. 하지만 교토 의정서의 전신이 되는 기후 변화에 관한 유엔 기본 협약 United Nations Framework Convention on Climate Change에는 Convention이라는 단어가 사용된다. 그와 비슷한 골자인 파리 협정 Paris Agreement 에는 Agreement라는 단어가 사용된다. 각각 단어의 엄밀한 의미를 추리고 비교할 건 아니다. 이런 이야기를 꺼낸 건 프로토콜이란 개념이 지는 외연에 대해 주의를 기울일 필요가 있어서다. 앞선 예를 기준으로 보면, 정식적인 협의 Convention의 한계나 미비점을 보충하기 위해 추가적으로 약속된 사안을 프로토콜 Protocol이라 부른다고 한다. 요약하자면 프로토콜은 어떤 사안에 대한 전체적이고 보편적인 합의에 대해 보충적이고 가변적으로 추가된 약속이다.
디지털, IT 세상은 거대한 하나의 약속을 근간으로 삼아 세워졌다. 그게 바로 그 이름도 유명한 네트워크 Network다. 네트워크 안에는 이미 그 자체의 통신 규약 체계가 배태되어있다. 디지털 개체들이 서로를 어떻게 식별하고, 서로 어떻게 연결되고, 서로 어떻게 통신하는 지는 네트워크가 다 말해준다. 이를 네트워크 통신 Network Communication 이라고 부른다. 프로토콜은 네트워크 통신이라고만 이름 붙이고 끝내기 어려운 다소 특정적이고 구체적인 통신 방식을 포괄하는 개념이다. 즉, 앞서의 정의를 따라 말하자면 프로토콜은 네트워크 통신을 보충하기 위해 추가된 약속이다. 네트워크라는 거대한 체계는 사실상 확정적이다. 단지 네트워크의 확정된 체계 논리를 구체화하는 방식들이 새롭게 추가되고 변할 수 있는 것이다.
이어지는 의문은 이러하다. 그렇다면 프로토콜이라고 이름 지어진 추가된 약속은 대체 무엇인가? 위키피디아의 말을 빌리자면 프로토콜이란 바로.
물리량의 변형을 매개하여 통신 체계 내 개체들의 정보가 주고 받아지게끔 하는 규칙 체계
A system of rules that allows two or more entities of a communications system to transmit information via any kind of variation of a physical quantity.
라고 하는데, 솔직히 감이 잘 오지 않는다. 물리량의 변형을 매개해서 정보가 주고 받아진다는 건, 이렇게 생각해볼 수 있을까.
kg(물리량) 증가 -> 살이 쪘다.(정보)
kg(물리량) 감소 -> 살이 빠졌다.(정보)
더 깊게 생각하는 건 정신 건강에 커다란 위험이 될 듯하여 이 정도로만 보기로 하자. 사실 중요한 건, 프로토콜을 네트워크 통신 자체와 동일시짓는 비약을 방지하는 일이었다. 프로토콜은 네트워크 통신의 보충적인 규약이고, 프로토콜의 목적은 통신 체계의 개체들의 정보가 서로서로 주고 받아질 수 있게끔 하는 것이라는 정도만 이해하자. 뒤의 글에서는 프로토콜을 통신 규약이라고 간단하게 부르겠다.
통신 규약이란 말하자면, 무엇을 어떻게 주고 받을 것인지를 정의하는 규약이다. 앞에서 짧게 언급한 위키피디아의 정의는 프로토콜 내에서 정보들이 '어떻게' 전달되는 지에 방점을 찍고 있다. 말했듯이 이 원리와 과정을 자세하게 알아볼 순 없겠다. 그걸 알고 설명할 수 있었으면 블로그가 아니라 논문을 쓸 것이다. 할 수 있는 말은 이 정도이다. 프로토콜의 실질적 작동 원리를 파악하고 설명하는 건 아주 높은 수준의 전공 지식을 필요로 한다. 한 마디로 완전 어렵다.
그러므로 아래의 글과 관련 포스트에선 프로토콜이라는 통신 규약 하에서 '무엇이' 주고 받아지는 지, 즉 정보의 양식이 어떠한지에 중점을 두고 설명을 이어가고자 한다. 정보의 양식을 파악하고, 덤으로 정보 전달 순서와 절차를 짚어보는 것만으로도 프로토콜을 충분히 공부했다고 할 수 있을 것이다.
묻자. 프로토콜은 무엇을 전달하고, 전달 받는가?
Packet
프로토콜에 의해 서로 다른 디지털 객체들은 서로의 정보를 주고 받을 수 있게 된다. 이렇게 주고받는 정보, 통신에 의해 전달되는 데이터를 패킷 Packet이라고 부른다. 이 또한 비-IT 분야에서도 사용되는 단어다. 소포라는 뜻인데, 이보다는 좀 더 범용적으로 쓰여 과자를 담은 과자 봉지의 이름에도 패킷 packet이 포함된된다. 일반화하여 말해 패킷은 다른 사물들을 하나로 묶어내기 위한 포장지, 꾸러미를 지칭한다. 패킷의 이러한 의미는 상당히 의미 심장하고, 프로토콜 통신 체계의 독특한 특징을 설명해준다.
프로토콜 하의 모든 데이터는 '포장'되어 주고 받아진다. 그리하여 프로토콜 하에서 주고 받아지는 어떤 실체를 패킷이라고 통칭할 수 있는 것이다.

프로토콜에 대해 찾다보면 프로토콜에도 여러 가지 종류가 있다는 걸 알게된다. 프로토콜의 종류를 나누는 기준은 곧, 바로 이 패킷을 구성하는 방식에 있다. 전송되는 패킷에 어떤 데이터를 넣는지에 따라 종류가 나뉘는 것이다. 이 뜻을 이해하기 위해선 프로토콜의 계층 layer에 대해 알아보아야 한다. 프로토콜의 계층은 곧바로 프로토콜의 전송 절차와 이어진다.
Protocol Layer
프로토콜의 계층을 딱 하나의 디자인으로 확정할 수는 없는 듯하다. 말했듯이, 프로토콜이란 보충적인 규약이므로 여러 형태로 구체화될 수 있겠다. 통상적으로는 아래의 4계층을 프로토콜의 기본 디자인으로 생각한다.

보니 OSI model의 일부라고 한다. 또 이러한 구분은 추상화된 정의 Abstract라고 한다. 물리적인 구분이 아니라 개념적인 구분이라는 것이겠다. OSI model의 개념이나 각 layer의 의미 등에 대해서는 기회가 될 때 더 공부를 해두어야겠다. 지금은 이것만 알아두자. 프로토콜 하에서 전송은 위의 네 계의 층을 거치며 이루어진다. 위의 계층에서 시작해 아래 계층을 거치는 순서다. 반드시 모든 계층을 거쳐야하는 건 아니다. 다만, 시작된 부분 기준으로 그 아래의 계층들은 모두 거쳐야 한다. 가령 Application layer에서 호출이 생겨났다면 호출은 아래의 세 개 계층을 모두 통과한다. 이 절차적 특성을 꼭 기억할 필요가 있다.
Protocol Type
각 계층에는 각각으로 대응되는 프로토콜들이 있다. 아래처럼 말이다.

앞서 말했듯이 프로토콜의 종류는 패킷에 어떤 데이터를 넣는지에 따라 나뉜다고 했다. 가령 HTTP와 SMTP가 서로 구별되는 호출인건, 내부에 서로 다른 양식의 데이터를 담고 있기 때문이라고 볼 수 있겠다. 이 차이를 꼼꼼히 들여다볼 순 없겠다. 내맘대로 비유해보자면, HTTP에 담기는 html과 SMTP에 담기는 메일 메세지는 확장자가 다르기 때문에! 둘은 서로 다른 프로토콜이다라고 할 수 있다. 물론 더 명확하고 상세한 차이가 있을 것이다.
가만 보면 프로토콜의 종류는 계층별로도 나뉘고 있다. 그렇다면, 프로토콜의 종류를 나누는 기준에 계층의 차이도 포함되어 있는 걸까? 그렇게 보아도 사실 틀린 것은 아닐 터이다. 기본적으로 계층이 다르면 패킷에 집어넣는 데이터도 다르기 때문일 것이다. 하지만 이 부분에 대해 조금 더 엄밀하게 짚어볼 내용이 있다.
HTTP와 SMTP의 차이는 HTTP와 TCP의 차이와는 다른 결을 지닌다. 이는 앞서 언급했던, 프로토콜 호출의 성질과 관련이 있다. 호출이 시작된 부분을 기준으로 해당 호출은 그 아래의 모든 계층을 지나야한다. 즉, HTTP 기반의 호출은 그 아래 계층들인 Transport Layer, Internet Layer, Data Link Layer를 거쳐야 한다.
관련된 기반 지식 없이 이 내용만 보자면 이런 착각을 할 수 있다. HTTP는 Application layer에서 시작된 호출의 한 종류이고, TCP는 Transport Layer에서 시작된 호출의 한 종류이다. 서로는 각각 독립된 호출 절차를 지니고 있다.
그렇지 않다. 상위의 계층에서 시작된 호출이 그 다음 계층을 '거친다'는 의미는 바로 그 다음 계층에 속해 있던 어느 프로토콜과 결합된다는 의미이다. 다시 말해, HTTP 호출은 그 아래 계층인 Transport Layer에 속한 프로토콜인 TCP, UDP 중 하나와 결합되어야 하며, 그렇게 결합된 호출은 또 그 아래의 Internet Layer에서 IPv4 혹은 IPv6와 결합되어야 한다. DCHP도, SMTP도 마찬가지다. 그러므로 실질적인 호출의 양상은 다음과 같은 도식을 지닌다.

프로토콜의 결합은 오직 다음 계층을 거치며 이루어진다. 그러므로 HTTP와 SMTP의 결합은 논리적으로 불가능하다. 이 점에서 HTTP와 SMTP의 차이가 HTTP와 TCP의 차이와 구별된다.
그렇다면 프로토콜의 결합이란 무엇일까? 간단하게 말해 두 프로토콜의 데이터를 합친다는 말이다. HTTP와 TCP가 서로 다른 프로토콜인 이유는 그것들이 패킷에 서로 다른 데이터를 집어넣기 때문이다. 그렇기에 앞서서 프로토콜의 종류를 나누는 기준으로 데이터 종류의 차이를 든 것이다.
예로 들자면 다음과 같다.

각각의 프로토콜에 의해 패킷에 특정한 정보들이 추가된다. HTTP는 html 데이터, TCP는 전송지와 출발지 Port, IPv4는 전송지와 출발지 IP를 각각 담고 Data link layer에서 객체의 MAC 주소가 담겨져 패킷이 구성된다. 이렇게 구성된 패킷은 패킷에 명시된 도착지의 정보에 따라 다른 객체에게 전달된다. 이런 식의 데이터 전송 체계를 프로토콜이라고 통칭할 수도 있겠다.
무튼 요점은 프로토콜의 종류에 따라 패킷에 담기는 데이터의 종류가 정의된다는 점이다.
*
프로토콜의 전송 절차와 종류에 대한 위의 설명은 다소간 거친 rough 부분이 없지 않다. 왜냐면 하나의 프로토콜이 한 종류의 데이터만 집어넣는 것도 아니기 때문이다. 또한 실질적으로 패킷 자체는 Internet Layer에서 생성된다고 한다. 그러므로 HTTP와 TCP는 다만 관련된 데이터를 생성하고 다음 계층에 넘기는 정도의 역할을 한다.
Packet 구성, 계층 별 의미, 프로토콜 데이터 종류 등에 대해서는 조금 더 공부가 필요하겠다. 포스팅을 하면서 줄곧 머리 속의 어느 빈 공간이 의식되었다. 관련 개념이 더 있었더라면 설명이 더욱 매끄럽고 탄탄했을 것임을 확신한다. 아쉬움은 접어두고, 관련 공부 내용들은 각각 별도의 포스팅을 이용해서 정리해보도록 하다.
'IT 이모저모' 카테고리의 다른 글
| JAVA Installation On Linux (0) | 2022.09.02 |
|---|---|
| About JAVA Platform (0) | 2022.09.02 |
| Spring boot 프로젝트 도커 이미징 (0) | 2022.09.02 |
| Docker Bridge 네트워크 이해 및 컨테이너 공용 네트워크 생성 (0) | 2022.09.02 |
| Mac os 내 경량 Linux 환경 구성하기 feat. linuxkit (0) | 2022.09.02 |