1. network application

1.1 network application 정의

네트워크 어플리케이션 : 서로 다른 종단시스켐(osi 7계층을 모두 만족하는 시스템. 즉 host)에서 동작하며, 네트워크를 통해 통신한다.

ex) 웹 서버와 웹 브라우저 간 소통

1.2 application과 network core

• application은 network core(router, switch)를 고려할 필요가 없다.

• application이 동작하는 동안 network core devices는 동작하지 않기 때문.

1.3 네트워크 어플리케이션 구조

네트워크 어플리케이션의 구조에는 하단과 같이 client-server, P2P 구조의 2가지가 존재한다.

1.3.1 client-server 구조

server : 항상 켜져 있는 호스트이며, 고정된 IP 주소를 갖고 있다. 한 서버 호스트가 클라이언트로의 모든 요청에 응답하는 것은 불가능하므로 data center가 강력한 가상의 서버를 생성하는 데 흔히 이용된다.

client : server와 소통하는 호스트이며 간헐적으로 서버와 연결될 수 있다. 서버와는 다르게 유동적인 IP 주소를 가질 수 있으며, 클라이언트들끼리 직접적인 소통이 불가하다.

1.3.2 P2P 구조

P2P : 는 서버에 최소한으로 의존하거나 전혀 의존하지 않는다. 서버에 의존하는 대신 application은 peer라는 간헐적으로 연결된 호스트들이 서로 직접 통신하도록 한다. 특정 서버를 통하지 않고 peer끼리 통신하므로 이를 peer to peer(P2P)구조라고 한다.

1.4 프로세스

OS에서 실제로 통신하는 것은 프로세스이다.

process : host에서 실행되는 프로그램이다. 프로그램의 인스턴스라고 표현하기도 한다.

1.4.1 같은 host의 프로세스 간 통신

• 같은 컴퓨터 상에서 process들끼리 통신하기 위해 OS가 system call이라는 인터페이스를 만들어 process끼리 통신함.

• 이를 통해 같은 컴퓨터 내의 process들끼리 inter process communication(IPC)를 할 수 있다.

• 실제로 IPC를 실행하는 모델에는 message passing과 shared memory방식이 있다고 한다.

1.4.2 다른 host의 프로세스 간 통신

• 서로 다른 호스트들 사이에서 프로세스 간 통신을 하려면, 먼저 상대 소켓의 주소가 필요하다.

• 프로세스가 메세지를 주고 받기 위해서는 그 프로세스의 소켓을 이용한다.

  socket : 데이터를 내보내거나 받는 창구. application process와 transport protocol의 인터페이스 역할을 해 api라고도 볼 수 있다.

• 방금 전 언급한 같은 호스트의 프로세스 간 통신에서는 process들끼리 통신하기 위해 system call이라는 인터페이스를 os에서 구축해 놓았다면, 다른 호스트의 프로세스 간 통신에서는 socket이라는 인터페이스를 구축한다.

• socket의 주소를 이용해 다른 호스트의 프로세스 간에 데이터를 주고받는다. 상대의 socket주소로 메세지를 주고받음(message interchange)으로써 통신을 할 수 있는 것이다.

• 프로세스의 역할로 client와 server를 구분 지을 수 있는데, client는 두 프로세스 간의 통신 세션에서 통신을 초기화하는 프로세스이고, server는 세션을 시작하기 위해 접속을 기다리는 프로세스를 말한다.

1.4.3 프로세스의 주소 배정

1.4.2에서 상대 process와 통신을 하기 위해서는 상대 프로세스의 주소가 필요하다고 했는데, 이 주소가 바로 IP address와 port number이다.

• IP address : 네트워크 환경에서 컴퓨터(노드)간 통신하기 위해 각 컴퓨터에 부여된 네트워크 상 주소. 호스트를 식별함.
• port number : 한 컴퓨터 내에서 특정 process를 지칭한다. 한 컴퓨터 내에서 프로세스마다 고유한 포트 넘버를 가지기 때문에 port number로 process를 구분한다.

ex) 우리가 네이버에 접속하고자 할 때 -> 네이버라는 웹 서버가 돌고 있는 프로세스의 소켓 주소를 입력해야 한다.
=> www.naver.com : DNS라는 system에 의해 IP로 변환
=> default로 포트 넘버 80이 입력

결과 : www.naver.com의 ip와 포트 넘버 80으로 네이버에 접속 성공!

1.5 application에서 원하는 transport layer에서의 기능

1. data integrity(신뢰적 데이터 전송)

2. throughput(처리량)

3. timing(시간)

4. security(보안)

<실제로 transport layer에서는 data integrity만 보장한다. 나머지는 application level에서 해결해야 한다.>

2. 여러 application protocol

3. HTTP

5.1 웹과 HTTP

HTTP : Hypertext(HTML) Transfer Protocol의 약자로, 웹의 application layer protocol이며, 클라이언트와 서버가 서로 HTTP 메시지를 교환해 통신함.

• client : 웹의 객체들을 요청하고, 받고, 전시하는 브라우저

• server : 웹 서버가 요청받은 객체를 response에 담아 보낸다.

1) 웹 페이지는 객체들로 구성되며, 이 객체들은 HTML 파일이나 JPEG 이미지, 오디오 파일 등이 될 수 있다.
웹 페이지는 여러 개의 참조된 객체들을 포함하는 base HTML-file로 구성된다.
이 때, 각 객체는 url로 주소를 지정할 수 있다.

2) http는 port번호 80을 이용하며, tcp로 서버와 클라이언트를 연결한다. 또, http는 stateless, 즉 이전의 history가 현재 영향을 끼치지 않는다.

3) HTTP에서 클라이언트와 서버의 상호작용이 TCP 상에서 발생할 때, TCP request와 TCP response가 같은 TCP 연결을 통하는가와 분리된 다른 TCP 연결을 통하는지에 따라 persistent HTTP인지, non-persistent HTTP인지가 구별된다.

5.2 non persistent HTTP(비지속 HTTP)

가정 ) 웹 페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되어 있고, 총 11개의 객체가 같은 서버 내에 있다고 가정하자.

연결 수행 과정은?

1) 사용자에게 웹 페이지를 보여주기 위해 HTTP 클라이언트는 HTTP의 default port number 80을 통해 연결하고자 하는 웹 서버의 주소로 TCP connection을 시도한다.

2) HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓으로 url을 이용해 서버로 HTTP 요청 메시지를 보낸다.

3) HTTP 서버는 1단계에서 설정된 TCP 연결 소켓을 통해 요청 메시지를 받고, response에 요청받은 객체를 캡슐화해 클라이언트로 보낸다.

4) HTTP서버는 TCP의 연결을 끊을 준비를 마친다(실제로 HTTP 클라이언트가 메시지를 받을 때까지 연결 끊지 않음)

5) HTTP 클라이언트가 response message를 받으면 TCP연결이 해제된다. 이 response message에는 HTML 파일이 들어 있어 파일 내에 있는 10개의 JPEG 객체에 대한 참조를 찾는다.

6) 참조되는 각 JPEG 객체에 대해 이 단계를 반복한다.

위의 상황에서의 non-persistent response time은 11 * (2RTT + transfer time)이다.

non-persistent에서 한 객체 당 response time은 tcp연결요청 - tcp 연결 수락(TCP connection initiate)의 1RTT와 객체 1개 request - response로 1RTT, 실제 파일이 이동하는 transfer time까지 합쳐서 2RTT + transfer time이 소요.

따라서 non-persistent에서 한 객체 당 response time이 2RTT + transmission time이 걸리기 때문에 총 11개의 객체가 존재하는 위 예시에는 11 * (2RTT + transfer time)이 걸리게 되는 것이다.

RTT : Round Trip Time의 약자로, 한 패킷이 클라이언트에서 서버로 갔다가 다시 되돌아오는 데 걸리는 시간을 의미한다.

5.3 persistent HTTP(지속 HTTP)

가정 ) 웹 페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되어 있고, 총 11개의 객체가 같은 서버 내에 있다고 가정하자.

연결 수행 과정은?

persistent한 HTTP는 모든 객체를 받을 때까지 TCP연결이 유지됨.

1) 사용자에게 웹 페이지를 보여주기 위해 HTTP 클라이언트는 HTTP의 default port number 80을 통해 연결하고자 하는 웹 서버의 주소로 TCP connection을 시도한다.

2) HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓으로 url을 이용해 서버로 HTTP 요청 메시지를 보낸다.

3) HTTP 서버는 1단계에서 설정된 TCP 연결 소켓을 통해 요청 메시지를 받고, response에 요청받은 객체를 캡슐화해 클라이언트로 보낸다.

4) HTTP 클라이언트가 response message를 받는데, 이 response message에는 HTML 파일이 들어 있어 파일 내에 있는 10개의 JPEG 객체에 대한 참조를 찾는다.

5) 받은 파일의 모든 참조 객체에 대해 각각 객체를 request하고 response하는 것을 반복한다.

6) 모든 객체를 받았으면 TCP 연결을 해제한다.

위의 상황에서의 persistent response time은 11 * (1RTT + transfer time) + 1RTT이다.

persistent에서 제일 처음 TCP 연결을 제외하고 한 객체 당 response time은 객체 1개 request - response로 1RTT, 실제 파일이 이동하는 transfer time까지 합쳐서 1RTT + transfer time이 소요.

따라서 persistent HTTP에서 한 객체 당 response time이 1RTT + transmission time이 걸리고, 객체를 제일 처음 전송할 때 TCP connection을 해야 하기 때문에 1RTT가 소요되기 때문에 총 11개의 객체가 존재하는 위 예시에는 11 * (1RTT + transfer time) + 1RTT이 걸리게 되는 것이다.