[혼공학습단 12기 혼공네트🌐] 혼자 공부하는 네트워크 week5

✏️기본 미션

Ch.05(05-1) 확인 문제 1번(p.271), (05-2) 확인 문제 2번(p.307), 풀고 설명하기

 
❓Ch.05(05-1) 확인 문제 1번(p.271)

루트 도메인은 .입니다.

❓ Ch.05( (05-2) 확인 문제 2번(p.307)

300번대 코드는 리다이렉션 상태 코드입니다.
 
 

✏️선택 미션

HTTP 요청 메시지 확인해 보기

 

---

📜내용 정리

Chap05. 응용 계층

5.1 DNS와 자원

1) 도메인 네임과 네임 서버
- 도메인 네임 : 호스트의 IP주소와 대응되는 문자열 형태의 호스트 특정 정보
- 네임 서버 : 도메인 네임과 IP주소를 관리
- 도메인 네임

• 점(.)을 기준으로 계층적으로 분류된다.
• 루트 도메인은 점으로 표현되며, 도메인 네임의 마지막에 .이 찍힌 형태로 표기
• 전체 주소 도메인 네임(FQDN) : 3단계 도메인.2단계 도메인.최상위 도메인.

- 호스트 네임 : FQDN의 첫 번째 부분 || FQDN 자체 || 네트워크 장치 자체의 이름
- 도메인 네임 시스템 (DNS) : 도메인 네임에 대한 관리 체계
 
2) 계층적 네임 서버
(1) 네임 서버 
- 로컬 네임 서버

• 클라이언트와 맞닿아 있는 네임 서버
• 클라이언트가 도메인 네임을 통해 IP주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버 
• 공개 DNS 서버를 이용할 수도 있다.

- 루트 네임 서버

• 루트 도메인을 관장하는 네임 서버
• 로컬 네임 서버가 대응되는 IP주소를 모를 때  루트 네임 서버에 해당 도메인 네임을 질의
• 질의에 대해 TLD 네임 서버의 IP주소를 반환할 수 있다.

- TLD 네임 서버

• TLD를 관리하는 네임 서버
• 질의에 대해 TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환할 수 있다.

- 책임 네임 서버

• 특정 도메인 영역을 관리하는 네임 서버
• 로컬 네임 서버가 마지막츠로 질의 하는 네임 서버

(2) IP주소를 알아내는 과정
- 재귀적 질의

• 클라이언트가 로컬 네임 서버에 도메인 네임을 질의하면 로컬 네임 서버가 루트 네임 서버에게 질의, 루트 네임 서버는 TLD 네임 서버에게 질의 ...
• 위의 과정을 반복해 최종 응답 결과를 역순으로 전달받는 형식

- 반복적 질의

• 클라이언트가 로컬 네임 서버에게 IP주소를 알고 싶은 도메인 네임을 질의하면, 로컬 네임 서버는 루트 도메인 서버에게 질의해 다음으로 질의할 네임 서버의 주소를 응답받는다.
• 위의 과정을 반복하고 최종 응답 결과를 클라이언트에게 알려주는 방식

- DNS 캐시 : 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후 같은 질의에 이를 사용
 
3) 자원을 식별하는 URL
- 자원 : HTTP 요청 메시지의 대상
- URL : 자원을 식별할 수 있는 정보 (위치 이용)
cf) URN : 이름을 이용해 자원을 식별
 
(1) URL

foo://www.example.com:8042/over/there?name=ferret#nose

 
- scheme

• 자원에 접근하는 방법
• ex) https://, http://

- authority

• 호스트를 특정할 수 있는 정보
• IP주소 혹은 도메인 네임 명시
• 콜론(:) 뒤에 포트번호를 덧붙일 수 있다.

 
- path

• 자원이 위치한 경로
• / 를 기준으로 계층적으로 표현

 
- query

• 쿼리 파라미터 혹은 쿼리 문자열
• ?로 시작되는 <키=값> GUDXODML EPDLXJ
• & 를 이용해서 여러 쿼리 문자열을 연결할 수 있다.

 
- fragment

• HTML 파일과 같은 자원에서 특정 부분을 가리키기 위해 사용

(2) URN
- 자원에 고유한 이름을 붙이기 때문에 위치나 프로토콜과 무관하게 자원을 식별할 수 있다.
 

5.2 HTTP

1) HTTP의 특성
- 요청-응답 기반 프로토콜

• 클라이언트와 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고받는 구조로 동작한다.

- 미디어 독립적 프로토콜

• 미디어 타입 : HTTP에서 메시지로 주고받는 자원의 종류
• HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 독립적으로 동작이 가능하다.

- 스테이트리스 프로토콜

• HTTP는 상태를 유지하지 않는 스테이트리스 프로토콜이다.
• HTTP 요청을 보낸 클라이언트와 관련된 상태를 저장하지 않는다.
• 이를 통해 확장성과 견고성을 확보할 수 있다.

- 지속 연결 프로토콜

• 하나의 TCP 연결상에서 여러 개의 요청-응답을 주고받을 수 있는 기술 

 
2) HTTP 메시지 구조

시작 라인 (줄바꿈)
필드 라인* (줄바꿈)
(줄바꿈)
메시지 본문**

* : 0개 이상, ** : 선택적\
 
(1) 시작 라인
- HTTP 메시지가 HTTP 요청 메시지일 경우에는 시작 라인은 '요청 라인'이 된다.

• 요청 라인 : 메서드 요청 대상 HTTP 버전
• 메서드 : 클라이언트가 서버의 자원에 대해 수행할 작업의 종류
• 요청 대상 : HTTP 요청을 보낼 서버의 자원

- HTTP 메시지가 HTTP 응답 메시지일 경우에는 시작 라인은 '상태 라인'이 된다.

• 상태 라인 : HTTP버전 상태코드 이유 구문*
• * : 선택적
• 상태 코드: 요청에 대한 결과를 나타내는 3자리 정수
• 이유 구문 : 상태 코드에 대한 문자열 형태의 설명

(2) 필드 라인
- 0개 이상의 HTTP 헤더가 명시된다.
- 각 HTTP 헤더는 콜론(:)을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성된다.
 
(3) 메시지 본문
- 본문이 필요할 경우 메시지 본문에 명시한다.
 
3) HTTP 메서드

HTTP 메서드	설명
GET	자원을 습득하기 위한 메서드
HEAD	GET과 동일하나 헤더만을 응답받는 메서드
POST	서버로 하여금 특정 작업을 처리하게끔 하는 메서드
PUT	자원을 대체하기 위한 메서드
PATCH	자원에 대한 부분적 수정을 위한 메서드
DELETE	자원을 삭제하기 위한 메서드
CONNECT	자원에 대한 양방향 연결을 시도하는 메서드
OPTIONS	사용 가능한 메서드 등 통신 옵션을 확인하는 메서드
TRACE	자원에 대한 루프백 테스트를 수행하는 메서드

 
4) HTTP 상태 코드  
- 100번대 : 정보성 상태 코드
- 200번대 : 성공 상태 코드

• 200 Ok : 요청이 성공했음
• 201 Created : 요청이 성공했으며 새로운 자원이 생성되었음.
• 202 Accepted : 요청을 잘 받았으나 아직 요청한 작업을 끝내지 않음
• 204  No content : 요청이 성공했지만 메시지 본문으로 표시할 데이터가 없음

- 300번대 : 리다이렉션 상태 코드

• 영구적 리다이렉션 : 자원이 완전히 새로운 곳으로 이동해 경로가 영구적으로 재지정되는 경우
  • 301 Moved Permanently : 영구적 리다이렉션(재요청 메서드 변경될 수 있음)
  • 308 Permanent Redirect : 영구적 리다이렉션(재요청 메서드 변경X)
• 일시적 리다이렉션 : 자원의 위치가 임시로 변경되었거나 임시로 사용할 URL이 필요한 경우
  • 302 Found : 일시적 리다이렉션 (재요청 메서드 변경될 수 있음)
  • 303 See Other : 일시적 리다이렉션 (재요청 메서드 GET으로 변경)
  • 307 Temporary Redirect : 일시적 리다이렉션 (재요청 메서드 변경되지 않음)

- 400번대 : 클라이언트 에러 상태 코드

• 400 Bad Request : 클라이언트의 요청이 잘못되었음
• 401 Unauthorized : 요청한 자원에 대한 유효한 인증이 없음
• 403 Forbidden : 요청이 서버에 의해 거부됨
• 404 Not Found : 요청받은 자원을 찾을 수 없음
• 405 Method Not Allowed : 요청한 메서드를 지원하지 않음

- 500번대 : 서버 에러 상태 코드

• 500 Internal Server Error : 요청을 처리할 수 없음
• 502 Bad Gateway : 중간 서버의 통신 오류
• 503 Service Unavailable : 현재는 요청을 처리할 수 없으나 추후 가능할 수도 있음.

 

5.3 HTTP 헤더와 HTTP기반 기술

1) HTTP 헤더
(1) 요청 시 활용되는 HTTP 헤더
- Host

• 요청을 보낼 호스트를 나타내는 헤더
• 주로 도메인 네임으로 명시되며, 포트 번호가 포함될 수 있다.

- User-Agent

• Host 헤더와 더불어 HTTP 요청 메시지에서 가장 흔히 볼 수 있는 헤더 중 하나
• 웹 브라우저와 같이 HTTP 요청을 시작하는 클라이언트 측의 프로그램

- Referer

• 클라이언트가 요청을 보낼 때 머무르고 있던 URL이 명시된다.

- Authorization

• 클라이언트의 인증 정보를 담는 헤더

(2) 응답 시 활용되는 HTTP 헤더
- Server

• 요청을 처리하는 서버 측의 소프트웨어와 관련된 정보를 명시

- Allow

• 클라이언트에게 허용된 HTTP 메서드 목록을 알려 주기 위해 사용된다.

- Retry-After

• 503 상태 코드와 함께 사용될 수 있는 헤더
• 자원을 사용할 수 있는 날짜 혹은 시각을 나타낸다.

- Location

• 클라이언트에게 자원의 위치를 알려주기 위해 사용되는 헤더
• 주로 리다이렉션이 발생했을 때나 새로운 자원이 생성되었을 때 사용된다.

- WWW-Authenticate

• 401 상태 코드와 함께 사용되는 헤더
• 자원에 접근하기 위한 인증 방식을 설명하는 헤더

 
🎮 Authorization과 WWW-Authenticate 헤더를 통해 인증되지 않은 클라이언트가 HTTP 인증(Basic 인증)을 수행하는 과정
1️⃣ 인증되지 않은 클라이언트가 서버에 GET 요청을 보낸다.
2️⃣ 서버는 클라이언트에게 상태 코드 401과 WWW-Authenticate 헤더를 통해 인증방식을 알린다.
3️⃣ 클라이언트는 사용자로부터 인증 정보(사용자 아이디, 비밀번호)를 전달받는다.
4️⃣ "사용자 아이디:비밀번호"를 Base64 인코딩한 값을 인증 정보로 삼은 Authorization 헤더를 통해 다시 GET 요청 메시지를 전송한다.  
5️⃣ 서버는 인증 정보를 확인한다.
6️⃣ 인증이 유효하면 상태 코드 200으로 응답하고, 인증되지 않으면 상태 코드 401로 응답한다.
 
(3) 요청과 응답 모두에서 활용되는 HTTP 헤더
- Date

• 메시지가 생성된 날짜와 시각에 관련된 정보

- Connection

• 클라이언트의 요청과 응답 간의 연결 방식을 설정하는 헤더

- Content-Lnegth

• 본문의 바이트 단위 크기(길이)를 나타낸다.

- Content-Type, Content-Length, Content-Encoding

• Content-Type : 메시지 본문에서 사용될 미디어 타입
• Content-Length : 메시지 본문에 사용된 자연어
• Content-Encoding : 메시지 본문을 압축하거나 변환한 방식

2) 캐시 (Cache)

- 불필요한 대역폭 낭비와 응답 지연을 방지하기 위해 정보의 사본을 임시로 저장하는 기술

• 개인 전용 캐시 : 웹 브라우저에 저장된 캐시
• 공용 캐시 : 클라이언트와 서버 사이에 위치한 중간 서버에 저장된 캐시

3) 쿠키 (Cookie)

- 서버에서 생성되어 클라이언트 측에 저장되는 데이터
 

4) 콘텐츠 협상(content negotiation)과 표현(representation)

- 콘텐츠 협상 : 같은 URL에 대해 가장 적합한 자원의형태를 제공하는 매커니즘
- 표현 : 송수신 가능한 자원의 형태
 
 

🤔느낀 점

최근에 프로젝트를 하나 끝냈는데 백엔드 담당이어서인지 이번 주차 내용이 더욱 재밌었습니다. API 사용을 위해  Authorization 헤더를 달아보고, 결과를 상태 코드로 확인해본 경험이 있어서 이론이 더 잘 와닿았던 것 같습니다!