요약
- DNS 서버 : 도메인 네임을 관리하는 네임 서버
- DNS(도메인 시스템) : 분산된 도메인 네임에 대한 관리 체계(프로토콜)
DNS와 자원
- 도메인 네임 : IP주소로 상대 호스트를 특정한다 했는데, 주소는 바뀔수도 있기 때문에 일반적으로 naver.com 처럼 도메인 네임을 사용(주소를 래핑하는것과 같은 의미같음)
- DNS 서버 : 이렇게 도메인 네임과 IP 주소를 관리하는 네임 서버를 DNS 서버라고함
도메인 네임
- .을 기준으로 계층적 분류
- 최상단에 루트 도메인 다음 단계 최상위 도메인
루트 도메인 -> 최상단 도메인 -> 2단계 도메인 -> 3단계 도메인 -> 4단계 도메인
- www.google.com이라고 가정해보자
일반적으로 루트 도메인은 생략한다. 생략하지 않으면 www.google.com.
com이 최상단 도메인, google이 2단계 도메인 www는 3단계 도메인이다.
그리고 전체를 전체 전체 주소 도메인 네임(FQDN)이라고 한다.
www까지 알게되면 모든 도메인 네임을 알 수 있어서 FQDN의 첫번째 부분을 호스트 네임이라고 함
리졸빙(resolve + ing)
-IP 주소를 모르는 상태로 도메인 네임에 대응되는 IP 주소를 알아내는 과정
HOW?
1. Client -> 로컬 네임 서버 : www.ex.com 도메인의 IP주소가 먼지 알려줄래~~?
1-1. (알고 있는경우) 알려준다.
2. (모르는 경우) 로컬 네임 서버 -> 루트 네임 서버 : www.ex.com 도메인의 IP 주소가 뭐야?
3. 루트 네임 서버 -> 로컬 네임 서버 : com을 관리하는 TLD 네임 서버 주소를 줄게 거기 물어봐
4. 로컬 네임 서버 ->TLD 네임 서버 : www.ex.com 도메인의 IP 주소가 뭐야?
5. TLD 네임 서버 -> 로컬 네임 서버 : ex.com 을 관리하는 네임 서버의 주소를 알려줄게
6. 로컬 네임 서버 -> 책임 네임 서버 : 알려줘 !!
7. 책임 네임 서버 -> 로컬 네임 서버 : 00.00.00야~
8. 로컬 네임 서버 -> Client : 00.00.00야!
이런 과정을 거치는 것을 반복적 질의라고한다. 여기서 로컬 네임에게 중간에 응답을 하지않고, 바로 루트 네임 -> TLD 네임 -> 책임 네임 역순으로 와서 최종 응답만 보내는 것을 재귀적 질의라고 한다.
근데 보다시피 이렇게 된 과정만 봐도 8단계를 거치게 된다. 이렇게 되면 시간도 오래걸리고 네트워크 상 메시지 수가 지나치게 늘어날 수 있다.
그래서 이런 결과를 임시로 저장해서 추후에 활용하기 위해 캐싱을 한다! (DNS 캐시)
HTTP
- 특징 : 요청과 응답을 기반으로 동작, 미디어 독립적, 상태를 유지하지 않음, 지속 연결 지원
- 응용 계층에서 청보를 주고받는 데 사용되는 프로토콜
HTTP 메시지 구조
시작 라인(줄바꿈) -> 요청 메시지일 경우 (요청라인), 응답 메시지일 경우(상태라인)
필드 라인* (줄바꿈) -> HTTP 헤더
(줄바꿈)
메시지 본문**.* 0개 이상
** 선택적
- 요청 라인 = 메서드 (공백) 요청 대상 (공백) HTTP 버전 (줄바꿈)
- 상태 라인 = HTTP 버전 (공백) 상태 코드 (공백) 이유 구문* (줄바꿈)
메서드 : 수행할 작업 종류, GET, POST, PUT, DELETE 등
요청 대상 : HTTP 요청을 보낼 서버의 자원, 보통 이곳에는(쿼리가 포함된) URI의 경로가 명시
HTTP 버전 : 말그대로 버전
HTTP 헤더와 HTTP 기반 기술
필드 라인에 HTTP 헤더가 명시된다고 했다.
HTTP 헤더는 매우 많다고 한다. 중요한 헤더만 요약
요청 시 활용되는 HTTP 헤더
1. Host : 요청을 보낼 호스트를 나타내는 헤더. 주로 도메인 네임으로 명시 (포트번호가 포함되어 있을 수 있다.)
2. User-Agent : 웹 브라우저와 같이 HTTP 요청을 시작하는 클라이언트 측의 프로그램을 의미
3. Referer : 클라이언트가 요청을 보낼 때 머무르고 있던 URL이 명시
4. Authorization : 클라이언트의 인증 정보를 담는 헤더
응답 시 활용되는 HTTP 헤더
1. Server : 서버 측 소프트웨어와 관련된 정보를 명시
2. Allow : 클라이언트에게 허용된 HTTP 메서드 목록을 알려줌
3. Retry-After : 상태 코드 053 응답과 함께 사용할 수 있는 헤더, 자원을 사용할 수 있는 날짜 혹은 시각을 나타냄
4. Location : 클라이언트에게 자원의 위치를 알려 주기 위해 사용되는 헤더
5. WWW-Authenticate : 상태 코드 401과 함게 사용되는 헤더 인증 방식을 설명하는 헤더.
요청과 응답에서 모두 활용되는 HTTP 헤더
1. Data : 메시지가 생성된 날짜와 시각에 관련된 정보를 담은 헤더
2. Connection : 클라이언트의 요청과 응답 간의 연결 방식을 설정하는 헤더
3. Content-Length : 본문의 바이트 단위 크기를 나타냄
4. Content-Type, Content-Language, Content-Encoding : 전송하려는 메시지 본문의 표현 방식을 설명하는 헤더(aka. 표현 헤더)
캐시
- 불필요한 대역폭 낭비와 응답 지연을 방지하기 위해 정보의 사본을 임시로 저장하는 기술
캐싱한다라고 함(성능향상에 큰 역할, 빠르게 요청에 응답할 수 있음) - 웹 브라우저에 저장되어 있기도하고(개인 전용 캐시), 클라와 서버 사이에 위치한 중간 서버에 저장되어 있기도 함(공용 캐시)
- 근데 이 캐시는 사본을 저장하고 있어서 원본과의 통일성을 유지해줘야한다. 그렇다고 매번 복사해오면 성능이 떨어지게 된다.
- 날짜 기반 검사
클라이언트는 IF-Modified-Since 헤더를 통해 서버에게 특정 시점 이후로 원본 데이터에 변경이 있었는지 물어볼 수 있다. 만약 변경이 있었으면 그때 갱신 요청을 한다.(혹은 삭제) - 엔티티 태그
'버전'이라는 기준으로 관리
자원이 변경될 때마다 자원의 버전을 식별하는 Etag 값을 변경해 체크
쿠키
- 가끔 인터넷을 보면 로그인 상태 유지라는 것을 볼 수 있다. HTTP는 기본적으로 상태를 유지하지 않는 스테이트리스 프로토콜인데? 이런 기능을 하는게 쿠키이다. (그래서 쿠키를 다 지우면 저장된 로그인 정보가 다~~ 날아간다)
- <이름,값> 으로 이루어짐
기본 숙제
도메인 네임과 네임 서버에 대한 설명으로 옳지 않은 것을 골라 보세요.(p.271)
4번, 루트 도메인은 . 이고 com은 최상위 도메인이다.(TLD)
HTTP 상태 코드에 대한 설명으로 옳지 않은 것을 골라 보세요.(p.307)
1번, 300번대 상태 코드는 리다이렉션 관련 상태코드이다.
추가 숙제
HTTP 요청 메시지 확인해보기
책과 동일한 example.com으로 확인해보았다.
HTTP 요청 메시지 헤더와 HTTP 응답 메시지 헤더를 볼 수 있다.
