[네트워크] 전송 계층(Transport) - TCP overview

TCP(Transmission Control Protocol, 전송 제어 프로토콜)

• TCP는 신뢰성이 없는 인터넷을 통해 종단간에 신뢰성 있는 바이트 스트림을 전송하도록 설계된 프로토콜이다.
• Reliable, In-order Byte Stream
  • 신뢰성: TCP는 데이터가 손실, 중복, 순서 뒤바뀜 없이 정확히 전송되는 것을 보장한다.
  • 순서 보장: 전송된 데이터는 전송된 순서대로 도착한다.
  • 메시지 경계 없음: TCP는 연속적인 바이트 스트림을 전송하며, 개별 메시지 경계를 정의하지 않는다.
• Congestion and Flow Control: TCP는 혼잡 제어 및 흐름 제어 메커니즘을 갖추고 있어, 네트워크의 혼잡 상태를 고려하고 송신자가 수신자를 압도하지 않도록 한다.
• 점대점(Point-to-Point): TCP는 한 송신자(sender)와 한 수신자(receiver) 간의 점대점(point-to-point) 통신을 제공하며, 멀티캐스팅이나 브로드캐스팅은 지원하지 않는다.
• 전이중(Full Duplex Data): 같은 연결에서 데이터가 양 방향으로 전송될 수 있다.
• MSS (Maximum Segment Size): TCP는 MSS를 정의하여 한 번에 보낼 수 있는 최대 세그먼트 크기를 결정한다.
• Cumulative ACKs: TCP는 누적된 확인 응답(cumulative ACKs) 방식을 사용하여 수신자가 받은 마지막 연속적인 바이트까지의 수신을 확인한다.
• Pipelining: TCP는 데이터의 효율적인 전송을 위해 파이프라이닝을 사용한다. 여러 개의 패킷이 동시에 “비행 중” 상태가 될 수 있다.
• Connection-Oriented: TCP는 연결 지향적이다. 데이터 교환 전에 송신자와 수신자 간에 핸드셰이킹이 이루어지며, 이 과정에서 초기 상태 설정이 수행된다.

TCP segment structure

• 4bytes(32bits) * 5줄 → 20bytes가 기본으로, 옵션이 붙으면 더 길어질 수도 있다.
• 인터넷을 통해 데이터를 전송할 때 사용되는 표준 방식인 패킷은 IP 헤더 + TCP 헤더 + 메세지로 구성된다.

Sequence numbers, ACKs

• 시퀀스 번호(Sequence numbers): byte stream “number” of first byte in segment’s data
• ACK(Acknowledgements): seq # of next byte expected from other side

• 간단한 텔넷(telnet) 시나리오
  • 텔넷(Telnet): 원격 컴퓨터에 대한 텍스트 기반의 터미널 접속을 제공하는 네트워크 프로토콜
  • 사용자가 ‘C’를 입력하면 호스트 A는 이 문자를 호스트 B로 전송한다.
  • 호스트 B는 ‘C’를 받고 이를 ACK로 확인한 후 ‘C’를 호스트 A에게 에코한다.
  • 호스트 A는 이 에코된 ‘C’를 받고 ACK를 보내 응답을 확인한다.
• 시퀀스 번호의 역할: 각 데이터 전송과 ACK 메시지에는 시퀀스 번호가 포함되어 있어, 양방향 통신이 올바른 순서로 진행되고 있는지 확인한다.

TCP 타임아웃 설정 방법

1. RTT(Round-Trip Time)보다 길게 설정
   • 타임아웃은 RTT(패킷이 송신자로부터 수신자에게 가고, 수신자로부터 ACK가 송신자에게 돌아오는데 걸리는 시간)보다 길게 설정해야 하고, RTT는 네트워크의 혼잡 상태에 따라 변동될 수 있다.
2. 너무 짧게 설정하지 않기
   • 타임아웃이 너무 짧으면, 아직 네트워크 상에서 전송 중인 패킷에 대해 불필요하게 재전송을 하게 되는 premature timeout이 발생할 수 있다.
3. 너무 길게 설정하지 않기
   • 타임아웃이 너무 길면, 패킷 손실에 대한 반응이 느려진다.

RTT 추정 방법

1. SampleRTT 측정
   • 송신자는 세그먼트를 전송하고 해당 세그먼트에 대한 ACK를 받을 때까지의 시간을 측정한다. 이 측정된 시간을 SampleRTT라고 한다. 재전송된 세그먼트는 SampleRTT 측정에서 제외한다.
2. EstimatedRTT 계산
   • SampleRTT는 변동성이 크기 때문에, 이를 “평활화(smoothing)”하기 위해 여러 최근 측정치의 평균을 사용한다. EstimatedRTT는 다음 공식으로 계산된다.
   • EstimatedRTT = (1 − α) × EstimatedRTT + α × SampleRTT
   • 여기서 α는 일반적으로 0.125로 설정된다.
3. DevRTT 계산
   • SampleRTT가 EstimatedRTT로부터 얼마나 벗어나는지의 변동성을 측정하는데, 이를 DevRTT라고 한다. DevRTT는 다음 공식으로 계산된다
   • DevRTT = (1 − β) × DevRTT + β × ∣SampleRTT − EstimatedRTT∣
   • 여기서 β는 일반적으로 0.25로 설정된다.
4. 타임아웃 간격 설정
   • 실제 타임아웃 간격은 EstimatedRTT에 “안전 여유분(safety margin)”을 더한 값으로 설정된다.
   • 이 여유분은 DevRTT에 기반하며, 네트워크의 변동성이 크면 클수록 안전 여유분도 커야한다. 타임아웃 간격은 다음과 같이 설정된다.
   • TimeoutInterval = EstimatedRTT + 4 × DevRTT

Fast Retransmit의 작동 방식

• Fast Retransmit은 TCP의 오류 제어 기능 중 하나로, 패킷 손실이 발생했을 때 표준 타임아웃을 기다리지 않고 즉각적으로 재전송을 시작할 수 있도록 한다.

1. 송신자가 데이터 패킷을 보낸다. 예를 들어, 시퀀스 번호 100을 가진 20바이트의 데이터를 포함하는 패킷을 전송한다.
2. 손실 감지: 송신자는 패킷을 보낸 후 ACK를 기다린다. 만약 패킷이 손실되면 (예: 시퀀스 번호 100의 패킷), 수신자는 그 이후의 패킷들을 받고도 처음 손실된 패킷에 대한 ACK를 보낼 수 없다. 대신, 수신자는 이미 받은 마지막 패킷의 ACK를 반복해서 보낸다.
3. 세 개의 중복 ACK 수신: 송신자가 동일한 시퀀스 번호에 대해 세 개의 중복 ACK를 받으면, 이는 네트워크에서 패킷 손실이 발생했을 가능성이 높다는 신호로 해석된다.
4. 빠른 재전송(Fast Retransmit): 송신자는 타임아웃을 기다리지 않고 즉시 손실된 것으로 추정되는 패킷을 재전송한다. 이 경우에는 시퀀스 번호 100의 패킷을 다시 보낸다.

• Fast Retransmit 알고리즘은 패킷 손실에 대한 빠른 반응을 가능하게 하여 TCP의 전체적인 성능을 향상시킨다. 타임아웃에 의존하는 대신, 네트워크 상황에 보다 민감하게 반응하여 불필요한 대기 시간 없이 데이터 전송을 계속할 수 있게 한다.

TCP connection management

• TCP 연결 관리는 데이터를 교환하기 전에 수립되는 절차이다.
• 클라이언트와 서버 간의 핸드셰이크(handshake) 단계를 포함한다.
• 이 핸드셰이크 과정은 연결을 설정하기 위한 당사자 간의 동의와 연결 매개변수(시작 시퀀스 번호 등)에 대한 합의를 포함한다.

TCP 핸드셰이크 과정

1. 연결 수립 동의: 클라이언트와 서버는 먼저 연결을 수립하려는 의사가 있음을 서로에게 알려준다.
2. 연결 매개변수 합의: 연결을 설정하기 위한 매개변수에 대해 합의한다.
3. 소켓 프로그래밍
   • 클라이언트는 대상 호스트의 이름과 포트 번호를 사용하여 새로운 소켓을 생성한다(new Socket(“hostname”, “port number”)).
   • 서버는 연결을 수신 대기하는 소켓(welcomeSocket)을 생성하고, 연결 요청이 들어오면 이를 수락(accept())하여 연결 소켓(connectionSocket)을 생성한다.

• 두 단계의 핸드셰이크는 다음과 같은 네트워크 환경의 변동성으로 인해 항상 신뢰할 수 없다.

  1. 변동 지연: 네트워크를 통한 메시지 전송에는 시간이 걸릴 수 있으며, 이 지연은 변동될 수 있다.
  2. 메시지 재전송: 메시지 손실로 인해 발생한 재전송은 메시지가 늦게 도착하게 할 수 있다.
  3. 메시지 재정렬: 네트워크 내에서 메시지가 재정렬되어 메시지의 도착 순서가 예상과 다를 수 있다.
  4. 상대방의 상태를 볼 수 없음: 네트워크 상의 다른 당사자가 현재 어떤 상태인지 직접적으로 알 수 없기 때문에, 연결 수립에 대한 양측의 동의를 확신하기 어렵다.
• 이러한 이유로 TCP는 세 단계 핸드셰이크(three-way handshake)를 사용한다.
• 3-way handshake는 연결을 설정하고 해제하는 과정에서 더 신뢰할 수 있는 방법을 제공하며, SYN(연결 요청), SYN-ACK(연결 요청에 대한 응답), ACK(최종 확인)의 세 단계로 이루어진다.
• 이 방식은 연결이 안정적으로 수립되도록 보장하고, 메시지 손실이나 순서 문제를 해결하는 데 도움을 준다.

TCP 3-way handshake

• 세 단계 핸드셰이크의 각 단계는 다음과 같다.

1. SYN: 클라이언트는 연결을 시작하기 위해 서버로 SYN 패킷을 보낸다. 이 패킷은 클라이언트가 선택한 초기 시퀀스 번호 x를 포함한다.
2. SYN-ACK: 서버는 클라이언트의 SYN 패킷을 받고, 클라이언트가 살아있다는 것을 확인한 후에 SYN-ACK 패킷을 클라이언트로 보낸다. 이 패킷은 서버의 초기 시퀀스 번호 y와, 클라이언트의 시퀀스 번호 x에 1을 더한 ACK 번호를 포함한다.
3. ACK: 클라이언트는 서버의 SYN-ACK 패킷을 받고, 서버가 살아있다는 것을 확인한 후에 ACK 패킷을 서버로 보낸다. 이 ACK 패킷은 서버의 시퀀스 번호 y에 1을 더한 번호를 ACK 번호로 포함한다.

• 이 과정이 완료되면, 클라이언트와 서버는 데이터를 안전하게 교환할 준비가 완료된다.

• 양쪽 모두 ESTAB(established) 상태에 있으며, 데이터 전송을 시작할 수 있다.

• 클라이언트는 socket()과 connect() 호출을 통해 연결을 초기화하고, 서버는 socket(), bind(), listen(), 그리고 accept() 호출을 통해 들어오는 연결을 수락한다. 이러한 함수 호출은 소켓 API의 일부로서, 네트워크 프로그래밍에서 일반적으로 사용된다.

Closing a TCP connection(4-way Handshake)

• TCP 연결을 종료하는 과정은 연결의 개설과는 반대로, 연결을 정상적으로 닫기 위한 네 단계의 과정을 거친다.
• 이 과정은 양방향 종료로, 각 당사자가 자신의 송신 측면을 종료하고, 이에 대한 응답으로 상대방으로부터 확인(ACK)을 받는다.
• 각 단계는 다음과 같다.

1. FIN 보내기: 연결을 종료하고자 하는 클라이언트나 서버는 FIN(Finish) 플래그가 설정된 TCP 세그먼트를 보낸다. FIN 비트가 1로 설정되면, 연결의 한 쪽 끝을 닫고자 함을 의미한다.
2. FIN에 대한 ACK 응답: FIN 세그먼트를 수신한 상대방은 이를 확인하기 위해 ACK 세그먼트를 보낸다.
3. FIN과 ACK의 결합: FIN을 받은 쪽도 연결을 종료할 준비가 되었다면, 자신의 FIN 세그먼트와 수신된 FIN에 대한 ACK를 결합하여 한 번에 보낼 수 있다.
4. 동시 FIN 처리: 두 당사자가 동시에 연결 종료를 원하는 경우, 동시에 FIN 세그먼트를 교환할 수 있으며, 각 당사자는 상대방의 FIN에 대해 ACK를 보낸다.

MTU (Maximum Transmission Unit)

• 네트워크 인터페이스에서 한 번에 전송할 수 있는 헤더와 페이로드를 모두 포함하는 전체 데이터 패킷의 크기
• TCP, UDP 같은 특정 프로토콜에 국한되지 않고, 네트워크 계층(예: IP 계층)에서 사용된다.
• MTU는 네트워크의 물리적 또는 논리적 특성에 따라 결정되며, 네트워크 링크에 따라 다를 수 있다.

• 이더넷의 표준 MTU는 일반적으로 1500 바이트

• MTU 설정은 네트워크의 성능과 효율성에 영향을 미친다.
  • 너무 큰 MTU는 네트워크의 오류율이 높을 때 패킷 손실을 증가시킬 수 있다.
  • 너무 작은 MTU는 오버헤드를 증가시켜 효율성을 감소시킬 수 있다.

MSS (Maximum Segment Size)

• TCP 연결을 통해 전송될 수 있는 데이터 세그먼트의 최대 크기
• TCP에서만 사용되는 용어로 헤더를 제외하고 순수하게 데이터 부분만을 포함한다.
• 일반적으로 MSS는 MTU에서 IP 헤더와 TCP 헤더의 크기를 빼서 계산한다.
  • 예를 들어, 이더넷의 MTU가 1500 바이트이고, IP 헤더와 TCP 헤더가 각각 20바이트일 경우, MSS는 1460 바이트가 된다 (1500 - 20 - 20).

TCP flow control

• TCP 흐름 제어(flow control)는 수신자의 버퍼가 넘치지 않도록 송신자의 데이터 전송 속도를 조절하는 메커니즘이다.
• 네트워크 계층에서 전달하는 데이터가 응용 계층이 소켓 버퍼에서 데이터를 제거하는 속도보다 빠를 때 중요한 역할을 한다.

흐름 제어의 목적

• 네트워크 계층이 IP 데이터그램의 페이로드를 TCP 소켓 버퍼로 전달하는 속도가 응용 계층이 그 데이터를 처리하는 속도보다 빠를 경우, TCP 흐름 제어가 필요하다.
• 수신자의 프로토콜 스택이 소켓 버퍼로부터 데이터를 제거하는 속도를 네트워크 전송 속도와 일치시키기 위해 사용된다.

흐름 제어의 방식

1. 수신 창 크기(rwnd)의 광고:
   • TCP 수신자는 TCP 헤더의 rwnd 필드를 통해 현재 자유롭게 사용할 수 있는 버퍼 공간의 크기를 광고한다.
   • rwnd (Receive Window): 수신자가 현재 처리할 수 있는 데이터의 양을 송신자에게 알려주는 역할
2. 수신 버퍼 크기(RcvBuffer) 설정:
   • 수신 버퍼의 크기는 소켓 옵션을 통해 설정될 수 있으며, 많은 운영 체제는 수신 버퍼 크기를 자동으로 조정
   • 일반적인 기본값은 4096 바이트
3. 송신자의 데이터 전송 제한:
   • 송신자는 수신한 rwnd 값을 기준으로 아직 확인되지 않은 (“비행 중인”) 데이터의 양을 제한한다.
   • 이는 수신자의 버퍼가 넘치지 않도록 보장하는 역할을 한다.

흐름 제어의 결과

• 송신자는 수신자의 버퍼 용량을 초과하여 데이터를 전송함으로써 발생할 수 있는 오버플로우를 방지한다.
• 송신자는 수신자의 버퍼가 가득 차기 전에 데이터 전송을 중단하고 수신자의 버퍼가 다시 데이터를 수용할 준비가 되었을 때 전송을 재개한다.
• TCP는 네트워크의 다양한 속도에 맞춰 데이터 전송률을 조절하며, 안정적인 데이터 전송을 보장한다.

TCP congestion control

• 혼잡(congestion)은 네트워크가 처리할 수 있는 것보다 많은 양의 데이터를 많은 소스가 너무 빠르게 보낼 때 발생하는 상태를 말한다.
• 특히 공유 네트워크 자원(예: 라우터 버퍼)의 한계로 인해 발생한다.

혼잡의 징후

• 긴 지연 시간: 라우터의 큐에 패킷이 많이 쌓이면 전송 지연이 길어진다.
• 패킷 손실: 라우터의 버퍼가 오버플로우(가득 참)되면 패킷이 버려진다.

혼잡 제어 원리

• 혼잡 제어(congestion control)는 네트워크의 혼잡 상태를 감지하고, 이에 대응하여 데이터 전송 속도를 조절하는 메커니즘이다.
• 흐름 제어(flow control)와는 다르며, 흐름 제어는 단일 송신자가 단일 수신자에게 너무 빠르게 데이터를 보내는 것을 제한하는 반면, 혼잡 제어는 네트워크 전체의 트래픽 부하를 관리한다.

Causes/costs of congestion: scenario 1

• 가장 간단한 시나리오에서 두 개의 흐름(flow)이 하나의 라우터를 통해 데이터를 보내고 있으며, 라우터에는 무한한 버퍼가 있다고 가정한다.
• 라우터의 입력 링크와 출력 링크의 용량은 R이다.
• 데이터의 원래 도착률(λin)이 R/2에 가까워질수록, 라우터에서 처리할 수 있는 최대 연결당 처리량은 R/2이므로, 큐의 지연 시간은 길어진다.
• 출력 링크의 용량에 가까운 도착률에서는 패킷의 처리와 전송이 지연되고, 이로 인해 전체적인 네트워크 성능이 저하될 수 있다.
• 재전송이 필요 없는 경우에도, 혼잡은 네트워크 성능에 심각한 영향을 줄 수 있으며, 이는 네트워크 설계와 관리에 있어서 주요한 문제 중 하나이다.

Causes/costs of congestion: scenario 2

Causes/costs of congestion: scenario 3

1. 네 송신자: 네 개의 호스트(Host A, B, C, D)가 데이터를 전송하고 있다.
2. 멀티홉 경로: 각 호스트의 데이터는 라우터를 통해 여러 홉을 거쳐 다른 호스트에 도달한다.
3. 유한한 버퍼: 라우터는 유한한 크기의 버퍼를 가지고 있어, 버퍼가 가득 차면 추가로 도착하는 패킷을 처리할 수 없어 패킷 손실이 발생한다.
4. 재전송: 패킷 손실이 발생하면, 송신자는 타임아웃을 감지하고 손실된 패킷을 재전송한다.

• 혼잡 상황에서의 문제

  • 혼잡 증가: Host A의 재전송(λ’_in)이 증가함에 따라, 라우터의 버퍼가 빠르게 차게 되어 추가로 도착하는 다른 호스트의 패킷들(예를 들어 Host B의 파란색 패킷)이 라우터의 상위 큐에서 드롭될 수 있다.
  • 처리량 감소: 그 결과, 파란색 패킷의 처리량(λ_out)이 감소하여 0에 가까워질 수 있다. 이는 다른 호스트의 데이터가 제대로 전송되지 않음을 의미하며, 실제 네트워크 성능에 큰 영향을 미친다.

• 결론

  • 이 시나리오는 혼잡 상황에서 일부 트래픽이 네트워크의 처리 용량을 초과할 때 다른 트래픽에 미치는 영향을 보여준다.
  • 혼잡 제어 메커니즘이 없는 무제어 재전송은 라우터의 버퍼를 빠르게 채우고 다른 정상적인 트래픽의 전송을 방해하여 네트워크의 전반적인 처리량을 감소시킬 수 있다.

Causes/costs of congestion: insights

1. 처리량과 용량의 한계: 네트워크의 처리량은 네트워크 링크의 용량을 초과할 수 없다. 모든 네트워크 장비는 데이터를 전송할 수 있는 최대 속도(용량)을 가지고 있으며, 이는 물리적인 제약사항에 의해 결정된다.
2. 지연 시간과 용량 접근: 네트워크의 사용량이 그 용량에 근접할수록 지연 시간은 증가한다. 이는 라우터나 스위치의 버퍼에 패킷이 쌓이기 시작함을 의미하며, 버퍼가 가득 차면 패킷이 더 빠르게 처리되지 않고 대기해야 하기 때문이다.
3. 손실과 재전송: 패킷 손실이 발생하면 송신자는 이를 재전송해야 한다. 이는 네트워크의 유효한 처리량을 실제로 감소시키는데, 이미 사용된 대역폭이 재전송된 패킷을 전달하는 데 다시 사용되기 때문이다.
4. 불필요한 중복 패킷: 때때로 재전송된 패킷들이 원래 패킷과 함께 도착하게 되는 경우가 있다(예를 들어, 원래 패킷이 손실되지 않았지만, 타임아웃으로 인해 재전송된 경우). 이러한 불필요한 중복 패킷은 네트워크의 유효 처리량을 더욱 감소시킨다.
5. 상류의 전송 용량 및 버퍼링 낭비: 하류에서 패킷이 손실될 때 상류에서의 전송 용량 및 버퍼링이 낭비된다. 예를 들어, 하류 라우터에서 패킷이 손실되면, 그 패킷을 전송하는 데 사용된 모든 리소스(처리 시간, 대역폭 등)가 헛되이 사용된다.

Approaches towards congestion control

• End-to-End 혼잡 제어
  • 네트워크로부터 명시적인 피드백을 받지 않고, 송신자와 수신자만으로 혼잡을 관리한다.
  • 네트워크의 요소들은 혼잡에 대한 직접적인 피드백을 제공하지 않는다.
  • 송신자는 패킷 손실이나 지연 증가와 같은 현상을 관찰함으로써 네트워크의 혼잡 상태를 추론한다.
  • TCP는 이러한 end-to-end 혼잡 제어 방식을 취하며, 타임아웃과 재전송, 혼잡 윈도우 조절을 통해 혼잡을 관리한다.
• 네트워크 지원 혼잡 제어
  • 라우터와 같은 네트워크 기기가 혼잡에 대한 피드백을 직접 제공한다.
  • 라우터는 혼잡의 정도를 나타내거나 송신 속도를 명시적으로 조절하도록 지시할 수 있다.
  • TCP ECN, ATM, DECbit 프로토콜
    • TCP ECN (Explicit Congestion Notification): ECN은 TCP 헤더의 일부분을 사용하여 네트워크의 혼잡 상태를 명시적으로 알린다. 송신자와 수신자는 이 정보를 사용하여 데이터 전송 속도를 조절할 수 있다.
    • ATM (Asynchronous Transfer Mode): ATM 네트워크는 QoS(Quality of Service) 보장과 혼잡 제어를 위해 연결 지향적인 서비스를 제공한다.
    • DECbit (Digital Equipment Corporation bit): DECbit 프로토콜은 라우터가 패킷 헤더의 특정 비트를 설정하여 네트워크의 혼잡 상태를 송신자에게 알린다.

TCP congestion control: AIMD

• AIMD(Additive Increase Multiplicative Decrease)는 TCP 혼잡 제어 메커니즘 중 하나이다.
• AIMD의 작동 방식은 다음과 같다.

1. Additive Increase (덧셈 증가): 네트워크가 혼잡하지 않다고 간주될 때, TCP 송신자는 자신의 전송률을 점진적으로 증가시킨다. 일반적으로 각 RTT(Round-Trip Time)가 지날 때마다 송신자는 전송률을 하나의 MSS(Maximum Segment Size)만큼 증가시켜 네트워크의 사용 가능한 대역폭을 점진적으로 탐색한다.
2. Multiplicative Decrease (곱셈 감소): 패킷 손실이 감지될 때(예를 들어, 세 개의 중복 ACK을 받는 경우), TCP 송신자는 혼잡이 발생했다고 판단하고 자신의 전송률을 절반으로 줄여 네트워크의 혼잡을 빠르게 완화시킨다.

• AIMD의 시각화
  • AIMD 톱니바퀴 동작: 그래프는 전송률이 시간에 따라 어떻게 변하는지를 톱니바퀴 형태로 보여준다. 전송률이 점진적으로 증가하다가 패킷 손실이 감지되면 급격히 감소하는 패턴을 반복한다. 이는 네트워크의 대역폭을 적극적으로 활용하려는 시도와 혼잡을 감지하면 즉시 대응하는 전략을 나타낸다.

TCP 혼잡 제어의 핵심 요소

1. cwnd (Congestion Window): TCP 송신자는 cwnd라는 혼잡 윈도우를 사용하여 현재 네트워크의 혼잡 상태에 따라 전송할 수 있는 데이터의 양을 결정한다. cwnd는 네트워크의 혼잡 상태를 반영하여 동적으로 조절되며, 혼잡이 감지되지 않을 때는 점진적으로 증가한다.
2. 송신 행동: TCP 송신자는 대략 cwnd 바이트만큼의 데이터를 전송하고, RTT(Round-Trip Time) 동안 ACK(확인 응답)을 기다린 후에 더 많은 데이터를 전송한다.
3. 전송률 계산: TCP의 전송률은 대략적으로 cwnd를 RTT로 나눈 값으로 추정할 수 있다. 이는 초당 전송되는 바이트 수를 나타낸다.
4. 송신 제한: 이미지에 나타난 공식 LastByteSent - LastByteAcked ≤ cwnd는 송신자가 혼잡 윈도우 크기 이내에서만 데이터를 전송해야 함을 나타낸다. 즉, 확인되지 않은 “비행 중인” 데이터의 양은 혼잡 윈도우의 크기를 초과할 수 없다.
5. 시퀀스 번호 공간: 이미지에서는 시퀀스 번호 공간을 보여주고 있으며, 녹색은 확인된 바이트, 노란색은 전송되었지만 아직 확인되지 않은 바이트, 회색은 아직 사용되지 않은 시퀀스 번호를 나타낸다.

---

reference

• TCP 3way handshake, 4way handshake