내가 이해한 내용을 바탕으로 정리한 글이기 때문에 내용 상 오류가 있을 수 있음을 미리 밝힌다.
🏷️이 글의 목표
우선 아래의 그림을 먼저 보자.
(이미지 출처 : https://jhnyang.tistory.com/403?category=947031)
해당 시리즈의 이전 글에서 Host H1이 Host H2에게 데이터를 마치 택배 부치듯 보낸다고 언급한 바 있다. 이 택배가 출발지에서 보내져서 목적지에 도달하기까지의 과정을 쉬운 비유와 예시를 통해 이 글에서 다뤄보도록 하겠다.
🏷️라우터가 3계층 프로토콜인 이유
📌 호스트와 라우터의 계층 차이
위의 그림을 다시 보면, 호스트는 총 5계층으로 그려져 있다. 애플리케이션 계층, 전송 계층, 네트워크 계층, 데이터 링크 계층, 물리 계층이 바로 그것이다.
반면 라우터는 총 3계층으로 그려져 있다. 네트워크 계층, 데이터 링크 계층, 물리 계층이 바로 그것이다.
다시 말해, 호스트에는 라우터에 없는 애플리케이션 계층과 전송 계층이 추가로 있다. 그 이유가 무엇이냐고? 호스트는 이들이 필요하고, 라우터는 필요 없기 때문이다. 이것이 무슨 이야기인지 자세히 살펴보자.
📌 호스트에 애플리케이션 계층과 전송 계층이 없는 이유
우선 호스트에 애플리케이션 계층과 전송 계층이 필요한 이유는 이전 글에서 설명했다.
그렇다면 라우터에 애플리케이션 계층과 전송 계층이 없는 이유는 무엇일까?
이에 앞서 라우터의 목적이 무엇인지부터 살펴보자. 라우터는 데이터를 가장 빠르고 안전한 경로로 수신자에게 보내는 것을 목표로 한다.
즉, 라우터에게 필요한 기능은
1) 택배의 출발지점과 도착지점을 분별하는 기능
2) 택배를 보내는 최적의 경로를 찾아내는 기능
3) 택배를 서둘러 다른 라우터에게 보내는 기능
이렇게 정리할 수 있다.
다시 본론으로 돌아와서, 애플리케이션 계층과 전송 계층이 라우터에 없는 이유를 살펴보자.
애플리케이션 계층에서는 실제 사용자가 사용하는 화면을 띄우는 등 인터페이스에 관련된 일이 이루어진다.
전송 계층에서는 택배가 누락 없이 모두 잘 왔는지 확인하는 일을 TCP가 담당한다.
이를 통해 알 수 있듯이, 라우터는 데이터의 빠른 전송이 목표이기 때문에 사용자 인터페이스나 데이터의 누락 관리에 관여하지 않는다.
🏷️데이터 전송 과정
데이터를 전송하는 과정을 구체적으로 살펴보자.
이전 글에서 예시를 들었던 대로, 데이터를 택배에 비유해 설명을 이어가도록 하겠다.
📌 목적지와 경유지 확인하기
송신자의 손을 떠난 택배는 수신자에게 도착하기 위해 멀고 먼 길을 떠나야 한다. 이를 위해 가장 먼저 해야할 것은 목적지의 주소를 확인하는 것이다.
예를 들어 목적지의 주소가 서울시 서대문구 빨강아파트 100동 100호라고 가정하자. 이때
'서울시 서대문구 빨강아파트' = 공인 IP
'100동 100호' = 사설 IP
'빨강아파트' = 라우터
택배의 목적지는 사설 IP가 아니라 공인 IP가 될 것임은 자명하다. 100동 100호를 찾아가라고 하면 황당하지 않은가.
여기서 한 가지 문제가 생긴다.
택배를 부치려는 당신의 위치가 부산광역시라고 해보자. 부산광역시에서 서울시까지 택배를 부치려면 한 번에 갈 수 없고 여러 곳을 경유해야 할 것이다. 문제는 서울시라는 목적지만 알 뿐, 구체적으로 어디를 거쳐서 가야 하는지를 모른다는 것이다.
이를 해결해주는 것이 바로 MAC 주소이다. MAC 주소는 목적지인 IP 주소까지 가기 위해 중간에 거쳐야 하는 경유지들이다. 이를 알아내는 방법은 ARP라는 일종의 확성기를 이용해 물어보는 것이다.
📌 라우터를 여러 개 거쳐서 목적지까지 택배 보내기
이제 목적지와 경유지를 모두 확인했다. 택배가 경유지인 라우터를 여러 개 거쳐서 목적지까지 도달하게 되는데, 이것이 어떻게 가능한지 살펴보자.
앞에서 '빨강아파트'가 바로 라우터라고 언급한 바 있다. 즉, 라우터는 쉽게 말해 건물이다.
라우터끼리 택배를 전달하는 원리를 예시로 살펴보자.
노랑아파트에서는 도착한 택배의 주인이 우리 아파트에 사는지 확인한다. 그리고 그 주인이 본인 아파트에 살지 않는다면, 옆의 파랑아파트에 택배를 넘겨준다.
이것이 라우터의 작동 원리이다.
📌 주인에게 택배를 건네주기
라우터를 여러 개 거친 택배가 드디어 택배의 주인이 사는 서울시 서대문구 빨강아파트에 도착을 했다. 주인은 100동 100호에 사는데, 빨강아파트에 사는 주민이 많아 라우터가 주인을 직접 찾기 어렵다. 그래서 빨강아파트에 고용되어 직접 100동 100호에 택배를 전달해주는 게 바로 스위치다.
스위치는 빨강아파트에 사는 여러 주민들의 소통창구로, 이들을 하나로 유닛화시켜준다. 네트워크적으로 말하자면, 여러 컴퓨터라는 주민들을 연결해 1개의 네트워크를 생성해주는 것이 스위치라고 할 수 있다.
🏷️데이터의 전송 형태와 확인
📌 데이터의 패킷화
여기서 한 가지 짚고 넘어가야 할 것이 있다. 나는 저번 글에서부터 데이터를 전송하는 것을 택배에 비유하며, 마치 택배 하나를 온전히 이동시킨다는 식으로 말했다.
하지만 실제로 네트워크에서 데이터는 하나가 아니라 여러 개로 나뉘어져서 따로따로 목적지에 도달하게 된다. 이를 패킷이라고 하는데, 마치 퍼즐 조각 나눈 것과 같다고 생각하면 된다.
이렇게 택배를 한꺼번에 보내지 않고 일부러 조각조각내서 따로 보내는 이유가 무엇일까? 그 이유는 훨씬 빠르고 안전하기 때문이다.
만약 주문된 떡 여러 개를 한꺼번에 이동시키다가 호랑이를 만나 몽땅 뺏긴다면, 다시 처음부터 모든 떡을 보내야 한다. 하지만 떡 하나 하나를 다른 경로를 통해 보내게 된다면, 떡 하나 정도 호랑이에게 뺏겨도 다른 떡들은 안전하게 도착하고 그 떡만 다시 보내면 된다.
📌 패킷의 전송 상황을 관리하는 TCP
송신자와 수신자의 TCP는 계속 통신하며 패킷들이 몇 개가 왔는지, 패킷을 더 보내도 되는지 확인한다.
패킷들은 데이터의 조각이기 때문에 마치 퍼즐 조각에 순서대로 숫자를 쓰듯이 순서가 부여된다. 송신자는 이러한 퍼즐 조각들을 따로 전송한다.
그러면 수신자는 따로따로 도착하는 퍼즐 조각들을 순서대로 정렬한다. 그리고 송신자에게 "나 1~5번 퍼즐 조각 잘 받았으니 아직 안 보낸 퍼즐들 있으면 더 보내!"라는 확인의 메세지 'ACK'를 보낸다.
🏷️글을 마무리하며
이번 글에서는 데이터가 송신자에서 수신자로 이동하는 과정을 설명했다. 다음 글에서는 수신자가 데이터를 받아 처리를 하는 과정을 살펴본다.
