[네트워크] 애플리케이션 계층 1 - TCP, UDP, HTTP, Pipeline, Web Cache, Proxy Server, Conditional GET

 

Network

네트워크는 프로그램이라고 할 수 있습니다.

다른 프로그램과의 차이점이 있다면 “통신 기능"이 하나 더 있다는 것입니다.

 

IP & Port

Client 측 프로세스가 Server 측 프로세스에게 메시지를 전달하기 위해서는 해당 Server를 가리키는 IP address와 해당하는 프로세스의 주소인 port가 필요합니다.

 

IP address

IP address는 네트워크 상에 존재하는 특정 머신을 지칭하기 위한 주소를 의미합니다.

 

Port

IP가 특정 머신을 지칭한다면 Port는 머신 내 원하는 프로세스의 주소를 의미합니다.

 

 

 

 

---

네트워크가 제공해주는 통신 기능

Data Integrity :

• TCP를 통해서 신뢰성 있는 데이터만 제공해줍니다.

 

네트워크 비제공 기능

• Timing
• ThroughPut
• Security

애플리케이션 계층에 속하는 프로그램 상에서 기능을 구현해야 합니다.

 

 

 

TCP Service (TCP가 제공해주는 기능)

Reliable Transport

• 신뢰성 있는 데이터를 보장해줍니다.

Flow Control

• 메시지를 빠른속도로 보내는데 Receiver의 능력치에 맞게 보내는 속도를 조절해줍니다.

Congestion Control

• 네트워크 상황에 맞게 보내는 속도 조절합니다.

Flow Control & Congestion Control

• 네트워크 상황 혹은 수신자(Receiver) 중 안좋은 상황에 맞춰서 데이터를 전송합니다.

 

 

UDP

• 메모리, CPU 점유율이 적어 비용이 작은 것 뿐이 없습니다.

 

 

 

 

---

HTTP 란?

Hyper Text Transfer Protocol로

• Hyper Text : 링크, 이미지를 의미
• Transfer : 전송
• Protocol : 규칙

을 의미합니다.

• HTTP Request, HTTP Response
• TCP를 이용합니다.
• 서버 프로세스 80번이 기본 할당되어 있습니다.

 

HTTP Stateless (무상태)

• TCP는 상대방에 대해 기억하지만, HTTP는 기억하지 않는다.

 

Persistent HTTP

• Request, Response를 재사용한다.
• 즉, TCP 하나만 만들어 계속 사용한다.
• Http PipeLining (HTTP1.1로 스펙 업그레이드 하면서 생김)

 

 

 

HTTP PipeLining 이란 ?

• reference 받을 때 request, response 하나씩은 비효율적이라 HTTP1.1에서 생겼습니다.
• Pipeline을 사용하면 패킷이 줄줄이 붙어 보내집니다.
• propagation이 한번만 들어 더 이득입니다. (queueing delay는 무시한 상태)

 

 

 

Non-Persistent HTTP

• 한번 사용할 때마다 TCP를 새로 만든다.
• 계속해서 TCP를 생성해야 하므로 비용이 Persistent HTTP 보다 더 듭니다.

 

 

 

HTTP request message

아래 내용은 간단하게 넘어가겠습니다.

request line - GET /index.html HTTP/1.1\\r\\n
header lines - HOST: ~~~~~~~~~~~~~~
               ~~~~~~~~~~~~~~~~~~~~

 

 

HTTP request message : general format

 

 

HTTP response message

• 아래에 있는 실제 데이터 ‘ data data data data data data ‘가 data requested HTML file 입니다

status line  - HTTP/1.1 200 OK\\r\\n
header lines - Data: ~~~~~~~~~~~~~~~~~~~~~~
               Server: ~~~~~~~~~~~~~~~~~~~~
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
실제 데이터     - data data data data data data data data data data data 

 

 

HTTP response status codes

200 OK
400 BAD ...

---

 

 

Cookie

HTTP는 Stateless하다. 그래도 기억이 필요할 때 cookie를 사용한다.

• Client가 평소처럼 http request message를 Server에게 보낸다
• Server는 해당 Client를 위한 고유 아이디를 만들어서 DB에 넣는다.
• 그리고 다시 http response message에 set-cookie와 함께 Client에게 보낸다
• Client는 이제 고유 아이디를 갖고 있고 일주일 후에 Server에 접근하여 해당 고유 아이디를 가지고 DB에 접근하여 관련된 데이터를 http response message에 담아서 Client에게 보낸다.

 

 

 

 

 

 

---

Web Cache (Proxy Server)

Client가 멀리 있는 Origin Server까지 가지 않고 Proxy Server의 Web Caches 파일에 접근하여 원하는 파일을 받아오는 기술

 

 

Web Cache 과정

• Client가 Proxy Server에 접근해 Caches File이 있는지 봅니다.
• caches가 있으면 Proxy Server에서 데이터를 받아옵니다.
• caches가 없다면 Proxy Server는 Origin Server로부터 데이터를 요청하여 받습니다.
  • 받은 데이터는 Proxy Server에 저장됩니다.
  • Client에게 데이터를 전달합니다.

즉, 최초의 Client가 아니면 Proxy Server에서 정보를 받아올 수 있습니다.

 

 

 

Web Cache 장점

Response Time 단축

• 요청-응답 시간을 단축시켜줍니다.
  • Client가 요청한 데이터를 가져오기 위해 Origin Server아닌 더 가까운 Proxy Server에서 정보를 가져오기 때문입니다.

 

Server Traffic 감소

• Client의 request가 전부 Server로 가지 않고 Proxy Server로 분산되어 Traffic이 감소됩니다.

 

 

 

 

Web Cache 예시

1. Web Cache를 사용하지 않는 경우

 

아래와 같이 가정한 상태 입니다.

avg object size : 100K bits
avg request rate (Client To Origin Server): 15/sec
// RTT (Round Trip Time) : 패킷망에서 상대측 호스트까지 패킷이 왕복하는 시간
RTT (Institutional Network To Origin Server) : 2sec
access link rate : 1.54 Mbps

• Client 에서 Origin Server까지 15개 Object를 request한다.
• Object Size가 100K bits 이기에
• avg data size = 15 * 100K bits = 1,500K bits = 1.5Mbits

Institutional network가 Origin Server에 1.54Mbps의 access link로 연결되어 있습니다.

 

Institutional network는 1Gbps의 LAN이 깔렸을 때 1.5Mbps를 이용하여 데이터를 전달하고 있습니다.

 

이 때 access link에서는 1.54Mbps이니 1.5Mbps를 보내면 대역폭(bandwidth)이 거의 다 사용되고 있으므로 delay 시간이 크게 발생합니다.

 

1.54Mbps / 1.5Mbps = 0.97.. 이니 1에 매우 가깝습니다.

1에 가까울수록 delay 시간은 급격히 늘어납니다.

 

즉, 총 delay를 계산하면 다음과 같습니다.

Total Delay = RTT + access delay + (1.5Mbps/1Gbps)

이러한 경우 Web Cache를 사용해보면 다음과 같습니다.

 

 

 

2. Web Cache를 사용하는 경우

 

 

위와 같은 상황으로 가정하겠습니다.

avg object size : 100K bits
avg request rate (Client To Origin Server): 15/sec
// RTT (Round Trip Time) : 패킷망에서 상대측 호스트까지 패킷이 왕복하는 시간
RTT (Institutional Network To Origin Server) : 2sec
access link rate : 1.54 Mbps
avg data rate : 1.5 Mbps
// hit rate : request 데이터가 web cache에 있으면 hit라 한다
hit rate : 0.4

 

hit rate가 40% 일 때는

access link 통과하는 데이터는 원래 데이터의 60%만 지나간다라는 의미입니다.

 

즉 위에서 계산했던 access delay는 다음과 같이 변합니다.

access delay = 1.5 Mbps * 0.6 / 1.54Mbps = 0.52...

0.97… → 0.52… 로 변경되며 delay가 감소 됐음을 알 수 있습니다.

 

결국 Total Delay도 변하게 됩니다.

Total Delay = RTT * 0.6 + 0.52... + (0.9Mbps/1Gbps)

 

 

 

Web Cache - Conditional GET

Cache를 사용하다보면 Consistence 문제가 생길 수 있습니다.

 

Origin Server에는 Client의 정보가 최신화 되어 있는데 Proxy Server는 그렇지 않아 정보가 다를 수 있습니다.

 

이런 일관성 문제를 해결하기 위해 Conditional GET이 있습니다.

 

Conditional GET

• if-modified-since <date> 와 같이 Client 측에서 date 이후 수정이 있었는지 Proxy Server측에서 비교해서 다를시 Server에서 데이터를 가져옵니다.