HTTP

Seung·2021년 12월 30일
0
post-thumbnail

인터넷 네트워크

IP(Internet Protocol)

  • 역할
    지정한 IP주소 (IP Address)에 데이터 전달
    패킷(Packet) 이라는 통신 단위로 데이터 전달
  • 한계
    비연결성
    비신뢰성
    프로그램 구분

    Packey (패킷) : 컴퓨터 네트워크가 전달하는 데이터의 형식화된 블록
    전달방식 : 패킷은 통신망을 통하여 노드에서 노드로 전해짐으로써 전송됨

    구조 (헤더 + 페이로드 + 트레일러)
    헤더 : 패킷의 주소 (송수신 주소)
    페이로드 : 내용과 데이터
    트레일러 : 에러검출에 사용 (없는 경우도 많음)

TCP, UDP

  • 인터넷 프로토콜 스택의 4계층
    애플리케이션 계층 - HTTP,FTP
    전송계층 - TCP, UDP
    인터넷계층 - IP
    네트워크 인터페이스 계층
    -프로토콜 계층
    애플리케이션 - 웹브라우저,SOCKET라이브러리, 게임 등
    OS - TCP,UDP / IP
    네트워크 인터페이스 - LAN드라이버, LAN장비
  • TCP특징
    • 연결지향 -
    • 데이터 전달 보증 : 데이터 전송여부를 보냄
    • 순서 보장 : 패킷 순서대로 전송
    • 신뢰할 수 있는 프로토콜
  • TCP 3 Way handshake
    1.SYN(접속요청) -> 2.ACK(요청수락) -> 3.ACK와 함께 데이터 전송가능
  • UDP특징
    • 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
    • IP와 비슷 (+ PORT와 체크섬 추가)
    • 애플리케이션에서 추가 작업이 필요

PORT

  • 동시에 같은 IP에서 둘이상 연결이 필요할 경우를 위해 사용
    패킷정보에 IP정보와 더불어 PORT를 함께 전송하여 프로세스 구분

DNS (Domain Name System0

  • 도메인 네임 시스템
    • 전화번호부
    • 도메인 명을 IP주소로 변환

URI (Uniform Resource Identifier)

  • URI는 locator,name로 추가 분류

    • URL (Uniform Resource Locator) : 리소스가 있는 위치를 지정
    • URN (Uniform Resource Name) : 리소스에 이름을 부여
      URI = URL로 일맥상통
  • URL 문법

    • scheme://[userinfo@]host[:port][/path][?query][#fragment]

    • https://www.google.com:443/search?q=hello&hl=ko


      프로토콜 : 어떤 방식으로 자원에 접근 할 것인 하는 규약
      (scheme => https,http,ftp 등)
      유저정보 : 사용자정보를 포함해서 인증
      ([userinfo@] 거의 사용안함)
      호스트 : 호스트명, 도메인명 또는 IP주소 사용
      (host => www.google.com,8.8.8.8)
      포트 : 접속포트 ([:port] => https=>443,http=>80)
      경로 : 리소스경로, 계층적구조 ([?query] => search)
      쿼리 : key=value형태로 ?시작, &추가 가능 (?q=hello&hl=ko)
      프래그먼트 : html내부 북마크등 사용


HTTP 특징

  • 클라이언트 서버구조
    Request Response 구조
  • 무상태 프로토콜
    스테이리스(Stateless)
    서버가 클리어인트 상태를 보존하지 않음
    장점: 서버확장성이 높음 / 단점: 클라이언트가 추가 데이터 전송
  • 비연결성 (connectionless)

HTTP 메시지

  • 메시지 구조


    • 요청시 메시지
      • start-line(시작라인)
        HTTP 메서드 : GET, POST 등등
        요청대상 : /search?q=seung/&hi=ko (절대경로[?query])
        HTTP Version : HTTP/1.1 1.2
      • header(헤더)
        HOST : www.google.com 등
      • empty line(공백라인)
      • message body(메시지)
        요청 메시지에도 body 본문을 가질수 있다
    • 응답시 메시지
      • start-line(시작라인)
        HTTP Version : HTTP/1.1 1.2
        HTTP 상태코드 : 200,400 등등
      • header(헤더)
        HTTP 전송에 필요한 모든 부가정보
        바디내용,바디크기,압축,인증,클라이언트 정보 등등
      • empty line(공백라인)
      • message body(메시지)
        실제 전송할 데이터
        HTML문서, 이미지, 영상, JSON 등등

HTTP 메서드

API URL설계

  • 리소스 식별, URI 계층 구조 활용

    • 리소스 : 회원
    • 행위 : 조회, 등록, 삭제, 수정
      • URI는 리소스 식별
        회원목록조회 : /members
        회원조회 : /members/{id} -> GET:리소스조회
        회원등록 : /members/{id} -> POST
        회원수정 : /members/{id} -> PUT, PATCH
        회원삭제 : /members/{id} -> DELETE
      • 행위 구분 (method)
        • GET : 리소스 조회,
          서버에 전달하고 싶은 데이터 쿼리를 통해 전달
        • POST : 요청 데이터 처리, 주로 등록시 사용
          메시지 바디를 통해 서러보 요청데이터 전달
        • PUT : 리소스를 대체(완전대체), 해당 리소스 없을시 생성
          리소스 위치를 알고URI를 지정
        • PATCH : 리소스 부분 변경
        • DELETE : 리소스 삭제
      • 기타메서드
        HEAD : GET과 동일하지만 메시지 부분을 제외, 상태줄과 헤더만 반환
        OPTIONS : 대상 리소스에 대한 통신 가능 메서드 설명
        CONNECT : 대상 자원으로 식별되는 서버에 대한 터널 설정
        TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행

  • 메서드의 속성

    • 안전 : 호출을 해도 리소스를 변경하지 않는다.
    • 멱등 : 몇번을 호출하든 결과가 똑같다.
      • GET : 결과가 항상 같음
      • PUT : 결과를 항상 대체함
      • DELETE : 결과를 삭제하여 몇번을 해도 삭제된 결과
    • 캐시가능 : 실제로는 GET, HEAD 정도만 캐시로 사용

HTTP 상태코드

  • 2xx - 성공
    • 200 OK : 요청 성공
    • 201 Created : 요청 성공하여 새로운 리소스 생성됨
    • 202 Accepted : 요청은 됐으나 처리가 완료되지 않음
    • 204 No Content : 서버가 요청을 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
  • 3xx - 리다이렉션
    응답결과에 Location 헤더가 있으면, Location위치로 자동 이동
    • 영구 리다이렉션
      특정 리소스의 URI가 영구적으로 이동
      • 301 Moved Permanently (요청 메서드 GET으로 변환, 본문이 제거 될수도?)
      • 308 Premanent Redirect (요청 메서드 유지)
    • 일시적인 리다이렉션
      리소스 URI가 일시적으로 변경
      • 302 Found (요청 메서드 GET으로 변환, 본문이 제거 될수도?)
      • 307 Temporary Redirect (요청 메서드 유지)
      • 303 See Other (요청 메서드 GET으로 변환)
    • PRG (POST Redirect GET)
      POST로 처리 후 새로고침을 진행시 동일한 내용이 중복 저장된다.
      해당 상황을 방지하기 위해 GET으로 Redirect
  • 4xx - 클라이언트 오류
    클라이언트의 요청에 잘못된 문법등으로 서버 요청을 수행 못함
    • 400 Bad Request
      요청구문,메시지등 오류 (파라미터나 스펙이 맞지 않을 경우)
    • 401 Unauthorized
      인증이 되지 않음
    • 403 Forbidden
      서버가 요청을 이해했지만 승인 거부
      접근권한이 불충분한 경우
    • 404 Not Found
      요청 리소스를 찾을 수 없음
  • 5xx - 서버오류
    서버문제로 오류 발생
    • 500 Internal Server Error
      서버 내부 문제로 오류 발생, 애매한 경우 500에러
    • 503 Service Unavailable
      서비스 이용불가, 일시적인 과부하 또는 작업으로 잠시 요청 불가
      Retry-After 헤더 필드로 얼마뒤 복구되는지 보내기 가능

HTTP 헤더

  • 표현
    표현헤더는 전송,응답 둘다 사용함

    • Content-Type : 데이터 형식
      미디어타입, 문자인코딩
      ex) 'text/html; charset=utf-8', 'application/json'
    • Content-Encoding : 데이터 압축 방식
      데이터를 압축하기 위해 사용
      ex) gzip, deflate, identity
    • Content-Language : 데이터의 자연어
      ex) ko, en, en-US
    • Content-Length : 데이터 길이
      바이트 단위의 길이
  • 협상
    클라이언트가 선호화는 표현 요청 (요청시에만 사용)

    • Accept : 클라이언트가 선호하는 미디어타입 전달

    • Accept-Charset : 클라이언트가 선호하는 문자 인코딩

    • Accept-Encoding : 클라이언트가 선호하는 압축 인코딩

    • Accept-Language : 클라이언트가 선호하는 자연어


      협상과 우선 순위

      1. Quality Values(q) 값 사용
        0~1, 클수록 높은 우선순위
        생략시에는 값이 1
        ex)
        Accept-Language:ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
        ->ko-KR 은 q 1생략
        ko-KR > ko > en-US - en 순
      2. 구체적인 것이 우선
        ex) Accept: text/, text/plain, text/plain;format=flowed, /
        -> text/plain;format=flowed > text/plain > text/
        > /

  • 전송방식

    • 단순전송
    • 압축전송
    • 분할전송
    • 범위전송
  • 일반정보

    • Form : 유저 에이전트의 이메일 정보
      요청에서 사용
    • Referer : 이전 웹 페이지 주소
      요청에서 사용
      A->B로 이동시 B를 요청시 Referer:A를 포함해서 요청
    • User-Agent : 유저 에이전트 애플리케이션 정보
      요청에서 사용
    • Server : 요청을 처리하는 오리진 서버의 소프트웨어 정보
      응답에서 사용
      Server: Apache/2.2.12
    • Date : 메시지 생성된 날짜
      응답에서 사용
  • 특별한 정보

    • Host : 요청한 호스트 정보 (도메인)
      요청에서 사용
      필수
    • Location : 페이지 리다이렉션
      응답결과에 Location 헤더가 존재시 해당 위치로 자동이동
    • Allow : 허용 가능한 HTTP 메서드
      405에서 응답에 포함해야함
    • Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야하는 시간
      503에서 서비스가 언제까지 중단인지 알려주는 기능
  • 인증

    • Authorization : 클라이언트 인증 정보를 서버에 전달
    • WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의
      401 응답과 함께 사용
  • 쿠키

    • Set-Cookie : 서버에서 클라이언트로 쿠키 전달 (응답)
    • Cookie : 클라이언트가 서버에서 받은 쿠키 저장하고,
      HTTP요청시 서버로 전달

    1. 쿠키 생명주기
      • Set-Cookie : expires=Sat, 14-Dec-2021 ~~~
        만료일이 되면 쿠키삭제
      • Set-Cookie : max-age=3600 (3600초)
        0이나 음수를 지정하면 쿠키 삭제
      • 세션 쿠키
        만료날짜 생략하면 브라우저 종료시까지만 유지
      • 영속 쿠키
        만료날짜를 입력하면 해당날짜까지 유지
    2. 쿠키 경로
      • 경로 설정시 해당경로를 포함한 하위 경로 페이자만 쿠키 접근
        ex) path=/home 이면 /home 이후 경로 가능
        /seung -> 불가능
    3. 쿠키 보안
      • Secure
        쿠키는 http, https를 구분하지 않고 전송
        Secure 적용시 https만 전송
      • HttpOnly
        XSS 공격 방지
        자바스크립트에서 접근 불가
        HTTP 전송에만 사용
      • SameSite
        XSRF 공격방지
        요청도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

캐시와 조건부 요청

캐시

캐시가 존재시 캐시 가능 시간동안 무언가를 가져올때
네트워크를 사용하지 않고 빠른시간에 가져올 수 있다.

검증 헤더와 조건부 요청

캐시 유효시간이 초과하여 다시 요청시 데이터가 변경되지 않았을 경우
서버에서 저장해 두었던 캐시를 재사용이 가능함.
단, 클라이언트 데이터와 서버의 데이터가 같다는 검증이 필요

  • 검증흐름

    1. 클라이언트가 최초 캐시를 저장시 서버에서
      cache-control(캐시 유지시간)과 Last-Modified(최종 수정일)을
      전송한다.
    2. 클라이언트는 해당 데이터를 캐시에 저장하고,
      캐시 시간이 초과 된 이후 재요청시 클라이언트가 가지고 있는
      if-modified-since(서버에게 마지막으로 받았던 데이터 최종 수정일)을
      서버에 함께 요청
    3. 서버에서 클라이언트가 보낸 최종수정일과 서버에서 가지고 있는 최종 수정일 비교
      3.1 서버에서 데이터 최종수정일이 동일 할 경우 304Not Modified
      HTTP Body가 없고,캐시유지시간을 포함하여 클라이언트에게 전송
      3.2 서버에서 데이터 최종수정일이 다를 경우 200OK로 모든데이터 전송
      HTTP Body가 존재
    4. 클라이언트 캐시 재사용

    Last-Modified <-> If-Modified-Since
    : 위에 검증 흐름대로 데이터 최종 수정일로 비교
    ETag <-> If-None-Match
    : 캐시용 데이터 임의의 교유한 버전의 이름으로 비교
    : ETag를 전송하여 같으면 유지, 다르면 다시 받는 방식

  • 캐시 제어 헤더

    • Cache-Control
      Cache-Control : max-age
      캐시 유효시간, 초단위
      Cache-Control : no-cache
      데이터는 캐시가능하지만 항상 서버에서 검증하고 사용
      Cache-Control : no-store
      데이터에 민간정보가 포함되어 있으니 저장 불가
    • Pragma (하위호환)
      Pragma:no-cache (HTTP 1.0 하위호환)
    • Expires (하위호환)
      캐시 만료일 지정 expires: Mon, 01 Jan ~~~
  • 프록시 캐시
    원서버 응답이 오래걸릴 경우 중간에 프록시 캐시서버에 접근하여 데이터 다운
    (공용캐시)

  • Cache-Control
    Cache-Control : public
    응답이 Public캐시에 저장되어도 됨
    Cache-Control : private
    응답이 해당사용자만을 위한것

  • 캐시 무효화
    Cache-Control: no-cache, no-store, must-revalidate
    Pragma: no-chach (HTTP 1.0 하위호환)

    • must-revalidate
      캐시 만료 후 최초 조회시 원서버에 검증
      캐시무효화시 no-cache와 더불어 같이 넣어야 하는 이유
      -> no-cache만 사용시 원서버에 불가피하게 접근 할수 없을 경우
      프록시 캐시에서 응답 할 수도 있다
      -> must-revalidate 사용시 원서버 불가피하게 접근하지 못할 경우
      504 Gateway Timeout으로 항상 오류를 발생시킴
profile
한번 해봅시다.

0개의 댓글