인프런 - 모든 개발자를 위한 HTTP 웹 기본 지식에서 김영한 님이 강의해주는 내용을 바탕으로 정리를 진행했습니다. 강의를 직접 듣고 싶으신 분들은 하단 북마크를 눌러주세요.
*제 포스팅에 나오는 모든 이미지는 김영한 님께서 만든 강의 자료에서 가져왔습니다.
요약 정리
전체 내용을 보기 쉽게 요약 정리해둔 부분입니다. 자세히 알기 원하는 문장을 선택하시면 관련 섹션으로 이동합니다.
들어가며
인터넷 네크워크에서는 어떤 식으로 인터넷에서 통신이 이루어지는지를 보고 통신이 이루어지기 위한 IP, TCP, UDP, PORT, DNS 에 대한 공부를 진행합니다.
웹, HTTP는 인터넷 네트워크 망에 기반해서 통신하기 때문에 사전 네트워크에 대한 기본 학습이 필요합니다. 이번 챕터에서 네트워크에 대한 기본 학습을 진행해봅시다. (ง˙∇˙)ว
인터넷 네트워크
만약, 컴퓨터 두 대가 통신을 진행한다고 하면 어떻게 할까요?
옆에 있는 컴퓨터 두 대라면, 선을 연결해서 통신을 주고 받을 수 있겠네요.
하지만 서로 멀리 떨어져 있는 상황에서는 어떻게 해야할까요?
이런 상황에서는 인터넷 망을 통해서 메시지를 보내야 합니다. 하지만 인터넷 망은 복잡합니다. 우리는 얽히고 설킨 인터넷 망 사이에 중간 노드들을 거쳐서 안전하게 목적지까지 데이터를 전달해줘야 합니다.
그렇다면 어떤 규칙을 적용해서 복잡한 인터넷 망을 넘어가야 할까요? 어떻게 목적지까지 안전하게 갈 수 있을까요?
우리는 이걸 알기 위해서 IP(인터넷 프로토콜)에 대해서 학습해야 합니다.
IP(인터넷 프로토콜)
만약, 한국에서 미국에 있는 친구에게 메시지를 보낸다고 한다면
우리는 복잡한 인터넷 망을 넘어가기 위해서 최소한의 규칙이 필요할 겁니다. IP 주소를 통해서 복잡한 인터넷 망을 넘어가는 것이 가능해졌습니다.
복잡한 인터넷 망을 넘어가는 방법은 이렇습니다.
⓵ 메시지를 보내는 나의 클라이언트가 IP 주소를 부여받습니다.(예시 IP: 100.100.100.1)
⓶ 메시지를 받는 친구의 서버가 IP 주소를 부여받습니다.(예시 IP: 200.200.200.2)
IP 프로토콜은 지정한 IP 주소(IP Address)에 메시지(데이터)를 전달할 수 있도록 정해둔 규칙입니다.
메시지(데이터)도 그냥 보내는 것이 아니라 패킷(Packet)이라는 통신 단위로 전달되게 됩니다.
이러한 IP 패킷은 규칙을 가지고 있는데, 하단 그림의 모양을 가지고 있습니다.
•
출발지 IP : 현재 나의 IP 주소
•
목적지 IP : 보낼 친구의 IP 주소
우리는 데이터를 보낼 때 IP 패킷에 출발지 IP, 목적지 IP, 그리고 전송 데이터를 넣고 인터넷 망에 패킷을 던집니다. 던져진 패킷은 규약을 따르는 서버들에 의해서 원하는 목적지에 보내지게 됩니다. 중간 노드(서버)들은 출발지와 목적지 IP를 이해를 하고 해당 목적지에 도달할 때까지 패킷을 중간 노드들끼리 서로 던집니다. 던지다보면 목적지 IP로 IP 패킷이 도착하게 됩니다.
IP 패킷을 받은 서버는 클라이언트에게 IP 패킷을 받았다는 정보를 보내주려고 합니다.
이때도 클라이언트 때와 동일하게 IP 패킷을 만들고 인터넷 망에 패킷을 던집니다. 중간 노드(서버)들끼리 패킷을 던지다보면 최종적으로 목적지 IP에 도착하게 됩니다.
항상 같은 중간 노드를 통해서 패킷이 이동하진 않습니다. 앞서 얘기했듯 인터넷 망은 복잡합니다. 따라서 응답시에 서로 다른 노드로 던져질 수 있습니다.
IP 주소를 부여하면서 찾아가고, IP 패킷을 사용해서 데이터를 담는 방식은 복잡한 인터넷 망 사이에서 두 대의 컴퓨터가 통신할 수 있게 도와주지만 그 안엔 한계가 존재합니다.
IP(인터넷 프로토콜)의 한계
1.
비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷이 전송
내가 데이터를 담아서 목적지 IP로 패킷을 전송했는데, 그 PC가 꺼져있다면 패킷을 받을 대상이 서비스 불능 상태이기 때문에 패킷 전송이 실패할 겁니다. 하지만 나는 해당 패킷이 제대로 전달이 되었는지, 안되었는지 알 수 없습니다.
패킷을 보내는 PC에서는 받는 PC의 상태를 모르기 때문에 일단 전송을 진행합니다. 하지만 받는 PC는 서비스 불능 상태이기때문에 패킷을 받을 수 없고, 패킷을 받지 못했다고 하더라도 보낸 PC에서는 아무런 응답을 받을 수 없습니다.
2.
비신뢰성
중간에 패킷이 사라지면? 패킷이 순서대로 오지 않는다면?
•
만약 내가 IP 패킷을 인터넷 망에 던졌는데 중간 노드(서버)에 문제가 있어서 패킷이 사라졌다면?
IP는 해당 문제를 해결해줄 수 있는 방법이 없습니다. 패킷이 소실되어도 모르기 때문입니다.
•
만약 내가 IP 패킷을 순서대로 보냈는데, 목적지 IP에서는 순서에 맞지 않게 도착했다면?
IP는 해당 문제를 해결해줄 수 있는 방법이 없습니다. 패킷들이 중간 노드를 타고 진행되는 흐름에 대해서 제어를 할 수 없기 때문입니다. 그리고 순서가 바뀌어서 도착한 패킷에 대해 목적지 IP가 순서 구분을 할 수 없기 때문입니다.
패킷의 용량이 되게 크다면(1,500바이트 이상) 보통 패킷을 끊어서 보내게 됩니다. 2개로 나눠진 패킷들은 항상 같은 노드를 타고 이동하지 않습니다. 중간에 서로 다른 노드를 타고 목적지 IP로 이동하게 될 수도 있습니다. 이때 2번째 순서를 가진 패킷이 1번째 순서로 들어가야 하는 패킷보다 먼저 도착하게 된다면 순서 문제가 발생하게 됩니다.
3.
프로그램 구분
같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?
한 PC에서는 여러 프로그램이 진행될 수 있습니다. 그렇다면 이 프로그램들을 구분하는 기준은 뭘까요? 지금 도착한 패킷이 어떤 프로그램에게 보내진 패킷인지 어떻게 알 수 있을까요?
IP는 프로그램을 구분할 수 있는 방법이 없습니다.
그렇다면 IP의 한계를 해결할 수 있는 방법은 뭘까요?
바로 TCP 입니다.
TCP(전송 제어 프로토콜)
인터넷 프로토콜 스택의 4계층을 보면,
인터넷 계층 위에 전송 계층이 있고 그 안에 TCP, UDP가 있는 걸 볼 수 있습니다. TCP, UDP는 IP를 보완해주는 역할을 합니다. 어떻게 보완하는지 알아보기 위해서 상황을 한 번 가정해봅시다.
애플리케이션에서 Hello, World! 라는 메시지를 전송하는 상황을 가정해봅시다.
⓵ Socket 라이브러리를 통해서 애플리케이션 계층에서는 메시지(데이터)를 OS로 넘깁니다.
⓶ OS 계층에서 TCP가 메시지(데이터)에다가 TCP 정보를 씌웁니다. - 초록색 부분
⓷ IP가 IP 정보를 씌웁니다. - 노란색 부분
⓸ 네트워크 인터페이스에 있는 LAN 카드를 통해 나가면서 Ethernet frame이 포함됩니다. - 검은색 부분
*Ethernet frame에는 LAN 카드에 등록된 맥 주소같은 물리적인 정보가 포함되어 있습니다.
위에 무언가를 덮어씌운다는건 알겠는데, 그게 무슨 역할을 하는걸까요?
위에서 계속 우리가 얘기하고 있는 패킷(Packet)은 Package(화물)와 Bucket(덩어리)의 합성어입니다. 화물 덩어리, 즉 택배 박스 입니다.
우리는 IP 패킷을 보낼 때 출발지, 목적지 IP 주소를 추가해서 보냈습니다. 택배를 보낼 때 보내는 사람과 받는 사람의 주소를 적어서 보내는 거처럼요. IP에서는 보내는 사람과 받는 사람의 주소를 적긴 적었는데, 아파트 이름만 적어서 보낸겁니다. 몇동, 몇호로 보내야 하는지를 명시하지 않은거예요.
TCP 정보에서는 아파트 이름을 보완해줄만한 정보를 적어줍니다. 예를 들어서 몇동, 몇호로 보내야하는지 추가로 적어주는거죠.
TCP 세그먼트는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 포함하고 있습니다.
TCP는 이름 그대로 전송을 어떻게 할 지 제어해주는 역할을 하는 프로토콜입니다. TCP가 가지고 있는 전송 제어, 순서, 검증 정보 등으로 IP만으로는 해결이 안됐던 순서 제어 문제 같은걸 해결할 수 있게 됩니다.
TCP의 특징
1.
연결지향 - 3 Way Handshake
TCP/IP 프로토콜로 연결을 하면 “쟤랑 나랑 연결이 되었나?”를 먼저 확인합니다. 연결이 되었는지 확인이 되면 전송하려던 데이터를 보내는거죠.
⓵ SYN 메시지를 통신할 PC에 보냅니다.
⓶ 메시지를 받은 PC는 메시지를 받았고 해당 요청을 수락한다는 의미로 SYN + ACK 메시지를 보냅니다.
⓷ 처음에 요청을 보낸 PC에서 요청을 수락한다는 의미로 ACK 메시지를 보냅니다.
⓸ 연결이 되었기 때문에 데이터를 전송할 수 있습니다.
⓹ 만약 연결이 불가능한 상태라면 데이터 전송을 하지 않습니다.
*요즘엔 최적화가 되어서 ⓷에서 ACK 메시지를 전송할 때 데이터를 같이 전송합니다.
통신 이전에 연결이 가능한 상태인지 먼저 확인하기 때문에 클라이언트, 서버 모두 서로를 믿을 수 있는 상태가 됩니다. 하지만 3 Way Handshake를 통한 연결은 진짜 연결된 게 아닙니다. 개념적으로만 연결되어 있는 상태입니다.
개념적으로만 연결되어 있는 상태? 무슨 말이냐?
실제로 중간엔 수 많은 서버들이 존재합니다. 중간 노드(서버)들이 연결이 되었는지, 안되었는지는 알 수 없습니다. 하지만 개념적으로 우리끼리 “연결이 되었다고 생각하자!” 라고 약속을 한겁니다. 내 PC를 위한 통신 전용 랜선이 생겼다고 보장할 수는 없지만 그냥 개념적으로는 연결이 됐다고 생각하시면 됩니다.
2.
데이터 전달 보증
데이터를 전송했을 때, 데이터를 받은 PC에서 데이터를 잘 받았다고 응답을 보내는 겁니다.
응답을 받은 PC는 내가 보낸 데이터가 잘 전달이 되었는지, 안 되었는지 이해할 수 있습니다. 응답이 없다면 문제가 생겼다는 걸 바로 알 수 있겠죠.
3.
순서 보장
만약 내가 1, 2, 3 순서로 패킷을 전송했을 시에 받는 PC에서 패킷 순서에 문제가 생긴 채로 받는다면, 문제가 생긴 부분부터 패킷을 다 버리고 다시 패킷을 전송해달라고 요청하는 겁니다.
물론, 받는 PC(서버)에서 순서를 다시 정렬하도록 최적화 가능하겠지만 기본적으로는 다시 보내달라고 요청을 합니다.
TCP가 이런 특징들을 가질 수 있는 이유는 TCP 세그먼트가 전송제어 정보, 순서 정보, 검증 정보를 가지고 있기 때문입니다. 우리는 TCP를 신뢰할 수 있는 프로토콜이라고 합니다. TCP는 신뢰할 수 있기 때문에 대부분의 애플리케이션 전송 계층에서 TCP를 사용합니다.
그렇다면, TCP 옆에 UDP는 뭔가요? 대부분의 애플리케이션이 TCP를 사용한다면, UDP는요?
UDP(사용자 데이터그램 프로토콜)는 기능이 없는 하얀 도화지라고 생각하시면 됩니다.
UDP(사용자 데이터그램 프로토콜)
UDP도 TCP처럼 IP위 전송 계층에 있는 프로토콜입니다. 하지만 기능이 없는 하얀 도화지입니다.
기능이 없는 하얀 도화지라고 얘기하는 이유는 TCP처럼 이런 것들을 보장해주지 않습니다.
•
연결 지향 X
•
전달 보증 X
•
순서 보장 X
즉, IP 와 똑같습니다. 하지만 그 위에 PORT와 Checksum 정보가 추가됩니다.
•
PORT
앞서 TCP에서 출발지, 목적지 PORT 라는 이름으로 PORT를 접하셨을겁니다.
하나의 IP에서 여러 애플리케이션이 돌아가면 들어오는 여러 패킷들이 전달되어야 하는 애플리케이션도 다 다를겁니다. 하지만 IP는 이를 구분할 수가 없었죠. 하지만 TCP, UDP는 PORT를 가지고 있기 때문에 이를 구분할 수 있습니다.
PORT에 대한 자세한 얘기는 PORT 섹션에서 하겠습니다.
•
Checksum
해당 데이터가 맞는 데이터인지 검증해주는 정보입니다.
보시다시피 UDP는 가지고 있는 정보가 많이 없기 때문에 단순하고 빠릅니다.
TCP의 경우에는 다 좋지만 넣을 정보가 많고 데이터 양이 크기 때문에 전송 속도를 빠르게 만들기 어렵습니다. 또한, 3 Way Handshake를 하는데 시간이 걸립니다. TCP를 더 최적화하는 것은 불가능하며 규약이 정해져있기 때문에 손을 댈 수가 없습니다.
하지만, 더 최적화하고 싶다면 TCP는 그대로 두고 UDP를 손대면 됩니다.
UDP는 아무것도 없는 하얀 도화지 입니다. 따라서 원하는 작업이 있다면 UDP에서 해주면 됩니다.
HTTP/3에서는 앱 브라우저에서 HTTP 통신을 진행할 때, 3 Way Handshake 까지 최적화를 시켜보자는 의미로 UDP를 사용합니다. HTTP/3는 UDP를 사용함으로써 Handshake 과정 자체를 날려버리고 다른 방법으로 연결의 신뢰성을 확보함으로써 레이턴시를 줄이는 방법을 택했다고 하네요.(참고블로그)
아무튼 TCP만 기본적으로 알고 있으면 앞서 진행할 내용을 이해하기 편할겁니다.
PORT
아까 UDP 섹션에서 얘기하고 있던 PORT에 대한 얘기를 더 해봅시다.
위에서 제가 TCP, UDP는 PORT를 가지고 있기 때문에 어떤 애플리케이션으로 보낸 패킷인지를 구분할 수 있다고 했습니다. 그렇다면 한 번에 두 개 이상의 PC를 연결하는 상황을 가정해볼게요.
제 PC는 여러 개의 서버와 통신해야 하는 상황입니다. 패킷이 제 PC가 가진 IP로 날라오는데 게임에서 필요한 패킷인지, 화상 통화에서 필요한 패킷인지, 웹 브라우저 응답으로 들어온 패킷인지 알 수 없습니다. 받았다고 해도 제 PC가 IP 200.200.200.2 서버로 패킷을 전송하게 될 시에 게임에 대한 응답으로 패킷을 보낸건지, 화상통화에 대한 응답으로 패킷을 보낸건지 해당 서버는 알 수 없습니다.
그걸 구분하게 하는 것이 PORT 입니다.
TCP 세그먼트를 보면 출발지 PORT, 목적지 PORT가 존재합니다. IP 주소는 목적지 서버가 어딘지를 알려주는 정보고, PORT는 서버에서 돌아가는 애플리케이션들을 구분할 수 있게 합니다. 같은 IP 내에서 프로세스를 구분할 때 PORT를 사용하는거죠.
우리가 게임 서버에 연결을 하고 싶다면 요청시에 { IP: 200.200.200.2, PORT: 11220 } 으로 정보를 넣어서 데이터를 보낼겁니다. 반대로 해당 서버에서 클라이언트로 응답을 보낸다면 { IP: 100.100.100.1, PORT: 8090 } 으로 응답을 보낼겁니다.
어떻게 반대쪽 서버가 내 PORT를 아는거죠?
우리가 패킷을 전송할 때 출발지 IP와 출발지 PORT를 다 보냅니다. 따라서 적절한 애플리케이션으로 응답 패킷을 보내줄 수 있는겁니다.
PORT는 0 ~ 65535까지 할당 가능하고, 0 ~ 1023은 잘 알려진 포트이기 때문에 사용하지 않는 것이 좋습니다.
잘 알려진 포트
DNS(도메인 네임 서비스)
우리가 앞서 봐온 IP 주소를 보면 이런 생각이 들겁니다.
기억하기 어렵다!!
우리가 구글 웹 페이지에 들어가기 위해서 200.200.200.2를 입력하진 않습니다. google.com를 입력하겠죠?
그리고 IP는 계속 같은 값을 가지고 있지 않습니다. 변경될 수 있습니다. 갑자기 200.200.200.2 였던 것이 200.200.200.3 으로 변경될 수 있습니다. 그렇다면 200.200.200.2 IP 주소를 알고 있는 사람들은 갑자기 접근이 안되는 문제가 생길겁니다.
이런 문제를 해결하기 위해서 DNS를 사용합니다.
DNS는 중간에 전화번호부같은 서버를 제공해줍니다. 서버에 도메인명을 등록하고 해당 도메인명으로 IP 주소를 변환합니다. 우리는 DNS 서버에 도메인을 사서 등록 가능합니다.
⓵ 클라이언트가 도메인명을 DNS 서버에게 물어봅니다.
⓶ DNS 서버는 해당 도메인 명에 맞는 IP를 응답으로 보내줍니다.
⓷ 클라이언트는 해당 IP로 접속합니다.
만약, IP 주소가 중간에 바뀐다면 서버에서 바뀐 IP 주소를 DNS 서버에 넣고, 서버 IP 주소를 변경하게 됩니다.
DNS 서버가 있으면 IP 주소를 기억하기 어려운 문제, IP가 변경될 수 있다는 문제를 모두 해결할 수 있습니다. 마치 전화번호부처럼 도메인 명에 맞게 IP 주소를 가지고 있으니깐요.