메시지는 주소를 겹겹이 붙여 보냅니다.

01

가장 안쪽 데이터는 진짜 규격으로 인코딩합니다.

화면 맨 안쪽에 보이는 바이트는 설명용으로 적어 둔 글자가 아니라, Redis 가 실제로 쓰는 형식에 맞춰 코드가 만들어 낸 것입니다. 명령 토큰 개수를 앞에 적고 각 토큰마다 길이와 내용을 붙이는 규칙을 그대로 구현했고, 길이를 셀 때는 글자 수가 아니라 UTF-8 바이트 수를 셉니다. 그래서 명령을 바꾸면 안쪽 바이트도 규격에 맞게 함께 바뀝니다.

02

일곱 계층 중 넷만 헤더를 붙입니다.

계층 목록에는 일곱 개가 다 나오지만, 실제로 포장이 생기는 것은 네 곳입니다. 표현 계층과 세션 계층은 이 예제에서 별도 헤더로 나타나지 않으며 화면에서도 그렇게 표시해 두었습니다. 교과서의 일곱 칸과 실제 인터넷 프로토콜이 일대일로 대응하지 않는다는 점을 감추지 않고 드러내는 편이, 나중에 실제 패킷을 봤을 때 덜 혼란스럽습니다.

03

각 계층이 붙이는 주소가 서로 다릅니다.

전송 계층은 어느 프로그램인지를 포트 번호로, 네트워크 계층은 어느 컴퓨터인지를 IP 주소로, 데이터링크 계층은 바로 다음 장비가 누구인지를 하드웨어 주소로 적습니다. 세 주소가 가리키는 대상의 범위가 다르다는 것이 계층을 나누는 이유이고, 화면에서 세 헤더를 동시에 펼쳐 볼 수 있게 한 것도 그 차이를 나란히 확인하라는 뜻입니다.

04

TTL 은 무한 순환을 막는 장치입니다.

네트워크 계층 헤더에 들어 있는 64 는 이 패킷이 지날 수 있는 장비 수의 상한입니다. 라우터를 지날 때마다 하나씩 줄고 0 이 되면 버려지므로, 경로 설정이 잘못돼 패킷이 원을 그리며 돌더라도 영원히 남지 않습니다. 이 값이 어떻게 줄어드는지는 이 화면이 아니라 경로를 다루는 데모에서 단계마다 확인할 수 있습니다.

05

포장을 벗기는 순서는 붙인 순서의 반대입니다.

받는 쪽은 가장 바깥 포장부터 확인합니다. 하드웨어 주소가 내 것인지 보고 떼고, IP 주소가 내 것인지 보고 떼고, 포트 번호를 보고 어느 프로그램에 넘길지 정합니다. 각 단계에서 확인하는 것이 그 계층이 붙인 주소 하나뿐이라, 아래 계층은 위 계층이 무엇을 싣고 있는지 몰라도 자기 일을 할 수 있습니다.

06

왕복을 한 화면에 넣었습니다.

요청만 보여주면 계층이 한 방향으로만 동작하는 것처럼 오해하기 쉽습니다. 응답 11단계를 이어 붙여 두면 같은 절차가 반대 방향으로 한 번 더 일어나고, 그때 출발지와 목적지의 모든 주소가 서로 뒤바뀐다는 것이 눈에 들어옵니다. 명령 하나에 이만큼의 절차가 두 번 필요하다는 점이 이 화면에서 가장 오래 남는 부분입니다.

07

포트 두 개의 성격이 다릅니다.

목적지 포트는 미리 정해진 번호라 보내는 쪽이 알고 있어야 하지만, 출발지 포트는 연결할 때마다 운영체제가 비어 있는 번호를 골라 붙입니다. 응답이 돌아올 때 이 번호를 보고 어느 프로그램에게 줄지 정하기 때문에, 같은 컴퓨터에서 여러 창을 열어도 답이 섞이지 않습니다. 화면에서 두 포트에 각각 다른 설명을 붙여 둔 것이 이 차이를 짚기 위한 것입니다.

08

계층마다 부르는 이름이 달라집니다.

같은 데이터가 전송 계층에서는 세그먼트, 네트워크 계층에서는 패킷, 데이터링크 계층에서는 프레임으로 불립니다. 내용물이 바뀐 것이 아니라 어느 계층의 시점에서 보느냐에 따라 부르는 말이 달라지는 것인데, 이 이름들이 문서에서 섞여 나오면 서로 다른 것처럼 읽히기 쉽습니다. 화면이 단계마다 현재 이름을 함께 표시하는 이유입니다.