MyLittleWiki

어렴풋이 과거엔 프루나, 당나귀부터 최근엔 토렌트로 많이 알려진 파일공유 프로그램들이 있습니다.

이들은 P2P 네트워크 기반으로 동작하는 파일공유방식인데 어떤 원리로 동작하는지 간단하게 알아봅니다.

1. P2P 네트워크?

2. 토렌트

3. P2P네트워크와 HTTP/FTP의 차이점

4. 트래커? DHT?

5. DHT

1. P2P 네트워크

P2P(Peer-To-Peer) 네트워크는 중앙 서버 없이 사용자(피어, Peer)간에 직접 데이터를 공유하는 네트워크 구조를 의미합니다.

일반적인 클라이언트-서버 방식과 달리, 각 사용자가 동시에 클라이언트이자 서버 역할을 수행하는 것이 특징입니다.

P2P 네트워크의 기본 원리

1. 모든 참여자는 동등한 권한을 가짐

일반적인 인터넷 서비스(예: 웹사이트)는 중앙 서버(호스트)에서 데이터를 제공하고, 사용자는 클라이언트로 다운로드하는 방식입니다. 반면, P2P 네트워크에서는 모든 참가자가 데이터를 제공하고 받을 수 있습니다.

2. 분산구조

특정 서버가 다운되더라도 네트워크 전체가 영향을 받지 않습니다.

트래픽 부하가 특정 서버에 집중되지 않고 여러 사용자가 분산해서 감당합니다.

3. 파일 조각화 및 공유

하나의 큰 파일을 작은 조각(Piece) 단위로 나누어 여러 피어(Peer)들에게 공유합니다.

각 피어는 자신이 가진 조각을 다른 피어들에게 제공하고, 부족한 조각을 다운로드합니다.

이런 방식 덕분에 다운로드 속도가 빨라지고, 서버 비용이 절감됩니다.

P2P 네트워크의 종류

P2P 네트워크는 중앙 서버 의존도에 따라 크게 3가지 유형으로 나뉩니다.

1. 중앙 집중형 P2P (Centralized P2P)

중앙 서버가 피어들을 관리하고, 파일 목록을 제공합니다(과거의 프루나가 이 종류에 해당합니다).

검색 속도가 빠르고 관리가 쉽다는 장점이 있으나, 서버가 중단되면 네트워크 전체가 마비되는 단점이 있습니다.

2. 분산 하이브리드형 P2P (Hybrid P2P)

중앙 서버는 검색 기능만 담당하고, 파일 공유는 피어들끼리 직접 수행합니다.(eDonkey가 이 종류에 해당합니다).

중앙 서버 부담이 적어지고 네트워크가 안정적인 장점이 있으나, 서버가 없어지면 검색이 어렵다는 단점이 있습니다.

3. 완전 분산형 P2P (Pure P2P)

중앙 서버 없이 DHT(분산 해시 테이블) 기술을 사용해 피어들끼리 직접 검색하고 공유가 가능합니다.(현재의 토렌트가 이 종류에 해당합니다).

서버가 필요 없어 네트워크를 차단하기 어려우나, 초기 피어 연결이 어려울 수 있다는 단점이 있습니다.

사용자들간의 네트워크가 구축되어 서로 공유하는것, 어디서 많이 들어본 방식입니다.
추가로 탈 중앙화 P2P(Decentralized P2P)방식이 존재하는데, 이것이 바로 블록체인&암호화폐의 방식입니다.
중앙 기관 없이 사용자 간 거래가 가능하며, 거래 내역은 분산 원장(블록체인)에 기록됩니다.
(블록체인에 대해 간단하게 알아보기 →)

2. 토렌트(Torrent)

: 토렌트(Torrent)서비스는 일반적인 HTTP/FTP 다운로드와는 다르게, 여러 사용자(피어)들이 파일의 조각을 서로 공유하며 빠르고 효율적으로 전송할 수 있도록 설계되어있는 서비스입니다.

토렌트 네트워크의 주요 개념

트래커(Tracker)

토렌트 클라이언트가 피어들의 목록을 얻는 중앙 서버 역할을 합니다.

트래커 없이 작동하는 방식(마그넷 링크 기반)도 있으며, 이를 DHT(Distributed Hash Table)기반의 분산 네트워크라고 합니다.

피어(Peer)

파일을 다운로드하거나 업로드하는 모든 사용자를 의미합니다. 같은 파일을 요청한 사용자들끼리 데이터를 공유합니다.

시드(Seed)

파일을 100% 다 가지고 있으며, 다른 피어들에게 파일을 업로드하는 사용자를 의미합니다. 시드가 많을수록 다운로드 속도가 빨라집니다.

리치(Peer, Leech)

파일을 다운로드하면서 일부만 업로드하는 사용자. 업로드 없이 다운로드만 할 경우 네트워크에 기여하지 않는다고 해서 리처(Leech, 거머리)라고 불립니다.

DHT(Distributed Hash Table)

중앙 트래커 없이 피어 간 직접 연결을 통해 정보를 공유하는 기술을 의미합니다. 마그넷 링크 방식에서 많이 사용됩니다.

동작 원리

1. 토렌트 파일(.torrent) 또는 마그넷 링크(.magnet) 획득

토렌트를 사용하려면 먼저 토렌트 파일을 다운로드하거나 마그넷 링크를 얻어야 합니다.

.torrent 파일은 특정 파일의 조각 정보와 트래커(Tracker) 서버의 주소 등을 포함합니다.

마그넷 링크는 트래커 없이도 P2P 네트워크에서 파일을 찾을 수 있도록 해줍니다.

2. 토렌트 클라이언트(예: uTorrent 등)가 메타데이터 분석

.torrent 파일 또는 마그넷 링크를 이용해 토렌트 클라이언트가 해당 파일을 구성하는 조각(piece)정보를 분석합니다.

트래커 서버에 접속해 같은 파일을 공유하는 피어(Peer) 정보를 얻습니다.

3. P2P 네트워크에서 파일 조각 다운로드

파일이 여러 조각으로 나뉘어있어, 각각의 조각을 다른 피어들에게서 병렬적으로 다운로드합니다.

다운로드 속도는 시드(Seed, 완전한 파일을 가진 사용자)와 피어(Peer, 일부 조각을 가진 사용자)의 수에 따라 달라집니다.

4. 파일 조각을 완성하고 시딩(Seeding) 시작

모든 조각을 받으면 파일이 완성되고, 이제 다른 사용자에게 해당 조각을 제공(업로드)하는 시더(Seeder)가 됩니다.

3. P2P네트워크와 HTTP/FTP의 차이점

4. 트래커(Tracker)? DHT?

P2P 네트워크에서 파일을 공유할 때, '다른 사용자가 이 파일을 가지고 있는지 어떻게 찾을까?' 라는 의문점이 생깁니다.

이 문제를 해결하는 방식이 트래커(Tracker)와 DHT(Distributed Hash Table)입니다.

트래커(Tracker)란 ?

P2P 네트워크에서 파일을 공유하는 사용자의 목록을 관리하는 서버입니다.

사용자가 특정 파일을 다운로드하려고 하면, 트래커가 해당 파일을 가지고 있는 사용자(시드, 피어) 목록을 알려줍니다.

완전 분산형 P2P에서는 '서버'라는 말이 등장하지 않습니다. 이 방식은 주로 중앙 집중형 방식에서 사용되며, BitTorrent의 초창기 방식입니다.

트래커의 동작 방식

사용자가 .torrent 파일을 열면, 클라이언트는 트래커 서버에 접속해, 해당 파일을 공유하는 피어(사용자)목록을 사용자에게 제공하고, 클라이언트는 이 피어 목록을 바탕으로 여러 사용자에게 파일 조각을 요청합니다.

다운로드가 진행되면서, 클라이언트는 자신의 정보를 트래커에 다시 업데이트해 새로운 사용자가 접근할 수 있도록 합니다.

DHT(Distributed Hash Table)이란 ?

중앙 서버 없이 피어들끼리 직접 정보를 공유하는 방식입니다.

사용자가 파일을 다운로드하려고 하면, DHT 네트워크에 "이 파일을 갖고 있는 사람을 찾습니다." 요청을 보내고, 네트워크에 연결된 다른 피어들이 분산된 해시 테이블(DHT)에서 해당 파일을 가진 사용자를 찾아 응답합니다.

그렇게 찾은 피어들과 직접 연결해 파일을 다운로드 합니다.

역시 다운로드를 완료하면 DHT 네트워크에 등록되어 다른 사용자들이 접근할 수 있도록 합니다.

서버의 유/무와 네트워크의 개념이 잘 와닿지 않습니다.

두 방식을 비유해보자면, 트래커 방식은 빌릴 수 있는 사람 목록을 관리하는 중앙 도서관에서 책을 찾는다고 이해할 수 있습니다.

DHT 방식은 도서관이 존재하지 않고, 친구 A에게 책 위치를 물어 (예: B랑 C가 반반씩 갖고있던데), B와 C로부터 책을 찾는다.

고 이해할 수 있을 것 같습니다.

5. DHT(Distributed Hash Table) 

더 자세한 내용으로 들어가면

DHT는 해시기반 키-값 저장소로의 개념으로 이해할 수 있습니다.

"파일 해시 → 피어 목록"을 매핑해 저장하고 검색하는 시스템입니다.

토렌트에 적용된 예시로 방식을 설명해보겠습니다.

1. 각 파일(토렌트)은 고유한 해시 값(InfoHash)를 가집니다.

2. DHT 네트워크에 참여한(uTorrent 클라이언트를 가지는) 사용자(모든 피어)는 특정 해시 값 범위의 정보를 저장합니다.

3. 해시 값 기반의 검색을 수행하게되면, 해당 파일을 가지고 있는 피어를 찾게됩니다.

핵심 원리는 Kademila 알고리즘 방식을 따른다고 되어있습니다.

이 알고리즘이 갖는 특징(동작 방식)은

1. 각 피어(사용자)는 고유한 노드 ID(Node ID)를 갖는다.

2. 파일(토렌트)도 해시 값을 갖는다.

3. 노드 ID와 해시 값이 가까운 피어가 해당 파일의 정보를 저장한다.

DHT 검색과정을 예로들겠습니다.

1. 노드 DI 생성: DHT 네트워크에 참여하는 모든 피어들은 고유한 160비트 노드 ID를 갖는다고 설명했습니다.

예: 내 노드 ID: 0xA3B4C5D....

2. 파일 해시(InfoHash) 생성: 파일을 공유할 때, 해당 파일은 SHA-1 해시 알고리즘을 통해 InfoHash를 생성합니다.

예: text.txt 파일의 InfoHas: 0xF1A23B4...

3. DHT에 피어 정보를 저장: text.txt파일을 공유하는 사용자끼리는 DHT 네트워크 참여자로서 '해시 값이 자기 노드 ID에 가까운 다른 참여자를 저장' 합니다.

그래서, 다른 사용자가 text.txt파일을 공유받고자 하게되면, 네트워크에서 역으로 0xF1A23B4 파일 InfoHash와 가장 가까운 노드들을 역으로 찾아가면서 공유받게 되는것입니다.

여기저기 CDN... 웹 서버에도 CDN 이야기가 AWS, CloudFlare에도 CDN 이야기가

CDN이 무엇인지 알아보도록 합니다.

1. CDN ?

2. CDN의 동작 원리

3. 캐싱 ?

4. 정리

1. CDN?

: CDN(Content Delivery Network)은 전 세계 여러 지역에 분산된 서버 네트워크를 통해 웹사이트의 정적 콘텐츠(이미지, 동영상, CSS, JavaScript 등)와 동적 콘텐츠를 빠르고 안정적으로 제공하는 기술입니다.

예를 하나 들어보겠습니다.

내가 개인적으로 운영하는 서버는 경기도 어딘가에 위치합니다.

나의 웹사이트를 접속하는 유저는 내 서버로부터 정적 콘텐츠 파일을 받아 웹사이트를 로딩합니다.

그런데 웹사이트가 잘돼서 유럽이나 미국에서 접속하는 유저가 생기기 시작하면, 그 멀리 있는 이용자에게 정적 콘텐츠 파일을 전달하기가 아무래도 느려질수 밖에 없습니다.

하지만 CDN을 사용하면, 사용자의 위치와 가까운 CDN 서버(엣지 서버, Edge server)에서 데이터를 제공해 속도를 개선하고, 서버 부하도 줄이면서, 보안성을 높이는 효과를 얻을 수 있습니다.

CDN을 제공하는 주요 서비스들은 아래의 기업들이 있습니다.

- Cloudflare: 보안 및 DDoS 방어 기능이 뛰어난 CDN

- AWS CloudFront: AWS 기반 서비스와 연동이 쉬운 CDN

- Akamai: 전 세계적으로 가장 널리 사용되는 기업용 CDN

- Google Cloud CDN: Google Cloud와 연계된 강력한 CDN

- Fastly: 초고속 콘텐츠 제공에 최적화된 CDN

2. CDN의 동작 원리

: CDN은 다음과 같은 방식으로 콘텐츠를 제공합니다.

1. 사용자가 웹사이트 접속
   • 예를 들어, 뉴욕에 있는 사용자가 서울에 있는 서버에서 제공하는 웹사이트를 방문한다고 가정합니다.
2. CDN이 가장 가까운 서버에서 콘텐츠 제공
   • CDN은 뉴욕 근처의 엣지 서버에 해당 콘텐츠를 캐싱(Cache)해두고 있다면, 원본 서버까지 가지 않고 엣지 서버에서 데이터를 제공합니다.
3. 캐싱이 없을 경우 원본 서버에서 가져옴
   • 만약 엣지 서버에 해당 콘텐츠가 없다면, 원본 서버에서 데이터를 가져와 사용자에게 전달하고, 동시에 캐싱해둡니다.
4. 이후 요청은 캐싱된 콘텐츠 제공
   • 같은 콘텐츠를 요청하는 다른 사용자에게는 원본 서버 대신 캐싱된 콘텐츠를 제공하여 속도를 높이고 트래픽을 절감합니다.

이 동작 원리를 따라가다 보면, 궁금증이 더 생깁니다.

"콘텐츠의 캐싱은 어떻게 이루어지는가?", "원본 데이터가 업데이트되었다면 캐싱된 콘텐츠는 바뀌나? 어떻게 바뀌나?"

3. 캐싱 ?

: CDN은 정적 콘텐츠를 원본 서버에서 가져와 엣지 서버(Edge Server)에 저장(캐싱, Caching)한 후 일정 기간 동안 보관하는 방식으로 동작합니다. 이 캐싱 방법은 크게 푸시 캐싱(Push Caching)과 풀 캐싱(Pull Caching)으로 나뉩니다.

1) 푸시 캐싱 (Push Caching)

: 웹사이트 운영자가 CDN 서버에 콘텐츠를 직접 업로드 하는 방식입니다. 원본 서버에서 미리 콘텐츠를 CDN에 보내기 때문에 즉각적인 캐싱이 가능합니다. 주로 예측 가능한 정적 콘텐츠(예: 앱 설치 파일, 이미지, 동영상) 등에 사용됩니다.

2) 풀 캐싱 (Pull Caching)

: 사용자가 CDN을 통해 요청했을 때, CDN 서버에 해당 콘텐츠가 없다면 원본 서버에서 가져와 저장하는 방식입니다. 웹사이트에 새로 추가된 콘텐츠도 사용자가 처음 요청할 때 자동으로 CDN 서버에 캐싱됩니다. 대부분의 일반적인 CDN 서비스는 풀 캐싱 방식을 기본적으로 사용합니다.

정적 콘텐츠를 계속 이야기하고있지만, 일부 서비스는 동적 콘텐츠(예: API 응답 데이터, HTML페이지)도 캐싱할 수 있습니다.

그렇다면, 위에서 가졌던 또다른 의문 "원본 데이터가 업데이트되었다면 캐싱된 콘텐츠는 바뀌나? 어떻게 바뀌나?"에 대해 알아봅니다.

3) 원본 데이터가 업데이트 된다면?

: 캐싱된 콘텐츠를 업데이트(무효화)하는 방법이 몇가지 있습니다.

CDN에서는 캐싱된 콘텐츠를 최신 상태로 유지하기 위해, 새로고침(Invalidate)하거나 갱신(Refresh)하는 방법을 사용합니다.

1. TTL(Time-To-Live) 설정
   • TTL은 CDN 서버가 콘텐츠를 캐싱해두는 시간을 의미합니다.
   • 예를 들어, TTL을 1시간(3600초)으로 설정하면, CDN은 1시간 동안 원본 서버에 다시 요청하지 않고 캐싱된 데이터를 제공합니다.
   • TTL이 만료되면, 다음 요청 시 원본 서버에서 데이터를 새로 가져와 다시 캐싱합니다.
   • Cache-Control: max-age=3600 헤더 설정으로 캐싱 데이터를 유지시킬 수 있습니다.
2. 캐시 무효화(Invalidate Cache)
   • 콘텐츠가 변경되었을 때 강제로 CDN의 캐싱 데이터를 삭제하는 방법입니다.
   • 일반적으로 CDN 서비스에서 관리자 패널에서 직접 캐시 무효화 요청을 하거나, API를 사용해 캐시를 삭제할 수 있습니다.
   • 캐시를 무효화하면 다음 요청부터는 원본 서버에서 새로운 콘텐츠를 받아 다시 캐싱하게 됩니다.
3. 캐시 버스팅(Cache Busting)
   • CDN에서 기존 캐싱된 데이터를 자동으로 무효화 하는 방법입니다.
   • 캐싱된 콘텐츠의 URL을 변경하면 CDN은 새로운 리소스로 인식해서 자동으로 업데이트된 데이터를 제공하게 됩니다.
4. ETag(엔터티 태그) 및 Last-Modified 헤더 활용
   • Etag: 원본 서버에서 각 파일이 고유한 식별자(해시값)를 생성하고, CDN이 이를 비교해 변경이 있는 경우 최신 버전으로 갱신합니다.
   • Last-Modified: 파일이 마지막으로 변경된 시간을 기록해, 변경된 경우만 새로운 콘텐츠를 가져오도록 설정합니다.

4. 정리

가장 일반적인 방법은 TTL과 캐시 버스팅을 함께 사용하는 것으로 설명됩니다.

자주 변경되지 않는 정적 콘텐츠는 TTL을 길게 설정하고, CSS와 JS파일 변경시에는 ?v=버전 방식을 사용합니다.

중요한 변경이 발생할 때에는 CDN 캐시 무효화 API를 꼭 사용해 모든 사용자가 새 파일을 받도록 합니다.

Wi-fi: Wirless Fidelity의 줄임말로, 무선 인터넷 연결 기술을 의미합니다.

일반적으로 라우터(Router)와 같은 무선 네트워크 장치를 통해 인터넷에 접속할 수 있도록 해주는 기술입니다.

와이파이는 IEEE 802.11(정보처리기사에도 나온다.)표준을 기반으로 하며, 2.4GHz,및 5GHz 주파수를 사용하여 데이터를 전송합니다.

라고 정리되어있지만, 여기서 모르는 단어가 무더기로 속출합니다.

라우터(무선 네트워크 장치), IEEE 802.11 표준, 2.4GHz, 5GHz 주파수 등.

1. 라우터

라우터는 이렇게, 공유기처럼 생겼습니다, 라고 하지만 익히 들어본 공유기, 라우터, 허브, 스위치 네 장비들은 네트워크를 구축하는데 쓰이는 장비이고 사실 다들 비슷하게 생겨선 기능이 조금씩 다릅니다(네트워크 장비 알아보기→)

짧게 요약하자면, 라우터는 네트워크가 인터넷(전세계)에 접속할 수 있도록 하는 장치로, 통신 신호들의 경로를 지정해주는 장치입니다. "Route(경로) + er(를 만들어주는)"

집에서의 예시로 설명해보겠습니다.

1. ISP(Internet Service Provider: KT, SK, LG와 같은 인터넷 서비스 제공업체)로부터 유선(광케이블, DSL 등)으로 인터넷 신호를 모뎀으로 공급받습니다.
2. 0, 1의 빛 신호를 모뎀(보통 KT 셋톱박스 등이 이런 역할을 합니다.)에서 디지털 전기신호(Ethernet 신호)로 변환합니다.(해당 내용은 OSI 7계층 알아보기→ 에서 자세히 다룹니다.)
3. 모뎀과 연결된 공유기(혹은 셋톱박스에 포함된 공유기 기능을 통해)가 이 인터넷 신호를 이용해 무선신호(2.4GHz/5GHz)를 생성합니다.
   → 해당 디지털 전기신호에는 정해진 규칙(IEEE 802.11 표준, DIX 2.0 등)에 따라 목적지가 정해져 있습니다. 연결된 스마트폰이나 노트북 등이 이에 해당되는데, 이곳으로 데이터를 보내기 위해 아날로그 전파(무선 주파수, RF 신호)로 데이터를 변환하는 변조(Modulation)과정을 거칩니다(이 때도 OFDM, QAM 등 다양한 데이터 압중 방식이 있습니다.).

이렇게 무선신호를 마구마구 뿌리고 있으면, 스마트폰, 노트북 등은 이 신호를 어떻게 잡아 사용할까요?

2. IEEE 802.11와 2.4GHz, 5GHz

무선랜, 와이파이(Wi-Fi)라고 부르는 무선 근거리 통신망 또는, 무선 네트워크에 사용되는 표준 규격으로, IEEE의 LAN/MAN 표준 위원회(IEEE 802)의 11번째 워킹 그룹에서 개발된 표준 기술임을 의미합니다.

즉, '전세계 기기들의 무선통신을 위해 디지털신호에 OSI 7계층 표준을 따를 때, 헤더는 어떻게 어떻게 구성해서 목적지/송신지를 어떻게 표기해서 우리 모두 이 규칙을 따릅시다!' 같은 의미로 알고있으면 이해하기 쉬울 것 같습니다.

이 규칙에 따라 2.4GHz 대역 전체 범위 2.400GHz ~ 2.4835GHz중 Wi-Fi는 (2.412GHz ~ 2.472GHz)범위를 따르기로 정한 것이고, 5GHz 역시 (5.180GHz ~ 5.825GHz)범위를 따르기로 정한 것입니다.

1. 공유기(A)가 설정된 규칙을 통해 선언합니다 → "저는 2.437GHz(6번채널)에서 Wi-Fi 신호를 쏘겠습니다 !"
   2.4GHz 내에서도 채널이라는게 존재하는데 보통 (1, 6, 11)채널이 사용됩니다. 0.005GHz단위로 채널이 바뀝니다.
   2.412(1채널) 2.417(2채널) ... 2.437(6채널) ... 2.472(11채널)
   이 때, 공유기는 SSID(네트워크 이름)을 함께 브로드캐스팅(전체송출) 합니다.
2. 스마트폰(B)의 Wi-Fi 모듈은 2.45GHz 대역에서 모든 채널을 스캔합니다.
   이 때, 와이파이 설정 목록에 스캔된 와이파이 목록이 주르륵 새로고침 되겠죠?
   (A의 iptime, B의 wi-fi, 204호 와이파이 ...)
   여기서 내가 원하는 와이파이를 선택하면, 이 SSID를 가진 Wi-Fi의 채널을 고정해 "이 신호만 받겠음!" 처리를 하는것입니다.
3. 이후에는 OSI 7계층을 기반으로 서로 정해진 프로토콜에 따라 데이터를 교환합니다.

이래서 스마트폰 Wi-Fi를 쓰지 않음에도 Wi-Fi기능을 켜두면 와이파이 모듈이 계속 2.4GHz 5GHz 대역을 스캔하느라 배터리가 빨리 닳는다고 이야기하나보다 !

(블루투스 작동법 알아보기→)

클라우드 인프라를 사용하건, 개인 로컬 서버를 사용하건 어디든 접속하거나 파일을 전송하려면 SSH를 보편적으로 가장 많이 사용하게 됩니다.

기본적인 사용법부터 터널링방법까지 익혀 어떤 인프라 환경에서든 자유로이 접속할 수 있도록 정리해봅니다.

1. SSH란 ?

2. SSH 터널

3. 키 기반 인증

1. SSH(Secure Shell)란 ?

네트워크를 통해 안전하게 원격 시스템에 접속하기 위해 사용하는 보안 프로토콜입니다. 암호화 기술을 사용해 네트워크상의 데이터 전송을 보호하며, 주로 원격 서버 관리, 파일 전송 등에 사용됩니다.

• OSI 7 계층 모델의 응용계층(Application Layer, 7계층) 에서 동작하는 프로토콜입니다.
  정보처리기사에서 해당 내용을 다루기도 합니다. 
  • 사용자에게 원격 로그인 서비스와 데이터 전송 기능을 제공하고, 하위 계층(전송 계층)의 지원을 받아 어플리케이션 수준에서 기능을 수행합니다.
  • 내부계층구조
    • 응용계층(7계층): SSH 클라이언트 프로그램(PuTTY, OpenSSH 등)이 이 계층에서 실행됩니다.
    • 전송계층(4계층): TCP 포트 22번을 통해 연결을 설정합니다(SSH는 TCP를 사용)
    • SSH는 Telnet과 같은 비보안 원격 접속 프로토콜을 대체해 안전한 통신을 보장하는 암호화된 프로토콜 입니다.

SSH의 주요 기능

1. 원격 접속: 원격 서버에 로그인하여 작업할 수 있습니다.
2. 보안 데이터 전송: 암호화된 방식으로 데이터를 주고받기 때문에 네트워크 도청에 안전합니다.
3. 포트 포워딩: SSH 터널링을 통해 다른 네트워크 서비스에 안전하게 접근할 수 있습니다.
4. 파일 전송(SFTP, SCP): SSH 프로토콜을 이용해 파일을 업로드 및 다운로드 할 수 있습니다.

SSH 연결 방식

• 기본적으로 클라이언트-서버 구조로 이루어져 있습니다.
  • 클라이언트: SSH를 사용해 연결을 시도하는 시스템(예: 로컬PC)
  • 서버: SSH 접속 요청을 처리하는 시스템(예: 클라우드 인프라 서비스의 서버)

SSH 연결 기본 구조

ssh [username]@[host]

• username: SSH 접속할 때 사용할 사용자 이름.
• host: IP 주소 또는 도메인

SSH 연결에 필요한 준비 사항

1. 서버 정보 확인
   • 클라우드 서비스 혹은 연결할 PC가 제공한 IP 주소.
   • SSH 포트(기본: 22)
2. 인증 방식
   • 비밀번호 방식: 서버에서 설정된 비밀번호로 인증.
   • SSH 키 방식: 공개키와 개인키를 사용해 인증.

+ 클라이언트 프로그램

기본적으로 윈도우, 리눅스, Mac OS 전부 OenSSH 클라이언트를 포함하고 있지만, 윈도우에선 PuTTY라고 SSH를 GUI 기반으로 사용할 수 있도록 지원하는 프로그램이 있습니다.

2. SSH 터널링

예를들어 다음과 같은 상황이라고 생각해 봅니다. (실제로 저는 Cloud서버 세팅을 위해 아래와 같은 상황을 겪었습니다.)

DMZ존에 위치한 중간 관리 서버(예:DMZ서버) 를 통해 내부망에 있어 직접 접근 불가능한 서버(예: WEB서버)에 접근 및 파일전송을 실행해야 하는데, 전송할 파일을 DMZ 서버에 전송하고, 다시 DMZ 서버에서 WEB서버로 파일을 전송하면 불필요한 파일의 복사가 실행되어 효율적이지 못합니다. 따라서, DMZ 서버를 거쳐 바로 WEB서버로 파일을 전송할 수 있도록 SSH 터널링을 사용합니다.

• 동작원리?
  • SSH 터널링은 로컬 포트를 중계 포트로 지정해 데이터 흐름을 안전하게 터널처럼 연결합니다(아래 방법 2)
  • 이를통해 중간노드를 경유해 최종 목적지와 연결되도록 만듭니다.
  • ProxyJump(아래 방법 1)은 이 과정을 자동화해 SSH 명령어에 중계 서버를 한 줄로 연결할 수 있도록 만듭니다.

SSH 터널링 방법

0. SSH ProxyJump 연결

ssh -J {DMZ서버 사용자 이름}@{DMZ서버 아이피} {WEB서버 사용자이름}@{WEB서버 아이피}

이후 각 서버의 사용자 이름에 대한 비밀번호를 요구하는창이 각각 발생한다(위의 예시로는 총 2번)

1. ProxyJump 사용 (OpenSSH 지원)ProxyJump는 중간서버를 통해 WEB 서버로 바로 파일을 전송할 수 있게 만듭니다.

(명령어가 길어지는게 불편하다면 ~/.ssh/config 파일에 설정을 추가해 더 간단하게 사용할 수도 있습니다.)

Host {별칭 지정}
	HostName {WEB서버 아이피}
	User {WEB서버 사용자이름}
	ProxyJump {DMZ서버 사용자이름}@{DMZ서버 아이피}

ssh {지정한 별칭} scp {전송할 파일} {지정한 별칭}:{저장할 경로}
spc -o ProxyJump={DMZ서버 사용자이름}@{DMZ서버 아이피} {전송할 파일} {WEB서버 사용자이름}@{WEB서버 아이피}:{저장할 경로}

2. 수동 포트 포워딩 (SSH 포트 포워딩)

ssh -L 2222:{WEB서버 아이피}:22 {DMZ서버 사용자이름}@{DMZ서버 아이피}

• -L 2222:{WEB서버 아이피}:22 : 로컬 포트 2222를 DMZ서버를 통해 WEB서버의 SSH 포트 22로 전달하겠음을 설정합니다. 이 명령을 실행하면 로컬 PC에서 내부망 WEB 서버로 SSH 접속하듯 사용할 수 있다.

scp -P 2222 {전송할 파일} {WEB서버 사용자이름}@localhost:{저장할 경로}

• localhost:2222를 통해 DMZ서버를 거쳐 WEB 서버로 파일을 직접 전송합니다.

3. 키 기반 인증

비밀번호 대신 공개키/개인키를 사용해 보안성을 강화한 인증방식입니다.

(Github Repository를 사용할 때 마주친 적이 있습니다.)

1. SSH 키 기반 인증의 개념

• 공개키(public key): 서버에 저장되는 키.
• 개인키(private key): 클라이언트에 보관되는 키. 절대 공유되지 않아야 합니다.
• 클라이언트가 SSH 연결 시 개인키를 사용해 인증하면, 서버는 저장된 공개키를 통해 인증 요청을 검증합니다.

2. SSH 키 생성 및 설정 방법

1. SSH 키 생성: 클라이언트(로컬 PC)에서 SSH 키를 생성합니다. 

ssh-keygen -t rsa -b 4096

• -t rsa: 키 타입을 RSA로 설정합니다.
• -b 4096: 키 길이를 4096비트로 설정합니다(권장)
• 기본적으로 ~/.ssh/ 디렉토리에 id_ras(개인키)와 id_ras.pub(공개키)가 생성됩니다.

2. 생성된 공개키를 서버에 복사합니다.

ssh-copy-id {사용자이름}@{서버IP}

• ssh-copy-id: ~/.ssh/id_ras.pub 공개키를 서버의 ~/.ssh/authorized_keys 파일에 추가합니다.

(수동으로 복사하는 방법도 있습니다, cat, mkdir, echo, chmod등의 명령어를 이용)

3. SSH 키 기반으로 접속하기

ssh -i ~/.ssh/id_rsa {사용자이름}@{서버IP}

• -i 옵션으로 사용할 개인키 경로를 지정한다.

4. 추가 보안 설정

• 키 인증만 허용하기 위해 비밀번호 인증을 비활성화 할 수 있습니다.

sudo nano /etc/ssh/sshd_config 명령어로 ssh 설정파일을 열고 PasswordAuthentication 항목을 no로 설정합니다.

sudo systemctl restart ssh 명령어로 ssh 서비스를 재시작합니다.

5. Troubleshooting

• 공개키 권한 오류: authorized_keys 파일의 권한을 600(읽기 및 쓰기)로 설정합니다.
• 퍼미션 거부 오류: 홈 디렉토리나 ~/.ssh 디렉토리의 소유자가 root가 아닌 사용자 본인인지 확인합니다.

(부디 틀렸거나 이해가 잘 되지 않게 설명된 내용에 대해 댓글들 달아주세요 !)

Http

: HyperText Transfer Protocol

Http는 WWW(World Wide Web), 일반적으로 인터넷이라 부르는 웹 상에서 정보를 주고 받을 수 있는 프로토콜입니다.

프로토콜은 무엇일까요 ?

사전으로는 '컴퓨터 내부에서, 또는 컴퓨터 사이에서의 데이터 교환 방식을 정의하는 규칙 체계'로 설명됩니다.

이해를 돕기 위한 비유로 택배 송장이 가장 적절할 것 같습니다.

프로토콜이 컴퓨터 사이의 데이터 통신을 위한 규칙체계라면,

사람 사이에 우편을 주고받는 규칙이 바로 택배 송장인것입니다 !

(택배회사마다 다른 양식을 갖고있듯, 컴퓨터 통신을 위한 프로토콜 형식 역시 목적에따라 여러 규칙을 갖고있습니다.

자세한 내용은 -> OSI 7 Layer 알아보기(미작성))

택배 송장을 보면 보내는사람의 성명, 전화, 주소, 받는사람의 성명, 전화, 주소가 있듯, HTTP 프로토콜에도 데이터통신을 하기위한 형식이 있습니다.

알 수 없는 영어가 마구 쓰여져있지만, 구조에 주목해본다면 택배 송장과 꽤 비슷하게 생겼음을 알 수 있습니다.

물론, 위의 이미지를 인쇄해서 양식을 작성한다음 스캔해서 데이터를 보내는 것이 아니라,

문자열 형식으로 데이터를 요청하고, 받는 형식으로 사용됩니다.

예를들어, 명령 프롬프트에 'curl https://www.naver.com/'을 입력해보겠습니다.

curl : Client URL의 약자로, 윈도우나 유닉스계열(Linux, MacOS 등)에서도 사용할 수 있는 명령줄 도구입니다.
다양한 프로토콜을 사용해 데이터를 전송할 수 있으며, 택배 송장 양식에 대한 직접작성 없이 테스트해보기 아주 좋은 도구입니다.

이는 'https://www.naver.com/' 주소로 GET요청을 보내는 명령어 입니다.
('GET요청'이 명령어 어디 쓰여있나요? : 생략되어있다면 기본 GET 요청을 전송합니다.)
'GET요청'이란 HTTP 메서드를 지칭하는데, GET 외에도 POST, PUT, DELETE 등 다양한 메서드를 사용할 수 있습니다.
(자세한 내용은 -> HTTP메서드 알아보기(미작성))

네이버 홈페이지 주소로 요청을 보내고 받은 응답입니다.

그런데 받은 응답을 자세히 보면! 익숙한 HTML 태그들이 보입니다.

또, 네이버 메인에 접속하면 보이는 한글 텍스트도 보입니다.

인터넷 브라우저(크롬, 엣지 등)을 이용해 네이버(www.naver.com)에 접속해 F12키를 눌러 개발자 도구를 열고,

Elements 탭으로 이동해보면 비슷한 것을 볼 수 있습니다.

사실 우리가 받은 외계어같은 긴 응답구문은 사실 네이버 메인페이지의 HTML 문서인 것입니다.

그렇다면 어떻게 'curl https://www.naver.com/' 한줄로 네이버 메인페이지의 html  문서를 가져올 수 있었을까요 ? 

처음 이야기했던 프로토콜 양식을 사실은 절반 이상 작성했습니다.

'https://www.naver.com/'

URL이라 불리는 이 한 줄 안에 많은 것이 담겨있습니다.

URL의 구조는 위 사진과같은 구조를 갖고있습니다.

1. 통신 프로토콜(스키마) : 어떤 프로토콜을 이용한 요청인지를 나타냅니다.

2. 호스트 : 웹 사이트가 호스팅되는 서버의 도메인(아이피 대신 사용되는 영문주소) 입니다.

3. 3차 도메인(서브 도메인) : 메인 도메인 내의 하위 섹션을 나타냅니다.

4. 2차 도메인(메인 도메인) : 조직이나 서비스의 고유 이름을 나타냅니다.

5. 1차 도메인(최상위 도메인) : 도메인의 목적이나 지역을 나타냅니다.

6. 포트번호 : 서버의 특정 서비스에 접근하기 위한 번호입니다. (생략시 기본값 사용, http는 80, https는 443)

7. 디렉터리 : 서버 내의 파일 경로를 나타냅니다.

8. 파일 : 접근하려는 특정 파일의 이름입니다.

9. 파일 형식 : 파일의 확장자로, 파일의 유형을 나타냅니다.

10. 쿼리(쿼리스트링) : 서버에 추가 정보를 전달하는 매개변수 입니다. '?' 뒤에 오며, 여러 매개변수는 '&'로 구분합니다.

갑자기 사진 하나에서 모르는 용어가 마구 등장했습니다.

지금은 URL 구조가 이런식으로 이루어져 있다만 알고계시면 될 것 같습니다.

자세한 내용은 다음 DNS 게시글에서 다루도록 하겠습니다 !