전송 계층 03

< kocw 한양대학교 이석복 교수님의 강의를 바탕으로 공부한 내용을 정리하는 중입니다. >

http://www.kocw.net/home/cview.do?cid=6166c077e545b736

컴퓨터네트워크

-> 이번에 배운 내용은 TCP의 flow control과 connection management이며, congestion control에 대해 간략히 살펴보았다.

 

TCP에서 중요한 기능 3가지를 뽑자면 ' RDT(reliable data tranfer), flow control, congestion control '이다.

이 중 flow control은 매우 중요한 기능이지만, 그 동작원리는 매우 간단한 편이다. 

 

Flow Control

 

TCP는 두 프로세서 사이에 데이터를 주고받는 것이다. 

앞서 각 프로세서는 Receiver와 Sender인 두 개의 기능을 모두 갖추고 있음을 배웠다. 그렇기에 데이터를 주고 받는 과정이 가능했는데, 각자 데이터를 보내는 양을 조절함에 있어 데이터를 받는 입장을 고려한 통신이 flow control 기능이다.

즉 Receiver가 받을 수 있는 만큼의 데이터를 보내는 것이다. 

 

TCP 통신이 구성되면 각 컴퓨팅의 프로세서는 receiver buffer와 sender buffer로 일정량의 데이터를 주고 받는다. 

 

위의 그림은 앞서 '전송 계층02'에서 사용했던 이미지로 Sender와 Receiver는 buffer이다. (buffer에서 정한 양<window size>만큼 데이터가 순차적으로 채워지면 애플리케이션에서 이를 읽는다.) 

 

통신과정에서 receiver buffer의 크기<window size>가 5라면 sender도 5의 크기만큼 데이터를 보낸다. 만약 receiver buffer의 5자리에서 1자리가 비어있다면 sender가 5개의 데이터를 보내는 것은 의미가 없다. sender는 receiver가 필요로하는 1개의 데이터를 채우기 위한 데이터만 보내는 것이 효율적일 것이다. 결국 flow control은 receiver의 상황에 따라 sender가 이에 걸맞는 데이터를 보내는 기능이다.

 

따라서 TCP 구조의 Header 부분에는 receive buffer size필드가 존재하고 이를 통해 sender에게 정보를 보내고 sender는 이에 맞춰 데이터 양을 조절하여 통신한다. 

이처럼 flow control는 중요한 기능이지만 작동방식은 매우 단순하다.

 

 

한편, flow control은 애플리케이션이 읽는 속도에도 영향을 받는데, receiver buffer에 데이터가 채워졌지만, 애플레케이션의 프로세서가 어떤 문제로 이를 읽지 않는다고 생각해보자. 그럼 sender는 receiver로부터 buffer size = 0이라는 내용을 받을 것이며, 이에 sender는 데이터를 보내지 않을 것이다. 후에 애플리케이션이 receiver의 데이터를 읽었고 이제 receiver buffer의 공간이 다시 비워졌다면 receiver는 sender가 데이터를 다시 보낼때까지 기다리고 있을 것이다. 

그렇지만 sender는 receiver의 공간이 0이라고 생각하기에 데이터를 보내지 않고 멈춰있다면 통신에 장애가 발생한다. 그래서 이를 방지하기 위해 sender는 만약 receiver의 공간이 0이라는 내용을 받으면 주기적으로 data가 매우 작거나 없는 세그먼트를 보내며 receiver에 데이터를 보낼 공간이 있나 확인한다.  

 

 

Connection Management

 

앞서 살펴본 내용은 두 컴퓨터의 TCP 통신이 작동되기 위해 각 컴퓨터의 필요에 적합한 sender와 receiver를 구성하고 데이터를 주고받으며 과정에서 발생하는 유실과 에러를 방지하기 위한 내용들을 살펴봤다. 

 

지금부터는 두 컴퓨터가 TCP 연결을 구성하는 원리에 대해 정리해보겠다. 

 

TCP 3 - Way handshake( 두 컴퓨터의 3번 통신으로 연결이 이뤄진다. )

두 컴퓨터의 TCP 연결을 위해서는 먼저 클라이언트 컴퓨터가 서버 컴퓨터에 요청을 보낸다. (연결하고 싶다는 의사표현)

이때 클라이언트 컴퓨터는 TCP 세그먼트의 헤드 부분에 있는 SYN 필드(3bit)에 1( 평소 통신에는 아무런 값도 넣지 않는다. )과 자신의 시퀀스 넘버를 넣어 서버 컴퓨터에 보낸다.  

헤더 부분을 보면 (SYN)이 있다.

 

이를 받은 서버 컴퓨터는 SYN Ack( 클라이언트 시퀀스 넘버+1 )를 보내며 연결 요청에 대한 긍정의 응답을 표현하며 자신의 시퀀스 넘버도 함께 전달한다. 

 

마지막으로 클라이언트는 서버에 SYN 필드의 값으로 0을 넣고 SYN Ack( 서버 시퀀스넘버+1 )에 대한 응답으로 마무리한다. 그리고 이 때부터 클라이언트는 데이터를 넣고 통신 가능해진다. ( 첫 SYN 요청에서는 TCP -> 서버의 응답 SYN Ack도 TCP -> 마지막 3번째는 HTTP request )

 

이처럼 3-way 방식으로 연결을 확인하는 것은 클라이언트와 서버 모두 연결 상태를 확인하기 위함이다. 실제로 TCP뿐만아니라 다른 통신도 이 방식을 많이 사용한다.

 

Closing TCP Connection

 

통신으로 데이터를 주고받는 과정이 끝나 더 이상 연결을 사용하지 않는다면, 연결을 끊는 것도 필요하다. 

 

만약 클라이언트가 보낼 데이터가 다 끝나서 연결 종료를 원한다면 TCP 세그먼트의 fin 필드에 1을 넣고 서버에 보낸다. 그리고 응답으로 서버는 Ack를 보낸다. 

이후 서버도 보낼 데이터가 종료되었으면, fin 필드에 1을 넣고 클라이언트에 보내며 Ack를 기다린다. 위의 그림을 보면 클라이언트는 Ack를 보낸 후 완전 종료하기까지 약간의 시간을 기다리는 데 이는 만약 Ack가 유실되었을 경우 TimeOut으로 서버가 다시 fin을 보낼 수 있기에 잠시 대기하다 종료하는 것이다. 이 과정을 거쳐 두 컴퓨터 간의 연결은 종료된다. 

 

 

congestion control

 

sender가 데이터를 보내는 양(=속도)에는 많은 고려(제약)사항들이 있는 데, 먼저 receiver의 상태에 따른 제약을 받는다는 점을 flow control에서 확인했다. 

 

그리고 sender와 receiver 사이에 존재하는 많은 네트워크 환경 역시 sender가 보내는 데이터 양에 많은 영향을 끼친다. 

즉 sender는 보내는 데이터 양의 조절에 있어 받는 receiver와 중간 전달자인 네트워크 환경에 의한 관리되는 것이다. 

그럼으로 receiver가 수용할 수 있는 양과 네트워크가 수용할 수 있는 양에 대한 고려로 sender는 전달할 데이터 양을 측정해야한다. 만약 receiver의 수용력이 10이고 네트워크가 5의 수용력을 지녔다면 sender는 5의 데이터를 보내야하며, 반대로 receiver의 수용력이 5이고 네트워크 수용력이 10이라면 sender는 5의 데이터를 보내야한다. 즉 어떤 것이든 상태가 더 안 좋은 지점에 포커스를 맞추고 전달해야한다. 

 

이를 위해 flow control로 receiver의 상태를 sender는 알 수 있다. 그런데 인터넷 네트워크 상태는 어떻게 알 수 있는가??

인터넷 네트워크는 public으로 모두가 사용하는 네트워크로 많은 사용자들이 제한없이 접근하여 빠른 통신을 요구한다. 따라서 네트워크 상태가 좋지않다면 모두가 통신의 속도에 어려움을 맞이하는데, TCP의 원리는 이런 상태를 악화한다.

왜냐하면 TCP는 TimeOut이 발생하면 같은 데이터를 다시 또 보내기 때문이다. 이러면 public인 인터넷 네트워크에는 지속적으로 부담이 가해지며 결국 모두의 통신 속도가 저하되는 악순환이 반복된다. 따라서 모든 사용자들이 원활한 통신을 위해서는 네트워크 환경에 따라 데이터 전달을 조절하는 기능이 필요한데 이에 대한 접근법이 2가지 있다.

 

1) Network-assisted congestion control

  데이터를 전달하는 네트워크(ex 라우터)에서 sender에게 피드백을 준다.( 매우 이상적이지만 현실에서는 x )

2) End-end congestion control

  클라이언트와 서버가 데이터를 주고받는 과정에서 네트워크 상태를 유추할 수 있게 만든다. 

 

실제 환경에서는 2번째 방법인 End-end congestion control 방식을 사용하고 있으며, 다음 챕터에서는 congestion control의 이러한 내용에 대해 공부할 예정이다.