TIL 17 : 인터넷 용어 기초

코딩/sparta TIL

TIL 17 : 인터넷 용어 기초

americanoallday 2025. 3. 17. 12:59

처음에는 물리적으로 연결되어 있어야 데이터를 주고 받을 수 있었다.

네트워크(Network)란?

컴퓨터, 서버, 장치(스마트폰, IoT 등)들이 서로 연결되어 데이터를 주고받을 수 있는 구조

특징

• 소규모 또는 대규모로 구성될 수 있음

• 특정 범위 내에서 작동 (예: 집, 회사, 캠퍼스 등)

• 인터넷 없이도 작동 가능 (예: 사내 네트워크)

예:

• LAN(Local Area Network): 한정된 지역(예: 회사 사무실)에서 구성된 네트워크

• WAN(Wide Area Network): 더 넓은 범위를 포함한 네트워크

인터넷(Internet)이란?

인터(Inter) + 네트워크(Network): 네트워크 간의 연결

인터넷은 컴퓨터 네트워크의 거대한 연결망으로 처음에는 컴퓨터끼리 물리적으로(케이블로) 연결되어 있어야 데이터를 주고받을 수 있었지만, 지금은 해저 광케이블이나 인공위성을 이용해 전 세계 어디서나 무선으로 연결할 수 있음. -> WWW가 구축됨

특징

• 네트워크들의 집합 (네트워크 간의 연결)

• TCP/IP 프로토콜을 사용해 데이터를 교환

• 모든 장치가 인터넷에 연결되면 서로 통신 가능

예:

• 웹 브라우징 (www.google.com 접속)

• 이메일 (Gmail, Yahoo)

• 스트리밍 서비스 (Netflix, YouTube)

🦋 쉽게 이해하기
• 네트워크: 집안의 컴퓨터와 프린터를 연결하는 작은 연결망
• 인터넷: 수많은 집, 회사, 나라의 네트워크를 연결한 전 세계의 네트워크

🦄 비유
• 네트워크: 도시 내부의 도로망
• 인터넷: 도시를 연결하는 고속도로와 전 세계 도로망

1. 내부 IP(Private IP)와 외부 IP(Public IP)

내부 IP(Private IP):

• 로컬 네트워크 내에서 장치들 간의 통신에 사용되는 IP 주소.

• 외부 인터넷에서 직접 접근할 수 없음.

• 예: 192.168.x.x, 10.x.x.x

외부 IP(Public IP):

• ISP(인터넷 서비스 제공자)가 네트워크에 할당한 고유한 IP 주소.

• 인터넷에서 접근 가능한 주소로, 웹사이트나 서버를 식별.

• 예: 203.0.113.x

2. 유동 IP(Dynamic IP)와 고정 IP(Static IP)

유동 IP:

• IP 주소가 DHCP 서버에 의해 동적으로 할당.

• 주기적으로 IP가 변경되며, 일반 가정용 네트워크에서 흔히 사용.

고정 IP:

• IP 주소가 항상 고정되어 변경되지 않음.

• 서버, CCTV, 호스팅 서비스 등 안정적인 접속이 필요한 환경에 사용.

3. DNS(Domain Name System)와 hosts 파일

DNS:

• 도메인 이름(예: www.google.com)을 IP 주소로 변환해주는 시스템.

• 인터넷의 전화번호부 역할.

• DNS 서버를 통해 동작하며, 사용자가 직접 설정 가능.

hosts 파일:

• 운영 체제에서 IP 주소와 도메인 이름의 매핑을 저장한 파일.

• DNS 서버보다 우선순위가 높음.

• 주로 로컬 개발 환경에서 사용.

• 위치 예: /etc/hosts (Linux, macOS), C:\Windows\System32\drivers\etc\hosts (Windows)

4. 레지스트리(Registry)와 레지스트라(Registrar)

레지스트리(Registry):

• 도메인 이름을 관리하는 데이터베이스.

• 도메인 등록 정보를 중앙에서 관리.

• 예: .com, .net 도메인을 관리하는 Verisign

레지스트라(Registrar):

• 사용자가 도메인 이름을 등록할 수 있도록 중개하는 회사 또는 기관.

• 예: GoDaddy, Namecheap, Google Domains

5. Well-known Port, Registered Port, Dynamic Port

Well-known Port (0-1023):

• 주로 표준 서비스와 프로토콜에 할당된 포트.

• 예: HTTP(80), HTTPS(443), FTP(21), SMTP(25)

Registered Port (1024-49151):

• 특정 애플리케이션에 등록된 포트.

• 예: MySQL(3306), Microsoft SQL Server(1433)

Dynamic Port (49152-65535):

• 클라이언트와 서버 간의 임시 연결에 사용.

• 주로 클라이언트에서 랜덤하게 할당.

6. 포트 포워딩(Port Forwarding)

정의:

• 외부 네트워크에서 내부 네트워크 장치에 접근할 수 있도록 포트를 열어주는 설정.

• 주로 NAT(Network Address Translation)를 사용하는 환경에서 사용.

용도:

• 원격 데스크톱 연결

• 게임 서버 호스팅

• CCTV 또는 IoT 장치 원격 제어

7. OSI 7계층과 TCP/IP 4계층

OSI 7계층 (Open Systems Interconnection Model)

• 네트워크 통신을 7단계로 나눈 참조 모델.

1. Physical Layer (물리 계층): 하드웨어 간의 물리적 전송 (케이블, 전기 신호).

2. Data Link Layer (데이터 링크 계층): MAC 주소를 사용하여 데이터 전송.

3. Network Layer (네트워크 계층): IP 주소를 기반으로 경로 설정 (라우팅).

4. Transport Layer (전송 계층): 데이터의 신뢰성 제공 (TCP, UDP).

5. Session Layer (세션 계층): 세션(연결) 관리.

6. Presentation Layer (표현 계층): 데이터 암호화, 압축, 변환.

7. Application Layer (응용 계층): 최종 사용자와의 상호작용 (HTTP, FTP 등).

TCP/IP 4계층

• 실제 인터넷 프로토콜이 동작하는 4계층 모델.

1. Network Access Layer: OSI의 1, 2계층에 해당 (물리 + 데이터 링크).

2. Internet Layer: OSI의 네트워크 계층과 유사 (IP 라우팅).

3. Transport Layer: OSI 전송 계층과 유사 (TCP, UDP).

4. Application Layer: OSI의 5, 6, 7 계층을 포함 (HTTP, FTP).

인터넷 프로토콜 IP

데이터 통신에 대한 규약(Internet Protocol)

데이터가 잘 전달하기 위해서는 최소한의 규칙이 필요함. 그 규칙이 IP.

데이터를 통신할 때는 데이터를 Packet으로 나눠서 전송 함.

패킷의 구성

헤더(Header) : 소스 IP(보내는 사람), 대상 IP(받는 사람)

페이로드(Payload) : 실제 데이터, 소스 PORT, 대상 PORT

트레일러(Trailer) : 수신여부

IP 방식의 문제점

1. 애플리케이션 구분이 안됨 : 패킷을 전송했으나 받는 쪽에서 어떤 프로그램에서 사용해야하는지 알 수 없음(포트 개념이 필요)

2. 비연결성 : 대상 컴퓨터가 꺼져있어도 무조건적으로 전송 함

3. 비신뢰성 : 패킷이 복잡한 네트워크 환경에서 소실되는 경우가 발생, 데이터가 크면 나뉘어서 전송이 되는데 패킷 순서가 바뀔 수 있음. 패킷이 손실되거나 오류가 발생해도 재전송을 진행하지 않음

위와 같은 문제점을 해결해 주는것이 TCP 프로토콜(Transmission Control Protocol) - 프로토콜(네트워크에서 데이터를 안전하게 전달하기 위한 하나의 규칙)

TCP 프로토콜(Transmission Control Protocol)

3 Way HandShake : 물리적으로 연결하는 것이 아니라 논리적인 컴퓨터끼리 연결하는 과정

1. SYN → A가 B에게 “연결할래?” 요청

2. SYN, ACK → B가 A에게 “좋아, 나도 연결할게!” 응답

3. ACK → A가 B에게 “확인했어!” 응답 → 연결 완료!

SYN (Synchronize)
- 클라이언트가 서버에게 연결을 요청하는 첫 번째 단계이다.
- 클라이언트는 서버에게 "연결을 시작하고 싶다"는 의사를 나타내기 위해 SYN 플래그가 설정된 패킷을 전송한다.
- 패킷에는 시퀀스 번호도 포함되어 있고 데이터 전송 순서를 관리할 준비를 한다.
ACK (Acknowledge)
- 서버가 클라이언트의 SYN 패킷을 받고, 이를 확인했다는 신호를 보내는 단계이다.
- 서버는 클라이언트의 SYN 요청을 수락하며, 자신도 연결을 시작하고 싶다는 뜻을 담아 SYN 플래그와 함께 ACK 플래그가 설정된 패킷을 클라이언트에게 전송한다.
- 이때, 서버는 클라이언트의 시퀀스 번호에 1을 더한 값을 ACK로 응답한다.

연결여부 확인 후, 패킷 순서가 다를 경우 재요청하거나 대기를 함.

→ TCP를 통해 통신하면 데이터를 잘 받았다는 응답을 반환해준다.

→ 패킷이 나뉘어져 올지라도 순서를 보장한다.

🐮 TCP는 신뢰성이 있지만 연결하는 과정, 데이터 전송에 시간이 많이 소요된다. TCP는 현재 단계 이상의 최적화를 하기 힘들다. (최소한의 논리적인 연결이 필요하기 때문) → 3 way handshake 과정을 거치는 만큼 속도가 느리다.

UDP(User Datagram Protocol)

비연결형, 신뢰성이 없는 전송 프로토콜, 빠른 전송이 중요

(온라인 게임, 화상통화, 스트리밍에 UDP 통신을 사용함)

UDP 특징

1. IP 방식과 거의 비슷(3 way handshake를 하지 않음)

2. 속도가 빠르다

3. IP와 차이점으로 PORT가 존재(TCP에도 존재)

4. 체크섬(Checksum)이 존재 : 잘못된 데이터가 왔는지 검증

PORT란

어떤 프로그램(애플리케이션)에서 사용하는지 구분하는 용도 (아파트의 호수 같은 개념)

자주 사용되는 PORT

1. 0 ~ 65535 할당 가능

2. 이미 사용되고 있는 포트 (0~1023)

- 국제 도메인 관리기구에 의해 관리된다. 사용하지 않는것이 좋다.

- FTP : 20, 21(TCP)

- SSH : 22(TCP)

- 텔넷 : 23(TCP)

- SMTP : 25(TCP)

- DNS : 53(TCP/UDP)

- DHCP : 67(UDP)

- HTTP : 80(TCP)

- HTTPS : 443(TCP)

- RDP : 3389(TCP/UDP)

- 실제 개발을 진행할 때 사용되지 않는 나머지 포트를 사용하여 개발하면 됨.

DNS(Domain Name System)

도메인 이름과 IP 주소를 서로 변환하는 역할을 수행한다.

🐭 DNS 동작 순서
1. 도메인 판매회사로부터 원하는 도메인을 구매 후 DNS 서버에 IP와 이름을 저장
2. 이후에 도메인 이름을 요청 시, DNS서버에서 해당 도메인에 해당하는 IP 주소를 반환 함

URI(Uniform Resource Identifier)

인터넷 자원을 나타내는 고유 식별자

자원인 데이터를 식별하는 통일된 방식

URL(Locator), URN(Name) 을 포함함

URL(Uniform Resource Locator)

인터넷에서 특정 자원의 위치를 나타내는 주소로 웹사이트 주소로 생각하면 됨.

위치를 의미, 도메인 주소로 알려져 있음, 프로토콜을 포함한다.(https)

> 한계 : 자원의 위치를 변경하면 기존 URL은 사용할 수 없다.

(예 : 기존 https://apple.com/ 에서 https://apple2.com/ 으로 변경 시 기존 경로를 아는 사람들은 변경된 페이지를 찾을 수 없음.)

이러한 한계를 극복하기 위해 URN이 등장함(변하지 않는 고유 식별자)

리소스 위치가 변경되어도 리소스를 찾음. 프로토콜을 포함하지 않음, 대중화되어 있지 않음

예)

URL : https://www.naver.com

URN : isbn:978-3-16-148410-0 (책 ISBN처럼 고유한 이름)

🐴 현재 대부분 URL을 사용하여, URI를 URL과 같은 의미로 사용하기도 함.

URL(Uniform Resource Locator) 구조

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

* 대괄호 : 생략이 가능

scheme (프로토콜)

어떤 통신 방식을 사용할지 나타냄.
웹에서는 https://, http://, ftp:// 주로 사용
기타 예시
- ftp:// → 파일 전송
- mailto: → 이메일 전송
- tel: → 전화 걸기

user[:password]

URL은 보안이 취약해서 사용하지 않음🚨
ftp://username:password@ftp.example.com
- username:password@ → 사용자 인증 정보
- ftp.example.com → 접속할 서버

❌ user[:password] 방식이 위험한 이유

1. 비밀번호가 노출됨

• URL은 로그에 남거나 공유될 수 있어서, 인증 정보가 쉽게 유출될 가능성이 있음.

• 예: https://admin:1234@mywebsite.com → 너무 위험함 ❌

2. 브라우저가 자동 차단

• 보안 취약점 때문에, 크롬, 파이어폭스 같은 최신 브라우저는 이 방식의 URL을 차단함.

3. 보안 정책 위반

• 대부분의 보안 규정(예: PCI DSS, GDPR)에서는 비밀번호를 URL에 포함하는 것을 금지하고 있음.

✅ 대체 방법 (보안 강화)

보안이 중요한 서비스는 다른 인증 방법을 사용해야 함.

1. Basic Auth + 브라우저 팝업

• HTTP Basic Authentication을 사용하면, 브라우저에서 사용자명/비밀번호 입력을 요청함.

• 예: https://example.com → 접속하면 로그인 창이 뜸.

2. OAuth 또는 API Key 사용

• API 접근 시, OAuth 토큰 또는 API 키를 사용하여 보안 강화.

• 예: https://api.example.com/data?apikey=123456

3. 세션 기반 로그인

• 웹사이트 로그인 후 세션 또는 토큰을 유지하여 추가 요청에서는 비밀번호를 포함하지 않음.

host (호스트, 도메인/IP)

https://www.google.com -> www.google.com이 host 부분
보통 도메인 이름을 사용하지만, 직접 IP 주소(142.250.74.206) 를 입력할 수도 있음.

port (포트 번호)

http://example.com:8080 (8080 포트로 접속)
포트는 일반적으로 생략

📌 일반적인 포트 번호

• 80 → HTTP 기본 포트

• 443 → HTTPS 기본 포트

• 21 → FTP (파일 전송)

• 3306 → MySQL 데이터베이스

path (경로)

https://www.google.com/search ->/search 부분이 path(경로)
웹 서버에서 특정 리소스(페이지, 파일)에 접근할 때 사용
리소스의 경로, 계층 구조로 구성되어있다.

query (쿼리 문자열)

https://www.google.com/search?q=스파르타+코딩클럽 -> ? 뒤에 나오는 부분이 query string(쿼리 문자열)
key=value 형태로 구성, ?로 시작되고 &으로 구분된다.
Query parameter, Query String 이라고 한다.

fragment (프래그먼트, 앵커)

https://example.com/docs#section1 -> #section1 부분이 fragment(프래그먼트)
특정 페이지 안에서 특정 위치로 이동하는 용도.
웹사이트에서 자동으로 해당 위치로 스크롤해 줌.
웹 브라우저에서만 동작하며, 서버에는 전달되지 않음

🪿 브라우저에 URL을 입력하면 어떤일이?!?

1. https://www.google.com:443/search?q=스파르타+코딩클럽&hl=ko URL을 입력한다.

2. DNS 서버를 조회하여 www.google.com 에 해당하는 IP 주소를 응답받는다.

포트 번호는 생략되어있다.
https에서 사용되는 PORT는 443이다.

3. 웹 브라우저에서 HTTP 요청 메세지를 생성한다.

스파르타 코딩클럽 검색해줘! 하는것과 같다.

4. 요청 패킷(HTTP 메세지가 포함되어 있다)을 구글 서버로 전송한다.

5. 구글 서버에서 HTTP 요청 메세지를 기반으로 응답 HTTP 메세지를 만들어 응답한다.

어디보자.. 스파르타 코딩클럽 검색해달라고? 그래 검색 결과는 이거야!

6. 응답패킷 도착 → HTML 이 응답으로 온다.

응답 결과가 브라우저에 그려진다.

프로그래밍 명명규칙(Casing)

https://americanoallday.tistory.com/25

TIL 3 : 깃 컨벤션 & JS Async

Timeline09:00 ~ 10:00 : 회의 (최종 웹 개발 검토)10:00 ~ 13:00 : 개인 학습13:00 ~ 14:00 : 점심 시간14:00 ~ 18:00 : 개인 학습18:00 ~ 19:00 : 저녁 시간 19:00 ~ 21:00 : 개인 학습 및 TIL 작성 Git 컨벤션(Git Commit Convention

americanoallday.tistory.com

JSON이란(JavaScript Object Ntation)

클라이언트와 서버가 통신할 때 사용하는 데이터 형식

용량이 작음

클라이언트 to 서버, 서버 to 서버

(XML : 가독성이 떨어지고, 불필요한 용량을 잡아먹는 단점이 있음)

JSON 형식 예제:

{
  "user": [
    {
      "first_name": "wonuk",
      "last_name": "Hwang",
      "age": 100,
      "phone_agree": false,
      "hobby": ["Java", "Spring"]
    },
    {
      "firstName": "sparta",
      "lastName": "Team",
      "age": 200,
      "phone_agree": true,
      "hobby": ["React", "Spring", "Node"]
    },
  ]
}

snake_case, camelCase 모두 사용이 가능하다.
- 우리가 만드는 Application 내에서 변환해주는 무엇인가가 있다.
key-value 형태로 구성되어 있다.
null, number, string, array, object, boolean 형태의 데이터를 사용할 수 있다.

MSA(MicroService Architecture)

아주 작은 단위로 서비스를 잘게 나누어 운영하는 아키텍처

(예전에는 하나의 서버에서 모든 기능을 처리했지만, 요즘은 작은 서비스 단위로 쪼개서 운영(MSA))

당 아키텍처를 가지게 되면 구성된 Application마다 어떠한 언어를 사용하는지에 상관없이 서로 통신을 할 수 있는데 이것이 가능한 이유는 JSON 형태로 데이터 통신을 하기 때문이다.

Scale Up, Scale Out

서버 성능을 확장하는 방식

Scale Up (수직적 확장)

단일 서버의 하드웨어의 사용을 높인다. (CPU, Memory 등의 스펙을 높인다)
요청에 대한 처리를 더욱 빠르게 할 수 있도록 만든다.
비용이 기하급수적으로 증가

Scale Out (수평적 확장)

같은 사양의 서버(인스턴스)를 여러 대 배치한다.
동시에 더 많은 사용자 요청을 처리할 수 있도록 만든다.
보통 Scale Out이 더 유연하고 효율적이라 많이 사용

Stateful, Stateless

클라이언트와 서버간의 통신 상태(state) 유지 여부에 따라 나뉘는 특성이다.

Stateful(상태 유지)

상담원(서버)은 수강생(클라이언트)의 요청들을 기억(상태 유지)하여 다음 질문들에 대한 처리가 가능하다.

Stateful 문제점

같은 서버가 유지되어야 한다. (ex : 같은 상담원에게 요청을 해야 기억을 토대로 처리가 가능함)

서버는 다양한 이유로 동작하지 않을 수 있다.(시스템 에러, 비지니스 로직 문제, 리소스 부족 문제 등)

요청 트래픽이 몰리게되면 상태를 유지하는것에 Resource가 많이 소모된다.

> 리소스가 버티지 못하면 서버가 종료되거나, 다음 요청에 대한 처리가 느려진다.

Stateless(무상태)

클라이언트의 상태를 유지하지 않는다.

Stateless 방식의 실제 요청방식

Stateless 방식의 장단점

장점

같은 서버를 유지할 필요가 없다.
Scale Out 수평 확장성이 높다.
- 갑자기 요청량이 증가하여도 서버를 증설하기 쉽다.

단점

클라이언트가 데이터를 추가적으로 전송해야 한다.
- 전송되는 데이터 양이 많아진다.

Stateless 한계점

WebApplication을 만들때 서버의 확장성을 고려하여 최대한 Stateless하게 만들어야 한다. 🐝
하지만, 실제로는 로그인과 같은 상태를 유지해야하는 경우가 발생한다.
추후에 배울 Cookie, Session, Token등을 활용하여 이러한 한계를 극복한다.
- 상태 유지를 최소화 시켜야 한다.

Connection, Connectionless

클라이언트와 서버 간의 연결 유지 여부에 따라 나뉘는 특성

Connection(연결)

서버는 클라이언트와 연결을 항상 유지하기 위해서 자원을 소모한다.
하지만, 수많은 사람들이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 작다.
- 클라이언트 2,3이 아무런 요청이 없어도 연결을 유지한다.

Connection 장단점

장점

새로운 연결 과정을 거치지 않아도 된다.
그만큼 요청에 대한 응답 속도가 빨라진다.

단점

클라이언트가 지속적으로 요청을 보낼거라는 보장이 없다.
즉, 연결을 위한 자원이 낭비된다.

Connectionless(비연결)

클라이언트와 서버는 연결을 유지하지 않는다. (요청이 있을 때만 연결)
서버는 최소한의 자원만을 사용한다.
(ex) 브라우저가 켜진 상태에서 인터넷이 종료(끊어져도)되어도 홈페이지가 정상적으로 노출된다.)

Connectionless 장단점

장점

서버 자원을 효율적으로 사용할 수 있다.

단점

요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야한다.
- 요청에 대한 응답 시간이 증가한다.
웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다.
- 캐시, 브라우저 캐싱로 해결한다. 쉽게 말해 임시저장(추후 다룰 예정)
현재는 HTTP 지속연결(Persistent Connection)로 문제를 해결한다.

HTTP 지속연결(Persistent Connections)

HTTP는 원래 요청-응답 후 연결을 끊음(Connectionless).
하지만 요즘은 한 번 연결하면 여러 요청을 처리하는 방식(Persistent Connection) 사용.
연결을 한번만 맺고 끊기 때문에, Connectionless 방식보다 연결 횟수가 적다.
- 그만큼 속도가 빨라졌다.

ex) HTML 요청 + CSS 요청 + JS 요청 + 이미지 요청