[컴퓨터 네트워킹]2장 애플리케이션 정리 - 1

2장 애플리케이션 계층
2.1 네트워크 애플리케이션의 원리

2.1.1네트워크 애플리케이션 구조
클라이언트-서버구조(client-server architecture)
항상 켜져 있는 호스트(서버, 서비스 제공자)와 서비스 사용자(클라이언트)의 상호작용으로 이루어진 구조
데이터 센터 : 많은 요청을 처리하기 위한 많은 수의 서버를 가진 서버

P2P(peer to peer) 구조
피어간의 상호 통신을 통해 이루어지는 구조
피어(peer) : 간헐적으로 연결된 호스트
- 각 피어는 클라이언트이며 서버의 역할을 수행한다.
- 자기 확장성을 가진다.
- 비용 효율적이다.
- 보안, 성능, 신뢰성의 약점

2.1.2 프로세스 간 통신

2개의 다른 종단 시스템(다른 os)에서 프로세스는 컴튜터 네트워크를 통한 메시지 교환으로 통신한다.

클라이언트와 서버 프로세스
- 두 프로세스 간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버라고 한다. 프로세스와 컴퓨터 네트워크 사이의 인터페이스
소켓(socket)을 통하여 네트워크로 메시지를 주고 받는다.
애플리케이션 계층에서 통제 가능 권한
1) 트랜스포트 프로토콜 선택
2) 최대 버퍼와 최대 세그먼트 크기와 같은 약간의 트랜스포트 계층 매개변수의 설정

프로세스 주소 배정
메시지를 전송하기 위해서 호스트를 식별할 주소가 필요
IP address : 호스트를 식별하는 고유한 주소
Port : 장치안에서 프로세스를 식별하는 번호

2.1.3 애플리케이션이 이용 가능한 트랜스포트 서비스
트랜스포트 프로토콜을 선택할 때 고려하는 사항
1. 신뢰적 데이터 전송(=데이터 무결성) : 패킷의 손실을 감당할 수 있는가?
2. 처리량(throughput) : 네트워크 경로를 따라 두 프로세스 간의 통신 세션에서 송신 프로세스가 수신 프로세스로 비트를 전달할 수 있는 비율
인터넷 전화와 같은 서비스는 지속적인 처리량을 요구 -> 대역폭 민감 애플리케이션(bandwidth-sensitive application)
전자메일, 파일전송은 지속적인 처리량이 필수적이지 않음 -> 탄력적 애플리케이션(elastic application)
3. 시간 : 상호작용이 중요한 앱(인터넷 전화, 화상회의, 대화형 게임)을 효과적으로 실행하기 위해서 낮은 지연이 필요
4. 보안 (암호화)

2.1.4 인터넷 전송 프로토콜이 제공하는 서비스
- TCP 서비스
연결지향형 서비스 : 핸드세이킹 과정(3way handshake, 4way handshake)
전이중 연결
신뢰적인 데이터 전송
혼잡제어
- UDP 서비스
비연결형 서비스
비교적 빠른 데이터 전송 2.1.5 애플리케이션 계층 프로토콜
프로토콜 정의 내용
1. 교환 메시지 타입(ex) 요청 메시지와 응답 메시지)
2. 여러 메시지 타입의 문법(ex) 메시지 내부의 필드와 필드 간의 구별 방법)
3. 필드의 의미, 즉 필드에 있는 정보의 의미
4. 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙 2.2 웹과 HTTP
2.2.1 HTTP 개요
웹페이지(web page 문서라고도 한다) : 객체들로 구성된다.
객체(object) : 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML, JPEG, GIF, 자바 애플릿)
웹 브라우저 : HTTP의 클라이언트 측을 구현
웹 서버 : URL로 각각을 지정할 수 있는 웹 객체를 소유 2.2.2 비지속 연결과 지속연결
RTT(round-trip-time) : 작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 데 걸리는 시간
비지속연결 : 각 요구/응답 쌍이 분리된 TCP 연결을 통해서 보내지는 방법, 하나의 요청을 할때마다 3way/4way handshake 과정을 반복하는 방법
지속연결 : 모든 요구와 해당하는 응답들이 같은 TCP연결을 통해 보내지는 방법

비지속연결

지속연결

지속연결 without pipe

지속연결 with pipe

2.2.3 HTTP 메시지 포멧
+carriage return (CR '\r') : 커서의 위치를 앞으로 이동
+line feed (LF '\n') : 현재 위치에서 바로 아래로 이동

HTTP 요청 메시지
1. ASCII 텍스트
2. 각 줄은 CR과 LF로 구별
3. HTTP 요청 메시지의 첫 줄은 요청 라인(request line)이라 부르고, 이후 줄 들은 헤더 라인(header line)이라고 부른다.
+ 요청 라인은 3개의 필드 '방식(method)필드', 'URL 필드', 'HTTP 버전 필드'로 구성된다.

=> 방식필드 종류(GET, POST, HEAD, PUT, DELETE)
GET 방식 : 브라우저가 URL 필드로 식별되는 객체를 요청
POST 방식 : HTTP 클라이언트는 사용자가 폼(ex : 사용자가 검색 엔진에 검색 단어를 넣을 때)을 채워 넣을 때 사용
HEAD 방식 : GET 방식과 유사, 서버가 HEAD 방식을 가진 요청을 받으면 HTTP 메시지로 응답하는데, 요청 객체를 보내지 않는다.
PUT 방식 : 웹 서버에 업로드할 객체를 필요로 하는 애플리케이션에 의해 사용
DELETE 방식 : 사용자 또는 애플리케이션이 웹 서버에 있는 객체를 지우는 것을 허용

HTTP 응답 메시지
HTTP 응답은 상태 라인, 헤더 라인, 개체 몸체로 구성되어있다.

--> 상세한 내용은 다음 블로그 글 참조 : https://miaow-miaow.tistory.com/181

2.2.4 사용자와 서버 간의 상호작용 : 쿠키

웹사이트는 쿠키를 이용하여 사용자의 상태를 추적하고 유지

- 4가지 구성요소
1. HTTP 응답 메시지의 쿠키 헤더 라인(cookie header line)
2. HTTP 요청 메시지의 쿠키 헤더 라인(cookie header line)
3. 사용자의 호스트에 저장되어 관리되는 쿠키 파일(cookie file)
4. 웹사이트의 백엔드 데이터베이스(back end database)

2.2.5 웹 캐싱
웹 캐시(web cache; 프록시 서버 proxy server)
-> 웹 서버를 대신하여 HTTP 요구를 충족시키는 네트워크 개체
자체로 디스크 저장 공간을 가지고 있으며, 최근에 요청된 객체들의 복사본을 저장하고 있다.
사용자가 느끼는 응답시간을 줄이기 위하여 설치

조건부 GET (복사된 객체가 갱신되었을 경우를 고려한 것 : if-modified-since 헤더 라인 사용)
--> 객체의 갱신여부를 확인하고 호스트에게 요청된 객체를 갱신하여 전달하는 것

2.3 인터넷 전자메일
2.3.1 SMTP

2.3.2 HTTP와의 비교
공통점
한 호스트에서 다른 호스트로 파일을 전송하는데 이용
파일 전송 시 지속 연결 사용

차이점
HTTP
- pull protocol (방향 : client -> server)
- 포맷 요구 없음
- HTTP 응답 메시지에 각 객체를 캡슐화
SMTP
- push protocol (방향 : server -> client)
- ASCII포맷 요구(각 메시지의 몸체를 포함하여)
- 텍스트와 이미지를 캡슐화하지 않고 한 메시지로 포함하여 생성

2.3.3 메일 메시지 포맷
From : hostA@mail.com \r\n
To : hostB@mail.com \r\n
Subject : SMTP message format example. \r\n
\r\n
message body(ASCII)

모든 헤더는 From : 헤더라인과 To : 헤더라인을 반드시 가져야한다.

2.3.4 메일 접속 프로토콜

POP3(post office protocol -version3)
- 구현이 쉽고 많은 클라이언트에서 지원
- 서버에서 이메일 수신하면 로컬에 저장(무조건 이메일 전체가 다운로드)을 하고 서버에서 메일 삭제
- 비동기화 방식

IMAP(internet mail access protocol)
- 다양한 특성을 갖지만 매우 복잡
- 사용자가 메시지의 구성요소를 얻을 수 있게 허용하는 명령을 가짐(부분 저장)

+웹 기반 전자메일(HTTP)
메일 서버와 사용자 에이전트간의 통신을 HTTP 사용
메일 서버 간의 메시지 교환은 SMTP 사용

2.4 DNS 인터넷의 디렉터리 서비스
호스트 식별자 -> 호스트 네임, IP주소

2.4.1 DNS가 제공하는 서비스
DNS (domain name system)
- DNS 서버들의 계층구조로 구현된 분산 데이터베이스
- 호스트가 분산 데이터베이스로 질의 하도록 허락하는 애플리케이션 계층 프로토콜

서비스
1. 호스트 네임을 IP주소로 변환해주는 디렉터리 서비스

2. 호스트 엘리어싱(host aliasing) : DNS는 호스트의 IP 주소뿐만 아니라 제시한 별칭 호스트 네임에 대한 정식 호스트 네임을 얻기위해 이용될 수 있다.

3. 메일 서버 엘리어싱(mail server aliasing) : 제공된 별칭 호스트 네임에 대한 정식 호스트 네임을 얻기위해 메일 애플리케이션에 의해 수행된다.

4. 부하 분산 (load distribution) : cnn.com 과 같은 인기 있는 사이트는 여러 서버에 중복되어 있어서,
각 서버가 다른 종단 시스템에서 수행되고 다른 IP주소를 갖는다.
중복 웹 서버의 경우, 여러 IP 주소가 하나의 정식 호스트 네임과 연관되어 있다.
DNS 데이터 베이스는 이 IP 주소 집합을 갖고 있다.
클라이언트가 주소 집합으로 매핑하는 호스트 네임에 대한 DNS 질의를 하면,
서버는 IP 주소 집합 전체를 가지고 응답한다.
이때 각 응답에서의 주소는 순환식으로 보낸다.

2.4.2 DNS 동작 원리 개요
분산 계층 데이터 베이스

DNS 동작 과정
- Local(hosts) -> DNS cashe table -> DNS server
- 위 과정에서 없다면 최상위(root domain) -> top level domain -> subdomain 순으로 IP를 찾음

DNS 서버 종류
- 루트 DNS 서버 :
- 최상위 레벨 도메인(TLD) 서버
- 책임 DNS 서버

DNS 질의 유형
1. 재귀적 질의(Recursive query) : 상대 네임서버에게 자신을 대신하여 원하는 도메인의 데이터를 인테넷에서 조회하여 응답
2. 반복적 질의(Interactive query) : 루트 네임서버로부터 도메인의 트리형태 계층구조를 따라 순차적으로 반복하여 진행하는 질의

2.4.3 DNS 레코드와 메시지
RR(resource records) 자원 레코드
(Name, Value, Type, TTL(time to live)) 의 4개의 투플(tuple)로 구성

Type필드에 따른 Value 필드의 의미
type A : 호스트 네임에 대한 IP주소
type NS : 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 아는 책임 DNS 서버의 호스트 네임
type CNAME : 별칭 호스트네임(name 필드)에 대한 정식 호스트 네임
type MX : 별칭 호스트 네임을 갖는 메일 서버의 정식 이름

DNS 메시지

헤더 영역 : 12byte로 구성, 식별자, 플래그, 질문의 수, 답변 RR의 수, 책임 RR의 수, 추가 RR의 수에 대한 정보를 포함
질문 영역 : 현재 질의에 대한 정보를 포함
답변 영역 : 원래 질의된 이름에 대한 자원레코드를 포함
책임 영역 : 다른 책임 서버의 레코드를 포함
추가 영역 : 다른 도움이 되는 레코드를 포함