Understanding the Basics of Internet Networking: DHCP, DNS, and How the Web Works
인터넷 네트워크의 기본 이해: DHCP, DNS, 그리고 웹의 동작 원리
Contents
1️⃣ DHCP (Dynamic Host Configuration Protocol)
2️⃣ DNS(Domain Name System)
3️⃣ 월드 와이드 웹과 HTTP (World Wide Web and HTTP)
Key Concepts in Networking and Web Protocols
(네트워킹 및 웹 프로토콜 핵심 개념 요약)
1. DHCP (Dynamic Host Configuration Protocol)
Definition (정의): DHCP는 클라이언트/서버 방식의 프로토콜로, 처음 부팅된 컴퓨터에 네트워크 정보를 자동으로 전달한다.
Relay Agent: 클라이언트와 서버가 동일한 네트워크에 없을 경우 중계 에이전트가 요청을 전달하게 된다
2. DNS (Domain Name System)
Purpose (목적): 인터넷 상의 호스트를 사용자 편리한 이름(텍스트)으로 구분하고, 이를 IP 주소로 변환하는 역할을 한다.
Resolution Methods (해석 방식): 귀환적 해석: 서버가 요청을 연속적으로 처리 / 반복적 해석: 클라이언트가 각 단계의 요청을 반복 처리
3. World Wide Web (WWW)
Definition (정의): 전 세계적으로 연결된 정보 체계로, 하이퍼링크 개념을 통해 문서 간 이동이 가능하게 한다.
Significance (중요성): 인터넷을 대중화하고, 정보 공유를 용이하게 만듦.
4. HTTP (HyperText Transfer Protocol)
Definition (정의):
웹 문서에 접근하기 위한 주요 프로토콜로, TCP 연결을 사용하며 상태를 저장하지 않는 비연결형 프로토콜입니다.Components (구성):
요청(Request): 메서드(GET, POST 등), 헤더, 바디.
응답(Response): 상태 코드(200 OK 등), 헤더, 바디.
5. Persistent vs. Nonpersistent Connections
Nonpersistent: 요청-응답마다 TCP 연결을 생성하고 종료.
Persistent: 하나의 TCP 연결로 여러 요청-응답 처리, 효율성 증대.
Core Takeaway (핵심 요점):
네트워크 프로토콜(DHCP, DNS)은 컴퓨터 간 통신을 자동화하고 효율적으로 만든다.
웹 프로토콜(HTTP, WWW)은 정보를 공유하고 웹 상호작용을 가능하게 한다.
Efficient protocols like persistent connections and HTTP enhancements enable faster and more reliable web communication. (영속적 연결과 HTTP 개선과 같은 효율적인 프로토콜은 빠르고 신뢰할 수 있는 웹 통신을 가능하게 한다.)
1️⃣ DHCP
(Dynamic Host Configuration Protocol)
DHCP는 TCP/IP (Transmission Control Protocol/Internet Protocol) 네트워크에서 컴퓨터나 다른 장치들이 네트워크에 접속할 때 필요한 IP 주소를 자동으로 할당하는 응용프로토콜 (Application Protocol) 이다. 이 프로토콜은 네트워크 설정을 자동화하여, 네트워크 관리자가 개별적으로 IP 주소를 할당하는 번거로움을 줄여주는 역할을 한다.
네트워크에 연결된 컴퓨터가 올바르게 작동하려면 다음 4가지 설정이 필수적이다:
IP 주소 (IP Address): 네트워크에서 컴퓨터를 고유하게 식별하는 주소.
서브넷 마스크 (Subnet Mask): 네트워크를 구분하는 정보. 일반적으로 255.255.255.0 또는 /24로 표현된다.
라우터 IP 주소 (Router IP Address): 인터넷이나 다른 네트워크와 통신할 수 있게 하는 기본 게이트웨이 (Default Gateway).
네임서버 IP 주소 (DNS Server IP Address): **DNS (Domain Name System)**와 관련되며, 텍스트 주소를 숫자로 변환 (e.g., google.com **→ 8.8.8.8)**해주는 역할을 한다.
이 설정들은 개인 컴퓨터에서는 비교적 간단하게 설정할 수 있지만, 조직 전체 네트워크를 관리하는 입장에서는 매우 번거롭고 휴먼 에러를 일으키기 쉬워진다.
DHCP (Dynamic Host Configuration Protocol)는 다음과 같은 이유로 설계되었다.
부팅한 컴퓨터가 위의 4가지 정보를 자동으로 받을 수 있도록 지원.
네트워크 관리자 대신 컴퓨터가 스스로 설정 작업을 수행.
자동화로 인해 설정이 더 간편하며, **휴먼 에러 (Human Error)**를 최소화.
즉 DHCP는 네트워크 관리자의 수고를 덜기 위해 수동 설정 대신, 컴퓨터가 부팅 시 필요한 네트워크 정보를 DHCP 서버에서 자동으로 가져오는 프로토콜이다.
DHCP #1: Message Exchange Process
(DHCP 메시지 교환 프로세스)
💡요약: DHCP가 클라이언트와 서버 간의 메시지를 통해 네트워크 정보를 자동으로 설정하는 과정을 소개한다. 클라이언트는 네트워크에 접속할 때 필요한 정보를 요청하고, 서버는 이에 응답하여 설정을 완료하게 된다.
How DHCP Assigns IP Addresses (DHCP가 IP 주소를 할당하는 방법)
Detailed Explanation (상세 설명)
1. Passive Open (패시브 오픈)
DHCP 서버는 항상 67번 포트와 68번 포트에서 클라이언트의 요청을 대기하는 상태이다.
네트워크에 연결된 컴퓨터가 전원을 켜면, 필요한 정보를 요청하는 과정을 시작하게 된다.
2. DHCP Discover (DHCP 디스커버)
Client Broadcasts a Discover Message (클라이언트가 디스커버 메시지를 브로드캐스팅함): 클라이언트는 아직 어떤 서버와 연결해야 할지 모르기 때문에 네트워크 전체에 브로드캐스팅 메시지를 보내게 된다.
이 메시지는 “누군가 저에게 네트워크 정보를 줄 수 있나요?”라는 요청다.
3. DHCP Offer (DHCP 오퍼)
Server Responds with an Offer (서버가 오퍼 메시지로 응답): Discover 메시지를 받은 DHCP 서버는 사용 가능한 IP 주소와 관련 정보를 담아 클라이언트에게 Offer 메시지를 보낸다.
여러 서버가 응답할 수 있으며, 클라이언트는 하나를 선택하게 된다.
4. DHCP Request (DHCP 리퀘스트)
Client Sends a Request to a Specific Server (클라이언트가 특정 서버에 요청 메시지 전송): 클라이언트는 여러 Offer 메시지 중 하나를 선택한 뒤 해당 서버에게 Request 메시지를 보낸다.
Request 메시지는 이제 특정 서버에게 전달되므로 브로드캐스팅이 아닌 단일 전송 방식으로 작동하게 된다.
5. DHCP Acknowledgement (DHCP ACK)
Server Sends an Acknowledgement (서버가 ACK 메시지 전송): 요청을 받은 서버는 클라이언트의 요청을 확인하고, 필요한 정보를 포함한 ACK 메시지를 보낸다.
이로써 클라이언트는 IP 주소와 네트워크 설정 정보를 성공적으로 받게 된다.
DHCP #2: Relay Agent and Subnet Communication (DHCP 릴레이 에이전트와 서브넷 통신)
💡요약: 클라이언트와 DHCP 서버가 서로 다른 네트워크(서브넷)에 위치한 경우, DHCP Relay Agent가 어떻게 통신을 중계하는지를 소개한다. 네트워크의 경계를 넘어 DHCP 요청을 전달하는 방법에 대해 설명하고 있다.
✅ Problem with Broadcast Packets (브로드캐스트 패킷 문제)
Broadcast Packets Don't Cross Subnets (브로드캐스트 패킷은 서브넷을 통과하지 못함): 클라이언트는 DHCP Discover 메시지를 보낼 때 수신자 주소를 255.255.255.255로 설정한다. 그러나 이 주소는 서브넷 외부로 전달되지 않으므로 다른 네트워크에 있는 DHCP 서버에 도달할 수 없게 된다.
이 문제로 인해 서브넷마다 별도의 DHCP 서버를 설정해야 하는 번거로움이 생길 수 있다.
✅ Solution: DHCP Relay Agent (해결책: DHCP 릴레이 에이전트)
Relay Agent Bridges Subnets (릴레이 에이전트가 서브넷을 연결함):
클라이언트와 동일한 서브넷에 위치한 DHCP Relay Agent는 클라이언트의 브로드캐스트 메시지를 받아, 이를 DHCP 서버의 유니캐스트 주소로 전달한다. 이를 통해 다른 서브넷에 있는 서버와 클라이언트가 통신할 수 있게 된다.Relay Agent는 클라이언트 메시지를 서버로 전달하고, 서버의 응답 메시지를 다시 클라이언트로 전달하게 된다.
✅ Network Configuration (네트워크 구성)
- Subnet and DHCP Server Placement (서브넷과 DHCP 서버 배치):
왼쪽 서브넷(회색 박스)은 클라이언트가 위치한 네트워크이고, 오른쪽 서브넷은 별도로 정의된 DHCP 서버가 위치한 네트워크이다. 두 네트워크 사이의 라우터를 통해 데이터가 전송된다.
DHCP #3: IP Address Leasing
(DHCP에서의 IP 주소 임대)
💡요약: 결과적으로 사용자, 클라이언트 입장에서 보면 네트워크 정보를 굳이 수동으로 설정하지 않더라도 자동으로 설정하게 된다. 한정되어 있는 IP주소를 DHCP서버가 할당해주네? 라고 생각할 수 있지만 할당 이라기 보단 잠시 이용할 수 있는 권한을 부여해주는 것과 같다. DHCP가 IP 주소를 "영구적으로 할당"하지 않고 "일시적으로 사용할 권한(임대)"을 부여하는 과정을 설명한다. 클라이언트는 주어진 임대 시간을 갱신하며, IP 주소를 지속적으로 사용할 수 있다.
✅ What is IP Address Leasing? (IP 주소 임대란?)
- DHCP 서버는 클라이언트에게 IP 주소를 할당할 때 Lease Time (임대시간)을 설한다. 클라이언트는 이 주소를 영구적으로 소유하지 않고, 설정된 기간 동안만 사용할 수 있다.
✅ Renewal at 50% of Lease Time (임대시간의 50% 시점에서 갱신)
- When Half the Lease Time Passes (임대시간의 절반이 지나면): 클라이언트는 DHCP REQUEST 메시지를 서버로 보내 갱신을 요청하게 된다. 서버가 이를 승인하여 ACK 메시지를 보내면 임대시간이 다시 초기화된다.
✅ No Response at 50% Time? (50% 시점에서 응답이 없을 경우)
- 클라이언트가 50% 시점에서 갱신 요청에 대한 응답을 받지 못하면,
87.5% of the Lease Time Passes (임대시간의 87.5% 시점)에 다시 REQUEST 메시지를 서버에 전송하게 된다.
✅ Successful Response (응답을 받은 경우)
- 서버가 요청을 승인하면, 클라이언트는 다시 임대시간 초기화로 돌아가며 IP 주소를 계속 사용할 수 있게 된다.
💡결론: DHCP의 임대 시스템은 효율적으로 IP 주소를 관리하며, 제한된 자원을 최대한 활용할 수 있게 한다.
2️⃣ DNS(Domain Name System)
DNS는 우리가 매일 매일 사용하는 것이다. 우리에게 익숙한 IP 주소는 인터넷에서 호스트를 식별할 수 있는 주소이다. IPv4에서 정의됨에 따라 4개의 숫자로 정의가 되어있다. 그리고 각각의 숫자는 255보다 작거나 같은 값으로 구성되어 있다. 따라서 특정한 서버를 접속하기 위해선 4개의 주소값을 알아야만 한다. 각각 사이트마다 다른 IP 숫자를 사람이 다 암기할수있을까? 불가능하다. 그래서 숫자로 표현된 주소보다는 텍스트로 정의된 주소값을 사람이 사용하도록 하고 그 텍스트를 기반으로 아이피를 변환하는것은 컴퓨터가 알아서 구동하도록 한다고 정의한 것을 “DNS”라고 한다.
✅ How DNS Simplifies the Internet (DNS가 인터넷을 단순화하는 방법)
사람이 기억하기 어려운 IP 주소를 대신해, 사람이 읽기 쉬운 텍스트 주소를 사용하도록 돕는 DNS (Domain Name System) 덕분에 인터넷 사용이 더욱 편리해졌다.
✅ What is an IP Address? (IP 주소란?)
- IP Address Identifies Devices on the Internet (IP 주소는 인터넷의 장치를 식별): IP 주소는 인터넷 상의 장치를 구분하기 위한 고유한 숫자이다. IPv4에서는 네 개의 숫자로 구성되며, 각 숫자는 0에서 255 사이의 값이다.
예:192.168.0.1
✅ The Challenge with IP Addresses (IP 주소의 한계)
- Hard for People to Remember Numbers (숫자를 기억하기 어려움): 각 웹사이트의 IP 주소를 사람이 기억하기는 매우 어렵다. 예를 들어, 특정 서버를 접속하려면 4개의 숫자 조합을 알아야 하므로 실용적이지 않다.
✅ What is DNS? (DNS란 무엇인가?)
- DNS Translates Text to Numbers (DNS는 텍스트를 숫자로 변환): 사람은
www.example.com처럼 텍스트로 된 주소를 사용한다. DNS (Domain Name System)는 이 텍스트 주소를 컴퓨터가 이해할 수 있는 숫자(IP 주소)로 변환한다.
✅ Why is DNS Important? (DNS가 중요한 이유)
- Makes the Internet User-Friendly (인터넷을 사용자 친화적으로 만듦): 사람들은 쉽고 직관적인 텍스트 기반 주소를 사용할 수 있다. 컴퓨터는 자동으로 이 텍스트를 숫자로 변환하므로 사용자는 복잡한 숫자를 알 필요가 없게 된다.
DNS #1: Converting Hostnames to IP Addresses (DNS의 작동 원리: 호스트 이름을 IP 주소로 변환하기)
💡요약: 사용자가 텍스트 기반의 호스트 이름 (hostname)을 입력했을 때, DNS가 이를 IP 주소로 변환하여 네트워크 통신을 가능하게 만드는 과정을 설명한다.
1. User Inputs Hostname (사용자가 호스트 이름 입력)
- 사용자는 File Transfer Client와 같은 애플리케이션에 www.example.com과 같은 텍스트 주소를 입력한다. 이는 사람이 이해하기 쉬운 방식으로 네트워크 리소스를 요청하는 첫 단계이다.
⬇️⬇️
2. Hostname Sent to DNS Client (DNS 클라이언트로 호스트 이름 전달)
- 애플리케이션 레이어의 파일 전송 클라이언트는 입력된 호스트 이름을 DNS Client에 전달한다.
⬇️⬇️
3. DNS Client Sends Query (DNS 클라이언트가 쿼리 전송)
DNS 클라이언트는 Query (쿼리)를 생성하여 DNS 서버에 요청을 보낸다.
이 요청은 "이 호스트 이름의 IP 주소를 알려주세요"라는 의미를 담고 있다.
⬇️⬇️
4. DNS Server Responds (DNS 서버가 응답)
- DNS Server는 데이터베이스를 조회하여 호스트 이름에 해당하는 IP 주소를 찾은 후, 이를 응답으로 클라이언트에 반환한다.
⬇️⬇️
5. DNS Client Sends IP to Application (DNS 클라이언트가 IP를 애플리케이션에 전달)
- DNS 클라이언트는 받은 IP 주소를 애플리케이션 클라이언트로 전달한다.
⬇️⬇️
6. Application Uses IP Address (애플리케이션이 IP 주소 사용)
- 애플리케이션은 IP 주소를 기반으로 네트워크 통신을 시작하며, 사용자가 요청한 작업이 실행된다.
DNS #2: Hierarchical Domain Name System (계층적 도메인 네임 시스템)
💡요약: DNS의 작동 원리: 호스트 이름을 IP 주소로 변환하기에서 - 호스트 이름을 어떻게 정의하는게 좋을까? 의논끝에 결과적으로 "Hierarchical Domain Name System (계층적 도메인 네임 시스템)"으로 결정되었다.
✅ What is a Hierarchical Domain Name Space? (계층적 도메인 네임 공간이란?)
- 호스트 이름을 여러 부분으로 나누어 구성하는 방식이다. 이는 도메인 이름을 조직의 성격, 이름, 부서 등으로 분리하여 관리하기 위함이다.
✅ Labels and Nodes (레이블과 노드)
Label (레이블): 문자열로 구성되며, 최대 63개의 문자를 가질 수 있다.
- 예:
www,example,com
- 예:
Nodes (노드): 트리 구조의 각 노드는 도메인 네임을 나타낸다. 루트는 최상위에 위치하며, 점(
.)으로 표시된다.
✅ Reading Order (읽는 순서)
Always Read from the Node to the Root (항상 노드에서 루트 방향으로 읽기):
도메인 이름은 가장 하위 레이블에서 시작해 최상위 루트까지 읽는다.
예:
www.example.com.
✅ Structure Example (구조 예시)
Top-Level Domain (최상위 도메인):
.com,.org,.edu등Second-Level Domain (2차 도메인):
example,google등Subdomains (서브도메인):
www,mail등
DNS #3: 계층적 도메인 네임 공간 Hierarchical Domain Name Space
위 예제는 계층적 도메인 네임 공간을 트리 구조로 표현하여, 루트(Root)에서 시작해 도메인이 점진적으로 분리되는 과정을 보여주고 있다.
✅ Root Level (루트 레벨): 도메인 네임 공간의 최상위에 Root (루트)가 위치한다. Root는 점(.)으로 표현되며, 모든 도메인의 시작점 역할을 한다.
✅ Top-Level Domains (최상위 도메인): Root 바로 아래에는 최상위 도메인(TLD)이 위치한다. 예) arpa, com, edu, org, ad, zw 등
최상위 도메인은 인터넷 사용 목적이나 지역을 기반으로 나뉜다.
Generic TLD (일반 TLD):
.com,.org,.eduCountry Code TLD (국가 코드 TLD):
.kr,.us,.jp
✅ Second-Level Domains and Beyond (2차 도메인 및 하위 도메인): Each TLD splits further into subdomains 각 최상위 도메인은 하위 도메인으로 나뉜다. 예) example.com, school.edu
- 하위 도메인은 필요에 따라 더 작은 도메인으로 분리될 수 있다. 예)
mail.example.com,cs.school.edu
✅ Tree Structure (트리 구조의 특징): 도메인 네임 공간은 트리 형태로 구성되어 관리와 검색이 효율적이다. 각 노드에는 도메인 이름이 있으며, 루트 방향으로 읽는다. 예) www.example.com
✅ How to Read a Domain Name from a Tree Structure
(트리 구조에서 도메인 이름 읽기)
특정 서비스에 대한 도메인의 이름을 찾고자한다면 트리구조를 꺼꾸로 보면 된다. 가장 아래 쪽에 세밀한 이름이 위치해 있다. 각 노드를 거칠때마다 .을 붙여야한다. 최종적인 full name 은 우리가 아주 익숙한 형태인 challenger.atc.fhda.edu로 완성된다.
✅ Start from the Bottom (가장 아래에서 시작): 트리 구조에서 가장 구체적인 이름(하위 노드)이 서비스나 자원의 이름을 나타낸다. 예) challenger
✅ Move Upward and Add Labels (위쪽으로 올라가며 레이블 추가): 하위 노드에서 상위 노드로 이동하면서 각 노드의 이름(레이블)을 추가한다. 각 레이블을 연결할 때마다 "."을 붙여준다. 예) challenger → challenger.atc → challenger.atc.fhda
✅ End with the Root (루트에서 끝내기): 최상위 루트(root)는 점(.)으로 표시된다. 최종 도메인 이름은 "challenger.atc.fhda.edu."처럼 완성된다. (마지막 점은 생략 가능)
✅ Full Domain Name (전체 도메인 이름): 최종적으로 하위 노드에서 상위 노드까지의 모든 레이블을 포함하여, 도메인 이름이 완성되었다. 이 이름은 우리가 익숙한 형태로 나타나게 된다. 예) challenger.atc.fhda.edu
DNS #4: 도메인 이름 이해하기 (Understanding Domain Names)
💡요약: 도메인 이름은 FQDN (Fully Qualified Domain Name)과 PQDN (Partially Qualified Domain Name) 2가지로 분리할 수 있다. 이 두 가지의 차이점을 알아본다. FQDN은 Fully, 전체 루트까지 포함한 전체 이름이고, PQDN은 Partially, 일부만 포함하는 의미가 있다.
✅ Fully Qualified Domain Name (FQDN)
FQDN은 호스트의 완전한 이름을 포함한 도메인 이름이다.
도메인 이름의 끝에 점(
.)이 붙으며, 이는 Root (루트)를 의미한다.Example of FQDN (FQDN 예시):
challenger.atc.fhda.edu.&www.funny.int.Key Feature (특징): 도메인 이름의 끝에
.이 있어, 트리의 최상위 루트까지 도달한 이름이다.
✅ Partially Qualified Domain Name (PQDN)
PQDN은 도메인 이름이 노드부터 시작했지만 루트에 도달하지 않은 이름이다. 즉 끝에 점(
.)이 없으며, 일반적으로 같은 사이트 내에서 사용하는 호스트 이름을 가리킬 때 사용한다.Example of PQDN (PQDN 예시):
challenger.atc.fhda.edu,cs.hmme,wwwKey Feature (특징): 끝에
.이 없으며, 현재 클라이언트와 동일한 사이트의 호스트를 나타낼 때 사용된다.
DNS #5: 인터넷에서 사용되는 DNS 도메인 유형 (Types of DNS Domains Used on the Internet)
💡요약: DNS 도메인은 루트(root)를 기준으로 크게 세 가지로 분류된다. Inverse Domain (역방향 도메인), Generic Domains (일반 도메인), Country Domains (국가 도메인)이다. 각 도메인은 특정 역할과 특징을 가지며, DNS의 효율적인 관리와 운영에 기여한다.
✅ Inverse Domain (역방향 도메인)
일반적으로 도메인 이름으로 IP 주소를 얻지만, 특정 상황에서는 IP 주소를 사용해 텍스트 도메인 이름을 알아내야 할 때도 있다. 이를 처리하기 위해 인버스 도메인이 정의되었다.
일반적인 도메인 이름 조회와는 반대 방향으로 작동한다.
예) 네트워크 관리자가 IP 주소를 기반으로 해당 호스트를 확인해야 할 때.
IP 주소를 역순으로 재배치하여 .in-addr.arpa 도메인 아래에서 검색한다.
- 예)
121.45.34.132→132.34.45.121.in-addr.arpa
✅Generic Domains(일반 도메인)
일반 도메인은 조직의 목적이나 특성에 따라 분류된다. 이들은 전 세계적으로 공통으로 사용되며, 특정 목적에 맞는 네임스페이스를 제공한다.
Subdomains and Structure (서브도메인과 구조)
Generic Domains 아래에 세부적인 서브도메인이 추가될 수 있다. 예) edu → fhda → atc → chal
최종적으로 완성된 도메인 이름은 chal.atc.fhda.edu와 같이 표시된다.
이러한 계층적 구조는 도메인을 효율적으로 관리하고 분리한다.
Examples of Generic Domains (일반 도메인의 예시)
.com: 상업용 조직 (Commercial Organizations)
.gov: 정부 기관 (Government Agencies)
.org: 비영리 단체 (Non-Profit Organizations)
.edu: 교육 기관 (Educational Institutions)
.net: 네트워크 관련 서비스 (Network Providers)
Purpose of Generic Domains (일반 도메인의 목적)
각 도메인은 특정 유형의 조직이나 서비스에 맞게 설계되었다.
- 예:
.edu는 교육 기관을,.gov는 정부 기관을 명확히 구분하여 사용한다.
- 예:
이러한 분류는 인터넷 리소스를 체계적으로 정리하고, 사용자가 쉽게 이해할 수 있도록 돕는다.
✅ Country Domains (국가도메인)
국가 도메인은 특정 국가를 나타내며, 도메인의 이름이 해당 국가의 약자를 포함한다. 이는 지역 기반 서비스와 국가별 관리에 사용된다.
Two-Letter Country Code (두 글자의 국가 코드):
국가 도메인은 ISO 3166 표준에 따라 두 글자로 표시된다.
us→ United States (미국)fr→ France (프랑스)ae→ United Arab Emirates (아랍에미리트)kr→ South Korea (대한민국)
Structure of Country Domains (국가 도메인의 구조): 국가 도메인 내에서도 하위 도메인으로 세분화될 수 있다. 이러한 구조는 특정 국가 내 지역이나 조직을 더 세부적으로 나타낼 수 있도록 설계되었다.
us (미국)
- ca.us (California), cup.ca.us (Cupertino, California), anza.cup.ca.us (Anza, Cupertino, California)
Purpose of Country Domains (국가 도메인의 목적)
각 국가의 인터넷 자원 관리와 지역별 구분을 용이하게 한다.
로컬 사용자와 서비스를 명확히 구분할 수 있다.
DNS #6: Understanding How DNS Resolves Names to IP Addresses (DNS가 이름을 IP 주소로 변환하는 과정 이해하기)
💡요약: DNS 프로토콜은 어떤식의 메세지 교환을 통해서 아이피 주소로 변환된 결과를 얻을 수 있는지에 대해 살펴보자. DNS는 이름을 IP 주소로 변환하는 단순한 클라이언트-서버 구조로 작동하게 된다. 클라이언트는 이름 해석기(Resolver)를 통해 로컬 네임 서버(Local Name Server)에 요청을 보낸다. 이때 귀환적(Recursive) 방식과 반복적(Iterative) 방식 두 가지로 요청을 처리한다. 또한, 캐싱(Caching)을 사용하여 동일 요청의 반복을 방지할 수 있다.
✅How Does DNS Work? (DNS는 어떻게 동작하나요?)
Client-Server Structure (클라이언트-서버 구조): 클라이언트는 이름 해석기(Resolver)를 통해 로컬 네임 서버에 요청을 보낸다. 네임 서버는 요청된 이름에 대한 IP 주소를 찾아 클라이언트에 반환한다.
클라이언트는 개인 컴퓨터가 될 수 있다.
✅ Types of Query Resolution (해석 방식의 유형): DNS는 클라이언트의 요청을 처리하기 위해 두 가지 방식으로 동작한다. Iterative Resolution(반복적 해석)은 클라이언트가 직접 DNS 서버에 여러 번 요청하며 도메인의 IP 주소를 찾는 방식이다.
- 클라이언트는 여러 번 요청을 반복해야 하므로 부담이 증가하지만, 네트워크와 DNS 서버의 부담은 감소한다.
- Recursive Resolution (귀환적 해석): 로컬 네임 서버가 모든 과정을 책임지고 최종 IP 주소를 찾아 클라이언트에 반환하는 방법이다. 클라이언트는 하나의 요청만 보내고 결과를 기다리게 된다.
클라이언트가 요청한 도메인 (mcgraw.com)의 IP 주소를 찾기 위해 DNS 서버가 귀환적 해석(Recursive Resolution) 방식을 사용하는 과정이다. 클라이언트는 단순히 요청만 보내며, 모든 작업은 네트워크의 DNS 서버들이 처리한다.
- Iterative Resolution (반복적 해석): 로컬 네임 서버는 요청을 받은 후, 다음 서버의 정보를 제공하여 클라이언트가 직접 요청을 반복한다. 클라이언트가 여러 요청을 보내며 필요한 정보를 단계적으로 얻는다.
클라이언트가 직접 여러 DNS 서버에 요청하며 정보를 점진적으로 얻는 방식을 보여준다/ 클라이언트의 부담은 커지지만 네트워크와 DNS 서버의 부담은 줄어드는 특징이 있다
- Default Behavior in DNS (DNS 기본 설정)
클라이언트가 옵션을 설정하지 않을 경우, DNS는 기본적으로 반복적 해석(Iterative Resolution)을 사용한다.
클라이언트가 귀환적 해석을 원할 경우, 이를 명시적으로 요청해야 한다.
- Caching in DNS (DNS의 캐싱)
DNS는 캐싱(Caching) 방식을 사용하여 동일 이름에 대한 반복적인 요청을 방지한다.
로컬 네임 서버는 이전 요청의 결과를 일정 기간 저장하여, 다시 요청이 들어오면 캐시된 데이터를 빠르게 반환하게 된다.
- 예: 이미 요청된
www.example.com의 IP 주소가 캐시에 있다면, 새 요청 시 원 서버에 접근하지 않고 캐시된 결과를 반환한다.
- 예: 이미 요청된
DNS #7: Encapsulation and Dynamic DNS (DNS의 캡슐화와 동적 DNS)
💡요약: DNS 서비스에선 캡슐화가 가능한데 UDP, TCP 모두 동일하게 53번 포트를 사용한다. 대부분의 개인 컴퓨터는 512바이트보다 작기 때문에 UDP를 주로 사용되고 그 외의 상황에서는 TCP를 사용할 수 있도록 정의 되어있다. 마지막으로 DDNS는 DNS에서 하나가 추가된 개념이다.
✅ DNS Encapsulation (DNS의 캡슐화)
Protocols and Port Usage (프로토콜과 포트 사용):
DNS는 UDP와 TCP 프로토콜 모두를 사용하며, 두 경우 모두 53번 포트를 사용한다.
UDP는 빠르고 간단한 데이터 전송에 적합합니다.
When to Use UDP or TCP? (UDP와 TCP의 사용 기준):
512바이트 이하의 응답 메시지: UDP 사용
- 대부분의 개인 컴퓨터 요청은 이 범위에 해당하므로 UDP가 주로 사용된다.
512바이트 초과 응답 메시지: TCP 사용
- 예: 대형 데이터 전송이나 특정 보안 요구 사항.
✅ Dynamic DNS (DDNS) Overview (동적 DNS의 개념)
What is DDNS? (DDNS란?)
기존의 DNS는 IP 주소가 정적으로 설정된 환경에서 설계되었다.
그러나 현대 환경에서는 IP 주소가 자주 변경될 수 있으며, 이를 자동으로 처리할 메커니즘이 필요하게 되었다.
DDNS는 이런 변경 상황을 자동으로 반영하여 DNS 데이터를 업데이트하게 된다.
Why is DDNS Useful? (DDNS가 유용한 이유):
동적 IP 주소: 인터넷 서비스 제공업체(ISP)가 사용자에게 동적 IP 주소를 제공하는 경우 유용하다.
자동 업데이트: 관리자가 직접 IP 주소를 변경할 필요 없이 자동으로 처리되어 편하다.
3️⃣ 월드 와이드 웹과 HTTP (World Wide Web and HTTP)
💡요약: World Wide Web (WWW)이 어떻게 인터넷의 대중화를 이끌었는지와, 정보를 연결하는 하이퍼링크(hyperlink) 구조의 중요성을 설명한다. WWW는 하이퍼텍스트와 하이퍼미디어를 통해 정보 공유와 탐색을 가능하게 한,인터넷이 오늘날까지 발전하기까지 중요한 역할을 하였다.
✅ What is the World Wide Web? (월드와이드웹이란?)
월드와이드웹(WWW)은 1983년 유럽 입자 물리 연구소(CERN)의 팀 버너스 리(Tim Berners-Lee)가 제안한 정보 교환 방식이다.
WWW는 인터넷에 연결된 컴퓨터 간에 정보를 공유할 수 있는 공간을 뜻한다.
✅ Features of the World Wide Web (월드와이드웹의 특징)
Hyperlink Structure (하이퍼링크 구조):
Hypertext and Hypermedia (하이퍼텍스트와 하이퍼미디어):
특정 텍스트, 이미지, 또는 미디어에 링크를 연결하여 다른 문서나 정보를 가리킨다.마우스 클릭만으로 링크를 따라 이동하며 웹 서핑(Web Surfing) 또는 웹 브라우징(Web Browsing)이 가능해졌다.
Web Pages and Websites (웹 페이지와 웹사이트):
관련된 정보를 모아둔 웹 페이지들의 집합을 웹사이트라고 한다.
✅ Why is WWW Important? (WWW가 중요한 이유)
Pre-WWW Era (WWW 이전 시대):
- 사용자는 명령어(Command)를 입력해 정보를 조회해야 했고, 결과는 단순 텍스트 형태로 표시되었다. 일반 사용자가 접근하기 어려웠다.
Post-WWW Era (WWW 이후 시대):
- WWW는 그래픽 기반 웹 브라우저를 도입하여 일반 사용자도 쉽게 인터넷을 사용할 수 있도록 만들었다. 인터넷이 대중화되는 데 중요한 역할을 했다.
✅Key Terms (핵심 용어)
Hyperlink (하이퍼링크): 다른 정보나 문서를 가리키는 텍스트나 미디어. 이를 클릭하여 관련 정보를 탐색한다.
Web Surfing (웹 서핑): 하이퍼링크를 따라 정보를 탐색하는 행위. 예) 클릭을 통해 여러 페이지를 방문.
Website (웹사이트): 관련된 웹 페이지들이 모여 있는 집합체.
Web Client(웹 클라이언트): 사용자가 입력한 URL을 기반으로 웹 문서에 접근하고 해석하여 화면에 표시하는 소프트웨어이다. 일반적으로 웹 브라우저라고 불리며, 사용자와 인터넷을 연결하는 게이트웨이 역할을 한다. 예) 크롬, 파이어폭스, 사파리, 익스플로어
Web Server(웹서버): 웹 문서를 저장하는 공간으로, 클라이언트의 요청이 있을 때마다 해당 문서를 전달한다. 웹 클라이언트가 요청한 파일, 이미지, 또는 데이터를 제공하는 정보의 출처 역할을 한다. 예) Apache: 오픈소스 웹 서버 소프트웨어, MS Internet Information Server (IIS): 마이크로소프트의 웹 서버 플랫폼.
💡How Do They Work Together? (웹 클라이언트와 웹 서버의 협력 과정)
사용자가 브라우저(웹 클라이언트)에 URL을 입력한다.
웹 클라이언트는 웹 서버에 데이터를 요청한다.
- 요청: "example.com의 홈페이지를 주세요."
웹 서버는 요청된 문서를 찾아 클라이언트로 반환한다.
웹 클라이언트는 반환된 데이터를 화면에 표시한다.
WWW #1: Distributed Client/Server Structure (월드 와이드 웹: 분산 클라이언트/서버 구조)
💡요약: 월드 와이드 웹이 어떻게 분산 클라이언트/서버 구조를 기반으로 작동하는지 알아본다. 클라이언트는 하나의 서비스를 이용하는 것처럼 느껴지지만, 실제로는 여러 서버가 각각의 역할을 수행하며 요청과 응답을 처리한다.
✅ What is a Distributed System? (분산 시스템이란?)
월드 와이드 웹은 여러 서버가 분산되어 서로 다른 작업을 처리한다. 아래 예시를 보면 이해가 더 쉽다.
클라이언트는 하나의 통합된 서비스를 사용하는 것처럼 느끼지만, 각 서버는 특정 파일이나 데이터(예: 문서, 이미지)를 제공한다.
✅Key Concept: Multiple Servers (주요 개념: 여러 서버):
클라이언트는 요청(Request)을 통해 데이터를 요구하고, 서버는 응답(Response)으로 데이터를 반환한다.
요청은 각 서버에 분리되어 전송되며, 서버마다 특정 역할을 담당한다.
Step 1: 클라이언트가 Site I에
A문서를 요청한다.Request 1: "A 문서를 주세요."
Response 1: 서버는
A문서를 반환한다.
Step 2: 클라이언트는
A문서 안에 포함된 이미지(B)를 요청한다.Request 2: "이미지 B를 주세요.”
Response 2: 서버는 이미지
B를 반환한다.
Step 3:
A문서 안에 또 다른 파일(C)에 대한 참조가 있으면, 클라이언트는 Site II에 요청을 보낸다.Request 3: "Site II의 파일 C를 주세요."
Response 3: Site II의 서버가 파일
C를 반환한다.
WWW #2: URL Structure and Usage in Web Browsing (URL의 구조와 웹 브라우징에서의 사용)
💡요약: 웹 브라우저의 입장에서는 어떤 문서가 어디에 저장되고 관리되고 있는지 알아야 한다. 그래서 위치를 지정하는 포멧이 필요한데 이를 URL로 표현하고 있다. 인터넷 상의 특정 정보를 찾는데 사용하는 표준 주소 형식인 셈이다. 인터넷 상에 있는 모든 정보를 지정할 수 있다. 전송계층으로 TCP를 사용하고 그 상위에서 HTTP를 사용하며, 80번 포트 번호를 사용한다. URL의 형식은 첨부된 예제와 같다. 포트주소는 보통 80번을 사용하도록 정의가 되어있다. 새로운 포트를 사용할 수도 있지만 사용하게 되면 웹 브라우저가 알고 있지 못하는 상황이기 때문에 새로운 포트 주소도 함께 입력해야 한다.
✅ What is a URL? (URL이란?)
- URL은 웹 브라우저가 특정 문서가 어디에 저장되어 있는지를 알아내기 위해 사용하는 주소 형식이다. 인터넷 상의 모든 정보의 위치를 지정하는 표준이다.
Protocol (프로토콜): 서버와 데이터를 주고받는 방식이다.
- 예) http: Hypertext Transfer Protocol (하이퍼텍스트 전송 프로토콜), https: HTTP + Secure (보안을 추가한 HTTP).
Host (호스트): 정보를 저장하고 있는 서버의 주소를 나타낸다. 예)
www.example.com.Port (포트): 서버와 통신하기 위해 사용되는 번호.
기본적으로 HTTP는 80번 포트, HTTPS는 443번 포트를 사용한다.
새로운 포트를 사용할 경우, 반드시 포트 번호를 명시해야 한다.
Path (경로):서버 내에서 특정 문서나 파일의 위치를 나타낸다. 예)
/folder/page.html.
✅URL in Action (URL의 동작 방식)
User Input (사용자 입력):
사용자가 브라우저에 URL을 입력.
Browser Request (브라우저 요청):
브라우저는 프로토콜, 호스트, 포트를 기반으로 요청을 생성한다.
경로를 따라 요청한 문서를 찾는다.
Response (응답):
서버는 요청된 문서를 브라우저에 반환한다.
브라우저는 이를 화면에 표시한다.
WWW #3: Classification of Web Documents Based on Content Generation Timing (문서의 내용 결정 시점에 따른 웹 문서의 분류)
💡요약: 웹 문서의 형식은 크게 3가지로 분류된다. 문서의 내용이 결정되는 시점에 따라서 달라진다. 우리는 당연하게도 웹 문서의 내용이 저장 되어 있는 것 아닌가? 라고 생각할 수 있지만 많은 경우 상황에 따라 문서의 내용이 변화하기도 한다. 더 자세한 내용을 알아보자.
웹 문서는 문서 내용이 결정되는 시점에 따라 위의 세 가지로 분류된다. 각 유형은 웹 문서가 생성되고 업데이트되는 방식에서 차이가 있다.
✅Static Documents (정적 문서): 정적 문서는 고정된 내용으로 서버에 저장되어 모든 사용자에게 동일한 정보를 제공한다.
What is a Static Document? (정적 문서란?)
정적 문서는 서버에서 미리 생성되어 저장된 콘텐츠로, 내용이 고정되어 있다.
클라이언트는 요청 시 서버에서 문서의 복사본을 받는다.
정적 문서의 내용은 수동으로 수정하지 않는 한 변하지 않는다.
Characteristics of Static Documents (정적 문서의 특징)
Fixed Content (고정된 내용):
서버에 저장된 문서는 요청 시 그대로 전달된다.
사용자의 요청에 따라 내용이 바뀌지 않는다.
Simple to Create and Use (생성 및 사용이 간단):
서버가 추가적인 처리를 하지 않아도 된다.
정적인 정보를 제공하기에 적합하다.
Examples of Static Content (정적 콘텐츠의 예):
- 회사 소개, 약도, FAQ, 회사 소개 페이지, 블로그의 고정된 글.
Examples of Static Document Formats (정적 문서 형식의 예시)
HTML (Hypertext Markup Language): 웹 페이지를 작성하는 기본 언어.
XML (Extensible Markup Language): 데이터를 구조화하고 저장하기 위한 언어.
XSL (Extensible Style Language): XML 문서의 스타일을 지정하기 위한 언어.
XHTML (Extended Hypertext Markup Language): HTML과 XML의 조합으로 고정된 웹 콘텐츠 제공.
✅ Dynamic Documents (동적 문서): 클라이언트의 요청에 따라 서버가 실시간으로 생성하는 문서이다. 이는 서버 내부의 응용프로그램이나 스크립트를 통해 이루어지며, 다양한 사용자 요청에 맞춰 맞춤형 콘텐츠를 제공한다.
What is a Dynamic Document? (동적 문서란?)
동적 문서는 클라이언트의 요청마다 새로 생성되는 문서이다.
서버는 정적 문서와 달리, 동적 응용 프로그램이나 스크립트를 사용해 실시간으로 콘텐츠를 생성한다.
데이터베이스와 연결되어 있는 경우가 많다.
예: 검색 결과 페이지, 사용자가 로그인한 후 표시되는 맞춤형 대시보드.
How Are Dynamic Documents Generated? (동적 문서는 어떻게 생성되나요?)
서버는 내부에 프로그램이나 스크립트를 실행하여 요청된 정보를 처리하고, 클라이언트에 결과를 반환한다.
예를 들어, 사용자가 쇼핑몰에서 특정 상품을 검색하면, 실시간으로 데이터베이스를 조회하여 해당 상품 정보를 보여준다.
Common Gateway Interface (CGI, 공통 게이트웨이 인터페이스)
CGI는 서버와 프로그램 간 데이터를 주고받는 방법과 규약을 뜻한다.
서버가 클라이언트 요청을 받아 프로그램에 전달하고, 프로그램의 결과를 다시 서버가 클라이언트에 반환한다.
Key Features of CGI (CGI의 주요 특징):
Programming Flexibility (프로그래밍 유연성): 일반적인 프로그래밍 언어로 동적 문서를 작성할 수 있다. 예: Python, Perl, PHP, Ruby.
Interoperability (상호 운용성): 규정된 인터페이스만 따르면 어떤 언어로도 구현 가능하다.
Real-Time Content (실시간 콘텐츠): CGI는 요청에 따라 맞춤형 문서를 실시간으로 생성한다.
👀번외: Modern Scripting Technologies for Dynamic Documents
(동적 문서를 위한 현대적 스크립트 기술)
동적 문서를 생성하기 위한 기술은 CGI에서 시작했지만, CGI는 웹 문서 전체를 새롭게 생성해야 하므로, 서버 자원이 낭비되는 단점이 있다. 사용자의 요청마다 새로 생성하는 방식은 속도가 느리고, 확장성이 떨어지게 된다. 즉 효율성 부족으로 인해 새로운 방식들이 등장하였다.
최신 기술들은 웹 문서의 고정된 부분은 HTML로 처리하고, 변경이 필요한 일부분만을 스크립트 언어로 프로그래밍하여 내장하는 기술들이다. 이 방식을 통해 서버의 작업량을 줄이고, 효율성을 극대화한다.
PHP (Hypertext Preprocessor)주로 웹 개발에서 널리 사용되는 언어- 서버 측에서 실행되며, 사용자의 요청에 따라 데이터베이스와 상호작용하여 콘텐츠를 동적으로 생성한다. 예) 사용자 맞춤형 뉴스 피드 생성.
JSP (Java Server Pages)Java 기반 기술로, HTML과 Java 코드를 함께 작성하여 동적 콘텐츠를 제공한다.
예: 쇼핑몰의 사용자 로그인 및 추천 상품 표시.
ASP (Active Server Pages)- 마이크로소프트에서 개발한 기술로, HTML과 서버 측 코드를 결합하여 동적 웹 페이지를 생성한다. 예) 실시간 주식 데이터 표시.
✅ Active Documents (액티브 문서)
💡요약: 클라이언트 측에서 실행되는 프로그램이나 스크립트를 필요로 하는 웹 문서이다. 서버에서 결과물을 생성해 전달하는 동적 문서와 달리, 클라이언트가 받은 문서가 브라우저에서 직접 실행되는 방식을 특징으로 한다.
What is an Active Document? (액티브 문서란?)
요청 후에도 사용자와의 상호작용에 따라 계속 업데이트되거나 동작하는 문서이다.
클라이언트 측에서 실행되는 스크립트 또는 애플리케이션을 포함한다.
Key Characteristics of Active Documents (액티브 문서의 주요 특징)
Client-Side Execution (클라이언트 측 실행): 액티브 문서는 클라이언트(사용자의 웹 브라우저)에서 실행되는 스크립트나 프로그램이 포함되어 있다. 서버에서 처리한 결과만 전달하는 동적 문서와 달리, 클라이언트의 기기에서 추가 작업을 수행하게 된다.
Interactivity (상호작용성): 사용자가 입력하거나 특정 동작을 수행하면, 문서의 동작이나 화면 내용이 실시간으로 변경된다. 예) 실시간 계산기, 드래그 앤 드롭 기능, 애니메이션 효과.
Alternative Name (다른 이름): "Client-Side Dynamic Document (클라이언트 사이트 동적 문서)"로 불리기도 한다.
Examples of Active Documents (액티브 문서의 예시)
Java Applet (자바 애플릿): Java 언어로 작성된 작은 애플리케이션으로, 웹 브라우저 내에서 실행된다. 예) 주식 차트, 실시간 시뮬레이션.
JavaScript (자바스크립트): 클라이언트 측에서 실행되는 프로그래밍 언어로, 웹 페이지에 동적인 콘텐츠를 추가한다. 예) 폼 유효성 검사, 슬라이드쇼, 실시간 채팅.
How Active Documents Work (액티브 문서의 작동 방식)
Request and Response (요청 및 응답): 클라이언트가 서버에 요청하면, 서버는 액티브 문서를 클라이언트에 반환한다.
Client-Side Execution (클라이언트 측 실행): 클라이언트가 받은 문서에는 실행 가능한 스크립트나 프로그램이 포함되어 있다. 사용자의 행동(클릭, 입력 등)에 따라 스크립트가 실행된다.
Dynamic Changes (동적인 변화): 클라이언트가 웹 페이지와 상호작용하면서 문서의 내용이 실시간으로 업데이트된다.
WWW #4: Static vs Dynamic Documents in Web Servers (웹 서버에서 정적 문서와 동적 문서의 차이)
💡요약: 클라이언트 요청에 대해 서버가 어떻게 다르게 응답하는지 알아본다. 정적 문서는 단순히 저장된 데이터를 반환하지만, 동적 문서는 요청에 따라 실시간으로 생성된 결과를 반환한다.
✅Content Generation (문서 생성)
정적 문서: 서버에 저장된 그대로 전달.
동적 문서: 요청마다 실시간으로 생성.
✅Server Load (서버 부하)
정적 문서: 서버 부하가 적음.
동적 문서: 요청 처리와 문서 생성을 위해 서버 자원을 더 많이 사용.
✅ Flexibility (유연성)
정적 문서: 고정된 내용만 제공.
동적 문서: 사용자 요청에 따라 맞춤형 콘텐츠 제공.
WWW #5: HTTP Protocol and Transactions (HTTP 프로토콜과 트랜잭션)
💡요약: 위에서 배운 문서들을 클라이언트-서버가 교환할 때 사용하는 프로토콜을 HTTP, HyperText Transfer Protocol (하이퍼텍스트 전송 프로토콜)라고 한다. 월드 와이드 웹에서 웹 문서에 접근하는데 사용되는 프로토콜이다. 잘 알려진 포트 80으로, 오류를 줄이기위해 TCP서비스를 이용한다. 서버와 클라이언트가 정보를 주고받는 기본적인 방식이며, 상태 정보를 저장하지 않는 특성을 가지고 있다.
✅What is HTTP? (HTTP란?)
HTTP는 웹에서 클라이언트와 서버 간 문서(동적, 정적, 웹문서)를 전송하는 데 사용되는 프로토콜이다.
잘 알려진 포트 번호 80을 사용하며, 오류를 줄이기 위해 신뢰성이 높은 TCP 서비스를 이용한다.
예) 사용자가 브라우저에서 URL을 입력하면, HTTP를 통해 서버가 해당 웹 페이지를 반환하게 된다.
✅ Stateless Protocol (상태 없는 프로토콜)
What does "Stateless" mean? (상태 없다는 것은 무슨 뜻인가요?)
HTTP는 클라이언트의 이전 요청이나 상태를 저장하지 않는다.
서버는 각 요청을 독립적으로 처리하며, 누가 요청했는지를 기억하지 않는다.
Examples of Stateless Behavior (상태 없는 동작의 예):
사용자가 웹사이트에 로그인하면, 서버는 입력된 ID와 비밀번호에 따라 정보를 반환한다. 그러나, 서버는 이전 로그인 세션을 기억하지 않으므로 다음 요청 시에도 로그인 정보를 다시 입력해야 한다.
근래에는 쿠키는 클라이언트 정보(예: 로그인 세션)를 브라우저에 저장하여 서버가 사용자를 구분할 수 있도록 돕는다.
쿠키의 예로는 사용자가 쇼핑몰에 로그인하면, 쿠키를 통해 서버가 사용자 정보를 기억하여 장바구니 상태나 추천 상품을 유지하는 것과 같다.
✅ HTTP Transactions (HTTP 트랜잭션)
HTTP 트랜잭션은 클라이언트의 요청(Request)과 이에 대한 서버의 응답(Response)으로 구성된다.
클라이언트가 서버에 데이터를 요청하면, 서버는 요청에 적합한 데이터를 찾아 응답하는 방식이다.
How does an HTTP Transaction Work? (HTTP 트랜잭션은 어떻게 작동하나요?)
Request (요청): 클라이언트가
GET /index.html요청을 보낸다. 예) 웹 페이지를 열기 위한 요청.Response (응답): 서버는 상태 코드
200 OK와 함께 요청된index.html의 콘텐츠를 본문으로 반환한다.요청과 응답이 완료되면 트랜잭션이 종료된다.
Components of Request Message (요청 메시지 구성 요소) : 클라이언트가 서버에 데이터를 요청할 때 사용하는 메시지이다.
Request Line (요청 라인): 요청의 핵심 정보를 정의한다. 예:
GET /index.html HTTP/1.1HTTP/1.1: 사용된 HTTP 프로토콜 버전.
Method (메서드): 서버에서 수행할 작업을 정의함.
- 예:
GET(데이터 요청),POST(데이터 전송).
- 예:
URL: 요청하는 리소스의 경로.
Version (버전): HTTP 프로토콜 버전 (예: HTTP/1.1).
Headers (헤더): 요청에 대한 추가 정보가 포함된다. 예)
User-Agent:클라이언트 브라우저 정보,Accept:클라이언트가 허용하는 콘텐츠 유형Blank Line (빈 줄): 헤더와 본문을 구분한다.
Body (본문): 필요한 경우 데이터(예: 폼 입력값)를 포함한다.
HTTP Response Message (HTTP 응답 메시지): 서버가 요청에 대한 결과를 클라이언트에 반환할 때 사용하는 메시지이다.
Status Line (상태 라인): 서버의 응답 상태를 정의한다. 예)
HTTP/1.1 200 OKVersion (버전): HTTP 프로토콜 버전.
Status Code (상태 코드): 응답 상태를 나타내는 숫자 코드.
- 예:
200(성공),404(리소스 없음).
- 예:
Phrase (문구): 상태 설명.
Header Lines (헤더): 응답에 대한 추가 정보를 포함.
- 예)
Content-Type:응답 콘텐츠의 유형 (예: HTML, JSON),Content-Length:콘텐츠의 길이.
- 예)
Blank Line (빈 줄): 헤더와 본문을 구분한다.
Body (본문): 요청한 데이터(예: HTML 페이지, 이미지 등)를 포함한다.
Key Similarities Between Request and Response (요청과 응답의 주요 공통점)
Structure (구조): 요청과 응답 모두 첫 라인 → 헤더 → 빈 줄 → 본문 순서로 구성된다.
Headers (헤더): 요청과 응답 모두 헤더를 통해 추가 정보를 제공한다.
Optional Body (선택적 본문): 일부 메시지에는 본문이 없을 수도 있다 (예:
GET요청).
WWW #6: HTTP Methods in Request Line (HTTP 요청 라인의 메소드)
💡요약: 위에서 언급된 HTTP Request Message에서 사용되는 Method(메서드)의 종류에 대해서 알아본다. 메서드는 클라이언트가 서버로 보낸 요청에서 수행하려는 작업의 종류를 정의한다. 요청 라인의 가장 첫 부분에 위치하며, 서버가 요청의 목적을 이해할 수 있도록 도움을 준다.
자주 사용되는 메서드
- GET: Request a document from the server, 서버에서 데이터를 가져오기 위한 요청이다. 예) 웹 페이지를 열 때 브라우저가 보내는 요청.
POST: Sends some information from the client to the server, 클라이언트가 데이터를 서버에 제출할 때 사용한다. 예) 로그인 양식 제출, 댓글 작성.
PUT: Sends a document from the client to the server, 서버에 데이터를 업로드하거나 기존 데이터를 수정할 때
그 외로 HEAD, DELETE, OPTIONS, TRACE: 특정 상황에서 사용되는 보조적인 메소드이다.
ACTION, DELECT, OPTIONS, TRACE, CONNECT는 상대적으로 덜 사용되는 메소드이다.
👀번외: Document Retrieval Using GET Method (GET 메서드를 사용한 문서 요청 과정)
GET 메서드는 클라이언트가 서버에 특정 문서를 요청할 때 사용된다.
- Client Request (클라이언트 요청): 클라이언트는 서버로 요청 메시지를 보낸다.
GET: 클라이언트가 서버에서
/usr/bin/image1파일을 요청.Accept: 클라이언트가 요청하는 파일 형식(예: GIF 또는 JPEG 이미지).
- 서버는 클라이언트 요청을 확인한 후 응답 메시지를 보낸다.
200 OK: 요청이 성공적으로 처리됨.
Content-Length: 응답 본문의 크기(2048 바이트).
Body: 요청된 문서의 실제 데이터.
- Client Receives Document (클라이언트가 문서를 수신): 클라이언트는 서버의 응답 메시지와 함께 문서를 획득하게 된다.
👀번외: Data Transfer from Client to Server using POST Method (POST 메서드를 사용한 클라이언트에서 서버로 데이터 전송)
POST 메서드는 클라이언트가 서버로 데이터를 전송할 때 사용하는 HTTP 메서드이다. 주로 폼 데이터 제출(예: 로그인 정보, 검색어 입력, 데이터 저장, 회원가입 등)이나 파일 업로드 같은 작업에 사용된다.
Client Request (클라이언트 요청): 클라이언트는 서버로 데이터를 포함한 요청 메시지를 보낸다.
POST: 데이터를 서버로 전송하겠다는 요청.
Content-Length: 전송된 데이터의 크기(50 바이트).
Input information: 클라이언트가 서버로 전송한 실제 데이터(예: 사용자 입력값).
Server Response (서버 응답): 서버는 요청을 처리한 후, 응답 메시지를 클라이언트로 보낸다.
200 OK: 요청이 성공적으로 처리되었음을 나타내는 상태 코드.
Content-Length: 응답 본문의 크기(2000 바이트).
Body of the document: 처리된 요청에 대한 결과 데이터.
WWW #7: HTTP Request Headers and Their Role (HTTP 요청 헤더와 역할)
💡요약: HTTP 트랜잭션에서 Request Message 부분에서 언급된 Headers의 이름에 대해서 설명한다. 헤더 라인은 요청에 대한 추가적인 옵션을 서버에 전달하는 역할을 한다. 클라이언트와 서버 간 통신을 보다 효율적이고 맞춤화된 방식으로 수행하도록 돕는다.
User-Agent: 클라이언트 프로그램 정보.
Accept: 수락할 수 있는 콘텐츠 형식.
Cookie: 클라이언트의 쿠키 반환.
Authorization: 클라이언트 권한.
헤더는 요청 메시지의 옵션 정보를 전달한다.
클라이언트가 서버에 어떤 데이터를 요청하는지, 요청 조건과 환경에 대한 추가 정보를 포함한다.
서버는 헤더 정보를 바탕으로 보다 맞춤형 응답을 제공할수 있게 된다.
WWW #8: HTTP Status Codes in Response Messages (HTTP 응답 메시지의 상태 코드)
💡요약: HTTP 트랜잭션 과정에서 Response Message의 구성을 보면 Status Line이 있다. 이는 서버의 응답 상태를 정의하는데 Status Code (상태 코드)도 이 상태라인의 일부분이다. 상태코드는 3자리의 숫자로 표현된다. 서버가 클라이언트 요청에 대해 처리 상태를 알려주는 방식으로, 요청이 성공했는지, 실패했는지, 혹은 추가 작업이 필요한지를 나타낸다.
Key Categories (주요 범주):
1xx: 정보 제공.
2xx: 요청 성공.
3xx: 리다이렉션.
4xx: 클라이언트 오류.
5xx: 서버 오류.
Common Codes (대표 코드):
200 OK:요청 성공.404 Not Found:요청한 리소스 없음.500 Internal Server Error:서버 오류 발생.
WWW #9: HTTP Response Headers and Their Role (HTTP 응답 헤더와 역할)
💡요약: Status Line과 마찬가지로 Header또한 HTTP Response Message의 구성요소이다. 이 정보는 클라이언트가 서버 응답을 이해하고 처리할 수 있도록 돕는 역할을 한다.
Common Headers (주요 헤더):
Date: 응답 날짜.
Set-Cookie: 클라이언트에 쿠키 저장 요청.
Content-Type: 응답 콘텐츠의 유형 (예: HTML, JSON)
Location: 요청을 리다이렉션.
Last-Modified: 마지막 변경 시간.
Content-Length: 콘텐츠의 길이.
WWW #10: Persistent vs. Nonpersistent HTTP Connections (영속적 vs 비영속적 HTTP 연결)
💡요약: 이런 HTTP동작에서도 두가지 분류가 존재한다. 비영속적 연결(Nonpersistent Connection) 과 영속적 연결(Persistent Connection)로 나뉜다. 기술에 발전에 따라서 HTTP 1.0에선 비영속적을 사용하였고 1.0이후 버전으로는 영속적 연결을 사용하고 있다. 이 두 연결 방식은 클라이언트와 서버 간의 데이터 요청 및 응답 처리 방법에 차이가 있다.
✅ Nonpersistent Connection (비영속적 연결)
- Definition (정의): 클라이언트와 서버가 각 요청-응답 트랜잭션마다 별도의 TCP 연결을 생성하고, 작업이 끝나면 연결을 끊는다.
요청: file1 → 연결 종료 → 요청: image1 → 연결 종료 → 요청: image2 → 연결 종료.
Process (과정):
클라이언트가 서버에 요청을 보낸다. (Connection establishment + Request)
서버가 응답을 완료(Response)하면 TCP 연결을 종료(Connection Termination)한다.
새로운 요청이 있을 경우, 다시 연결을 설정해야 한다.
Key Features (특징):
단점: TCP 연결을 반복적으로 설정하고 종료하므로 성능 부담이 크다.
사용 사례: HTTP 1.0에서 주로 사용되었다.
✅ Persistent Connection (영속적 연결)
- Definition (정의): 클라이언트와 서버가 하나의 TCP 연결로 여러 요청과 응답을 처리한 후, 작업이 끝난 후에만 연결을 종료하게 된다.
요청: file1, image1, image2 → 응답: 모두 처리 후 한 번의 연결 종료.
Process (과정):
클라이언트가 서버에 요청을 보낸다. (Connection Establishment + Request)
서버는 여러 요청에 대해 하나의 연결로 응답한다. (Response)
모든 작업이 끝난 후에 한 번만 TCP 연결을 종료한다. (Connection Termination)
Key Features (특징):
장점: TCP 연결 설정/종료의 오버헤드가 줄어들어 성능이 향상된다.
사용 사례: HTTP 1.1 및 이후 버전에서 기본 방식으로 사용되고 있다.
✅ Key Differences (주요 차이점)
