TCP 송/수신 원리

 

🔍 이해하면 인생이 바뀌는 TCP 송·수신 원리

TCP 통신 구조는 단순히 '보내고 받는다' 이상의 복잡한 흐름을 갖고 있습니다. 이 글에서는 TCP 통신의 내부 동작 원리를 송신부터 수신까지 단계별로 정리해보았습니다. 특히 속도 지연이나 병목 현상의 원인을 파악하는 데 중요한 흐름 제어 개념까지 함께 다룹니다.

---

📦 TCP 데이터 전송의 흐름

1. 전송 준비 – 파일에서 메모리로

• 서버는 전송할 데이터를 한꺼번에 전송하지 않고 일정 크기(예: 64KB)씩 잘라서 메모리에 올립니다.
• 이 데이터를 send() 등을 통해 커널의 TCP 송신 버퍼로 넘기며 전송이 시작됩니다.

예시: 1.3MB 파일을 64KB 단위로 나누어 전송

---

2. TCP 세그먼트 구성

• 메모리에 올려진 데이터는 TCP가 **세그먼트(segment)**라는 단위로 쪼개고, 각각에 시퀀스 번호를 부여합니다.
• 이 시퀀스 번호를 통해 나중에 수신 측에서 정확한 순서로 재조립이 가능하게 됩니다.

---

3. 세그먼트 → 패킷 → 프레임 (계층별 포장)

• 세그먼트는 IP 계층으로 내려가며 IP 패킷으로 감싸지고,
• IP 패킷은 다시 데이터링크 계층(L2)에서 **프레임(Ethernet 등)**으로 감싸져 전송됩니다.

각 계층은 **캡슐화(encapsulation)**를 통해 데이터를 보호하고 전달 정보를 포함합니다.

---

📥 수신 측 동작

4. 프레임 해체 → 데이터 복원

• 수신 측은 프레임을 해체하면서 다시 IP 패킷 → TCP 세그먼트를 추출하고,
• 시퀀스 번호를 기준으로 재조립한 후 사용자 애플리케이션의 버퍼로 전달합니다.

---

5. ACK(확인 응답) 전송

• 수신 측은 세그먼트를 잘 받으면, 다음에 받아야 할 시퀀스 번호를 ACK로 응답합니다.
• 예: 1번, 2번 세그먼트를 받으면 ACK = 3

이를 통해 송신자는 어떤 데이터까지 안전하게 전달됐는지 확인하고, 다음 세그먼트를 보낼 수 있습니다.

---

🪟 TCP 윈도우 사이즈와 흐름 제어

6. 윈도우 사이즈란?

• 수신 측은 자신이 **얼마만큼 더 받을 수 있는지(버퍼 여유량)**를 윈도우 사이즈로 알려줍니다.
• 이 값은 ACK에 포함되어 송신 측으로 전송됩니다.

7. 수신 애플리케이션이 느릴 경우

• 수신 애플리케이션이 TCP 버퍼에서 데이터를 recv()로 빨리 읽지 않으면, 버퍼가 꽉 차게 됩니다.
• 이때 윈도우 사이즈가 0이 되면 송신자는 전송을 일시 중단합니다. → 속도 지연의 핵심 원인!

---

🎯 실무 관점에서의 인사이트

문제 상황 원인 확인 포인트

TCP 전송 속도 저하	네트워크 병목이 아닌 수신 측 애플리케이션의 recv() 속도 문제	윈도우 사이즈 분석 (tcpdump, wireshark 등으로 확인)
송신자는 전송할 의지가 있으나 멈춤	수신 측 버퍼에 여유 공간 없음	ACK 패킷에 포함된 윈도우 크기 확인
CPU 부하 or 로직 병목	수신 측에서 처리 시간이 길어짐 → 읽기 지연	리드(read) 속도 로그 분석 필요

---

🧩 쉬운 비유: 직소 퍼즐과 택배

• 세그먼트 = 퍼즐 조각
  전체 파일은 작은 조각(세그먼트)으로 나뉘어 보내지고, 수신 측에서 조립되어 원래 파일을 복원합니다.
• 패킷 = 택배 박스
  퍼즐 조각은 택배 상자(패킷)에 담겨 트럭(프레임)으로 전달됩니다.

이 비유는 실제 동작을 완전히 설명하진 못하지만, 처음 개념을 이해하는 데 도움이 됩니다.

---

✅ 마무리

TCP는 단순히 ‘데이터를 신뢰성 있게 전달하는 프로토콜’ 이상의 정교한 흐름 제어 시스템입니다.
특히, 수신 측의 처리 속도와 윈도우 사이즈가 전체 전송 효율에 큰 영향을 미친다는 점을 이해하면, 실제 장애 원인 분석이나 성능 튜닝에 강력한 무기가 됩니다.

---

📎 함께 보면 좋은 자료

• [Wireshark로 TCP 윈도우 분석하는 방법]
• [소켓 프로그래밍에서 recv() 속도 최적화 팁]

 

 

참조

https://www.youtube.com/watch?v=K9L9YZhEjC0