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

 

🍒 Recap

• 인터넷 통신
• 복잡한 인터넷 망에서 메시지를 보내기 위해 “IP” 규칙을 사용
• IP의 한계를 “TCP”로 해결
• “UDP”는 IP와 거의 동일하지만 PORT가 추가된 백지 개념. 필요에 따라서 UDP 위의 애플리케이션에서 기능을 확장할 수 있음(ex. 최적화)
• 같은 IP 내에서 동작하는 애플리케이션을 구분짓기 위해 “PORT” 사용
  • IP = 아파트
  • PORT = 몇동 몇호
• IP는 외우기 어렵고 변경될 수 있는 문제가 있는데, 이를 “DNS”를 등록하여 이 문제를 해결함

 

 

1. 인터넷 통신

인터넷에서 컴퓨터 둘은 어떻게 통신할까?

• 케이블로 연결되어 있으면 바로 요청(클라→서버), 응답(서버→클라)하면 됨
• 하지만 실제는 먼 거리도 통신해야 함 ⇒ “인터넷 망” 이용

복잡한 인터넷 망

• 수많은 노드(=서버)를 거쳐서 메시지가 전달됨
• 어떤 과정을 거쳐서 어떤 규칙으로 어떻게 넘어갈까? ⇒ “IP”에 대해 알아야 함

 

2. IP(Internet Protocol, 인터넷 프로토콜)

IP 주소 부여

• 통신하기 위해서 클라이언트, 서버가 IP 주소를 부여 받음

IP의 역할

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

 

IP 패킷 정보

데이터를 그냥 보내지 않고, IP 패킷이라는 규칙에 따라서 보내게 됨

• 출발지 IP
• 목적지 IP
• 기타

 

패킷 전달

클라이언트 패킷 전달

1. 출발지 IP, 목적지 IP, 메시지를 담은 패킷을 노드에 던짐
2. 목적지 IP에 도달

서버 패킷 전달

1. 출발지 IP, 목적지 IP, OK 메시지를 담은 패킷을 노드에 던짐
2. 목적지 IP에 도달

인터넷망은 복잡하므로, 요청할 때와 응답할 때 서로 다른 노드를 거쳐서 전달될 수도 있음

 

IP 프로토콜의 한계

• 비연결성
  • 대상이 서비스 불능, 패킷 전송: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷이 전송됨 (ex. PC가 꺼져있거나)
  • 상대가 패킷을 못받아도 우리는 그 사실을 모름
• 비신뢰성
  • 패킷 소실: 중간에 패킷이 사라지면?
  • 패킷 전달 순서 문제 발생: 여러 개 보낸 패킷이 순서대로 안오면?
• 프로그램 구분
  • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면? → 구분할 수가 없음

이러한 IP의 한계를 해결해주는 것이 바로 TCP (+UDP)

 

 

3. TCP, UDP

TCP/IP 4 Layer

인터페이스 → 인터넷 → 전송 → 애플리케이션

 

프로토콜 계층

애플리케이션 → OS → 인터페이스

채팅 프로그램으로 메시지 전송 시

1. socket 라이브러리를 통해 OS 계층에 메시지를 넘김
2. OS 계층의 TCP가 TCP 패킷을 생성하고 메시지에 씌움
3. IP가 IP 패킷을 생성하고 메시지에 씌움
4. 메시지에 이더넷 프레임을 포함하고, 네트워크 인터페이스인 LAN 카드를 통해 메시지가 나감

이더넷 프레임(Ethernet frame)
LAN카드에 등록된 MAC주소 등…물리적인 정보를 포함

 

패킷 정보

• 패킷 = package(수하물) + bucket(덩어리)

IP 패킷 정보

TCP/IP 패킷 정보

• IP만으로 해결되지 않았던 순서와 같은 문제들이 해결됨

 

TCP 특징

TCP (=Transmission Control Protocol, 전송 제어 프로토콜)

• 연결 지향 - TCP 3 way handshake (가상 연결)
• 데이터 전달 보증
• 순서 보장

더 많은 기능이 있지만 우선은 이 정도만 알자

⇒ 신뢰할 수 있는 프로토콜
⇒ 현재는 대부분 TCP 사용

연결 지향 - TCP 3 way handshake (가상 연결)

• 연결이 됐는지 확인 후 메시지를 보냄
• IP의 비연결성 한계 해결

1. (클라→서버) SYN 보냄
2. (서버→클라) SYN + ACK 보냄
3. (클라→서버) ACK 보냄
4. 데이터 전송

양쪽 다 알았다고(=ACK) 데이터를 보내면서 서로의 연결을 확인 후 데이터 전송
만약 서버가 중간에 꺼졌다면 ACK 응답이 없으니 연결이 안됐다고 판단하고 데이터를 전송하지 않음

요즘은 방식이 최적화가 되어서 3번 과정에서 ACK를 보낼 때 데이터도 함께 전송함

TCP 3 way handshake는 실제 연결(물리적 연결)이 아닌, 개념적인 연결(가상 연결)
연결을 위해 거치는 수많은 노드들이 잘 연결되어 안전한지 검증된 건 아니다. 연결을 위한 전용 랜선이 보장된 것이 아님. 그냥 서버, 클라가 논리적으로 연결이 됐구나, 하는 것임.

 

데이터 전달 보증

• 데이터가 중간에 누락됐는지 여부를 알 수 있음
• IP의 비신뢰성 - 패킷 소실 한계 해결

데이터 전송 후, 서버가 데이터를 잘 받았다고 응답을 보내므로 데이터 전송이 잘 됐는지 알 수 있음

 

순서 보장

• IP의 비신뢰성 - 패킷 전달 순서 문제 발생 한계 해결

 

UDP 특징

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

• 하얀 도화지에 비유(기능이 거의 없음)
  • TCP 3 way handshake (x)
  • 데이터 전달 보증 (x)
  • 순서 보장 (x)
  • 데이터 전달 및 순서가 보장되지 않으나, 단순하고 빠름
  • IP와 거의 동일함
• +port, +체크섬 기능 추가
  • port: 애플리케이션 구분
  • 체크섬: 메시지가 잘 왔는지 검증해주는 데이터
• 최적화 가능
  • TCP는 기능이 너무 많아서 시간도 너무 많이 걸리고 데이터 양도 너무 커서 전송 속도가 느림. 이미 구축이 되어 있어서 최적화 불가능. (이미 인터넷이 TCP 기반으로 사용되고 있으므로 수정하는 등 손을 댈 수가 없음)
  • 애플리케이션에서 추가 작업 필요
    • 최적화를 하고 싶다면 UDP를 사용하고, 애플리케이션 레벨에서 원하는 걸 만들면 됨
  • 최근 각광 받는 중
    • 예전
      • 신뢰할 수 있는 정보 → TCP
      • 영상, … 깨져도 되는 정보 → UDP
    • 시간이 지나면서 모든 정보는 TCP로 보내게 됨 (심지어 영상까지도)
    • 최근
      • UDP가 뜨는 중
      • 웹 브라우저 HTTP 3이 등장
      • TCP는 시간이 너무 많이 걸린다. 더 최적화하자. → UDP 사용
      • HTTP 3 + UDP

 

 

4. PORT

PORT란?

한 번에 둘 이상 연결해야 하면?

IP만 가지고는 각 패킷이 어느 요청에 대한 응답인지 알 수가 없음

 

TCP/IP 패킷 정보

 

같은 IP 내에서 프로세스 구분

1. 웹 브라우저 요청 (200.200.200.3:80)
2. 응답 (100.100.100.1:10010)

IP = 아파트
PORT = 몇동 몇호

 

PORT 번호

• 0~65535 할당 가능
• 0~1023: 잘 알려진 포트, 사용하지 않는 것이 좋음
  • FTP - 20, 21
  • TELNET - 23
  • HTTP - 80
  • HTTPS - 443

 

 

5. DNS

IP의 문제점

• IP는 기억하기 어렵다
• IP는 변경될 수 있다
  • IP가 바뀌면 클라이언트가 서버로 접근할 수 없게 됨

 

DNS

DNS란?

DNS (=Domain Name System, 도메인 네임 시스템)

• 전화번호부
• 도메인 명을 IP 주소로 변환

 

DNS 사용

1. 도메인 구매 (도메인 명 - google.com)
2. DNS 서버에 도메인 등록 (google.com ↔ IP: 200.200.200.2)
3. 클라이언트가 도메인 명으로 접근
4. DNS 서버에서 해당 도메인 명의 IP를 찾고, 응답으로 줌
5. 클라이언트가 응답 받은 IP로 접근

만약 추후에 IP가 변경되면?
DNS 서버에서 도메인 명에 매칭되는 IP 주소를 변경하면 됨

 

DNS를 사용하게 되면 앞서 IP의 문제점을 해결할 수 있게 됨