"TCP/IP"의 두 판 사이의 차이
29번째 줄: | 29번째 줄: | ||
* 연결 설정 | * 연결 설정 | ||
− | TCP는 전화를 거는 것처럼 상대와 연결을 설정하고 통신을 시작한다. 이 과정을 3-way | + | TCP는 전화를 거는 것처럼 상대와 연결을 설정하고 통신을 시작한다. 이 과정을 3 방향 핸드셰이크 메커니즘(3-way Handshake)라고 하고 절차는 아래와 같다. |
# 상대에게 통신을 하고 싶다는 메시지를 보낸다. (SYN) | # 상대에게 통신을 하고 싶다는 메시지를 보낸다. (SYN) | ||
# 상대는 그 메시지에 대한 응답 + 나도 통신 준비가 되었다는 메시지를 보낸다. (SYN-ACK) | # 상대는 그 메시지에 대한 응답 + 나도 통신 준비가 되었다는 메시지를 보낸다. (SYN-ACK) | ||
40번째 줄: | 40번째 줄: | ||
여기까지 언급된 것만 보면 컴퓨터끼리 통신을 할 때 마치 데이터 하나씩만 전달하는 것처럼 보일 수 있다. 물론 그렇게 통신한다고 해서 문제가 되는 것은 아니나 당연히 상대가 많이 받을 수 있다면 많이 보내주는 것이 효율적이다. 하지만 무턱대고 보낼 수 있는 것도 아니다. 상대가 5쪽만 받을 수 있는데 보내는 쪽에서 닥치고 10쪽씩 보내버리면 어차피 5쪽은 못 받고 누락되는 것은 마찬가지이다. 따라서 받는 쪽에서 "나 32쪽 받아야 됨. 근데 나 지금 6쪽만큼 받을 수 있음"이라 알려주면 보내는 쪽에서 32쪽에서 37쪽까지 자료를 보내주는 방식으로 동작한다. | 여기까지 언급된 것만 보면 컴퓨터끼리 통신을 할 때 마치 데이터 하나씩만 전달하는 것처럼 보일 수 있다. 물론 그렇게 통신한다고 해서 문제가 되는 것은 아니나 당연히 상대가 많이 받을 수 있다면 많이 보내주는 것이 효율적이다. 하지만 무턱대고 보낼 수 있는 것도 아니다. 상대가 5쪽만 받을 수 있는데 보내는 쪽에서 닥치고 10쪽씩 보내버리면 어차피 5쪽은 못 받고 누락되는 것은 마찬가지이다. 따라서 받는 쪽에서 "나 32쪽 받아야 됨. 근데 나 지금 6쪽만큼 받을 수 있음"이라 알려주면 보내는 쪽에서 32쪽에서 37쪽까지 자료를 보내주는 방식으로 동작한다. | ||
이를 위한 TCP의 헤더파일을 살펴보면 목적지주소, 확인응답, 오류검출및복원, 실제데이터 등이 포함되는데 UDP와 구분되는 것이 확인응답(Acknowledge)파일이다. 이것으로 송수신 시 계속 확인응답을 보내어 잘 갔는지, 잘 왔는지 확인을 하여 데이터 신뢰도가 높다. 하지만 데이터 용량이 증가하여 수신속도가 떨어진다는 단점이 따라오게 된다. 물론 그 단점보다는 신뢰성이 높다는 장점이 훨씬 크기 때문에 무시된다<ref name="TCP">TCP 나무위키 - https://namu.wiki/w/TCP</ref> | 이를 위한 TCP의 헤더파일을 살펴보면 목적지주소, 확인응답, 오류검출및복원, 실제데이터 등이 포함되는데 UDP와 구분되는 것이 확인응답(Acknowledge)파일이다. 이것으로 송수신 시 계속 확인응답을 보내어 잘 갔는지, 잘 왔는지 확인을 하여 데이터 신뢰도가 높다. 하지만 데이터 용량이 증가하여 수신속도가 떨어진다는 단점이 따라오게 된다. 물론 그 단점보다는 신뢰성이 높다는 장점이 훨씬 크기 때문에 무시된다<ref name="TCP">TCP 나무위키 - https://namu.wiki/w/TCP</ref> | ||
+ | |||
+ | * 혼잡 제어(Congestion Control) | ||
+ | 사실 초기 TCP에서는 없던 요소이다. 한정된 네트워크 대역폭에서 소수의 사람들이 쓸 때는 몰랐는데 사용자가 점점 늘어나다보니 네트워크 회선이 그 부하를 감당하지 못하고 사망하는 것이 원인이었다. 여기서 말하는 사망이란, 송신해야 할 책의 낱장이 중간에 있는 네트워크 기기(라우터 등)에 무한히 몰리게 되는 상황을 말한다. 즉, 중간 네트워크 기기가 송신하는 낱장의 속도가 그 기기가 수신하는 속도보다 느리게 되면 이러한 상황이 발생한다. 독이 깨져있어서 물이 새는데 물이 새는 속도보다 더 빨리 물을 채운다면 독이 넘치게 할 수 있는 것과 같다. 이 상황에서 기존 TCP는 위에서 언급했던 방식대로 동작한다고 생각해보자. 그러면 다음과 같은 일들이 발생한다. | ||
+ | 송신자A: '이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!' | ||
+ | 송신자B: '이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!' | ||
+ | 송신자C: '이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!' | ||
+ | 여기서 A, B, C는 라우터로 송신하는 (독에 물을 붓는) 사람들이다. 이미 라우터에는 아직 라우터가 미처 다 송신하지 못한 A, B, C의 낱장들이 남아 있다. 그런데 A, B, C가 각각 낱장을 또 보낸다. 이것은 두 가지 문제가 있다. | ||
+ | # 라우터의 저장에도 한계 용량이 있다. 독의 크기가 유한하기 때문에 물을 너무 많이 부으면 넘친다. 그 넘친 물은 다시 독으로 들어오지 않듯, 그렇게 라우터 내의 저장 공간에 저장되지 못한 낱장들은 손실된다. | ||
+ | # 흐름 제어의 예시에서 보듯, 47쪽을 보냈는데 답신이 없으면 또 47쪽을 보낸다. 만약 라우터가 무한한 저장공간을 가진다는 비현실적인 가정을 하더라도, 결국 라우터에 쌓여가는 낱장들 때문에 48쪽을 보낼 때까지 47쪽을 비정상적으로 많이 보내야 한다. 이는 비효율적이다. 심지어 그러한 가정도 없다면, 보내지는 낱장들은 그저 종이의 낭비이다. (전문용어를 쓰자면, 버려지는 패킷을 위해 전력을 사용했으니, 그 전력이 낭비라는 것이다.)이러한 문제로 말미암아, 1980년대에 이를 제어하기 위한 방법이 추가됐다. 단순한 예로 통신을 시작할 때 일단 보내는 쪽에서 30 ~ 35쪽까지 자료를 보내본다. 그래서 상대가 잘 받았으면 이후 보내는 양을 조금씩 늘려보는 방식을 취한다. 그러다가 상대가 데이터를 제대로 받지 못한 것이 확인되면 그 즉시 보내는 양을 확 줄인다. 그리고 다시 슬금슬금 보내는 양을 늘렸다가 또 못 받았으면 줄여버리는 형태로 보내는 양을 조절하게 된다. | ||
+ | 이 방법은 버스트 (burst) 를 줄이기 위한 것이다. 깨진 독에 어떻게 물이 차오르기 시작하는지를 생각해보면 어렵지 않다. 어느 순간에 빠지는 속도보다 들어오는 속도가 커지는 순간이다. 이것을 버스트라고 부르는데, 요점은 버스트가 나지 않으면 물이 차오르기 시작할 일도 없다는 것이고, 버스트가 발생해서 물이 차오르기 시작했다면 일단 물이 다 빠진 다음에 물을 부으면 되겠다는 생각이다. 이를 네트워크 환경에 맞추어 해석하면, 처음에 버스트가 생기지 않을 적절한 양을 보내고, 버스트가 일어나 라우터에 낱장들이 쌓이기 시작하는 것이 의심된다면 일단 라우터에서 그 낱장들이 빠지는 것을 기다린다는 방법이 되는것이다. | ||
+ | 위 방법을 통해 TCP로 통신하는 모든 사용자들이 네트워크 상황에 따라 속도를 조절할 수 있게 되었으며, 많은 사용자들이 동시에 통신을 시도하면 속도에서 손해를 보게되지만 죽지는 않게 만들었다. 이론적으로 100 Mbps 회선에서 5명의 사람이 동시에 TCP로 통신을 시도하면 초반에는 서로 차이가 있지만 궁극적으로는 100 Mbps 회선을 각각 20 Mbps씩 공평하게 나눠가지는 효과를 얻게 된다.<ref name="TCP"></ref> | ||
* 연결지향적 (Connection-oriented) | * 연결지향적 (Connection-oriented) | ||
62번째 줄: | 73번째 줄: | ||
* 세그먼트화 처리 (데이터를 패키징 처리한다.) | * 세그먼트화 처리 (데이터를 패키징 처리한다.) | ||
바이트들을 모아서 세그먼트화하고 이에 TCP 헤더를 붙이고, 이들을 순서제어한다. (TCP 세그먼트 : TCP에서 IP로 전달되는 정보 단위(통상, 수 백 바이트 정도)양 끝단의 TCP 모듈간에 서로 교환되는 데이터 단위를 TCP 세그먼트라고한다.) | 바이트들을 모아서 세그먼트화하고 이에 TCP 헤더를 붙이고, 이들을 순서제어한다. (TCP 세그먼트 : TCP에서 IP로 전달되는 정보 단위(통상, 수 백 바이트 정도)양 끝단의 TCP 모듈간에 서로 교환되는 데이터 단위를 TCP 세그먼트라고한다.) | ||
− | |||
− | |||
− | |||
− | |||
* 비 실시간적 응용 | * 비 실시간적 응용 | ||
102번째 줄: | 109번째 줄: | ||
앞에서 말한 특징들은 대부분 TCP/IP의 장점이라고 할 수 있다. 그렇다면 단점도 알아보자 | 앞에서 말한 특징들은 대부분 TCP/IP의 장점이라고 할 수 있다. 그렇다면 단점도 알아보자 | ||
− | 1. 응용 프로그램 계층 프로토콜인 HTTP / HTTPS | + | * 1. 응용 프로그램 계층 프로토콜인 HTTP / HTTPS |
− | HTTP (Hypertext Transfer Protocol)는 월드 와이드 웹 (World Wide Web)의 데이터 전송을위한 기초이지만이 프로토콜은 다양한 보안 위험을 야기하며 침투 및 도용에 | + | HTTP (Hypertext Transfer Protocol)는 월드 와이드 웹 (World Wide Web)의 데이터 전송을위한 기초이지만이 프로토콜은 다양한 보안 위험을 야기하며 침투 및 도용에 취약하다. |
− | + | * 2. 전송 계층 프로토콜인 TCP | |
− | 2. 전송 계층 프로토콜인 TCP | + | TCP 3 방향 핸드 셰이크 메커니즘, 승인 메커니즘 및 혼잡 제어 메커니즘은 네트워크가 불안정 할 때 대역폭과 시간 낭비를 초래한다. |
− | TCP 3 방향 핸드 셰이크 메커니즘, 승인 메커니즘 및 혼잡 제어 메커니즘은 네트워크가 불안정 할 때 대역폭과 시간 낭비를 | + | * 3. 인터넷 레이어 프로토콜인 IP |
− | + | IP 주소는 종종 실제 주소와 연결된다. 사회 공학 기술을 사용하여 해커는 주소를 개인에게 연결하고 개인을 프로파일링하며 사기 행위를 저지를 수 있다. 플랫폼은 또한 주요 식별자 중 하나로 IP 주소를 사용하므로 관련 광고를 제공하기 위해 IP 탐색을 추적한다. | |
− | 3. 인터넷 레이어 프로토콜인 IP | + | * 4. 데이터 링크 계층 프로토콜로서의 이더넷 |
− | IP 주소는 종종 실제 주소와 | + | CSMA / CD를 사용하는 버스 토폴로지 구조는 대량의 충돌 발생시 정체를 일으킬 수 있다. 만약 중앙 노드가 실패하면 전체 네트워크를 사용할 수 없다. |
− | + | 네트워크에 변동이 발생하면 TCP / IP는 대역폭 사용량을 제대로 관리 할 수없고 전송 효율을 빠르게 저하시킬 수 없으며 블록체인과 같은 대규모 정보 방송 네트워크를 완벽하게 지원할 수 없어 최신 블록과 동기화하여 이미 채굴 된 블록의 시간과 리소스를 낭비한다. 또한 TCP / IP 보안 구성 요소에 필요한 배포 및 학습 비용으로 인해 부적절한 배포로 인한 잠재적 취약성이 남아있을 수 있다. 또한 모든 블록체인 관련 통신 (예 : 검증, 보안, 데이터 저장을 위해 블록 체인에 의존하는 통신)은 TCP / IP를 통해 동일한 문제를 겪게된다.<ref> 아스카쨩, 〈[https://www.tokenpost.kr/forum/free/20824 TCP/IP 프로토콜의 문제점을 해결하는 새로운 인터넷 프로토콜]〉, 《토큰포스트》, 2019-12-03</ref> | |
− | 4. 데이터 링크 계층 프로토콜로서의 이더넷 | ||
− | CSMA / CD를 사용하는 버스 토폴로지 구조는 대량의 충돌 발생시 정체를 일으킬 수 | ||
− | |||
− | 네트워크에 변동이 발생하면 TCP / IP는 대역폭 사용량을 제대로 관리 할 수없고 전송 효율을 빠르게 저하시킬 수 없으며 블록체인과 같은 대규모 정보 방송 네트워크를 완벽하게 지원할 수 없어 최신 블록과 동기화하여 이미 채굴 된 블록의 시간과 리소스를 | ||
2020년 7월 28일 (화) 16:10 판
TCP/IP(티씨피/아이피)란 전송제어프로토콜(Transmission Control Protocol)/인터넷 프로토콜(Internet Protocol)의 약자로서, 인터넷에서 사용되는 표준 통신 프로토콜이다. TCP/IP는 서로 다른 시스템을 가진 컴퓨터들을 서로 연결하여 데이터를 전송하기 위해 사용한다. 티씨피/아이피라고 읽는다.
개요
TCP/IP는 문자 그대로는 전송제어프로토콜, 인터넷 프로토콜을 의미한다. ISO의 7계층 구조에 의하면 TCP는 계층4에 그리고 IP는 계층3에 해당되는 프로토콜의 이름이다. 그러나 보통 우리가 TCP/IP라고 말하면 이는 계층3, 계층4 프로토콜만 얘기하는 것이 아니라 TCP/IP프로토콜 조합(protocol suit)을 의미하는 경우가 대부분이므로 여기에는 ISO의 계층5,6,7 에 해당하는 여러가지 응용 프로토콜과 계층3, 계층4에 있는 또다른 프로토콜까지 포함되며, 오늘날 인터넷을 움직이는 통신 소프트웨어의 뼈대가 되는 모든 프로토콜을 말한다. 따라서 TCP/IP와 인터넷을 따로 떼어놓고 생각하는 것은 불가능하다. 1960년대 후반과 1970년대 초의 네트워크는 각기 다른 네트워크에 속하는 사용자들이 자원을 공유하도록 지원하지 않았다. 네트워크 관리자들은 보안상의 문제로 사용자들이 자원에 마음대로 접근하는 것을 꺼려하였고 어떤 정보 시스템의 사용자가 자신의 사용 범위를 다른 네트워크로 확대하도록 하는 것이 매우 어려운 상태였다. 이러한 기간 동안 자원을 여러 사용자들이 공유하는 것이 좋다는 점을 점차 인식하게 되었다. 최종 사용자 응용 프로그램이 서로 상호 접속되기 위해서는 네트워크 관리자가 아닌 전자 우편(Electric Mail)이나 파일 전송(File Transfer)같은 응용의 표준화가 뒤따라야 했다. TCP와IP는 이러한 문제를 해결하기 위해서 개발되었다. 네트워크를 서로 접속하는 필요성은 이와같이 자원의 공유측면과 정보의 교환 측면에서 긴히 필요하게 되었다. 이때, 네트워크간의 접속에 필요한 프로토콜이 필요한 것이다. 이 프로토콜로서 TCP/IP 프로토콜이 존재하며 이 프로토콜을 사용하여 서로 접속된 네트워크를 인터넷(Internet)이라 한다. 즉, 여러개의 네트워크들이 서로 유기적으로 결합되어 있는 커다란 하나의 가상 네트워크를 인터넷이라고 하는 것이다. 따라서, 인터넷에 가입한다는 의미는 이 커다란 네트워크에 접속함을 의미한다.[1]
기능
TCP는 전송 제어 프로토콜로서, 근거리 통신망이나 인터넷에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟(octet)을 안정적으로, 순서대로, 에러 없이 전송하고, 수신된 패킷을 원래의 메시지로 조립하는 일을 담당한다.
IP는 각 패킷의 주소 부분을 처리해 패킷들이 목적지에 정확하게 도달하도록 하는 일을 담당한다.
등장 배경
- 1960년대 DoD(미 국방성)에 의해 통신기술에 대한 연구 시작
- 기존에는 중앙집중식 네트워크를 사용했는데, 중앙집중식 네트워크는 회선교환기(중심부)가 공격을 당하면 모든 네트워크의 연결이 끊기기 때문에 분산형 네트워크 처럼 어느 한 부분이 공격받아도 끊기지 않는 네트워크가 필요하기 때문에 DoD에서 통신기술에 대한 연구를 진행하였다.(군사적인 목적 뿐만이 아니라 , 기존 회선 교환방식의 효율성 때문에도 통신기술에 대한 연구를 시작하였다.)
- 1969년 패킷 교환 기술 개발 , 아르파넷(ARPANET)의 시작
위에서 설명한 네트워크를 구현하기 위해 여러 연구를 진행한 결과 '패킷 교환기술'이 가장 적합하다고 생각되어 패킷교환기술의 실용성을 실험하기 위해 DARPA(미 국방성 고등연구 계획국)에서 아르파넷이라는 네트워크를 구축하였다. (초기 4개의 노드 연결에서 34개 노드를 연결하는 형태로 실험을 성공하여 패킷교환방식의 실용성을 증명하였다.) 아르파넷은 패킷교환방식의 실용성 실험과 더불어 , PC대 PC통신의 신뢰성 높은 통신을 제공하는 프로토콜도 연구하였다. 위의 연구를 토대로 TCP/IP를 개발하였고 1982년에 TCP/IP 사양이 결정되었고 1983년에 TCP/IP를 아르파넷의 공식적인 프로토콜로 인정하였다.
- 1980년 이후 아르파넷에서만 사용되던 TCP/IP 전파
TCP/IP의 등장에는 아르파넷이 중요한 역할을 하였지만 , TCP/IP는 아르파넷에서만 사용하였으므로 일반에게는 전파되지 않았다. 그런데 현재 TCP/IP가 전세계에 널리 보급되고 주로 사용되는 이유는 1982년 TCP/IP의 사양이 결정되었을때 , 유닉스(UNIX) OS에서 TCP/IP를 탑제하였기 때문이다.(그 당시 대학 , 연구소 등에서는 대부분 유닉스 OS를 사용하고 있었다.) 유닉스 OS 덕분에 대학 , 연구소 등이 NSFnet(아르파넷의 후손)에 연결되게 되었고 이때부터 TCP/IP로 연결된 세계적인 네트워크를 '인터넷'이라고 부르기 시작하였다.(이후 각 컴퓨터 제조업체에서도 TCP/IP를 지원하게 되었다.)
- 1990년대 이후 일반인도 본격적으로 인터넷에 접속
90년대 전까지는 인터넷을 (TCP/IP로 연결된 세계적인 네트워크) 대학 , 연구기관 등만 사용할 수 있었고 일반인들은 PC통신(한정된 인원끼리 커뮤니케이션)밖에 사용하지 못했다. 그러나 ISP의 등장으로 일반인도 인터넷을 사용할 수 잇게 되었다. (TCP/IP는 기존에 연구목적으로 인터넷에 오랜기간 운용되었기 때문에 일반인에게 서비스화해도 안정적으로 운용할 수 있었다.)[2]
특징
TCP와 IP 각각의 특징을 살펴보고 TCP/IP의 특징[3]에 대해 알아 보았다.
TCP의 특징
- 연결 설정
TCP는 전화를 거는 것처럼 상대와 연결을 설정하고 통신을 시작한다. 이 과정을 3 방향 핸드셰이크 메커니즘(3-way Handshake)라고 하고 절차는 아래와 같다.
- 상대에게 통신을 하고 싶다는 메시지를 보낸다. (SYN)
- 상대는 그 메시지에 대한 응답 + 나도 통신 준비가 되었다는 메시지를 보낸다. (SYN-ACK)
- 2번에서 받은 메시지에 응답을 보낸다. (ACK)
이와 같은 과정을 통해 나와 상대가 통신준비를 마쳤고, 현재 통신이 연결되어 있음을 보장하게 된다. 기존의 회선교환 방식의 개념과 유사하지만 단순히 서로 연결되어 있다는 것만 보장한다.
- 신뢰성 보장과 흐름 제어(Flow Control)
연결설정을 통해 통신준비를 마치면 이제 서로 데이터를 주고받을 수 있다. 다만 네트워크를 통해서 한 번에 보낼 수 있는 데이터의 양은 제한이 되어 있으므로 분할해서 보내야 된다. 간단히 비유하면 책 한 권 내용을 보내줘야 되는데 이것을 통째로 전송할 수 없으므로 한 장씩 보내는 것으로 생각하면 쉽다. 따라서 분할된 데이터에는 고유번호가 부여되는데 이는 책의 쪽 번호와 같다고 생각하면 된다. 이를 바탕으로 보내는 사람은 현재 몇 쪽을 보낸 것인지 상대에게 알려줄 수 있고, 받는 사람은 다음에 받을 자료가 몇 쪽인지를 알고 보내는 사람에게 요청할 수 있게 된다. 이를 통해 데이터가 제대로 전달됐는지도 알 수 있다. 예를 들어 31쪽을 받을 차례인데 31쪽이 안 오고 다른 데이터가 도착한다면 보내줄 때까지 "31쪽을 보내주세요" 요청하도록 TCP가 설계되어 있다. 그러면 보내는 사람은 상대가 요청한 31쪽을 보내주게 된다. 더불어 47쪽을 보낼 때 알람을 설정하게 되어있는데, 만약 이 알람이 울릴 때까지 받는 사람이 48쪽을 달라고 하지 않으면 역시 데이터가 누락된 것으로 추측할 수 있다. 이를 근거로 보내는 사람은 47쪽을 다시 전송할 수 있다. 여기까지 언급된 것만 보면 컴퓨터끼리 통신을 할 때 마치 데이터 하나씩만 전달하는 것처럼 보일 수 있다. 물론 그렇게 통신한다고 해서 문제가 되는 것은 아니나 당연히 상대가 많이 받을 수 있다면 많이 보내주는 것이 효율적이다. 하지만 무턱대고 보낼 수 있는 것도 아니다. 상대가 5쪽만 받을 수 있는데 보내는 쪽에서 닥치고 10쪽씩 보내버리면 어차피 5쪽은 못 받고 누락되는 것은 마찬가지이다. 따라서 받는 쪽에서 "나 32쪽 받아야 됨. 근데 나 지금 6쪽만큼 받을 수 있음"이라 알려주면 보내는 쪽에서 32쪽에서 37쪽까지 자료를 보내주는 방식으로 동작한다. 이를 위한 TCP의 헤더파일을 살펴보면 목적지주소, 확인응답, 오류검출및복원, 실제데이터 등이 포함되는데 UDP와 구분되는 것이 확인응답(Acknowledge)파일이다. 이것으로 송수신 시 계속 확인응답을 보내어 잘 갔는지, 잘 왔는지 확인을 하여 데이터 신뢰도가 높다. 하지만 데이터 용량이 증가하여 수신속도가 떨어진다는 단점이 따라오게 된다. 물론 그 단점보다는 신뢰성이 높다는 장점이 훨씬 크기 때문에 무시된다[4]
- 혼잡 제어(Congestion Control)
사실 초기 TCP에서는 없던 요소이다. 한정된 네트워크 대역폭에서 소수의 사람들이 쓸 때는 몰랐는데 사용자가 점점 늘어나다보니 네트워크 회선이 그 부하를 감당하지 못하고 사망하는 것이 원인이었다. 여기서 말하는 사망이란, 송신해야 할 책의 낱장이 중간에 있는 네트워크 기기(라우터 등)에 무한히 몰리게 되는 상황을 말한다. 즉, 중간 네트워크 기기가 송신하는 낱장의 속도가 그 기기가 수신하는 속도보다 느리게 되면 이러한 상황이 발생한다. 독이 깨져있어서 물이 새는데 물이 새는 속도보다 더 빨리 물을 채운다면 독이 넘치게 할 수 있는 것과 같다. 이 상황에서 기존 TCP는 위에서 언급했던 방식대로 동작한다고 생각해보자. 그러면 다음과 같은 일들이 발생한다. 송신자A: '이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!' 송신자B: '이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!' 송신자C: '이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!' 여기서 A, B, C는 라우터로 송신하는 (독에 물을 붓는) 사람들이다. 이미 라우터에는 아직 라우터가 미처 다 송신하지 못한 A, B, C의 낱장들이 남아 있다. 그런데 A, B, C가 각각 낱장을 또 보낸다. 이것은 두 가지 문제가 있다.
- 라우터의 저장에도 한계 용량이 있다. 독의 크기가 유한하기 때문에 물을 너무 많이 부으면 넘친다. 그 넘친 물은 다시 독으로 들어오지 않듯, 그렇게 라우터 내의 저장 공간에 저장되지 못한 낱장들은 손실된다.
- 흐름 제어의 예시에서 보듯, 47쪽을 보냈는데 답신이 없으면 또 47쪽을 보낸다. 만약 라우터가 무한한 저장공간을 가진다는 비현실적인 가정을 하더라도, 결국 라우터에 쌓여가는 낱장들 때문에 48쪽을 보낼 때까지 47쪽을 비정상적으로 많이 보내야 한다. 이는 비효율적이다. 심지어 그러한 가정도 없다면, 보내지는 낱장들은 그저 종이의 낭비이다. (전문용어를 쓰자면, 버려지는 패킷을 위해 전력을 사용했으니, 그 전력이 낭비라는 것이다.)이러한 문제로 말미암아, 1980년대에 이를 제어하기 위한 방법이 추가됐다. 단순한 예로 통신을 시작할 때 일단 보내는 쪽에서 30 ~ 35쪽까지 자료를 보내본다. 그래서 상대가 잘 받았으면 이후 보내는 양을 조금씩 늘려보는 방식을 취한다. 그러다가 상대가 데이터를 제대로 받지 못한 것이 확인되면 그 즉시 보내는 양을 확 줄인다. 그리고 다시 슬금슬금 보내는 양을 늘렸다가 또 못 받았으면 줄여버리는 형태로 보내는 양을 조절하게 된다.
이 방법은 버스트 (burst) 를 줄이기 위한 것이다. 깨진 독에 어떻게 물이 차오르기 시작하는지를 생각해보면 어렵지 않다. 어느 순간에 빠지는 속도보다 들어오는 속도가 커지는 순간이다. 이것을 버스트라고 부르는데, 요점은 버스트가 나지 않으면 물이 차오르기 시작할 일도 없다는 것이고, 버스트가 발생해서 물이 차오르기 시작했다면 일단 물이 다 빠진 다음에 물을 부으면 되겠다는 생각이다. 이를 네트워크 환경에 맞추어 해석하면, 처음에 버스트가 생기지 않을 적절한 양을 보내고, 버스트가 일어나 라우터에 낱장들이 쌓이기 시작하는 것이 의심된다면 일단 라우터에서 그 낱장들이 빠지는 것을 기다린다는 방법이 되는것이다. 위 방법을 통해 TCP로 통신하는 모든 사용자들이 네트워크 상황에 따라 속도를 조절할 수 있게 되었으며, 많은 사용자들이 동시에 통신을 시도하면 속도에서 손해를 보게되지만 죽지는 않게 만들었다. 이론적으로 100 Mbps 회선에서 5명의 사람이 동시에 TCP로 통신을 시도하면 초반에는 서로 차이가 있지만 궁극적으로는 100 Mbps 회선을 각각 20 Mbps씩 공평하게 나눠가지는 효과를 얻게 된다.[4]
- 연결지향적 (Connection-oriented)
- 같은 전송계층의 UDP가 비연결성(connectionless)인 것과는 달리, TCP는 연결지향적이다. (이 경우, 느슨한 연결(Loosly Connected)을 갖으므로 강한 연결을 의미하는 가상회선이라는 표현 보다는 오히려 연결지향적이라고 표현 한다.)
- 연결 관리를 위한 연결설정 및 연결해제가 필요하다. (양단간 어플리케이션/프로세스는 TCP가 제공하는 연결성 회선을 통하여 서로 통신한다.)
- TCP 연결의 식별, 다중화, 포트번호
- TCP 연결(회선)의 식별 : 소켓(양단 IP주소 및 포트번호 쌍)으로 회선을 식별한다. (2개의 IP 주소 및 2개의 포트 번호에 의한 4개가 하나의 연결(회선)을 식별한다.)
- 여러 응용 간 다중화 가능: 단일 연결 뿐만아니라 다수 연결의 동시적 처리도 가능하다.
- 응용과의 연결점 식별 : TCP는 포트 번호에 의해 어플리케이션(응용)과의 연결점을 식별한다.
- 전이중 전송방식/양방향성 (Full-Duplex)
종단간 양 프로세스가 서로 동시에 세그먼트를 전달할 수 있다. (양방향 각각에 대해 `송수신 버퍼` 및 `데이터흐름용 순서번호`를 유지한다.)
- 멀티캐스트 불가능 (단대단 전송 방식 (1:1) 즉, 유니캐스트성이다.)
단일 송신자와 단일 수신자 간에 단일 경로 연결이 설정된다.
- 상위 응용과는 바이트 스트림(Byte Stream)으로 주고받는다.
- 논리적(의미를 갖는) 단위인 메세지 스트림이 아니다. (각 데이터 간의 구분을 의미적으로 구분하지 않고,단순히 바이트들의 연속적인 흐름으로 보고, 이들을 묶어 세그먼트화하여 전송한다.)
- 상위 응용 개발자들이 흐름제어,회선관리,전송단위 등을 신경쓰지 않도록 한다.
- 세그먼트화 처리 (데이터를 패키징 처리한다.)
바이트들을 모아서 세그먼트화하고 이에 TCP 헤더를 붙이고, 이들을 순서제어한다. (TCP 세그먼트 : TCP에서 IP로 전달되는 정보 단위(통상, 수 백 바이트 정도)양 끝단의 TCP 모듈간에 서로 교환되는 데이터 단위를 TCP 세그먼트라고한다.)
- 비 실시간적 응용
TCP는 데이터의 전달에 대한 보장을 하지만, 전달에 따른 지연에는 취약하므로 실시간적 응용에는 통상 UDP를 사용한다.
- TCP 활용
- 상위 프로토콜 지원 : HTTP, FTP, SMTP 등이 있다.
- 응용 지원 : TELNET, rlogin, 웹, 전자우편 등이 있다.
IP의 특징
- 신뢰성(에러제어)` 및 `흐름제어` 기능이 전혀 없다. (신뢰성을 확보하려면 IP 계층 위의 TCP와 같은 상위 트랜스포트 계층에 의존해야 한다.)
- 비연결성 데이터그램 방식
- 패킷의 완전한 전달(소실,중복,지연,순서바뀜 등이 없게하는 것)을 보장하지 않는다.
- IP 헤더 내 수신 및 발신 주소를 포함한다.
- IP 헤더 내 바이트 전달 순서는 최상위 바이트(MSB)를 먼저 보낸다.
- 경우에 따라, 단편화가 필요하다.
- 모든 상위 계층 프로토콜들(TCP,UDP,ICMP,IGMP 등)이 IP 데이타그램에 실려서 전송된다.
TCP/IP의 특징
- 통합 주소지정 체계를 가진다.
- 소형과 대형 네트워크 모두에서 사용할 수 있는 장비 식별/주소 지정 체계를 가진다.
- 점점 커지는 네트워크에 적절하다.
- 유일한 주소를 보장하기 위해 주소체계를 중앙에서 관리한다.
- 라우팅에 용이하다.
- 장비보다는 네트워크를 연결하는데 초점이 맞춰져있다.
- 한 네트워크에서 다른 네트워크로 한 단계씩 데이터를 전달한다.
- 서로 다른 네트워크에 있는 장비 간에 데이터 교환이 가능하다.
- 하부 네트워크에 독립적이다.
근거리 네트워크(LAN), 무선(WLAN), 원거리 네트워크(WAN) 같은 모든 하위 계층 네트워크에서 운영이 가능하다.
- 표준과 개발 절차가 공개 되어 있다.
표준이 공개되어 있으며 RFC 절차에 따라 누구나 참여 가능하다.
TCP/IP의 단점
앞에서 말한 특징들은 대부분 TCP/IP의 장점이라고 할 수 있다. 그렇다면 단점도 알아보자
- 1. 응용 프로그램 계층 프로토콜인 HTTP / HTTPS
HTTP (Hypertext Transfer Protocol)는 월드 와이드 웹 (World Wide Web)의 데이터 전송을위한 기초이지만이 프로토콜은 다양한 보안 위험을 야기하며 침투 및 도용에 취약하다.
- 2. 전송 계층 프로토콜인 TCP
TCP 3 방향 핸드 셰이크 메커니즘, 승인 메커니즘 및 혼잡 제어 메커니즘은 네트워크가 불안정 할 때 대역폭과 시간 낭비를 초래한다.
- 3. 인터넷 레이어 프로토콜인 IP
IP 주소는 종종 실제 주소와 연결된다. 사회 공학 기술을 사용하여 해커는 주소를 개인에게 연결하고 개인을 프로파일링하며 사기 행위를 저지를 수 있다. 플랫폼은 또한 주요 식별자 중 하나로 IP 주소를 사용하므로 관련 광고를 제공하기 위해 IP 탐색을 추적한다.
- 4. 데이터 링크 계층 프로토콜로서의 이더넷
CSMA / CD를 사용하는 버스 토폴로지 구조는 대량의 충돌 발생시 정체를 일으킬 수 있다. 만약 중앙 노드가 실패하면 전체 네트워크를 사용할 수 없다. 네트워크에 변동이 발생하면 TCP / IP는 대역폭 사용량을 제대로 관리 할 수없고 전송 효율을 빠르게 저하시킬 수 없으며 블록체인과 같은 대규모 정보 방송 네트워크를 완벽하게 지원할 수 없어 최신 블록과 동기화하여 이미 채굴 된 블록의 시간과 리소스를 낭비한다. 또한 TCP / IP 보안 구성 요소에 필요한 배포 및 학습 비용으로 인해 부적절한 배포로 인한 잠재적 취약성이 남아있을 수 있다. 또한 모든 블록체인 관련 통신 (예 : 검증, 보안, 데이터 저장을 위해 블록 체인에 의존하는 통신)은 TCP / IP를 통해 동일한 문제를 겪게된다.[5]
각주
- ↑ 한솔, 〈TCP/IP 의 기본 개념〉, 《개인 블로그》, 2003-12-09
- ↑ JHEPARK, 〈TCP/IP 역사와 표준화 관련〉, 《티스토리》, 2015-11-10
- ↑ 별의수다, 〈TCP/IP(Transmission Control Protocol / Internet Protocol) 프로토콜 개요〉, 《네이버 블로그》, 2018-01-14.
- ↑ 4.0 4.1 TCP 나무위키 - https://namu.wiki/w/TCP
- ↑ 아스카쨩, 〈TCP/IP 프로토콜의 문제점을 해결하는 새로운 인터넷 프로토콜〉, 《토큰포스트》, 2019-12-03
참고자료
- 미니송, 〈TCP/IP 프로토콜에 대한 설명, TCP,IP의 개념〉, 《티스토리》, 2017-08-11
- 인터넷 프로토콜 스위트 위키백과, 〈인터넷 프로토콜 스위트〉, 《위키백과》
- Jung Woo, 〈TCP 개요, 기능, 특성〉, 《블로거》, 2014-06-09