[네트워크] Network | Addressing Process, Application-layer protocol, TCP & UDP, HTTP overview

 

특정 목적지로 우편 메일을 보내기 위해서는 목적지가 주소를 갖고 있어야 한다. 마찬가지로 호스트상에서 수행되고 있는 프로세스가 패킷을 다른 호스트에서 수행되고 있는 프로세스로 패킷을 보내기 위해서는 수신 프로세스가 주소를 갖고 있을 필요가 있다. 이때 두 가지의 정보가 필요한데, 호스트의 주소와 그 목적지 호스트 내의 수신 프로세스를 명시하는 식별자가 필요하다. 

 인터넷에서 호스트는 IP 주소르 식별된다. 하지만 호스트의 주소를 아는 것 뿐만 아니라 수신 호스트에서 수행되고 있는 수신 프로세스도 식별해야 한다. 목적지 포트 번호 (Port Number) 가 이 목적을 위해서 사용된다. 예를 들어 웹 서버는 포트 번호 80번으로 식별된다. SMTP 프로토콜을 사용하는 메일 서버 포트 번호는 25번으로 식별된다. 

 

 

 

애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다.

1. 교환 메시지 타입

2. 여러 메시지 타입의 문법

3. 필드의 의미 (정보의 의미)

4. 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙

 

여러 애플리케이션 계층 프로토콜은 RFC에 명시되어 있으므로 공중 도메인에서 찾을 수 있다. HTTP는 RFC로 얻을 수 있다. 만약 브라우저 개발자가 HTTP RFC의 규칙을 따른다면, 브라우저는 HTTP RFC의 규칙을 따른 어떠한 웹 서버로부터도 웹 페이지를 가져올 수 있다.

 

네트워크 애플리케이션과 애플리케이션 계층 프로토콜을 구별하는 것은 중요하다. 애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐이다. 예시를 들자면, 웹 사용자가 필요에 따라 웹 서버로부터 '문서'를 얻게 해 주는 네크워크 애플리케이션이다. 웹은 HTML, 웹 브라우저, 웹 서버, 애플리케이션 계층 프로토콜을 포함하는 여러 요소들로 구성된다. 웹 애플리케이션 계층 프로토콜 HTTP는 브라우저와  웹 서버 사이에서 교환되는 메시지의 포맷과 순서를 정의한다.

 

 

Data integrity (신뢰적 데이터 전송)

 

패킷은 라우터의 버퍼에서 Overflow되거나 패킷의 비트가 잘못되면 호스트에 의해서 버려질 수 있다. 따라서 데이터가 올바르고 완전히 다른 애플리케이션에 전달되도록 보장하기 위해 조치를 취해야 한다. 만약 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 이를 신뢰적 데이터 전송을 제공한다고 한다. 만약 트랜스포트 계층 프로토콜이 신뢰적 데이터 전송을 제공하지 않을 때 데이터가 수신 프로세스에 전혀 도착하지 않을 수 있다. 이를 손실 허용 어플리케이션 (Loss-Tolerant Application) 이라고 한다. 이의 예시로 실시간 오디오, 비디오가 있다.

 

Throughput (처리량)

 

처리율이란 네트워크 경로를 따라 두 프로세스 간의 통신 세션에서 송신 프로세스가 수신 프로세스로 비트를 전달할 수 있는 비율을 나타낸다. 다른 세션들이 대역폭을 공유하기 때문에 가용한 처리율은 시간에 따라 변동한다. 그렇기 때문에 서비스로 애플리케이션은 보장된 처리율을 요구할 수 있다. 

 대욕폭 민감 애플리케이션들이 특정 처리율 요구사항을 갖고 있는 반면에 융퉁성 있는 애플리케이션은 가용한 처리율을 많으면 많은 대로 적으면 적은 대로 이용할 수 있다. 그 예로 전자 메일, 파일 전송, 웹 전송이 있다.

 

Timing (시간)

 

트랜스포트 계층 프로토콜은 시간 보장을 제공할 수 있다. 처리율 보장과 마찬가지로 시간 보정은 여러 가지 형태로 나타난다. 한 가지 예는 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 100msec 내에 도착하도록 하는 것이다. 이러한 서비스는 게임과 같은 상호 데이터 전송에 엄격한 시간 제한 조건을 요구한다.

 

Secuirty (보안)

 

송신 호스트에서 트랜스포트 프로토콜은 송신 프로세스가 전송하는 모든 데이터를 암호화할 수 있고 수신 호스트에서 트랜스포트 프로토콜은 그 데이터를 수신 프로세스로 전달하기 전에 데이터의 암호를 해독할 수 있다.

 

 

인터넷이 제공하는 애플리케이션 지원 유형을 살펴보자. 인터넷은 애플리케이션에게 2개의 전송 프로토콜, UDP와 TCP를 제공한다. 개발자로서 새로운 인터넷 애플리케이션을 만들 때 첫 번째 결정해야 하는 것 중의 하나는 UDP 혹은 TCP 중 어느 것을 사용할 지를 결정하는 것이다.

 

 

TCP 서비스 모델

: 연결지향형 서비스와 신뢰적인 데이터 전송 서비스를 포함한다.

 

- 연결지향형 서비스

: 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하도록 한다. (Hand Shaking 과정)

- 신뢰적인 데이터 전송 서비스

: 통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존한다. 또한 TCP 혼잡 제어 방식이란 것이 있는 데 이는 네트워크가 혼잡 상태에 이르면 프로세스 속도를 낮추는 기능을 갖고 있다.

 

UDP 서비스

: 최소의 서비스 모델을 가진 간단한 전송 프로토콜이다. 

 

- 비연결형이므로 두 프로세스가 통신하기 전에 Hand Shaking을 하지 않는다.

- 비신뢰적 데이터 전송서비스를 제공한다.

- 혼잡 제어 방식을 포함하지 않는다. 따라서 UDP의 송신 측은 데이터를 원하는 속도로 하위 계층으로 보낼 수 있다.

 

 

 

전자 메일, 원격 터미널 접속, 웹, 파일 전송 모두 TCP를 사용하고 있음을 볼 수 있다. 이 애플리케이션들은 TCP가 모든 데이터가 궁극적으로 목적지에 도착하도록 보장하는 신뢰적 데이터 전송 서비스를 제공하기 때문에 주로 TCP를 선택했다. 인터넷 전화 응용 (Skype) 은 보통 패킷 손실을 허용하지만 효율성을 위해 최소의 전송속도를 필요로 하기 때문에, 인터넷 전화 응용 개발자들은 UDP 상에서 자신들의 응용을 수행하기를 선호한다. 또한 표에서 Streaming audio/video는 모두 Real time 이 아닌 이미 업로드가 완료된 데이터를 의미한다.

 

 

www.someschool.edu는  는 호스트 네임이고 그 뒤는 경로 이름이다. 웹 브라우저 (크롬, 파이어폭스)는 HTTP의 클라이언트 측을 구현하기 때문에 웹의 관점에서 브라우저와 클라이언트라는 용어를 혼용하여 사용할 수도 있다. HTTP의 서버 측을 구현하는 웹 서버는 URL로 각각을 지정할 수 있는 웹 객체를 갖고 있다.

 

 

 

웹의 애플리케이션 계층 프로토콜인 HTTP는 웹의 중심이다. HTTP는 두 가지 프로그램으로 구현된다. 클라이언트 프로그램과 서버 프로그램. 서로 다른 종단 시스템에서 수행되는 클라이언트 프로그램과 서버 프로그램은 서로 HTTP 메시지를 교환하여 통신한다.

 

 

 

HTTP 는 TCP 전송 프로토콜을 사용한다. HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작한다. 일단 연결이 이루어지려면 브라우저와 서버 프로세스는 그들의 소켓 인터페이스를 통해 TCP로 접속한다. 클라이언트는 HTTP의 요청 메시지를 소켓 인터페이스로 보내고 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다. 마찬가지로 HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보낸다.

 서버가 클라이언트에게 요청 파일을 보낼 때, 서버는 클라이언트에 관한 어떠한 상태 정보도 저장하지 않는다는 것을 기억해야 한다. 만약 특정 클라이언트가 몇 초 후에 같은 객체를 두 번 요청한다면, 기존의 객체를 기억하지 않고 동일한 것을 두 번 보낸다는 것이다. 정리하자면 HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로 HTTP를 Stateless Protocol 이라고 한다.

 

 

 

 

클라이언트-서버 상호 작용이 TCP 상에서 발생할 때 애플리케이션 개발자는 중요한 결정을 할 필요가 있다. 분리된 TCP 연결을 통해 보내져야 하는가? 혹은 모든 요구와 해당하는 응답들이 같은 TCP 연결상으로 보내져야 하는가? 전자의 경우 비지속성 연결(Non-persistent) 이라고 하고 후자의 경우 지속 연결(Persistent) 라고 한다. 

 

 

 

 

1. HTTP 클라이언트는 HTTP의 기본 포트 번호 80을 통해 서버로 TCP 연결을 시도한다. 

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

3. HTTP 서버는 1단계에서 설정된 소켓을 통해 요청 메시지를 받는다. 또한 객체를 추출하여 응답 메시지에 캡슐화한다.

 

 

 

4. HTTP 서버는 TCP 연결을 끊는다. (실제로 TCP 클라이언트가 응답 메시지를 올바로 받을 때까지 연결을 끊지 않는다)

5. HTTP 클라이언트가 응답 메시지를 받으면, TCP 연결이 중단된다.

6. 그 이후 참조되는 JPEG 객체에 대하여 처음 4 단계를 반복한다.

 

 

 

클라이언트가 기본 HTML 파일을 요청하고 그 파일이 클라이언트로 수신될 때까지의 시간을 측정해보자. 이를 위해서 작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 데 걸리는 시간인 RTT를 정의한다. RTT는 전파지연, 패킷 큐잉 지연, 패킷 처리 지연 등을 포함하는 시간이다. 그래서 총 응답 시간은 2RTT와 HTML 파일을 서버가 전송하는 데 걸리는 시간을 더한 것이다.

 

 

비지속 연결은 몇 가지 단점을 가지고 있다. 첫 번째로 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다. TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 한다. 둘째로 각 객체는 2 RTT를 필요로 한다. TCP 연결 설정에서 1RTT, 객체를 요청하고 받는데 1RTT.

 

하지만 지속 연결에서 서버는 응답을 보낸 후 TCP 연결을 그대로 유지한다. 이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들어질 수  있다. (Pipelining 이라고 한다) HTTP의 디폴트 모드는 파이프라이닝을 이용한 지속 연결을 사용한다.

 

 

 

 

TCP 연결을 위해서 2RTT가 소요되고 Object을 요청하고 받는데 2RTT가 소요된다. 하지만 Parallel 하지 않기 때문에 8개의 Object에 대해서 각각 2RTT가 소요되므로 총 Elapse는 18X가 된다.

 

5개의 연결에 대해서 Parallel 하게 작동하므로 10개의 Object에 대해서 총 2번의 2RTT가 소요된다. 그러므로 총 Elapse는 6X가 된다.

 

 

Pipeline 이라는 것은 한 번의 Request로 모든 Object를 response할 수 있다는 것을 의미한다.측 TCP 연결 설정을 하는데 2RTT가 소요되고 8개의 Object를 받는데 1RTT가 걸린다. 그러므로 총  3RTT가 소요된다.

 

Pipeline하지 않는 Persistent한 Connection의 경우, 하나의 Object에 대해 1RTT가 소요되고 총 8개의 Object에 대해서는 8RTT가 소요된다. 그러므로 총 Elapsed Time은 10X가 된다.

 

 

HTTP 요청 메시지의 첫 줄은 Request Line이라고 부르고 그 이후의 줄들은 Header Line이라고 부른다. Request Line은 3 개의 필드로 구성되어 있다. Method 필드, URL 필드,  HTTP 버전 필드를 갖는다. Method 필드는 GET, POST, HEAD, PUT 등 다양한 값을 가질 수 있지만 HTTP 메시지의 대부분은 GET 방식을 사용한다. GET 방식은 브라우저가 URL 필드로 식별되는 객체를 요청할 때 사용된다. 위 사진에서는 /index.html Object를 요청하고 있다. 또한 HTTP/1.1 버전을 구현하고 있음을 알 수 있다.

 

헤더 라인 Host:www.someschool.edu는 객체가 존재하는 호스트를 명시하고 있다. User-agent 라는 것은 서버에게 요청하는 브라우저 타입을 명시하고 있다.