HTTP

Seung·2021년 12월 30일

Cache cookie http method

인터넷 네트워크

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으로 항상 오류를 발생시킴