TCP 정의
TCP란 Transmission Control Protocol 의 약어로 컴퓨터가 다른 컴퓨터와 데이터 통신을 하기 위한 규약(프로토콜(协议))의 일종이다. TCP는 세계 통신 표준으로 개발된 OSI 모형에서 4번째 계층인 전송 계층(Transport Layer)에서 사용하는 규약으로, 보통 하위 계층에서 사용하는 IP와 엮어서 TCP/IP로 표현하는 경우가 많다.
- 즉, 전송 계층에서 사용하는데, 하위 계층에서 사용하는 IP와 역어 TCP/IP로 표현된다.
TCP stands for Transmission Control Protocol which indicates that it does something to control the transmission of the data in a reliable way.
TCP 개발 동기
TCP의 개발 동기는 군사적인 목적이 시작이었다. 적국이 푝격, 심지어 핵전쟁이 발발하더라도 죽지 않고 정상적으로 동작하는 네트워크를 기초로 만들어졌다.
옛날 통신방식으로는 회션교환(CirCuit switching)(영화나 드라마 일제 강점기에서 자주 나오는 다이얼 형태의 방식)이 있었는데, 이 방식은 예를 들어 서울에서 부산으로 간다고 할 때 미리 이동할 경로를 경부고속도로만 이용한다로 정해놓은 방식이다. 이런 상황은 통신을 중계해주는 곳이 망가지너나 단락이 되면 통신이 바로 끊키는 상황이 벌어진다.
이에 따라 사용 된것이 패킷교환(Packet switching) 방식인데, 회선 교환가 다르게 경로가 정해져 있지 않다. 경부고속도로가 심각하게 막히면 다른 고속도로나 국도를 우회해서 가는 방식이다. 따라서 서로 연결이 가능한 회선 하나만 남아있어도 통신이 끊켜도 우회에서 통신할수 있는 환경이다. 다만 이 방식은 어떻게든 통신을 유지하는 것이 목적이므로, 네트워크의 환경이 떨어진다. 이로 인해 중간에 데이터가 유실되거나 너무 늦게 전달 되는 등 신뢰성이 떨어지는 문제점이 있다.
이런 문제점을 해결하고자 통신 규약 TCP가 개발되었다.
The process of communication between devices over the internet happens according to the current TCP/IP suite model(stripped out version of OSI reference model). The Application layer is a top pile of stack of TCP/IP model from where network referenced application like web browser on the client side establish connection with the server. From the application layer, the information is transferred to the transport layer where our topic comes into picture. The two important protocols of this layer are – TCP, UDP(User Datagram Protocol) out of which TCP is prevalent(since it provides reliability for the connection established). However you can find application of UDP in querying the DNS server to get the binary equivalent of the Domain Name used for the website
TCP 연결 설정
TCP는 전화를 거는 것처럼 상대와 연결을 설정하고 통신을 시작한다.
TCP provides reliable communication with something called Positive Acknowledgement(접수) with Re-transmission(PAR). The Protocol Data Unit(PDU) of the transport layer is called segment. Now a device using PAR resend the data unit until it receives an acknowledgement. If the data unit received at the receiver’s end is damaged(It checks the data with checksum functionality of the transport layer that is used for Error Detection), then receiver discards the segment. So the sender has to resend the data unit for which positive acknowledgement is not received. You can realize from above mechanism that three segments are exchanged between sender(client) and receiver(server) for a reliable TCP connection to get established. Let us delve how this mechanism works
공식적인 TCP 연결 절차로 Three way Handshake
1) 상대에게 통신을 하고 싶다고 메세지를 보낸드 (SYN(Synchronize Sequence Number))
2) 상대는 그 메세지에 대한 응답 + 나도 통신 준비가 되었다는 메세지를 보낸다. (SYN-ACK(Synchronize Sequence Number+Acknowledgement))
3) 2번에서 받은 메세지에 응답을 보낸다(ACK)
이와 같이 과정을 통해 나와 상대가 통신준비를 맞쳤고, 현재, 통신이 연결되어 있음을 보장하게 된다.
기존의 회선 교환 방식의 개념과 유사하지만 단순히 서로 연결되어 있는 것만 보장한다.
- Step 1 (SYN) : In the first step, client wants to establish a connection with server, so it sends a segment with SYN(Synchronize Sequence Number) which informs server that client is likely to start communication and with what sequence number it starts segments with
- Step 2 (SYN + ACK): Server responds to the client request with SYN-ACK signal bits set. Acknowledgement(ACK) signifies(의미하다) the response of segment it received and SYN signifies with what sequence number it is likely to start the segments with
- Step 3 (ACK) : In the final part client acknowledges the response of server and they both establish a reliable connection with which they will start the actual data transfer
The steps 1, 2 establish the connection parameter (sequence number) for one direction and it is acknowledged. The steps 2, 3 establish the connection parameter (sequence number) for the other direction and it is acknowledged. With these, a full-duplex communication is established.
Note – Initial sequence numbers are randomly selected while establishing connections between client and server.
공식적인 TCP 연결 해제 절차로 four way Handshake
TCP의 연결을 해제(Connection Termination) 하는 과정
- 예를 들어, A 프로세스(Client)가 B 프로세스(Server)에 연결 해제를 요청
- A->B: FIN
- 프로세스 A가 연결을 종료하겠다고 FIN 플래그 전송
- 프로세스 B가 FIN 플래그로 응답하기 전까지 연결을 계속 유지
- B->A: ACK
- 프로세스 B는 일단 확인 메세지를 보내고 자신의 통신이 끝날 때까지 기다린다.(이상태가 TIME_WAIT 상태)
- 수신자는 Acknowledgement Number 필드를 (Sequence Numb er + 1)로 지정하고, ACK 플래그 비트를 1로 설정한 세그먼트를 전송한다.(자세한 설명은 TCP 개념 2에 설명)
- 자신이 전송할 데이터가 남아있다면 이서어 계속 전송한다.
- B-> A: FIN
- 프로세스 B가 통신이 끝났으면 연결 종료 요청합이한다는 의미로 A에게 FIN 플래그 전송한다.
- A-> B: ACK
TCP 신뢰성 보장과 흐름 제어 (Flow Control)
연결 설정을 통해 통신 준비를 맞치면 이제 서로 데이터를 주고 받을 수 있다. 다만 네트워크를 통해서 한 번에 보낼 수 있는 데이터의 양은 제한되어 있어 분할해서 보내야 한다.(약간 토렌트 방식)
간단히 비유하면 책 한 권 내용을 보내줘야하는데 이것을 통째로 전송할 수 없으므로 한 장씩 보내는 것으로 생각하면 된다. 따라서 분할된 데이터에는 고유 번호가 부여되는데 이 는 책의 쪽 번호와 같다고 생각하면 된다. 이를 바탕으로 보내는 사람은 현재 몇 쪽을 보낸 것인지 상대에게 알려줄 수 있고, 받는 사람은 다음에 받을 자료가 몇쪽인지를 알고 보내는 사람에게 요청할 수 있게 된다.
이를 통해 데이터가 제대로 전달됐는지도 알 수 있다. 예를 들어 31쪽을 받을 차례인데 31쪽이 안오고 다른 데이터가 도착하면, “31 쪽을 보내주세요” 요청하도록 TCP가 설계되어 있다. 그러면 보내는 사람은 상대가 요청한 31쪽을 보내주게 된다. 더불어 47쪽을 보낼 떄 알람을 설정하게 되어 있는데, 만약 알람이 울릴 때까지 받는 사람이 48쪽을 달라고 하지 않는다면 역시 데이터가 누락된 것으로 추측할 수 있다. 이를 근거로 보내는 사람은 47쪽을 다시 전송할 수 있다.
여기까지 언급된 것만 보면 컴퓨터끼리 통신을 할 때 마치 데이터 하나씩만 전달 하는 것처럼 보일 수 있다. 물론 그렇게 통신한다고 해서 문제가 되는 것은아니나 당연히 상대가 많이 받을 수 있다면 많이 보내주는 것이 효율적이다. 하지만 무턱대고 보낼 수 있는 것도 아니다. 상대가 5쪽만 받을 수 이쓴ㄴ데 보내는 쪽에서 닥치고 10쪽씩 보내버리면 어차피 5쪽은 못 받고 누락되는 것은 마찬가지 이다. 따라서 받는 쪽에서 “나 32쪽 받아야함, 그러나 6쪽만큼 받을 수 있음”이라 알려주면 보내는 쪽에서 32쪽에서 37쪽까지 자료를 보내는 방식으로 동작한다.
이를 위한 TCP 헤더 파일을 살펴 보면
- 목적지 주소
- 확인 응답
- 오류 검출 및 복원
- 실제 데이터
이중 중요한 역할이 확인 응답인데, 확인 응답(Acknowledge) 파일은 송수신 시 꼐속 확인 응답을 보내어 잘 갔는지, 잘 왔는지 확인을 하여 데이터 신뢰도를 높인다. 하지만 데이터 용량이 증가하여 수신 속도가 떨어진다 는 단점이 있다. 그러나 단점보다는 신뢰성이 높다는 장점이 훨씬 크기 떄문에 무시한다.
TCP 혼잡 제어 (Congestion Control)
Congestion Control은 초기 TCP에는 없던 요소이다. 한정된 네트워크 대역폭에서 소수의 사람들이 쓸때는 몰랐지만, 사용자가 점점 늘어나다보니 네트워크 회선이 그 부하를 감당하지 못하고 사망하는 것이 원인이다. 여기서 말하는 사망이란, 송신해야 할 책의 날장이 중간에 있는 네트워크 기기(라우터 등)에 무한히 몰리게 되는 상황을 말한다.
- 즉, 중간 네티워크 기기가 송신하는 날장의 속도가 그 기기가 수신하는 속도보다 느리면(즉 데이터를 받는 Client보다 데이터를 보내는 Server의 송신이 느리면)이러한 상황이 발생하게 된다. 독이 깨져있어서 물이 새는데, 물이 새는 속도보다 더 빨리 물을 채운다면 독이 넘치는 것과 같다.
이 상황에서 기존 TCP는 위에 언급 했던 방식대로 동작한다고 생각해보자. 그러면 다음 과 같은 일이 발생한다.
- 송신자A: ‘이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!’
- 송신자B: ‘이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!’
- 송신자C: ‘이상하네, 벌써 47쪽을 보낸 지 한참 됐는데 왜 받았다는 연락이 안 올까. 한 번 더 보내야겠다!’
…
여기서 A,B,C는 라우터로 송신하는 (독을 물을 붓는 사람, Client) 사람들이다. 이미 라우터에는 아직 라우터가 미쳐 다 송신하지 못한 A,B,C의 날잘들이 남아 있다. 그런데 A,B,C가 각각 날장을 또 보내는데 크게 두가지 문제가 있다.
-
라우터의 저장에도 한계 용량이 있다. 독의 크기가 유한하기 때문에 물을 너무 많이 부으면 넘친다. 그 넘친 물을 다시 독으로 들어오지 않듯, 그렇게 라우터 내에 저장 공간에 저장되지 못한 날장들은 손실된다.
-
흐름 제어(Flow contorl)의 예시에서 보듯, 47쪽을 보냈는데 답신이 없으면 또 47쪽을 보낸다. 만약 라우터가 무한한 저장 공간을 가진다는 비현실적인 가정하에더라도, 결국 라이터에 쌓여가는 날장들 때문에 48쪽을 보낼 때까지 47쪽을 비정상적으로 많이 보낸다. 이는 비효율적이다. 심지어 그러한 가정도 없다면, 보내지는 날장들은 그저 종이의 낭비다(버려지는 패킷을 위해 전력을 사용했으니, 전력 낭비이다)
이러한 문제를 해결하기 위해 Congestion Control 요소가 TCP에 추가되었다.
단순한 예로 통신을 시작할 때 일단 보내는 쪽에서 30~35쪽까지 자료를 보낸다. 그래서 상대가 잘 받았으면 이후 보내는 양을 조금씩 늘려보는 방식을 취한다. 그러다 상대가 데이터를 제대로 받지 못한 것이 확인 되면 그 직시 보내는 양을 확 줄인다. 그리고 다시 슬금 슬금 보내는 양을 늘렸다가 또 못 받으면 줄여버리는 형태로 보내는 양을 조절하게 된다. 보내는 양을 늘리고 줄이는 방법은 AIMD(Addictive increase/Multicative Decrease) 를 채택하고 있으나, 구체적으로 적용되는 방식은 TCP 버전마다 방식이 다르다.
이 방식은 Bust를 줄이기 위한 이다. 깨진 독에 어떻게 물이 차오르기 시작하는지를 생각해보면 어렵지 않다. 어느 순간 빠지는 속도보다 들어오는 속도가 커지는 순간이다. 이것을 버스트라고 부르는데, 요점은 버스트가 나지 않으면 물이 차오르기 시작할 일도 없다. 버스트가 발생해서 물이 차오르기 시작했따면, 일단 물을 다 빠진 다음에 물을 부으면 된다는 생각이다. 이를 네트워크 환경에 맞춰 해석하면, 처음에 버스트가 생기지 않을 적절한 양을 보내고, 버스트가 일어나 라우터에 날장들이 쌓이기 의심이 된다면, 일단 라우터에서 그 날장들이 빠지는 것을 기다리는 방법이 되는 것이다.
위 방법을 통해 TCP로 통신하는 모든 사용자들이 네트워크 상황에 따라 속도를 조절할 수 있게 되었으며, 많은 사용자들이 동시에 통신을 시도하면 속도에서 손해를 보지만 죽지는 않게 되었다. 이론적으로 100Mbps 회선에서 5명의 사람이 동시에 TCP로 통신을 시도한다면 초반에는 서로 차이가 있지만 궁극적으로는 100Mbps회선을 각각 20Mps씩 공평하게 나눠 가지는 효과를 가지게 된다.
TCP 통신에서 중요한점
- 데이터 누락을 막고 Three handshake를 통해 항상 연결 상태를 유지해야한다
- Client가 받을 수 있는 할당 데이터량이 있다. 그 한계를 넘어 버린 상태에서 서버가 데이터를 보내게 되면 데이터 누락이 생긴다.
- 그렇기 때문에 Client측에서 한번에 받을 수 있는 데이터량을 Server에 보낸다.
- ACK를 계속 보내서 잘 받았는지 잘 보내졌는지 확인 응답을 계속 보낸다.
- 사용자가 많으면 네트워크 회선에 부하가 걸려서 사망하게 된다. 그렇기 때문에 TCP에서 Congestion Control 요소가 중요하다.
그외 이야기
현존하는 상당수의 네트워크 프로그램은 TCP를 기반으로 통신한다. 그만큼 데이터 신뢰성을 중요시하는 프로그램들이 많다. 이메일이나 파일 전송같은 경우 데이터 하나가 날아가면 꽤 골치아픈 문제가 발생한다. 하지만 TCP에서 제공하는 신뢰성 보장 방법들을 반드시 사용할 필요는 없다. 만약 프로그램에서 필요하지 않든다면 구현하는 과정에서 기능을 끌 수 있게 되어 있다. 물론 그만큼 신뢰성이 떨어지는 상황은 감수해된다.
- 즉, 컴퓨터 간에 라우터로 네트워크를 전송 받을 때, TCP, C++의 데이터 구조에서 펑션이나 데이터 멤버들을 이용하여 이와 같은 규약을 지켜 데이터의 안전성과 흐름을 보장한다.
- Three handshake
- Flow Control
- Congestion Control
그 외에 TCP 자체가 오히려 비효율 적인 경우도 발생한다. 대표적으로 실시간성을 중요시하거나 응답성을 중요시하는 프로그램인데 이를 위해 개발 된것이 바로 UDP이다.
정리
- TCP는 데이터 전달을 관리하는 규칙
- 데이터를 작게 나누워서 한 쪽에서 다른쪽으로 옮기고, 이를 다시 조립하여 원래의 데이터로 만드는 규칙(Torrents)
- 여기서 잘게 나뉜 데이터 단위를 패킷
- 인터넷에서는 정보를 전달하는 단위
- TCP는 패킷을 조립하고, 손실된 패킷을 확인하고, 재전송하도록 요청하는 기능
Reference
https://namu.wiki/w/TCP
https://www.geeksforgeeks.org/tcp-3-way-handshake-process/
