
TCP/IP는 인터넷에서 데이터가 이동하기 위한 기본 교통 규칙이다.
컴퓨터 끼리 '어떻게 보내고, 어떻게 받는지'를 정해둔 약속이라고 보면된다.
우리가 Express 서버에서 API 요청을 보내고 응답을 받는 것도,
사실은 모두 이 TCP/IP 위에서 이루어진다.
HTTP는 그 위에 올라가는 규칙으로, '웹에서는 요청과 응답을 이런 형식으로 주고받자!'
라고 정해둔 약속이다.
인터넷 통신을 택배 시스템으로 예를 들어 이해해보자.
IP는 주소다. '어느 집으로 보낼지'만 담당한다.
-> 목적지 안내
TCP는 택배 기사다. 물건이 순서대로 잘 도착했는지 확인하고, 중간에 분실되면 다시 보내준다.
-> 안전 배송
HTTP는 택배 박스 안에 들어있는 주문서 양식이다.
POST /users -> 'users라는 주소에 POST 요청을 보냅니다'와 같은 주문서를 발급할 수 있다.
위의 method 호출 시 내부적인 흐름은 아래와 같다.
즉 우리가 사용하는 req, res는 TCP/IP 위에서 만들어진 추상화 객체다.
인터넷은 두개 이상의 컴퓨터를 유선으로 '직접 연결'한 상태가 아니기 때문에,
전 세계 수많은 네트워크(집/회사/통신사/해외망)가
여러 장비(공유기, 스위치, 라우터)를 거쳐 연결되어 있고,
내가 보낸 데이터는 중간 경로를 여러 번 갈아타며 목적지까지 도착한다.
그래서 '데이터를 보냈다'만으로는 통신이 성립하지 않는다.
다음과 같은 문제를 해결할 규칙이 없으면,
같은 인터넷 선을 공유하는 환경에서 데이터는 쉽게 섞이거나, 유실되거나, 순서가 꼬이게 된다.
내가 보낸 데이터가 정확히 '어떤 컴퓨터'로 가야 하는지 지정할 방법이 필요하다.
이 역할을 담당하는 것이 IP 주소이고,
'목적지 IP까지 패킷을 어떻게 전달할지'를 결정하는 장비가 라우터(router) 다.
인터넷에서는 데이터가 중간에서 끊기거나(패킷 유실), 일부만 도착하거나, 아예 사라질 수 있다.
이때 '안전 배송'을 위해서는 아래와 같은 규칙이 필요하다.
이 역할을 담당하는 것이 TCP다.
따라서 TCP는 '보내긴 했는데, 상대가 진짜 받았는지'를 확인해서 통신을 안정적으로 만든다.
큰 데이터를 보내면 한 번에 전송되지 않고 여러 조각(패킷)으로 쪼개진다.
그런데 인터넷에서는 이 조각들이 아래와 같은 상황이 발생할 수 있다.
예를 들어 1,2,3,4 조각 중 3이 먼저 오고 1이 나중에 올 수도 있다.
이때 받는 쪽에서는 다음과 같은 처리를 해주어야한다.
TCP는 순서 번호(시퀀스)를 이용해 이 조립을 지원한다.
전송 중에 데이터가 손상될 수도 있다.
그래서 '보낸 내용과 받은 내용이 같은지' 확인할 장치가 필요하다.
TCP는 체크섬(checksum) 같은 방식으로 오류를 감지하고,
문제가 있으면 다시 전송하도록 한다.
정리하면 TCP/IP는 아래를 해결하기 위한 '기본 통신 규칙'이다.
IP: 주소를 붙여 목적지까지 전달(어디로 보낼지)
TCP: 안전하게 전달되도록 보장(잘 도착/순서/재전송)
그리고 이 규칙들을 계층(레이어)으로 나눠서 처리한다.
IP 계층은 '어디로'를 해결하고
TCP 계층은 '제대로'를 해결한다
이 위에 HTTP 같은 '웹용 메시지 규칙'이 올라가서,
우리가 Express로 구현한 API 요청/응답이 실제 통신으로 성립한다.