CS/기타

(CS) 네트워크 - 응용 계층, HTTP의 기초와 응용

흰색텀블러 2025. 3. 28. 08:38

HTTP의 기초

 

DNS와 URI / URL

도메인 네임과 DNS

  • IP 주소의 한계점 : 특정 호스트의 특징을 나타내기 어려움 & IP 주소는 바뀔 수 있음 → 도메인 네임이 등장
  • 도메인 네임 예시 : naver.com, kernel.org등 문자열 호스트 특정 정보로, 호스트의 IP 주소와 대응
  • 네임 서버 : 도메인 네임과 그에 대응하는 IP 주소를 관리하는 서버
  • DNS 서버 : 도메인 네임을 관리하는 네임 서버
  • 호스트 : 네임 서버에 "도메인 네임 가진 호스트 IP 주소를 주세요!" → 호스트 IP 주소 얻을 수 있음 == 리졸빙 한다

 

  • 도메인 네임의 계층적 구조
    • 점(.) 을 기준으로 분류 되어있음.
    • [최상단에 루트 도메인(.) → 최상위 도메인(TLD) - kr, jp, cn ... → 2단계 도메인 → 3단계 도메인 ] == 전체 주소 도메인 네임 (FQDN)
    • 도메인 네임 시스템 (DNS)
      • 계층적으로 분산되어 있는 도메인 네임에 대한 관리 체계
      • DNS를 이용할 수 있도록 하는 어플리케이션 계층 프로토콜을 의미하기도 함
    • 도메인 네임이 네임서버를 바탕으로 리졸빙 되는 방법
      • 1. 로컬 네임 서버(클라이언트와 맞닿아 있는 네임 서버)에게 도메인 네임 질의 → 루트 도메인 관장하는 서버 → 최상위 도메인을 관장하는 서버 .... 등에 걸쳐 꾸준히 질의
      • 즉, 도메인 네임이 계층적인 구조를 띄는 것처럼, 도메인 네임의 각 구조를 관리하는 서버 또한, 계측적 구조로 관리
      • 질의 과정이 많이 반복 → 네트워크 내 트래픽 증가 → 리졸빙에 오랜 시간 걸림 → → 기존에 응답받은 결과를 임시로 저장하여, 추후 같은 질의에 활용하는 경우가 많음 → DNS 캐시라고 함.
      • DNS 캐시 사용시, 빠른 시간안에 원하는 IP 주소를 얻어낼 수 있음 → 자주 질의되는 도메인 네임의 경우, 로컬 네임 서버 선에서 캐시 되어 있음!!!!!

 

 

자원과 URI / URL

  • 자원 : 네트워크 상의 메시지를 통해 주고받는 최종 대상 (ex. HTML, image, avi, txt ...)
  • URI(Uniform Resource identifier)
    • 웹 상에서의 자원(Resource)을 식별(identifier) 하기 위한 통일된 방식(Uniform)이자 정보
    • URN(Uniform Resource Name) : 이름으로 자원을 식별하는 방식 → 고유성을 가지고 있음
    • URL(Uniform Resource Locator) : 위치로 자원을 식별하는 방식, 오늘날 많이 쓰임

http에서의 URL 구조

  • 1. scheme
    • 자원에 접근하는 방법
    • 일반적으로 사용할 프로토콜 명시 (http, https)
  • 2. authority
    • 호스트를 특정할 수 있는 IP 주소나 도메인 네임 명시
    • : 뒤에 포트 번호를 명시 할 수 있음
  • 3. path
    • 자원이 위치하고 있는 경로 명시
    • 슬래시 기준으로 계층적 표현
  • 4. query
    • URL에 대한 매개변수 역할을 하는 문자열
    • 쿼리 문자열, 쿼리 파라미터로 불림
    • DB 짤때, ~~~~/reportId=1& 이부분
  • 5. fragment
    • 자원의 한 조각을 가리키기 위한 정보
    • 일반적으로 HTML 파일과 같은 자원에서 특정 부분을 가리키는데 사용

 

HTTP의 특징과 메시지 구조

  • HTTP의 목적
    • 애플리 케이션의 다양한 자원을 네트워크를 통해 송수신 하기
    • 데이터의 형식에 구애받지 않고, 다양한 앱 데이터의 송수신을 가능하게 하는 것!!!

HTTP의 특징

  • 1. 요청 응답 기반 프로토콜
    • 클라이언트의 요청 메시지 → 응답 메시지를 보내는 서버
    • 같은 HTTP 메시지이지만, 요청, 응답 HTTP 메시지의 형태는 다름
  • 2. 미디어 독립적 프로토콜
    • 미디어 타입 : HTTP에서 메시지로 주고받는 자원의 종류 (MIME 타입이라고도 함)

미디어 타입의 형태 종류

 

  • 3. 스테이트리스 프로토콜
    • 서버는 HTTP 요청을 보낸 클라이언트 관련 상태를 기억하지 않음 → 클라이언트의 모든 HTTP 요청은 독립적인 요청으로 간주
    • 인터넷 표준 공식 문서인 RFC 9110에서 가장 먼저 강조된 특성!
    • 상태를 유지하지 않는 이유?
      • HTTP 서버는 많은 클라이언트와 동시 상호 작용 → 모든 상태 정보 유지는 서버에 부담
      • 서버가 여러대일 경우, 모든 상태정보를 공유해야하는데, 만약 못할경우, 특정 서버와 상호작용 → 종속되버림 → 통신 내역을 잃어버리는 상황 발생 가능 
    • HTTP 설계 목표는 확장성과 견고성이 있음
      • 모든 요청을 독립 처리 → 종속 X → 서버의 추가나 대체가 쉬워짐 → 확장성 증가
      • 서버 중 하나에 문제가 생기더라도 다른 서버로 대체 → 견고성 증가
  • 4. 지속 연결 프로토콜
    • 지속 연결
      • 하나의 TCP 연결 상에서 여러개의 요청-응답을 주고받을 수 있는 기술
      • 비지속 연결보다 빠른 속도로 여러 HTTP의 요청과 응답 처리 가능

 

  • HTTP 버전별 특징

 

 

HTTP 메시지 구조

  • 시작 라인

시작라인, 필드라인, 메시지 본문으로 이루어짐
필드라인 : 여러개 존재 가능
메시지 본문 : 없을 수 있으며, HTTP를 통해 주고받는 자원 명시

 

구분 필드 이름 설명
요청 라인 메서드(method) 클라이언트가 서버의 자원에 대해 수행할 작업의 종류를 나타냄
요청 대상(request-target) 요청을 보낼 서버의 자원을 명시
일반적으로 쿼리 문자열이 포함된 URL의 path가 명시
HTTP 버전(HTTP-version) 사용된 HTTP 버전으로, 'HTTP/<버전>'형식
상태라인 HTTP 버전(HTTP-version) 사용된 HTTP 버전으로, 'HTTP/<버전>'형식
상태 코드(status code) 요청에 대한 결과를 나타내는 3자리 정수
이유 구문(reason phrase) 상태 코드에 대한 문자열 형태의 설명 (200 등)

 

 

  • 필드 라인
    • HTTP 헤더 명시
    • 메시지 전송과 관련된 부가 정보이자 제어 정보임
    • 여러개의 헤더가 포함되어 있음

 

  • 요약

 

HTTP 메서드와 상태 코드

HTTP 메서드

HTTP 메서드

 

  • 1. GET 과 HEAD
    • GET : 자원을 조회하는 용도
    • 즉, 웹 브라우저를 통한 웹 페이지 조회 == GET 요청 메시지에 대한 응답
    • HEAD : 응답 메시지에 메시지 본문이 포함되지 않는다는 점 제외, GET 메서드와 동일

 

 

  • 2. POST
    • 서버로 하여금 특정 작업을 처리하도록 요청하는 용도로 사용되는 메서드
    • 일반적으로 '클라이언트가 서버에 새로운 자원을 생성하고자 할때' 사용

 

  • 3. PUT 과 PATCH
    • PUT : 덮어쓰기를 요청하는 메서드
    • PATCH : 부분 수정을 요청하는 메서드
  • 4. DELETE
    • 특정 자원의 삭제를 요청할 때 사용되는 메서드

 

HTTP 상태 코드

  • 1. 200번대 : 성공 상태 코드
상태코드 이유 구문 설명
200 OK 요청이 성공
201 Created 요청이 성공했고, 새로운 자원 생성
202 Accepted 요청은 잘받음, 아직 요청한 작업을 끝내지 않음
204 No Content 요청은 성공, 메시지 본문으로 표시할 데이터X

 

  • 2. 300번대 : 리다이렉션 상태 코드
    • 리다이렉션 : 클라이언트가 요청한 자원이 다른곳에 있을때, 다른 곳으로 요청을 이동시키는 것
      • 영구적 리다이렉션 : 자원이 완전히 새로운 것으로 이동 → 경로가 영구적으로 재지정되는 것
      • 일시적 리다이렉션 : 자원의 위치가 임시로 변경 or 임시로 사용할 URL이 필요한 경우 사
상태코드 이유 구문 설명
301 Moved Permanently 영구적 리다이렉션 - 재요청 메서드가 변경될 수 있음
308 Permanent Redirect 영구적 리다이렉션 - 재요청 메서드가 변경되지 않음
302 Found 일시적 리다이렉션- 재요청 메서드가 변경될 수 있음
303 See Other 일시적 리다이렉션 - 재요청 메서드가 GET으로 변경됨
307 Temporary Redirect 일시적 리다이렉션 - 재요청 메서드가 변경되지 않음
304 Not Modified 캐시 - 자원이 변경되지 않음

 

  • 3. 400번대 : 클라이언트 에러 상태 코드
    • 클라이언트에게 잘못이 있음을 나타내는 상태 코드
      • 401 : 인증(authentication)을 요구하는 상태 코드
        • 인증 : 자신이 누구인지를 증명하는 작업
      • 403 : 권한(authorization)을 요구하는 상태 코드
        • 권한 : 인증된 주체에게 허용된 작업
상태코드 이유 구문 설명
400 Bad Request 요청 메시지의 내용이나 형식 자체에 문제

401 Unauthorized 요청한 자원에 대한 유효한 인증이 없음
403 Forbidden 요청이 서버에 의해 거부됨 (자원에 대한 접근 권한 충분X)
404 Not Found 요청받은 자원을 찾을 수 없음
405 Method Not Allowed 요청한 메서드를 지원하지 않음

 

  • 4. 500번대 상태 코드
    • 서버에게 잘못이 있음을 나타내는 상태 코드
상태코드 이유 구문 설명
500 Internal Server Error 요청을 처리할 수 없음 (대부분 이것)
502 Bad Gateway 중간 서버의 통신 오류

 

 

HTTP 주요 헤더

요청 메시지에서 주로 활용되는 HTTP 헤더 : Host, User-Agent, Referer

  • 1. Host
    • 요청을 보낼 호스트가 명시되는 헤더
    • 도메인 네임이나 IP 주소로 표현, port number가 포함될수도 있음
  • 2. User-Agent
    • HTTP 요청을 시작하는 클라이언트 측의 프로그램 (웹 브라우저가 대표적)
    • 운영 체제, 아키텍처의 정보, 렌더링 엔진의 종류 등 명시
  • 3. Referer
    • 클라이언트가 요청을 보낼때 머무르던 URL이 명시 → 클라이언트의 유입 경로 파악 가능

응답 메시지에서 주로 활용되는 HTTP 헤더 : Server, Allow, Location

  • 1. Server
    • HTTP 응답 메시지를 보내는 서버 호스트와 관련된 정보 명시
  • 2. Allow
    • 처리 가능한 HTTP 헤더 목록을 알리기 위해 사용
  • 3. Location
    • 클라이언트에게 자원의 위치를 알려주기 위해 사용
    • 주로, 리다이렉션이 발생했을때, 새로운 자원이 생성되었을 때 사용

 

요청, 응답 메시지 모두에서 활용되는 HTTP 헤더 : Date, Content-Length, Content-Type, Content-Language, Content-Encoding, Connection

  • 1. Date
    • 메시지가 생성된 날짜와 시각 정보 담은 헤더
  • 2. Content-Length
    • 메시지 본문의 바이트 단위 크기를 표현에 사용
  • 3. Content-Type,  Content-Language, Content-Encoding
    • 메시지 본문이 어떻게 표현되었는지 관련된 헤더
    • 표현 헤더라고도 함
  • 4. Connection
    • HTTP 메시지를 송신하는 호스트가 원하는 방식의 연결을 명시하는 헤더
    • keep-alive : 지속 연결 희망 , close : 연결 종료 희 

 

HTTP의 응용

쿠키

  • HTTP의 스테이트리스한 특성을 보완하기 위한 수단
  • 서버에서 생성되며, 클라이언트 측에 저장되는 <이름, value> 쌍 형태의 데이터
  • 쿠키의 만료 기간등과 같은 속성값도 소유 가능
  • 클라이언트의 브라우저에 주로 저장

 

캐시

  • 응답받은 자원의 사본을 임시 저장하여, 대역폭 낭비및 응답 지연을 방지하는 기술
  • 원본 데이터와 캐시된 사본 데이터간의 일관성이 깨질 가능성 → 캐시에 유효기간을 부여하는 이유
  • 캐시 신선도 : 캐시도니 사본 데이터와 서버의 원본데이터의 유사한 정도
  • 만약, 서버의 원본 데이터가 변하지 않았을 경우, 캐시 유효기간이 만료되도, 새로 받을 필요는 없음!! → 이를 확인하기 위해, 유효기간이 만료될 경우, 원본 자원이 변경된 적이 있는지를 질의 함!! (날짜 기반일수도, 엔티티 태그 기반일수도 있음!)
    • 1. 서버의 요청받은 자원이 변경 된 경우
      • 상태 코드 200과 함께 새로운 자원 반환
    • 2. 서버가 요청받은 자원이 변경되지 않은 경우
      • 상태코드 304(Not Modified)를 통해, 자원이 변경되지 않았음을 알림
      • 304 코드는 '캐시된 자원을 참조하자' 라는  뜻
    • 3. 서버가 요청받은 자원이 삭제된 경우
      • 상태코드 404 (Not Found)를 통해 자원이 존재하지 않음을 알림

 

보안 : SSL/TLS와 HTTPS

  • HTTPS : HTTP에 SSL or TLS라는 프로토콜의 동작이 추가된 프로토콜
  • SSL(Secure Sockets Layer) , TLS(Transport Layer Security) : 인증과 암호화를 수행하는 프로토콜이며, TLS는 SSL을 계승한 프로토콜
  • HTTP에서 TLS 핸드쉐이크가 추가된것 == HTTPS
  • TLS 핸드쉐이크의 핵심
    • 1. 암호화 통신을 위한 키를 생성/교환 할수 있다.
    • 2. 인증서 송수신과 검증이 이루어질수 있다.