CH2_Application Layer(2.1~2.2)

2.1 Principles of Network Applications 

네트워크 애플리케이션은 서로 다른 엔드 시스템에서 실행되는 프로그램이 통신하여 작동하는 구조를 가진다.

 

따라서 개발자는 엔드 시스템에서 작동하는 소프트웨어만 개발하면 된다.

 

ex) 이메일, 웹, 파일전송, 통화, SNS, 유튜브 등.

2.1.1 Network Applications Architectures

client-server architecture

서버 : 항상 켜져있으며 클라이언트의 요청을 처리한다.

클라이언트 : 서버에 요청을 보내고 응답을 받는다.

 

- 서버는 고정된 IP주소를 가지고 있어 클라이언트가 언제든 접근할 수 있다.

- 클라이언트들간의 직접적인 통신은 이루어지지 않고 서버를 통해 이루어진다.

- 관리가 용이하지만, 사용자가 몰리면 부하가 발생할 수 있기에 여러개의 데이터센터를 운영한다.

 

P2P (peer to peer) architecture

여기에는 서버와 클라이언트의 역할을 동시에 수행하는 peer 라는 것이 존재한다.

- peer와 peer가 서버를 거치지 않고 직접 통신한다.(ex . bitTorrent)

- 각 peer가 자체 컴퓨팅 리소스를 활용하여 비용이 적게들고 부하가 발생할 가능성이 적지만, (자기 확장성 good)

  보안, 신뢰, 성능 등의 측면에서 client-server 에 비해 복잡하고 불안정하다.

 

2.1.2 Processes Communicating

프로세스는 실행중인 프로그램을 의미한다.

 

서로 다른 종류의 end system에 있는 프로세서들은 네트워크를 통해 정보를 주고받는다.

 

client-server : 한 프로세스는 서버, 한 프로세서는 클라이언트로 클라이언트가 서버에 요청하면 서버가 답변을 보낸다.

 

P2P : 각 피어가 서버, 클라이언트의 역할을 동시에 수행할 수 있다.

 

socket

다른 프로세스와 통신할 수 있도록 도움을 준다. (소켓을 통해 데이터를 전달하며, 소켓을 통해 데이터를 받는다)

애플리케이션 레벨에서 프로세스 간 정보를 주고받는 인터페이스이며 API (Application Programming Interface)로 제공된다.

 

Addressing Processes

IP 주소

네트워크 상에서 각 호스트는 고유의 IP 주소를 가지고 있다.

이 IP 주소는 32비트 또는 128비트 (IPv6) 크기의 숫자로 이루어져 있고, 인터넷 상에서 호스트를 식별하는 데 사용된다.

포트 번호

IP 주소는 호스트를 식별하지만, 호스트 내에서 여러 프로세스가 동시에 실행되기 때문에 포트 번호를 통해 특정 프로세스를 구분한다.

각 포트 번호는 호스트 내에서 통신하는 프로세스를 식별하는 역할.

ex) 웹 서버는 일반적으로 포트 80을 사용하고, 이메일 서버(SMTP)는 포트를 사용.

 

2.1.3 Transport Services Available to Applications

1. Reliable Data Transfer

- 네트워크에서 손실된 데이터를 복구할 수 있는 능력

- 음성 통화나 영상 스트리밍에서 작은 데이터의 손실은 큰 문제가 되지 않아 여기에 적합할 수 있다.

 

2. Throughput

- 초당 비트 수

- 대역폭 민감 애플리케이션은 일정한 처리량을 요구하는 애플리케이션이며, 예를 들어 멀티미디어 애플리케이션이 이에 해당.

- 탄력적인 애플리케이션은 가용한 대역폭을 최대한 활용하여 더 많은 처리량을 사용할 수 있는 애플리케이션이다.

 

3. Timing

- 데이터를 시간안에 전달할 수 있는 능력

- ex)실시간 애플리케이션

 

4. Security

- 전송 계층은 데이터의 기밀성(Confidentiality)이나 무결성(Integrity) 등을 보장할 수 있다.

  송신 측에서 데이터를 암호화하고, 수신 측에서 이를 복호화하는 방식으로 기밀성을 제공하며,

  전송 중 데이터가 도난당하거나 변조되지 않도록 할 수 있다.

- 이 외에도 전송 계층은 데이터 무결성(전송 중 데이터가 손상되지 않도록 하는 것)과

  종단 인증(송신자가 누구인지 확인하는 절차) 같은 보안 서비스도 제공한다.

 

 

2.1.4 Transport Services Provided by the Internet

 

 

TCP

1. Connection-oriented Service

- 클라이언트와 서버가 통신하기 전에 3-way handshaking을 통해 연결을 설정한다.

- 이는 양방향으로 데이터를 주고받을 수 있는 full-duplex 연결이고, 연결이 완료되어야 데이터 전송이 가능하다.

- 데이터 전송이 끝나면 연결 종료

2. Reliable Date Transfer

- 데이터를 손실없이 전송할 수 있도록 보장한다.

- 데이터가 성공적으로 도착했는지 확인하기 위해 acknowledgment메커니즘을 사용한다.

 

UDP

1. Connectionless Service

- 클라이언트와 서버가 통신할 때 미리 연결을 설정하지 않아 속도가 빠르다.

 

2. Unreliable Data Transfer

- 데이터가 전송되다가 일부 손실될 수 있다.

- 따라서, 데이터의 손실보다 속도가 중요한 곳에서 사용.

 

 

Security

TCP나 UDP는 기본적으로 암호화 기능을 제공하지 않지만, **TLS(Transport Layer Security)**와 같은 프로토콜을 추가로 사용하여 데이터 암호화와 무결성을 보장할 수 있다.

이를 통해 데이터가 전송 중에 중간에서 도청되거나 변조되는 것을 방지할 수 있다.

 

2.1.5 Application-Layer Protocols

애플리케이션 계층 프로토콜은 네트워크 애플리케이션 간 통신 방식을 정의한다.

 

-주요 정의

• 메시지 종류: 요청 메시지(request)와 응답 메시지(response)를 포함

• 메시지 구조: 각 메시지의 필드 형식과 위치를 규정

• 메시지 의미: 각 필드의 의미를 명확히 함.

• 메시지 송신 및 응답 규칙: 언제, 어떻게 메시지를 보내고 응답할지 규칙을 정함.

 

공개 프로토콜

많은 애플리케이션 계층 프로토콜은 RFC (Request for Comments)로 정의되어 공개된다

ex) HTTP(웹 문서 전송을 위한 프로토콜)는 RFC 7230에 정의된 프로토콜

 

비공개 프로토콜

일부 애플리케이션은 프로토콜을 공개하지 않고 자체적으로 사용한다.

ex) Skype는 비공개 애플리케이션 계층 프로토콜을 사용합니다.

 

네트워크 애플리케이션 /

애플리케이션 계층 프로토콜은 전체 애플리케이션의 일부분이다.

• 브라우저: 클라이언트 측의 소프트웨어

• 웹 서버: 요청을 처리하는 서버

• HTML 문서 형식 등: 문서 교환을 위한 표준

• HTTP 프로토콜: 브라우저와 웹 서버 간에 메시지를 교환하는 프로토콜

 

 

2.1.6 Network Applications Covered in this Book

1. Web (HTTP)

2. e-mail (Internet's first killer application)

3. DNS (directory service)

4. Video Streaming ()

5. P2P 

 

---

 

2.2 The Web and HTTP

---

HTTP(HyperText Transfer Protocol)

 

HTTP는 클라이언트가 서버와 메세지를 주고받는 구조를 정의한다.

 

클라이언트가 브라우저에 특정 URL을 요청하면 그 입력은 HTTP클라이언트 요청으로 변환되어 서버에 전달되고

 

서버는 웹페이지나 리소스를 클라이언트에게 보내 클라이언트는 웹페이지를 볼 수 있게 된다.

 

URL

http://www.someSchool.edu/someDepartment/picture.gif

1. hostname : www.someSchool.edu 

2. /someDepartment/picture.gif

 

Stateless Protocol

HTTP는 클라이언트가 보낸 요청을 기억하지 않는다.

메모리 부담은 적지만 기억해야 하는 경우 캐싱, 쿠키나 세션ID를 사용한다.

 

Relation with TCP

HTTP는 TCP위에서 작동한다.

먼저 TCP연결을 설정하고 HTTP를 보낸다.

 

Version 

HTTP/1.0 : 초기 버전으로 각 요청마다 새로운 TCP연결을 설정해야 함.

HTTP/1.1 : Kepp-Alive 기능이 추가되어 하나의 TCP연결을 재사용하여 여러개의 HTTP요청을 처리할 수 있음

HTTP/2 : Multiplexing 기능이 추가됨. 하나의 연결로 여러 요청을 동시에 처리할 수 있음.

 

Security

HTTP는 자체 보안 기능이 없어 TLS를 결합한 HTTPS사용

 

 

2.2.2 Non-Persistent and Persistent Connections

Non-Persistent Connections

1. TCP연결을 설정하고, 클라이언트가 서버에 http요청을 보내고 응답을 받는다.

2. 클라이언트가 요청한 객체(HTML file 등등) 을 서버가 클라이언트에게 전달 후 TCP연결을 종료한다.

3. 클라이언트는  다음 객체를 요청할 때 새로운 TCP연결을 설정하고 다시 요청을 보낸다.

각 객체에 대해 TCP연결을 새로 설정해야 하기 때문에 시간이 오래 걸릴 수 있다.

 

RTT(Rount-Trip time)

클라이언트에서 서버로 작은 패킷을 보내고 서버가 응답하는데 걸리는 시간이다.

Non-persistent connection에서는 각 객체마다 2개의 RTT가 필요 ( 1.TCP연결설정, 2.요청 및 응답 주고받기)

 

Persistent Connections

한 번의 TCP연결로 여러개의 요청 및 응답을 처리할 수 있다.

클라이언트와 서버 사이의 연결이 유지되며 여러개의 객체를 전달할 수 있기에 

non-persistent connection보다 효율적이라고 할 수 있다.

 

2.2.3 HTTP Message Format

HTTP메세지는 ASCII 텍스트로 표현되기 떄문에 사람은 읽을 수 없다.

 

HTTP Request Message

1. Request Line

GET : 요청 방식을 정의한다. 이외에 POST, HEAD, PUT, DELETE등의 다양한 HTTP메서드 존재

/somedir/page.html : 요청하는 리소스의 경로.

HTTP/1.1 : 사용되는 HTTP의 버전 (1.1은 persistent connection 을 지원)

 

2. Header Lines

Host: www.someschool.edu  -> 서버의 도메인 이름. 

Conncetion : close -> 클라이언트가 서버에 요청이 끝나면 TCP연결을 어떻게 해달라고 요청하는 필드

User-agent: Mozilla/5.0 -> 요청을 보낸 브라우저나 클라이언트 프로그램의 정보. 서버는 이를 통해 맞춤형 페이지 제공

Accept-language: fr -> 클라이언트가 선호하는 언어. 서버는 이를 통해 해당 언어로 번역된 서비스 제공

 

3. Blank Line

헤더가 끝났음을 알려준다. 이후 본문이 올 수 있다.

 

4. Entity Body

요청 메서드가 POST일 경우 사용자가 입력한 데이터를 Entity Body에 담아 서버로 전송.

 

---

HTTP Response Message

 

 

1. Status Line

HTTP/1.1 -> HTTP버전

200 OK -> 상태 코드, 200은 요청이 성공적으로 처리되었음을 의미.

• 200 OK: 요청이 성공적으로 완료되었음을 나타냄.

• 301 Moved Permanently: 요청한 리소스가 새로운 URL로 영구적으로 이동되었음을 나타냄

• 400 Bad Request: 서버가 요청을 이해하지 못했거나 요청 형식이 잘못되었음을 의미함

• 404 Not Found: 서버가 요청한 자원을 찾을 수 없음을 나타냄

• 505 HTTP Version Not Supported: 서버가 요청한 HTTP 버전을 지원하지 않음을 의미

 

2. Header Lines

Connection: close -> 클라이언트와 서버간 TCP연결을 종료할 것임을 나타냄

Date: Tue, 18 Aug 2015 15:44:04 GMT -> 날짜와 시간

Server: Apache/2.2.3 (CentOS) -> 응답을 생성한 서버의 SW 정보

Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT -> 해당 리소스가 마지막으로 수정된 날짜와 시간

Content-Length: 6821 -> 응답 본문(HTML)의 길이를 바이트 단위로 나타낸 것

Content-Type: text/html -> 응답 데이터의 유형을 지정. text/html은 HTML문서임을 나타냄

 

3. Blank Line

헤더가 끝났음을 나타내고 이후 Entity Body가 올 수 있다.

 

4. Entity Body

HTML파일의 내용이 담김(실제 콘텐츠)

 

 

 

2.2.4 User-Server Interaction: Cookie

HTTP는 stateless프로토콜이기 때문에 클라이언트의 이전 상태나 행동을 기억하지 않는다.

그래서 쿠키를 사용하여 클라이언트의 상태 정보를 유지한다.

 

-쿠키의 구성 요소

1. 헤더라인

- 서버가 클라이언트에게 보내는 HTTP응답메세지에 포함된 것.

- 클라이언트가 서버에 요청을 보낼 때 포함하는 HTTP요청메세지에 포함된 것.

 

2. 쿠키 파일

- 클라이언트의 브라우저에 저장된 것

 

3. 데이터베이스

- 서버측에서 사용자의 상태정보를 기록하는것

 

-쿠키의 작동방식

1. 사용자가 최초로 접속했을 때 고유 ID를 부여하고 이를 데이터베이스에 저장.

2. 클라이언트는 서버로부터 받은 헤더라인(쿠키포함)을 기반으로 쿠키 파일 저장.

3. 클라이언트가 사이트 재접속시 HTTP요청메세지 헤더에 쿠키정보를 포함하여 서버에 보내고 맞춤형 서비스 제공받음.

4. 서버는 클라이언트로부터 받은 쿠키 정보를 통해 이전의 정보를 불러올 수 있음.

 

-쿠키의 장단점

장점

맞춤형 서비스를 제공받을 수 있음

 

단점

사용자의 행동을 추적할 수 있기에 프라이버시 침해 우려가 있음. 

제 3자 서비스가 쿠키를 통해 사용자의 활동을 추적할 우려가 있음.

 

 

 

 

2.2.5 Web Caching

웹 캐시는 프록시 서버라고도 불리우며,

클라이언트가 웹페이지를 요청할 때 원본서버가 아닌 캐시 서버에서 데이터를 제공할 수 있도록 하는 기술이다.

 

자주 요청되는 데이터를 저장해두고, 해당 요청이 들어왔을 때 캐시에 저장된 데이터를 반환하는 방식이다ㅏ.

 

-동작 과정

1. 클라이언트가 웹페이지나 객체를 요청하면 웹 캐시 서버가 요청을 수신한다.

2.캐시히트-> 캐시 서버는 그 객체의 복사본이 있는지 확인한 뒤 있으면 캐싱된 HTTP응답메세지를 보낸다. 

  -캐시히트는 응답시간이 매우 짧고 네트워크 비용이 거의 들지 않는다.

3.캐시미스-> 만약 객체의 복사본이 없다면, 원본서버에 TCP연결을 하여 데이터를 가져오고 클라이언트에게 전달한다.

  - 캐시미스의 경우 네트워크 지연 시간이 추가되며 캐시 효율이 낮아진다.

 

-캐시의 장점

1. 응답 시간 단축 -> 자주 요청되는 데이터를 복사해두기 때문에 시간을 단축할 수 있다.

2. 네트워크 트래픽 감소 -> 원본서버에 접근하는 횟수를 줄일 수 있기에 트래픽이 감소한다.

3. 대역폭 절감 -> 네트워크에 사용되는 대역폭을 줄여 혼잡도를 완화할 수 있다.

 

-캐시 히트율(Cache Hit Rate)

히트율이 0.6(60%)인 경우 100개의 요청 중 60개는 캐시에서 처리되고 나머지는 원본 서버에서 받아와야 한다는 의미.

 

 

 

2.13에서는 2.12의 트래픽 문제를 캐시로 해결하였다. 

만약 캐시히트율이 0.4 라고 가정한다면 전체요청의 40%가 캐시에서 즉답이 가능하다는 의미이다.

 

CDN(Content Delivery Network)

여러 지리적으로 분산된 캐시 서버를 사용하여 사용자와 가장 가까운 서버에서 콘텐츠를 제공하는 방식.

주로 동영상 스트리밍 서비스, 이미지 제공 서비스, 소프트웨어 다운로드 서비스 등에서 많이 사용됨.

 

-캐싱의 한계

1. 데이터 최신화 문제

  캐시에 복사된 데이터가 오래된 데이터일 수 있음.

  이를 방지하기 위해 조건부GET을 사용하고 서버로부터 최신 데이터를 확인하는 절차 필요.

 

2. 프록시 서버 의존성

  만약 캐시 서버에 문제가 생기는 경우 전체 시스템의 성능이 저하될 수 있음.

  이를 방지하기 위해 HA(고가용성) 구조나 분산 캐시 시스템 구축할 필요 있음

 

3. 콘텐츠 개인화 문제

  캐시는 고정된 콘텐츠에 효과적이다.

  맞춤형 서비스가 필요한 경우 캐싱의 사용이 적합하지 않을 수 있다.

 

 

-조건부GET (Conditional GET)

캐시에 복사된 데이터가 오래된 것인지 확인하기 위한 요청 방식

HTTP클라이언트는 캐시에 있는 객체의 Last-Modified정보를 서버에 전달하고,

서버는 이를 바탕으로 데이터가 변경된 경우 최신화한다.

데이터가 변경되지 않은 경우 304Not Modified 상태 코드를 반환한다.

 

2.2.6 HTTP/2

단일 TCP연결로 요청과 응답을 Multiplexing할수 있다는 특징을 가진다.

 

-목표

- 지연시간 감소 -> 멀티플렉싱으로 시간줄임

- 헤더 필드 압축 -> HTTP헤더를 효율적으로 압축해 전송량 줄임

- 서버 푸시 -> 클라이언트가 요청하기 전에 미리 클라이언트에 푸시 가능

 

-업그레이드하며 해결하고자 했던 것들

- HTTP/1.1에서는 병목현상을 해결하기 위해 여러개의 병렬 TCP연결을 열어 동시에 전송했지만, 서버리소스를 많이 잡아먹었다.

 

- HTTP/2 는 프레임 단위로 데이터를 나누고 멀티플렉싱하여 요청 및 응답을 한꺼번에 처리한다. 

 

 

-프레임 구성 및 데이터 흐름

- 프레임은 HTTP/2 프레이밍 하위 계층에서 처리된다.

 

- 클라이언트는 이를 재조합하여 처리한다. 프레임간 병렬 처리가 가능해 지연시간이 급격히 줄어든다.

 

-HTTP/2의 서버 푸시

클라이언트가 요청하기 전에 서버 푸시 기능을 통해 미리 데이터를 보낼 수 있다.

 

예를 들어, HTML페이지를 요청할 때 해당 페이지에 필요한 이미지나 CSS파일 등을 서버가 미리 보낸다.

이를 통해 추가적인 요청없이 리소스를 미리 받아 웹페이지 로드를 빠르게 할 수 있다.