1 Transmission Control Protocol

Transmission Control Protocol의 축약어로 컴퓨터가 다른 컴퓨터와 데이터 통신을 하기 위한 규약(프로토콜)의 일종이다. TCP는 세계 통신표준으로 개발된 OSI 모형에서 4번째 계층인 전송 계층(Transport Layer)에서 사용하는 규약으로, 보통 하위 계층에서 사용하는 IP와 엮어서 TCP/IP로 표현하는 경우가 많다. 동일 계층에서 사용하는 또다른 프로토콜로 UDP가 존재한다.

1.1 개발동기

TCP의 개발동기는 군사적인 목적과도 닿아있다. 미국 국방성 산하의 고등 연구국에서 ARPANET을 연구할 때 관심을 가진 주제가 적국의 폭격, 심지어 핵전쟁이 발발하더라도 죽지 않고 정상적으로 동작하는 네트워크였다. 당시 일반적으로 사용되던 통신방식은 회선교환(Circuit Switching) 방식이었다. 예를 들어 서울에서 부산으로 간다고할 때 미리 이동할 경로를 "경부고속도로만 이용한다"로 정해놓는 방식이다. 이러한 방식은 통신을 중계해주던 곳이 개박살나거나 중간에 선 하나가 단락되는 것만으로도 통신이 바로 끊어지는 상황이 벌어졌다.

이에 따라 사용된 것이 패킷교환(Packet Switching) 방식인데, 앞서의 사례와는 달리 경로가 정해져 있지 않다. 경부고속도로가 심하게 막히면 다른 고속도로나 국도로 우회를 해서 갈 수 있는 방식이다. 따라서 서로 연결이 가능한 회선 하나만 남아있어도 통신이 끊어지지 않고 계속될 수 있는 환경을 구축하게 된 셈이었다. 다만 이 방식은 어떻게든 통신을 유지하는 것이 목적이므로 네트워크 환경의 안정성은 떨어질 수 밖에 없었다. 이로 인해 중간에 데이터가 유실되거나, 너무 늦게 전달되는 등 신뢰성이 떨어지는 문제점이 있었다. 이러한 문제점들을 해결하고자 신뢰성을 보장할 수 있는 통신 규약을 연구하게 됐고, 이에 따라 나온 것이 TCP이다.

구체적으로 다룰 경우 전문적인 내용들이 튀어나오므로 TCP의 특징을 최대한 간략하게 설명한다.

1.2 특징

1.2.1 연결설정

TCP는 전화를 거는 것처럼 상대와 연결을 설정하고 통신을 시작한다. 절차는 아래와 같다.

1) 상대에게 통신을 하고 싶다는 메시지를 보낸다. (SYN)

2) 상대는 그 메시지에 대한 응답 + 나도 통신 준비가 되었다는 메시지를 보낸다. (SYN)

3) 2번에서 받은 메시지에 응답을 보낸다. (ACK)

이와 같은 과정을 통해 나와 상대가 통신준비를 마쳤고, 현재 통신이 연결되어 있음을 보장하게 된다. 기존의 회선교환 방식의 개념과 유사하지만 단순히 서로 연결되어 있다는 것만 보장한다.

1.2.2 신뢰성 보장과 흐름 제어(Flow Control)

연결설정을 통해 통신준비를 마치면 이제 서로 데이터를 주고받을 수 있다. 다만 네트워크를 통해서 한 번에 보낼 수 있는 데이터의 양은 제한이 되어 있으므로 분할해서 보내야 된다. 간단히 비유하면 책 한 권 내용을 보내줘야 되는데 이것을 통째로 전송할 수 없으므로 한 장씩 보내는 것으로 생각하면 쉽다. 따라서 분할된 데이터에는 고유번호가 부여되는데 이는 책의 쪽 번호와 같다고 생각하면 된다. 이를 바탕으로 보내는 사람은 현재 몇 쪽을 보낸 것인지 상대에게 알려줄 수 있고, 받는 사람은 다음에 받을 자료가 몇 쪽인지를 알고 보내는 사람에게 요청할 수 있게 된다.

이를 통해 데이터가 제대로 전달됐는지도 알 수 있다. 예를 들어 31쪽을 받을 차례인데 그 자료가 안오고 다른 자료가 계속 도착한다면 보내줄 때까지 "~~현기증 난단 말이에요~~31쪽 좀 보내주세염"하고 요청하도록 TCP가 설계되어 있다. 그러면 보내는 사람은 상대가 요청한 31쪽을 보내주게 된다. 더불어 31쪽을 보낼 때 알람을 설정하게 되어있는데, 만약 이 알람이 울릴 때까지 받는 사람이 32쪽을 달라고 하지 않으면 역시 데이터가 누락된 것으로 추측할 수 있다. 이를 근거로 보내는 사람은 31쪽을 다시 전송할 수 있다.

여기까지 언급된 것만 보면 컴퓨터끼리 통신을 할 때 마치 데이터 하나씩만 전달하는 것처럼 보일 수 있다. 물론 그렇게 통신한다고 해서 문제가 되는 것은 아니나 당연히 상대가 많이 받을 수 있다면 많이 보내주는 것이 효율적이다. 하지만 무턱대고 보낼 수 있는 것도 아니다. 상대가 5쪽만 받을 수 있는데 보내는 쪽에서 닥치고 10쪽씩 보내버리면 어차피 5쪽은 못받고 누락되는 것은 마찬가지이다. 따라서 받는 쪽에서 "나 32쪽 받아야 됨. 근데 나 지금 6쪽만큼 받을 수 있음"이라 알려주면 보내는 쪽에서 32쪽에서 37쪽까지 자료를 보내주는 방식으로 동작한다.

이를 위한 TCP의 헤더파일을 살펴보면 목적지주소, 확인응답, 오류검출및복원, 실제데이터등이 포함되는데 UDP와 구분되는 것이 확인응답(Acknowledge)파일이다. 이것으로 송수신시 계속 확인응답을 보내어 잘 갔는지, 잘왔는지 확인을 하여 데이터 신뢰도가 높다. 하지만 데이터용량이 증가하여 수신속도가 떨어진다는 단점이 따라오게 된다. 물론 그 단점보다는 신뢰성이 높다는 장점이 훨씬 크기 때문에 무시된다.

1.2.3 혼잡 제어(Congestion Control)

사실 초기 TCP에서는 없던 요소이다. 한정된 네트워크 대역폭에서 소수의 사람들이 쓸 때는 몰랐는데 사용자가 점점 늘어나다보니 네트워크 회선이 그 부하를 감당하지 못하고 사망하는 것이 원인이었다. 평일의 고속도로와 휴일의 고속도로를 생각하면 아주 쉽게 이해할 수 있다(…). 이로 인해 기존 TCP의 한계가 지적됐고, 1980년대에 이를 제어하기 위한 방법이 추가됐다.

단순한 예로 통신을 시작할 때 일단 보내는 쪽에서 30 ~ 35쪽까지 자료를 보내본다. 그래서 상대가 잘 받았으면 이후 보내는 양을 조금씩 늘려보는 방식을 취한다. 그러다가 상대가 데이터를 제대로 받지 못한 것이 확인되면 그 즉시 보내는 양을 확 줄인다. 그리고 다시 슬금슬금 보내는 양을 늘렸다가 또 못 받았으면 줄여버리는 형태로 보내는 양을 조절하게 된다. 보내는 양을 늘리고 줄이는 방법은 AIMD(Addictive Increase/Multicative Decrease)를 채택하고 있으나 구체적으로 적용되는 방식은 TCP 버전마다 약간씩 차이가 있으므로 자세한 설명은 이하생략.

위 방법을 통해 TCP로 통신하는 모든 사용자들이 네트워크 상황에 따라 속도를 조절할 수 있게 되었으며, 많은 사용자들이 동시에 통신을 시도하면 속도에서 손해를 보게되지만 죽지는 않게 만들었다. 이론적으로 100Mbps 회선에서 5명의 사람이 동시에 TCP로 통신을 시도하면 초반에는 서로 차이가 있지만 궁극적으로는 100Mbps 회선을 각각 20Mbps씩 공평하게 나눠가지는 효과를 얻게 된다.

1.2.4 그 외 이야기

현존하는 상당수의 네트워크 프로그램은 TCP를 기반으로 통신한다. 그만큼 데이터 신뢰성을 중요시하는 프로그램들이 많다. 이메일이나 파일전송 같은 경우 데이터 하나가 날아가면 꽤나 골치 아픈 문제가 발생한다. 하지만 TCP에서 제공하는 신뢰성 보장 방법들을 반드시 사용할 필요는 없다. 만약 프로그램에서 필요로 하지 않는다면 구현하는 과정에서 기능을 끌 수 있게 되어 있다. 물론 그만큼 신뢰성이 떨어지는 상황은 감수해야 된다.

그 외에 TCP 자체가 오히려 비효율적인 경우도 발생한다. 대표적으로 실시간성을 중요시하거나 응답성을 중요시하는 프로그램인데 이를 위해 개발된 것이 바로 UDP이다.

TCP

목차