[컴퓨터 네트워킹 하향식 접근] 챕터2

목차

1. 네트워크 애플리케이션의 구조
2. 프로세스와 컴퓨터 네트워크 사이의 인터페이스
3. 애플리케이션 요구에 적합한 서비스 제공 프로토콜 고르는 기준
4. 웹과 HTTP
5. HTTP 메세지 포맷
6. 쿠키
7. 웹 캐싱
8. 클라이언트 측 캐시
9. 서버 측 캐시
10. 조건부 GET
11. HTTP/2
12. HTTP/3
13. 인터넷 전자메일 SMTP
14. DNS 인터넷의 디렉터리 서비스
15. P2P 파일 분배
16. 비디오 스트리밍과 콘텐츠 분배 네트워크
17. 소켓 프로그래밍: 네트워크 애플리케이션 생성

 

네트워크 애플리케이션의 구조

 

클라이언트 서버 구조

클라이언트는 서로 직접적으로는 통신x 

서버는 항상 고정 IP주소를 가지고 동작한다.

데이터 센터 - 많은 수의 호스트를 갖추어 가상의 서버를 생성

 

P2P 구조

항상 켜져 있는 인프라스트럭처 서버에 최소로 의존

대표적인 예로는 비트토렌트

서버 대역폭을 요구하지 않기 때문에 비용 효율적

자기 확장성 - 각 피어들은 파일을 다른 피어들에게 분배함으로써 그 시스템에 서비스 능력 추가

 

프로세스 간 통신

운영체제에서 실제 통신하는 것은 프로그램이 아니라 프로세스

프로세스란 종단 시스템에서 실행되는 프로그램

 

웹: 브라우저 -  클라이언트 프로세스, 서버 - 서버 프로세스

p2p: 파일을 내려받는 피어 - 클라이언트, 파일을 올리는 피어 - 서버

 

-> 두 프로세스 간의 통신 세션에서 통신을 초기화하는 프로세스를 클라이언트라 하고, 세션을 시작하기 위해 

접속을 기다리는 프로세스를 서버라고 한다. 

 

프로세스와 컴퓨터 네트워크 사이의 인터페이스

프로세스는 소켓을 통해 네트워크로 메시지를 보내고 받음

프로세스 = 집

소켓 = 출입구

 

소켓은 애플리케이션과 네트워크 사이의 API라고도 한다.

애플리케이션 개발자는 트랜스포트 계층에 대한 통제권은 거의 갖지 못한다.

 

프로세스 주소 배정

호스트의 프로세스 -> 다른 호스트의 프로세스

패킷을 보낼 때 수신 프로세스는 주소를 가져야 한다.

프로세스 식별을 위해 필요 -> (IP주소 + PORT번호)

 

 

애플리케이션 요구에 적합한 서비스 제공 프로토콜 고르는 기준

1. 신뢰적 데이터 전송

TCP - 프로토콜이 보장된 데이터 전송 서비스 제공으로 오류 없이 수신 프로세스에 도착할 것이라는 확신 존재

UDP - 어느 정도의 데이터 손실을 참아낼 수 있는 실시간 서비스에 알맞다.

 

2. 처리율

대역폭 민감 애플리케이션: 처리율 요구사항을 가진다. -> 비디오 인코딩 

탄력적 애플리케이션: 가용한 처리율이 많으면 많은 대로 적으면 적은대로 이용가능 -> 전자메일, 파일 전송 등

 

3. 시간

트랜스포트 계층 프로토콜은 시간 보장을 제공 가능

 

4. 보안

트랜스포트 프로토콜은 하나 이상의 보안 서비스 제공가능

기밀성, 무결성, 종단 인증 제공

 

TCP는 보안 서비스를 제공하기 위해 TLS(transport layer security)를 통해 쉽게 강화될 수 있음

-> 암호화, 데이터 무결성, 종단 인증 포함

 

++ 중요 TCP와 UDP의 차이

TCP - 신뢰성 보장, 사전연결(핸드 셰이크), 혼잡 제어, 흐름 제어

UDP -  비신뢰적 연결, 사전 연결 x

웹과 HTTP

웹 페이지의 구성

HTML파일 + 여러 참조 객체

URL -> 호스트 이름 + 경로

 

 

HTTP과정

1. TCP를 전송 프로토콜로 사용

2. HTTP클라이언트는 서버에 TCP연결

3. 브라우저 + 서버 프로세스 -> TCP로 접속

4. 그 이후 요청과 응답 발생

 

 

 

이때 서버는 클라이언트에 관한 상태정보 저장x

즉 HTTP는 비상태 프로토콜

 

 

 

비지속 연결과 지속 연결

비지속 연결 HTTP ex ) HTTP/1.0

 

TCP 연결 후 수행 과정

1.  HTTP 클라이언트는 HTTP의 기본 포트 번호 80울 통해 TCP 연결 시도
2. 클라이언트의 TCP연결 소켓을 통한 HTTP 요청 메세지
3. 서버 요청 메세지를 받은 후 객체를 추출하고 응답 메시지를 소켓을 통해 클라이언트로 보냄
4. HTTP 클라이언트가 응답 메시지를 받으면 TCP 연결 중단 

 

서버가 객체를 보낸 후에 TCP연결이 끊어진다. 따라서 오버헤드가 너무 커진다.

 

 

TCP 연결을 위한 세 방향 핸드셰이크

1. 클라이언트가 작은 TCP 메시지를 서버로 보냄
2. 서버는 작은 메시지로 응답
3. 클라이언트가 다시 서버에 응답

 

RTT(round-trip-time) = 패킷 전파 지연, 큐잉 지연, 패킷 처리 지연 등을 포함

총 응답 시간 = 2RRT + HTML파일 서버 전송하는데 걸린 시간

 

 

지속 연결 HTTP

그와 반대로 연결을 지속하고 있다.

디폴트 모드는 파이프라이닝을 이용한 지속 연결

 

 

 

HTTP 메세지 포맷

요청 메세지

 

1. request 라인 - 메소드 필드, URL필드, HTTP 버전 필드 가짐
2. 헤더 라인 - 웹 프록시 캐시에서 필요로 함
3. body - 요청할 데이터 담음

 

 

메소드 종류

POST - 먹등하지 않음

GET- 요청

HEAD - 리소스를 GET메소드로 요청했을 때 응답으로 오는 헤더부분만 요청하는 메소드

PUT - 먹등함 일부 속성을 추가

 

 

응답 메세지

1. 상태 라인 - 버전 필드, 상태 코드, 해당 상태 메시지
2. 헤더 라인 - Date, Server, Content-Length, Content-Type 등을 포함
3. 개체 몸체 - 요청 객체

 

상태 코드 - 200, 301(요청 객체의 이동), 400(오류 코드), 404, 505(HTTP프로토콜 버전 서버 지원x)

 

쿠키

사용자의 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하길  원할때 이용

요소 4가지

1. HTTP 응답 메시지 쿠키 헤더 라인

2. HTTP 요청 메시지 쿠키 헤더 라인

3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일

4. 웹사이트의 백엔드 데이터베이스

 

클라이언트의 요청 -> 서버는 응답으로 Set-Cookie 헤더 포함

그이후 클라이언트 요청은 Cookie 헤더 포함

 

따라서 쿠키는 비상태 HTTP 위에 사용자 세션 계층을 생성하는데 이용

but 사생활 침해를 할 수 있다는 단점 존재

 

++세션과 쿠키의 관계

• 세션 ID를 쿠키에 저장: 세션과 쿠키는 함께 사용되는 경우가 많습니다. 서버는 클라이언트가 요청을 할 때마다 세션 ID를 쿠키에 저장해서 클라이언트에게 전달하고, 이후 요청마다 클라이언트는 이 쿠키를 통해 세션 ID를 서버에 전송합니다. 서버는 세션 ID를 바탕으로 사용자의 상태나 데이터를 관리할 수 있습니다.

 

• 보안 측면: 세션 데이터는 서버 측에 저장되기 때문에, 쿠키를 사용하는 것보다 더 안전합니다. 쿠키는 클라이언트 측에 저장되기 때문에, 민감한 정보를 직접 쿠키에 저장하면 보안 문제가 발생할 수 있습니다. 따라서 쿠키에는 세션 ID와 같은 최소한의 정보만 저장하고, 실제 민감한 데이터는 서버 측 세션에서 관리하는 것이 일반적입니다.

 

 

웹 캐싱

웹 서버를 대신하여 HTTP요구를 충족시키는 네트워크 개체

 

1. 브라우저는 웹 캐시와 TCP연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP요청을 보낸다.

2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인 저장 되어 있을 경우 웹 캐시는 클라이언트 브라우저로

HTTP응답 메세지와 함께 객체 전송

3. 웹 캐시가 객체를 갖고 있지 않다면 TCP연결로 객체에 대한 HTTP요청을 보낸다. 
요청을 받은 후에 기점 서버는 웹 캐시로 HTTP응답 메시지와 함께 객체를 보낸다.

4. 웹 캐시의 객체를 수신할 때 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP응답 메시지와 함께 사본을

보낸다.

 

캐시는 서버이면서 클라이언트 

즉 브라우저로부터 요구를 받고 응답을 보내는 것은 서버이고 

출처 서버에게 요구를 보내거나 응답을 받는 것은 클라이언트

 

 

++이해를 위한 내용

클라이언트 측 캐시

• 웹 브라우저 캐시: 클라이언트(사용자) 측에서 웹 브라우저는 자주 요청되는 데이터를 로컬에 저장해 두어 성능을 최적화합니다. 예를 들어, 사용자가 웹사이트를 방문할 때, 이미 다운로드된 이미지, CSS, JavaScript 파일 등이 브라우저 캐시에 저장됩니다. 이후 동일한 웹사이트를 방문할 때 서버에 다시 요청하지 않고 캐시에 저장된 데이터를 사용함으로써 페이지 로딩 속도가 빨라집니다.
  • 클라이언트 측 캐시의 역할: 네트워크 트래픽 감소, 로딩 시간 단축, 서버 부담 감소.

서버 측 캐시

• 서버 캐시: 서버에서도 캐시를 사용해 자주 요청되는 데이터를 미리 저장해 두고 빠르게 응답할 수 있습니다. 예를 들어, 데이터베이스 쿼리 결과나 동적 페이지 렌더링 결과를 서버 캐시에 저장해, 동일한 요청이 들어올 때 매번 다시 계산하거나 데이터를 가져오는 대신 캐시에 저장된 데이터를 반환합니다. 이는 서버의 성능을 높이고 응답 시간을 줄이는 데 도움을 줍니다.
  • 서버 측 캐시의 역할: 서버 처리 속도 향상, 시스템 리소스 절약, 사용자 응답 시간 단축.

 

두가지 장점

1. 클라이언트의 요구에 대한 응답 시간을 줄일 수 있다.

2. 웹 캐시는 한 기관에서 인터넷으로의 접속하는  링크상의 트래픽을 대폭으로 줄일 수 있다.

 

CDN(Content Distribution Network)의 사용을 통해 웹 캐시는 인터넷에 점진적으로 중요한 역할을 하고 있다.

 

 

조건부 GET

웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만 새로운 문제를 야기할 수 있다.

-> 캐시 내부에 있는 객체의 복사본이 새것이 아닐 수 있다는 점이다.

 

모든 객체가 최신의 것임을 확인하면서 캐싱을 해주는 방식 - 객체 + 수정된 날짜 함께 저장

캐싱된 복사본 사용 시 304 Not Modified 상태라인 이는 클라이언트에게 요청 객체의 복사본을 사용하라는 의미

 

 

HTTP/2

TCP연결상에서 멀티플렉싱 요청/ 응답 지연시간 감소 , 요청 우선순위화, 서버 푸시,

HTTP 헤더 필드 효율적 압축 기능 제공

 

기존 HTTP/1의 문제점

웹 페이지당 오직 하나의 TCP 연결을 가짐

-> HOL 블로킹 문제 발생 - 큰 객체로 인해 작은 객체 전달의 병목이 생기게 된다.

그래서 기존 HTTP/1은 여러개의 병렬 TCP연결을 통해 해결해 왔다.

그래서 HTTP/2는 병렬 TCP의 연결을 줄여 소켓의 수를 줄이고 TCP혼잡을 제어하고자 했다.

 

HTTP/2 프레이밍

HTTP 메시지를 독립된 프레임들로 쪼개고 인터리빙하고 반대편 사이트에서 재조립

즉 각 메시지를 작은 프레임으로 나누고 같은 TCP연결에서의 요청과 응답 메시지를 인터리빙한다.

 

메세지 우선순위화 및 서버푸싱

병렬적인 데이터 스트림으로 쪼갠 후 1~256 가중치를 부여해 요청에 대한 우선 순위를 매김

따라서 높은 우선순위의 요청을 위한 프레임을 제일 먼저 보낼 수 있다.

 

클라이언트 요청에 대해 여러개의 응답을 통해 서버는 클라이언트의 요청 없이도 추가적인 객체를 

클라이언트에게 푸시하여 보낼 수 있다. 즉 서버는 해당 요청들을 기다리는 데 소요되는 추가 지연을 없앤다.

 

 

HTTP/3

트랜스포트 프로토콜인 QUIC는 UDP 프로토콜 위에 위치하는 애플리케이션 계층에 구현되어 있다.

RTT를 줄이기 위해 핸드쉐이크 과정 최소화

HTTP/3는 QUIC위에서 작동하도록 설계된 새로운 HTTP 프로토콜이다.

 

 

인터넷 전자메일 SMTP

인터넷 메일 시스템

3개의 주요 요소: 사용자 에이전트, 메일 서버, SMTP

 

사용자 에이전트: 대표적인 예로는 아웃룩, 지메일 등이 있다.

 

메일 서버: 각 수신자는 메일 서버 안에 메일박스를 가지고 있다.

메일을 서버로 전달할 수 없다면 메세지를 메세지 큐에 보관한다.

 

++부연 설명

메일 서버가 이메일을 수신하고 클라이언트는 이메일을 전송한는 방식으로 동작

 

SMTP: 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜로 

클라이언트와 서버 모두가 메일 서버에서 수행된다.

 

주요한 특징

1. HTTP보다 오래되었으며 전송 후 아스키를 원래 메세지로 변환해야 한다.
2. 두 메일 서버가 먼 거리에 떨어져 있더라도 중간 메일 서버를 사용하지 않음
3. 메일 서버에 남아 새로운 시도를 위해 기다림

주요 과정

1. 클라이언트 SMTP는 서버 SMTP TCP연결 설정
2. 서버와 클라이언트는 애플리케이션 계층 핸드셰이킹을 수행 (TCP와 유사)
3. SMTP 핸드셰이킹 과정 동안에 SMTP 클라이언트는 송신자의 전자메일 주소와 수신자의 전자메일 주소 제공
4. 계속 메시지 교환 or TCP close

메일 메시지 포맷

RFC 5322

헤더 라인: from 과 to 헤더 라인을 반드시 가짐

body: 아스키 문자의 메세지 몸체

 

 

메일 접속 프로토콜

 

메일 서버가 로컬 PC에 있지 않은 이유: 호스트가 항상 켜져 있어야 함

 

SMTP는 푸시의 프로토콜인 반면 메시지를 얻는 것은 풀의 동작이기 때문에

전자메일을 확인하기 위해서 HTTP나 IMAP 사용하여 메일 서버에 의해 유지되는 폴더 관리

 

 

DNS 인터넷의 디렉터리 서비스

호스트 이름:  사람이 기억하기 쉬운 호스트 이름 식별자

IP 주소: 고정 길이의 계층구조를 가진 IP 주소

 

과정

1. 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행한다.

2. 브라우저는 URL 로부터 호스트 이름을 www.sfsfs.ff.com을 을 추출하고 그 호스트 이름을 

DNS 애플리케이션의 클라이언트 측에 넘긴다.

3. DNS 클라이언트는 DNS 서버로 호스트 이름을 포함하는 질의를 보낸다.

4. DNS클라이언트는 호스트 이름에 대한 IP 주소를 가진 응답을 받게 된다.

5. 브라우저가 DNS로부터 IP 주소를 받으면 브라우저는 해당 IP 주소와 그 주소의 80번 포트에 위치하는

HTTP 서버 프로세스로 TCP 연결을 초기화한다.

 

+추가 서비스

호스트 에일리어싱

복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질 수 있다.

정식 호스트 이름 + 별칭 호스트 이름

 

메일 서버 에일리어싱

MX 레코드(어떤 메일 서버로 보내야 할지 지정하는 레코드)는 기업의 메일 서버와 웹 서버가 같은 호스트 이름을 갖는 것을 허용한다.

 

부하 분산

DNS는 중복 웹 서버 같은 여러 중복 서버 사이에 부하를 분산하기 위해 사용한다.

클라이언트가 주소 집합으로 매핑하는 호스트 이름에 대한 DNS 질의를 하면 서버는 IP 주소

집합 전체로 응답한다.

 

단일 중앙 집중 방식 DNS 문제점

서버의 고장 - 이 네임 서버가 고장 나면 전체 인터넷이 작동하지 않는다.

트래픽 양 - 단일 DNS 서버가 모든 DNS 질의를 처리해야 한다.

먼 거리의 중앙 집중 데이터베이스 - 먼 클라이언트는 심각한 지연을 겪는다.

유지관리 - 새로운 호스트를 반영하기 위해 자주 갱신해야 한다.

 

분산 계층 데이터베이스

 

루트 DNS 서버 - TLD서버의 IP주소들을 제공한다.

최상위 레벨 도메인 서버(TLD) - 책임 DNS 서버에 대한 IP 주소를 제공한다.

책임 DNS 서버 - 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공한다.

 

재귀적 + 반복적

 

재귀적

DNS 캐싱

질의 사슬에서 DNS서버가 DNS 응답을 받았을 때 로컬 메모리에 응답에 대한 정보를 저장할 수 있다.

호스트 DNS와 IP 주소 사이의 매핑과 호스트는 영구적인 것이 아니기 때문에 DNS 서버는 어떤 기간 이후에

저장된 정보를 제거한다.

 

DNS레코드와 메시지

DNS 분산 데이터베이스를 구현한 DNS 서버들은 호스트 이름을 IP 주소로 매핑하기 위한 

자원 레코드(RR)을 저장한다.

 

자원 레코드는 다음과 같은 필드를 포함하는 4개의 튜플로 되어있다.

(Name, Value, Type, TTL(time to live))

 

1. Type-A - Name은 호스트 이름이고 Value는 호스트 이름에 대한 IP주소
2. Type-NS Name은 도메인이고 Value는 도메인 내부의 호스트에 대한 IP주소
3. Type-CNAME Value는 별칭 호스트 이름 Name에 대한 정식 호스트 이름
4. Type-MX Value는 별칭 호스트 Name을 갖는 메일 서버의 정식 이름

 

 

 

P2P 파일 분배

서버의 역할을 최소화 시켰고 각 피어끼리 통신

 

P2P구조의 확장성

 

클라이언트-서버 구조 분배 시간

서버의 경우 분배 시간은 피어의 수 N에 따라 선형적으로 증가한다.

 

 

p2p 구조 분배 시간

 

둘의 시간 비교

->피어가 비트의 소비자이자 재분배자인 것의 직접적인 결과

 

비트토렌트

파일 분배를 위한 인기 있는 p2p 프로토콜

비트토렌트 용어로 특정 파일의 분배에 참여하는 모든 피어의 모임을 토렌트라고 부른다.

 

토렌트에 참여하는 피어들은 같은 크기의 청크를 다운로드한다.

청크는 쌓을 수 있다.

 

비트토렌트의 동작

1. 트래커라는 인프라스트럭처 노드로 자신이 토렌트에 있음을 알린다.
2. 피어 집합에서 부분 집합을 선택해 이들의 목록을 얻는다.
3. 앨리스는 그 중 갖고있지 않는 청크에 대해 TCP 연결을 요구한다.
4. 청크 요청 결정에서는 rarest first(가장 드문 것 먼저)라는 기술을 사용한다.
5. 어느 요청에 응답할지 결정할때는 현명한 교역 알고리즘을 이용한다.
6. 즉 가장 빠른 속도로 그녀에게 데이터를 제공한 이웃에게 우선순위를 주는 것

 

비디오 스트리밍과 콘텐츠 분배 네트워크

네트워킹 측면에서 비디오의 두드러진 속성

1. 높은 비트 전송률 ex) 4k 스트리밍 -> 10Mbps 이상의 비트 전송률

2. 압축을 사용한 동일한 비디오의 여러 버전 품질 ex) 300kbps, 1 Mbps, 3Mbps 의 속도 비디오 버전

 

 

HTTP 스트리밍 및 DASH

1. 클라이언트 비디오 시청을 원하면 서버에게 TCP연결을 설립하고 배플리케이션 버퍼에 전송된 바이트가 저장된다.

2. 이 버퍼의 바이트 수가 미리 정해진 임곗값을 초과하면 클라이언트 애플리케이션이 재생을 시작한다.

 

-> 클라이언트의 가용 대역폭의 차이에도 불구하고 똑같이 인코딩된 비디오를 전송받는 것은 시간 차이가 발생하는 

문제점이 생기게 되는데 이를 위해 새로운 형태의 HTTP 기반 스트리밍인 DASH가 개발되었다.

 

DASH(Dynamic Adaptive Streaming over HTTP)의 특징

서로 다른 인터넷 접속 회선을 가진 클라이언트들에게 서로 다른 인코딩률을 갖는 비디오를 선택할 수 있도록 허용한다.

DASH를 사용할 때 각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다. 

HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 메니페스트 파일을 갖고 있다.

 

클라이언트가 충분한 분량의 버퍼링된 비디오를 가지고 있고 측정된 수신 대역폭이 클경우

-> 고품질의 비디오 조각 단위 데이터 선택

 

콘텐츠 분배 네트워크(CDN)

다수의 지점에 분산된 서버들을 운영하면, 비디오 및 다른 형태의 웹 콘텐츠 데이터의 복사본을 

분산 서버에 저장한다. 

 

++서버 클러스터

서버 클러스터(server cluster)는 여러 대의 서버를 하나의 시스템처럼 구성하여 고가용성, 성능 향상, 확장성을 제공하는 시스템 구성을 의미합니다.

 

일반적으로 서버의 위치에 대해 다음 두 가지 철학 중 하나를 채용

Enter Deep: 서버 클러스트를 세계 곳곳의 접속 네트워크에 구축함으로써  ISP의 접속 네트워크로 

깊숙이 들어다는 것

 

Bring Home: 핵심 지점에 큰 규모의 서버 클러스트를 구축하여 ISP를 Home으로 가져오는 개념

ISP와 직접 연결된 사용자들에게 데이터 전송을 빠르게 할 수 있습니다.

 

CDN은 콘텐츠 복사본을 클러스트에 저장하는데 모든 비디오의 복사본을 전부 유지할 필요가 없다.

실제로 CDN은 클러스트에 대해 PUSH 방식이 아닌 PULL 방식을 이용한다.

 

CDN 동작

 

클러스트 선택 정책

클라이언트를 동적으로 어떤 서버 클러스트 또는 CDN 데이터 센터로 연결하는 방식

클러스트 정책의 하나로 클라이언트에게 지리적으로 가장 가까운 클러스트 할당

CDN은 주기적으로 클러스터와 클라이언트 간의 지연 및 손실 성능에 대한 실시간 측정 수행

 

소켓 프로그래밍: 네트워크 애플리케이션 생성

TCP, UDP 주요 차이점

 

• TCP: 데이터를 스트림 형태로 전송하며, 데이터가 순서대로 전달되도록 보장합니다. 각 패킷(세그먼트)에 송신자와 수신자의 IP 주소가 포함되어 있어, 전송 중에 패킷의 순서를 관리합니다.

 

• UDP: 데이터를 독립적인 데이터그램으로 전송합니다. 패킷의 순서가 보장되지 않으며, 각 패킷은 독립적으로 처리됩니다. 송신자와 수신자의 IP 주소가 포함되어 있지만, 전송 중에 순서 조정이 없습니다.