컴퓨터 네트워크 6일차 : 어플리케이션 구조, 소켓, 어플리케이션 레이어 프로토콜, HTTP connection

컴퓨터 네트워크 5일차 : Throughput, Layering, ISP, Network Security

5일차에 이어 지난주 수요일 수업 정리를 해보겠습니다 : )

그후 7일차 수업을 들어야겠네요 ㅎㅎ...

추석부터 바쁜 일상입니다앗 ㅠㅠ

 

---

1. 네트워크 어플리케이션

우리는 다양한 어플리케이션을 사용하고 있습니다.

스마트 폰이나 노트북으로 웹서핑 등 우리는 웹서비스를 이용합니다.

이메일 서비스, 카카오톡과 같은 텍스트 메세징 서비스 등 모두가 네트워킹을 필요로하는 어플리케이션들 입니다.

 

그외에도 유튜브와 같은 스트리밍 비디오 서비스, 원격 접속 등 여러분들이 사용하는 어플리케이션 중에서 네트워킹을 필요로하지 않는 것을 찾는 게 더 어렵습니다.

1-1. writing?

네트워킹 앱을 프로그램에 writing한다는 것은 end system에서 돌아가는 어플리케이션을 만드는 것을 말합니다.

end system은 클라이언트랑 서버를 말합니다. 종단 host라고 말하기도 합니다.

즉, end system = 종단 host = 클라이언트 & 서버

 

웹 서버 소프트웨어는 브라우저 소프트웨어와 커뮤니케이션하면서 동작합니다.

웹 서비스를 개발하는 사람은 서버에서 돌아가는 소프트웨어랑 브라우저에서 돌아가는 소프트웨어를 페어로 개발해야 합니다.

물론 회사에선 영역을 나누겠지만, 두 소프트웨어가 함께있어야 인터워킹하며 동작할 수 있습니다.

 

네트워킹을 필요로하는 어플리케이션을 만들 때 1가지 알아둬야 할 사실은 네트워크 코어 디바이스에 대한 소프트웨어를 만들 필요가 없다는 것입니다. 이것은 지난 시간에 배웠던 레이어링과 관련이 있습니다.

 

end 디바이스는 피지컬레이어, 링크레이어, 네트워크 레이어, 트랜스포트 레이어, 어플리케이션 레이어가 다 동작 합니다. 여기서 네트워킹 회사를 만드는 회사에서는 어플리케이션 레이어만 구현을 하게 됩니다. 어플리케이션 레이어를 구현하기 위해선 트랜스포트 레이어랑 인터페이스를 맞추는 작업 정도는 필요하지만, 실질적인 구현은 어플리케이션 레이어만 구현하면 됩니다.

 

스위치는 중간에 피지컬과 데이터 링크까지 구현된 장비를 말합니다. 즉 L2장비라고 합니다.

라우터는 피지컬, 데이터링크, 네트워크 레이어까지 구현된 장비를 말합니다. 즉, L3장비라고 합니다.

 

이런 이유로 네트워킹 개발자 입장에선 L1~L4까지 구현할 필요가 없습니다. 코어네트워크와 연동하는 기능도 개발할 필요가 없습니다.

개발한 앱이 여러 라우터를 거쳐서 목적지까지 잘 도착합니다. 그러기 위해서 자신이 개발한 애플리케이션이 라우터에서 어떻게 잘 동작하게끔 할지를 고민할 필요가 없습니다. 왜냐하면 라우터에서 일어난 동작은 L1~L3까지만 담당을하고, 그 부분은 이미 표준화된 스펙으로 구현이 되있기 때문입니다.

 

만약에 레이어링이 되어있지않고 네트워크 개발자가 전체 레이어를 통으로 개발하게끔 네트워크 시스템을 설계했다면?

시장에서 L1~L5까지 모두 구현할 줄 아는 개발자는 못구한다고 볼 수 있습니다.

네트워킹을 필요로하는 어플리케이션이 시장에서 확산되는 속도가 굉장히 늦어질 수 밖에 없습니다.

때문에 지난 시간에 배운 레이어링으로 네트워킹 기능을 모듈화하고, 어플리케이션 개발자는 어플리케이션 개발에만 집중할 수 있도록 할 수 있는 것입니다. 즉, 빠른 개발이 가능합니다.

 

 

1-2. 어플리케이션 구조

대표적으로 2가지 구조가 있습니다. 1) client-server 2) peer to peer구조가 있습니다.

 

1) client-server 장점

가장 기본이되는 구조입니다. 네트워킹을 할 때 처음에 서비스를 요청하는 노드(=client)가 존재합니다. 클라이언트로부터 서비스요청을 받고 처리하는 노드(=server)가 필요합니다.

 

 

server(ex. web server)의 가장 큰 특징은 always-on host 입니다. 또한 permanent IP address 즉, 주소가 변하지 않고 유지됩니다.

맛집이 계속 주소지를 바꾸는 경우 손님은 찾아갈 수가 없습니다. 이와 같이 서버도 특별한 사정이 있다면 IP주소를 바꾸기도 하지만, 일반적으로 IP주소가 유지됩니다.

 

인터넷은 국경도 없고, 사용할 수 있는 시간이 제한이 되어있지 않습니다. 때문에 서버로부터 서비스를 24시간 받을 수 있습니다.

 

+plus

수천~수만대 서버를 엮어 데이터 센터를 만듭니다. 구글은 수십억명의 사람들에게 서비스를 제공하는데, 수백만대의 서버들이 데이터 센터로 묶여있기도 하고, 전세계에 퍼져있기도 합니다. (=서버 팜 = 데이터센터)

 

 

client(ex. web browser)는 서버와 커뮤니케이션하는 노드입니다. 간헐적(intermittently)으로 서버에 연결이 됩니다. 여러분들이 네트워크를 간헐적으로 사용한다는 뜻입니다. 또한 기본적으로 동적인 IP주소를 사용합니다.

 

예를 들면, 우리의 집주소가 바뀌어도 맛집을 갈 때 문제가 없습니다. 마찬가지로 클라이언트는 IP주소가 바뀌더라도 바뀐 주소를 알려주기만 하면, 서버와 안전하게 소통이 가능합니다.

 

+plus

네이버, 다음만해도 데이터 센터가 존재하고, 구글, 아마존, 페이스북보다는 스케일이 작지만, 존재합니다.

미국에는 남는 땅이 많아 매입을해 데이터센터 전용 지역을 만듭니다. 구글에선 중부지방에 데이터센터만 깔아두는 곳이 있습니다. 우리나라는 땅이 좁아서 네이버에서 부지 매입하려고 하는데, 많은 충돌이 있었습니다. 전자파가 많이 나온다는 생각을 가지고 있어서 주민들이 반대를 하기 때문입니다.

이렇게 컨테이너는 server rack들로 구성이 되어있습니다. server rack은 slot형태에 서버들을 끼워둔 형태입니다. 컨테이너는 2500개의 서버를 가질 수 있습니다.

 

컨테이너의 서버가 돌아가려면 어마어마한 전기가 필요합니다. 갑자기 정전이 일어나게 된다면, 갑자기 구글을 못쓰게 될 수 있습니다 ㅠㅠ

전력공급에 많은 안정성을 가하기 위해 비상 전력(=power supply)을 운영하는 등으로 힘쓰고 있습니다. 

 

*서버 뻗는 이유*

1) 전원이 부족할 때

2) 과열

 

과열 때문에 굉장히 낮은 온도로 서버를 구성합니다. 이것으로도 부족해서 컨테이너는 물을 활용한 쿨링시스템을 가동하고 있습니다. 또한 에어컨을 통해서 열을 식히는 등 데이터 센터를 운영하고 있습니다.

 

지난 시간에 말했던 ISP에 데이터센터가 물려 있는 것입니다.

 

 

2) peer to peer 장점

no always on server : 항상 켜져있는 서버가 없는 구조입니다.

모든 노드들이 서버이자 동시에 클라이언트가 되는 구조이기 때문입니다.

스카이프와 같은 텔레폰 서비스가 좋은 예인데요. 모든 노드(=peer)들이 함께 커뮤니케이션을 합니다.

peer의 역할은 클라이언트와 서버의 역할을 동시에 수행합니다.

 

P2P 파일 쉐어링을 하게되면 파일을 다운받고, 

 

client-server구조는 server에 컨텐츠가 있는지 물어보고, 있다면 파일을 다운 받습니다.

peer to peer에서는 컨텐츠를 검색하면 그 컨텐츠를 갖고 있는 client(=peer)가 있다면, 분할에서 직접 받게 됩니다.

이 때 원하는 컨텐츠를 peer가 50%씩 가지고 있어서 전달해주게 된다면 전달해주는 peer가 server역할을 하게 됩니다. 받는사람은 client의 역할을 하게 되는 것이죠. 하지만 client의 역할을 했던 사람도 나중에 동일한 컨텐츠를 제공하는 server에 역할도 할 수 있게 됩니다. 즉, 내가 파일을 받음과 동시에 내가 받은 파일을 나누는 역할도 하게 됩니다.

 

이처럼 peer to peer 구조는 항상 켜져있는 서버가 없는 구조이지만, peer가 클라이언트와 서버 구조를 동시에 갖는 구조입니다.

유식하게 self scalability(확장성)라고 하기도 합니다.

 

+plus

자신의 의지와 상관없이 클라이언트와 서버 역할을 하게 됩니다.

만약 '예능 프로그램'과 함께 배포하면 안되는 소설을 껴서 배포하는 서버 역할을 하게 된다면, 저작권 침해죄가 성립되기도 합니다.

 

 

1-3. 서버 확장성

client-server 구조

게임을 위해 서버를 하나 구매했습니다. 하지만 게임이 잘된다면, 서버를 증설할 필요가 있습니다. 계속된 서버 투자를 진행하던 와중 인기가 시들해져서 유저수가 줄었습니다. 서버가 필요 없어집니다. 이런식으로 개발할 때 서버의 스칼라빌리티는 중점으로 다뤄집니다.

 

peer to peer은 스스로 서비스의 용량을 확장시킵니다. 각 peer들은 클라이언트와 서버의 역할을 동시에 수행하기 때문에 peer가 늘어난다는 말은 client가 늘어난다는 것이고, client가 늘어난다는 말은 서비스 수요가 증가한다는 말이기 떄문입니다.

또한 peer가 늘어난다는 말은 서버가 늘어난다는 말도 됩니다. 즉, 스스로 더 많은 유저들을 수용할 수 있는 확장성을 갖추게 됩니다. (=self scalability)

 

대부분의 peer들은 컨텐츠를 받음과 동시에 나가는 경우가 많습니다. 컨텐츠를 받으려고 하는 사람은 많지만, 제공하려고 하는 사람은 peer는 상대적으로 적어 컨텐츠가 peer 간에 잘 퍼지지 않고, 특정 peer들만 서버 역할을 담담하게 되는 상태가 발생하게 됩니다.

 

이처럼 peer to peer는 장점도 있지만, client-server구조에 비해 복잡하다는 점과 특정 peer만 서버를 담당한다는 단점이 있습니다.

 

 

2. Processes

호스트에서 동작되는 프로그램은 프로세스라고 합니다. OS에선 프로세스 간의 커뮤니케이션을 inter process communication이라고 합니다. 동일한 호스트에 있는 여러 개의 프로세스끼리 통신을 말합니다.

 

하지만, 여기에선 동일한 호스트에 있는 프로세스가 아닌 서로 다른 호스트에 있는 프로세스를 이야기 할 겁니다. 이러한 과정을 메세지를 교환하면서 서로 커뮤니케이션을 한다고 말합니다.

 

2-1. 클라이언트/서버 프로세스

client-server

client 역할을 하는 프로세스를 클라이언트 프로세스라고하고, server 역할을 하는 프로세스를 서버 프로세스라고 합니다.

클라이언트는 프로세스를 시작하는 역할을 하고, 서버는 클라이언트로부터 접근을 기다리고 있다고 클라이언트에서 서비스 요청이 오면 그 서비스를 처리하는 프로세스 입니다.

 

2-2. 소켓

프로세스가 서로 네트워킹을 하기 위해 메세지를 주고 받을 겁니다. 그 때 애플리케이션 레이어에서 트랜스포트 레이어로 메세지를 내려줍니다. 내려준 인터페이스를 소켓(socket)이라고 합니다. 어플리케이션 레이어와 트랜스포트 레이어 사이에서 소프트웨어 인터페이스 소켓이 서로 소통할 수 있게 도와주는 역할을 하는 겁니다.

네트워크 프로그래밍을 다른말로 하면 소켓 프로그래밍이라고도 부릅니다. 소켓 프로그래밍을 쓰지 않으면 일반적인 네트워킹을 개발하는 것과 같기 때문입니다. 로컬에서 도는 앱을 만들고 싶다면, 소켓개발하지 않고, 그냥 애플리케이션만 개발하면 된다는 말입니다.

 

즉, 어플리케이션에서 트랜스포트 레이어로 내려보낼 때 소켓인터페이스를 거치게 됩니다.

 

어플리케이션 레이어 말고 나머지 레이어는 OS 제어하고 기능을 제공하지만, 어플리케이션은 앱 개발자에 의해서 제어하고 구현하고 있습니다.

 

애플리케이션 개발자가 OS 제공하는 4계층 기능을 쓰기 위해선 트랜스포트 레이어, 어플리케이션의 인터페이스를 맞춰줘야 합니다. 이 인터페이스를 소켓이라고 하는 겁니다.

 

2-3. 네트워킹의 identifier : IP & PORT NUMBER

수신자가 메세지를 받기 위해선 반드시 유니크한 identifier가 필요합니다. 주소가 유니크하지 않으면, 원하는 목적지로 데이터를 보내지 못합니다. 네트워킹에서도 identifier가 필요합니다.

 

먼저, host를 구분하는 identifier가 필요합니다. host a와 host b는 IP주소로 구분합니다.

문제는 host b에서 돌아가는 프로세스는 여러 개입니다. (카카오톡, 웹 브라우저 등) 소켓인터페이스를 통해서 데이터를 보낼 때 IP주소만 붙여서 보내면 host까지는 잘 찾아가지만, 여러 개의 프로세스 중 어느 프로세스에 이 데이터를 올려보내야할지 구분할 수 없습니다.

아파트 앞까진 가도 몇 동 몇 호까지는 못 찾아가는 격이죠.

 

그렇다면 프로세스를 구분하려면 어떤 identifier가 필요할까요?

바로 port 번호 입니다!

 

어플리케이션 종류에 따라 정해져 있는 포트 번호가 있을 수 있고, 자신이 포트 번호를 정하실 수도 있습니다.

HTTP는 80포트, 메일 서비스는 25번 포트를 쓰게 됩니다.

 

 

3. 어플리케이션 레이어 프로토콜

어플리케이션 레이어에서 어플리케이션 데이터를 전달하기 위해서 사용되는 프로토콜을 어플리케이션 레이어 프로토콜이라고 합니다.

 

3-1. 어플리케이션 레이어 프로토콜이 정의하는 것?

어플리케이션 사이에 교환되는 메세지에 대한 시syntax와 semantics를 정의합니다.

 

syntax : 메세지 안에있는 필드들, 그 필드들이 어떤 방식으로 서술되는지를 정의합니다.

semantics : 필드 안에 정보들이 어떤 의미들을 갖는지를 정의합니다.

 

프로토콜을 정의한다라는 말은 syntax와 semantics를 정의한다라는 말로 봐도 이해가 될 것 같습니다.

어떤 메세지의 포맷을 정의하고 포맷의 기입되는 정보들의 의미를 정의를 하는 것 입니다.

 

어플리케이션 프로토콜에는 다음과 같은 것들이 있습니다.

원격 접속 어플리케이션을 지원하는 Telnet, 파일을 전송하는 것을 지원하는 FTP, 메일 전송을 담당하는 SMTP, 웹 프로토콜 HTTP 등이 있습니다.

 

메세지의 포맷과 메세지 포맷의 의미, 어떤 메세지를 받았을 때 어떤 리액션이 나와야하는지를 구체적으로 정리하는 게 프로토콜 디자인하는 것입니다. 전세계 기구를 통해서 프로토콜을 표준화하고, 표준에 맞게 개발자들이 구현하게 됩니다.

 

 

3-2. 어플리케이션 레이어 프로토콜이 정의하는 것, 자세하게!

 

1) 메세지의 타입을 정의합니다.

: 클라이언트가 서버한테 리퀘스트 메세지를 보낼 수 있습니다. 서버는 리스폰스 메세지를 보낼 수 있습니다. 이러한 메세지 타입들이 정의가 되야 합니다.

 

2) 메세지 syntax

 

3) 메세지 semantics

 

4) 정의된 필드 안에 어떤 정보들이 들어가는, 언제 어떻게 프로세스가 메세지를 보내고 메세지에 반응하는지에 대한 규칙들을 정의합니다.

 

 

3-3. 어플리케이션 레이어 프로토콜의 종류

 

1) open protocols

: 전 세계에 표준화되어 규격화되어 있는 프로토콜을 말합니다. 인터넷과 관련된 프로토콜은 ITF, RFC에서 보통 표준화가 많이 됩니다. 무선 통신과 관련된 것은 WiFi는 IEEE에서 표준화 됩니다. 3G, 4G, 5G는 3GPP 표준화 기구에서 표준화가 됩니다. TCP/IP 등 인터넷과 관련된 프로토콜들은 ITF에서 표준화 합니다. 유선통신과 인터넷은 미국에서 주도, 무선 통신은 유럽에서 주도를 했다는 것을 알 수 있습니다.

 

2) proprietary protocols

proprietary 하다라는 말은 회사에 특화(전용)되었다는 말 입니다. 표준화 기구에 의해서 전세계 전문가들이 서로 합의해서 만든 것이 아닌 회사에서 독자적으로 갖고 싶었던 기술이여서 호환성 같은 거 생각하지 않고, 개발해서 시장을 장악하는 것 입니다. 대표적으로 스카이프 프로토콜이 있습니다.

 

 

4. 어플리케이션 레이어와 트랜스포트 레이어

어플리케이션 레이어가 트랜스포트 레이어에서 받는 서비스가 있습니다. 어플리케이션 레이어에서 트랜스포트 레이어로 전달될 때 헤더가 붙는데, 이 헤더가 바로 트랜스포트가 어플리케이션 레이어에게 주는 서비스 입니다.

 

4-1. 트랜스포트 레이어의 담당 : data integrity와 timing

트랜스포트 레이어에서는 data integrity(무결성)를 보장하느냐 마느냐를 담당합니다.

data integrity(무결성) : 어플리케이션 데이터가 전달되는 과정에 있어서 오류/에러에 의해서 바뀌지 않고 100% 오리지널 데이터 보존되는 것을 이야기 합니다.

 

파일전송, 웹거래(온라인뱅킹) 같은 경우 100% reliable한 상태를 요구합니다. 데이터 1비트도 손실이 나면 안됩니다. (=로스가 나면 안된다) 하지만 속도(timing)에는 민감하지 않습니다.

유튜브, 음성 같은 경우는 데이터가 좀 깨지면, 화질이 안좋아지거나 음성 퀄리티가 나빠질 수 있지만 critical한 것은 아닙니다. 하지만, 반응 속도(timing)에는 민감하겠죠.

외우는 것이 아닌 이해하고 넘어가자!

 

4-2. 트랜스포트 레이어 : 서비스마다 다른 담당

 

1) TCP(ack을 활용한다)

: 100% reliable한 트랜스포트 기능을 제공합니다. 보내는 프로세스와 받는 프로세스 사이에 데이터가 절대로 손실이 발생하지 않도록 보장합니다.  loss가 발생하면 재전송을 해서 완전히 전송될 때 까지 재전송을 합니다. 이런 재전송을 위해 프로토콜이 복잡한 편 입니다.

 

데이터가 잘갔는지 못갔는지 확인을 하려면 커넥션이 필요합니다. 커넥션을 통해서 잘 갔는지 못갔는지 트래킹을 하게 됩니다. (=connection oriented) 클라이언트와 서버 사이에 TCP커넥션을 맺고, 커넥션을 통해서 데이터가 reliable하게 전송하도록 보장합니다.

 

 

 

2) UDP(ack을 활용안한다)

: ack 활용없이 데이터 던져주고 끝나는 간단한 원리 입니다. 커넥션도 따로 맺지 않습니다. 그냥 목적지 ip주소와 포트번호 던지고 끝납니다. 데이터 손실이 나도 추가 조치는 따로 없습니다.(=unreliable)

 

 

4-3. UDP는 왜 존재할까?

기본적으로 complexity가 낮기 때문에 클라이언트와 서버한테 부하가 적습니다. 그리고 처음에 커넥션 셋업이 필요 없기 때문에 바로 데이터를 보낼 수 있어서 초기에 데이터를 보내는 속도가 굉장히 빠릅니다.

 

즉, 적은 데이터를 빨리 보낼 때 좋은 프로토콜 입니다.

그래도 UDP가 항상 빠르다고 단정짓기는 어렵습니다. UDP프로토콜을 너도나도 쓰게되면, 과도한 데이터가 네트워크에 발생해서 오히려 congestion이 늘어날 수 있기 때문입니다.

 

TCP는 reliable한 전송 뿐만 아니라 congestion을 컨트롤하는 기능도 포함이 되어 있습니다. 때문에 네트워크를 좀 더 효율적으로 쓸 수 있습니다. 때문에 90%는 TCP를 사용합니다.

 

 

 

5. 웹과 HTTP

웹 서비스를 네트워킹 할 때 사용하는 프로토콜을 HTTP라고 합니다.

웹 페이지는 여러 개의 오브젝트로 구성이 되어 있습니다. 뼈대를 구성하는 html 파일이 있고, 이미지나 비디오 등도 웹 페이지에 구성하는 오브젝트로 포함이 되어 있습니다.

웹을 다운 받으려면 우선 html을 받고, 다른 부가적인 오브젝트들을 받으면서 최종적으로 페이지가 구성이 됩니다.

 

5-1. URL

각각의 오브젝트는 url로 구분이 됩니다. url은 host name과 오브젝트가 있는 경로의 조합으로 오브젝트가 구분이 됩니다.

 

5-2. HTTP 프로토콜 동작 절차

웹 어플리케이션 레이어 프로토콜은 클라이언트랑 서버로 구성되는 구조가 가장 일반적입니다. 클라이언트에는 기본적으로 웹 브라우저가 설치 되어 있어요. (크롬, 사파리 등) 서버는 다양한 브라우저를 지원하기 위한 아파치 웹 서버를 많이 사용합니다. 

 

웹 클라이언트가 하는 일은 오브젝트를 요청하고, 오브젝트들을 받으면 다시 재구성해서 화면에 띄워주는 역할을 합니다.

웹서버는 웹 클라이언트가 서비스를 요청하면 오브젝트들을 다시 보내주는 역할을 합니다.

리퀘스트를 웹서버로 보내면, 서버는 http 리스폰스를 보내고, 리스폰스에는 html 페이지 등 오브젝트들이 포함이 되어 있습니다.

리스폰스에 포함된 오브젝트 파일들을 갖고 브라우저를 재구성해서 우리에게 보여주는 것입니다.

 

http프로토콜은 트랜스포트 프로토콜로 기본적으로 TCP를 사용합니다. 클라이언트는 항상 TCP 프로토콜을 서버에 먼저 맺습니다. 포트번호를 지정해줘야하는데, 포트번호 같은 경우 웹서버는 80포트를 사용하게 됩니다.

 

즉, TCP 프로토콜을 서버와 맺고(커넥션), 80포트를 통해 http 리퀘스트를 날립니다. 그럼 서버는 TCP 커넥션을 accept하고, TCP커넥션을 통해 http 메세지를 브라우저와 웹서버 사이에서 주고받고 합니다. 내가 원하는 오브젝트를 다 받았다면, 추가적으로 받을 데이터가 없다면 TCP커넥션을 close합니다.

 

 

5-3. HTTP : stateless

http는 상태를 기억하지 않습니다. 여러 클라이언트로부터 http 리퀘스트가 오면, 서버는 그냥 리퀘스트에 대한 리스폰스를 보내고 서버 역할을 끝냅니다. 리퀘스트가 누구한테 왔는지 상태들을 저장하지 않는다는 것을 의미합니다.

ex ) 주인이 단골을 대하는 태도는 기억을 하고 있기 때문... 하지만 사람이 너무 많다면 기억은 너무 어렵습니다.

 

이와같이 HTTP도 수천~수만개의 리퀘스트가 오기 때문에 state를 관리하는게 서버에 부담을 줄 수 있기 때문에 리퀘스트를 메세지를 보고, 그거에 대한 리스폰스가 수동적으로 처리하는거지 각 리퀘스트에 대한 상태정보를 기억하지 않겠다는 말입니다. 이는 서버에 부담을 줄이는 좋은 방안입니다.

 

 

5-3. HTTP connection

웹 페이지를 구성하기 위해서 html 텍스트 파일과 html이 참조하고 있는 이미지가 10개가 있다고 가정해봅시다.

이를 다 받아야지 1개의 웹페이지를 띄울 수 있는 것이죠.

유저가 먼저 url을 입력하면, HTTP 클라이언트가 HTTP 서버에다가 TCP 커넥션을 연결을 요청합니다.

그러면 서버가 80포트로 오는 요청을 받습니다.

accept하게되면 클라이언트에게 메세지가 가고, 클라이언트는 "내 TCP 요청을 수락했군(=내 리퀘스트를 받을 준비가 되었군)"이라고 인식합니다.

 

그 후, TCP 커넥션 소켓을 보내 데이터를 전송하게 됩니다.리퀘스트 메세지에는 클라이언트가 받고자 하는 오브젝트(html 파일 정보)가 포함되어 있습니다.

 

http서버는 리퀘스트를 받습니다. 클라이언트가 요청한 오브젝트를 포함한 리스폰스 메세지를 만들어 소켓을 통해 클라이언트에게 전달해줍니다.

 

정보 전달이 끝나면, 오브젝트 1개 받으면, tcp 커넥션을 닫습니다.

클라이언트는 리스폰스 메세지를 받고, 지금까지 동작을 반복하며 10개의 오브젝트를 받습니다.

 

Q. 웹페이지를 구성할 때 많은 스텝이 발생하는 곳은 어딜까요?

TCP 연결을 열고 닫는데, 많이 할애가 됩니다. 오브젝트를 받는 갯수가 많아질수록 TCP프로토콜을 열고 닫고해야하기 때문에 너무 느려진다는 뜻 입니다. HTTP프로토콜을 통해 오브젝트를 받을 때의 지연을 분석해보면, 다음과 같은 time 그래프가 나옵니다.

라우터 트립 타임(RTT) : 아주 작은 메세지를 클라이언트에서 서버까지 보내고, 서버에서 클라이언트로 보내는 시간(=1RTT)

 

아주 작은 메세지이기 때문에 transmission delay는 거의 없습니다. 다만, propagation delay가 영향이 큽니다.

리스폰스 메세지는 기본적으로 오브젝트가 포함이 되어 있습니다. 때문에 transmission delay가 포함이 됩니다.

 

즉, 걸리는 시간은 

커넥션 맺을 때 1RTT + 리퀘스트 & 리스폰스 보낼 때 1RTT + 오브젝트 전달할 때 걸리는 Transmission delay가 발생합니다.

=2RTT + Transmission delay

 

그 후, 서버는 커넥션은 1개의 오브젝트를 받고 연결을 끊습니다.

 

---

빨간날은 역시 집중이 힘드네요 ㅎㅎ...

겨우겨우 하나 작성해봅니다!

화이팅!