모든 개발자를 위한 HTTP 웹 기본 지식 : Internet Network

jkky98·2024년 7월 2일

HTTP

목록 보기

7/7

컴퓨터간 통신

클라이언트 컴퓨터와 서버 컴퓨터가 존재할 때 인터넷 통신에서 클라이언트의 요청은 당연하게도 인터넷 망을 통해서 전해진다. 이때 인터넷은 수많은 노드들로 이루어져 있는데 수 많은 노드들을 타고다니면서 최종 도착지인 서버에 도착한다.

https://www.submarinecablemap.com/
실제로 한국의 인터넷 노드는 일본 노드의 자식 노드이다. KT 인터넷이 하나 미국과 직통하는 길을 가지고 있다고는 한다.(해저케이블의 광섬유는 실제로 1초에 지구를 7번을 도는 속도라고 한다.)

IP(internet protocol)

현실에서 보내는 사람의 주소, 받는 사람의 주소를 보내는 사람이 운송장에 적어서 택배를 보내곤 한다. 인터넷 통신도 똑같이 IP(주소)로 하여금 클라이언트와 서버 IP주소를 담아 요청을 인터넷망으로 뿌린다.

지정한 IP주소로 데이터를 전달하며, 패킷이라는 통신 단위로 데이터를 전달한다.

IP패킷에는 그러므로 출발지IP, 도착지IP, 기타... + 전송데이터가 실린다.

IP의 한계

만약 클라이언트가 IP패킷을 인터넷망으로 보냈는데 도착지 주소의 컴퓨터가 꺼져있다면 답을 받을 수 없다. 요청은 이미 갔지만 대답은 돌아오지 않는 것이다. 받았는지 안받았는지조차 알 수 없다.

또한 패킷을 여러 개 보냈을 때 패킷이 순서대로 오지 않거나, 아예 패킷이 도중 누락되거나 하여도 받는 서버측 입장에서는 곤란한 지점이 생기지 않는다. 그냥 안왔을 뿐이니까.(보낸이가 곤란하겠지)

또한 서버에서 통신하는 애플리케이션이 여러개라면 IP주소만으로 어떤 애플리케이션과 소통해야하는지 알 수 없다. 모든 애플리케이션에 전달메세지를 주며 에러를 내고 다닐수는 없을 것이다.

TCP의 등장

TCP는 이러한 IP의 단점들을 극복시켜 준다. 인터넷 프로토콜 스택의 4계층은 아래와 같다.

IP위에 TCP의 과정이 존재함을 확인할 수 있다.

위의 과정으로 네트워크 통신의 예를 볼 수 있다. Hello, world! 라는 데이터를 HTTP 통신에 맞는 형식으로 소켓에 HTTP 패킷을 전달하면 소켓은 OS로 이를 전달하며 OS는 TCP패킷을 생성 -> IP패킷을 생성하고 최종적으로 LAN장비를 이용하여 인터넷 망으로 도착지를 찾아 패킷은 떠나게 된다.

TCP/IP 패킷 정보

IP 패킷안에 감싸져있는 TCP 세그먼트에는 출발지 PORT, 도착지 PORT와 전송제어, 순서, 검증정보등이 들어있다.

TCP의 특징

TCP 3 way handshake라는 방법을 통해 연결을 확인한다.(IP만 이용했을 때의 문제를 극복한다.) 데이터 전달을 보증하며 순서를 보장한다.

TCP 3 way handshake

TCP는 통신 이전 서로의 연결을 확인할 수 있는 방법을 제시한다 그것이 바로 TCP 3 way handshake이다. 클라이언트에서 서버로 SYN(접속 요청)을 보내고 그것을 받은 서버는 클라이언트에게 SYN(접속 요청) + ACK(요청 수락)를 보낸다. 다시 클라이언트는 서버에게 ACK(요청 수락)을 보낸다. 이로써 본격적인 통신전에 서로의 연결을 확인한다. 이 과정은 논리적인 절차일 뿐 실제로 패킷이 노드를 지나는 과정에서 노드들은 이 사실을 알지는 못한다.

데이터 전달 보증 : TCP는 데이터를 전송할 때 수신자로부터 확인 응답(ACK)을 받는다. 송신자는 데이터를 전송한 후, 수신자로부터 해당 데이터가 성공적으로 도착했다는 확인 응답을 받기 전까지는 데이터를 전송한 것으로 간주하지 않는다. 만약 일정 시간 내에 확인 응답을 받지 못하면, 송신자는 해당 데이터를 다시 전송한다.
순서 보장 : 서버로 여러 패킷이 들어올 때 서버에서 받는 패킷의 순서가 틀리다면 서버는 클라이언트에게 순서가 틀린 패킷부터 패킷을 다시보내라고 요청한다.

UDP(User Datagram Protocol)

UDP는 하얀 도화지에 비유된다. TCP는 IP의 보완적인 성격이 강한데, UDP는 IP랑 다를 것이 없기 때문이다.(Port, 체크섬 정도만 추가) 즉 UDP는 추가 작업을 필요로 한다. 그러므로 여태 HTTP통신을 이용하는 사람들(개발자)은 대부분 TCP체제를 사용해왔지만 최근 UDP의 사용이 많아지고 있다. 실제로 UDP는 TCP 3 way handshake와 같은 방식을 사용하지 않으므로 속도비용적으로 우수하다고 할 수 있기에 극한을 추구하기 위함인 것 같다.

Port

사실 IP는 집 주소라는 느낌보다는 아파트 동의 느낌이다.(범위가 더 넓다.) 포트를 통해 여러 애플리케이션(xxx동 xxx호)이 동시에 같은 IP 주소(xxx동)를 사용할 수 있으며, 서로 다른 네트워크 서비스가 동일한 물리적 네트워크 연결을 통해 통신할 수 있다.

포트 정보는 TCP에 담기며 더 바깥을 감싸는 IP패킷에 IP주소가 담긴다.

포트 번호는 0부터 65535까지의 숫자로 구성되며 이들은 다음과 같이 세 가지 주요 범주로 나뉜다.

Well-Known Ports (0-1023): 표준 서비스 및 프로토콜에 할당된 포트입니다. 예를 들어, HTTP는 포트 80, HTTPS는 포트 443, FTP는 포트 21, SSH는 포트 22 등을 사용한다. 이러한 포트들은 표준 서비스를 위한 것이므로 프로그래머가 직접 사용하지 않도록 한다.
Registered Ports (1024-49151): 특정 애플리케이션과 관련된 포트입니다. 예를 들어, MySQL은 포트 3306, PostgreSQL은 포트 5432 등을 사용한다.
Dynamic or Private Ports (49152-65535): 일시적인 목적이나 임시 연결에 사용됩니다. 클라이언트가 서버에 연결할 때 주로 사용되며, 커넥션이 종료되면 포트가 해제된다.

DNS

IP는 변경 가능성이 존재한다. 아이피는 일단 기억하기 어렵다. 단순히 IPv6가 숫자가 많이 나열된 것도 그렇지만 IPv4에서도 인간이 보기에 랜덤한 숫자들의 배열일 뿐이다. 반면 www.google.com같은 경우는 저 주소가 구글 서비스에 대한 것이구나를 쉽게 파악할 수 있다.

또한 IP는 변경될 수 있다. 만약 IP가 변경된다면, 요청을 넘기는 쪽(클라이언트)은 과거의 집(변경이전 IP + (TCP)Port)에 요청을 보내게 될 것이다.

이러한 IP의 까탈스러움을 방지하기 위한 중개자인 DNS가 존재한다.
만약 서버의 IP가 바뀌었다면 DNS서버에 자신의 IP변경 사항을 업데이트하며 클라이언트는 이와 상관없이 google.com으로 요청을 보낸다. 또한 도메인 명을 사용하므로 기존의 IP만 사용했을 때보다 서버가 어떤 곳인지 잘 표현할 수 있다.