파이프 라인 기법에 대한 개괄적인 설명을 했으니 이제 TCP에서 왜 파이프라인 전송이 필요한지 알아보자. 앞으로 언급할 예에서 나올 수치는 계산하고, 이해하기 쉽도록 과장한 부분이 많을 것이기 때문에 실제적인 수치라 생각해서는 안된다.
다음과 같은 상황을 생각해보자.
- 서울에 있는 사람이 부산에 있는 사람에게 10Mbit짜리 파일을 전송한다. 파일 전송 시 거리에 따른 지연 시간은 10초이다.
- 네트웍에는 트래픽 부하가 전혀 걸려있지 않고 두 사람만 사용하고 있다. 즉 두 사람은 네트웍의 모든 전송 속도를 사용할 수 있다.
- 이 네트웍은 초당 1Mbit를 전송할 수 있다.
- 계산상의 편의를 위해 Gbit, Mbit에서의 단위는 1024가 아니라 1000로 정한다.
- 수신자는 패킷을 받자마자 ACK를 보내고, 그 ACK의 크기는 송신된 패킷과 같다고 가정한다.
이 상황에서 TCP가 파일을 1Kbit의 MSS로 분할하여, 한 패킷 전송 후 ACK를 받은 후 그 다음 패킷을 전송한다고 하면 서울의 송신자는 얼마동안 일을 하게되는가?
t=0 가 최초로 전송을 시작한 때라고 생각하고 각각의 상황을 좀 더 자세히 생각해보자.
t=0 : 서울의 송신자가 첫 번째 세그먼트를 전송하기 시작한다. 네트웍이 초당 1Mbit를 보낼 수 있으므로,
첫 번째 비트부터 마지막 비트를 네트웍에 전달하기까지 0.1초가 걸릴 것이다.
t=0.1 : 송신자가 세그먼트의 마지막 비트를 네트웍에 전달했고, 이 마지막 비트가 부산에 도착해야 수신자는 패킷을 인식할 것이다.
t=10.1 : 서울부터 부산까지의 거리 지연 시간이 10초이므로 이 때에 마지막 비트가 부산에 도착한다. 수신자가 패킷을
받자마자 Ack를 한다고, 또한 그 ACK의 size도 패킷과 동일하다고 가정했기 때문에 바로 Ack 과정이 시작된다.
t=20.1 : 수신자가 Ack한 패킷의 첫번째 비트가 서울에 도착한다. 이제부터 송신자는 네트웍으로부터 ACK 패킷을 받는 동작을 시작한다.
t=20.2 : 송신자가 모든 패킷을 받았다.
이 과정에서 송신자가 일하는 시간을 패킷의 전체 송,수신 시간에 대한 비율로 계산해보자.
총 시간 20.2초 중에 송신자는 네트웍으로 데이터를 전달하고, 수신하는 0.2초만 바빴다. 나머지 시간은 ACK가 오기를 기다리면서 멍청히 아무 일도 하지 않았다는 것이다. 비율로 따지면 0.99퍼센트이다. 이것은 웃기지도 않은 효율로서 이 프로토콜을 사용하여 예에서 들었던 네트웍을 사용하면, 아무런 트래픽 부하가 없는 즉, 1Mbps의 속도를 full로 사용할 수 있는 네트웍을 혼자 사용한다 하더라도, 9.9Kbps정도의 속도밖에 사용할 수 없다는 의미이다. 이것은 잘못 설계된 프로토콜이 얼마나 망의 속도를 제한하는지를 보여주는 예라 할 수있다.
이러한 문제점을 해결하기 위해 TCP는 파이프라이닝 전송을 사용한다. 즉 패킷에 대한 응답이 도착하기 전에 다음 패킷을 전송시킨다는 것이다. 이것은 우리가 다루었던 송, 수신자의 Idle time을 줄이는 올바른 해결책이지만, 언제나 그렇듯이 또 다른 문제를 발생시킨다. 그것은 패킷 전송 도중 손실된 패킷이나 손상된 패킷이 발생했을 때 그것을 해결하기 위한 좀 더 복잡한 방법을 필요로 한다는 것이다. 그 점에 대해서는 다음 포스트에서 다루도록 하겠다.
댓글 없음:
댓글 쓰기