IP 프로토콜 사용 시 클라이언트 입장
- 대상 서버가 패킷을 받을 수 있는 상태인지 모름
- 패킷 소실
- 패킷 전달 순서 문제 발생
-> TCP/UDP 로 해결
TCP 특징 (Transmission Control Protocaol)
- 연결 지향 - TCP 3 way handshake (가상 연결)
- 데이터 전달 보증
- 순서 보장
-> 순서 안 맞게 보내면 다시 보내라고 요청
TCP 3 way handshake 연결 과정
- SYN(접속 요청)
- SYN+ACK
- ACK(요청 수락)
- 데이터 전송
UDP 특징 (User Datagram Protocol)
- 연결 지향 x
- 데이터 전달 보증 x
- 순서 보장 x
- 단순, 빠름!!!!
- IP와 거의 같지만 + PORT + 체크섬
DNS 란 ? (Domain Name System)
- 도메인 명을 IP주소로 변환
- 도메인 명은 그대로 , IP 주소는 변경해서 쓰면됨
URI(Uniform Resource Identifier)
-
URL (Resource Locator) - 리소스가 있는 위치 지정(변함)
EX) https://www.google.com:443/search?q=hello&hl=koscheme : http, https, ftp
host : www.google.com (호스트명)
port : 80, 443 (생략가능)
path : search
query : ?q=hello&hl=ko (key=value 형태, ?로 시작. &로 추가, query parameter라 부름)
fragment : html 내부 북마크 등에 사용 -
URN (Resource Name) - 리소스에 이름을 부여(고정값)
HTTP (HyperText Transfer Protocol)
- 모든 데이터를 HTTP에 담아 전송
TCP : HTTP/1.1 , HTTP/2
UDP : HTTP/3
무상태 프로토콜(Stateless)
- 서버가 클라이언트의 상태를 보존 x
- 응답 서버를 쉽게 바꿀 수 있다 -> 무한한 서버 증설 가능
- 아무 서버나 호출해도 됨
비 연결성
- HTTP는 기본이 연결을 유지하지 않는 모델
- 일반적으로 초 단위의 이하의 빠른 속도로 응답
- 서버 자원을 매우 효율적으로 사용
-> TCP/IP 연결을 새로 맺어야함 - 3 way handshake 시간 추가
지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
HTTP/2, HTTP/3에서는 더 최적화
HTTP 메시지 -> 헤더 + 공백 + 바디
HTTP 헤더
- HTTP 전송에 필요한 모든 부가 정보 (Content-Type, Content-Length 등등)
HTTP 바디
- 실제 전송한 데이터(HTML 문서, 이미지 영상, JSON 등등 모든 데이터)
HTTP 메서드 종류
- GET : 리소스 조회
- POST : 요청 데이터 처리, 주로 등록
- PUT : 리소스를 완전히 대체, 해당 리소스 없으면 생성(덮어버림)
- PATCH : 리소스 부분 변경
- DELETE : 리소스 삭제
- 기타 메서드 (HEAD, OPTIONS, CONNECT, TRACE)
HTTP 메서드 속성
- 안전(Safe) - 호출해도 리소스를 변경하지 않는다. GET - Safe / POST - Safe x
- 멱등(Idempotent) - 몇 번을 호출하던 결과가 똑같다. GET - 멱등 / POST - 멱등 x
-> 자동 복구 메커니즘 - 캐시가능(Cacheable) - 리소스를 캐싱해서 사용. 실무에선 거의 GET만 캐시가능
클라이언트에서 서버로 데이터 전송
- 쿼리 파라미터로 데이터 전송 - GET
- 메시지 바디로 데이터 전송 - POST, PUT, PATCH
파일 관리 시스템
PUT 사용 시 클라이언트가 리소스 URI를 알고 있어야 한다.
스토어(Store)
- 클라이언트가 관리하는 리소스 저장소
- 클라이언트가 리소스의 URI를 알고 관리
HTTP 상태코드
-
2xx(Successful)
- 200 OK : 요청 성공
- 201 Created : 요청 성공해서 새로운 리소스가 생성됨
- 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음
- 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 payload 본문에 보낼 데이터가 없음
-
3xx(Redirection)
- 영구 리다이렉션 - 301 Moved Permanently, 308 Permanent Redirect
- 일시 리다이렉션
302 Found : GET으로 변할 수 있음(모호함)
307 Temporary Redirect : 메서드가 변하면 안됨
303 See Other : 메서드가 GET으로 변경
Post로 주문 후에 웹 브라우저를 새로고침하면?
새로고침은 다시 요청이므로 중복 주문이 들어감
-> PRG : Post/Redirect/Get 로 해결
1. Post로 주문후에 새로 고침으로 인한 중복 주문 방지
2. Post로 주문후에 주문 결과 하면을 GET 메서드로 리다이렉트
3. 새로고침해도 결과 화면을 GET으로 조회
4. 중복 주문 대신에 결과 화면만 GET으로 다시 요청- 기타 리다이렉션
304 Not Modified : 캐시를 목적으로 사용(캐시로 리다이렉트)
-
4xx(Client Error)
- 400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
- 401 Unauthorized : 인증되지 않음
- 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함
- 404 Not Found : 요청 리소스를 찾을 수 없음
-
5xx(Server Error)
- 500 Internal Server Error : 서버 문제로 오류 발생
- 503 Service Unavailable : 서비스 이용 불가
HTTP 헤더 부가 정보들
-
표현
Content-Type : 미디어 타입, 문자 인코딩 (text/html;, application/json)
Content-Encoding : 표현 데이터를 압축 (gzip)
Content-Language : 표현 데이터의 자연 언어 (ko, en)
Content-Length : 표현 데이터의 길이 (바이트 단위) -
협상 (클라이언트가 선호하는 표현 요청)
Accept : 미디어 타입
Accept-Charset : 문자 인코딩
Accept-Encoding : 압축 인코딩
Accept-Language : 자연 언어 -
전송 방식
- 단순 전송 : Content-Length
- 압축 전송 : Content-Encoding
- 분할 전송 : Transfer-Encoding
- 범위 전송 : Range, Content-Range
- 일반 정보
- From : 유저 에이전트의 이메일 정보
- Referer : 이전 웹 페이지 주소
- User-Agent : 유저 에이전트 애플리케이션 정보, 통계 정보
- Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
- Date : 메시지가 발생한 날짜와 시간
- 특별한 정보
- Host : 요청한 호스트 정보(도메인), 필수 헤더
- Location : 페이지 리다이렉션(3xx)
- Allow : 허용 가능한 HTTP 메서드(405)
- Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간(503)
- 인증
- Authorization : 클라이언트 인증 정보를 서버에 전달
- WWW-Authenticate : 리소스 접근 시 필요한 인증 방법 정의(401)
- 쿠키
- Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)
- 생명주기 : Expires, max-age
- 도메인 : 명시하면 명시한 문서 기준 도메인 + 서브 도메인 포함
생략하면 현재 문서 기준 도메인만 적용 - 경로 : 이 경로를 포함한 하위 경로 페이지만 쿠키 접근
- 보안
1. Secure : https 만 전송
2. HttpOnly : 자바스크립트에서 접근 불가, HTTP 전송에만 사용
3. SameSite : 요청 도메인과 쿠키에 설정된 도메인이 같을 때만 쿠키 전송
- Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달
브라우저 캐시 : 유효 시간동안 데이터 캐싱
만약 캐시 시간이 초과했을 때 데이터가 같은 경우 다시 서버에게 요청해야되는가 ??
Last-Modified 로 검증
- 응답 헤더에 Last-Modified를 내리고 웹 브라우저 캐시에 저장
- 최종 수정일 조회 요청 후 캐시와 서버의 날짜 비교
- 날짜가 같다면 서버에서 헤더만 내리고 304 내림 (바디를 다시 안내려도 됨)
- 바디는 브라우저 캐시의 바디 값 재사용
- 날짜가 다르면 새로운 데이터(헤더+바디) 내리고 200 OK 내림
비교 날짜가 다르지만 내린 데이터가 같거나 1초 미만 단위로 차이날 때는 ??
ETag(Entity Tag)로 검증
- 캐시용 데이터에 임의의 고유한 버전 이름(ETag)을 달아둠
- ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기
-> 캐시 제어 로직을 서버에서 완전히 관리 (클라이언트는 캐시 메커니즘을 모름)
캐시 제어 헤더
- Cache-Control : 캐시 제어 (max-age, no-cache, no-store) = 이걸로 다 함
- Pragma : 캐시 제어(하위 호환)
- Expires : 캐시 유효 기간(하위 호환)
원 서버가 멀 경우 프록시 캐시 도입
- 클라이언트 캐시에서 원 서버로 가기위해 그 사이에 프록시 캐시 서버를 둠
Cache-Control : no-cache
- 항상 원 서버에 검증
- 프록시 캐시에서 원 서버에 접근할 수 없는 경우 오류 보다 오래된 데이터라도 보여줌
Cache-Control : no-store
- 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 빠르게 삭제)
Cache-Control : must-revalidate
- 캐시 만료후 최초 조회시 원 서버에 검증
- 프록시 캐시에서 원 서버에 접근할 수 없는 경우, 항상 오류 발생(504)
