[ 컴퓨터 네트워크 / Computer Network ] 이론 4주차

1.  FLOW CONTROL 을 위해 WINDOW SIZE 가 변하는 과정을 지켜보자

2.  ACK 에 관한 몇가지 이슈

206

207

208

209

210

211

212

213

214

206 - 214 까지 데이터를 보냈다. 그런데 ACK 이 210, 그리고 WINDOW SIZE = 4 왔다

.....???

206

207

208

209

210

211

212

213

214

.....다시 보낸다. N 은 줄어들었고 ( Shrunking ) 데이터는 다시 보내줘야한다.

왜 이런일이 일어났는가 ?

Time Delay 때문이다. 내가 보고 이만큼이구나 해서 보낸 N 은 지금 이 순간 수신자의 N이 아닌 이전 단계에 미리 보내져 있던 N 이기 때문이다. 완벽한 실시간 통신이 아니기 때문에 Time Delay 가 있고 이로인해서 가끔 발생 할 수도 있는 문제이다.

3. Silly Window Syndrome

보낼 데이터량보다 헤더의 크기가 더 큰 비효율적인 상황들을 해결하고자 하는 데서 생기는 문제들과 그 해결법

내가 1바이트 짜리 문자 하나를 보낸다고 해도, TCP/IP 가 헤더로 못해도 40바이트 이상을 
사용하게 되는데 이는 비효율적이다.

이것을 해결하는 가장 쉬운 방법은 모아서 한번에 보내는 것으로 이에대한 이야기들을 다룬다.

A. Nagle 알고리즘 ( 송신측 )

모아서 한번에 보내면 비효율을 해결할 수 있다. 라는 아이디어에서 시작된것으로

간단한 몇가지 조건만을 만족하면된다.

- 처음 출발하는 데이터는 무조건 그냥 출발한다 ( 통신 연결 후 첫 데이터 )

- 그 다음부터의 데이터는 아래의 두가지 룰을 한 가지라도 만족하면 출발한다.

1. MSS ( Maximum Segment Size ) 

Segment 에 들어갈 수 있는 최대 사이즈 만큼 데이터가 모인다면 출발한다.

2. 이전 단계에서 출발했던 데이터의 ACK이 오면 최대 사이즈 만큼 모이지 않았어도 출발한다.
    ( 더 기다리면 어플리케이션의 성능에 영향을 미칠 수 있기 때문 )

B. Clark 의 해결법과 ACK 차단 방법 ( 수신측 )

만일 어플리케이션이 아주 작은 양의 바이트만을 사용 한다면 ??

아무짓도 안한다면 rwnd = 1 이런데도 그냥 이걸 송신측에 정보를 전달할 것이고, 그럼

송신측에선 이 1바이트에 헤더를 덕지덕지 붙여서는 송신을 해올 것이다. 이러한 비효율을 막아내기 위해서 두가지 방법이 있다.

- Clark 의 해결법

아예 rwnd가 충분히 크지 않다면 그냥 rwnd = 0 이다 라고 보내버리는 법이다.
rwnd 가 충분히 커질 때 까지 ( 한 패킷을 만들 정도로 ) rwnd = 0 이라고만 보낸다.

- ACK 차단

아예 ACK 을 안보내버리는 방법으로 송신측은 내가 보낸 데이터가 갔는지 안갔는지,

이제 WINDOW SIZE가 어느정도인지 알 방법은 ACK 밖에 없는데 이 ACK 가 오지않으니
아무것도 못한채 그저 기다리기만 할것이다. 충분한 빈 공간이 생겼을 때 ACK 을 다시 보내준다.

이 방법은 Delay 의 존재에 의해서 조금더 수신이 들어 올 수 는 있다. 하지만 조금 시간이

지나면 ACK 을 보내지 않았으므로, 더이상 송신이 오지 않을 것이다.

4. ERROR CONTROL 신뢰성 부분에 대한 이슈

- ACK 에 대한 ACK 은 존재하지 않는다.

- Read 를 하면 TCP 는 온전한 순서가 완성된 것들만 올려준다.

1

2

-

4

5

이런식으로 현재 데이터를 받아놨다면 1, 2 만 올려보내고 나머진 3이 들어올때까지 대기한다!

-TCP 는 순서대로 하는 것을 좋아해 !

- TCP 는 삼진아웃을 좋아해

  원래 내가 이미 보낸 데이터에 대해서 다시 달라고 요청이 온다고 바로 주는게 아니고

  충분한 시간을 WAIT 한 다음에 그래도 안왔다고 하면 다시 보내주는 것이 원칙이다.

  왜냐하면 어떠한 문제로 인해 아직 도달하지 못했을 뿐인 경우도 있기때문이다.

  하지만 3번 중복되서 재요청 ( ACK ) 이 돌아오면, TIME WAIT 으로 간주하고,
  바로 재전송을해준다.

- TCP 는 그러려니 하는 것을 좋아해

  송신측이 보냈던 것에 대한 ACK 을 제대로 받지 못했다 하더라도 그 다음에 오는 ACK 이 이후 데이터를 잘 받았다 라고 오면, 그 전에 받은것은 잘 받았겠지 하고 넘어가는 것

5. 잃어버린 ACK 가 일으키는 데드락을 해결하자

- 수신 측이 수신을 하고 rwnd = 0 이라고 다시 송신측으로 보내주면 송신측은 wait 를 시작한다.

  이후 수신측이 rwnd = n 이라고 보냈는데 이게 문제 때문에 송신측 까지 도달하지 못할경우

송신도 수신도 무한히 wait 만 하게된다.

해결법으로는 넘겨받은 rwnd 가 0 일겨웅엔 주기적으로 아직도 rwnd = 0 이냐고 재확인을 하게한다.