개념 사전/네트워크 / 전송 계층
개념 사전 · 프로토콜

TCP

Transmission Control Protocol · 전송 제어 프로토콜

는 연결별 상태를 유지하며 응용에 순서가 있는 바이트 스트림을 제공하는 전송 프로토콜이다. 순서 번호··재전송·윈도우를 사용하지만 응용 메시지 경계나 업무 처리 성공까지 보장하지 않는다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • 손실·중복·재정렬된 세그먼트를 처리해 응용이 연속된 바이트를 읽도록 한다.
  • 수신 윈도우로 상대 버퍼를, 혼잡 윈도우로 네트워크 전송 부담을 조절한다.
  • 포트와 양 끝점 주소로 여러 연결을 분리하고 각 연결의 시작·종료 상태를 관리한다.

02어떤 순서로 동작하나

  1. 클라이언트

    클라이언트가 Seq=1000인 을 보낸다. 상태는 SYN_SENT가 된다.

  2. 서버 +

    LISTEN 서버는 Seq=5000, =1001인 +을 보낸다. 서버는 SYN_RECEIVED가 된다.

  3. 클라이언트

    클라이언트가 =5001을 보내고 로 전환한다. 아직 서버가 이 를 받았다는 뜻은 아니다.

  4. 서버 연결 확정

    서버가 마지막 를 수신하면 로 전환한다. 양쪽의 순서 번호를 확인한 연결에서 바이트를 교환한다.

  5. 바이트 전송과 제어

    수신자는 연속 수신한 바이트의 다음 번호를 로 알리고 수신 창을 광고한다. 송신자는 수신 창과 혼잡 창 안에서 전송하며 손실 추정· 등의 조건에 따라 재전송한다.

  6. 방향별 종료

    송신할 데이터가 끝나면 으로 자기 송신 방향을 닫고 상대 를 기다린다. 반대 방향도 별도로 종료되며 상태 순서에 따라 등이 남을 수 있고, 는 이 정상 종료와 다른 중단 방식이다.

03먼저 알아둘 용어와 구성요소

세그먼트 데이터의 첫 바이트 위치를 나타내는 순서 번호다. 과 도 각각 시퀀스 공간 1바이트를 소비한다.
다음에 기대하는 연속 바이트 번호로 그 이전을 누적 확인한다.
Receiver Window다. 수신자가 현재 받아들일 수 있다고 광고하는 수신 창이다.
Retransmission Timeout이다. 를 받지 못했을 때 재전송을 시작하는 타임아웃 값이다.
연결 시작 때 초기 시퀀스 번호를 동기화하는 플래그다. 은 시퀀스 공간 1바이트를 소비한다.
Acknowledgment 필드가 유효함을 나타내는 플래그다. 누적 값은 다음에 기대하는 시퀀스 번호다.
송신 방향의 데이터를 더 보내지 않겠다는 플래그다. 도 시퀀스 공간 1바이트를 소비한다.
연결을 즉시 거절하거나 중단하는 리셋 플래그다. 정상적인 종료 절차와 다르다.
수신 데이터를 응용으로 신속히 넘기도록 알리는 표시다. 응용 메시지의 경계나 별도 패킷 전송을 보장하지 않는다.
Urgent Pointer가 유효함을 알리는 플래그다. 일반적인 스트림 데이터와 구별되는 긴급 데이터 처리를 나타낸다.
Initial 다. 연결의 각 송신 방향에서 시작하는 시퀀스 번호다.
Maximum Segment Size다. 연결 시작 시 알리는 수신 가능한 데이터 부분의 최대 크기로 IP· 헤더는 제외한다.
Selective Acknowledgment다. 수신한 불연속 데이터 범위를 송신자에게 추가로 알려 손실 구간의 재전송을 돕는 옵션이다.
Congestion Window다. 송신자가 네트워크 혼잡을 고려하여 허용하는 미확인 전송량의 한도다.
Round-Trip Time이다. 송신부터 관련 응답 수신까지의 왕복 시간이다.
Smoothed 다. 여러 관측값으로 갱신한 평활 왕복 시간 추정치다.
Variation이다. 추정에서 변동성을 나타내며 재전송 타이머 계산에 반영한다.
연결 시작 시 협상하는 창 크기 확장 옵션이다. 헤더의 16비트 Window 값을 더 큰 범위로 해석하게 한다.
능동 연결 측이 을 전송하고 응답을 기다리는 상태다.
을 받고 과 를 전송한 뒤 최종 를 기다리는 상태다.
연결 설정이 완료되어 양방향 데이터 전송이 가능한 상태다.
상대의 을 받아 수신 방향 종료를 알았지만, 로컬 응용이 아직 송신 방향을 닫지 않은 상태다.
능동 종료 측 등이 지연 세그먼트와 종료 재전송에 대비해 일정 시간 연결 정보를 유지하는 상태다.
아직 되지 않은 가장 오래된 송신 바이트의 시퀀스 번호다.
다음에 보낼 새 데이터의 시퀀스 번호를 나타내는 송신 상태 변수다.
LEARN THROUGH PRACTICE

실습: 100바이트 전송과 누적 ACK·재전송 추적

SSH에서 수집한 Seq·Next Seq·로 확인되지 않은 바이트 범위를 찾는다.

실습 구성과 전제

  • SSH의 양방향 캡처다. 암호화된 내용 대신 전송 헤더를 분석한다.
  • 일부 화면은 헤더만 잘려 있다. 보이지 않는 지연이나 손실 위치는 추정하지 않는다.

  1. 동일 연결과 번호 기준 고정

    • 양끝 IP·포트가 같은 SSH 연결을 고르고 .stream으로 좁힌다. 다른 연결의 상대 Seq가 같아도 같은 데이터가 아니다.
    • 여기서는 상대 Seq로 계산한다. 는 반대 방향 데이터의 수신 상태임을 기록한다.
    text
    Wireshark 표시 필터: tcp.port == 22
선택한 패킷 → Follow → TCP Stream
표시 필터를 해당 tcp.stream으로 고정

    실제 stream 번호는 선택 결과를 사용한다.

    확인 기준

    raw와 relative 번호를 섞지 않는다.

  2. 송신 범위 계산

    • Seq 4132, Next Seq 4232이므로 100바이트이며 범위는 4132~4231이다. 1924는 역방향의 다음 수신 위치다.
    • Flags 0x018은 +다. 데이터 길이는 Seq 차이와 Len으로 판단하며 만으로 계산하지 않는다.
    TCP 패킷 교환 · 유실 시나리오 실제 확인 (7)원본 크기로 보기 ↗
    • Sequence 4132와 Next Sequence 4232가 보인다.
    • ACK 1924와 Flags 0x018이 별도 필드다.
    확인 기준

    4232−4132=100과 데이터 방향을 함께 기록한다.

  3. 반대 방향 누적 ACK 해석

    • 반대 방향의 Seq와 Next Seq는 모두 1924, 는 4132다. 4131까지 연속 수신을 확인하며 4132부터는 아직 누적 확인하지 않는다.
    • 하나만으로 직전 패킷이 반드시 손실되었다고 단정하지 않는다. 관측 위치·처리 순서·후속 도 필요하다.
    TCP 패킷 교환 · 유실 시나리오 실제 확인 (8)원본 크기로 보기 ↗
    • Seq와 Next Seq가 모두 1924다.
    • ACK 4132, Flags 0x010, Window 2944가 보인다.
    확인 기준

    4132와 기대값 4232를 비교하되 손실 지점을 추정하지 않는다.

  4. 반복 범위와 원인 분리

    • 후속 화면에도 Seq 4132~Next Seq 4232가 나타나 같은 100바이트 범위가 반복된다. 재전송 기록과 부합한다.
    • 빠른 재전송인지 만료인지는 시간과 패턴이 필요하다. 잘린 헤더만으로 원인을 확정하지 않는다.
    text
    Wireshark 표시 필터: tcp.analysis.retransmission || tcp.analysis.fast_retransmission

    실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.

    TCP 패킷 교환 · 유실 시나리오 실제 확인 (9)원본 크기로 보기 ↗
    • 4132~4232 범위가 다시 보인다.
    • ACK 1924와 PSH·ACK는 보이지만 시각은 없다.
    확인 기준

    전체 캡처에서 재전송 표시·시각·동일 범위를 함께 확인한다.

실습에서 확인한 동작 원리

  • 는 패킷 개수가 아니라 다음 연속 바이트 위치를 알린다.
  • 반복 범위 확인과 재전송 원인·손실 위치 확정은 다른 단계다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 재전송되지 않은 데이터에서 표본 200ms와 260ms를 순서대로 얻은 가상 예다. 시계 정밀도 G=10ms, α=1/8, β=1/4, K=4를 사용한다. =200ms, =100ms로 초기화한다. 계산 =200+max(10,4×100)=600ms이며 RFC 6298의 권고 하한을 적용하면 1초가 된다.
  • 두 번째 표본의 차이는 |200−260|=60ms다. 이전 를 사용해 =0.75×100+0.25×60=90ms를 먼저 계산한다. =0.875×200+0.125×260=207.5ms다. 새 계산 =207.5+max(10,4×90)=567.5ms이며 같은 하한 조건에서는 1초를 유지한다.
  • 재전송 뒤의 는 어느 전송에 대한 응답인지 모호하므로 원칙적으로 표본에서 제외한다. 타임스탬프 등으로 모호성을 해소하는 경우와 운영체제별 타이머 구현은 구분한다.

05혼동하기 쉬운 점과 확인 기준

  • 수신자가 1000~1499를 받은 뒤 2000~2499를 먼저 받으면 누적 는 1500에 머문다. 뒤쪽 자료가 도착했어도 연속 수신 범위의 공백을 건너뛰어 =2500으로 올리지 않는다.
  • 가 협상됐다면 [2000,2500) 블록으로 따로 받은 구간을 알릴 수 있다. 왼쪽은 첫 바이트, 오른쪽은 마지막 바이트 다음 번호이며 누적 를 대체하지 않는다.
  • 1500~1999가 도착하면 앞서 보관한 구간과 연결되어 가 2500으로 진행한다. 최초 공백이 손실이었는지 단순 지연·재정렬이었는지는 송수신 시각과 재전송 기록을 추가로 봐야 한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

TCP 헤더·상태·흐름 제어와 재전송TCP의 바이트 번호와 연결 상태를 기준으로 연결 수립, 데이터 전달, 손실 복구, 종료를 해석한다. 헤더와 옵션의 크기를 읽고 원문 SSH 캡처의 ACK·재전송 사례를 다시 계산한다.상세 노트 읽기 →
READ · OBSERVE · CONNECT

함께 보는 학습 자료

아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.

패킷 예제

RFC 9293 §3.5·Figure 6: 연결 설정

양쪽 상태와 Seq·를 같은 시간축에서 읽어 이 순서 공간을 소비하는 이유를 확인한다.

읽으면서 확인할 것
  • Figure 6의 ·/· 순서
  • 와 의 차이
  • 재전송·동시 연결의 별도 분기

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.