TCP

Taiwan Communist Party에 대한 내용은 대만공산당 문서 참고하십시오.

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이다.

1.2. 특징[편집]

---

1.2.1. 연결설정[편집]

---

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

Three Way Handshake

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

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

1.2.2. 신뢰성 보장과 흐름 제어(Flow Control)[편집]

---

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

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

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

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

1.2.3. 혼잡 제어(Congestion Control)[편집]

---

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

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

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

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

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

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

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

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

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

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

1.2.4. 그 외 이야기[편집]

---

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

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

TCP에 쓰이는 흐름 제어 및 신뢰성 제어 알고리즘은 현대에 들어서는 지나치게 구식이고 성능 상으로 비효율적이라는 평을 받고 있어 개발자들이 UDP 소켓에서 더 효율적인 알고리즘으로 TCP의 기능을 구현하려는 시도가 이어지고 있다. UDP 기반의 웹 문서 프로토콜인 QUIC와 HTTP/3, UDP 기반의 보안 소켓인 DTLS가 그 사례다.

2. 관련 네트워크 문서[편집]

---

• QoS

3. 교통 통제, 교통 수신호(Traffic Control Post)[편집]

---

도로교통법 제5조 (신호 또는 지시에 따를 의무) ① 도로를 통행하는 보행자와 차마의 운전자는 교통안전시설이 표시하는 신호 또는 지시와 다음 각 호의 어느 하나에 해당하는 사람이 하는 신호 또는 지시를 따라야 한다.

1. 교통정리를 하는 국가경찰공무원(의무경찰순경을 포함한다. 이하 같다) 및 제주특별자치도의 자치경찰공무원(이하 "자치경찰공무원"이라 한다)

2. 국가경찰공무원 및 자치경찰공무원(이하 "경찰공무원"이라 한다)을 보조하는 사람으로서 대통령령으로 정하는 사람(이하 "경찰보조자"라 한다)

② 도로를 통행하는 보행자와 모든 차마의 운전자는 제1항에 따른 교통안전시설이 표시하는 신호 또는 지시와 교통정리를 하는 국가경찰공무원·자치경찰공무원 또는 경찰보조자(이하 "경찰공무원등"이라 한다)의 신호 또는 지시가 서로 다른 경우에는 경찰공무원등의 신호 또는 지시에 따라야 한다.

보통 도로 중앙선 즈음의 가운데 서서 교통을 정리하는 데 쓰이는 수신호를 의미한다. 민간에서는 주로 신호등이 없는 도로거나, 신호등이 있지만 출퇴근 시간대에 너무 혼잡해서 교통경찰 1명이 수동으로 신호등을 조작하고 다른 1명은 도로를 정리할 때 쓰인다. 군대에서는 군용차량 등을 유도하거나 행군 행렬의 안전을 위해서 쓰인다.

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

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

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

사복을 착용한 경찰관은 수신호로 교통을 통제할 수 없다고 보는 것이 타당하다. 사복경찰관의 수신호에 유효성을 부여해 그 위반을 단속한다면, 단지 신호의 유효성을 믿지 못했을 뿐인 무고한 시민을 범죄자로 몰아갈 수 있기 때문이다. 또한 최소한의 증표없이 수신호하는 것을 허용하면 도로교통의 예측가능성을 크게 해치고, 사회혼란을 꾀하는 세력에게 악용될 수도 있다. 애초 사복을 입고 도로 한가운데 들어가는 것 자체가 매우 위험하다. 정 긴급하다면 하다못해 완장이라도 착용해야 할 것이며, 이 경우에도 강제력보다 시민의 자발적 헙조에 기댈 수밖에 없다.

모범운전자가 수신호를 잘못해 사고가 난 경우 경찰로부터 공무를 위탁받은 것으로 보고 고의나 중대한 과실이 없는 한 국가가 책임을 진다.#

이 외에 전우회, 어머니회, 공사장 신호수 등의 수신호도 많이 볼 수 있지만 법적 효력은 없고 단순히 교통 상황에 보조하는 역할에 그친다. 예를 들어 어린이보호구역에서 정지 깃발을 들고 횡단보도를 차단했다가 열었다하는 행위는 단순히 횡단보도의 신호등이 녹색으로 켜지거나 무신호 횡단보도에서 보행자가 있을때, 즉 원래도 정지를 해야하는 상황에서 정지하라고 안내해주는 것 뿐이다. 이들에게 횡단보도 신호가 적색인데 횡단보도를 열거나, 무신호 횡단보도에서 아무도 없는데 차량에게 정지를 명령할 수 있는 권한은 없는 것이다. 공사장 신호수의 신호도 단순히 공사차량의 진출입이 있으니 운전자에게 주의를 환기시키는 행위일 뿐이니 어디까지나 참고만 하여야 한다. 신호등처럼 전적으로 믿으면 사고나기 십상이며 책임도 운전자에게 있다.

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

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

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


모범운전자가 하는 모습. 다만 경찰이나 모범운전자나 저렇게 절도있게 하는 모습으로 하는 경우는 드문 편이다.

3.1. 둘러보기[편집]

---