TCP

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

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

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

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

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

Three Way Handshake

1) 상대에게 통신을 하고 싶다는 메시지를 보낸다. (SYN)
2) 상대는 그 메시지에 대한 응답 + 나도 통신 준비가 되었다는 메시지를 보낸다. (SYN-ACK)
3) 2번에서 받은 메시지에 응답을 보낸다. (ACK)

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

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

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

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

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

사실 초기 TCP에서는 없던 요소이다. 한정된 네트워크 대역폭에서 소수의 사람들이 쓸 때는 몰랐는데 사용자가 점점 늘어나다보니 네트워크 회선이 그 부하를 감당하지 못하고 사망하는 일이 발생하였다. 여기서 말하는 사망이란, 송신해야 할 책의 낱장이 중간에 있는 네트워크 기기(라우터 등)에 무한히 몰리게 되는 상황을 말한다. 즉, 중간 네트워크 기기가 송신하는 낱장의 속도가 그 기기가 수신하는 속도보다 느리게 되면 이러한 상황이 발생한다. 독이 깨져있어서 물이 새는데 물이 새는 속도보다 더 빨리 물을 채운다면 독이 넘치게 할 수 있는 것과 같다.

이 상황에서 기존 TCP는 위에서 언급했던 방식대로 동작한다고 생각해보자. 그러면 다음과 같은 일들이 발생한다.

송신자A: '이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!'
송신자B: '이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!'
송신자C: '이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!'
...

여기서 A, B, C는 라우터로 송신하는 (독에 물을 붓는) 사람들이다. 이미 라우터에는 아직 라우터가 미처 다 송신하지 못한 A, B, C의 낱장들이 남아 있다. 그런데 A, B, C가 각각 낱장을 또 보낸다. 이것은 두 가지 문제가 있다.

1, 라우터의 저장에도 한계 용량이 있다. 독의 크기가 유한하기 때문에 물을 너무 많이 부으면 넘친다. 그 넘친 물은 다시 독으로 들어오지 않듯, 그렇게 라우터 내의 저장 공간에 저장되지 못한 낱장들은 손실된다.

2. 흐름 제어의 예시에서 보듯, 47쪽을 보냈는데 답신이 없으면 또 47쪽을 보낸다. 만약 라우터가 무한한 저장공간을 가진다는 비현실적인 가정을 하더라도, 결국 라우터에 쌓여가는 낱장들 때문에 48쪽을 보낼 때까지 47쪽을 비정상적으로 많이 보내야 한다. 이는 비효율적이다. 심지어 그러한 가정도 없다면, 보내지는 낱장들은 그저 종이의 낭비이다. (전문용어를 쓰자면, 버려지는 패킷을 위해 전력을 사용했으니, 그 전력이 낭비라는 것이다.)

이러한 문제로 말미암아, 1980년대에 이를 제어하기 위한 방법이 추가됐다.

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

이 방법은 버스트 (burst) 를 줄이기 위한 것이다. 깨진 독에 어떻게 물이 차오르기 시작하는지를 생각해보면 어렵지 않다. 어느 순간에 빠지는 속도보다 들어오는 속도가 커지는 순간이다. 이것을 버스트라고 부르는데, 요점은 버스트가 나지 않으면 물이 차오르기 시작할 일도 없다는 것이고, 버스트가 발생해서 물이 차오르기 시작했다면 일단 물이 다 빠진 다음에 물을 부으면 되겠다는 생각이다. 이를 네트워크 환경에 맞추어 해석하면, 처음에 버스트가 생기지 않을 적절한 양을 보내고, 버스트가 일어나 라우터에 낱장들이 쌓이기 시작하는 것이 의심된다면 일단 라우터에서 그 낱장들이 빠지는 것을 기다린다는 방법이 되는것이다.

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

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

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

보통 도로 중앙선 즈음의 가운데 서서 교통을 정리하는 데 쓰이는 수신호를 의미한다. 경찰공무원(의무경찰 포함), 모범운전자, 군사경찰, 소방공무원의 수신호는 실제 신호등과 동등한 법적 효력을 가진 신호이며 이들의 수신호를 어기면 신호위반으로 처벌될 수 있다. 신호등과 수신호의 지시가 다르다면 신호등을 무시하고 수신호를 따라야 한다. 수신호 대신 신호등을 따르는 것도 신호위반이다. 수신호가 우선 적용되기 때문이다.

경찰공무원과 의무경찰, 모범운전자의 수신호는 모든 상황에서 적용할 수 있으며, 군사경찰의 경우 군차량·군사장비의 수송 작전이나 부대 내 중요 지점의 교통 정리에 한정해서, 그리고 소방공무원은 구급차, 소방차의 긴급 통행이 필요한 상황에서만 효력이 발생한다.

교차로에서 둘 이상의 수신호가 서로 충돌하는 경우 경찰공무원의 수신호에 따라야하고 다른 수신호는 무시할 수 있다. 가령 경찰공무원과 군사경찰의 수신호가 서로 반대된다면 군사경찰이 아니라 경찰공무원의 지시가 우선이라는 뜻이다.

이 외에 전우회, 어머니회, 공사장 신호수 등의 수신호도 많이 볼 수 있지만 법적 효력은 없다.

민간에서는 주로 신호등이 없는 도로거나, 신호등이 있지만 출퇴근 시간대에 너무 혼잡해서 교통경찰 1명이 수동으로 신호등을 조작하고 다른 1명은 도로를 정리할 때 쓰인다.

수신호를 하기 위해선 눈에 잘 띄는 백색 장갑과 호각, 경광봉이 필요하다. 일반적인 호각은 문방구에서도 팔지만 경찰용은 경찰 마크가 호각에 새겨져있고 사슬이 달려 어깨에 고정할 수 있도록 되어 있으며 소리가 더 또렷하여 멀리 퍼져나간다. 호각을 불 때는 그냥 '삐이이이이익' 후 부는 것이 아니고 혀 끝을 호각 입구에 대고 막아서 '튭튭' 하듯이 소리를 끊어서 '삑삑' 하며 응용해서 쓴다.'''

위의 중앙경찰학교 영상과 비교해보자.

교통 수신호는 경찰과 육해공 해병대 군사경찰, 전우회나 대형마트/백화점 등 각 조직들이 쓰는 것이 다 다르다고 봐도 될 정도로 각 집단별로 차이가 있고 한 집단 내에서조차 다르게 하는 경우가 많다. 어떤 조직에서는 기관에서 배운대로 정석을 지키는가 하면, 어떤 조직에서는 정석에서 동작을 생략하거나 변형하는 등 개개 하부 조직의 관습대로 하는 경향이 있으므로 천차만별의 모습을 보인다. 또한 경광봉을 들었을 때와 그냥 손으로만 하는 수신호도 다르다. 그러나 그게 경찰이든 군사경찰이든 모범운전자든 누구든 자꾸 수신호를 하다보면 지치기 때문에 시간이 갈수록 교통 수신호가 처음보다 못하거나 형편 없어진다는 것은 똑같다.