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

담·2024년 8월 13일
네트워크컴퓨터공학
0

컴퓨터공학

목록 보기
11/12
post-thumbnail

DNS와 자원

도메인 네임

  • IP주소와 대응되는 문자열 형태의 호스트 특정 정보이며, 네임 서버가 관리한다.
  • 사용자가 상대 호스트를 특정하기 위해 IP 주소보다는 도메인 네임을 많이 사용한다.

DNS

도메인 네임과 네임 서버

  • 계층적이고 분산된 도메인 네임에 대한 관리 체계이자 이를 관리하는 프로토콜
  • 도메인 네임과 IP 주소는 네임서버에서 관리, 도메인 네임을 관리하는 네임 서버는 DNS 서버라고 불림

네트워크 상에서 호스트를 특정 지을 수 있는 주소

  • MAC 주소
  • IP 주소

전화번호와 유사함

모든 전화번호를 외우기 힘들며 언제든 변경될 수 있다.

⇒ IP/MAC 주소를 알고있기란 어려우며 언제든지 바뀔 수 있다.

  • 전화번호부와 유사한 기능을 수행하는 DNS
  • 사람이 기억하기 쉬운 도메인 이름과 호스트를 특정 지을 주소를 매핑

*도메인 : 호스트에 부여되는 문자열 이름 (e.g. fastcampus.co.kr)

  • hosts 파일 = 개인 전화번호부
    • 모든 전화번호부를 관리하기 어렵다.

  • 계층적 도메인 구조

    • 루트 네임 서버 : 점(.), 생략하여 표기에 대개 최상위 도메인을 ‘도메인 네임의 마지막 부분’으로 간주
    • TLD (Top Level Domain: 최상위 도메인) DNS 서버 : com, net, org, kr, jp, cn, us, doctor, lawyer, company 등
    • Second Level Domain_2단계 도메인 : www.example.com에서 ‘example’
    • Third Level Domain_3단계 도메인 : www.example.com에서 ‘www’
      • 도메인 단계는 더 늘어날 수 있으며 일반적으로 3~5단계 도메인 정도 이다.

  • 전체 주소 도메인 네임(FQDN_Fully-Qualified Domain Name) : 도메인 네임을 모두 포함하는 도메인 네임

    • 호스트 네임 : FQDN 자체를 가리키기도 하며, 때로는 네트워크 상의 장치 자체의 이름을 가리키는데 사용되기도함 : www.example.cim에서 첫 번째 부분(www)

  • 서브 도메인(하위 도메인)

계층적 네임 서버

계층적인 도메인 네임을 효율적으로 관리하기 위해 네임 서버 또한 계층적인 형태를 이룬다.

  • 도메인 네임 풀이(resolve), 리졸빙하다 :
    • IP 주소를 모르는 상태에서 도메인 네임에 대응되는 IP주소를 알아내는 과정
    • 리졸빙(풀이)하기 위해 사용되는 네임 서버의 유형 :
      로컬 네임 서버, 루트 네임 서버, TLD 네임 서버, 책임 네임 서버가 있다.
  • 로컬 네임 서버(local name Server)
    • 클라이언트와 맞닿아 있는 네임 서버
    • 클라이언트가 도메인 네임을 통해 IP주소를 알아내고자 할 때 가장 먼저 찾게되는 네임 서버
    • 일반적으로 ISP 에서 할당해 주는 경우가 많다.
      • 공개 DNS서버를 이용할수도 있다. (구글의 8.8.8.8, 8.8.4.4 / 클라우드플레어의 1.1.1)
  • 루트 네임 서버
    • 로컬 네임 서버가 대응되는 IP 주소를 모를때, 해당 도메인 네임을 질의한다.
    • 루트 도메인을 관장하는 네임 서버
    • 질의에 대해 TLD 네임 서버의 IP주소를 반환할 수 있다.
  • TLD 네임 서버
    • TLD 를 관리하는 네임 서버
    • 질의에 대해 하위 도메인 네임을 관리하는 네임 서버 주소를 반환할 수 있다.
  • 책임 네임 서버 (authoritative name server)
    • 도메인 영역을 관리하는 네임서버
    • 자신이 관리하는 도메인의 영역의 질의 에 대해서는 다른 네임 서버에 떠넘기지 않고 곧바로 답할 수 잇는 서버
    • 마지막으로 질의하는 서버

로컬 네임 서버가 네임 서버에게 질의하는 방법

  • 재귀적 질의
    • 클라이언트 → 로컬 네임 서버 → 루트 네임 서버 → 루트 네임 서버 → TLD 네임 서버 → 다음 단계 질의
    • 과정을 반복하며 최종 읍답 결과를 역순으로 전달받는 방식

  • 반복적 질의
    • 클라이언트 → 로컬 네임 서버 → 루트 네임서버 → 로컬 네임 서버 (응답 받음) → TLD 네임 서버 → 로컬 네임 서버 (응답 받음) → 책임 네임 서버 → 로컬 네임 서버 (응답 받음)
    • 과정을 반복하다가 최종 응답 결과를 클라이언트에게 알려주는 방식

서버가 저장하는것 : DNS 레코드 (자원 레코드)

  • A 레코드 : 도메인에 대한 IPv4 주소
  • AAAA 레코드 : 도메인에 대한 IPv6 주소
  • CNAME 레코드 : 도메인에 대한 별칭
  • NS 레코드 : 네임 서버 주소
  • SOA 레코드 : 도메인에 대한 관리자 정보
  • 네임 서버의 과부하를 줄이기 위해 DNS 캐시 사용
    • 네임 서버들이 기존에 응답받은 결과를 임시로 저장했다가 추후 같은 질의에 활용한다.
    • TTL 기간동안 DNS 저장

자원과 자원의 식별

네트워크 상에서의 ‘자원’

  • 두 호스트가 네트워크상를 통해 서로 정보를 주고받을때, 송수신하는 대상
    • 네트워크로 주고받을 수 있는 모든 정보
    • 파일, 이미지, 동영상, HTML, XML, JSON …
  • 자원을 요청하고 요청한 자원을 응답하려면 자원을 식별(identify)할 수 있어야 한다.
    • URI (Uniform Resource Identifier) : 자원을 식별하는 통일된 방식

URI

  • 자원을 식별할 수 있는 정보를 의미
  • 식별 방법으로 위치 기반의 URL과 이름 기반의 URN

URI 분류

  • URI는 위치 혹은 이름으로 분류 가능하다
    • URL : 위치 기반 자원 식별(Locator)
    • URN : 이름 기반 자원 식별 (Name)

URL 구성 요소

  • scheme
    • 일반적으로 프로토콜 이름 명시 (자원에 접근하는 방법)
    • http:// , https://
  • authority
    • = [userinfo”@”] host [”:” port]
      • 사용자 이름을 이용한 인증 가능(생략가능)
      • 호스트를 특정할수 있는 정보 (IP 주소, 도메인 네임)
      • 포트 번호 (생략가능)
  • path
  • query
    • 쿼리 문자열(query string), 쿼리 파라미트(query parameter)
    • <키=값> 형태로 서버에 전달할 문자 형태의 파라미터
    • ?로시작, &(앰퍼샌드) 로 다수의 query 로 구분
  • fragment
    • 자원의 조각(fragment)를 가리키는 데에 사용 (#로 구분)
    • 흔히 HTML 파일과 같은 자원에 특정 부분을 가리키기 위해 사용된다.

URN

  • 자원에 고유한 이름을 붙이는 이름 기반 식별자
  • 위치나 프로토콜과 무관하게 자원을 식별할 수 있다.

웹 서버와 웹 어플리케이션 서버

  • 서버 : 대답response하는 대상
  • 클라이언트 : 요청request 하는 대상

서버

  • 웹 서버 : apache, ngnx 등

  • 웹 어플리케이션 서버 (WAS) : Apache Tomcat , IBM, WebSphere 등

  • 서버가 응답해야 하는 자원

    • 정적인 자원 :
      • 언제/어디서/누가 봐도 변하지 않는 정보
      • HTML, 이미지, 동영상 등
    • 동적인 자원 :
      • 언제/어디서/누가 보는지에 따라 변할 수 있는 정보
      • 주로 데이터베이스 사용

  • 웹 서버와 웹 어플리케이션은 사용하는 이점

    • 과도한 부하 방지
    • 보안 상의 이점
    • 여러 웹 어플리케이션 서버 연동 용이

HTTP

HTTP (Hypertext Transfer Protocol)는 응용 계층에서 정보를 주고받는 데 사용되는 프로토콜

HTTP 특성

1. 요청 - 응답 기반의 프로토콜이자, 클라이언트 -서버 구조 프로토콜

  • HTTP 클라이언트 (HTTP 요청 메시지)
  • HTTP 서버 (HTTP 응답 메시지)
  • 서버간에도 HTTP 메시지를 주고받을 수 있다.

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

  • 어떤 형태의 데이터도 HTTP 메세지로 보낼 수 있다.
  • HTTP에서 메시지로 주고받는 자원의 종류를 미디어 타입(media type) 혹은 MIME 타입이라 부른다.
    • HTML, 이미지, JSON, XML, 파일, 영상, 이미지 등 가능
    • ‘타입/서브타입’ 형식으로 구성
      • tedt/html , text/javascript , text/css . image/* , video/mp4, audio/wav, application/json, multipart/form-data 등
    • 매개변수는 ‘타입/서브타입;매개변수=값’ 형식으로 구성
      • type/subtype;paramter=value

3. 비연결성 프로토콜

  • HTTP 1.0, HTTP 1.1, HTTP 2.0은 TCP 기반

TCP는 연결성 프로토콜

  • 다수의 클라이언트가 연결을 시도할 경우, 연결을 유지하는 동안 서버의 자원 소모가 너무 크다.

4. 스테이트리스 프로토콜

  • 서버는 HTTP 요청을 보낸 클라이언트와 관련된 상태를 기억하지 않는다. 그렇기 때문에 모든 요청은 독립적인 요청으로 간주된다.

스테이트풀 프로토콜일 경우

  • 클라이언트는 한 서버에 종속 된다.
  • 여러 요청을 보내야 할 경우 한 서버에만 요청해야 한다.

서버의 IP의 변경, 장애, 여러대의 서버 등의 변수에 대해서 대응하기 어렵다.

  • 클라이언트는 한 서버에 종속될 필요가 없다. ⇒ 견고성이 높아진다.
  • 여러 번 요청을 보내야 할 경우 여러 서버에 요청 가능 ⇒ 서버의 확장이 용이해진다.

5. 지속 연결 프로토콜

  • Keep-Alive
  • 연결 할때 마다 3-way handshake를 진행한다면, (HTTP 1.0 이하)
    • 혼잡 증가
    • 시간 지연 증가(handshake, slow start 시간 존재)
  • 하나의 연결을 사용해 여러 개의 HTTP 요청 / 응답 주고받기

HTTP 버전별 특성

  • HTTP 0.9: 단일한 요청 방법(GET 메서드), 비지속 연결, 별다른 기능 X
  • HTTP 1.0: 다양한 요청 방법과 헤더 추가
  • HTTP 1.1: 지속 연결 기능 추가
  • HTTP 2.0: 요청 순서대로 응답을 반환할 필요 없음, 헤더 압축
  • HTTP 3.0: UDP 기반 프로토콜인 QUIC로 변경

HTTP 메시지

  • 구조 : 시작 라인, 필드 라인, 메시지 본문

HTTP 시작 라인

  • 요청 메시지일 경우 : 요청 라인
    • HTTP 메서드 (공백) 요청 대상 (공백) HTTP 버전 (개행)
      • 메서드 : 클라이언트가 서버의 자원(요청 대상)에 대해 수행할 작업의 종류
      • 요청 대상 : HTTP 요청을 보낼 서버의 자원
  • 응답 메시지일 경우 : 상태 라인
    • HTTP 버전 (공백) 상태 코드 (공백) 이유 구문* (개행)
      • 상태 코드 : 요청에 대한 결과를 나타내는 세 자리 정수
      • 이유 구문 : 상태 코드에 대한 문자열 형태의 설명

필드라인 (헤더 라인)

  • 0개 이상의 HTTP 헤더가 명시
  • 콜론(:)을 기준으로 헤더 이름과 하나 이상의 헤더 값으로 구성된다.

메시지 본문

  • HTTP 요청 혹은 응답 메시지에서 본문이 필요한 경우 명시된다.

HTTP 메서드

서버에게 요청할 동작 (해당 자원으로 어떤 동작을 요청할지)

  • GET :
    • 자원조회
  • POST :
    • 요청할 데이터 처리
    • 메시지 본문으로 처리할 데이터 전송
    • 메시지 본문에 해당하는 데이터 처리하도록 요청
    • 어떻게 처리할지는 서버가 결정 ( 새 자원 생성 및 가공 등)
  • PUT:
    • 자원 덮어쓰기
    • 자원이 있다면 본문으로 보낸 데이터로 대체
    • 자원이 없다면 본문으로 보낸 데이터로 생성
  • PATCH:
    • 자원 일부분 변경
  • DELETE:

    • 자원 삭제

      이외에도 HEAD, OPTIONS, TRACE, CONNECT 존재

  • 멱등성 : 여러 번 동일한 요청을 보내도 첫 요청 결과와 같은가
  • 캐시 가능성 : 응답 결과를 캐시해서 사용할 수 있는가
  • 요청대상 : 요청할 자원의 위치

HTTP 상태 코드

상태 코드설명
100 번대 (100 ~ 199)정보성 상태 코드
200 번대 (200 ~ 299)성공 상태 코드
300 번대 (300 ~ 399)리다이렉션 상태 코드
400 번대 (400 ~ 499)클라이언트 에러 상태 코드
500 번대 (500 ~ 599)서버 에러 상태 코드
  • 2XX: 성공
    • 200 OK: 요청 성공 (GET)
    • 201 Created: 요청 성공, 새로운 자원 생성됨 (POST)
    • 202 Accepted: 요청 성공, 처리는 아직 미완료
    • 204 No Content: 요청 성공, 응답할 데이터 없음
  • 3XX: 리다이렉션 (이 요청을 처리하려면 추가적인 처리가 필요함)
    • 응답의 Location 헤더를 통해 특정 위치로 이동
  • 4XX: 클라이언트 오류
    • 400 Bad Request : 클라이언트의 잘못된 요청
    • 401 Unauthorized: 미인증
    • 403 Forbidden: 금지된 자원에 접근 (자원에 접근할 권한이 없음)
    • 404 Not Found: 요청한 자원 없음 (공개한 자원이 아님)
  • 5XX: 서버 오류
    • 500 Internal Server Error: 서버 오류
    • 502 Bad Gateway: 중간 서버의 통신 오류
    • 503 Service Unavailable: 현재 이용 가능하지 않음

HTTP 헤더

header-field = field name ":" field-value

요청 시 활용되는 HTTP 헤더

  • Host : 요청을 보낼 호스트를 나타내는 헤더, 도메인 네임, 포트 포함 가능
  • User-Agent : 유저 에이전트, 클라이언트가 사용한 소프트웨어, 브라우저 명칭과 정보
    • Mozilla: 접속한 브라우저가 Mozilla와 호환된다 (대부분 포함되어 있는 정보)
    • Windows NT 10.0; Win64; x64: 윈도우 10 버전의 64비트 x64 아키텍처 사용한다
    • AppleWebKit: 브라우저를 렌더링하는 Apple의 웹킷 엔진을 사용한다
    • Chrome, Safari: 브라우저 이름과 버전
  • Referer : 클라이언트가 직전에 머물렀던 URL(이전에 참조한 페이지 혹은 리소스)
  • Authorization : 인증 정보를 담는 헤더

응답 시 활용되는 HTTP 헤더

  • Server : 서버가 사용한 소프트웨어 명칭과 정보
  • Allow : 허용된 HTTP 메서드 목록을 알려준다.
  • Retry-After : 503 상태 코드과 함께 쓰이며, 자원 을 사용할 수 있는 날짜 혹은 시각
  • Location : 리다이렉트시 이동할 경로
  • WWW-Authenticate : 401 상태 코드와 함께 쓰이며, 인증 방식을 설명하는 헤더

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

  • Date : 메세지 생성 시간 (HTTP 요청 또는 응답이 발생한 시간 _ “GMT”는 그리니치 표준시)
  • Connection : keep-alive일 경우 킵 얼라이브, 종료시에는 close
  • Content-Length: 데이터의 바이트 단위 길이
  • Content-Type:
    • HTTP 요청 및 응답에서 사용될 컨텐츠의 유형
      • text/html; charset=utf-8: HTML 문서, 인코딩 형식은 utf-8
      • application/json: JSON 형식 데이터, API Request-Reseponse에서 주로 사용
      • image/png: png 타입 이미지 데이터
      • text/plain; charset=utf-8: 텍스트 파일 데이터, 인코딩 형식은 utf-8
      • application/xml: xml 데이터
    • MIME 타입으로 명시
      • 웹 상에서 컨텐츠의 유형을 나타내기 위한 방법
        (<type/subtype> 형식으로 표기, *은 ‘모든’을 의미)일종의 웹 상에서 확장자를 나타내기 위한 방법!
      • Content-Encoding: 데이터의 인코딩/압축 방식
      • gzip: gzip 압축 (가장 대중적)
      • deflate: deflate 압축
      • br: brotli 압축
      • identity: 압축하지 않음
  • Content-Language: 데이터의 언어
    • en, en-US: 영어 : en:일반적 영어, en-US: 미국이라는 국가의 영어
    • ko, ko-KR: 한국어 : ko:일반적 한국어, ko-KR: 한국이라는 국가의 한국어
  • Content-Encoding : 메시지 본문을 압축하거나 반환한 형식

캐시

  • 서버의 지연을 줄이기 위해 웹 페이지, 이미지 등의 자원 사본을 임시로 저장하는 웹 기술
  • 캐시된 자원이 저장되는 공간 : 클라이언트(브라우저; 개인 전용 캐시) 혹은 특별한 서버 (캐시 서버, 프록시 서버; 공용 캐시)

캐시 신선도

  • 캐시된 사본 데이터가 얼마나 최신 원본 데이터와 유사한지
  • 캐시 데이터에 유효 기간을 설정
    1. Expires 헤더에 만료 날짜 설정
    2. Cache-Control 헤더의 Max-Age값으로 유효기간 초를 설정

cache-control 헤더

캐시기능을 알림

cache-control설명
max-age=숫자(초)캐시한 자원의 지속시간
no-cache캐시 가능한 자원이나, 항상 origin 서버에 검증하기
no-store캐시하면 안될 자원

Last-Modified 헤더

  • 해당 자원이 언제 마지막으로 변경되었는지를 알림
  • e.g. Last-Modified: 2023년 8월 1일 09:00:00

캐시된 자원의 변경

캐시된 자원이 될 경우의 아래의 두가지 경우가 있다.

첫 번째 경우, (날짜 기반)

  • 클라이언트 요청시 if-modified-since 헤더로 특정 시점 이후 자원 변경 여부를 묻는다.
  • 만약 변경되었다면 다시 다운로드
  • 만약 변경되지 않았다면 서버는 304 Not Modified 응답을 보낸다. (자원 변견없으니 캐시로 Redirect 진행)

두 번째 경우, (엔티티 태그 기반)

  • Etag를 통해 자원의 변경 여부 감지 가능
  • 서버는 캐시된 자원에 Etag라는 식별 문자를 붙이고,
  • 클라이언트는 If-None-Match 헤더를 통해 해당 Etag가 변경되었는지를 물어본다.
  • 서버에 의해 생성되고, 클라이언트에 의해 저장된다.
  • 서버로부터 받은 정보를 클라이언트 측(웹 브라우저)에 임시 저장되는 이름=값 형태의 데이터
  • 유효 기간이 있다.
  • 쿠키를 전송할 도메인과 경로가 정해져있다.
  • 확인 방법 : 브라우저 → 개발자 도구 → Application → Storage → Cookies
  • 서버가 Set-Cookie 헤더로 쿠키를 전달하면, 클라이언트는 쿠키를 저장하여 다음 HTTP 요청의 Cookie 헤더로 활용

쿠키의 도메인

  • Set-Cookie : domain=example.com
  • example.com(을 비롯한 서브 도메인)에 접근할 때 쿠키 활용

쿠키의 경로

  • Set-Cookie: path=/
  • path에 명시된 경로 하위 경로에서 쿠키 활용
  • ex) path =/posts (path=/posts/1 , path/posts/2 )

쿠키의 유효 기간

  • 날짜 : Set-Cookie: expires=Wed, 10 Aug 2023 12:00:00 GMT
  • 시간(초) : Set-Cookie: max-age=1000

쿠키와 세션

  • 세션 : 서버에서 저장 및 관리
  • 쿠키 : 클라이언트(브라우저)에서 저장 및 관리
  • 세션 인증
    1. 클라이언트는 서버에게 인증 정보 전송
    2. 인증 정보가 올바르다면, 서버는 세션 아이디를 생성해 클라이언트에게 전송
    3. 서버는 생성한 세션 아이디를 데이터베이스에 등에 저장
    4. 클라이언트는 추후 요청을 보낼 때 쿠키 내에 세션 아이디를 포함하여 전송
    5. 서버는 쿠키속 세션 아이디와 저장된 세션 아이디를 비교하여 클라이언트를 식별

쿠키의 보안 기능

  • Secure
    • HTTPS 인 경우에만 전송
  • HTTPOnly
    • 자바스크립트 (document.cookie)에서 접근 불가
    • XSS 공격 방지

컨텐츠 협상 Content Negotiation

  • 클라이언트가 원하는 컨텐츠를 받을 수 있도록 서버에게 부탁하는 기능
  • 컨텐츠 타입, 언어, 인코딩 방법 등 클라이언트 맞춤 컨텐츠 제공 가능
  • Accept(-X) 헤더 이용
    • Accept: 클라이언트가 선호하는 컨텐츠 타입
    • Accept-Encoding: 클라이언트가 선호하는 인코딩
    • Accept-Language: 클라이언트가 선호하는 언어
  • 여러 맞춤 요청을 보낼 수 있다.
    • Accetp:text/html , application/xml, 등
    • Quality Value 값을 기준으로 우선수위 매길 수 있다.
    • 최소 0에서 최대 1까지, 클 수록 우선순위가 높다.
    • Accept: text/html, text/plain;q=0.9, text/;q=0.8, /*;q=0.7
    • Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

5주차

진도: Chapter 05

  • 기본 숙제(필수): Ch.05(05-1) 확인 문제 1번(p.271), (05-2) 확인 문제 2번(p.307), 풀고 설명하기
  • 추가 숙제(선택): HTTP 요청 메시지 확인해 보기

기본 숙제

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

4)

  • GET 요청 메서드는 조회를 위한 메서드, 메시지 본문을 포함하지 않는 것이 적합하다.

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

1)

  • 자원이 존재하지 않을때는 400번대 상태 코드
  • 300번대 상태 코드는 리다이렉션 관련 상태 코드

추가 숙제

HTTP 요청 메시지 확인해 보기

yes24 베스트 셀러 데이터 요청에 대한 메시지를 확인해보았다.

회고

항상 사용하는 HTTP를 좀 더 깊게 배우는 계기가 되어서 좋았다.
아, 그런데 왜이렇게 이 챕터를 학습하는게 오래걸렸고 힘들었는지는 모르겠다 히히
300 번대 상태 코드는 아직도 이해가 잘 안되어서 나중에 실제 사용할 때 한 번 봐야할 것 같다.

profile
담
성실하게
이전 포스트

[혼공네트] 4주차_전송 계층

다음 포스트

[혼공네트] 6주차_안정성을 위한 기술(with. 와이어샤크로 확인하는 TCP)

0개의 댓글