네트워크 6.

TCP 세그먼트 구조

순서번호(시퀀스 넘버)

세그먼트에 이쓴 첫 번째 바이트의 바이트 스트림 번호

확인응답 번호(Acknowlefgements)

다른 호스트로 부터 기대하는 다음 바이트의 순서번호

 

텔넷

A -> 순서번호 42 확인응답 79   B

42번 보내고 79달라
A <- 순서번호79  확인응답 43    B

79 보낸다 43 달라

A -> 순서번호 43 확인응답 80   B 

43보낸다 80 달라 이런식

 

TCP의 RTT, timeout

RTT보다 tiemout가 커야한다

너무 짧으면 불필요한 재전송

너무 길면 세그먼트 손실에대한 늦은 반응

 

RTT 측정방법

세그먼트 전송으로부터 ACK수신까지 걸리는 시간 길이

 

EstimatedRTT = (1-a) * EstimatedRTT + a * EstimatedRTT

a값은 0.125

위 식을 통해 일부분식 계속 업데이트 함

 

safety margin(안전마진)

EstimatedRTT에서 큰 변화를 예방하기 위해 safety margin이 필요

 

일반적인 타임아웃 시간

timeoutInterval = EstimatedRTT + 4*DevRTT(saftymargin)

 

DevRTT = EstimatedRTT과 smapleRTT의 편차

DevRTT = (1-b) *DevRTT + b*(sampleRTT - EstimatedRTT)

b = 0.25

 

TCP송신

가장 오래되고 ACK받지 않은 세그먼트를 기준으로 타이머를 잼

 

TCP fast retransmission

타임아웃 전 3개의 같은 ack를 받으면 ack에 대한 정보를 보내줌

 

TCP흐름제어

네트워크 계층으로부터 받는 정보 양과 애플리케시션에서 사용하는 정보양을 조절하는 것

네트워크으 계층의 정보 공급이 너무 빠르다면?

속도를 조절해 수신자의 버퍼가 넘치치 않도록 함

 

수신자는 rwnd필드에 있는 버퍼 빈 공간을 알림

-> 송신자는 rwnd로 향하는 akc되지 않은 데이터 양을 제한

수신자가 버처가 넘치지 않는 것을 보장함

 

TCP 연결 관리

 데이터 교환 전 송수신자가 handskake를 함

2way-handshake

 

반 개방형 연결

2way handshake일 경우

timeout에 의해 의도치 않게 연결이 한쪽만 열리는 현상

복수 데이터 에러

전송지연과 timeout로 인해 같은 값을 여러번 전송

 

2way의 문제를 해결하기 위한 3-way handshake

1. 클라이언트가 서버에 연결 요청

2. 서버가 연결요청을 확인 수락 ack전송

3. 수락 ack에 대한 ack 전송

 

TCP연결 종료

클라이언트 서버가 각각 자신의 연결을 종료

FIN bit = 1인 세그먼트 전송

ack에 대한 fin에 응답

 

혼잡제어

혼잡

너트워크가 처리하기에 너무 많은 데이터를 빠르게 전송하는 소스가 많음

징후

long delays라우터 버퍼에서 대기

packet loss 버퍼가 라우터에서 오버플로우(사라짐)

 

시나리오 무한 버퍼

무한한 버퍼에 지속적으로 값이 들어감

최대 처리량을 넘어서면 무한 대기에 들어감

 

하나의 라우터에 유한 버퍼인 경우

버퍼가 유한하므로 drop되는 패킷이 생기고 이 패킷을 전송자는 재전송 해야함

 

이상화 해결법 라우터 버퍼가 이용 가능할 떄만 전송하기

비현실적

라우터 버퍼가 언제 사용한지 알 수 없음 

재전송이 안일어남

 

이상화  해결법

패킷이 drop될 때를 정확히 알 때

drop될 때만 재전송함

비현실적

송신단은 수신단 상황을 모름

패킷이 일어버려진 것을 알 때만 재전송해함(일부 손해)

 

현실적 시나리오 - 불필요한 중복

패밋이 꽉찬 버퍼 때문에 라우터에서 잃어버려지거나 drop될 수 있음

재전송함

timeout로 인한 불필요한 재전송 발생

이로서 총 loss는 drop로 인한 재전송  + 불필요한 중복 전송으로 인한 loss

중복이 많아지면 처리율이 떨어짐

혼잡의 비용 - 수신자 처리율에 비해 많은 일

 

시나리오 라우터에 2개의 송신자A, B 있을 때

A의 전송량ㅇ이 계속 증가한다면? B의 전송량을 줄어들다 0 이됨 - 제로섬

 

혼잡의 또 다른 비용

패킷이 drop될 때 패킷에서 사용되는 업스트립 전송 욜량과 버퍼링이 낭비됨

 

혼잡

처리율을 전송용량을 초과할 수 없음

전송욜량에 도다할 때 delay증가

손실/재전송은 유효처리율 감소

업스트림 전송용량/ 다운스트림 패킷 손실에 대한 버퍼링 낭비

 

혼잡 제어를 위한 접근 방법

end to end 혼잡제어

네트워크는 혼잡에 대한 명시적인 피드백이 없음

발견된 손실과 지연으로부터 유추해야함

TCP는 이런 유추를 사용한다

 

네트워크 지원 혼잡제어

라우터는 혼잡한 라우터를 통고하는 프름으로 송호신 호스트에 직접적인 피드백을 제공

 

AIMD

송신자는 혼잡이 발생할 때 까지 전송 속도를 증가 시킬 수 있도 손실이 발생하면 속도를 줄임

additive increse : RTT마다 MSS에의한 전송 속도를 1씩 증가

multiplicative decrease : 손실 이벤트 발생 시 송신 속도를 절반으로 감소

하지만 timeout 이후라면 1mss씩 잘라냄

AIMD 톱니행동 서서히 증가하다 반으로 떨어지는 모습

 

cwnd 전송했지만 아직 ack받지않은 값 + 준비되었지마느아직 보내지 않은 값

TCP rate = cwnd / RTT

마지막 전송한 값 - 마지막 ack된 값 <= cwnd

cwnd는 RTT만큼 기다린 후 더 많은 bytes를 전송함

cwnd는 네트워크 혼잡에 대비해 계속 값이 바뀜

 

TCP slow start

첫 번째 손실이 일어날때 까지 rate가 지수적으로 증가함

처음 cwnd는 1

RTT마다 cwnd가 2배로 증가

기하급수적인 증가

지수증가가 선형 증가로 바뀌는 타이밍

ssthresh부터 1씩 증가한다

ssthresh 이전 손실 시점의 절반 시점

 

TCP CUBIC

AIMD의 cwnd 복구가 느린것을 해결하기 위함

wmax 혼잡 손실이 감지된 전송 속도

혼잡 상태가 아마 많이 변환되지는 않을 것을 가정

손실 시wmax의 절반까지 떨어짐

세제곱으로 증가함

리눅스에서 인기있음

bottleneck link CUBIC가 송신 속도를 라우러에서 output가 발생할 때까지 증가시킴

이 bottleneck link에 근접하지만 넘치지는 않게 유지하는 것이 목표

RTTmin 혼잡하지 않은 RTT

cwnd를 고려한 혼잡하지 않은 처리율 = cwnd/RTT

측정된 처리율이 혼잡하지 않은 처리율과 비슷할 때 cwnd를 선형적으로 증가시킴

측정된 처리율이 혼잡하지 않은 처리율과 멀리 떨어진 경우

cwnd를 선형적으로 감소

손실을 유발/강제하지 않고 혼잡제어함

낮은 delay를 유자하는 동안 처리율을 최대화함

구글에서도 쓰는 방법BBR(bottlenexk bandwidth and roudntrip)

 

ECN

네트워크 지원 혼잡제어를 구현

네트워크 라우터에 의해 표시되는 ip헤더에 있는 2개의 bit

목적지는 송신자에게 혼잡을 알리기 위해 ack에 ECE를 추가함

송신자 -> 라우터(해더에 ECN혼잡비트 추가) ->수신자

송신자 <- 라우터  <- 수신자(akc에 ECE추가)

 

공평성

N개의 TCP 세션이 R대역폭의 bottlelinkf를 공유한다면

각각 R/N평균 속도를 가져야함

 

TCP의 경우

공평하다 같은 RTT를 가짐

 

UDP의 경우

일정속도로 송신만하고 패킷 손실도 허용함

공평성 보장 없음

 

병렬 TCP의 경우

추가된 프로세스가 1개만 추가한다 -> 공평

여러개를 추가한다 -> 불공평

 

 QUIC

http성능 향상을 위해 http3부터 udp를 씀

애플리케이션 계층에서 별도의 신뢰성있는 데이터 전송 보안을 해결함

연결설정, 오류제어, 혼잡제어를 하나의 RTT에 해결한다 -> 빠르다