[Computer Network] Internet Protocol Layer

 

 

 

응용 계층 (OSI 5/6/7)

운영체제의 프로세스로 띄워지는 요소를 의미한다. 

스프링으로 백엔드 서버를 구축하고 컴퓨터에 띄우면 하나의 독립된 프로세스가 되는데, 이 백엔드 서버가 응용 계층 역할을 수행한다.

 

HTTP / SMTP / FTP 같은 프로토콜과 이 프로토콜을 사용하는 소프트웨어가 응용 계층에 속한다. 

 

전송 계층 (OSI 4)

TCP - HTTP/1.1, HTTP/2

UDP - HTTP/3 (Chrome 브라우저)

 

이미 운영체제에 구현되어 있는 부분이라 직접 구현하지 않고 운영체제의 네트워크 스펙을 그대로 사용한다.

포트번호를 사용한 프로세스 연결, TCP UDP를 사용한 오류제어 및 혼잡제어를 수행한다. 

TCP의 경우 1Gbps 에서 40명이 동시에 요청 시 대역폭을 나눠 25Mbps로 균등하게 분배해주고,

UDP의 경우 제어가 없기에 해당 예시에서 39Gbps 상당의 패킷은 유실된다. 

 

그래서 사실 HTTP에는 UDP가 어울리지 않는데, HTTP/3 에서는 UDP + QUIC(보강로직) 을 사용한다.

QUIC는 구글이 설계한 프로토콜으로 자체적으로 재전송 로직 / 보안 / 멀티플렉싱을 내장하고 있다.

 

데이터를 전송 단위로 나누는 작업은 여기서 수행한다.

 

네트워크 계층 (OSI 3)

컴퓨터간 정보를 전달한다. 

호스트 식별을 위해 IP 주소를 사용하고, 라우팅을 통해 최적 경로를 탐색한다. (다익스트라, 벨만-포드)

 

데이터는 패킷 단위로 쪼개서 전송된다. 

네트워크 환경(MTU)에 맞춰서 쪼개는 작업은 여기서 수행한다.

 

데이터링크 및 물리 계층 (OSI 1/2)

이더넷, 와이파이, MAC

같은 네트워크 안에서 신호를 프레임 단위로 안정적으로 전달한다.  

 

 

 

---

 

 

 

응용 계층의 프로토콜은 사용자가 실제로 이용하는 서비스인 웹, 이메일, 파일전송 등을 의미한다.

즉, 서로 다른 컴퓨터간 데이터를 주고받는 규칙이 프로토콜이다.

 

웹에서는 HTTP / 파일 전송에서는 FTP / 이메일에서는 SMTP / 화상회의에서는 RTP 

이렇게 각 서비스별로 프로토콜을 따로 사용하는데... 

 

최근에는 별도의 응용 프로토콜을 만들기보다는 HTTP 하나로 모든 걸 해결하는 추세이다.

 

서버는 고정 IP를 사용한다. 클라이언트가 언제든 같은 주소로 접근할 수 있어야 하기에..

윈도우 기준으로 그냥 제어판 들어가서 IP 고정해 주면 됨.. 리눅스에서는 파일에 직접 쓰면 되고.. 

 

클라이언트는 IP가 고정될 필요가 없다. 네트워크에 접속할 때 마다 자동으로 할당되는 임시 IP 주소(DHCP)를 활용한다.

DHCP 서버는 클라이언트에게 임시로 IP를 빌려주고 클라이언트는 그 IP를 사용해 인터넷에 접속한다.

공유기에는 내부적으로 DHCP 서버가 켜져 있고, 설정에서 지정해 둔 IP 범위에 따라서 IP가 할당된다. 

 

고정 IP는 관리비용이 크고 자원이 낭비되지만 서버는 항상 접근이 가능해야 한다. 그러니 고정 IP

클라이언트는 고정일 필요가 없다. DHCP는 자동이라 편하고 IP 낭비도 막을 수 있다. 그러니 동적 IP 

고정 및 동적 IP와 사설 및 공인 IP는 전혀 다르니 헷갈리지 말 것.. 

 

반면 Peer-to-Peer 는 모든 기기가 동등한 지위로 서로 통신한다. (p2p)

클라이언트-서버 구조와는 전혀 다른 구조로, 그냥 내 컴퓨터가 클라이언트이면서 서버 역할을 한다.

 

중앙 서버 없이도 네트워크 전체가 연결될 수 있음.

근데 사실 Bootstrap Server나 Signaling Server를 두고 사용하긴 하는데.. 그래도 컨셉은 같다. 

 

서버 없이 통신한다는게 가능한가? 뭔소린가 싶긴 한데.. "연결"과 "전송"을 분리해서 보자.

전송은 Peer-to-Peer 가 맞다. 얘내가 서버를 거치지 않고 직접 전송한다.

다만 연결을 위해서는 Signaling, Bootstrap이 잠깐 사용된다. 데이터를 처리하진 않고 연결만 다룬다.

 

(컨트롤 평면: 얇은 서버)            (데이터 평면: 서버 무관)
  [Signaling(SB)]  ─────────┐
        ▲                   │  offer/answer/ICE (문자)
        │                   │
   ws/http                   ▼
 [Peer A]  ⇄⇄⇄⇄  (STUN/ICE/Hole Punch)  ⇄⇄⇄⇄  [Peer B]
                      (직접경로)

 

BitTorrent가 딱 이런 구조로 작동한다. 피어의 IP/Port를 알려주고, 전체 파일을 작은 조각으로 나눠서 다룬다. 

초기 파일은 Seeder가 가지고 있고, Seeder가 토렌트를 처음 생성하고 배포를 시작한다.

 

이게 진화한게 블록체인 기술이다.

p2p 네트워크 자체는 그냥 서로 데이터를 주고받는 구조라서, 진짜 기록을 보장해주는 장치가 없다.

이를 위해 합의와 서명이 도입됐고, 이 기술이 블록체인이다.

 

서버 없이도 통신되는데 그럼 p2p 안쓰는게 호구 아님? 키 교환으로 통신 간 보안도 보장되는데.

근데 Peer가 오프라인이면 서비스가 안되고 중앙화된 상태관리가 아니니까 이거에 따른 문제점도 많다. 

 

 

잠깐 파일 배포 시간을 비교해보자. Server-Client / p2p

 

 

$$
\textbf{Client–Server (중앙 서버 1대)} \\
T_{\mathrm{CS}}
= \max\left(
\frac{N F}{u_s},
\frac{F}{d_{\min}}
\right)
$$

$$
\textbf{Pure P2P (순수 P2P)} \\
T_{\mathrm{P2P}}
= \max\left(
\underbrace{\frac{F}{u_s}}_{\text{서버가 최초 1복사본 배포}},
\underbrace{\frac{N F}{u_s + \sum_{i=1}^{N} u_i}}_{\text{전체 업로드 자원으로 N복사본 생성}},
\underbrace{\frac{F}{d_{\min}}}_{\text{가장 느린 다운로드 병목}}
\right)
$$

$$
\text{(동일 피어 가정: }u_i=u,\; d_i=d\text{)} \\
T_{\mathrm{P2P}}
= \max\left(
\frac{F}{u_s},
\frac{N F}{u_s + N u},
\frac{F}{d}
\right)
$$

$$
\textbf{스케일링 비교:} \quad
T_{\mathrm{CS}} \propto N, \quad
T_{\mathrm{P2P}} \text{ 는 } N \uparrow \text{일 때 } \frac{N}{u_s+N u} \downarrow
\;\Rightarrow\; \text{상대적으로 완만함.}
$$

 

 

순수 p2p에서는 중앙 서버가 없으니 각 키를 어느 피어에 저장해야하는지 결정해야 한다.

이 때 Distrubuted Hash Table을 도입한다. 해시 공간에 원형 링을 구성해서 모든 피어와 키를 같은 해시 공간에 매핑한다.

 

 

 

 

키를 가장 가까운 피어에게 할당한다.

여기서 가깝다는건 물리적 거리가 아니라, 해시 공간 상의 논리적 거리가 가까움을 의미함.

이러면 각 피어가 일부 키 값만 관리하게 되어 전체 데이터가 자연스럽게 분산되고, 피어가 새로 들어오거나 나가도 일부 키만 재배치하면 되니 굉장히 효율적이다.

 

Signaling, Boostrap 서버가 있으면 초기 피어 탐색이 간단해지지만, 그 서버가 없어지면 네트워크 전체가 무너진다.

그러니 DHT 같은 구조가 그걸 대체하기 위해 등장했다.

 

p2p가 유용할 때는 대용량  파일을 분산 배포할 때, WebRTC를 사용할 때 정도고, 트랜잭션 및 인증이 중요한 서비스에서는 여전히 클라이언트 - 서버 모델이 유용하다.

그런데 유용한 도구인건 맞으니.. 익숙하다고 서버-클라이언트 모델을 무조건 맹신하기보다는 상황봐서 적당히 사용해보는게 좋을듯..

 

 

 

응용 계층에서는 프로세스간 통신으로 처리된다. (IPC)

클라이언트건 서버건 서로 통신할 때는 쓰레드가 아니라 프로세스 단위로 처리된다.

스프링으로 백엔드를 만들고 띄우면 Tomcat 웹 서버가 프로세스 단위로 실행되고, 클라이언트의 크롬 브라우저도 프로세스 단위로 실행된다.

물론 그 안에서 여러 쓰레드가 동작할 수는 있다. 

서버 전체는 하나의 프로세스지만 동시에 여러 클라이언트를 처리하기 위해 Tomcat은 멀티쓰레딩을 사용한다.

쓰레드는 어차피 내부 실행 단위니까 쓰레드끼리 통신을 위해서 결국 프로세스를 거쳐야 한다.

 

소켓은 네트워크를 통해 다른 컴퓨터의 프로세스와 데이터를 주고받기 위한 통로라고 생각하면 된다.

클라이언트의 프로세스에도 소켓이 있고, 서버의 프로세스에도 소켓이 있다. 이 소켓이 연결되면 프로세스간 통신 채널이 완성된다.

 

import socket

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(('0.0.0.0', 8080))   # (IP, PORT)
server.listen()

print("Server waiting for connection...")
conn, addr = server.accept()
print("Connected by", addr)

data = conn.recv(1024)
print("Received:", data.decode())

conn.sendall(b"Hello from server!")
conn.close()
server.close()

 

 

파이썬으로 socket을 설정할 때 bind로 소켓에 IP주소와 포트번호를 연결하고 listen으로 소켓을 수신 대기 상태로 전환시킨다.

 

HTTP도 소켓위에서 동작하는 응용 계층 프로토콜이다.

소켓은 그냥 파이프라인. HTTP는 통로를 사용하는 규칙으로 생각하자.

 

그런데 여기서 TCP(Transmission Control Protocol)를 알아야 한다.. 소켓은 통로의 끝일 뿐이고, TCP는 그 통로 위에서 데이터를 안전하게 주고받는 방법을 정한 규칙이다. 

 

TCP는 전송 계층 프로토콜으로 데이터를 정확한 순서로 전달하는 역할을 수행한다.

소켓은 TCP 방식을 사용하기 위한 운영체제의 인터페이스 객체라고 생각하면 된다. 

 

HTTP는 TCP 위에서 돌아가고.. TCP는 IP 위에서 돌아가고.. 소켓은 HTTP와 TCP사이를 연결해주고.. 

소켓이 프로세스의 문 자체라면 TCP는 두 문을 이어주는 길을 만드는 역할을 수행한다.