너무 많이 본 내용들이라 지루해서 대충 쓴 감이 있다..

목차
1. HTTP
2. Cookie / Web-Cache
3. DNS

1. HTTP

 

드디어 Application Layer까지 올라왔다.

📌 Web & Http
  • Web
    • WWW(World Wide Web)의 약어
    • 전세계 사용자들이 서로의 정보를 공유할 수 있는 가상의 공간
    • 여러 기술들과 약속들로 형성된 인터넷 상의 플랫폼
  • Http
    • HyperText Transfer Protocol, 웹이 통신을 하기 위한 약속
    • HyperText란 웹 상에 존재하는 웹 페이지끼리 서로 참조할 수 있는 기술
    • Web에서 HyperText는 마크업 언어인 HTML로 표현

Web page는 object들로 구성되어 있는데, 각각은 다른 Web Server에 저장되어 있다.

(Object는 HTML, JPEG 이미지, Java applet, audio file 같은 것들)

그리고 Web page는 Html 문서를 기반으로 URL로 주소가 매칭되어 있는 참조 오브젝트들이 작성되어 있다.

 

이게 무슨 의미인지 알아보기 위해 네이버 메인 화면을 살펴보자.

www.naver.com에 접속하면 정말 많은 이미지와 아이콘들이 있는데, 이건 건 사실 한 번의 요청만으로 이런 결과물을 만들어낸 것은 아니다.

처음 Request를 네이버 Server에 보내면 아래와 같은 HTML 문서를 돌려준다

대충 설명하자면 Web browser가 이 문서를 읽고 해석해서 화면에 예쁘게 꾸며주는 과정을 진행한다.

그런데 html을 아무리 뒤져봐도 사진은 보이지 않는다. 그저 "사진 이미지가 있는 주소(URL)"만을 명시해두었다.

이건 html 골격을 짜면서, 이 빈 칸에 대한 데이터를 얻고 싶다면 해당 URL로 다시 Request를 보내야 함을 뜻한다.

실제로 메일 아이콘의 url이 css에 정의되어 있다.

그리고 이 URL을 주소 창에 입력하면, 해당 png 파일을 직접 다운까지 받을 수 있다.

정리하면 www.naver.com에  html을 요청하고, html은 문서를 화면에 렌더링하는 과정에서 추가로 받아와야 하는 정보들에 대해서 또 다시 요청을 수행한다.

위의 예시의 경우 pm.pstate.net 이라는 host name 안의 resources/asset/sp_main.~.png 파일을 요구한 것이다.

아래쪽에 보면 sp_main.~.png 파일도 요청해서 받아온 것을 알 수 있다.

 

📌 Overview

  • Client : HTTP 기반으로 Browser가 request, response 수행 후, Object를 화면에 띄움
  • Server : Client 측 Request를 듣고 있다가 Request에 해당하는 Response 돌려 줌

HTTP의 특징들만 더 정리해보자면

  • HTTP는 TCP 통신을 사용한다.
    • Client는 Server와 80번 port로 TCP 연결을 한다.
    • Client의 browser와 Web Server 사이에 HTTP message가 오고간다.
  • HTTP는 "stateless"하다.
    • HTTP 자체는 기본적으로 Caching 하지 않기 때문에, 상태를 관리하지 않는다.
    • 즉, Server는 Client의 이전 Request에 대한 어떠한 정보도 유지하지 않는다.
  • HTTP의 2가지 종류
    •  
    • HTTP는 Non-persistent와 Persistent가 있는데, 이건 아래에서 따로 다루자.
  • HTTP Message
    • Request
    • Response
      • Status Code : request가 잘 됐는지, 혹은 어떤 이유로 실패했는지
        • 200 OK
        • 301 Moved Permanetly
        • 400 Bad Request
        • 404 Not Found
        • 505 HTTP Version Not Supported 등

(좌) Request, (우) Response

 

📌 As-is. Non-persistent HTTP

요새 안 쓰는 방식이다. 왜 안 쓰게 됐는지는 설명을 들으면 바로 납득 가능하다.

위에서 언급했듯이 HTML 문서를 받으면, 그에 해당하는 Object를 얻기 위한 추가적인 Http message를 보낸다.

문제는 HTTP 통신이 TCP로 이루어지니 할 때마다 3-way handshake를 하는 과정이 수반된다.

html 받았는데, png 이미지가 필요해서 다시 요청을 보내려고 했더니 Server가 소켓을 말소해버린 상황...

그래서 Client가 다시 연결 요청을 해서 이미지를 받아오고, 그 과정을 필요한 Obj 수만큼 반복한다.

 

만약 이 방식을 채택한다면 Web Server에 Request를 하고, 온전한 결과를 만들어내는 데까지 다음과 같은 시간이 소모된다.

Non-persistent HTTP response time = (2RTT + file transmission time) * (object file 개수)

 

📌 To-be. Persistent HTTP

말 그대로 모든 데이터를 전부 받기 전까지는 Socket을 말소하지 않는다.

이제는 한 번의 3-way handshaking만 하면 obj에 대한 요청만 수행하면 되므로 오버헤드가 감소한다.

 

요새는 Web-socket이란 걸 이용해서 아예 실시간 서비스를 제공하기도 한다.

2. Cookie / Web-Cache

 

📌 Cookie
 

[DRF] 6. Mini-Project : Create Blog(4) - JWT

JWT token 이론 정리가 끝나면 본격적으로 로그인 기능을 구현해봐야겠다. DRF를 이해하고 포스팅하는 것이 아니라, 속성으로 머리에 때려넣고 어떻게 잘 반죽해가며 쓰는 중이라 틀린 내용도 많을

jaeseo0519.tistory.com

정말 예전에도 설명을 했지만, HTTP에는 State란 개념이 존재하질 않으니 문제가 많았다.

당장 로그인 한 유저에 대한 관리부터 어떻게 할 것인가? request한 사용자가 누군지도 모르는데 인증이 불가능하다.

그래서 사용자가 Request를 하면, Response에 set_cookie 옵션을 넣어서 보내면 Browser가 사용자 DB에 일정 기간동안 모셔둔다.

그리고 이후에 request를 보낼 때, 해당 cookie를 같이 보내면 서버가 "얘 전에 왔던 애네?"라고 판단할 수 있는 것이다.

물론 최근에는 보안 이슈로 인해서 거의 사용하지 않을 뿐더러, 사용하더라도 Client의 허락을 구해야 한다. 

 

📌 Web-Cache

Web cache(proxy)는 사용자 요청에 대한 응답을 저장해둔다.

그리고 같은 요청이 들어오면 저장된 응답을 똑같이 돌려준다.

만약 해당 요청에 대한 캐시가 없다면, 원래대로 origin server에 요청을 하는데 그 응답을 저장해두는 식이다. 

 

이 방식의 장점은 다음과 같다.

  • Client
    • 응답 속도가 빨라진다.
    • 외부망을 덜 사용해도 되므로 비용이 절감한다.
  • Server
    • 트래픽 부하 분산으로 서버 부담이 줄어든다.

3. DNS

 

📌 Domain Name System

Domain Name Service라고 하기도 하는데, 보통 그냥 DNS라고 부른다.

  • 도메인 이름으로 32bit IP 주소로 바꿔주는 서비스
  • key-value 쌍으로 값을 저장한다.
  • 전 세계의 DNS 서버가 연대하며, 계층 구조로 이루어져 있다.
  • application-layer protocol
  • UDP 통신을 이용한다. (데이터가 작기 때문에 TCP는 오버헤드 발생)

 

📌 hierarchy structure

중앙 집중화가 좋지 않은 이유는 너무도 분명하다.

  • 도메인 주소명과 IP를 1:1로 매칭시키는 것은 데이터 양도 너무 방대하고 탐색도 너무 느리다.
  • 전세계의 트래픽이 한 곳에 집중된다.

이러한 분명한 단점들 때문에 DNS 서버를 계층구조로써 분리해놓았다.

전 세계에 논리적으로 13개가 존재하는 Root DNS Server가 존재하는데, www.amazon.com을 주소창에 입력하면 다음과 같은 일련의 요청이 발생한다. 

참고로 www는 서버명, amazon과 com은 도메인 명이며, 가장 끝의 com이 최상위 도메인 명이 된다.

  1. Client가 root sever에 "www.amazon.com"를 물어보면 Root가 com DNS Server 주소를 알려준다.
  2. Client가 com DNS에 "www.amazon.com"를 물어보면 Root가  amazon DNS Server 주소를 알려준다.
  3. Client가 amazon DNS에 "www.amazon.com"를 물어보면 www DNS Server 주소를 알려준다.
  4. Client가 www DNS에 "www.amazon.com"를 물어보면 "www.amazon.com" IP 주소를 돌려준다.

 

📌 Top-Level Domain & Authoritative servers

  • TLD server
    • 우리가 주로 아는 com, ort, net, edu, jobs 등등 모두 top-level domain이다.
    • cn, uk, fr, ca, jp, kr 은 top-level country domain에 속한다.
  • authoritative DNS servers
    • 조직 자체의 DNS 서버인데, 보통은 돈 주고 service provider들한테 돈 주고 등록한다.
    • 학교 같은 집단에 있을 수도 있고, 없을 수도 있고..KT에서 제공해줄 수도 아닐 수도 있는 그런 것

 

📌 Local DNS name servers

보통은 Client가 직접 Root DNS Server에 요청을 보내지는 않는다.

근처의 가장 가까운 DNS Server(local DNS Server)에 요청을 보내면, 거기서 모든 query를 처리하고 결과만 알려준다.

💡 엄격하게 따지면 Local DNS Server는 계층에 속하지 않는다.

로컬 DNS 서버는 사용자 로컬 네트워크에 위치하며, 해당 네트워크에서 도메인 주소를 IP 주소로 변환해준다.

즉, 계층 구조의 일부기 보다는 특정 네트워크 환경의 서비스 역할에 불과하다.

중간 관리자가 있으면 좋은 것이 DNS Server도 캐싱을 하기 때문에 요청 정보에 대한 결과를 일정 시간 보관해둔다.

(정보가 바뀔 수도 있으니 일정 시간 후에 캐싱된 결과는 제거하고 새롭게 갱신한다.)

따라서 해당 DNS Server를 통해 같은 주소로 접속하려는 다른 host가 있다면, 굳이 root DNS Server에 요청을 보내지 않아도 빠르게 응답을 받을 수 있다.

 

계층 구조로도 구현할 수 있기는 한데, 대부분은 이전의 iterated query 방식을 택하지 않을까 싶다.

그리고 겉보기에도 그게 더 합리적이라고 생각된다.

 

📌 DNS records

DNS cache에는 다음과 같은 정보가 담겨 있다.

RR(resource records) format : (name, value, type, ttl)

name, value는 domain, ip 주소를 의미하고, ttl은 유효기간인데 type은 뭔가?

 

type name value
A hostname IP address
NS domain

ex. example.ac.kr		 hostname of authoritative name server

ex. dns.example.ac.kr
CNAME alias name (별명) canonical name (실제 이름)
MX email name of SMTP mail server 

 

여기서 A랑 NS 정도는 구분 하는 게 좋지 않을까~ 내 시험을 위해..

확실히 TCP 얘기하다가 여기로 올라오니까 흥미가 급격하게 떨어져서 대충 정리해버렸다.

저작자표시 비영리

티스토리툴바