TCP에러컨트롤

센더가 프레임을 하나 보내고 거기에 별 이상이없으면 리시버가 ack를 하나보냄 그 애크를 확인한후 다음 프레임을 보냄

그리고 그 보낸 프레임도 이상이없으면 애크를 다시 보냄

이때 프레임을 보내고 애크가 올때 까지 스탑하고 웨이트한다고(웨이트 트레이닝? 내가 제일 좋아하는건디 ㅋ) 해서 이런 방식의 프로토콜을 스탑엔 웨이트 ARQ라고함(기본적인 에러컨트롤 프로토콜)

몇번 세그먼트에 에러가 있다는걸 정확하게 알 수 없기 때문에 이런식으로함.

프레임에 에러가 있다면 리시버가 애크를 보내지 않는 방식으로 에러가 있다는것을 알림.

프레임마다 고유의 식별자를 붙혀야함.(식별자 두개만 있으면됨)

리시버가 두개의 식별자를 통해 다 알수있음

애크가 안오면 프레임을 재전송하게됨. 

프레임에서 식별자 0 을 보내면 리시버가 받고 다음 포인터인 1로 받을거다라고 포인팅을 한 후에 애크를 주면 (애크를 1로 보내면 0은 잘받았고 다음번엔 1로 받을걸 기대한다는 것)  애크를 받은 후에 포인터를 1로 바꿈 만약 프레임이 1로 보낼때 1이 오류가 나면 리시버는 해독을 중지 그럼 타이머가 동작하여 일정시간되면 프레임 재전송함 다시 1로 보냄 근데 이번엔 오류가 없으면 다시 애크를 0 으로 보내고 프레임은 포인터를 0으로바꾸고 0으로 프레임을 보내는 식으로 동작함.

근데 여기서 애크가 로스트가 된다면 다시 프레임에서는 원래 보냈던 0을 다시 보내겠지? 그럼 애크가 로스트가 났구나라고 유추할수있음 그래서 또받은 프레임은 DISCARD하고 다시 애크를 보냄 이것이 동작원리!

근데 여기서 보면 저 구간을 하나의 시간이라고 보면 프레임을 보낸 시간은 굉장히 작음 거의 놀고있다는 뜻임 효율이 안좋앙 효율을 좋게하기 위해선 프레임 렝스를 길게하는것도 하나의 방법임 근데 이 프레임 렝스가 너무 길면 무슨 문제가 있냐면 뭔 문제가 있데....

 

센더는 포인터 두개로 작동 프레임 하나가 준비되면 센드 넥스트포인터는 다음 포인터로 이동 센더는 바로 프레임 보냄 이때 프레임 번호는 버퍼의 번호 0을 찍어서보냄 

리시버도 하나의 포인터 가짐 센더가 데이터를 보내면 여기다 저장할거임 이라고 굳게 결심함. 프레임 0의 리시브가 완료되어서 리시버0에 저장이되고 애크를 보냄과 동시에 리시버N을 옆으로 이동 

애크의 수신이 완료된 시점에서는 센더에서 0번에 저장된 데이터가 지워지고 퍼스트 포인터가 오른쪽으로 옮겨짐 

 이 사진에서 회색으로 칠해진 저 칸을 뜻하는 두 선은 윈도우라고하는데 한번에 보낼수있는 프레임의 갯수를 알려줌

갑자기 보낼 데이터가 많아지면 애크를 기다리지 않고 1~7번까지 프레임으로 다보냄 이것이 GO BACK N 프로토콜임

애크가 오는 순서대로 윈도우가 오른쪽으로 슬라이딩됨.

사진에 있는 상황은 3개의 프레임을 보낸상황이고 애크2가 누락된 상황인데 여기서 애크3이 애크2와3을 합친역할을 해줘서 커버 쳐줌 즉 애크3을 받음으로써 프레임 12가 잘받은걸 확인할수있음

 

한번에 보낼수있는 프레임의 수는 2의M승-1개임

최악의 경우는 프레임은 다 잘갔는데 애크가 죄다 망가진 경우! 그런 경우에 우리가 다 프레임을 한번에 보내면 에러남

 

왜 GO BACK N ARQ인 이유?

만약 프레임 1부터7까지 쭉보냈는데 프레임 1에 에러가 나면 그럼 이 리시버는 아무짓도 안하게 설계가됨.

근데 프레임 2가 와도 아무짓도안함 리시버는 프레임1이올때까지 계속 기다림 그래서 1~7다 보내도 애크 하나도 못받고 타임아웃발생하면 프레임 1부터 죄다 다시 보내야함 그래서 GOBACKN임 1번으로 다시 돌아가 이느낌임!

 

TCP에러 컨트롤은 고백N에 기반을 두지만 좀 다름 

비슷한점은

네거티브애크가 없음

만약 1프레임에 대해 애크가없어도 계속 쭉쭉보냄

타임아웃을 통해 잃은걸 찾음

 

다른점은

1번이 올때까지 기다렸다가 순차적으로 보냄

버퍼를 세밀하게 운영 하면서 2번프레임이 들어왔는데 걔의 시작 바이트 넘버가있으면 1번 프레임의 바이트길이는 이정도였겠구나 추론하여서 그만큼 띄워놓고 2번프레임을 그자리에 써놓음(바이트 오리엔티드 넘버링을한다)

TCP는 아이디가 많음 가용한 버퍼스페이스가 제한되지않음(가변적인 버퍼스페이스 사용)

 

애크를 보내는건 두가지 의미가있음

1.니가 보낸 세그먼트를 잘받았다

2. 그걸 내가 잘 처리 완료했다

 

잘받았는데 애크를 안주는경우는 아직 상위레이어로 올리지않아서

 

TCP round trip time, timeout

타임아웃시간을 정하는 핵심 원리는? RTT란 무엇이며 이걸 통하여 시간을 정함

프레임을 보내면 애크를 보내오잖아? 그 애크를 받을때까지의 텀을 RTT(라운드 트립 타임)이라고함

근데 이 RTT는 그때마다 다름 그래서 이걸 어떻게 보정해주지? RTT의 마지막값을 타임아웃으로 정할까?

아니다 여러개를 샘플링해서 최근 RTT를 샘플링해서 평균구함 다만 산술 평균이 아니라 웨이티드 에버리지 구함

최근값에 좀 더 비중을 둠. 최근값이 좀 더 좋잖여~ 거기에 여유분을 더하는데 추정된 RTT에 여유분을 더하는데

타임아웃시간은 추정된 ERTT(추정된 RTT)+여유분

그래서 RTT보다 제법 크게 타임아웃이 결정이됨 하지만 핵심은 RTT에 기반을 둠

 

TCP의 또다른 특징은 

여기서 301을 제대로 받지못하면 DUPLICATE 애크를 보냄 이 듀플이케이트 애크가 NAK(네거티브 애크)같은거임

301못받았다고 야무지게 3번정도 보냄 기대하지않은 넘버들어올때마다 301을 원하니까301을 계속 달라고 보냄

한 3번정도 보내면301 보내줌 이렇게 3개의 듀플리케이티드 애크를 통해 빠르게 재전송을 하는것을 Fast retransmission이라고 함.

두개의 프레임마다 하나의 애크를보냄 이걸 딜레이드 애크라고함

 

윈도우(아까 에러처리할때 배웠징?)의 크기를 조절하는게 tcp에서 해주는중요한일

윈도우로 전송속도제어가능 

윈도우의 크기는 한번에 보낼수있는 세그먼트의 수를 의미 

이때 c는 가상의 파이프가 최대로 보낼수있는 양을 뜻한(최대전송량)

이 c는 정해져있는값 RTT도 정해져있는값 X를 크게하면 전송속도가 빨라짐 작게하면 느려짐

X가 너무 작으면 효율떨어짐 근데 너무 크면 에러가 발생하면 재전송하게되고 여유가 없어서 문제생김 그래서 이 X를 적당한 크기로 정해주는걸 윈도우 컨트롤 이라함 그걸로 우리는 트랜스미션레이트를 컨트롤 할수있음.

센더에서 리시버까지 가상의 파이프를 얼마나 채울것인가!! 적당하게 채우는게 핵심

TCP는 컨트롤을 3개를 하는데 FLOW컨트롤 Congestion 컨트롤 에러컨트롤 근데 여기서 

플로우 컨트롤과 콘제스쳐컨트롤을 한방에 정리할거임!

 

플로우컨트롤:

리시버가 오버로드(처리용량을 넘어서 일을 너무 많이주는것)(쉽게 얘기하면 오래된 스마트폰에 데이터를 많이 넣어주면 버벅거리는것)하는걸 방지하는것 but, 어떻게? 방지하는 주체는 리시버임 리시버가 주체적으로 컨트롤함 센더한테 리시브윈도우(rwnd)(리시버에 가용한 버퍼의 크기)를 알려주는 방법으로 컨트롤함

 

컨제스쳐컨트롤:

네트워크(센더와 리시버 사이의 세그먼트가 지나가는 길 사이에있는 중계장비나 링크를 다 합친 엔티티)가 오버로드하는걸 방지함. 오버로드되는 이유는 외부에서 인풋으로 너무많이 몰리면 오버로드됨. 어떻게 이걸 방지할까?

네트워크의 오버로드 여부를 센더가 결정을함 네트워크가 오버로드 되있다 라고 결론 내리면 콘제스쳐윈도우(cwnd)라고하는 윈도우값을 줄이고 문제없는거라고 결론을 내리면 윈도우값 늘림 윈도우를 늘이고 줄임에따라 데이터보냄 윈도우값크면 많이보내고 적으면 적게보내고 

리시브 윈도우와 컨제스쳐윈도우는 서로 독립적으로 운용을 함.

리시브 윈도우는 리시버 상태에따라 커졌다 작아졌다하고 컨제스쳐윈도우는 네트워크 상태에따라 커졌다 작아졌다 하니까 당연한 말임! 

그런데 TCP가 실제로 사용하는 윈도우는 딱 하나임

min(cwnd,rwnd)값으로 결정이됨 그래서 저 윈도우 사이즈를 w라고하면 w에 맞춰서 세그먼트 한번에 보냄 네트워크는 널널한데 리시버가 버벅대면 w줄여서 안좋은상황에맞춰서 보냄 이것이 TCP윈도우 컨트롤의 핵심임.