[네트워크] 3. Application Layer (1)

2.1 네트워크 애플리케이션의 원리

네트워크 애플리케이션 개발의 중심은 다른 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것

라우터나 링크 계층의 스위치와 같이 코어 게층에서 실행되는 소프트웨어를 작성할 필요 없음

→ 인터넷 애플리케이션의 광대하고 빠른 발전의 원동력

 

 

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

• 클라이언트-서버 구조
• P2P 구조
• 클라이언트 - 서버 구조
  • server : 항상 켜져 있는 호스트, 고정 IP주소를 가짐, 하나의 서버로 모든 클라이언트의 요청에 응답할 수 없으므로 주로 데이터센터에 모여있음
  • client : 가끔 혹은 항상 켜져 있음, 이 구조 상에서의 클라이언트는 직접 통신하지 않음
• P2P (Peer To Peer)
  • 서버에 최소한의 의존
  • Peer는 isp가 소유하지 않고, 사용자가 제어하는 데스크탑이거나 랩탑
  • 주요 특징 : 자가 확장성 (self - scalability)= 비용 효율적
  • 각 피어들은 파일을 다른 피어들에게 분배함으로써 그 시스템에 서비스 능력을 추가함

 

 

2.1.2 프로세스 간 통신

 

실제 통신하는 것은 process (종단 시스템에서 실행됨)

메시지 교환을 통한 통신

같은 호스트에서 두 개 이상의 프로세스가 통신할 수도 있음 = IPc (inter-process commmunication)

 

클라이언트와 서버 프로세스

(송신 프로세스) — 메시지를 만들어 네트워크 계층으로 전달 — (수신 프로세스) 응답 메시지를 보냄

• 웹에서는 브라우저-클라이언트, 웹 서버 - 서버
• P2P 파일 공유 시스템에서는 한 프로세스가 서버와 클라이언트 모두 가능함
• (파일 다운 - 클라이언트, 파일 업로드 - 서버)

클라이언트 : 두 프로세스 간 통신 세션에서 통신을 초기화하는 프로세스. 다른 프로세스와 세션을 시작하기 위해 접속을 초기화

서버 : 세션을 시작하기 위해 접속을 기다리는 프로세스

 

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

프로세스는 **소켓(socket)**을 통해 네트워크 계층으로 메시지를 주고 받음

소켓 : 애플리케이션 계층과 트렌스포트 계층의 인터페이스 = API (application programming interface)

소켓 뒤편에 전송 구조가 있음

• 애플리케이션 개발자는 → 소켓의 애플리케이션 계층에 대한 모든 통제권은 갖지만, 소켓의 트렌스포트 계층에 대한 통제권은 거의 갖지 못함
• 애플리케이션 계층과 트렌스포트 계층 모두 소켓 있음ㅇㅇ

 

프로세스 주소 배정

인터넷에서 호스트는 IP주소로 식별됨. 32비트 구성

한 호스트가 많은 네트워크 응용을 수행할 수 있으므로 수신 소켓을 식별하기 위해 목적지 포트 번호를 사용함

(http… 웹 서버의 경우 port : 80, SMTP… 메일 서버의 경우 port : 25)

소켓 페어 (socket pair)

이 네개의 값을 통해 두 프로세스 간 통신을 특정화 할 수 있음

• source ip + source port
• destination ip + destination port

 

 

2.1.3 애플리케이션이 이용 가능한 트랜스포트 서비스

• 신뢰적 데이터 전송 (data integrity)
• 보장된 데이터 전송 서비스를 제공하는 프로토콜 = 신뢰적 데이터 전송 (rdp, tcp)
• 쓰루풋(thoughput, 처리량)멀티미디어와 같은 경우…? minimmum 요구..?
• 네트워크 경로를 따라 두 프로세스 간의 통신 세션에서 송신 프로세스가 수신 프로세스로 비트를 전달할 수 있는 비율
• 시간 timing인터넷 전화, 멀티플레이어 게임과 같은 상호 작용 실시간 애플리케이션에 매력적
• 시간 보장 제공
• 보안 security수신 호스트 → 트랜스포트 프로토콜은 수신 프로세스로 전달하기 전 데이터 암호 해독 가능
• 송신 호스트 → 트렌스포트 프로토콜은 전송하는 모든 데이터를 암호화할 수 있음

→ encryption, data integrity

 

 

 

 

2.1.4 인터넷 전송 프로토콜이 제공하는 서비스

인터넷은 애플리케이션에게 2개의 전송 프로토콜을 제공함 → UDP, TCP

• TCP (Transport Control Protocol)
  • 연결 지향형 서비스 (connection - oriented)
    • 메시지를 전송하기 전, 서로 전송 제어 정보 공유
    • 3-way handshaking
    • 프로세스가 서로에게 동시에 메시지 전송 가능 = full-duplex
  • 신뢰적인 데이터 전송 서비스 (reliable transport)
  • 혼잡 제어 (congestion control)
  • 통신하는 프로세스의 직접적 이득 보다는 전체 성능 향상을 위해 혼잡도 조절
  • flow control
  • 제공하지 않는 것 : 시간, 최소한의 쓰루풋 보장, 보안
• UDP (User Datagram Protocol)
  • best effort service model
  • 비연결형 (connection miss)
  • 비신뢰적인 데이터 전송 서비스 (unreliable data transport)
  • 순서 엉망
  • 혼잡 제어 x
• UDP 사용 이유 : 오버헤드 없고 빠르다
• 수정을 가하지 않은 , vanilla TCP나 UDP는 보안, 즉 암호화를 제공하지 않는다.요즘에 tls를 표준으로 많이 사용2.1.5 애플리케이션 계층 프로토콜이 정의하는 것
  • [format]교환 메시지 타입 (요청 메시지, 응답 메시지 .., )
  • [format]여러 메시지 타입의 문법 (메시지 내부의 필드와 필드 간 구별 방법)
  • [order]필드의 의미, 즉 필드에 있는 정보의 의미
  • [action] 언제, 어떻게 프로세스가 메시지를 전송하고 응답하는지 결정하는 규칙
  2.2 웹과 HTTPHTTP, Hyper Text Transfer Protocol
  • Web page 라고 하는 객체들로 구성
  • 객체(object)는 단순히 단일 URL로 지정할 수 있는 하나의 파일을 뜻함 (html 파일, jpeg 이미지, gif 이미지, 오디오 클립 등)
  • html 파일은 페이지 내부의 다른 객체를 그 객체의 url로 참조함
  • 각 url은 객체를 갖고 있는 서버의 호스트 네임과 객체의 경로 이름을 가짐
• 웹의 애플리케이션 계층 프로토콜 - tcp
• 2.2.1 http 개요
• 트랜스포트 계층이지만 어플리케이션 계층에서 구현하여 전송 전, 키로 암호화함
• → TLS (Transport Layer Security) : 데이터 무결성, 종점 인증 시스템, 암호화된 tcp 연결 제공

사용자가 웹 페이지 요청 → 브라우저가 페이지 내부의 객체에 대한 http 요청 메시지를 전송 → 서버의 요청 수신 , 객체 포함하는 http 응답 메시지 전송

• http 클라이언트는 서버에 tcp 연결 요청 … port 번호 80으로 → 서버의 응답 → 연결되면 브라우저와 서버 프로세스는 각자의 소켓 인퍼페이스를 통해 tcp 접속

클라이언트는 http 요청 메시지를 소켓으로 보내고, 소켓으로부터 http 응답 메시지 받음

http 서버는 소켓으로 요청 메시지 받고 → 응답 메시지 보냄

• http를 비상태 프로토콜이라 함 (stateless protocol)↔ statefull 프로토콜은 복잡함
• 과거 기록 다 저장해야 하고, 중간에 튕기면 그 상태 유지하기 위한 설정 등이 필요함
• 클라이언트에 대한 정보를 유지하지 않음

 

 

2.2.2 비지속 연결과 지속 연결

• 비지속 연결 (non-persistent connection)
  1. http 클라이언트는 http의 기본 포트 번호 80을 통해 어쩌고 서버로 tcp 연결 시도. tcp 연결과 관련하여 클라이언트와 서버 각각에 소켓 있음
  2. http 클라이언트는 1단계에서 설정된 tcp 연결 소켓을 통해 서버로 http 요청 메시지를 보냄. 경로 이름 포함
  3. 연결 소켓을 통해 http 서버는 요청 메시지를 받음, 저장장치로부터 객체 추출, 응답 메시지에 객체 캡슐화, 소켓을 통해 응답 메시지 전송 → tcp에게 연결 끊을 것을 요청 ( 그러나 응답 메시지 와야 끊음)
  4. http 클라이언트가 응답 메시지 받으면 , tcp 연결 종료 → 메시지로부터 파일 추출, 파일 조사하고 객체에 대한 참조 찾음
  • RTT (Round-Trip Time)
  • 패킷이 클라이언트로부터 ~ 서버, 서버로부터 ~ 다시 클라이언트로 가는 왕복 시간
  비지속적인 RTT = 2 RTT + HTML 파일을 서버가 전송하는 시간1 RTT - 객체 요청하고 받기비지속 연결의 단점
  • 각 객체마다 2 rtt 필요
  • 여러 클라이언트의 요청을 동시에 서비스하는 웹 서버에 심각한 부담
  서버는 응답을 보낸 후에 tcp 연결을 그대로 유지한다.객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수 있다일반적으로 http 서버는 일정 기간 (타임아웃 기간) 사용되지 않으면 연결을 닫는다.
• → 파이프라이닝 (pipelining)
• 같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내진다.
• 지속 연결 HTTP (HTTP 1.1)
• 1 RTT - tcp 연결 요청
• 비지속 = 연결이 다른 객체를 위해 유지되지 않는다.

 

 

2.2.3 http 메시지 포맷

• 요청 메시지
• 응답 메시지

아스키코드 텍스트로 쓰여 있어 사람들이 읽을 수 있음

 

http 요청 메시지

첫 줄 : request line (요청 라인)

→ method(방식) 필드 : GET, POST, HEAD, PUT, DELETE… 메서드

• GET : 서버에게 데이터 전송. URL 필드로 식별되는 객체 요청할 때 사용 (?를 따라간다?)
• POST : 요청 메시지의 개체 몸체 - 사용자가 폼을 채워넣을 때 사용함.
• 클라이언트에서 서버로, 웹페이지에서 동작하기 위한 메서드
• HEAD : 헤더 정보 요청할 때 사용
• PUT : 서버에 새 파일(객체) 업로드, 파일 교체… 해커들이 파일 교체, 파일 업데이트, 보내는 명령 수정 가능해서 위험해서 사용을 권고함

→ URL 필드

→ http 버전 필드

나머지 줄 : header line (헤더 라인)

http 메시지의 대부분은 get 방식을 사용한다. 브라우저가 url 필드로 식별되는 객체를 요청할 때 사용된다.

 

http 응답 메시지

상태 라인

→ 버전 필드, 상태 코드, 해당 상태 메시지

헤더 라인

개체 몸체

• 상태 코드 (response status)
  • 200 OK : 요청 성공, 정보가 응답으로 전송됨
  • 301 moved Permanently : 요청 객체의 영원한 이동. 새로운 URL은 응답 메시지의 Location : 헤더에 나와있음. 클라이언트 소프트웨어는 자동으로 새로운 URL 추출함
  • 400 bad request : 서버가 요청을 이해할 수 없다는 일반 오류 코드
  • 404 Not Found : 요청 문서가 서버에 존재하지 않는다.
  • 505 HTTP Version Not Supported : 요청 http 프로토콜 버전을 서버가 지원하지 않는다.

 

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

http 서버의 GET/ response interaction은 상태를 유지하지 않는다.

사용자 식별을 위한 사용, 상태 유지를 위한 사용

4가지 구성요소

1. http 응답 메시지 쿠키 헤더 라인
2. http 요청 메시지 쿠키 헤더 라인
3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
4. 웹 사이트의 백엔드 데이터베이스

웹 서버에 요청이 들어오면 서버는 유일한 식별번호 (IP)를 만들고, 이 식별번호로 인덱스되는 백엔드 데이터베이스 안에 엔트리를 만든다. 그런 후 웹 서버는 브라우저에 응답하는데, 이 http 응답에 식별번호를 담고있는 Set-cookie : 헤더가 포함된다.

브라우저가 http 응답을 받았을 때, Set-cookie의 헤더를 볼 수 있다. 브라우저는 관리하는 특정한 쿠키 파일에 그 라인을 덧붙이고 이 라인은 서버의 호스트 네임과 Set-cookie: 헤더와 식별번호를 포함한다.

서버로의 http 요청은 Cookie : —— 과 같은 헤더 라인을 넣어 요청 메시지를 보낸다.

쿠키 사용 사례 :

• 권한 (authorization)
• 장바구니 유지
• 추천
• 사용자 session state 유지 ( 웹 메일…)

 

 

2.2.5 웹 캐싱 (Web cache), 프록시 서버

 

원 출처의 웹 서버를 대신하여 http 요구를 충족시키는 네트워크 개체

자체적으로 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존

• 네트워크 트래픽과

1. 브라우저는 웹 캐시와 tcp 연결을 설정하고 웹 캐시에 있는 객체에 대한 http 요청을 보냄
2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인.

저장되어 있으면 - 클라이언트 브라우저로 http 응답 메시지 + 객체 전송

저장되어있지 않으면 - 원출처의 서버인 www.어쩌구로 tcp 연결 설정 → 캐시와 서버 간의 tcp 연결로 객체에 대한 http 요청 (이러한 요청을 받으면 기점 서버는 웹 캐시로 http 응답 메시지 + 객체 전송)

1. 웹 캐시가 객체를 수신할 때 객체를 지역 저장장치에 복사하고 → 클라이언트 브라우저에 http 응답 메시지 + 객체 사본을 … 클라이언트 브라우저와 웹 캐시 사이에 설정된 tcp 연결을 통해 전송함

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

 

조건부 GET

웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 새로운 문제 야기 → 객체의 복사본이 새 것이 아닐 수 있음

If-modified-since :

• 304 not modified클라이언트에게 요청 객체의 캐시된 복사본을 사용하라는 의미
• 요청한 객체를 포함하지 않음. - 대역폭 낭비 없음, 사용자의 응답 시간 줄임
• 200 OK - 포함

 

HTTP 1.1

하나의 tcp로 multiple, pipelined GETs

문제 : 서버는 FCFS 방식으로 응답함 (=First Come First Served)

→ 큰 오브젝트 뒤에 들어온 작은 오브젝트는 쓸데없이 기다리는 시간이 길어짐 (HOL blocking. Head Of Line)

→ TCP에서 잃어버린 세그먼트를 재전송함 (손실 회복) … 객체의 전송을 지연시킬 수 있으며 네트워크 효율성에도 영향을 미침

 

 

HTTP 2.0

목표 : 다중 오브젝트의 http 요청 메시지로 인한 딜레이 감소

서버에서 클라이언트로 보내는 메시지에 flexibility를 증가함

→ 요청한 오브젝트를 보내는 순서를 FCFS에 의존하지 않고 클라이언트가 정의한 오브젝트 우선순위에 기반함

→ http1.1에서 매번 요청하고 응답하는 과정이 불필요하다 생각해서 요청하지 않은 오브젝트를 클라이언트한테 그냥 push함

→ 오브젝트를 frame 단위로 쪼갠다. (HOL blocking 문제 완화)

 

 

HTTP 3.0

http2.0 에서는 tcp 연결에 보안 기능이 따로 없음

→ 보안 추가

→ 에러 처리 기능

→ 혼잡 제어 기능 (파이프라이닝 증가) congestion control over UDP (= QUIC)

 

 

2.3 인터넷 전자메일

• 사용자 에이전트 : 사용자가 메시지를 읽고, 응답, 전달, 저장, 구성하게 해줌
• 메일서버 : 전자메일 기반 구조의 중심.
  • 각 수신자는 메일 서버 안에 메일박스(mail box)를 가짐. 메시지 유지 및 관리 역할
• 메시지 큐 : 메일을 보낼 수 없다면, 메시지 큐에 보관해두고 나중에 전달을 위한 재시도 함
• SMTP (Simple Mail Transfer Protocol)
  • 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜
  • TCP의 신뢰적인 데이터 전송 서비스 이용

 

2.3.2 HTTP와의 비교 (RFC)

포트 번호 25, 신뢰적 전송 서비스인 TCP 사용

다이렉트 전송 : 한 메일 서버로부터 다른 메일 서버로 파일(메시지)를 전송

• 전송을 위한 3가지 동작메시지 전송
• 종료
• 핸드쉐이킹 (그리팅)…. tcp 연결 위함
• 커맨드/ response interaction (http와 유사)As;dkfesstatus code and phr
• commands : 아스키코드

→ 메시지는 무조건 아스키코드 7비트여야 함!!

 

 

2.3.3 메일 접속 프로토콜

[SMTP] Simple Mail Transfer Protocol

[IMAP] internet Mail Access protocol

사용자 에이언트 UA는 자신의 메일 서버로 전자메일 메시지를 SMTP를 이요하여 보냄

사용자의 메일 서버는 SMTP(클라이언트)를 사용하여 수신자의 메일 서버로 전자메일 메시지를 중계함

송신자의 UA -(SMTP)→ 송신자의 메일 서버 -(SMTP)→ 송신자의 메일 서버 -(IMAP)→ 수신자의 UA

수신자 에이전트는 메시지를 얻기 위해 SMTP을 사용할 수 없음 (smtp는 push로 동작하는데 메시지를 얻는 건 PULL의 동작으로 이뤄짐)

→ POP3 (post office protocol 3), IMAP, HTTP 와 같은 메일 접속 프로토콜이 있음.

HTTP

구글, 야후, 웹 기반 전자메일의 형태…

여전히 SMTP를 사용하여 메시지를 다른 메일 서버로 전달하거나 다른 메일 서버로부터 수신함