TCP 정체 제어

TCP congestion control

전송 제어 프로토콜(TCP)은 네트워크 혼잡 방지 알고리즘을 사용하여 혼잡 방지를 달성하는데, 여기에는 저속[1] 시작 및 혼잡 창(CWND)을 포함한 다른 계획과 함께 부가적인 증가/증가 감소(AIMD) 방식의 다양한 측면이 포함된다. TCP 혼잡 방지 알고리즘은 인터넷 혼잡 통제를 위한 일차적 기반이다.[2][3][4] 엔드투엔드 원칙에 따르면, 혼잡통제는 대체로 네트워크 자체가 아니라 인터넷 호스트들의 기능이다. 인터넷에 접속하는 컴퓨터의 운영 체제의 프로토콜 스택에서 구현되는 알고리즘의 몇 가지 변형과 버전이 있다.

울혈 붕괴를 피하기 위해 TCP는 다면 혼잡 제어 전략을 사용한다. 각 연결에 대해 TCP는 CNWND를 유지하여 엔드투엔드로 전송될 수 있는 총 승인되지 않은 패킷 수를 제한한다. 이는 흐름 제어에 사용되는 TCP의 슬라이딩 윈도우와 다소 유사하다.

첨가제 증가/증가 감소

가법 증가/증가 감소(AIMD) 알고리즘은 폐쇄 루프 제어 알고리즘이다. AIMD는 혼잡 창문의 선형 성장과 혼잡 발생 시 지수적 감소를 결합한다. AIMD 정체 제어를 사용하는 다중 흐름은 결국 동일한 양의 접선 링크를 사용하기 위해 수렴될 것이다.[5]

이것은 에 설명되어 있는 알고리즘이다. RFC5681은 "혼합 회피" 상태를 위한 것이다.[6]

정체창

TCP에서 혼잡 창(CWND)은 언제든지 보낼 수 있는 바이트 수를 결정하는 요인 중 하나이다. 정체창은 송신자에 의해 유지되며 송신자와 수신자 사이의 연결이 너무 많은 트래픽으로 과부하되는 것을 막는 수단이다. 이는 수신기가 과부하되는 것을 방지하기 위해 존재하는 송신자에 의해 유지되는 슬라이딩 윈도우와 혼동되지 않아야 한다. 정체창은 링크에 정체량이 얼마나 있는지 추정해 계산한다.

연결이 설정되면 각 호스트에서 독립적으로 유지되는 값인 정체 창은 해당 연결에서 허용되는 최대 세그먼트 크기(MSS)의 작은 배수로 설정된다. 정체 창의 추가 분산은 가법 증가/증가 감소(AIMD) 접근법에 의해 결정된다. 즉, 모든 세그먼트가 수신되고 수신확인이 제때에 발신인에게 도달하면 일정 부분 상수가 창 크기에 추가된다는 것을 의미한다. 그것은 다른 알고리즘을 따를 것이다.

시스템 관리자는 TCP 튜닝의 일환으로 최대 창 크기 제한을 조정하거나 가법 증가 시 상수를 조정할 수 있다.

TCP 연결을 통한 데이터 흐름도 수신자가 광고하는 수신 창 사용에 의해 제어된다. 송신자는 자신의 정체 창과 수신 창보다 적은 양의 데이터를 전송할 수 있다.

느린 시작 및 혼잡 방지

"저속 시작" 리디렉션 일본 망가의 경우 느린 시작(망가)을 참조하십시오.

RFC 5681에 의해 정의되는 슬로우 스타트(Slow start)[7]는 TCP가 다른 알고리즘과 연계해 사용하는 정체 제어 전략의 일부로서, 네트워크가 포워딩할 수 있는 것보다 더 많은 데이터, 즉 네트워크 혼잡을 야기하지 않도록 하기 위해 송신할 수 있는 데이터 전송을 회피한다.

느린 시작은 초기 값인 cwnd로 시작하며 2, 3 또는 4 MSS여야 한다.[7] 정체 창 크기에 대한 값은 각 승인(ACK)이 수신될 때마다 1 MSS씩 증가하여 각 RTT당 창 크기를 효과적으로 두 배로 늘릴 수 있다.[a] 또는 그 이하

전송 속도는 패킷 손실이 감지되거나 수신자의 광고된 창(rwnd)이 제한 요인이 될 때까지 느린 시작 알고리즘에 의해 증가될 것이다.

또는 저속 시작 임계값(신속)에 도달하여 저속 시작 또는 정체 방지 알고리즘을 사용하는지 여부를 결정하는 데 사용되며, 이 알고리즘은 저속 시작을 제한하도록 설정된 값이다.

만약 CNWND가 Ssthresh에 도달하면, TCP는 정체 회피 알고리즘으로 변경된다. RTT당 최대 1 MSS까지 증가시켜야 한다.

일반적인 공식은 각각의 새로운 ACK가 MSS * MSS/CWND에 의해 CND를 증가시킨다는 것이다. 그것은 거의 선형적이고 허용 가능한 근사치를 제공한다.

손실 이벤트가 발생하는 경우, TCP는 네트워크 정체 때문이라고 가정하고 네트워크에 제공되는 부하를 줄이기 위한 조치를 취한다. 이러한 측정은 사용되는 정확한 TCP 정체 방지 알고리즘에 따라 달라진다.

TCP 송신자가 재전송 타이머를 사용하여 세그먼트 손실을 감지하고 해당 세그먼트가 재전송 타이머를 통해 아직 재전송 타이머를 통해 재전송되지 않은 경우, ssthresh의 값은 이하의 값으로 설정되어야 한다.

전송되었지만 아직 누적 인정되지 않은 데이터 양의 절반 또는 2 * MSS

TCP 타호
손실이 발생하면 재전송이 전송되고, 현재 CNWND의 절반이 초기 CNWND에서 다시 느린 시작이 시작되는 것으로 저장된다.
TCP 리노
빠른 재전송이 전송되며, 현재 CNWND의 절반은 새 CWND로 저장되므로 느린 시작을 건너뛰고 정체 회피 알고리즘으로 직접 이동한다. 여기서 전체적인 알고리즘을 빠른 복구라고 한다.

느린 시작은 승인되지 않은 세그먼트가 네트워크 정체 때문이라고 가정한다. 이는 많은 네트워크에 대해 허용되는 가정이지만, 데이터 링크 계층 전송 품질 저하와 같은 다른 이유로 인해 세그먼트가 손실될 수 있다. 따라서 느린 출발은 무선 네트워크와 같이 수신 상태가 좋지 않은 상황에서 저조한 성능을 발휘할 수 있다.

저속 시동 프로토콜은 또한 단명 연결에도 좋지 않은 성능을 발휘한다. 이전 웹브라우저는 웹서버에 대한 많은 연속적인 단명 연결을 생성하며, 요청된 각 파일에 대한 연결을 열고 닫을 것이다. 이로 인해 대부분의 연결이 저속 시동 모드로 유지되었고, 이로 인해 응답 시간이 저하되었다. 이러한 문제를 방지하기 위해 최신 브라우저는 여러 연결을 동시에 열거나 특정 웹 서버에서 요청한 모든 파일에 대해 하나의 연결을 재사용한다. 그러나 웹 사이트가 웹 광고, 소셜 네트워킹 서비스의 기능 공유,[8] 웹 분석의 카운터 스크립트 등을 구현하기 위해 사용하는 여러 타사 서버에는 연결을 재사용할 수 없다.

빠른 재전송

빠른 재전송은 손실된 세그먼트를 재전송하기 전에 송신자가 기다리는 시간을 줄이는 TCP의 향상이다. TCP 송신자는 일반적으로 손실된 세그먼트를 인식하기 위해 간단한 타이머를 사용한다. 특정 세그먼트(추정 왕복 지연 시간의 함수)에 대한 승인이 특정 시간 내에 수신되지 않는 경우, 송신자는 해당 세그먼트가 네트워크에서 손실되었다고 가정하고 세그먼트를 재전송한다.

중복 인정은 빠른 재전송 메커니즘의 기본이다. 패킷을 수신한 후, 수신한 데이터의 마지막 순서 바이트에 대한 승인이 전송된다. 주문형 패킷의 경우, 이것은 사실상 마지막 패킷의 시퀀스 번호에 현재 패킷의 페이로드 길이를 더한 것이다. 시퀀스의 다음 패킷이 손실되지만 시퀀스의 세 번째 패킷이 수신되는 경우, 수신자는 첫 번째 패킷에 대해 인식된 값과 동일한 마지막 순서 내 바이트의 데이터만 인식할 수 있다. 두 번째 패킷은 분실되고 세 번째 패킷은 순서가 맞지 않기 때문에 마지막 순서형 데이터 바이트는 이전과 동일하게 유지된다. 따라서 중복 승인이 발생한다. 송신자는 패킷을 계속 송신하고, 네 번째와 다섯 번째 패킷은 수신자에 의해 수신된다. 다시 두 번째 패킷이 시퀀스에서 누락되어 마지막 순서 바이트는 변경되지 않았다. 이 두 패킷 모두에 대해 중복 승인이 전송된다.

송신자가 세 번의 중복된 승인을 받았을 때, 승인에 명시된 마지막 순서 바이트를 따르는 데이터를 운반하는 세그먼트가 손실되었다고 합리적으로 확신할 수 있다. 빠른 재전송을 가진 송신자는 이 패킷의 시간 초과를 기다리지 않고 즉시 재전송한다. 재전송된 세그먼트를 수신할 때, 수신기는 수신한 데이터의 마지막 순서 바이트를 승인할 수 있다. 위의 예에서, 이것은 다섯 번째 패킷의 페이로드의 끝을 인정할 것이다. TCP는 기본적으로 누적 승인을 사용하기 때문에 중간 패킷을 승인할 필요가 없다.

알고리즘

정체 제어 알고리즘(CCAs)의 명명 규칙은 케빈 폴과 샐리 플로이드에 의해 1996년 논문에서 비롯되었을 것이다.[9][failed verification]

다음은 다음 속성에 따른 하나의 가능한 분류다.

  1. 네트워크로부터 받은 피드백의 종류와 양
  2. 현재 인터넷에서 점진적인 배포 가능성
  3. 개선을 목표로 하는 성능 측면: 고대역폭 지연 제품 네트워크 (B), 손실 링크 (L), 공정성 (F), 단선에 대한 장점 (S), 가변 속도 링크 (V), 수렴 속도 (C)
  4. 그것이 사용하는 공정성 기준

일부 잘 알려진 혼잡 방지 메커니즘은 이 계획에 의해 다음과 같이 분류된다.

변종 피드백 필수 변경 사항 혜택들 공정성
(신규) 리노 손실 — — 지연
베가스 지연 보낸 사람 손실은 적게 비례적
고속 손실 보낸 사람 고대역폭
BIC 손실 보낸 사람 고대역폭
큐빅 손실 보낸 사람 고대역폭
C2TCP[10][11] 손실/지연 보낸 사람 초저지연 및 높은 대역폭
NATCP[12] 멀티비트 신호 보낸 사람 거의 최적 성능
탄성-TCP 손실/지연 보낸 사람 높은 대역폭/단거리 및 장거리
애자일-TCP 손실 보낸 사람 높은 대역폭/단거리
H-TCP 손실 보낸 사람 고대역폭
FAST 지연 보낸 사람 고대역폭 비례적
복합 TCP 손실/지연 보낸 사람 고대역폭 비례적
웨스트우드 손실/지연 보낸 사람 L
저지 손실/지연 보낸 사람 L
BBR[13] 지연 보낸 사람 BLVC, Bufferbloat
클램프 멀티비트 신호 수신기, 라우터 V 맥스민
TFRC 손실 보낸 사람, 받는 사람 재전송 금지 최소지연
XCP 멀티비트 신호 발신인, 수신인, 라우터 BLFC 맥스민
VCP 2비트 신호 발신인, 수신인, 라우터 BLF 비례적
맥스넷 멀티비트 신호 발신인, 수신인, 라우터 BLFSC 맥스민
제트맥스 멀티비트 신호 발신인, 수신인, 라우터 고대역폭 맥스민
빨간색 손실 라우터 지연 감소
ECN 단비트 신호 발신인, 수신인, 라우터 감소손실

TCP Tahoe 및 Reno

TCP Tahoe와 Reno 알고리즘은 4.3의 버전이나 향미에서 소급하여 명명되었다.각각이 처음 등장한 BSD 운영 체제(그들 이름은 타호 호수 및 네바다주 리노 인근 도시의 이름을 따서 지었다). 타호 알고리즘은 4.3에서 처음 나타났다.BSD-Tahoe (CCI Power 6/32 "Tahoe" Minicputer를 지원하기 위해 만들어졌으며, 나중에 4.3의 일부로 비 AT&T 면허소지자에게 제공되었다.BSD 네트워킹 릴리스 1; 이것은 광범위한 배포와 구현을 보장한다. 4.3에서 개선되었다.BSD-Reno 및 이후 네트워킹 릴리스 2 및 이후 4.4로 공개됨BSD-Lite.

RTO(재전송 시간 초과)와 중복 ACK를 패킷 손실 이벤트로 간주하지만, Tahoe와 Reno의 동작은 주로 중복 ACK에 대한 반응 방식에 차이가 있다.

  • Tahoe: 3개의 중복 ACK가 수신되는 경우(즉, 데이터에 피기백되지 않고 수신자의 광고 창을 변경하지 않는 동일한 패킷을 인정하는 4개의 ACK) Tahoe는 빠른 재전송을 수행하고, 저속 시작 임계값을 현재 정체 창의 절반으로 설정하며, 정체 창을 1MSS로 줄이고, 저속 시작 s로 재설정한다.테이트의[14]
  • 리노: 중복 ACK가 3회 접수되면, 리노는 빠른 재전송을 실시하고 (타호처럼 1 MSS로 설정하는 대신) 정체 창을 절반으로 줄여 느린 시작 단계를 건너뛰고, 스슈레시를 새로운 정체 창과 동일하게 설정하고, 빠른 복구라는 단계로 진입한다.[15]

Tahoe와 Reno 모두에서 ACK가 시간 초과(RTO 시간 초과)되면 슬로우 스타트(slow start)가 사용되며, 두 알고리즘 모두 정체 창을 1MSS로 줄인다.[citation needed]

TCP 뉴 리노

RFC 6582(RFC 3782 및 RFC 2582의 이전 정의를 생략함)에 의해 정의된 TCP New Reno는 TCP Reno의 빠른 복구 단계 동안 재전송을 개선한다.

빠른 복구 중에 전송 창을 가득 채우기 위해 반환되는 모든 중복 ACK에 대해 정체 창 끝에서 새 전송되지 않은 패킷이 전송된다.

Reno와 다른 점은 New Reno가 다수의 패킷 손실이 발생할 경우 창을 너무 많이 줄일 수 있다는 것이다. 모든 데이터를 승인할 때까지 빠른 복구와 리셋을 하지 않는다.

재전송 후, 새롭게 인정된 데이터는 다음과 같은 두 가지 경우를 가진다.

  • 전체 확인: ACK는 전송된 모든 중간 세그먼트를 인정하며, 새로 고침은 변경할 수 없으며, 새로 고침으로 설정될 수 있음
  • 부분 승인: ACK는 모든 데이터를 인정하지 않는다. 이는 또 다른 손실이 발생할 수 있음을 의미하며, 허용되는 경우 첫 번째 승인되지 않은 세그먼트를 재전송하십시오.

복구에 필요한 데이터의 양을 기록하기 위해 "복구"라는 변수를 사용한다. 재전송 시간 제한 후, 변수 복구에서 전송된 가장 높은 시퀀스 번호를 기록하고, 이 시퀀스 번호가 인정되면 빠른 복구 절차를 종료하고, TCP는 정체 회피 상태로 돌아간다.

뉴 리노에서 패킷 손실이 없지만 대신 패킷이 3개 이상의 패킷 시퀀스 번호로 재주문될 때 문제가 발생한다. 이 경우 뉴르노는 실수로 빠른 회복에 들어간다. 재주문된 패킷이 중복 전달되고 불필요한 재전송이 즉시 전송될 때.

New Reno는 낮은 패킷 오류율에서 SAK만큼의 성능을 발휘하며, 높은 오류율에서 Rno를 크게 능가한다.[16]

TCP 베가스

주요 기사: TCP 베가스

1990년대 중반까지, TCP의 모든 설정 타임아웃과 측정된 왕복 지연은 전송 버퍼에서 마지막으로 전송된 패킷에 기초하였다. 애리조나 대학의 래리 피터슨과 로렌스 브래크모는 타임아웃이 설정되고 전송 버퍼의 모든 패킷에 대해 왕복 지연이 측정되는 TCP 베가스(네바다 최대의 도시 라스베가스의 이름을 따서 명명)를 도입했다. 게다가, TCP 베가스는 혼잡 창문에 첨가된 증가를 사용한다. 다양한 TCP s에 대한 비교 연구에서, TCP Vegas가 TCP 큐빅 다음으로 가장 부드러운 것으로 나타났다.[17]

TCP 베가스는 피터슨의 실험실 외부에 널리 배치되지 않았지만 DD-WRT 펌웨어 v24 SP2의 기본 정체 제어 방법으로 선택되었다.[18]

TCP 하이블라

TCP Hybla는 대기 시간이 높은 지상 또는 위성 라디오 링크를 포함하는 TCP 연결에 대한 페널티를 없애는 것을 목표로 한다. 히블라 개선은 혼잡 창 역학의 해석적 평가에 기초한다.[19]

TCP BIC

주요 기사: BIC TCP

바이너리 증가 정체 제어(BIC)는 LFN(Long Fat Networks)으로 알려진 높은 지연 시간을 가진 고속 네트워크에 최적화된 CCA를 갖춘 TCP 구현이다.[20] BIC는 기본적으로 Linux 커널 2.6.8 ~ 2.6.18에서 사용된다.[citation needed]

TCP 큐빅

주요 기사: 큐빅 TCP

CUBIC는 덜 공격적이고 보다 체계적인 BIC 파생상품으로, 마지막 혼잡 이벤트 이후 시간의 입방 함수로서 이벤트 전 변곡점이 창으로 설정된다. 버전 2.6.19와 3.2 사이의 Linux 커널에서는 기본적으로 큐빅이 사용된다.

애자일-SD TCP

애자일-SD는 실제 리눅스 커널을 위해 설계된 리눅스 기반 CCA이다. 특히 적용된 버퍼 크기가 작을 때, 대응력 인자(AF)라고 하는 새로운 메커니즘을 이용한 손실 기반 접근법을 채용하여, 근거리 네트워크나 광섬유 네트워크와 같은 고속·단거리 네트워크(저-BDP 네트워크)를 통한 대역폭 활용도를 높이는 수신측 알고리즘이다.[21] NS-2 시뮬레이터를 이용한 컴파운드 TCP(MS 윈도 기본 CCA), 큐빅(Linux 기본)과 성능을 비교 평가해 왔다. 평균 처리량 기준으로 총 성능을 최대 55% 향상시킨다.

TCP 웨스트우드+

주요 기사: TCP Westwood 플러스

Westwood+는 유무선 네트워크 모두에 대한 TCP 정체 제어 성능을 최적화하는 TCP Reno의 송신자 전용 수정이다. TCP Westwood+는 혼잡 에피소드, 즉 세 번의 중복 승인 후 또는 시간 초과 후 정체 기간과 저속 시작 임계값을 설정하기 위한 엔드투엔드 대역폭 추정을 기반으로 한다. 대역폭은 수신확인 패킷의 반환 속도를 평균하여 추정한다. 세 번의 중복 ACK 후 맹목적으로 혼잡 창을 절반으로 반반하는 TCP Reno와는 대조적으로, TCP Westwood+는 적응적으로 슬로우 스타트 임계값을 설정하고 혼잡 발생 시 이용 가능한 대역폭의 추정을 고려한 혼잡 창구를 설정한다. 리노와 뉴 리노에 비해 웨스트우드+는 무선 링크에 비해 처리량을 크게 높이고 유선 네트워크의 공정성을 향상시킨다.[citation needed]

복합 TCP

주요 기사: 복합 TCP

컴파운드 TCP는 공정성을 훼손하지 않으면서 LFN에서 좋은 성능을 달성한다는 목표로 두 개의 서로 다른 정체 창을 동시에 유지하는 마이크로소프트의 TCP 구현이다. 마이크로소프트 윈도 비스타와 윈도 서버 2008 이후 윈도 버전에 광범위하게 배치되어 있으며 리눅스뿐 아니라 구 마이크로소프트 윈도 버전에 포팅되어 있다.

TCP 비례 요금 인하

TCP 비례율감소(PRR)[22]는 복구 중 전송되는 데이터의 정확성을 향상시키기 위해 고안된 알고리즘이다. 알고리즘은 복구 후 윈도우 크기가 저속 시작 임계값에 최대한 가깝게 유지되도록 한다. 구글이 수행한 테스트에서 PRR은 평균 지연 시간을 3-10% 단축하고 복구 시간 초과 시간을 [23]5% 단축했다. PRR은 버전 3.2 이후 Linux 커널에서 사용할 수 있다.[24]

TCP BBR

병목 대역폭 및 왕복 전파 시간(BBR)은 2016년 구글에서 개발한 CCA이다.[25] 대부분의 CCA는 패킷 손실에 의존하여 혼잡을 감지하고 전송 속도를 낮춘다는 점에서 손실 기반이지만, BBR은 TCP 베가스와 마찬가지로 모델 기반이다. 알고리즘은 네트워크의 모델을 구축하기 위해 네트워크가 아웃바운드 데이터 패킷의 가장 최근의 비행을 전달했던 최대 대역폭과 왕복 시간을 사용한다. 패킷 전달의 각 누적 또는 선택적 승인은 데이터 패킷의 전송과 패킷의 수신 사이의 시간 간격에 걸쳐 전달된 데이터의 양을 기록하는 속도 샘플을 생성한다.[26] 네트워크 인터페이스 컨트롤러가 초당 메가비트에서 초당 기가비트 성능으로 진화함에 따라, 패킷 손실 대신 버퍼블로와 관련된 지연 시간은 최대 처리량을 나타내는 더 신뢰할 수 있는 마커가 되어 BBR과 같이 더 높은 처리량과 더 낮은 지연 시간을 제공하는 모델 기반 CCA가 더 많은 대중에게 신뢰할 수 있는 대안이 된다.tCP 큐빅과 같은 ar 손실 기반 알고리즘.

BBR은 Linux 4.9 이후 Linux TCP에 사용할 수 있다.[27] 그것은 또한 QUIC에도 이용 가능하다.[28]

BBR 버전 1(BBRv1)은 효율적이고 빠르지만 비 BBR 스트림에 대한 공정성은 논란이 되고 있다. YouTube에서 구현했을 때, BBRv1은 평균 4% 더 높은 네트워크 처리량과 일부 국가에서 최대 14%의 높은 처리량을 보였다.[29] 구글의 발표는 BBRv1이 큐빅과 잘 공존하고 있다는 것을 보여주지만,[25] 제프 휴스턴과 호크, 블레스, 지터바트와 같은 연구원들은 그것이 다른 스트림들에게 불공평하고 확장성이 없다고 생각한다.[30] Hock 외 연구진은 또한 Linux 4.9의 BBR 구현에서 "대기 지연 증가, 불공정, 대규모 패킷 손실과 같은 심각한 내재적 문제들"을 발견했다.[31]

Soheil Abbasloo 외 (C2TCP의 저자)는 BBRv1이 셀룰러 네트워크와 같은 동적 환경에서 잘 수행되지 않는다는 것을 보여준다.[10][11] 그들은 또한 BBR이 불공평한 이슈를 가지고 있다는 것을 보여주었다. 예를 들어, 큐빅 흐름(Linux, Android 및 MacOS의 기본 TCP 구현)이 네트워크에서 BBR 흐름과 공존할 때, BBR 흐름이 큐빅 흐름을 지배하고 그 흐름으로부터 전체 링크 대역폭을 얻을 수 있다(의 그림 16 참조).

버전 2는 큐빅과 같은 손실 기반 정체 관리와 함께 운영될 때 불공정한 문제를 다루려고 시도한다.[32] BBRv2에서 BBRv1이 사용하는 모델은 패킷 손실에 대한 정보와 ECN의 정보를 포함하도록 증강된다. BBRv2는 때때로 BBRv1보다 처리량이 낮을 수 있지만, 일반적으로 더 좋은 처리량을 가진 것으로 간주된다.

C2TCP

셀룰러 제어 지연 TCP(Cellular Controlled Delay TCP, C2TCP)[10][11]는 네트워크 기기의 변경을 요구하지 않고 서로 다른 어플리케이션에 대한 다양한 QoS 요구사항을 만족시킬 수 있는 유연한 엔드투엔드 TCP 접근방식이 없었기 때문에 동기부여가 되었다. C2TCP는 현재 LTE와 미래 5G 셀룰러 네트워크 등 고도로 역동적인 환경에서 가상현실, 화상회의, 온라인게임, 차량통신 시스템 등 애플리케이션의 초저지연 및 고대역폭 요구사항을 만족시키는 것을 목표로 하고 있다. C2TCP는 손실 기반 TCP 위에 추가 기능(예: Reno, NewReno, CIVIC, BIC, ...), 서버 측에만 설치하면 되고, 애플리케이션이 설정한 원하는 지연에 바인딩된 패킷의 평균 지연을 만든다.

NYU의[33] 연구원들은 C2TCP가 다양한 최첨단 TCP 체계의 지연 및 지연분산 성능을 능가한다는 것을 보여주었다. 예를 들어, 그들은 평균적으로 BBR, 큐빅, 웨스트우드에 비해, C2TCP는 다양한 무선 네트워크 환경에서 패킷의 평균 지연을 각각 약 250%, 900%, 700% 감소시킨다는 것을 보여주었다.[10]

탄성-TCP

Elastic-TCP는 클라우드 컴퓨팅을 지원하기 위해 고BDP 네트워크에 대한 대역폭 활용도를 높이기 위해 2019년 2월에 제안되었다. 리눅스 커널용으로 설계된 리눅스 기반 CCA이다. 윈도 관련 가중 함수(WWF)라고 하는 새로운 메커니즘을 이용한 손실 지연 기반 접근법을 채용하는 수신측 알고리즘이다. 인적 튜닝 없이도 서로 다른 네트워크 특성을 다룰 수 있는 탄력성이 높다. NS-2 시뮬레이터와 테스트베드를 이용해 컴파운드TCP(MS 윈도 기본 CCA), 큐빅(Linux 기본), TCP-BR(구글이 사용하는 Linux 4.9 기본)과 성능을 비교해 평가받았다. 탄성-TCP는 평균 처리량, 손실 비율 및 지연 측면에서 총 성능을 크게 향상시킨다.[34]

NATCP

Soheil Abbasloo 외.는 NATCP(Network-Assisted TCP)[12]에 MEC(Multi-access edge Computing)를 대상으로 한 논란의[according to whom?] TCP 설계를 제안했다. NATCP의 핵심 아이디어는 네트워크의 특성이 사전에 알려져 있었다면 TCP는 다르게 설계되었을 것이라는 점이다. 따라서 NATCP는 현재 MEC 기반 셀룰러 아키텍처에서 사용 가능한 특징과 속성을 사용하여 TCP의 성능을 최적 성능에 가깝게 한다. NATCP는 네트워크의 Out-of-Band 피드백을 근처에 위치한 서버에 사용한다. 셀룰러 접속 링크의 용량과 네트워크의 최소 RTT를 포함하는 네트워크로부터의 피드백은 서버들의 송신 속도를 조절하도록 안내한다. 예비 결과에서 알 수 있듯이 NATCP는 최신 TCP 체계를 능가한다.[12][35]

기타 TCP 정체 방지 알고리즘

TCP New Reno는 가장 일반적으로 구현된 알고리즘이며,[citation needed] SAK 지원은 매우 일반적이며[citation needed], Reno/New Reno로 확장된 것이다. 다른 대부분의 제안들은 아직 평가가 필요한 경쟁적인 제안들이다. 2.6.8로 시작한 리눅스 커널은 기본 구현을 뉴 리노에서 BIC로 전환했다. 디폴트 이행은 2.6.19 버전에서 다시 큐빅으로 변경되었다. FreeBSD는 New Reno를 기본 알고리즘으로 사용한다. 하지만, 그것은 다른 많은 선택들을 지원한다.[46]

대기열 방식과 관계없이 대역폭과 지연 시간의 흐름당 산출물이 증가하면 TCP는 비효율적이 되어 불안정해지기 쉽다. 이것은 인터넷이 매우 높은 대역폭의 광학 링크를 포함하도록 진화함에 따라 점점 더 중요해지고 있다.

TCP Interactive(iTCP)[47]는 애플리케이션이 TCP 이벤트에 가입할 수 있도록 하고 그에 따라 대응함으로써 외부 TCP 계층에서 TCP로의 다양한 기능 확장을 가능하게 한다. 대부분의 TCP 혼잡 체계는 내부적으로 작동한다. iTCP는 또한 소스의 발생률을 제어하는 것과 같은 혼잡 통제에 고급 응용 프로그램들이 직접 참여할 수 있게 한다.

제타-TCP는 대기 시간과 손실률 측정에서 모두 정체를 감지한다. 굿풋 제타-TCP를 극대화하고 혼잡 가능성에 기반한 다른 혼잡 창 역오프 전략을 적용한다. 또한 패킷 손실을 정확하게 감지하여 재전송 시간 제한 재전송을 피하고 인바운드(다운로드)[48] 트래픽을 가속 및 제어하는 다른 개선사항도 가지고 있다.

네트워크 인식별 분류

CCA는 네트워크 인식과 관련하여 분류될 수 있으며, 이는 이러한 알고리즘이 네트워크 상태를 인지하는 정도를 의미한다. 이것은 블랙박스, 그레이박스, 그린박스 등 3가지 주요 범주로 구성된다.[49]

블랙박스 알고리즘은 맹목적인 혼잡 조절 방법을 제공한다. 그것들은 정체 시 수신되는 이진 피드백에서만 작동하며, 그들이 관리하는 네트워크의 상태에 관한 어떠한 지식도 가정하지 않는다.

회색 상자 알고리즘은 대역폭, 흐름 경합 및 기타 네트워크 상태에 대한 지식을 측정 및 추정하기 위해 시간 인자를[clarification needed] 사용한다.

그린 박스 알고리즘은 시스템 실행 중 어떤 시점에서든 각 흐름에 할당되어야 하는 총 대역폭의 공정한 몫을 측정하는 양방향 혼잡 제어 방법을 제공한다.

블랙박스

  • 고속-TCP[50]
  • BIC TCP(Binary Increment Blooming Control Protocol)는 네트워크가 완전히 이용되는 시간을 극대화하기 위해 창문이 사건 이전과 같을 때까지 각 정체 사건 후 발생원 비율의 오목한 증가를 사용한다. 이후 공격적으로 조사한다.
  • 큐빅 TCP – 창이 마지막 혼잡 이벤트 이후 시간의 입방 함수인 BIC의 덜 공격적이고 더 체계적인 파생 모델이며, 변곡점은 이벤트 전에 윈도우로 설정된다.
  • AIMD-FC(급속 수렴에 따른 부가적 증가 승수 감소), AIMD의 개선.[51]
  • 이항 메커니즘
  • SIMD 프로토콜
  • 가이미드

그레이 박스

  • TCP Vegas – 대기열 지연을 추정하고, 흐름당 일정한 패킷 수가 네트워크에서 대기하도록 창을 선형적으로 늘리거나 줄인다. 라스베가스는 비례적 공정성을 구현한다.
  • FAST TCP – 라스베가스와 동일한 평형을 이루지만 선형 증가 대신 비례적 제어를 사용하고, 안정성을 보장하기 위해 대역폭이 증가함에 따라 의도적으로 이득을 축소한다.
  • TCP BBR – 대기열 지연을 추정하지만 지수 증가를 사용한다. 공정성을 위해 의도적으로 주기적으로 속도를 늦추고 지연 시간을 줄인다.
  • TCP-Westwood(TCPW) – 손실 때문에 창이 대역폭 지연 제품에 대한 송신자의 추정치(가장 작은 측정 RTT에 관측된 ACK 수신 속도를 곱한 값)로 재설정된다.[52]
  • C2TCP[11][10]
  • TFRC[53]
  • TCP-Real
  • TCP-제르시

그린박스

  • 바이모달 메커니즘 – 바이모달 혼잡 방지 및 제어 메커니즘.
  • 라우터에 의해 구현된 신호 방식
  • 네트워크 지원 정체 제어
    • NATCP[12] - Network-Assisted TCP는 네트워크의 최소 RTT와 셀룰러 액세스 링크의 용량을 나타내는 대역 외 명시적 피드백을 사용한다.
    • VCP – 가변 구조 정체 제어 프로토콜(VCP)은 두 개의 ECN 비트를 사용하여 네트워크 정체 상태를 명시적으로 피드백한다. 그것은 또한 엔드 호스트측 알고리즘을 포함한다.

TCP 패킷 구조에 사용자 정의 필드를 추가해야 하는 알고리즘은 다음과 같다.

  • 명시적 제어 프로토콜(XCP) – XCP 패킷은 피드백 필드가 있는 정체 헤더를 운반하여 송신자의 정체 창의 증가 또는 감소를 나타낸다. XCP 라우터는 효율성과 공정성을 위해 피드백 값을 명시적으로 설정한다.[54]
  • MaxNet – MaxNet은 흐름의 경로에 있는 라우터의 최대 정체 수준을 전달하는 단일 헤더 필드를 사용한다. 이 비율은 이 최대 혼잡의 함수로 설정되어 최대-최소 공정성을 초래한다.[55]
  • JetMax – JetMax는 MaxNet과 마찬가지로 최대 정체 신호에만 반응하지만 다른 오버헤드 필드도 운반한다.

Linux Usage

  • BIC는 Linux 커널 2.6.8 ~ 2.6.18에서 기본적으로 사용된다. (2004년 8월 ~ 2006년 9월)
  • CIVICE는 버전 2.6.19 이후 Linux 커널에서 기본적으로 사용된다. (2006년 11월)
  • PRR은 Linux 커널에 통합되어 버전 3.2 이후 손실 복구 개선(2012년 1월)
  • BBR은 Linux 커널에 통합되어 버전 4.9(2016년 12월) 이후 모델 기반 정체 제어를 가능하게 한다.

참고 항목

메모들

  1. ^ 실제로 수신기가 ACK를 지연시킬 수 있더라도, 일반적으로 수신자가 수신하는[2] 두 세그먼트당 하나의 ACK를 전송한다.

참조

  1. ^ 제이콥슨 & 카렐스 1988.
  2. ^ a b W. Stevens (January 1997). TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. doi:10.17487/RFC2001. RFC 2001.
  3. ^ M. Allman; S. Floyd; C. Partridge (October 2002). Increasing TCP's Initial Window. doi:10.17487/RFC3390. RFC 3390.
  4. ^ "TCP Congestion Avoidance Explained via a Sequence Diagram" (PDF). eventhelix.com.
  5. ^ Chiu, Dah-Ming; Raj Jain (1989). "Analysis of increase and decrease algorithms for congestion avoidance in computer networks". Computer Networks and ISDN Systems. 17: 1–14. CiteSeerX 10.1.1.136.8108. doi:10.1016/0169-7552(89)90019-6.
  6. ^ Allman, M.; Paxson, V. (September 2009). TCP Congestion Control. IETF. sec. 3.1. doi:10.17487/RFC5681. RFC 5681. Retrieved 4 March 2021.
  7. ^ a b Blanton, Ethan; Paxson, Vern; Allman, Mark (September 2009). "TCP Congestion Control". {{cite journal}}: Cite 저널은 필요로 한다. journal= (도움말)
  8. ^ 닉 오닐 "사이트를 느리게 만드는 이유는? Be The Like Button"이 될 수도 있다. 2010년 11월 10일 AllFacebook. 2012년 9월 12일에 검색됨
  9. ^ Fall, Kevin; Sally Floyd (July 1996). "Simulation-based Comparisons of Tahoe, Reno and SACK TCP" (PDF). Computer Communications Review. 26 (3): 5–21. CiteSeerX 10.1.1.586.2403. doi:10.1145/235160.235162. S2CID 7459148.
  10. ^ a b c d e f Abbasloo, S.; Xu, Y.; Chao, H. J. (2019). "C2TCP: A Flexible Cellular TCP to Meet Stringent Delay Requirements". IEEE Journal on Selected Areas in Communications. 37 (4): 918–932. arXiv:1810.13241. doi:10.1109/JSAC.2019.2898758. ISSN 0733-8716. S2CID 53107038.
  11. ^ a b c d Abbasloo, S.; Li, T.; Xu, Y.; Chao, H. J. (May 2018). "Cellular Controlled Delay TCP (C2TCP)". 2018 IFIP Networking Conference and Workshops: 118–126. arXiv:1807.02689. Bibcode:2018arXiv180702689A. doi:10.23919/IFIPNetworking.2018.8696844. ISBN 978-3-903176-08-9. S2CID 49650788.
  12. ^ a b c d 아바스루 외 2019년.
  13. ^ Cardwell, Neal; Cheng, Yuchung; Gunn, C. Stephen; Yeganeh, Soheil Hassas; Jacobson, Van (2016). "BBR: Congestion-Based Congestion Control". Queue. 14 (5): 20–53. doi:10.1145/3012426.3022184. Retrieved 6 December 2016.
  14. ^ 쿠로즈 & 로스 2008 페이지 284.
  15. ^ 쿠로즈 & 로스 2012, 페이지 277.
  16. ^ VasanthiN., V.; SinghM., Ajith; Kumar, Romen; Hemalatha, M. (2011). Das, Vinu V; Thankachan, Nessy (eds.). "Evaluation of Protocols and Algorithms for Improving the Performance of TCP over Wireless/Wired Network". International Conference on Computational Intelligence and Information Technology. Communications in Computer and Information Science. Springer. 250: 693–697. doi:10.1007/978-3-642-25734-6_120. ISBN 978-3-642-25733-9.
  17. ^ "Performance Analysis of TCP Congestion Control Algorithms" (PDF). Retrieved 26 March 2012.
  18. ^ "DD-WRT changelog". Retrieved 2 January 2012.
  19. ^ "Archived copy". Archived from the original on 11 October 2007. Retrieved 4 March 2007.{{cite web}}: CS1 maint: 타이틀로 보관된 사본(링크)
  20. ^ V., Jacobson; R.T., Braden. TCP extensions for long-delay paths. doi:10.17487/RFC1072. RFC 1072.
  21. ^ Alrshah, M.A.; Othman, M.; Ali, B.; Hanapi, Z.M. (September 2015). "Agile-SD: A Linux-based TCP congestion control algorithm for supporting high-speed and short-distance networks". Journal of Network and Computer Applications. 55: 181–190. doi:10.1016/j.jnca.2015.05.011. S2CID 2645016.
  22. ^ "Proportional Rate Reduction for TCP". Retrieved 6 June 2014.
  23. ^ Corbet, Jonathan. "LPC: Making the net go faster". Retrieved 6 June 2014.
  24. ^ "Linux 3.2 - Linux Kernel Newbies". Retrieved 6 June 2014.
  25. ^ a b "BBR: Congestion-Based Congestion Control". Retrieved 25 August 2017.
  26. ^ Cheng, Yuchung; Cardwell, Neal; Yeganeh, Soheil Hassas; Jacobson, Van. "Delivery Rate Estimation". Retrieved 25 August 2017. {{cite journal}}: Cite 저널은 필요로 한다. journal= (도움말)
  27. ^ "BBR congestion control [LWN.net]". lwn.net.
  28. ^ "BBR update". datatracker.ietf.org.
  29. ^ "TCP BBR congestion control comes to GCP – your Internet just got faster". Retrieved 25 August 2017.
  30. ^ "TCP and BBR" (PDF). Retrieved 27 May 2018.
  31. ^ "Experimental Evaluation of BBR Congestion Control" (PDF). Retrieved 27 May 2018.
  32. ^ "A Performance Evaluation of TCP BBRv2". Retrieved 12 January 2021.
  33. ^ "Cellular Controlled Delay TCP (C2TCP)". wp.nyu.edu. Retrieved 27 April 2019.
  34. ^ Alrshah, M.A.; Al-Maqri, M.A.; Othman, M. (June 2019). "Elastic-TCP: Flexible Congestion Control Algorithm to Adapt for High-BDP Networks". IEEE Systems Journal. 13 (2): 1336–1346. arXiv:1904.13105. Bibcode:2019ISysJ..13.1336A. doi:10.1109/JSYST.2019.2896195.
  35. ^ Abbasloo, Soheil (3 June 2019), GitHub - Soheil-ab/natcp, retrieved 5 August 2019
  36. ^ Yuan, Cao; Tan, Liansheng; Andrew, Lachlan L. H.; Zhang, Wei; Zukerman, Moshe (6 June 2008). "A generalized FAST TCP scheme". Computer Communications. 31 (14): 3242–3249. doi:10.1016/j.comcom.2008.05.028. hdl:1959.3/44051.
  37. ^ a b "Rice Networks Group".
  38. ^ "TCP Veno: TCP Enhancement for Transmission over Wireless Access Networks" (PDF). IEEE Journal on Selected Areas in Communication.
  39. ^ "XCP @ ISI".
  40. ^ "High speed TPC" (PDF). www.csc.lsu.edu.
  41. ^ "Archived copy". Archived from the original on 3 April 2011. Retrieved 5 March 2011.{{cite web}}: CS1 maint: 타이틀로 보관된 사본(링크)
  42. ^ Benaboud, H.; Berqia, A.; Mikou, N. (2002). "An analytical study of CANIT algorithm in TCP protocol". ACM SIGMETRICS Performance Evaluation Review. 30 (3): 20. doi:10.1145/605521.605530. S2CID 6637174.
  43. ^ Rouhani, Modjtaba (2010). "Nonlinear Neural Network Congestion Control Based on Genetic Algorithm for TCP/IP Networks". 2010 2nd International Conference on Computational Intelligence, Communication Systems and Networks. pp. 1–6. doi:10.1109/CICSyN.2010.21. ISBN 978-1-4244-7837-8. S2CID 15126416.
  44. ^ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Roy, Abhishek; Saxena, Navrati (January 2018). "D-TCP: Dynamic TCP congestion control algorithm for next generation mobile networks". 2018 15th IEEE Annual Consumer Communications Networking Conference (CCNC): 1–6. doi:10.1109/CCNC.2018.8319185.
  45. ^ Kanagarathinam, Madhan Raj; Singh, Sukhdeep; Sandeep, Irlanki; Kim, Hanseok; Maheshwari, Mukesh Kumar; Hwang, Jaehyun; Roy, Abhishek; Saxena, Navrati (2020). "NexGen D-TCP: Next Generation Dynamic TCP Congestion Control Algorithm". IEEE Access. 8: 164482–164496. doi:10.1109/ACCESS.2020.3022284. ISSN 2169-3536.
  46. ^ "Summary of Five New TCP Congestion Control Algorithms Project".
  47. ^ "iTCP - Interactive Transport Protocol - Medianet Lab, Kent State University".
  48. ^ "Whitepaper: Zeta-TCP - Intelligent, Adaptive, Asymmetric TCP Acceleration" (PDF). Retrieved 6 December 2019.
  49. ^ Lefteris Mamatas; Tobias Harks; Vassilis Tsaoussidis (January 2007). "Approaches to Congestion Control in Packet Networks" (PDF). Journal of Internet Engineering. 1 (1). Archived from the original (PDF) on 21 February 2014.
  50. ^ "HighSpeed TCP". www.icir.org.
  51. ^ "AIMD-FC Homepage". neu.edu. Archived from the original on 13 January 2009. Retrieved 13 March 2016.
  52. ^ "Welcome to Network Research Lab". www.cs.ucla.edu.
  53. ^ "Equation-Based Congestion Control for Unicast Applications". www.icir.org.
  54. ^ Katabi, Dina; Handley, Mark; Rohrs, Charlie (2002). "Congestion control for high bandwidth-delay product networks". Proceedings of the 2002 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications - SIGCOMM '02. New York, New York, USA: ACM Press: 89. doi:10.1145/633025.633035. ISBN 1-58113-570-X.
  55. ^ "MaxNet -- Max-Min Fair, Stable Explicit Signalling Congestion Control". netlab.caltech.edu.

원천

외부 링크