컴퓨터 네트워크 7일차 : HTTP 프로토콜, 쿠키, 웹캐시, 이메일, DNS

 

 

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

추석 연휴에도 좋은 강의를 진행해주신 교수님...

오늘도 열심히 열강해보았습니다 ^_^

 

---

1. HTTP 프로토콜

HTTP 프로토콜 사용할 때 이슈가 존재합니다. 2RTT와 트랜스미션 딜레이가 오브젝트 하나 받을 때마다 발생한다는 점인데요. 심지어 웹페이지를 받을 때 1개의 오브젝트 뿐만 아니라 많은 오브젝트를 받아 1개의 웹페이지를 완성하기 때문에 너무 많은 지연이 발생할 수 있다는 문제가 있습니다.

 

그래서 이런 문제를 해결하기 위한 솔루션으로 TCP에서는 TCP 커넥션을 하나만 여는 것이 아닌 여러 개를 병렬로 여는 방식을 사용합니다. 보통 5~10개의 TCP 커넥션을 동시에 열어서 한 번에 오브젝트를 여는 것 입니다. 순차적으로 받으면 오래걸리기 때문입니다.

 

 

1-1. TCP CONNECTION

 

1) non-persistent HTTP : 오브젝트 1개 받고 닫고~

오브젝트 하나 받고서 커넥션을 바로 끊는 방식 입니다. 하나의 오브젝트는 TCP 커넥션마다 최대 1개를 받을 수 있게 하는 것 입니다. 때문에 2RTT+transmsion delay가 하나의 오브젝트마다 이뤄지게 됩니다. 오브젝트들을 여러 개 받으니까 TCP 커넥션을 바로 닫지말고 열어두어 재활용하자는 것이 아래 나오는 persistent HTTP입니다.

 

2) persistent HTTP : 오브젝트 계속 들어오니까 일정 시간 열어두자~

현재 디폴트로 사용되고 있는 형식 입니다. 서버가 HTTP 리스폰스 중에는 연속적인 HTTP 메세지가 클라이언트와 서버사이에 발생할 수 있기 때문에 클라이언트가 오브젝트를 받자마자 참조된 오브젝튿르을 계속적으로 받을 수 있으니까 TCP 커넥션을 남겨두자고 하는 것 입니다. 그렇다고, 무한정 남겨두면 안되는 것이 서버 입장에서 TCP 커넥션을 남겨두는 것은 서버와 클라이언트의 리소스를 잡아먹는 것이기 때문입니다. 지금도 얼마나 남겨둘 것인지는 많은 연구가 진행되고 있다고 합니다.

 

 

1-2. HTTP request message

HTTP request message는 기본적으로 2가지 타입이 있습니다. 아래 1) 2)와 같습니다.

 

1) request type (과제로도 낼 예정 / 원서 131~136 참조)

: 아스키코드 형태로 human-readable한 형태로 제시가 됩니다.

request 라인에는 GET메소드가 주로 쓰이는데, get 메소드는 오브젝트를 얻을 때 쓰는 메소드로 일반적으로 많이 쓰입니다.

여러 호스트에 대한 부가적인 정보들은 header lines에 포함됩니다.

 

2) response type

 

 

1-3. Method types

1) HTTP 1.0 버전

HTTP 1.0 버전에서는 GET/POST 방식이 존재합니다.

POST : 서버의 인풋을 업데이트할 때, 객체를 갱신할 때 사용합니다.

HEAD : 서버한테 어떤 오브젝트를 요청하는 게 아니라 오브젝트가 없는 리스폰스만 요청할 때 사용하는 메소드 입니다. 서버 상태를 확인하거나 디버깅할 때 사용합니다.

 

2) HTTP 1.1 버전

GET/POST/HEAD메소드를 포함해 PUT/DELETE메소드가 포함이 되었습니다.

PUT : 단순히 input 넣는 걸 넘어서서 파일을 업로드 하는 기능을 제공합니다. 클라이언트가 서버에다가 파일을 제공하는 것입니다. 객체의 추가나 업로드를 제공하는 것을 이 메소드에서 합니다.

DELETE : 서버에 파일에 있는 클라이언트가 삭제할 수 있도록하는 메소드 입니다.

 

 

1-4. HTTP response message

리퀘스트 메세지가 가면 서버에선 리스폰스 메세지를 보내게 됩니다.

리스폰스 타입은 먼저, 프로토콜 버전이 정의가 됩니다. (HTTP/1.1)

그 다음에 리스폰스 메세지가 정의가 됩니다. (200 OK : 너가 리퀘스트 한 것을 잘 해결했다 라는 의미입니다.)

그리고 헤더에는 여러 부가정보들이 달리게 됩니다. Server의 종류, 서버 상태가 언제 갱신되었는지 등을 기재합니다.

리스폰스 타입을 보고 persistant TCP를 지원한다고 알 수 있다.

특히 Keep-Alive 부분이 중요한데요. 앞에서 TCP 커넥션을 바로 닫지 않고, 한동안 남겨둔다 했는데 이것을 persistant TCP라고 했습니다. Keep-Alive(=계속 살아있게 냅둔다)는 바로 이 기능을 사용하겠다라는 뜻입니다.

Keep-Alive : timeout=10 -> 계속 살아있게 냅두는 것이 아닌 일정 시간 동안만 냅두겠다는 의미입니다.

 

 

1-5. HTTP response status codes

200 OK : 클라이언트가 요청한 게 성공적으로 처리가 되었습니다.

301 Moved Permanently : 자신이 요청한 오브젝트를 서버가 가지고 있지 않을수도 있습니다. 오브젝트가 존재하는 서버의 위치가 바뀐 것 입니다. 때문데 다른 서버로 이전되었다고 새로운 주소를 알려주기도 합니다.

400 Bad Request : 너가 요청한 리퀘스트는 해석할 수가 없다는 의미 입니다. 클라이언트가 잘못된 리퀘스트를 보내는 등 서버 입장에서는 해석이 안되는 경우 입니다.

404 Not Found : 서버에서 요청한 오브젝트가 존재하지 않고, 어디로 이전했는지도 모를 때 쓰입니다.

505 HTTP Version Not Supported : HTTP 버전이 맞지 않을 때 사용됩니다.

 

 

2. Cookies

HTTP 설계 철학은 stateless 프로토콜이라고 했습니다. 그 이유는 서버의 부담을 최대한 줄여주고, 가능한한 더 많은커넥션을 서버에서 처리할 수 있게하기 위해서 입니다. 하지만 웹서비스를 제공하는 웹서비스 프로바이더 입장에서는 state를 관리하고 싶습니다. 그래도 HTTP 설계 철학과는 어긋나기 때문에 쿠키라는 것을 제안하게 됩니다.

 

HTTP 리스폰스 메세지에 쿠키 헤더를 추가하고, 쿠키 번호를 가지고 특정 사람의 상태를 추적하는 것입니다.

유저의 host는 쿠키 파일을 가지고 있고, 유저 브라우저는 쿠키 파일에 있는 쿠키 넘버를 가지고 리퀘스트를 보내낼 때마다 자신의 쿠키 아이디를 서버에게 알려줍니다.

 

웹서버에서도 쿠키아이디가 어떤 host 인지를 맵핑을 해둡니다. 그래서 이 서비스를 사용한 유저가 누군지, 언제 방문했는지와 같은 정보들의 데이터베이스를 관리하면서 그 사람한테 맞춤 서비스를 제공합니다.

 

2-1. 쿠키의 기능

1) 특정 유저 접근을 못하게 할 수가 있습니다.

2) 유저의 아이디 정보를 통해서 유저 맞춤형 컨텐츠를 제공할 수 있습니다.

 

그외에도 많은 곳에서 사용되는데요.

1) 인증 (자동로그인)

2) 쇼핑카트

3) 추천

등 서버와 클라이언트 사이에서 서버의 백엔드 데이터베이스에도 저장이되어있고, 클라이언트에도 저장이 되어 있어 이 메세지는 HTTP 메세지를 통해 실어날라지면서 state를 관리할 수 있게 하게 됩니다.

 

좋은 서버를 제공받을수는 있지만, 프라이버시를 침해할 수 있는 기능이기도 합니다.

 

 

3. Web caches (proxy server)

웹서비스를 사용할 때 지연을 줄이는 게 굉장히 중요합니다. 반응속도가 너무 중요하잖아요.

이를 위해 패러렐 TCP 커넥션, persistance HTTP도 지원하고 있습니다. 더 나아가 웹 캐시 기능도 도입이 되었습니다.

 

웹 캐시는 서버의 개입없이 클라이언트의 리퀘스트를 처리하고자 하는 목적에 의해서 등장했습니다. 유저는 1차적으로 어떤 오브젝트를 요청할 때 오리지널 웹서버에 요청하는게 아닌 나한테 가까히 있는 프록시 웹서버에 요청합니다. 만약 프록시 웹서버가 내가 요청하는 오브젝트가 있다면, 서비스를 해줍니다.

 

프록시 서버가 원하는 오브젝트를 가지고 있을 시 오리지널 서버에 요청할 필요가 없기 때문에 반응속도가 더 빨라집니다. 또한 서버의 일이 줄어듭니다.

 

3-1. 웹캐시/프록시 서버 작동 원리

클라이언트1가 프록시서버에 HTTP request를 보내면, 프록시 서버는 요청한 정보가 있는지 확인을하고, 없을 경우 origin server에 HTTP request를 보내게 됩니다.(프록시 서버 = 클라이언트)

 

프록시 서버는 origin server에게 정보를 받아 client1에게 제공하게 됩니다. 이 때 프록시 서버는 이 정보를 임시 저장(캐시)하게 됩니다.

 

만약 클라이언트2가 클라이언트1과 똑같은 정보를 프록시 서버에 요청할 경우 임시 저장된 정보가 남아있다면, 오리진 서버를 거치지 않고, 빠르게 데이터를 넘겨줄 수 있습니다. (프록시 서버 = 서버)

 

즉, 프록시 서버는 클라이언트&서버의 역할을 동시에 합니다.

 

참고로 캐시는 ISP(Internet Service Provider)에 의해 설치가 됩니다.

 

 

3-2. 웹캐시/프록시 서버 왜 사용할까요?

1) 앞서 말씀드렸듯이 response time이 감소하기 때문입니다.

2) 앞에 프록시 서버가 대처함으로써 오리진 서버의 트래픽을 감소시키기 때문입니다.

3) 컨텐츠 프로바이더는 효과적으로 전달할 수 없던 컨텐츠를 캐시를 이용함으로써 빠르게 효율적으로 전달 가능하기 때문입니다.

 

 

3-3. 캐싱의 예시

하나의 오브젝트 사이즈 : 1Mbits

오리진 서버에 데이터 요청할 때 15개 오브젝트를 요청하게 됩니다. = 15/sec

때문에 브라우저의 데이터 rate는 1Mbit x 15/sec = 15Mbps

 

그림처럼 1RTT는 2초가 걸립니다.

엑세스 링크의 rate는 15Mbps이고요.

 

이 때 엑세스 링크는 제대로 활용이 되지 못한 상태로 가장 느리기 때문에 보틀넥에 속합니다.

또한 LAN의 utilization은 1.5%로 역시 제대로 활용되지 못하고 있는 상태죠.

 

이런 상태일 경우 internet delay + access delay + LAN delay는 각각

2초 + ?분 + 밀리세컨드 = 총 ?분으로 보틀넥 때문에 수 분이 걸리는 딜레이가 발생하게 되는 것입니다.

 

때문에 보틀넥 access link의 속도를 늘릴 필요가 있죠.

만약 access link의 속도가 100Mbps일 경우, nternet delay + access delay + LAN delay는 각각

2초 + 밀리세컨드 + 밀리세컨드 = 총 ?초로 효율을 높일 수 있습니다.

 

다만, 이런 방법은 돈이 많이듭니다.

 

그래서 우리는 엑세스 링크 속도를 올리는 방안보단, 캐시를 사용하게 됩니다.

 

웹 캐시가 요청받은 데이터를 가지고 있는 확률을 cache hit이라고하고, 없을 확률을 cache miss라고 합니다. 이 때 cache hit이 40%라고 하고, cache miss가 60%라고 한다면, 엑세스 링크로 60%만 요청되기 때문에 효율성이 높아집니다. 엑세스 링크는 15Mbps 속도에서 60%인 9Mbps만 처리하면 되는 것이죠.

 

그러면 전체 시스템은 0.6+0.4 = 약 1~1.2초 정도로 처리할 수 있게 됩니다.

이는 위에 엑세스 링크의 속도를 올리는 비싼 방법보다 싸고, 가성비 좋은 방안입니다.

 

 

4. Electronic Mail

 이메일은 asynchronous(비동기) 방식입니다. 즉, 상대방과 스케줄을 맞춰 함께 체크하지 않아도 된다는 의미입니다. 보통 우리 이메일을 보낼 때 이메일 보낸다고 통보하지 않듯이 말이죠.

 

때문에 이메일은 빠르고, 보내기 쉽고, 비싸지 않다는 장점을 가지고 있어요.

 

 

4-1. 이메일에 꼭 필요한 3가지 요소

1) user agents

2) mail server

3) SMTP (simple mail transfer protocol)

 

이렇게 3가지 요소가 필요합니다.

 

메일 에이전트는 가까운 메일 서버에 메세지를 보내고, 메일 서버는 목적 대상과 가까운 메일 서버에 메세지를 전달합니다. 전달할 때 SMTP를 지켜서 보내게 되는것이죠. 메일 서버는 마치 우체국같네요.

 

user agent는 mail reader라고도 불립니다. 메일 메세지를 composing, editing, reading 할 수 있죠.

예를 들면, 아웃룩, 네이버 웹 클라이언트, 안드로이드 구글 웹 클라이언트, 아이폰 메일 클라이언트가 있습니다.

 

메일 서버는 유저에게 온 메세지를 메세지 큐에 저장해둡니다. 위에서 말씀드렸다시피 메일 서버 사이에 SMPT프로토콜이 존재합니다.

 

 

4-2. 이메일 작동원리

유저 에이전트 앨리스가 아웃룩(이메일주소)을 통해 메세지를 보내면, 메일 서버에서는 메세지 큐에 저장하게 됩니다. 그 후 이메일 대상자와 가까운 메일 서버에 SMTP 프로토콜을 기준으로 전달됩니다. 이 때 메세지는 데이터 손실이 일어나면 안되기 때문에 TCP 프로토콜이 사용됩니다.(=reliable, 25번 포트 사용) 목적 서버와 TCP 커넥션이 성공되면, 상대방 메일 서버에 들어갈 수 있는 것이죠.

마지막으로 메세지를 대상자가 받아서 읽으면 끝입니다.

 

즉, TCP는 메일 서버 간 hand shaking(TCP 커넥션 맺기) -> transfer of messages(SMTP 보내기) -> closure(TCP 커넥션 닫기) 동작을 진행합니다.

 

 

4-3. HTTP VS SMTP

이 둘은 비슷해보여도 큰 차이점이 있습니다.

 

HTTP는 Pull 프로토콜입니다. HTTP리퀘스트를 보내, HTTP 리스폰스를 받는 식이죠.

반면, SMTP는 Push 프로토콜입니다. 앨리스가 밥에게 메일을 푸쉬하는 식입니다.

 

또한 SMTP는 아스키로만 메세지를 전달할 수 있습니다. 때문에 7bit 아스키코드를 이용하죠.

이미지를 아스키코드로 바꿔 다시 이미지로 변경해 전달하는 복잡한 전달 방식을 사용합니다.

 

 

4-4. 메일 엑세스 프로토콜

SMTP, POP, IMAP, HTTP의 4가지가 있는데요. 특히 HTTP는 많이 쓰입니다. 특히 지메일에 쓰이기도 합니다.

 

POP3 : 받는 사람의 메일서버로부터 유저 에이전트에게 메일을 보냅니다. 다운로드 및 삭제 기능이 있죠,

IMAP : 하나의 장소에 모든 메세지를 저장합니다. 단, 삭제 기능은 없어요.

Web-based E-mail : 유저에이전트는 웹브라우저와 HTTP를 통해 메일박스와 소통합니다. 리퀘스트 및 리스폰스를 이용해 메세지를 보내고 받습니다. 현재 가장 많이 쓰이는 방식이죠.

종합해보면 메일서버로 메세지를 보낼 땐 SMTP를 메세지를 당겨올 땐 POP3, IMAP을 사용하고 있는 것이죠.

 

 

5. DNS (domain name system)

우리는 IP주소 대신 www.~~~ 과 같은 호스트 주소를 사용합니다.

IP주소가 외우기 어렵기 때문인데요. 사람은 호스트주소를 선호하지만, 라우터 같은 경우 바이너리 데이터를 다루기 때문에 IP주소를 선호해요. 때문에 이런 호스트 주소와 IP주소를 바인딩, 맵핑 시켜줄 무언가가 필요하다고 생각되어 나타난 것이 DNS입니다.

 

 

5-1. IP주소

IP주소는 인터넷 호스트를 식별할 수 있는 주소 입니다.

121.7.106.83과 같이 4bytes(=32bits)이며, 계층 구조입니다.

참고로 앞에 121.7.106은 네트워크 아이디이고, 83은 호스트 아이디로 구성됩니다.

 

5-2. DNS

분산된 데이터베이스와 같습니다. 계층 구조이기 때문이죠.

호스트, 네임서버는 DNS를 사용하는데요. 호스트 네임과 아이피 주소를 맵핑하기 위함입니다.

 

그렇다면 왜 계층구조를 사용할까요?

1) 하나의 서버에서 감당하다 서버에 오류가 생기면, 전세계 사람들은 인터넷을 이용할 수 없기 때문입니다.

2) 또한 하나의 서버에 전세계의 트래픽이 몰려 볼륨이 커집니다.

3) 한국에서 미국까지 거리처럼 하나의 서버는 거리를 감당할 수 없을 테죠.

4) 마지막으로 유지보수도 너무 힘들겁니다.

 

즉, 확장성이 떨어지기 때문입니다!

이것이 바로 분산된 계층적 구조를 이용하는 이유가 되겠습니다.

루트 DNS 서버, 탑 레벨 도메인 서버 (TLD), Authoritative DNS 서버가 필수적인 3가지 서버이고, 로컬 DNS 네임 서버즈는 선택적인 서버로 총 4가지 서버로 계층이 구성됩니다.

 

클라이언트가 www.amazon.com의 IP주소를 찾고 싶다고 가정해봅시다. 

루트 서버에서는 TLS DNS 서버를 찾습니다. com을 가진 서버가 어딘지를요.

com DNS 서버를 찾으면, Authoritative DNS 서버를 탐색합니다. 아마존.com이 있는지를요.

그 후에 아마존의 IP주소를 찾게 되는 것입니다.

 

 

5-3. DNS 서버

 

1) 루트 네임 서버

루트 네임 서버는 전세계 13곳에 존재합니다.

 

2) 탑 레벨 도메인 (TLD) 서버

com, org, net, edu와 같은 탑 레벨 도메인을 찾아주는 서버 입니다.

 

3) Authoritative DNS 서버

보통 기관에서 관리하는 서버 입니다. 예를 들어 아마존과 같은 회사와 조직에서 직접 관리 합니다.

 

 

---

7일차 공부도 토요일이 되어서야 끝냈네요 ㅠㅠ

내일은 8일차 공부를 올리도록 하겠습니다!