20180410 2 : Application Layer, http protocol

네트워크란, 사실 프로그램을 동작시키는 프로세스이다. 메세지를 교환한다는 특징이 있으며, 송수신을 한다는 것

Client - Server Architecture
서버는 항상 켜져 있으며, 고정된 주소가 있다. 클라이언트가 서버에 접속(접근)할 수 있도록. 클라이언트는 고정된 주소를 가질 필요가 없다. 

OS 내부에 프로세스들이 많다.

프로세스들 사이에 메시지 교환이 필요하다.

IPC (Inter Process Communication) 이 마련되어 있다. 

IPC (Inter Process Communication)

프로세스는 완전히 독립된 실행객체입니다. 서로 독립되어 있다는 것은 다른 프로세스의 영향을 받지 않는다는 장점이 있다. 그러나 독립되어 있기 때문에 별도의 설비가 없이는 서로 간에 통신이 어렵다는 문제가 있으며, 이를 위해 커널 영역에서는 IPC라는 내부 프로세스간 통신(Inter Process Communication)을 제공하고 프로세스는 커널이 제공하는 IPC 설비를 이용하여 프로세스간 통신이 가능한 것이다.

네트워크는 다른 머신과의 메시지 교환이다. 결국 OS 가 마련해준 인터페이스 "소켓" 을 통해서 다른 머신과의 통신이 가능하며 다른 머신과의 통신을 위해서는 아래와 같은 내용들이 필요하다.

(1) IP : Internet Protocol

(2) port number

IP 주소와 더불어 해당 머신 내의 특정한 프로세스를 이용하기 위해서는 더불어 PORT 번호가 필요하다.

예시)

(1) 우리가 주소 창에 www.naver.com 를 친다.

(2) 해당 호스트 네임이 DNS 라는 서비스를 통해 해당 www.naver.com 이 IP 주소로 변경된다.

(3) 웹 서버의 포트 번호는 기본적으로 80번 포트로 약속되어 있다. 

- 특정 프로토콜은 특정한 포트번호로 설정되어 있다.

사용자 입장에서 소켓을 통해 메시지를 내려받을 때, 원하는 요구사항

(1) 빨리 도착했으면 하는 것 : timing
(2) 기밀 및 보안성 : security

(3) 데이터 무결성 : data integrity

...

현재의 인터넷은 어떤 사용자에 대한 특정한 요구사항을 시행하지 않으며 다만, data integrity (데이터 무결성) 에 대해서 해당 패킷이 목적지까지 유실되지 않고 도달하도록 도와줄 뿐이다.

그 외의 요구사항에 대해서는 애플리케이션 계층에서 구현하여야 한다.

따라서 네트워크를 사용하는 입장에서는 네트워크가 어떤 서비스를 제공해주어야 알고 그 밖에 이슈들에 대해서는 대책을 마련해야 한다.

TCP / UDP

TCP

reliable transport : 유실되지 않고 감

flow control : 수신 호스트에 대해서 속도를 조절

congestion control : 네트워크 상황에 맞게 속도를 조절

connection-oriented

UDP

아무것도 해주지 않는다. 값이 싸다.

HTTP overview

- Hypertext Transport Protocol

- 메세지 종류가 딱 두가지로 존재.

request & response 

- TCP 를 사용한다. (신뢰성 있는 문서전달을 위해서)
- 80번 포트를 사용 (웹서버)

- stateless protocol, 상대방의 상태에 대해서 정보를 저장하지 않는다.

- TCP 를 재사용하느냐 ? TCP 를 새롭게 생성하느냐?
persistent HTTP vs non-persistent HTTP

Non-persistent HTTP

http request 를 보내기 위해선 TCP 가 존재하여야 한다. 커넥션을 만들어주어야 한다.

실제로 http request message 는 TCP connection 이후에 존재한다. 그리고 해당하는 object 를 response 받고 TCP connection 은 끊기며 다시 해당 리소스를 들고 오기 위해서 TCP connection 을 반복한다.

Persistent HTTP

한번 TCP connection 이 존재하면 다시 재사용한다. 

Sample problem

persistent HTTP 를 이용하였을 때 end to end delay 는 얼마인가?

- Control message = K bit long (TCP hadnshake, HTTP request) 

- Base HTML object = L bits

- N reference objects, each L bit long

- Link bandwidth = R bps

- Propagation delay = d seconds

>> 4(K/R + d) + N(K/R + d + K/R + d)

N reference objects 에 대해서 매번 송수신을 해야하는 문제점이 발생. 한꺼번에 request 를 보내고 한꺼번에 response 를 받는 방식이 더 효율적이지 않을까?

pipelined 을 하게 되면 N 개의 request 가 한꺼번에 가므로 propagation delay 를 줄일 수 있다.

TCP, UDP  헤더필드가 매우 중요

User-server state : cookie

Web caches (proxy server)

웹 프록시 혹은 웹 캐시, 프록시 서버.

사용자와 서버 중간에 위치하여 사용자가 요청한 리퀘스트에 대해서 서버에게 대신 전달하는 역할. 서버로부터 가져온 오브젝트를 보관하고 있다가 다른 클라이언트의 요청 시 해당 서버로 요청하지 않고 스스로 가져온 파일을 전달한다.

(1) delay 가 적다. 빠르다.

(2) server side 입장에서 부하가 덜하다.
(3) ISP 에 붙은 갑 관계의 통신사에 대해서 특정 회선 사용이 덜 하기 때문에 비용이 덜 소모.. 트래픽이 외부로 빠져나가지 않는다.

웹 캐시, 웹 프록시가 무조건 답일까?

실 서버에 대해 리소스가 변경된다거나 버전이 바뀐경우 데이터의 일관성이 떨어진다. 사용자는 이전 내용을 확인할 수 있는 문제가 생긴다. 하지만 HTTP 프로토콜은 캐시가 가진 데이터가 최선버전인지 확인할 수 있는 메커니즘을 가지고 있다. 이 메커니즘을 Conditional Get 이라고 부른다. 클라이언트가 request message 를 보낼 때 수정되었던 마지막 날짜를 보내고, 수정되지 않았다면 수정되지 않음을 response message 로 보낸다.

Conditional Get

Conditional Get 은 웹 캐시, 프록시 서버가 사용한다. 클라이언트에게 요청온 데이터가 최신버전인지에 대해서 실서버에게 요청하고 응답받는다.

Chaching

주어진 리소스의 복사본을 저장하고 요청 시에 그것을 대신 전달해주는 기능이다. 웹 캐시가 자신의 스토어에 해당 요청 리소스를 가지고 있다면, 요청을 가로채 원래의 서버로부터 리소스를 다시 다운로드하지 않고 대신 자신이 가지고 있는 리소스의 복사본을 리턴하는 것이다. 하지만, 모든 리소스들이 항상 동일한 상태로 유지되는 것이 아니기 때문에 캐시는 알맞게 구성되어야 한다. 

[ 참고동영상 ]

[ 컴퓨터 네트워크 ]

정리 )

• 네트워크란
• IPC (Inter Process Communication) 이란
• 웹서버 기본 포트 번호는 무엇인가
• TCP 의 특징 (간략히)
• http protocol 의 특징 (간략히)
• persistent HTTP 개념
• Non-persistent HTTP 개념
• Web Caches (Proxy Server) 개념
• Web Caches (Proxy Server) 를 사용함으로 인해서 단점은
• Conditional GET 이란 무엇인가