[혼공네트] 5주차 응용계층

기본숙제

5-1 확인문제 1번

도메인네임과 네임서버에 대한 설명으로 옳지 않은것.

4번.

1. 8.8.8.8은 구글의 공개 DNS 서버.

2. 도메인 네임은 호스트를 특정할 수 있는 문자열형태 정보.

3. DNS는 계층적이고 분산된 도메인 네임의 관리체계이자 프로토콜

4. www.example.com 에서 루트도메인은 여기서 생략된 .com 뒤의 점.

 

5-2 확인문제 2번

HTTP 상태 코드에 대한 설명으로 옳지 않은 것.

1번

300번대 상태 코드는 요청을 완수하기 위해 추가적 조치가 필요할 때를 위한 리다이렉션 코드다.

새로운 URL로 리다이렉션 시킴. 메서드가 유지되는 코드와 바뀔 수 있는 코드가 있다.

 

추가 숙제

한빛출판 웹페이지의 HTTP 요청 메시지.

HTTP 1.1버전으로 html 웹페이지 요청 GET 메서드를 사용중이다

원하는 언어는 한글이고 가중치 생략했기에 가장 높은 가중치의 한글 페이지가 제공되고 있다.

User-Agent에서 윈도우10 64비트 OS를 사용함을 확인할 수 있고

지속 연결을 위해 keep-alive가 설정되어있다.

서버 도메인이 Host 헤더에 표시되어있다.

cache-control 헤더가 0 이므로 캐시 유지 시간이 없고 매번 새로운 데이터를 요청할 것이다.

 

 

내용정리.

도메인 네임 문자열과 IP주소와 대응되는 정보는 네임서버에서 관리하며 이중

도메인 네임을 관리하는 네임서버를 DNS 서버라고 부름.

 

www.google.com  주소를 기준으로 뒤에서부터 com이 최상위(TLD), google이 2단계,www가 3단계도메인.

맨뒤의 .이 루트도메인으로서 있지만 표기에선 생략함.

DNS와 같은 네임서버는 계층적 구조를 띄고 있다.

 

클라이언트가 도메인 네임의 IP주소를 알고싶다면 (ex) www.google.com)

로컬네임서버에 우선 요청을 한다.

(ISP 할당 로컬 네임 서버 말고 구글의 8.8.8.8같은 공개 DNS서버를 이용할 수도 있다)

로컬네임서버에 해당 정보가 없다면 클라이언트에게 루트네임서버의 주소를 알려준다.

루트네임서버에 질의하면  .com TLD 네임서버의 주소를 알려준다.

TLD 네임서버에 질의하면 google.com을 관리하는 책임 네임서버의 주소를 알려준다.

여기서 최종적으로 원하는 IP주소를 질의를통해 얻을 수 있다.

 

이렇게 클라이언트에게 다음 주소를 알려주는 반복적 질의 방식과

각 네임서버에서 상위 네임서버에 질의하는 재귀방식이 있다.

 

과도한 질의로 인한 과부하를 방지하기 위해 DNS캐시를 통해 정해진 TTL 동안

응답 결과 정보를 저장해두어 사용한다.

 

도메인 네임을 구매한 경우, DNS레코드를 등록하여 도메인 네임이 어떤 주소와 연결되어야 하고

어떤 CNAME을 갖고 있는지 네임서버에 알려야한다.

 

URI

자원 -> 네트워크상에서 메시지를 주고받는 대상

인터넷상 대부분의 통신이 HTTP기반으로 이루어지는 상황에서 

자원은 HTTP 요청 메시지의 대상 이라고 할 수 있다.

그 자원을 식별할 수 있는 정보를 URI라고 하고, 위치 기반의 방식인 URL과 이름 기반 URN으로 나눈다.

scheme -> http와 같이 자원에 접근하는 방식

authority -> 도메인네임이나 IP주소같이 식별 가능한 데이터

path -> 자원이 위치한 경로

query -> HTTP 요청시 요구할 내용, 상호작용에 용이하다

fragment -> 자원의 특정 위치를 표현하기 위한 부분

 

URN

urn:isbn:123456789 와 같은 형식으로 고유한 이름의 식별자를 사용한다.

 

 

HTTP

클라이언트-서버 구조의 요청-응답 프로토콜

송신 자원 특성에 제한을 두지 않고 인터페이스를 제공할 뿐인 미디어 독립적 프로토콜

서버가 클라이언트의 상태를 기억하지 않는 stateless.

많은 요청을 처리할 것이기에 기억하는것이 비효율적이고 서버가 여러대 분할처리를 할수도 있기때문.

HTTP1.1부터는 매번 쓰리핸드쉐이크를 할 필요 없이 한번의 TCP 연결에서 여러개의 요청응답을

주고받을 수 있는 keep-alive 기능 추가.

 

 

요청에서 POST와 HTTP 1.1 사이에 요청대상이 들어간다.

www.google.com/hello?q=world  라면 .com/뒤 부분. 하위경로가 없다면 바로 슬래시하나.

 

300번대 상태코드

영구적 리다이렉션 -> 자원이 완전히 새로운 곳으로 이동해 경로가 영구적 재지정

일시적 리다이렉션 -> 일시적으로 자원이 이동하거나 다른 URL이 필요한 경우

상태코드에 따라 요청 메서드가 바뀔수도 있고 바뀌지 않을수도있음.

 

http2 에서는 fcfs 방식등에 의한 HOL blocking을 방지하기 위해 오브젝트를 프레임 단위로 나누어 스케줄을 조정해 전송.

 

캐시

클라이언트가 같은 자원을 두번 이상 요청할 경우 망의 낭비를 방지하기 위해 캐시를 도입한다.

보냈던 자원을 일정 기간동안 사본으로 저장하다가 같은 요청이 올 시 그 사본을 사용하는 것.

(웹브라우저나 중간 서버에 사본을 저장해둔다)

사본이 최신버전인지 확인할 방법으로 헤더에 정보를 추가한다. (캐시 신선도 확인)

보낸 자원의 사본이 언제까지 최신인지 날짜나 시간의 정보를 전송해주는 방식과

(Expires, Cache-Control)

해당 사본에 해당하는 코드를 통해 최신 버전인지 확인하는 방법이 있다. (Etag)

클라이언트는 다시 요청할 때, 이 날짜나 코드를 통해 최신 사본인지 서버에 확인한다.

(If-Modified-Since, If-None-Match)

서버는 그대로 사용해도될지(200), 수정되었는지(304), 이제없는지(404) 답해준다.

 

쿠키

HTTP 통신은 stateless 하지만, 로그인 되었는지 등을 체크할 필요가 있다.

따로 저장해두고 사용할 데이터가 없다면 매 요청마다 인증 정보를 포함해야 하고 비효율적일 것.

인증이 필요한 첫 요청 시에만 인증 정보를 보내고 서버에서 세션 아이디 생성 후 DB에 저장하고

쿠키에 세션 아이디를 포함 해 Set-Cookie 헤더로 클라이언트에게 전송해준다.

 

클라이언트는 다음 요청시부터 해당 쿠키를 Cookie 헤더에 포함해서 서버에 전송하고

서버는 그 정보를 기반으로 아직 해당 쿠키가 유효한지 DB를 참고해 응답을 결정한다.

쿠키에는 도메인과 해당 도메인의 어떤 경로인지와 유효기간 등의 정보가 포함된다.

보안에 취약한 점 때문에 자바스크립트 쿠키변조를 막기 위한 HttpOnly 속성 등이 있다.

 

콘텐츠 협상

사용자 선택 언어에 따라 페이지 언어가 다르게 제공되는 상황을 생각.

자원을 다양한 형식으로 표현할 수 있고

HTTP 통신으로 클라이언트가 습득하는 것은 다양한 표현 중 하나.

GET 메서드는 자원의 특정 표현을 습득하기 위한 메서드라고 할 수 있다.

 

요청 헤더에 Accept-language에 원하는 언어들을 가중치를 넣어서 보내면 해당 가중치에 맞추어

서버에서 적절하게 응답해준다. 0~1까지고 클수록 우선순위가 높고 default는 1이다.

Accept 헤더에는 원하는 자원 형식.