😗TCP? HTTP랑 비슷한 거 아님?

Intro.

TCP에 대해서 알려면 사실 배경지식이 많아야 한다고 생각한다. OSI 7계층, IP, UDP 등... 다양한 정보와 뗄레야 뗄 수 없는 관계를 가지고 있는 프로토콜이기 때문이다. 이런 주제들도 앞으로 블로그에 열심히 써서 올릴테니 이번 게시글에서는 TCP가 무엇인지 간략히 알아보고 어디서 많이 들어본 TCP와 HTTP의 차이가 무엇인지를 중점으로 글을 써보겠다.

 

 

---

What is TCP?

TCP는 Transmission Control Protocol의 약자로 험난한 인터넷 세상에서 데이터를 안전하고 정확하게 전달하기 위한 프로토콜(약속)이다. 인터넷을 통해 데이터를 전송할 때 큰 데이터는 한 번에 전송할 수 없기 때문에 '패킷'이라는 단위로 잘개 쪼개어 전송하게 된다. 

 

왜 패킷으로 쪼개 보낼까? 한 번에 큰 데이터를 못 보내는 이유는 뭘까?

 

우선 첫번째는 하드웨어의 한계이다. 우리 모두가 74평짜리 펜트하우스에 살지 않는 것처럼.. 네트워크 장비마다 한 번에 처리 가능한 용량이 다를 뿐더러 물리 법칙으로 인해 한 번에 한계 이상의 데이터를 처리하는 것은 불가능하다.

 

두번째는 비용의 문제다. 인터넷 통신을 할 때는 생각보다 오류가 많이 발생한다고 한다. 만약 한 시간씩이나 걸려서 큰 용량의 데이터를 전달했는데 만약 오류가 난다면? 상상만 해도 끔찍하다. 복구하기 위해 많은 비용이 들 것이다.

 

세번째는 효율성의 문제다. 차도에서 겁나 길고 넓어서 한 번 지나갈 때 3개의 차선과 1km의 여유가 필요한 자동차가 도로를 지나간다고 생각해보자 아마 미국이었으면 총을 쏴서 전복시켰을 것이다. 그럴 공간에 많은 사람들이 동시에 지나다닐 수 있는 작은 승용차 여러 대가 도로를 이용하는 것이 유연하고 효율적일 것이다. 인터넷도 마찬가지이다. 패킷별로 다양한 최적의 경로를 실시간으로 이용해 많은 사용자의 데이터를 보내는 것이 더 효율적이다.

 

TCP는 신뢰성을 가장 중요하게 생각한다. 때문에 이미 포장된 데이터도 세그먼트라는 단위로 한 번 더 포장하여 데이터를 보내주고, 상대방에게 보낼 때도 상대방이 지금 데이터를 잘 받을 수 있는 상태인지 수시로 확인하여 데이터의 손실이나 누락이 발생하지 않도록 노력한다.

 

---

TCP의 작동 원리

TCP의 작동 원리를 큰 흐름에서 보면 3단계로 나뉜다.

1. 연결 설정 (3-Way Handshake)
2. 데이터 전송
3. 연결 해제 (4-Way Handshake)

 

3-Way Handshake

서로가 준비됐음을 서로에게 알려주고 통로를 연결하는 과정이다.

1. SYN: 클라이언트가 서버에게 SYN(synchronize) 플래그가 설정된 메시지를 보냅니다. 이때 SYN은 클라이언트의 임의 시퀀스 번호 A를 포함합니다. 
2. SYN-ACK: 서버는 클라이언트의 SYN에 응답하여 SYN-ACK 메시지를 보냅니다. 서버는 자신만의 새로운 시퀀스 번호 B를 포함한 SYN을 전송하고, 클라이언트의 시퀀스 번호 A에 1을 더한 ACK(acknowledgment)를 함께 보냅니다(A+1).
3. ACK: 클라이언트는 서버로부터 받은 SYN에 대해 ACK 메시지를 전송합니다. 이때 ACK는 서버의 시퀀스 번호 B에 1을 더한 값(B+1)을 포함합니다.

좀 어려운 소리 같이 느껴지긴 한다. SYN이 질문, ACK 답변이라고 생각하면 된다.

 

4-Way Handshake

서로 데이터를 다 전송하고 난 뒤에 통로를 철거하는 과정이다.

1. FIN: 클라이언트가 "데이터 다 보냈어, 이제 끊자"라고 신호를 보냅니다.
2. ACK: 서버가 "알겠어, 일단 확인. 나도 정리할 게 남았으니 잠시만 기다려"라고 답합니다.
3. FIN: 서버가 정리를 마친 후 "나도 준비됐어, 이제 진짜 끊자"라고 신호를 보냅니다.
4. ACK: 클라이언트가 "확인했어, 안녕!" 하고 마지막 응답을 보낸 후 종료합니다.

 

 

왜 갈 땐 3-Way였는데, 올 때는 4-Way일까?

통신을 연결하는 과정에서는 상대방이 살아있는지 확인만 하면 된다. 하지만 데이터 전송을 마치고 연결을 끊을 때는 서로 데이터를 다 보냈는지 확인하는 과정이 필요하다. TCP는 신뢰성을 중요시 여기기 때문에 통신에 에러가 있는지 마지막에도 확인한다.

 

---

TCP vs HTTP

이번엔 HTTP와의 차이점을 알아보자.(맞짱뜨면 누가 이길까)

 

우선 둘 다 데이터 통신과 관련된 프로토콜이다. 하지만, 계층과 역할에서 명확한 차이가 드러난다. TCP는 데이터를 주고 받는 통로 자체를, HTTP는 그 통로에서 주고 받는 메세지의 형태나 언어를 생각하면 쉽다. 느껴지겠지만, TCP가 하위계층으로 HTTP보다 우선시된다. 자동차가 다니려면 도로가 있어야 하는 것과 같다.

 

HTTP는 무상태성을 지닌 단방향 통신이다. '서로가 데이터를 주고 받는데 왜 단방향 통신이지?'라는 의문이 생길 수 있다. HTTP는 요청 없이 응답을 보낼 수 없다. 챗봇과 전화를 비교해보자 전화는 통화중이면 어떤 상황이든 서로가 서로에게 말을 걸 수 있다. 하지만, 챗봇은 내가 물어보지 않으면 나한테 답변을 제공할 수 없는 것과 같다. 그런 의미에서 단방향 통신이다. 그리고 이미 지겹겠지만, 서버의 효율과 확장성을 위해 HTTP는 무상태성이다.

 

TCP는 상태성을 지닌 양방향 통신이다. TCP에서 중요한 것은 신뢰성과 안정성이다. 때문에 서로가 잘 연결되어있는지 수시로 확인해야하기 위해서 상태성을 지닌다. HTTP와 다르게 서로가 서로에게 언제든 데이터를 보낼 수 있다.

 

사실 이 둘 중 하나를 선택해서 쓰는 것이 아니라 둘 다 사용해야 하기 떄문에 굳이 비교 대상이 아니긴 하다.