Chapter 2

신뢰할 수 있는 링크와 보안

  • 2.1 Reliability
  • 2.2 Connection lifecycle
  • 2.3 Flow control
  • 2.4 Congestion control
  • 2.5 Custom protocols
  • 2.6 Encryption
  • 2.7 Authentication
  • 2.8 Integrity
  • 2.9 Handshake

분산 시스템의 모든 통신은 결국 하나의 질문에서 시작해 — "이 불안정한 네트워크 위에서 어떻게 믿을 수 있는 채널을 만들지?" IP는 패킷을 유실하고, 중복시키고, 순서를 뒤섞어. TCP는 그 위에 신뢰할 수 있는 채널이라는 환상을 만들고, TLS는 그 신뢰할 수 있는 채널 위에 보안이라는 환상을 또 쌓아. 약한 보장 위에 강한 보장을 레이어링하는 이 패턴이 이 책 전체를 관통하거든.

TCP가 신뢰성을 만드는 방법부터 보자. 바이트 스트림을 세그먼트로 쪼개고, 각각에 순차 번호를 붙여서 수신자가 빈 구간과 중복을 감지할 수 있게 해. 모든 세그먼트는 수신자가 ACK해야 하고, 안 오면 타이머가 돌아서 재전송해. 체크섬으로 데이터 무결성도 검증하고. 순차 번호 + ACK + 재전송 + 체크섬 — 이 조합이 "순서대로, 빠짐없이, 손상 없이"의 환상을 만드는 거야.

근데 이 환상은 공짜가 아니야. 연결을 열려면 3-way handshake(SYN → SYN/ACK → ACK)로 풀 라운드 트립 동안 데이터가 안 나가. RTT가 짧을수록 빨리 맺어지니까 서버를 클라이언트 가까이 두는 게 중요해. 닫을 때도 소켓이 바로 사라지지 않고 TIME_WAIT으로 수 분간 대기하거든. 연결이 빠르게 열리고 닫히면 TIME_WAIT 소켓이 쌓여서 새 연결이 실패할 수 있어. 그래서 커넥션 풀을 쓰는 거야.

**흐름 제어(flow control)**는 송신자가 수신자를 압도하지 않게 하는 백오프 메커니즘이야. 수신자가 ACK 보낼 때 수신 버퍼 크기를 같이 알려주고, 송신자는 그 이상 안 보내. **혼잡 제어(congestion control)**는 수신자가 아니라 네트워크 자체를 보호해. 송신자가 혼잡 윈도우를 유지하는데, 새 연결 시 작게 시작해서 지수적으로 키워. 세그먼트가 유실되면 윈도우를 확 줄이고 다시 천천히 키우고. 대역폭 공식은 Bandwidth = WinSize / RTT — TCP가 윈도우를 최적화하려 노력하지만 RTT는 어쩔 수 없어.

TCP의 신뢰성이 맞지 않는 경우도 있어. UDP는 연결 없이, 순차 번호 없이, ACK 없이, 흐름/혼잡 제어 없이 — 날것 그대로야. 멀티플레이어 게임에서 초당 수십 번 보내는 상태 스냅샷이 유실되면 재전송할 의미가 없잖아 — 게임은 실시간이니까 이미 쓸모없지. **HTTP/3도 UDP 기반(QUIC)**이야.

여기까지가 "신뢰할 수 있는 채널"이야. 근데 그 채널을 누가 엿듣고 있으면 아무 소용이 없지. 도청, 위장, 변조 — 이 세 가지를 막으려면 TLS가 필요해.

**암호화(encryption)**부터. 통신 내용을 제3자가 못 읽게 만드는 건데, TLS는 대칭키 암호화를 써. 문제는 이 키를 어떻게 안전하게 교환하냐지. 여기서 비대칭키 암호화가 등장해 — 공개키로 암호화하면 비밀키로만 복호화할 수 있으니까, 처음에 대칭키를 안전하게 주고받고 이후 통신은 빠른 대칭키로 처리하는 거야.

암호화만 하면 끝일까? 내가 통신하는 상대가 진짜 그 상대인지도 확인해야 해. 안 그러면 **중간자 공격(man-in-the-middle)**에 당하거든. TLS는 **인증서(certificate)**로 이걸 해결해. 서버가 자기 공개키가 담긴 인증서를 보여주고, 이 인증서는 신뢰할 수 있는 **인증 기관(CA)**이 서명한 거야. CA들은 **신뢰 체인(chain of trust)**을 형성해서 루트 CA까지 올라가.

세 번째 기둥은 **무결성(integrity)**이야. TLS는 **MAC(Message Authentication Code)**을 써서 메시지가 중간에 변조되지 않았는지 보장해. 체크섬이랑 비슷하다고? 핵심 차이는 MAC은 비밀키가 있어야 계산 가능하다는 거야. 공격자가 메시지를 변조해도 MAC을 다시 만들 수 없지.

이 세 가지를 합치는 과정이 TLS 핸드셰이크야. 클라이언트와 서버가 암호화 알고리즘에 합의하고, 서버가 인증서로 신원을 증명하고, 공유 세션 키를 교환해. TCP 핸드셰이크에 더해서 **추가 왕복(RTT)**이 필요하지. TLS 1.3이 1-RTT로 줄였고, 이전에 연결한 적 있으면 0-RTT도 가능하지만 — 보안은 공짜가 아니야.

결국 이 장 전체가 하나의 이야기야. IP라는 불안정한 바닥 위에 TCP가 신뢰를, TLS가 보안을 쌓아. 각 레이어는 아래 레이어의 약점을 보완하면서 성능이라는 대가를 치르지. 이 추상화 레이어링 패턴을 이해하면 나머지 분산 시스템 개념도 같은 눈으로 볼 수 있어.


정리

2장 읽고 기억할 거 세 가지:

  1. TCP는 순차 번호 + ACK + 재전송 + 체크섬으로 신뢰의 환상을, TLS는 암호화 + 인증 + 무결성으로 보안의 환상을 만들어 — 약한 보장 위에 강한 보장을 쌓는 레이어링 패턴이야.
  2. 신뢰성과 보안 모두 RTT 비용이 붙어 — 3-way handshake, congestion control의 slow start, TLS handshake 전부 서버를 클라이언트 가까이 두는 게 중요한 이유지.
  3. TCP의 대가가 안 맞으면 UDP 위에 커스텀 프로토콜 — 게임, 실시간 스트리밍, HTTP/3(QUIC)이 그 예야.