[혼자 공부하는 네트워크] 5. 응용 계층

DNS와 자원

메시지를 주고받기 위해서는,

• 메시지를 주고받는 송수신지 파악 → IP 주소, 도메인 네임
• 송수신하고자 하는 정보 파악 → 자원

도메인 네임과 네임 서버

IP 주소만으로 송수신지 특정하는 것은 번거로움

• 통신하고자 하는 모든 호스트의 IP 주소 기억하기 어려움
• IP 주소는 언제든 바뀔 수도 있음

그래서 상대 호스트 특정을 위해 도메인 네임을 사용

도메인 네임( = 전화번호에 대응하는 사용자 이름): 호스트의 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보

ex) www.example.com

• 도메인 네임은 네임 서버(DNS 서버)에서 관리됨(= 공용 전화번호부)
  • IP 주소가 변경되어도 도메인 네임 다시 대응하면 그만
• hosts 파일: 호스트마다 도메인 네임과 IP 주소의 대응 관계를 담은 파일(= 개인 전화번호부)
  • hosts 파일 위치: 맥OS나 리눅스(/etc/hosts), 윈도우(%SystemRoot%￦System32￦drivers￦etc￦hosts)

네임 서버의 관리

네임 서버는 점(.)을 기준으로 계층적으로 분류함

네임 서버의 계층적 구조(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 루트 도메인(root domain)
• 최상위 도메인(TLD;Top-Level Domain)
• 2단계 도메인, 3단계 도메인, 4단계 도메인, ...

[네임 서버가 저장하는 내용]

네임 서버는 DNS 자원 레코드(DNS resource record)를 저장함

• DNS 자원 레코드 = 이름(호스트 이름), 값(value), TTL, 레코드 유형, 등
• 웹 서비스를 배포할 때, 먼저 도메인 네임을 구입한 후, 해당 도메인 네임과 IP 주소가 대응됨을 네임 서버에 알려야 함
• 이를 위해 만들어야 하는 정보가 DNS 자원 레코드임
• ex) 네임 서버에 example.com을 질의하면 1.2.3.4 응답, DNS 캐시는 300초간 저장
  www.example.com에 질의하면 1.2.3.4 응답

타입	이름	값	TTL
A	example.com	1.2.3.4	300
CNAME	www.example.com	example.com	300

• 레코드 유형: 레코드 유형이 달라지면 레코드 이름과 값의 의미가 달라짐

레코드 유형	설명
A	특정 호스트에 대한 도메인 네임과 IPv4 주소와의 대응 관계
AAAA	특정 호스트에 대한 도메인 네임과 IPv6 주소와의 대응 관계
CNAME	호스트 네임에 대한 별칭 지정
NS	특정 호스트의 IP 주소를 찾을 수 있는 네임 서버
MX	해당 도메인과 연동되어 있는 메일 서버

 

전체 주소 도메인 네임(FQDN; Fully-Qualified Domain Name): 전체 도메인 계층을 모두 포함하는 도메인 네임

• FQDN까지 알면 비로소 하나의 호스트를 식별할 수 있게 됨

FQDN(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

서브 도메인(subdomain): 다른 도메인이 포함된 도메인

ex) google.com의 서브 도메인: mail.google.com, www.google.com, drive.google.com

 

계층적 도메인 네임

• 이를 관리하기 위한 네임 서버 또는 계층적으로 관리됨
• 네임 서버는 전 세계 여러 군데 분산되어 위치되어 있음

계층적이고 분산된 도메인 네임에 대한 관리 체계 = Domain Name System, DNS

 

계층적 네임 서버

도메인 네임에 대응하는 IP 주소를 알아내는 과정

• 도메인 네임을 풀이(resolve)한다
• 계층적이고 분산된 네임 서버들이 사용됨
• 주요 네임 서버의 유형: 로컬 네임 서버, 루트 네임 서버, TLD 네임 서버, 책임 네임 서버

주요 네임 서버(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

1. 로컬 네임 서버(local name server)

• 클라이언트와 맞닿아 있는 네임 서버
  • 클라이언트가 도메인 네임을 통해 IP 주소를 알아내고자 할 때 가장 먼저 찾게 되는 네임 서버
  • 로컬 네임 서버의 주소는 일반적으로 ISP에서 할당
  • 공개 DNS 서버 public DNS Server를 이용할 수도 있음 ex) 구글의 8.8.8.8, 8.8.4.4
• 클라이언트로부터 요청받은 도메인 네임이 처음 보는 도메인 네임이면, 루트 네임 서버한테 질의함

2. 루트 네임 서버(root name server)

• 루트 도메인을 관장하는 네임 서버
  • 로컬 네임 서버가 대응되는 IP 주소를 모를 경우
  • TLD 네임 서버의 IP 주소를 반환할 수 있음

로컬 네임 서버와 루트 네임 서버간의 질의 과정(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

3. TLD 네임 서버

• TLD를 관리하는 네임 서버
• DNS 질의에 대해 TLD의 하위 도메인 네임을 관리하는 네임 서버 주소 반환
  • 하위 도메인 네임을 관리하는 네임 서버는 그보다 하위 도메인 네임을 관리하는 네임 서버 주소 반환

로컬 네임 서버와 TLD 네임 서버간의 질의 과정(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

4. 책임 네임 서버(authoritative name server)

• 특정 도메인 영역(zone)을 관리하는 네임 서버
• 다른 네임 서버에게 떠넘기지 않고 곧바로 답할 수 있는 네임 서버
• 즉, 책임 네임 서버는 로컬 네임 서버가 마지막으로 질의하는 네임 서버
• 일반적으로 로컬 네임 서버는 책임 네임 서버로부터 원하는 IP 주소를 얻어냄

 

네임 서버의 계층적 구조를 토대로 IP 주소를 알아내는 과정

1. 재귀적 질의(recursive query)

• 클라이언트 → 로컬 네임 서버 → 루트 네임 서버 → TLD 네임 서버 → 책임 네임 서버에게 질의
• 최종 응답 결과를 역순으로 전달

재귀적 질의(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

2. 반복적 질의(iterative query)

• 네임 서버에 일일이 질의-응답 반복
• 최종 응답 결과를 클라이언트에게 전달

반복적 질의(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

재귀적 질의와 반복적 질의로 IP 주소를 알아내는 과정은 문제가 존재함.

• 시간이 오래 걸리고 네트워크상의 메시지 수가 지나치게 늘어날 수 있음
• 루트 네임 서버에 과부하 우려

이 문제를 해결하기 위해 사용하는 것이 DNS 캐시(DNS cache)임

 

DNS 캐시(DNS cache)

네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후 같은 질의에 이를 활용하는 것

• DNS 캐시를 저장하는 용도로만 사용되는 서버도 있음
• DNS 캐시를 활용하면 더 짧은 시간 안에 원하는 IP 주소를 얻어낼 수 있음
• DNS 캐시는 영원히 남아있는 것은 아님
  • 임시 저장된 값은 TTL(Time To Live: 캐시될 수 있는 시간) 값과 함께 저장됨

---

자원을 식별하는 URI

자원(resource): 네트워크상의 메시지를 통해 주고받는 대상

• 두 호스트가 네트워크를 통해 서로 정보를 주고받을 때, 송수신하는 대상 ex) HTML 파일, 이미지나 동영상 파일, 텍스트 파일 등
• 자원은 'HTTP 요청 메시지의 대상'이라 보기도함

URI(Uniform Resource Ideontifier)

자원을 식별할 수 있는 정보

 

1. URL(Uniform Resource Locator): 위치를 이용해 자원을 식별

• 오늘날 인터넷 환경에서 자원 식별에 더 많이 사용되는 식별자

URL(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

[URL 구조]

① scheme: URL의 첫 부분으로써, '자원에 접근하는 방법'을 의미

• 일반적으로 사용할 프로토콜이 명시
  • HTTP를 사용하여 자원에 접근할 때는 http://를
  • HTTPS를 사용하여 자원에 접근할 때는 https://를 사용

② authority: '호스트를 특정할 수 있는 정보', 이를테면 IP 주소 혹은 도메인 네임이 명시

• 콜론(:) 뒤에 포트 번호를 덧붙일 수도 있음

③ path: '자원이 위치한 경로'가 명시

• 자원의 위치는 슬래시(/)를 기준으로 계층적으로 표현되고, 최상위 경로 또한 슬래시로 표현

④ query: HTTP는 요청-응답 기반의 프로토콜

• 클라이언트는 서버에게 URI(URL)가 포함된 HTTP 요청 메시지를 보내고,
• HTTP 서버는 이에 대해 HTTP 응답 메시지를 보냄

scheme, authority, path만으로 요청-응답하는 과정(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 이런 요청은 scheme, authority, path만으로 어떻게 표현할 수 있을까? ex: 검색 결과, 정렬 결과

query를 이용해 요청-응답하는 과정(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 이럴 때 사용하는 쿼리 문자열(query string), 쿼리 파라미터(query parameter)라고도 부름
• 물음표(?)로 시작되는 <키, 값> 형태의 데이터
• 앰퍼샌드(&)로 여러 쿼리 문자열을 덧붙일 수 있음
• ex) http://example.com/random/path?query=value&query2=value2
• 개발자가 설계하기 나름임

⑤ fragment: '자원의 한 조각을 가리키기 위한 정보'

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

fragment(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

2. URN(Uniform Resource Name): 이름을 이용해 자원을 식별

• URL의 단점
  • 위치를 기반으로 자원을 식별하는데 자원의 위치는 언제든 변할 수 있음
  • 즉, 자원의 위치가 변경되면 기존 URL로는 자원을 식별할 수 없음
• URN의 장점
  • 자원에 고유한 이름을 붙이는 이름 기반 식별자이기에 자원의 위치와 무관하게 자원을 식별
• URN은 아직 URL만큼 널리 채택된 방식은 아님
  ex) urn:isbn:04883920

---

HTTP

• 사용자와 밀접하게 맞닿아 있는 프로토콜
• 웹 세상의 기반이 되는 가장 중요한 프로토콜

HTTP 중요한 특성

1. 요청-응답 기반 프로토콜이다.

• HTTP는 '클라이언트-서버 구조 기반의 요청-응답 프로토콜'
  • HTTP 요청 메시지와 HTTP 응답 메시지는 메시지 형태가 다름

2. 미디어 독립적 프로토콜이다.

• HTTP를 정의하는 공식 문서(RFC 9110)에 따르면, 

HTTP가 요청하는 대상은 '자원'이다. HTTP는 자원의 특성을 제한하지 않으며, 
자원과 상호작용하는 데 사용할 수 있는 인터페이스를 정의할 뿐이다.
대부분의 자원은 URI로 식별된다"

• 즉, HTTP는 주고받을 자원의 특성과 무관하게 그저 자원을 주고받을 수단(인터페이스) 역할만 함
• HTTP를 통해 HTML, JPEG, PNG, JSON, XML, PDF 등 다양한 종류의 자원 송수신 가능
• 미디어 타입(Media Type): HTTP에서 메시지를 주고받는 자원의 종류, 웹 세상의 확장자 (= MIME 타입(Multipurpose Internet Mail Extension Type))
  • 슬래시를 기준으로 '타입/서브타입(type/subtype)'형식으로 구성
    • 타입: 데이터의 유형
    • 서브타입: 주어진 타입에 대한 세부 유형
  • 미디어 타입에는 부가적인 설명을 위해 선택적으로 매개변수 포함 가능
    • '타입/서브타입;매개변수=값'의 형식으로 표현 → type/subtype;parameter=value (ex: type/html;charset=UTF-8)
  • 미디어 타입의 종류는 매우 다양하며, 새로운 미디어 타입을 등록할 수도 있음

미디어 타입 종류(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 즉, HTTP는 주고받을 미디어 타입에 특별히 제한을 두지 않고 동작하는 미디어 독립적 프로토콜
• 여러 미디어 타입 통칭: 별표 문자(*)
  • ex) text/* = text 타입의 모든 서브타입
  • ex) image/* = image 타입의 모든 서브타입
  • ex) */* = 모든 미디어 타입

3. 상태를 유지하지 않는(=stateless) 프로토콜이다.

• HTTP는 상태를 유지하지 않는 스테이트리스(stateless) 프로토콜
  • 서버가 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다는 의미
  • 클라이언트의 모든 HTTP 요청은 기본적으로 독립적인 요청으로 간주
• HTTP가 상태를 유지하지 않는 이유는, HTTP의 확장성과 견고성 때문
  1. HTTP 서버는 일반적으로 많은 클라이언트와 동시에 상호 작용함. 또한, 오늘날 많은 HTTP 서버는 높은 가용성(장애가 생겨도 문제없이 동작되게끔)을 위해 여러 대로 다중화되어 구성되어 있는 경우가 많음
     즉, 여러 서버들이 모든 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담
  2. 특정 클라이언트가 특정 서버에 종속되는 상황 방지
     HTTP가 상태를 유지하는 프로토콜이라면, 클라이언트는 자신의 상태를 기억하는 특정 서버하고만 통신

HTTP가 상태를 유지하지 않는 이유(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 스테이트리스 프로토콜은 확장성(scalability)과 견고성(robustness)을 위해 설계되었음
  • 상태를 유지하지 않는 특성은, 특정 클라이언트가 특정 서버에 종속되지 않게 하기 위해서고, 또한 서버에 문제가 생겨도 다른 서버로 대체 용이하게 하기 위해서이다.

4. 지속 연결을 지원하는 프로토콜이다.

• 비지속 연결
  • 초기의 HTTP 버전(HTTP 1.0 이하)
  • TCP 연결 수립한 후, 요청에 대한 응답을 받으면 연결 종료
  • 추가적인 요청-응답을 하기 위해서는 다시 TCP 연결 수립부터 반복
• 지속 연결(persistent connection) 또는 킵 얼라이브(keep-alive)
  • 최근 대중적으로 사용되는 HTTP 버전(HTTP 1.1 이상)
  • 하나의 TCP 연결상에서 여러 개의 요청-응답을 주고받을 수 있는 기술

비지속 연결과 지속 연결(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

HTTP 버전

1. HTTP/0.9

• 현재 거의 사용되지 않는 초창기 HTTP 버전
• 사용 가능한 메서드: GET
• 헤더 지원 X

2. HTTP/1.0

• HEAD, POST 등 GET 이외에 메서드 도입
• 헤더 지원 시작
• 공식적으로는 지속 연결 미지원

3. HTTP/1.1

• 오늘날까지 널리 사용되는 버전
• 지속 연결 공식적 지원
• 파이프라이닝, 콘텐츠 협상 기능 등 다양한 편의 기능 추가
• 메시지 본문 = 평문
• HTTP/1.1의 고질적 문제: HOL 블로킹(Head-of-line blocking)
  
  • 같은 큐에 대기하며 순차적으로 처리되는 여러 패킷이 있을 경우, 첫 번째 패킷의 처리 지연으로 인해 나머지 패킷 처리도 모두 지연되는 문제 상황

HOL 블로킹 문제(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

4. HTTP/2.0

• 오늘날까지 널리 사용되는 버전
• HTTP/1.1의 효율과 성능을 높이기 위한 버전
• 메시지 본문 = 바이너리 데이터
• 헤더 압축 전송 가능
• 서버 푸시(server push) 기능: 클라이언트가 요청하지 않았더라도 미래에 필요할 것으로 예상되는 자원 미리 전송하는 기능
• HTTP 멀티플랙싱(multiplexing)을 통한 HOL 블로킹 완화
  • 여러 스트림(stream)을 활용해 병렬적으로 메시지를 주고받는 기술
  • 요청-응답 단위는 하나의 스트림에서 이루어짐
  • 스트림별 독립적인 송수신 가능
  • 별도의 스트림을 통해 여러 데이터를 병렬적으로 주고받으며 HOL 블로킹 완화

5. HTTP/3.0

• 이전까지의 HTTP 버전 = TCP 기반 동작
• HTTP/3.0 = UDP 기반 프로토콜인 QUIC(Quick UDP Internet Connections) 기반으로 동작
• 연결형 프로토콜 기반 송수신 속도 < 비연결형 프로토콜 기반 송수신 속도 → 빠른 송수신 가능

---

HTTP 메시지 구조

﹡ HTTP 1.1 버전 기준으로 서술

• 시작 라인, 필드 라인, 메시지 본문으로 구성
  • 필드 라인은 없거나 여러 개 있을 수 있음
  • 메시지 본문은 없을 수 있음
  • 필드 라인과 메시지 본문 사이에는 빈 줄바꿈이 있음

HTTP 메시지 구조(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• HTTP 메시지는 HTTP 요청 메시지일 수도 있고, HTTP 응답 메시지일 수도 있음

1. 시작 라인(start-line)

시작 라인(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• HTTP 요청 메시지일 경우, 시작 라인 = '요청 라인'
  • 메서드(method): 클라이언트가 서버의 자원(요청 대상)에 대해 수행할 작업의 종류
    대표적으로 GET, POST, PUT, DELETE 등
  • 요청 대상(request-target): HTTP 요청을 보낼 서버의 자원
    
    • 보통 (쿼리가 포함된) URI의 경로가 명시
      ex) 클라이언트가 "http://www.example.com/hello?q=world"로 요청 → 요청 대상은 "/hello?q=world"
    • 만약 하위 경로가 없더라도 요청 대상은 슬래시(/)로 표기
      ex) 클라이언트가 "http://www.example.com"으로 요청 → 요청 대상은 "/"
  • HTTP 버전(HTTP-version): 사용된 HTTP 버전
    • 'HTTP/<버전>'이라는 표기 방식을 따르며, HTTP 버전 1.1은 HTTP/1.1로 표기

요청 라인(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

• HTTP 응답 메시지일 경우, 시작 라인 = '상태 라인'
  • HTTP 버전(HTTP-version): 사용된 HTTP 버전
    • 'HTTP/<버전>'이라는 표기 방식을 따르며, HTTP 버전 1.1은 HTTP/1.1로 표기
  • 상태 코드(status code): 요청에 대한 결과를 나타내는 세 자리 정수
  • 이유 구문(reason phrase): 상태 코드에 대한 문자열 형태의 설명
  • ex) HTTP/1.1 200 OK, HTTP/1.1 404 Not Found

응답 라인(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

2. 필드 라인 또는 헤더 라인(header-line)

헤더 라인(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 0개 이상의 HTTP 헤더(HTTP header) 명시
• HTTP 헤더: HTTP 통신에 필요한 부가 정보
• 콜론(:)을 기준으로 헤더 이름(header-name)과 하나 이상의 헤더값(header-value)으로 구성

3. 메시지 본문(message-body)

메시지 본문(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• HTTP 요청 혹은 응답 메시지에서 본문이 필요할 경우 선택적으로 메시지 본문에 명시
• 다양한 콘텐츠 타입이 사용 가능

---

HTTP 메서드

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

 

1. GET - 가져다주세요

• 특정 자원을 조회할 때 사용되는 메서드 (ex: 웹 브라우저 URL 입력)
  • 클라이언트가 서버에게 '이것을 가져다주세요'라 요청 보내는 것과 같음
  • '이것' = 자원 (HTML, JSON, 이미지 파일이나 일반 텍스트 파일 등)
• 요청 메시지 
  ex) http://www.example.com/example-page에 대한 간략화된 GET 요청 메시지
  ﹡ GET 요청 메시지에서는 메시지 본문보다 쿼리 문자열이 사용되는 경우가 많음
  • Host: 요청을 보내는 대상

GET 요청 메시지 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 응답 메시지: GET 요청 메시지가 성공적으로 처리되었다면 이에 대한 응답으로서 요청한 자원을 전달받음

GET 요청 성공에 대한 응답 메시지 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

2. HEAD - 헤더만 가져다주세요

• HEAD 메서드를 사용하면 서버는 요청에 대한 응답으로 응답 메시지의 헤더만을 반환
• 요청 메시지
  ex) http://www.example.com/example-page에 대한 HEAD 요청을 보낸 예시

HEAD 요청 메시지 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 응답 메시지

HEAD 요청 성공에 대한 응답 메시지 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

3. POST - 처리해 주세요

• 서버로 하여금 특정 작업을 처리하도록 요청하는 메서드
  ex) 게시판 글 작성, 댓글 작성, 이미지 업로드 등
• 요청 메시지: 처리할 대상은 흔히 메시지 본문으로 명시

POST 요청 메시지 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 많은 경우 '클라이언트가 서버에 새로운 자원을 생성하고자 할 때' 사용
• 새로운 자원이 생성시 서버는 응답 메시지의 Location 헤더를 통해 새로 생성된 자원의 위치를 알려줌

POST 응답 메시지(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

PUT - 덮어써 주세요

• 요청 자원이 없다면 메시지 본문으로 자원을 새롭게 생성
• 요청 자원이 존재한다면 메시지 본문으로 자원을 완전히 대체

PUT 메서드 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

PATCH - 일부 수정해 주세요

• PUT 메서드 ≒ 덮어쓰기/대체, PATCH 메서드 ≒ 부분적 수정
• 메시지 본문에 맞게 자원 일부 수정

PATCH 메서드 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

DELETE - 삭제해 주세요

• 특정 자원을 삭제하고 싶을 때 사용
• 요청 메시지
  ex) example.com/texts/a.txt라는 자원을 삭제하도록 요청하는 메시지

DELETE 요청 메시지 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

 

※ 개발자 입장에서 HTTP 메서드는 설계의 대상이다. 어떤 메서드는 구현할 수도 있고, 어떤 메서드는 구현하지 않을 수도 있음.

같은 URL에 대해 메서드별 동작을 여러 개 구현할 수도 있음

---

HTTP 상태 코드

• 상태 코드는 요청에 대한 결과를 나타내는 세 자리 정수로, 상태 코드의 종류는 백의 자리 수를 기준으로 유형을 구분

상태 코드	설명
100번대(100~199)	정보성 상태 코드
200번대(200~299)	성공 상태 코드
300번대(300~399)	리다이렉션 상태 코드
400번대(400~499)	클라이언트 에러 상태 코드
500번대(500~599)	서버 에러 상태 코드

 

200번대: 성공 상태 코드

• '요청이 성공했음'을 의미
• 주요 상태 코드
  • 200(OK): ex) 'http://example.com/images/a.pn'로 GET 요청을 성공적으로 보낸 경우
  • 201(Created)
    • POST 요청으로 서버에 새로운 자원을 생성한 경우 상태 코드 201 응답
    • 이때, Location 헤더를 통해 생성된 자원의 위치를 명시
  • 202(Accepted): 요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않았음
    • 요청 결과를 곧바로 응답하기 어려운 경우
    • ex) 작업 시간이 긴 대용량 파일 업로드 작업, 배치 작업과 같이
  • 204(No Content): 요청을 잘 받았고, 마땅히 본문으로 표현할 것이 없음 ex) DELETE 메서드 요청

상태 코드	이유 구문	설명
200	OK	요청이 성공했음
201	Created	요청이 성공했으며, 새로운 자원이 생성되었음
202	Accepted	요청을 잘 받았으나, 아직 요청한 작업을 끝내지 않았음
204	No Content	요청이 성공했지만, 메시지 본문으로 표시할 데이터가 없음

 

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

• 리다이렉션(redirection): '요청을 완수하기 위해 추가적인 조치가 필요한 상태'로, 클라이언트가 요청한 자원이 다른 곳에 있을 때, 클라이언트의 요청을 다른 곳으로 이동시키는 것

리다이렉션(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

1) 영구적인 리다이렉션(permanent redirection): 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정
이 경우 기존의 URL에 요청 메시지를 보내면 항상 새로운 URL로 리다이렉션

상태 코드	이유 구문	설명
301	Moved Permanently	영구적 리다이렉션: 재요청 메서드 변경될 수 있음
308	Permananet Redirect	영구적 리다이렉션: 재요청 메서드 변경되지 않음

• 영구적인 리다이렉션의 경우, 클라이언트, 웹 크롤러 등이 기존의 URL을 기억할 필요가 없기 때문에 검색 엔진 혹은 크롤러 등에 영향을 끼칠 가능성이 있음
• 클라이언트가 서버에 GET 요청 메시지를 전송하고,
  301 혹은 308 응답을 받은 후,
  응답 메시지의 Location 헤더에 명시된 경로로 재요청을 보낼 경우,
  클라이언트가 보내는 두 번째 요청 메서드는 첫 번째 요청 메서드와 동일한 GET이 됨
• 클라이언트가 서버에 POST 요청 메시지(GET 메서드가 아닌 요청 메시지)를 전송하고, 
  301 응답을 받은 후,
  응답 메시지의 Location 헤더에 명시된 경로로 재요청을 보낼 경우,
  클라이언트가 보내는 두 번째 요청 메서드는 GET 요청으로 바뀔 '수도' 있음

301과 308 상태 코드(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

2) 일시적인 리다이렉션(temporary redirection): 자원의 위치가 임시로 변경되었거나 임시로 사용할 URL이 필요한 경우에 주로 사용

어떤 URL에 대해 일시적인 리다이렉션 관련 상태 코드를 응답받았다면 여전히 요청을 보낸 URL은 기억!

상태 코드	이유 구문	설명
302	Found	일시적 리다이렉션: 재요청 메서드 변경될 수 있음
303	See Other	일시적 리다이렉션: 재요청 메서드 GET으로 변경
307	Temporary Redirect	일시적 리다이렉션: 재요청 메서드 변경되지 않음

307과 303 상태 코드(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

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

• '클라이언트에 의한 에러가 있음'을 알려 주는 상태 코드

상태 코드	이유 구문	설명
400	Bad Request	클라이언트의 요청이 잘못되었음
401	Unauthorized	요청한 자원에 대한 유효한 인증이 없음
403	Forbidden	요청이 서버에 의해 거부됨(ex: 접근 권한이 없을 경우)
404	Not Found	요청받은 자원을 찾을 수 없음
405	Method Not Allowed	요청한 메서드를 지원하지 않음

• 400(Bad Request): 클라이언트의 요청이 잘못되었음을 알려 주는 상태 코드

400 코드(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 401(Unauthorized): 특정 자원에 접근하기 위해 인증이 필요한 경우, 요청에 대한 인증이 필요할 경우 서버는 401(Unauthorized) 상태 코드 응답
  • 서버가 상태 코드 401(Unauthorized)로 응답할 때는 반드시 WWW-Authenticate라는 헤더를 통해 인증 방법을 알려 주어야 함

401 코드(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 403(Forbidden): 클라이언트의 권한이 충분하지 않을 경우의 상태 코드

인증(Authentication) 여부 vs 권한 여부(Authorization) 여부
- 인증: 자신이 누구인지 증명하는 것
- 권한 여부/인가: 인증된 주체에게 작업을 허용하는 것

• 404(Not Found): 접근하고자 하는 자원이 존재하지 않음을 알리는 상태코드
  • 존재하지만 공개하지 않는 자원에 대해 404(Not Found)를 응답하는 경우도 있음
• 405(Method Not Allowed): 구현되지 않은 메서드로 요청을 보낼 경우

405 코드(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

 

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

• 클라이언트가 올바르게 요청을 보냈을지라도 발생할 수 있는 서버 에러에 대한 상태 코드

상태 코드	이유 구문	설명
500	Internal Server Error	요청을 처리할 수 없음
502	Bad Gateway	중간 서버의 통신 오류
503	Service Unavailable	현재 요청을 처리할 수 없으나 추후 가능할 수도 있음

• 500(Internal Server Error): '서버의 예기치 못한 상황으로 요청을 처리할 수 없음'
  • 상태 코드 500은 서버 내 에러를 통칭
• 502(Bad Gateway): 클라이언트와 서버 사이에 위치한 중간 서버의 통신 오류를 나타내는 상태 코드

502 상태(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 503(Service Unavailable): '현재 서비스를 일시적으로 이용할 수 없음'
  • 서버가 과부하 상태에 있거나 일시적인 점검 상태일 때 볼 수 있는 상태

---

HTTP 헤더와 HTTP 기반 기술

HTTP 헤더

• 필드 이름(헤더 이름)과 필드 값(헤더 값)이 콜론(:)을 기준으로 구분
• 헤더 유형
  • 특별한 사전 지식이 필요하지 않은 헤더
  • 사전 지식이 필요한 헤더 ex) 캐시, 쿠키, 콘텐츠 협상 관련 헤더

HTTP 메시지 구조(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

[특별한 사전 지식이 필요하지 않은 헤더]

 

1. HTTP 요청 시 주로 사용되는 헤더

• Host: 요청을 보낼 호스트를 나타내는 헤더, 주로 도메인 네임 명시, 포트 번호가 포함되어 있을 수 있음
  ex) http://info.cern.ch/hypertext/WWW/TheProject.html에 접속할 때의 HTTP 요청 메시지의 일부

Host(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• User-Agent: HTTP 요청을 시작하는 클라이언트 측의 프로그램 ex) 웹 브라우저
  • User-Agent 헤더: 요청 메시지 생성에 관여한 클라이언트 프로그램과 관련된 다양한 정보 명시

User-Agent(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• Referer: 클라이언트가 요청을 보낼 때 머무르고 있던 URL이 명시
  
  • 클라이언트의 유입 경로를 파악
    ex) Referer: https://en.wikipedia.org/
• Authorization: 클라이언트의 인증 정보를 담는 헤더
  • 인증 타입(type)과 인증을 위한 정보(credentials) 명시
    → Authorization: <type> <credentials>
  • 인증 타입에 따라 인증 정보에 명시될 값이 달라짐
  • 가장 기본적인 HTTP 인증 타입은 Basic
    • username:password를 Base64 인코딩한 값을 인증 정보로 삼는 방식
  • Basic 이외에도 Token 인증 타입인 Bearer도 존재함

2. HTTP 응답 시 주로 사용되는 헤더

• Server: 요청을 처리하는 서버 측의 소프트웨어와 관련된 정보 명시
  ex) 'Unix 운영체제에서 동작하는 아파치 HTTP 서버'를 의미하는 헤더 → Server: Apache/2.4.1 (Unix)
• Allow: 클라이언트에게 허용된 HTTP 메서드 목록을 알려주기 위해 사용
  • 상태 코드 405(Method Not Allowed)를 응답하는 메시지에서 Allow 헤더가 함께 사용
• Retry-After: 상태 코드 503(Service Unavailable)과 함께 사용될 수 있는 헤더
  • 자원을 사용할 수 있는 날짜 혹은 시각을 나타냄
    ex) '2024년 8월 23일 금요일 09시 이후에 사용 가능함' → Retry-After: Fri, 23 Aug 2024 09:00:00 GMT
    '120초 이후에 사용 가능함' → Retry-After: 120
• Location: 클라이언트에게 자원의 위치를 알려 주기 위해 사용되는 헤더
  • 주로 리다이렉션이 발생했을 때나 새로운 자원이 생성되었을 때 사용
• WWW-Authenticate: 상태 코드 401(Unauthorized)과 함께 사용되는 헤더
  • 자원에 접근하기 위한 인증 방식을 설명
    ex) WWW-Authenticate: Basic

Authorization과 WWW-Authenticate 헤더를 통한 HTTP 인증(Basic 인증) 과정

① 인증되지 않은 클라이언트가 서버에 GET 요청 메시지를 전송
② 서버는 401(Unauthorized)과 함께 WWW-Authenticate 헤더를 통해 인증 방식을 알림
③ 클라이언트는 사용자로부터 인증 정보(사용자 아이디와 비밀번호)를 전달받음
④ 클라이언트는 Base64 인코딩한 값을 Authorization 헤더를 통해 요청 메시지를 전송
⑤ 서버는 인증 정보를 확인
⑤ 인증이 유효하면 상태 코드 200으로 응답하고, 인증되지 않았으면 상태 코드 401로 응답

 

요청과 응답 모두에서 활용되는 HTTP 헤더

• Date: 메시지가 생성된 날짜와 시각에 관련된 정보를 담은 헤더
  ex) Date: Tue, 15 Nov 1994 08:12:31 GMT
• Connection: 클라이언트의 요청과 응답 간의 연결 방식을 설정하는 헤더
  • 지속 연결이 Connection에 명시되는 대표적인 연결 방식
  • 가장 대표적으로 사용되는 값은 keep-alive와 close

Connection(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• Content-Length: 본문의 바이트 단위 크기(길이)
  ex) Content-Length: 100
• Content-Type, Content-Language, Content-Encoding: 메시지 본문의 표현 방식을 설명하는 헤더,
  표현 헤더(reperesentation header)의 일종
  • Content-Type 헤더: 메시지 본문에서 사용된 미디어 타입
    ex) png, html 등
  • Content-Language 헤더: 메시지 본문에서 사용된 자연어를 명시,
    - 언어 태그로 명시: 하이픈(-)으로 구분된 구조
    - 일반적으로 첫 번째 서브 태그 = 언어 코드, 두 번째 서브 태그 = 국가 코드
    - 언어 코드-국가 코드의 조합 = "어떤 국가에서 사용하는 어떤 언어"
    ex) ko-KR, en-GB, en-US
  • Content-Encoding 헤더: 메시지 본문을 압축하거나 변환한 방식

Content-Encoding 헤더(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

---

HTTP 기반 기술

1. 캐시

응답 받은 자원의 사본을 임시 저장하는 기술

• 추후 동일한 요청에 대해 캐시된 데이터를 활용할 수 있음
• 불필요한 대역폭 낭비 방지, 응답 지연 방지
• 빠른 자원 접근 가능
• 개인 전용 캐시(private cache): 웹 브라우저에 저장
• 공용 캐시(public cache): 클라이언트와 서버 사이에 위치한 중간 서버에 저장
• 캐시는 '사본'이기 때문에 신선도의 검사와 유지 필요
  • 캐시된 데이터는 얼마든지 원본 데이터와 달라질 수 있음
  • 캐시 신선도: 캐시된 사본 데이터가 얼마나 최신 원본 데이터와 유사한지를 표현으로,
    - 캐시 신선도가 높을수록 클라이언트는 최신 정보를 임시 저장한 상태라는 것을 의미

캐시 신선도 검사: 유효 기간 설정 → 기간이 만료되었다면 원본 데이터를 다시 요청

• 응답 메시지의 Expires 헤더(날짜)와 Cache-Control 헤더의 Max-Age 값(초)을 사용
  ex) 캐시의 유효 시간을 2024년 2월 6일 화요일 12:00:00로 설정, 또는 1200초로 설정하는 응답 메시지

유효 기간 설정 방법(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 유효 기간이 끝났어도 서버의 원본 데이터가 변화하지 않았다면, 캐시된 데이터를 사용해도 됨. 이를 검사하기 위해 클라이언트는 캐시 신선도의 재검사를 수행함

캐시 신선도 재검사

1) If-Modified-Since 헤더: 날짜를 기반으로 서버에게 물어보는 방법

• If-Modified-Since 헤더에 명시된 시점 이후로 원본에 변경이 있었다면 그때만 새 자원으로 응답하도록 서버에게 요청하는 헤더

캐시 신선도 재검사 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 서버의 Last-Modified 헤더: 상태 코드 304(Not Modified)를 통한 자원의 '변경 여부'뿐만 아니라, 자원이 마지막으로 수정된 시점도 알려줄 수 있음

Last-Modified 헤더 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

2) If-None-Match 헤더: 엔티티 태그(Etag)를 기반으로 서버에게 물어보는 방법

• Etag는 '자원의 버전'을 식별하기 위한 정보
  • 버전(version): '유의미한 변경 사항'
  • 즉, 자원이 변경될 때마다 자원의 버전을 식별하는 Etag 값이 변경
  • 반대로 자원이 변경되지 않았다면 Etag 값도 변경되지 않음 → 304(Not Modified) 상태 코드 반환

Etag를 활용한 신선도 검사(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• '이 Etag 값과 일치하는 자원이 있는가?', '혹시 Etag 값이 abc인 www.example.com/index.html이라는 자원이 있는가? 자원이 변경되었다면(Etag 값이 바뀌었다면) 그때만 새 자원으로 응답하라'와 같이 신선도 검사

If-None-Match 헤더를 통해 신선도 검사 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

2. 쿠키(Cookie)

• HTTP는 상태를 유지하지 않는 스테이트리스한 프로토콜임
• 서버에서 생성되어 클라이언트 측에 저장되는 데이터
  • 상태를 유지하지 않는 HTTP의 특성을 보완하기 위한 수단
  • 기본적으로 <이름, 값> 쌍의 형태, 추가로 다양한 속성을 가질 수 있음
• 서버는 쿠키를 생성하여 클라이언트에게 전송
• 클라이언트는 전달받은 쿠키를 저장해 두었다가 추후 요청 메시지에 쿠키를 포함하여 전송
• 쿠키를 통해 요청이 같은 클라이언트에서 왔는지, 로그인 상태를 유지하고 있는지 등을 알 수 있음

 

[쿠키를 활용하는 인증 기술, 세션 인증]

• HTTP는 스테이트리스 프로토콜
  • 같은 클라이언트가 서버에 여러 번 요청을 보낸다고 해도, 기본적으로 서버는 모든 요청들을 별개의 요청으로 간주
  • 클라이언트가 서버에 요청 메시지를 보낼 때마다 (아이디, 비밀번호와 같은) 인증 정보를 보내고 번거로운 인증 과정을 거쳐야 하는 것인가?
  • 그럴 필요 없음! 쿠키를 활용하는 기술 존재
• 세션 아이디(session id)와 세션 인증(session authentication)
  ① 클라이언트는 서버에게 (아이디, 비밀번호와 같은) 인증 정보를 전송
  ② 인증 정보가 올바르다면, 서버는 세션 아이디를 생성해 클라이언트에게 전송
  ③ 서버는 생성한 세션 아이디를 데이터베이스 등에 저장
  ④ 클라이언트는 추후 요청을 보낼 때 쿠키 내에 세션 아이디를 포함하여 전송
  ⑤ 서버는 쿠키 속 세션 아이디와 저장된 세션 아이디를 비교하여 클라이언트를 식별
  → 요청을 보낼 때마다 번거로운 인증 과정을 거칠 필요가 없음
• 서버의 쿠키 생성 - 클라이언트의 쿠키 활용
  
  • 응답 메시지의 Set-Cookie 헤더, 요청 메시지의 Cookie 헤더 활용
• 응답 메시지의 Set-Cookie 헤더
  • 쿠키의 이름, 값과 더불어 세미콜론(;)으로 구분되는 속성(들)을 전달
  • 한 응답 메시지에 전달할 쿠키가 여러 개라면 다음과 같이 여러 개의 Set-Cookie

응답 메시지의 Set-Cookie 헤더(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 요청 메시지의 Cookie 헤더
  • 서버에 전달할 쿠키의 이름과 값을 나타내는 헤더
  • 여러 개의 쿠키 값을 서버에 전달해야 할 때는 세미 콜론(;)을 사용

요청 메시지의 Set-Cookie 헤더(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 쿠키는 브라우저에서 저장되고 관리됨
  
  • 크롬 브라우저에서 개발자 도구를 열고, [Application] → [Storage] → [Cookies]

 

[쿠키의 속성 값]

쿠키의 속성값(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 쿠키는 사용 가능한 도메인이 정해져 있음
  
  • www.naver.com에게 받은 쿠키를 전혀 다른 웹 사이트인 www.google.com에게 전송하면 안됨
  • 응답 메시지 속 Set-Cookie 헤더의 'domain' 속성으로 정함

쿠키의 도메인(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 같은 도메인이라도 경로별로 쿠키를 구분하여 사용하고 싶을 경우
  • ex) www.example.com/lectures를 포함한 하위 경로에서 사용하고자 하는 쿠키와 www.example.com/books를 포함한 하위 경로에서 사용하고자 하는 쿠키를 구분하고 싶을 경우
  • 'path' 속성으로 쿠키가 적용될 경로를 명시: 지정된 경로 + 하위 경로에서 쿠키 활용

쿠키의 path(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 쿠키 유효 기간
  • Expires 속성을 통해 쿠키 만료 시점 지정
  • Max-Age 속성을 통해 초 단위 유효 기간 지정

쿠키의 유효기간(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

[쿠키의 한계와 보안 기술]

쿠키의 한계

• 쿠키의 대표적인 한계는 보안이다.
• 쿠키 정보는 쉽게 노출되거나 조작될 수 있음

Secure와 HttpOnly

• Secure: HTTPS 프로토콜이 사용되는 경우에만 쿠키 전송
• HttpOnly: HTTP 송수신을 통해서만 쿠키를 이용하도록 제한하는 속성
  • 쿠키 관련 데이터는 자바스크립트 언어를 통해서도 접근 가능
  • HttpOnly는 자바스크립트에서 쿠키에 접근하지 못하도록 하는 속성

쿠키와 유사한 웹 스토리지: 로컬 스토리지와 세션 스토리지
클라이언트가 저장하고 클라이언트의 상태를 추측할 수 있는 <키-값> 쌍 형태의 정보
- 웹 스토리지는 웹 브라우저 내에 저장, 일반적으로 쿠키보다 더 큰 데이터 저장 가능
- 쿠키는 서버로 자동 전송되지만, 웹 스토리지의 정보는 서버로 자동 전송 X
- 웹 스토리지 종류에는 로컬 스토리지와 세션 스토리지 존재
- 로컬 스토리지(local storage): 별도로 삭제하지 않는 한 영구적으로 저장이 가능한 정보
- 세션 스토리지(session storage): 세션이 유지되는 동안(브라우저가 열려 있는 동안) 유지되는 정보

 

3. 콘텐츠 협상

같은 URI에 대해 가장 적합한 '자원의 형태'를 제공하는 메커니즘

• 같은 URI로 식별 가능한 HTML 문서라 해도, 영어로 요청하면 영어로 된 형태를 제공, 한국어로 요청하면 한국어로 된 형태 제공
• 자원의 표현(representation): 송수신 가능한 자원의 형태
  • 즉, 콘텐츠 협상은 클라이언트에게 가장 적합한 자원의 표현을 제공하는 메커니즘

• GET 메서드의 정의: '자원의 특정 표현을 습득하기 위한 메서드'
• 콘텐츠 협상 관련 HTTP 헤더
  • Accept 헤더: 선호하는 미디어 타입
  • Accept-Language: 선호하는 언어
  • Accept-Charset 및 Accept-Encoding: 선호하는 문자 인코딩과 압축 방식
  • ex) 클라이언트가 선호하는 언어가 한국어 및 클라이언트가 HTML 문서 타입을 선호

콘텐츠 협상 관련 HTTP 헤더 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 선호도에 우선순위 반영 가능
  ex) '언어는 한국어를 가장 선호하지만, 영어도 받을 용의가 있다.'
  '미디어 타입은 HTML 문서를 가장 선호하고, XML을 다음으로 선호하고, 일반 텍스트를 다음으로 선호한다'
  • 우선순위는 콘텐츠 협상 관련 헤더의 q값으로 표현(q는 Quality Value의 약자)
    • 값이 클수록 우선순위가 높음
    • 생략되었을 경우에는 1을 의미
    • 범위는 0부터 1까지
  • ex) 한국어(ko-KR, ko), 영어(en-US, en)순으로 선호하고, HTML, XML, 일반 텍스트 순으로 선호

콘텐츠 협상 관련 HTTP 헤더를 우선순위 반영(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

---