[ 김영한 모든 개발자를 위한 HTTP 웹 기본 지식 #1 ] 인터넷 네트워크

김수호·2023년 8월 16일

김영한 모든 개발자를 위한 HTTP 웹 기본 지식

첫 번째 섹션의 내용은 인터넷 네트워크에 관한 내용이다.

🤔 HTTP & 웹 강의인데 왜 인터넷 네트워크에 대해서 알아야할까?
: 결국 웹이나 HTTP도 인터넷 네트워크에 기반해서 동작한다. 따라서 HTTP 학습을 위한 사전 기본학습이라고 생각하자.

👉 목차는 다음과 같다.

1) 인터넷 통신
2) IP(Internet Protocol)
3) TCP, UCP
4) PORT
5) DNS

1) 인터넷 통신

두대의 컴퓨터가 물리적으로 원거리에 떨어져있다고 가정하자.

서로 데이터를 주고받기 위해서는 인터넷 망을 통해서 메시지를 보내야 한다.
( 인터넷 망을 통해서 "Hello, world!"라는 메시지가 전송되기 위해서는 그 과정에서 수많은 중간 노드라고 하는 서버들을 거쳐서 메시지가 전송된다. )

그러면 어떤 규칙으로 어떻게 전송되는걸까 ?
어떻게 이런 수많은 복잡한 상황을 거치고 목적지까지 안전하게 도착할 수 있을까?
이것을 이해하기 위해서는 IP(인터넷 프로토콜)에 대해서 학습해야 한다.

2) IP(인터넷 프로토콜)

복잡한 인터넷망을 통해서 서로 멀리 떨어져있는 컴퓨터끼리 통신하기 위해서는 최소한의 규칙이 있어야한다. 그 규칙이 바로 IP(Internet Protocol)이다.
- 통신을 하려는 클라이언트와 서버는 모두 IP 주소를 부여받아야 한다.
  - IP 주소를 통해 클라이언트와 서버는 메시지를 주고 받는 것이 가능해 진다.

IP(인터넷 프로토콜) 역할

지정한 IP 주소(IP Address)에 데이터 전달.
패킷(Packet)이라는 통신 단위로 데이터 전달.
- 전송 데이터(Hello, world!) 외 출발지 IP(100.100.100.1)와 목적지 IP(200.200.200.2) 정보 등이 포함된다.
- 이렇게 만들어진 IP 패킷을 인터넷 상에 던진다.
- 인터넷 상의 노드들은 모두 IP 프로토콜을 따르기 때문에 해당 패킷의 정보(출발지, 목적지, ..)를 이해할 수 있다.
- 중간 노드들은 목적지 노드가 어디있는지 서로 물어가면서 해당 패킷을 전달한다. (라우팅 과정)

IP 프로토콜의 한계

비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송. (IP 프로토콜에서 클라이언트는 대상 서버가 패킷을 받을 수 있는 상태인지 모른다.)

비신뢰성
- 중간에 패킷이 사라지면?
  - 인터넷 상의 중간 노드가 갑자기 꺼져버린다든가 하는 문제로 패킷이 유실될 수 있다. (패킷 소실 문제)
- 패킷이 순서대로 안오면?
  - 전송하려는 패킷의 용량이 매우 큰 경우 (보통, 대략 1,500Byte 정도가 넘으면 해당 내용을 끊어서 보낸다.)
  - 이러한 경우 전송하려는 패킷들의 순서가 중요하다.
  - IP프로토콜에서는 하나의 데이터에 연관된 패킷들이 각각 다른 경로로 전송될 수 있다. 따라서 도착하는 순서가 보장되지 않는다. (패킷 전달 순서 문제)

프로그램 구분
- 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면? (IP프로토콜에서는 이를 구분하기에 한계가 있다.)

☝️ 이러한 IP 프로토콜의 한계를 해결해주는 것이 TCP 프로토콜이다. 다음에는 TCP와 UDP에 대해 알아보자.

✔️ 참고

인터넷 프로토콜 정의
(출처: https://www.cloudflare.com/ko-kr/learning/network-layer/internet-protocol/)

3) TCP, UDP

이번에는 TCP와 UDP에 대해서 알아보자.
이전에 IP 프로토콜의 한계들이 있었다. 이를 TCP 프로토콜이 해결해준다.

우리가 이전에 보았던 IP 패킷 정보이다. (출발지 IP와 목적지 IP 등이 있다.)

TCP/IP 패킷 정보
- IP 패킷안에 TCP 세그먼트가 들어간다.
- TCP 세그먼트에는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증정보 등이 들어가게 된다.

TCP 특징
전송 제어 프로토콜(Transmission Control Protocol)

연결지향 - TCP 3 way handshake (가상 연결)
- 클라이언트 -> 서버, 서버 -> 클라이언트 양방향으로 연결 설정함으로써 클라이언트도 서버를 믿을 수 있고, 서버도 클라이언트를 믿을 수 있다.
- 3 way handshake 과정이 끝나면 두 호스트가 연결된 것이다. 먼저 연결을 한 후, 그 다음에 데이터 전송이 일어난다. 따라서 서버에 문제 있어서 메시지 수신 못하는 경우 데이터 전송을 하지 않는다.
- 참고로 요즘에는 최적화가 되어서 마지막 3번 ACK를 보낼 때 데이터를 같이 보낸다.
- (참고) 3 way handshaking을 통한 연결은 물리적인 연결이 아니다. 논리적인 가상 연결이다. 두 종단 컴퓨터끼리만 SYN, SYN+ACK, ACK를 주고 받은 후 서로 연결되었다고 알고있는 것이지, 중간의 수많은 노드들은 그 사실을 알지 못한다. 이 연결을 위한 전용 랜선이 보장되는 것이 아니다.

데이터 전달 보증 (패킷 소실 문제 해결)
- 데이터를 전달하면, 서버에서 데이터를 잘 받았다고 응답을 해준다.

순서 보장 (패킷 순서 문제 해결)
- 서버측에 도착한 패킷이 순서대로 오지 않았다면 해당 패킷부터 재요청을 한다. (클라이언트에서 패킷을 1, 2, 3으로 보냈을때, 서버에서 패킷 1, 3, 2순서로 받은 경우 패킷 2부터 재요청.)

UDP 특징
사용자 데이터그램 프로토콜(User Datagram Protocol)

하얀 도화지에 비유(기능이 거의 없음)
연결지향 X - TCP 3 way handshake X
데이터 전달 보증 X
순서 보장 X
데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
정리
- IP와 거의 같다. +PORT +체크섬 정도만 추가
- 애플리케이션에서 추가 작업 필요

🤔 그럼 UDP를 왜 사용하는 것일까?

TCP는 3 way handshaking을 통한 연결 설정과정에 시간이 걸린다. 뿐만아니라 신뢰성을 보장하기 위해서 TCP 헤더에 들어가는 검증 정보들을 넣으면 데이터의 크기도 커지고, 전송 속도도 더 빠르게 만들기 힘들다. -> 추가로 최적화가 힘들다.
내가 더 최적화하고 싶다면?
- TCP는 더이상 손을 못댄다. 이미 인터넷이 TCP기반으로 사용되기 때문에 건드릴 수 없다. 따라서, TCP는 그대로 두고 UDP를 가지고 최적화 할 수 있다. UDP는 아무런 기능이 없기 때문에 그 위에 내가 하고자 하는 것을 애플리케이션 레벨에서 만들어내면 된다.
- 인터넷 HTTP 통신에서 TCP 프로토콜이 거의 90% 이상을 점령했다. 이전에는 신뢰성있는 데이터에만 사용하라고 했지만, 이제는 동영상 같은 실시간 스트리밍이 중요한 데이터에도 TCP를 사용한다. (그런데 UDP도 최근에 다시 각광받고 있다. HTTP3 스펙에서는 TCP/IP 연결설정에 들어가는 비용까지 다 줄이기 위해 더 최적화를 하면서 UDP 프로토콜을 사용한다.)

✔️ 참고

인터넷 프로토콜 스택 4계층

프로토콜 계층
- 채팅프로그램으로 메시지(Hello)를 전송한다고 가정해보자.
  - 프로그램이 Hello 메시지 생성.
  - SOCKET 라이브러리를 통해 OS계층에 메시지 전달.
  - TCP는 Hello, world 메시지에 TCP 정보를 씌움.
  - TCP 밑의 IP 계층으로 메시지를 넘긴다. IP는 TCP 정보 위에 IP와 관련된 데이터들을 씌운다. -> IP 패킷이 생성됨.
  - 생성된 패킷이 네트워크 인터페이스를 통해서 나갈때, Ethernet frame으로 감싸져서(물리적 정보 등) 나간다.

4) PORT

이번에는 PORT에 대해 알아보자.

한 번에 둘 이상 연결해야 한다면?
- 클라이언트 PC가 여러 서버와 통신하고있다. 그 과정에서 패킷들이 클라이언트로 올 때, 이게 게임에서 필요한 패킷인지, 화상통화에서 필요한 패킷인지 웹 브라우저의 응답 결과로 오는 패킷인지 알수없다. (반대로 보낼때도 마찬가지다.)
  이것을 어떻게 구분할 수 있을까?