<aside> ☁️

클라우드웨이브 네트워크 1주차 · 2/5 · 약 5분

클라우드웨이브 부트캠프: 네트워크에서 클라우드 네이티브까지

</aside>

둘째 날에는 TCP 3-way handshake와 라우팅을 배웠다. 이전에는 서버 접속이 되지 않으면 곧바로 “방화벽 문제인가?”부터 떠올렸다. 그런데 연결이 만들어지는 순서와 패킷이 선택하는 길을 나눠서 보니 확인할 지점이 훨씬 분명해졌다.

이 글에서 확인할 것

• TCP 연결 수립의 각 단계는 무엇을 확인하게 해 주는가?
• 가장 구체적인 라우팅 경로는 어떻게 선택되는가?
• 퍼블릭 서브넷과 인터넷 연결을 실제 조건으로 어떻게 판별하는가?

3-way handshake는 단순한 인사가 아니었다

TCP 연결은 다음 순서로 시작된다.

1. 클라이언트가 SYN을 보낸다.
2. 서버가 SYN + ACK로 응답한다.
3. 클라이언트가 ACK를 보낸다.

처음에는 서로 준비됐는지 묻는 인사 정도로 생각했다. 핵심은 양쪽이 연결 상태와 초기 순서 정보를 동기화하는 데 있다.

이 과정을 장애 상황에 대입하면 의미가 생긴다.

• SYN이 목적지에 도달하지 못하면 주소, 경로 또는 접근 정책을 확인한다.
• SYN은 갔지만 SYN-ACK가 돌아오지 않으면 서버의 리스닝 상태와 반환 경로를 확인한다.
• TCP 연결은 됐지만 응답이 없다면 TLS나 HTTP 같은 상위 단계로 범위를 좁힌다.

HTTP 4xx나 5xx 응답을 받았다면 적어도 어떤 HTTP 처리 주체까지는 요청이 도달했다는 단서가 된다. 반대로 타임아웃 하나만으로 애플리케이션 문제라고 단정할 수는 없다.

라우팅 테이블은 패킷의 다음 목적지를 정한다

라우팅은 목적지 IP를 보고 패킷을 어디로 보낼지 결정하는 과정이다. 라우팅 테이블에는 보통 목적지 프리픽스와 다음 대상이 기록된다.

flowchart LR
    A["패킷의 목적지 IP"] --> B["라우팅 테이블 조회"]
    B --> C{"가장 구체적인<br/>일치 경로"}
    C --> D["VPC local"]
    C --> E["Internet Gateway"]
    C --> F["NAT·VPN 등 다른 대상"]