20180415 6 : TCP, sender & receiver

packet error 가 생길 수 있는 네트워크에서 어떤 메커니즘을 사용하면 극복할 수 있는가.

(1) Error Detection

(2) Feed-back

(3) Re-Transmission

(4) Time-out

 

- sender 와 receiver 가 있지만 Feed-back 자체 내에서 에러가 있는 경우

(1) 리시버의 수신여부를 모르기 때문에 센더는 데이터 재전송을 한다.

(2) 리시버의 관점에서는 해당 데이터가 새로운 데이터인지 혹은 재전송된 데이터인지 모르기 때문에 sequence number 를 이용한다

(3)sequence number 의 범위는 단순히 1비트로 표현한다. (0과 1)

 

ACKs & NAKs

NAKs 를 사용하지 않고 ACKs를 이용하면서 sequence number 를 이용한다. 

 

Errors & Loss 가 같이 발생하는 경우

패킷을 전송할 때 타이머가 필요하다. 타이머가 만료되기 이전에 피드백을 받으면 정상, 타이머가 만료되기 이전에 피드백을 받지 못하면 데이터가 유실됬음을 인지할 수 있다. 따라서 센더가 다시 해당 패킷을 보낸다.

 

(1) no loss

(2) packet loss
- 센더의 타이머가 유실된 패킷을 재전송 하는데 이용. 타이머가 만료가 되면 센더가 다시 패킷을 재전송

(3) ACKs loss 

- (2)의 내용처럼 타이머 만료시간을 통해서 패킷을 재전송하지만 리시버측에서는 존재하고 있는 데이터이기 때문에 버리고 ACKs 메세지를 보내고 센더측으로 새로운 데이터를 받을 준비를 한다.

(4) premature timeout / delayed ACK

 

Stop And Wait Operation (Stop & Wait)

 

 

 

위의 그림처럼 한다면 매우 비효율적이다. 왜냐하면 패킷을 하나 보내고 다시 하나 받는 그러한 과정들 속에서 오버헤드가 발생하기 때문이다. 따라서 아래의 표현처럼 Pipelining 을 실시해주어야 한다. 한번에 패킷을 받고 한번에 Feedback 를 받는 형태이다

 

 

 

Pipelined Protocols

- go-Back-N 프로토콜

- Selective repeat 

이라는 프로토콜이 존재한다. 실질적으로 쓰이는 프로토콜이 아니다. (교육적인 목적)

 

TCP Overview

• point 2 point 
• reliable, in-order byte
• pipelined
• full duplex data
  Sender & Receiver 라는 개념 자체가 사실 송신도 하면서 수신도 하기 때문에 상호간에 데이터가 이동됨을 이야기한다.
• tcp segment 

해당 프로토콜을 이해할 수 있기 때문이다.

TCP Segment Structure

 

• source port & dest port
  멀티플렉싱과 디멀티플렉싱을 하기 위함
• sequence number 
  Acks & Naks 을 통해서 트랙킹하기 위함
  송신자에 대한 sequence number 이다.
• acknowledgement number
  각각이 송수신자이기 때문에 sequence number 이다.
  수신자에 대한 sequence number 이다.
  
  TCP의 송신자는 버퍼를 두 개 가지고 있다.
  (1) send buffer
      애플리케이션에서 데이터를 보내려고 하는 버퍼. 버퍼 내부에서 송신되는 세그먼트는 수신 측의 리시브 버퍼 측에 쌓인다.
  (2) receive buffer 
      반대 측에서 보내는 데이터들이 해당 리시브 버퍼에 쌓인다.
  
  버퍼의 존재이유는 In-order byte 를 가능케 한다. 순서대로 데이터를 보내주기 위함이다. 
• cheksum
  Error Detection 을 위함이다.
• receive window
  flow control 을 하기 위함이다. 수신 측의 리시브 버퍼를 확인하기 위해 사용된다.

TCP 에서 사용하는 시퀀스 번호

- Byte stream "number" of first byte in segment's data : 제일 앞에 있는 바이트번호가 sequence number 가 된다.

- seq # of next byte expected from other side : ex) "ACK#10" 은 9번 시퀀스 번호까지 잘 받았고 10번 시퀀스 번호를 갖는 데이터를 기다린다.

 

TCP 는 파이프라이닝 방식으로 보내지만, window size 만큼 보내며 ACKs 없이 보낼 수 있다.  

TCP round trip time, timeout
타임아웃이 커지면, 느리게 진행될 것이다.

송신측과 수신측의 round trip time 이 존재하면 이 시간보다 타이머 만료시간을 조금 더 크게 잡아놓는것이 이상적이다. 하지만 round trip time 은 다르다. 왜냐하면 queueing delay 가 생기며 라우터의 큐마다 패킷이 담겨져있는 사이즈가 다르기 때문이다.

 

TCP sender 의 동작
(1) 보낼 데이터가 있으면 세그먼트를 만들어 시퀀스 번호를 붙인다.

(2) 보내기 이전에 타이머가 세팅이 안되어있으면 세팅을 시킨다.

(각 TCP 소켓에는 timer 가 하나 존재한다.)
(3) 세그먼트를 보내는 그 찰나에 타이머를 실행시키고 이후에 윈도우 사이즈만큼 데이터를 보낸다. 타이머는 계속 시간이 가는 상태이다.

(4) 피드백 받기 이전에 Timer 가 만료되면 해당 세그먼트를 재전송한다.

(5) Timer 가 만료되기 이전에 ACKs를 받았으며 해당 시퀀스 번호가 50을 받았다.

(6) 49까지 해당 수신측에서 잘 받았기 때문에 앞선 번호들을 버린다. 이후에 SEND_BASE 와 Timer는 새롭게 전송할 세그먼트 쪽으로 매핑시켜준다.
(7) 이후 남은 window size 만큼 새롭게 상위 계층에서 데이터를 내려 받는다. (window size 를 옮긴다는 표현도 있음)

 

리시버가 기다리고 있는 시퀀스 번호를 잘 받은 경우,

바로 ACKs 를 보내야 하지만, 50ms 만큼 기다렸다가 ACKs 를 보내라는 의미?

 

계속 데이터가 올 수 있기 때문에 기다렸다가 한번에 ACKs 를 보내자. Cumulative ACK 를 의미한다.

 

패킷 유실시 대기하는 시간이 오래 걸리는 문제 발생. reliable 하게 작동하지만 performance 관점에서는 비효율적이다. 어떤 방법을 쓰면 좋을까? 

 

타이머를 사용하지 않고 패킷 유실을 판단하자. in-order delivery 를 신경써주어야 한다. 

여기서 duplicate ACKs 를 최소 3개 이상 받게되면 패킷 유실을 판단한다. 그렇게 되면 타이머가 터지지 않았음에도 불구하고 세그먼트를 재전송한다. ( 전제조건 : 같은 ACK 번호를 3개 이상 받게되면 ) 오리지날 ACK 번호를 제외하고 받은 ACK 번호 3개를 의미한다. 이를 Fast Re-Transmit 이라고 한다.

 

[ 참고동영상 ]

 

[ 컴퓨터 네트워크 ]

 

정리 )

• packet Error 가 생길 수 있는 네트워크에서 어느 메커니즘을 사용하면 극볼할 수 있는가?
• Error Dectection : Checksum(체크섬) 관련링크
• Feedback
• Re-transmisstion ( 타당한 근거 : Timeout / 3-duplicate ACKs )
• Timeout
• Sequence Number 는 무엇이고 왜 사용하는지
• 송신 패킷의 번호를 부여,
• 리시버는 센더 측에서 보낸 데이터가 새로운 데이터인지 혹은 재 전송된 데이터인지 모르기 때문에 식별하기 위한 번호로써 이용한다.
• TCP 는 상위 애플리케이션과 데이터를 주고받을 떄 바이트 스트림으로 간주한다.
• 바이트 단위로 시퀀스 번호가 부여되며 이 번호를 통해서 패킷을 트랙킹 할 수 있다.
• 따라서 Sequence Number 는 TCP 가 In-Order Delivery 를 가능하도록 해준다.
• Pipelined Protocols
• 패킷을 하나 보내고 하나 받는 형식은 오버헤드가 존재하며 비효율적이다. 따라서 한번에 대량의 패킷을 송신하고 이후에 대량의 ACKs 를 수신하는 파이프라이닝 기법이 있다. (실질적으로 쓰이는 프로토콜은 아니라고 한다.)
• TCP 특징 설명
• 신뢰성 있트 네트워크 통신
• 순차적인 네트워크 통신
• 파이프 라인
• 센더가 즉 리시버이다. 상호간의 데이터가 이동됨
• TCP & UDP 헤더필드가 중요한 이유
• 헤더필드를 알면 해당 프로토콜을 이해할 수 있기 때문
• TCP 세그먼트 구조 및 설명
• http://www.tcpipguide.com/free/t_TCPMessageSegmentFormat-3.htm
• source port #
• dest port #
• sequence number
• acknowledgement number
• Flag bit (connection estab : SYN, FIN, ...)
• checksum
• window size
• window size
• flow control 을 위해서 사용하는 16비트 필드
• 한번에 전송할 수 있는 최대 프레임의 크기이다. (일반적으로 바이트 개수 N)
• TCP sender 의 동작방식 설명
• 패킷 유실을 판단할 근거를 타이머만으로 해결할 것인지에 대한 문제
• 3 duplicate ACKs 
• Fast Re-Transmission