Kimsu

언제 다시봐도 기억할 수 있게

인터넷의 동작 방식

최초의 데이터 교환은 스탠포드 대학교의에서 인터넷의 전 모델인 알파넷(ARPANET)으로 전송한 메세지로 LOGIN 명령이다. 하지만 이 초기 네트워크는 LO 두글자를 보내고나면 항상 접속이 끊어져 신뢰성이 없었다. 소련의 해킹 공격으로인한 오프라인 상태에서도 데이터를 교환할 수 있는 방법을 찾고있던 미국의 네트워크 엔지니어들은 컴퓨터들 간의 신뢰할 수 있는 정보 교환을 보장하는 TCP를 개발했다.

1. 통신 프로토콜

인터넷 통신을 위한 주요 프로토콜로 TCP와 UDP 가 있으며 , 서로 다른 방식으로 데이터를 전송하고 처리한다.

1. TCP (Transmission Control Protocol)

TCP는 인터넷 프로토콜 스위트의 일환으로, 신뢰성을 중요시하는 이메일, 파일 전송, 웹 페이지 로딩 등 다양한 응용 프로그램에 적합하며, 데이터가 정확히 전달되도록 보장한다.
그래서 인터넷에서 가장 널리 사용되는 전송 프로토콜이다. TCP는 신뢰성 있는 데이터 전송을 보장하기 위해 다음과 같은 절차를 따른다.

  1. 데이터 패킷화 컴퓨터가 TCP를 통해 데이터를 전송할 때, 데이터를 여러 개의 작은 데이터 패킷(packet)으로 분할하여 목적지로 보낸다.
    각 패킷에는 목적지 주소가 포함되어 있어 최종 수신지까지 전달된다.

  2. 데이터 전송 및 라우팅 이때 인터넷을 구성하는 컴퓨터는 전체 메세지를 처리하지않고 패킷을 목적지로 전달하기만 한다.
    패킷은 여러 경로를 통해 전달될 수 있으며, 인터넷의 유동성에 따라 최적의 경로를 선택하여 이동한다.

  3. 수신 확인과 재조립 수신 시스템은 패킷을 받으면 패킷을 순서에 맞게 재조립하여 원본 데이터를 복원한다.
    수신자는 패킷을 받을 때마다 수신 확인 신호를 송신자에게 보내며, 패킷이 손실되거나 손상되면 송신자는 해당 패킷을 재전송한다.

  4. 체크섬과 흐름 제어

인터넷의 성장에따라 TCP는 개선되었고, packet은 수신자가 데이터의 손상 여부를 감지하고 필요시 재전송을 요청해야하는지 여부를 결정할 수 있는 checksum과 함꼐 전송된다.

Checksum(체크섬) packet이 수신자가 데이터 손상을 감지하고 패킷으 재전송해야 하는 지 여부를 결정할 수 있게 도와주는것 송신자의 전송속도를 수신자의 데이터 처리속도에 맞추고 조정하는 흐름제어기능이 있어 네트워크 성능을 최적화할 수 있다.

TCP는 전달 보증떄문에 가장 일반적인 프로토콜로 남아있지만, 오늘날에는 UDP도 자주 사용되고 있다.

2. UDP (User Datagram Protocol)

데이터가 일정한 속도로 스트리밍 될 수 있도록 패킷을 의도적으로 삭제하는 새로운 프로토콜이다.
TCP와 달리 연결을 설정하지 않고 데이터를 빠르게 전송할 수 있는 비연결형 프로토콜이다. 주로 실시간 스트리밍이나 온라인 게임같은 빠른 데이터 전송이 필요한 애플리케이션에 사용된다.

  1. 연결 없는 빠른 전송
    송신자가 데이터를 보내는 즉시 수신자에게 도착하도록 패킷을 전송한다.
    각 패킷은 독립적으로 전송되며, 순서에 관계없이 전송된다.

  2. 신뢰성보다 속도 UDP는 체크섬 기능을 지원하지만, 패킷 손실 시 재전송 하지는 않는다.

  3. 실시간 전송에 유리 소비자들은 네트워크 혼잡시 Feed(피드)를 지연하는 것보다 약간의 프레임이 손실되는 것을 더 선호하기때문에 끊김 없이 스트림을 감상할 수 있는 Live Video Streaming이나 Online Game에 적합하다.

2. IP (Internet Protocol)

IP(인터넷 프로토콜)는 인터넷에서 데이터 패킷을 특정 목적지로 전달하는 데 사용되는 주소 체계이다.
IP 주소는 인터넷에 연결된 각 컴퓨터나 장치에 고유하게 할당되며, 데이터가 정확한 위치에 도달할 수 있도록한다. 각 IP 는 고유해야하므로, 새로운 IP 주소는 구조화된 방식으로 발급한다.

1. IP 주소 할당

모든 인터넷 연결 장치는 고유한 IP 주소를 부여받아야한다.
이 주소는 국제 도메인 관리기구(ICANN, Internet Corporation for Assigned Names and Numbers)에서 각 지역의 주소 관리 당국에 블록 단위로 할당된다. 지역 당국은 다시 인터넷 서비스 제공업체(ISP, Internet Service Provider)나 호스팅 업체에 주소 블록을 분배한다. 일반 사용자가 인터넷에 연결하면 ISP는 몇 달간 고정된 상태를 유지(ISP는 주기적으로 IP 주소를 순회함)하는 IP주소를 컴퓨터에 할당한다. 인터넷에서 콘텐츠를 호스팅하는 회사들도 네트워크에 접속하는 각 서버의 IP주소를 할당받는다.

2. IP 주소의 종류

IPv4

현재 널리 사용되는 IP 주소 체계로, 32비트 2진수로 표현된다.
IPv4는 $2^{32}$, 약 43억 개의 주소를 지원하며, 일반적으로 점으로 구분된 4개의 숫자로 표시한다.
(예: 구글의 도네임 서버주소 → 8.8.8.8)

IPv6

IPv4 주소의 고갈 문제를 해결하기 위해 개발되었다.
IPv6는 128비트 주소 체계로, 16진수 8개 그룹으로 구성되어 콜론(:)으로 구분된다.
(예: fe80::8274:36c5:3197:7a3b%3) IPv6는 훨씬 많은 장치를 연결할 수 있는 주소 공간을 제공한다.

3. IP 주소의 작동 원리

사용자가 브라우저를 통해 웹사이트에 접속하려 할 때, 데이터 패킷은 목적지인 서버의 IP 주소로 전송된다.
IP 주소는 각 패킷의 목적지를 정의하고, 인터넷을 통해 올바른 경로로 전달되도록 도와준다.
인터넷의 인프라는 이러한 IP 주소 체계를 기반으로, 데이터를 정확히 원하는 위치로 보내준다.

IP 주소는 브라우저와 다른 인터넷간의 트래픽을 인식하고 IP주소로 라우팅 할 수 있지만 사람이 기억하기는 어렵다. 그래서 사람은 www.google.com 같은 도메인 이름를 사용한다. 하지만 컴퓨터는 이러한 이름을 이해하지 못하고 IP 주소로 인식하는 문제가 발생한다. 이런 문제를 해결하기위해 DNS라는 글로벨 디렉터리를 사용한다.

3. DNS (Domain Name System)

DNS(도메인 이름 시스템)는 도메인 이름과 IP 주소를 서로 매핑하는 시스템이다. DNS는 사용자가 쉽게 기억할 수 있는 도메인 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환하여 웹사이트 접속을 가능하게 한다.
( www.google.com → 8.8.8.8) 도메인명 또한 IP 주소처럼 고유해야하므로 도메인 이름 등록 대행(Domain Name Register)이라는 민간단체에 사용하기전에 등록해야한다.

1. DNS 조회 과정

사용자가 도메인 이름을 입력하면, 브라우저는 DNS 서버에 IP 주소를 요청한다.

  1. 로컬 Cache를 확인 브라우저가 도메인 이름을 처름으로 접하면 로컬 도메인 네임 서버(ISP가 호스팅한 서버)를 사용해서 검색한다. 컴퓨터는 그 결과(최근 접속한 도메인의 IP 주소)를 캐시에 저장해 두고, 캐시된 주소가 있다면 DNS 요청 없이 해당 IP 주소로 접속한다.

  2. 재귀 DNS 서버 조회 로컬 캐시에 IP 주소가 없다면 ISP의 재귀 DNS 서버로 요청이 전달된다.

  3. 권한 있는 네임 서버 조회 재귀 DNS 서버는 루트 서버, TLD 서버, 권한 있는 네임서버 순으로 IP 주소를 찾는다.

  4. IP 주소 반환 권한 있는 네임서버에서 IP 주소를 받아 사용자에게 전달하고, 브라우저는 해당 IP 주소로 웹사이트에 접속한다.

2. DNS의 계층 구조

DNS는 계층적으로 구성된 시스템이라서 도메인 이름을 빠르게 검색할 수 있다.

  • 루트 서버 DNS의 최상위 서버로, 전 세계적으로 분산되어 있습니다. .com, .org, .net 등 최상위 도메인(TLD)에 대한 정보를 제공한다.
  • TLD 서버 각 최상위 도메인에 대한 정보를 저장하고 있습니다. 예를 들어, .com 도메인의 경우 .com TLD 서버가 관리한다.
  • 권한 있는 네임서버 특정 도메인에 대한 최종 IP 주소 정보를 저장하고 있으며, 최종적으로 사용자가 입력한 도메인 이름을 IP 주소로 변환한다.

3. DNS 캐싱과 DNS 캐시 포이즈닝 📌

DNS 캐싱은 인터넷 속도와 효율성을 크게 높여주지만, 동시에 캐시 포이즈닝 공격의 취약점이 될 수 있다.
그러므로 DNS 보안을 강화하고, DNSSEC를 활용하는 등 보안 대책을 철저히 해야한다.

  1. DNS 캐싱 DNS 캐싱은 DNS 서버나 로컬 시스템이 최근 조회한 도메인 이름과 그 IP 주소를 일정 시간 동안 저장하여, 같은 요청이 반복될 때 재조회 없이 빠르게 응답할 수 있도록 하는 과정이다.
    이는 불필요한 DNS 요청이 줄이고, 웹사이트 접속 속도도 크게 향상시킬 수 있다.
    캐시에는 TTL(Time To Live)이라 불리는 유효 기간이 설정되어 있고, 기간이 만료되면 캐시가 갱신되도록 다시 DNS 조회를 요청한다. DNS 캐싱은 아래의 단계로 이루어진다.

  • 로컬 캐싱 사용자 컴퓨터나 브라우저가 최근 방문한 사이트의 IP 주소를 저장하여, 재방문 시 DNS 조회 없이 빠르게 접속하게 한다.

  • ISP 캐싱 ISP의 DNS 서버가 자주 조회되는 사이트 정보를 저장하여, 같은 정보를 반복 요청하는 여러 사용자들에게 빠르게 응답한다.

  • DNS 서버 캐싱 계층적 구조의 각 DNS 서버도 조회 결과를 캐시에 저장하여, 이후 동일한 도메인 요청이 들어오면 재귀 과정 없이 빠르게 응답할 수 있게 한다.

  1. DNS 캐시 포이즈닝 DNS 캐시 포이즈닝(DNS Cache Poisoning)은 공격자가 악의적인 방식으로 DNS 캐시에 잘못된 정보를 주입하여, 사용자가 특정 도메인 이름으로 접속할 때 원래 사이트가 아닌 피싱 사이트나 악성 사이트로 유도하게 하는 공격이다.
    이는 DNS 시스템의 신뢰성을 악용하는 방식으로, 정상적인 DNS 캐시에 조작된 IP 주소를 삽입해 사용자가 의도하지 않은 사이트에 접속하도록 만든다.

작동 방식 공격자가 특정 DNS 서버에 잘못된 IP 주소를 응답으로 보내 캐시에 저장하게 하고, 이후 사용자가 해당 도메인에 접속할 때 조작된 IP 주소로 연결하여 피싱 사이트나 악성 코드가 포함된 사이트로 접속하게 만든다.

예방 방법 > DNS 서버 보안을 강화하고, DNSSEC(DNS Security Extensions)와 같은 보안 프로토콜을 적용하는 것이 중요하다.
DNSSEC는 DNS 조회에 디지털 서명을 포함하여, 사용자가 신뢰할 수 있는 응답을 받았는지 확인할 수 있도록 돕는다.

4. 기타 도메인

도메인 네임 서버는 특정 도메인 이름을 다른 도메인 이름으로 매핑하는 역할을 하는 CNAME이라는 DNS 레코드도 있다.
주로 하나의 도메인을 다른 도메인으로 연결해줄 때 사용되며, 이를 통해 여러 도메인이 하나의 IP 주소를 공유할 수 있게 해준다.

CNAME

CNAME 레코드는 특정 도메인이 다른 도메인의 별칭(alias)으로 작동하도록 설정하는 것(www가 없어도 같은 서버로 연결) 예를 들어, www.name.com이라는 도메인이 있고, 이를 name.com으로 연결하려고 할 때, www.name.com에 CNAME 레코드를 설정하여 name.com으로 연결되도록 할 수 있다. ( www.name.com에 요청을 보내면 DNS는 name.com의 IP 주소를 찾고 그 IP로 연결)

주의 CNAME 레코드는 최상위 도메인에 사용할 수 없고, 서브도메인에만 설정할 수 있다. 다른 레코드(A, MX(Mail Exchange))와 함꼐 사용할 수 없다.

4. Application Layered Protocol

TCP나 UDP 위에 구축되는 프로토콜을 애플리케이션 계층 프로토콜이라 한다. 웹 브라우저, 이메일 클라이언트, 파일 전송 프로그램 등과 같은 애플리케이션이 사용하는 프로토콜들이 여기에 속한다.

HTTP (HyperText Transfer Protocol)

웹 서버는 HTTP를 통해 웹 페이지와 그 자원들을 사용자 에이전트(웹 브라우저)로 전송한다.
HTTP는 요청(request)과 응답(response) 구조로 작동하며, 주로 무상태(Stateless) 프로토콜이기 때문에 서버가 클라이언트의 상태를 따로 저장하지 않는다.

상태 저장 연결 (stateful connection)

서버가 클라이언트의 상태 정보를 지속적으로 저장하여 이전 요청의 맥락을 유지하는 방식이다.
(예: 사용자가 로그인한 상태를 유지하거나 장바구니 정보를 저장)

HTTP는 기본적으로 무상태 프로토콜이지만, 세션이나 쿠키를 통해 상태를 유지할 수 있다.

HTTP 요청

  • Method: 요청의 종류를 정의 (예: GET, POST)
  • URL: 요청하는 자원의 경로
  • Headers: 요청의 부가 정보 (브라우저 정보, 쿠키 등)
  • Body: 전송할 데이터 (POST 요청 시 주로 사용됨)
# 상태 코드
GET http://example.com HTTP/1.1      # 요청 줄: 메서드, URL, 프로토콜 버전
# 헤더
Host: example.com                    # 요청 대상 서버 호스트명 지정
User-Agent: Mozilla/5.0              # 요청을 보내는 클라이언트의 브라우저 유형
Accept: text/html, application/xml   # 브라우저가 받아들이는 콘텐츠 유형
Accept-Encoding: gzip, deflate       #  지원하는 압축 방식 지정

HTTP 응답 서버는 요청을 받으면, 요청에대한 응답을 클라이언트로 전달한다.
HTTP 응답은 상태 코드, 헤더, 바디로 구성되며, 웹 페이지를 렌더링할 수 있는 자원들이 포함된다.

# 상태 코드
HTTP/1.1 200 OK                    # 프로토콜 버전, 상태 코드, 상태 메시지로 구성
# 헤더
Content-Encoding: gzip             # 데이터 압축 방식 정보
Content-Type: text/html; charset=UTF-8   # 데이터의 MIME 타입을 명시
Cache-Control: max-age=3600        # 캐시 제어 정보를 제공하여 로컬 캐시 가능 설정
Content-Length: 1024               # 본문 크기 지정 (예시)

# 본문: HTML 콘텐츠 시작
<!doctype html>
<html>
  <style type="text/css"> </style>
  <body></body>
</html>
HTTP 메서드 설명 사용 사례 및 특징
HEAD GET 메서드와 동일한 요청을 수행하되, 응답 본문(body)은 반환하지 않음. - 리소스의 메타데이터(예: 헤더)만 필요할 때 사용
- 캐싱 확인이나 리소스 상태 검사에 유용
CONNECT 프록시 서버와 클라이언트 간의 터널을 설정하여 안전한 TCP 연결을 생성함. - HTTPS 요청 시 SSL 터널을 형성하여 암호화된 통신을 위해 주로 사용됨
OPTIONS 특정 URL에서 지원하는 HTTP 메서드를 확인하거나, 서버의 일반적인 기능을 요청함. - CORS 요청 시, 서버가 지원하는 메서드를 미리 확인
- 서버와 클라이언트 간의 통신 옵션을 미리 협상하기 위해 사용
TRACE 클라이언트에서 서버로 요청을 보내고, 중간 서버나 프록시의 변경 없이 그대로 반환함. - 요청 경로를 테스트하거나, 네트워크 문제를 진단할 때 사용
- 디버깅 목적에 주로 사용됨

handShake

암호화

초기의 웹은 HTTP 요청과 응답은 데이터 패킷을 가로채는 모든 사람이 읽을 수 있는 텍스트의 형태로 보내졌다.
이런 가로채기를 막기위해 현대의 웹에서는 인코딩으로 메세지를 위장한다.
웹서버와 브라우저는 통신을 보호하기위해 TLS 암호화 방식을 사용하여 요청과 응답을 보낸다.

TLS (Transport Layer Security) 데이터 전송 시 보안을 강화하기 위해 사용되는 프로토콜로, 네트워크 통신을 암호화하여 제3자가 데이터를 읽을 수 없도록 보호한다. (암호키 없이는 해독 불가) 또한 패킷을 변조하려는 시도도 탐지할 수 있어 데이터의 무결성을 보장한다. TLS를 이용한 HTTP 통신을 HTTPS라고한다.

HTTPS (HyperText Transfer Protocol Secure) HTTP에 TLS 암호화가 추가된 프로토콜로, HTTP 요청과 응답이 암호화되어 안전한 데이터 전송을 보장한다. 이를 통해 웹사이트와 사용자 간의 데이터가 보호되며, 보안이 중요한 웹 서비스에서 기본적으로 사용된다.

태그:

카테고리:

업데이트:

댓글남기기