CH3 : Transport Layer (4)

* 이 글에 관련된 모든 내용은 Computer Networking A Top-Down Approach 7th에서 가져온 내용이다. *

 

Reliable Data Transfer

---

- TCP는 SR ARQ방식과 비슷한 매커니즘을 사용한다.

그러나 SR처럼 WS를 정해놓지 않고 이 WS는 dynamic하게 변한다. 이때 이 WS는 flow control과 congestion control의 영향을 받는다.

- cumulatvie ACK을 사용하고 다음에 받아야할 seq num을 보낸다

예를 들어 현재 seq num 1000번까지의 데이터를 받았다면 ack(1001)을 보낸다.

- 재전송을 지원한다.

timeout이 일어나면 재전송을 하는데 이때 이미 온 ACK에 대해서 똑같은 ACK이 3번오게되면 timeout이 발생하지 않아도 재전송을 한다. (three duplicaiton ACKs에 의한 fast transmission)

fast retransmission 예제

 

Delayed ACK : piggyback on ACK on data

segment를 받은 receiver는 해당 seq number에 해당하는 ACK을 보낸다. 그러나 메시지에 ACK의 번호, 즉 헤더만 보내기엔 너무 비효율적이고 아깝기 때문에 reciever쪽에서도 보낼 데이터가 있다면 같이 보내는게 좋다. 그래서 receiver는 ACK을 보낼때 같이 보낼 데이터가 있는지 없는지 살짝 기다린 후에 있다면 같이보내고 없다면 그냥 보낸다.

 

 

 

Flow Control

---

receiver의 buffer에서 overflow가 발생하는 것을 막는 것이 목표이다.

 

receiver는 현재 자신의 buffer에서 사용가능한 window size를 sender에게 알려준다.

sender는 receiver에게 받은 window size이상의 데이터를 전송하지 않는다.

때문에 receiver의 buffer에 application layer로 넘겨주지 못한 데이터들이 점점 차도 overflow가 나지 않는다.

 

Q. 현재 receiver의 buffer가 꽉차있는 상태이고 sender는 receiver로부터 window size가 0이라고 메시지를 받은 상태이다. 그런데 만약 이상태에서 receiver의 buffer에 여유공간이 생겼고 receiver는 그 사실을 sender에게 보내주려하는데 만약 이 패킷이 loss가 나게되면 어떡할까? (window size에 대한 정보는 header이기 때문에 header에 대한 재전송은 없다)

 

위 문제에 대한 답은 뒤에서 차근차근 설명한다.

 

Transmission Policy

---

TCP에는 Tinygram이라는 문제가 있다. 

실제 전송해야할 데이터의 크기가 1B라면 헤더사이즈는 TCP 헤더사이즈 20byte + IP 헤더사이즈 20byte (배울 예정)이므로 아무리 작아도 40byte이다. 총 데이터의 길이는 41byte인데 그 중 헤더만 40byte인것이다. 이는 효율적인 측면에서 매우 안좋다.

그렇다면 데이터를 모아서 보내면 되지 않을까?

 

사람이 화면에 타이핑을 치고있다고 가정해보자.

내가 키를 하나하나 누를 때마다 tinygram이 발생하고 내가 치는 것을 그때그때 마다 화면에 띄우기 위해서는 1byte임에도 불구하고 계속 전송을 해야 할 것이다.

만약 이 tinygram들을 모아서 보낸다면 내가 지금 치고있는 글자들이 바로바로 화면에 나타나지 않고 몇개씩 뭉쳐서 완성이된 이후에 나타날 것이다. 

 

이러한 상황을 막고자 Nagle's algorithm이 등장했다.

 

Nagle's algorithm

1. 우선 첫번째 byte는 tinygram으로 한다. (그냥 보낸다) 그리고 그 다음부터는 첫번째 보낸 byte에 대한 ACK이 올때까지 buffer에 저장한다.

2. data가 WS의 반이상이거나 maximum segment 사이즈가 되면 그냥 보낸다.

 

이렇게 되면 어느정도 해결할 수 있다

 

하지만 요즘은 이 알고리즘을 disabled시킨다.

마우스를 쓰는 환경에서 여러 부분을 클릭했는데 그 정보를 모아놨다가 한번에 보내면 매우 많은 문제가 생기기때문이다.

 

 

TCP Timers

---

TCP에는 4개의 타이머가 있다.

 

1. Retransmission timer

ARQ매커니즘을 위해 재전송시간을 재기위한 타이머

 

2. Persistent timer

아까 위에서 window size가 0이라고 sender에게 보냈는데 그 패킷이 로스가나면 어떻게 할지 설명하겠다고 했었다.

persistent timer는 이때 사용된다.

3.  Keep-alive timer

sender와 receiver가 맺은 TCP connection에서 아무런 정보가 흐르고 있지 않고 있다면 그것은 곧 낭비일 것이다. 때문에 keep-alive timer를 두어 일정시간동안 둘 사이에 정보가 흐르지 않으면 probe packets을 75초 간격으로 10번 보내고 이것에 대해서도 응답이 없으면 connection을 없앤다. 

보통 keep-alive time은 2시간이다.

 

4. 2MSL(Maximum Segment Lifetime) timer

커넥션을 release하기전에 이전에 loss가 났던 패킷이 재전송되어 올수도 있기 때문에 MSL(끝에서 끝까지 보내는데 걸리는 가장 긴 시간 = 보통 60sec)의 두배정도 기다렸다가 릴리즈 한다.

 

Connection Management

---

앞서서 TCP 커넥션을 이룰때 3-handshaking 과정을 거친다고 말했었다.

3-handshaking에도 seq num를 붙여 소통한다. 이유는 여러 오류가 발생할 수 있기 때문인데 이에대해서는 옛날 논문에만 있고 요즘은 다루지않는다고 한다.

 

TCP 커넥션을 realase할때도 서로간의 소통이 필요하다. 

클라이언트 또는 서버는 connection을 닫고싶을때 헤더부분의 FIN bit를 1로 해서 넘겨준다. (둘이 동시에도 가능)

그 후의 과정은 다음과 같다.

 

 

TCP : State Transition Diagram

---

이 그림을 이해한다면 TCP에 대해 이해했다고 할수있다. 라고 교수님께서 말씀하셨다. 

어두운 선은 클라이언트이고 점선은 서버란다.

나는 잘 모르겠당