두 컴퓨터는 세 번 인사한 뒤 대화합니다.

01

양쪽 상태를 따로 들고 있습니다.

각 단계는 내 쪽 상태와 서버 쪽 상태를 각각 하나씩 가지고 있습니다. 연결이 하나의 값으로 관리되는 것이 아니라 양 끝이 각자의 상태를 들고 있다는 점이 중요한데, 그래서 다섯 번째 단계처럼 한쪽은 연결됐다고 보는데 다른 쪽은 아직 아닌 구간이 생깁니다. 실무에서 마주치는 여러 증상이 바로 이 어긋난 구간에서 나옵니다.

02

회선 위의 단계를 따로 뒀습니다.

세그먼트를 만드는 단계와 그것이 상대에게 도착하는 단계 사이에 ‘이동 중’ 단계를 하나 끼워 넣었습니다. 두 단계로 나누지 않으면 보내는 즉시 받는 것처럼 보여서, 왜 세 번이나 오가야 하는지가 설명되지 않기 때문입니다. 첫 SYN 이 상대에게 닿았는지 보낸 쪽이 알 수 없다는 사실이 이 데모 전체의 전제입니다.

03

ACK 은 다음에 받고 싶은 번호입니다.

받은 번호가 아니라 다음에 기대하는 번호를 적는다는 점이 처음 볼 때 가장 헷갈리는 부분입니다. SYN 은 데이터가 없는데도 번호를 하나 차지하기 때문에 100 에 대한 응답이 101 이 됩니다. 화면의 각 필드에 붙은 설명이 이 계산을 그때그때 짚어 주도록 해 두었고, 숫자를 외우는 대신 규칙을 확인하게 하는 것이 목적입니다.

04

시작 번호는 읽기 쉬운 값으로 고정했습니다.

화면의 100 과 300 은 규격이 정한 값이 아니라 데모가 고른 예시입니다. 실제 시작 번호는 공격자가 다음 값을 추측해 남의 연결에 끼어들지 못하도록 예측하기 어렵게 선택합니다. 여기서 고정값을 쓴 것은 101 과 301 이 어디서 나왔는지 눈으로 따라갈 수 있게 하기 위해서이고, 이 점을 각 필드 설명에도 함께 적어 두었습니다.

05

상태 이름은 규격의 것을 그대로 씁니다.

CLOSED · LISTEN · SYN_SENT · SYN_RCVD · ESTABLISHED 는 데모가 지어낸 이름이 아니라 규격에 정의된 상태입니다. 한글 설명을 함께 붙이되 영문 이름을 그대로 노출한 이유는, 실제로 서버에서 연결 상태를 확인할 때 보게 되는 문자열이 이것들이기 때문입니다. 화면에서 익힌 단어가 터미널에서 그대로 쓰이는 편이 낫습니다.

06

계산과 화면을 분리해 두었습니다.

여덟 단계를 만드는 코드는 화면 코드와 따로 있고, 자동 테스트가 단계 수와 각 단계의 상태 조합을 직접 확인합니다. 버튼을 눌러 가며 사람이 확인하는 방식이었다면 단계를 하나 고칠 때마다 전부 다시 봐야 했을 텐데, 상태 머신만 따로 검증하면 화면을 바꿔도 연결 절차가 조용히 틀어지지 않습니다.

07

멈춘 칸이 곧 볼 곳을 정해 줍니다.

이 표를 실무에서 쓸 수 있는 이유는, 연결이 안 될 때 어느 상태에서 멈췄는지가 원인의 범위를 좁혀 주기 때문입니다. 내 쪽이 첫 인사를 보낸 상태에서 움직이지 않으면 그 인사가 상대에게 닿지 않은 것이고, 서버 쪽에 답을 보낸 상태가 잔뜩 쌓여 있으면 서버는 답했는데 마지막 확인이 돌아오지 않는 것입니다. 화면에서 상태 배지를 크게 띄워 둔 것도 숫자보다 이 칸을 먼저 보는 습관을 들이려는 의도입니다.

08

네 장면은 여덟 단계에서 골라낸 것입니다.

화면 위쪽의 장면 표시는 네 칸이지만 내부 단계는 여덟 개입니다. 세그먼트가 만들어지는 순간과 도착하는 순간 중 사람이 이야기로 기억하기 좋은 지점만 골라 장면으로 묶었기 때문입니다. 모든 단계를 다 보여주면 정확하지만 여덟 번을 눌러야 하고, 네 번으로 줄이면 대신 회선 위에 머무는 구간이 흐려집니다. 두 표현을 한 화면에 같이 둔 것이 절충안입니다.