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

인터넷 통신

만약 서버와 클라이언트가 붙어있다면, 별문제 없이 요청과 응답을 주고받으면 될 것이다. 하지만, 서버와 클라이언트가 굉장히 멀리 떨어져 있는 경우에는 인터넷을 거쳐 통신을 해야만 한다.

 

이런 경우에는 인터넷 망을 통해 서버로 요청을 보내야 한다. 인터넷은 그래프 자료 구조의 노드처럼 수많은 서버와 링크들을 거쳐서 메시지가 전달되어야 한다.

 

복잡한 인터넷 망을 어떻게 지나가야 message가 안전하게 전달되는지는 IP(인터넷 프로토콜)을 알아야 한다.

---

IP (Internet Protocol)

우리가 우선 인터넷 망을 거쳐 원하는 서버로 요청(request) 또는 메시지(message)를 보내고자 하는 경우 IP 주소가 있어야 한다.

 

이 IP 주소는 client와 server가 모두 부여받아야 한다.

ex) client (100.100.100.1), server(200.200.200.1)

 

IP (Internet Protocol)의 역할

• 지정한 IP 주소 (IP Address)에 데이터를 전달
• 패킷(packet)이라는 통신 단위로 데이터를 전달

 

IP 패킷의 구성요소

• 출발지의 IP 주소
• 목적지의 IP 주소
• 전송할 데이터
• 기타 등등..

IP (인터넷 프로토콜)은 이렇게 만들어낸 IP packet을 인터넷에 내던져서 목적지로 향하게끔 한다. 이렇게 올바른 목적지에 에 IP packet이 전달되면, 목적지에서도 다시 출발지로 전송을 잘 받았다는 응답을 원래의 출발지로 전달하게 된다.

 

이때, 같은 출발지와 목적지라고 하더라도 다른 경로를 통해서 갈 수 있다.

 

IP 프로토콜의 한계

• 비연결성
  • 패킷을 받을 대상이 없거나 서비스 불능 상태라고 하더라도 패킷이 전송된다.
• 비신뢰성 (신뢰할 수 없음)
  • 중간에 패킷이 사라진다면?
  • 패킷이 순서대로 도착하지 않는다면? (메시지가 너무 커서 여러 개의 패킷으로 쪼개져 전달되는 경우)
• 프로그램 구분
  • 같은 IP를 사용하는 서버에서 통신하는 어플리케이션이 두 개 이상이라면? (인터넷 프로토콜 만으로는 프로세스 간 식별이 불가능하다. host 식별까지만 가능하다.)

하지만, IP 프로토콜만 사용하는 경우 위와 같은 한계점에 봉착하게 된다.

---

TCP와 UDP

IP (인터넷 프로토콜) 만으로는 해결할 수 없는 문제들을 해결하기 위해 사용하는 protocol이 TCP이다. (UDP는 이런 문제들을 해결해주지는 않지만, 도움이 되는 protocol)

 

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

• 어플리케이션 계층 (Application Layer) - HTTP, FTP
• 전송 계층 (Transport Layer) - TCP, UDP
• 인터넷 계층 (Internet Layer) - IP
• 네트워크 인터페이스 계층

TCP와 UDP protocol은 IP 프로토콜 상위의 전송 계층에 위치해서 IP 프로토콜을 살짝 보완해주는 개념이라고 생각하면 된다.

 

프로토콜 계층

프로토콜 계층을 위 그림과 같이 처리해서 인터넷으로 넘기는 구조를 따른다. (각각의 프로토콜 계층을 거치면서 프로토콜에 필요한 정보를 덧붙여가는 방식으로 패킷이 점점 불어나간다.)

 

IP 패킷 구조

ip 패킷에는 위에 정리한 바와 같이 출발지와 목적지의 IP 주소와 전송 데이터 등의 정보를 보유

 

TCP/IP 패킷 구조

TCP/IP 패킷의 경우 기존의 IP 패킷에 TCP 프로토콜에 필요한 정보들이 추가 작성된다. port 번호와 다양한 부가 정보들이 기입된다.

 

< ⚠ 참고 packet = package(수하물) + bucket(덩어리) 두 단어의 합성어라고 한다. (택배 박스에 수하물 넣어서 보내는 것과 같은 구조) >

 

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

• 연결 지향 - TCP 3 way handshake (가상 연결, 개념적으로만 연결된 상태 물리적(X))
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 protocol
• 현재는 대부분 TCP를 사용한다.

위 특징을 보면 알 수 있듯이 IP 프로토콜이 보장하지 못하던 것들을 TCP를 사용함으로써 보장할 수 있게 된다. 그래서 신뢰할 수 있는 프로토콜이라 부른다.

 

TCP 3 way handshake

1. client에서 server로 SYN을 보낸다.
2. server에서 client의 SYN에 대한 응답으로 SYN + ACK를 client로 전송
3. client에서 다시 응답으로 ACK를 전송
4. 데이터 전송 시작

위 세 개의 과정을 거친 이후에 통신이 된다고 하여, TCP 3 way handshake라고 부른다. 최근에는 최적화를 통해 3번 과정에서 바로 데이터 전송이 시작된다고 한다.

 

데이터 전달 보증

클라이언트에서 전송한 데이터에 대해 잘 받았는지 여부를 서버가 응답으로 보내서 확인한다.

 

순서 보장

기본적으로는 순서가 잘못된 경우 해당 패킷부터 전부 버리고, 다시 전송하라고 요청하는 방식으로 동작하여 순서에 대한 보장을 한다.

 

이러한 검증은 TCP/IP packet에 탑재된 여러 정보를 통해 검증이 가능한 것

 

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

• 하얀 도화지에 비유됨 (기능이 거의 없기 때문이다.)
• 비연결 지향 - TCP 3 way handshake X
• 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠르다. (연결 없이 데이터 주고받으니 빠를 것)
• 정리
  • IP 프로토콜과 거의 같다. (+ PORT 번호 + checksum 정도의 기능만 추가)
  • 어플리케이션에서 추가 작업이 필요하다.
  • 최근에는 웹 브라우저의 최적화 증가로 각광받고 있다. (연결 과정까지 최적화해보자.)

---

PORT

한 개의 호스트가 한 번에 두 개 이상의 호스트와 연결되어야 한다면?

디스코드를 하면서 게임하는 상황을 예로 들 수 있을 것 같다.

앞서 IP 프로토콜에 의해 생성된 IP 주소로 호스트를 구분하였다면, PORT 번호를 이용해서 호스트 안에서 실행되는 프로세스를 식별하게 된다.

 

여기서 말하는 PORT는 TCP/IP 패킷에 실려있는 그 PORT에 해당하고, UDP에도 탑재된다.

이런 식으로 호스트 내부의 프로세스간 식별에는 PORT가 사용된다.

 

PORT 특징

• 0 ~ 65535 범위 내에서 할당 가능하다.
• 0 ~ 1023: 잘 알려진 포트 (well-known port number 전용, 사용하지 않는 것이 좋다.)
  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

---

DNS (Domain Name System)

IP주소는 단순 숫자의 조합으로 이루어져 있어서 기억하기가 어렵고, 변경될 수 있다. 따라서 우리는 IP 주소와 별개로 서버의 주소를 기억하기 위한 별도의 수단이 필요하다.

 

DNS는 domain namer과 ip 주소를 mapping 해주는 별도의 서버를 갖고 있는데, 이를 DNS 서버라고 부른다. 도메인을 사서 DNS 서버에 등록하면, 도메인 만으로 원하는 서버와 통신이 가능하다. 

 

따라서 DNS를 통해

• IP 주소를 기억하기 어렵고
• IP 주소는 변경될 수 있다.

이 두 가지 문제를 해결할 수 있게 된다.