출발, 목적에 각각 IP가 주어지고 Hello, world!를 보낸다. 그러면 각 노드에서 목적 IP를 찾아서 던지고 목적지까지 찾아간다.
비연결성
비신뢰성
프로그램 구분
IP 패킷정보에는 출발지 IP, 목적지 IP, 기타 정보가 담겨져 있다.
전송 제어 프로토콜(Transmission Control Protocol)
연결지향 - TCP 3 way handshake(가상 연결)
데이터 전달 보증
순서 보장
패킷이 1, 2, 3 이렇게 와야는데 1, 3, 2 이렇게 오면 다 버리고 2번부터 다시보내라고 하는 것
사용자 데이터그램 프로토콜(User Datagram Protocol)
정리
- IP와 거의 같다. +PORT + 체크섬 정도만 추가
- 애플리케이션에서 추가 작업 필요
TCP는 건들 수 없지만 더 최적화할 수 있다면 UDP로 해야 합니다. 최근에는 UDP가 뜨고 있다. 더 최적화해서 사용하기 위해서 UDP를 사용하는 겁니다.
URI 단어 뜻
- Uniform: 리소스 식별하는 통일된 방식
- Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)
- Identifier: 다른 항목과 구분하는데 필요한 정보
• 프로토콜(https)
• 호스트명(www.google.com)
• 포트 번호(443)
• 패스(/search)
• 쿼리 파라미터(q=hello&hl=ko)
• scheme://[userinfo@]host[:port][/path][?query][#fragment]
• https://www.google.com:443/search?q=hello&hl=ko
• 프로토콜(https)
• 호스트명(www.google.com)
• 포트 번호(443)
• 패스(/search)
• 쿼리 파라미터(q=hello&hl=ko)
• 주로 프로토콜 사용
• 프로토콜: 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙
• 예) http, https, ftp 등등
• http는 80 포트, https는 443 포트를 주로 사용, 포트는 생략 가능
• https는 http에 보안 추가 (HTTP Secure)
• URL에 사용자정보를 포함해서 인증
• 거의 사용하지 않음
• 호스트명
• 도메인명 또는 IP 주소를 직접 사용가능
• 포트(PORT)
• 접속 포트
• 일반적으로 생략, 생략시 http는 80, https는 443
• 리소스 경로(path), 계층적 구조
• 예)
• /home/file1.jpg
• /members
• /members/100, /items/iphone12
• key=value 형태
• ?로 시작, &로 추가 가능 ?keyA=valueA&keyB=valueB
• query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터, 문자 형태
• fragment
• html 내부 북마크 등에 사용
• 서버에 전송하는 정보 아님
HTTP 메시지에 모든 것을 전송
• HTML, TEXT
• IMAGE, 음성, 영상, 파일
• JSON, XML (API)
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용
• 지금은 HTTP 시대
• HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
• HTTP/1.0 1996년: 메서드, 헤더 추가
• HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
• RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
• HTTP/2 2015년: 성능 개선
• HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선
• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3
• 현재 HTTP/1.1 주로 사용
• HTTP/2, HTTP/3 도 점점 증가
• 클라이언트 서버 구조
• 무상태 프로토콜(스테이스리스), 비연결성
• HTTP 메시지
• 단순함, 확장 가능
스테이스리스(Stateless)
이렇게 하면 서버와 클라이언트가 독립적으로 진화를 할 수 있어서 좋다.
스테이스리스(Stateless)
실무 한계
- 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
무상태
예) 로그인이 필요 없는 단순한 서비스 소개 화면상태 유지
예) 로그인
- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
- 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
- 상태 유지는 최소한만 사용
HTTP 응답에는 다음과 같은 네 가지 주요 구성 요소가 있습니다.
응답 상태 코드 : 리소스 요청에 대한 응답으로 서버의 상태 코드를 표시합니다. 예를들어, 클라이언트 측 오류는 400으로 표시되는 반면 성공적인 응답은 200으로 표시됩니다.
HTTP 버전 : HTTP 프로토콜 버전은 HTTP 버전으로 표시됩니다.
응답 헤더 : 응답 메시지의 메타데이터가 이 섹션에 포함됩니다. 데이터는 콘텐츠 길이, 유형, 응답 날짜, 서버 유형 등과 같은 항목을 제공하는 데 사용할 수 있습니다.
응답 본문 : 서버가 실제로 반환한 리소스 또는 메시지는 응답 본문에 포함됩니다.
Content-Type은 응답의 미디어 타입을 의미한다.
예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
HTTP 메시지에 모든 것을 전송
요청 메시지
요청 메시지 - HTTP 메서드
- GET : 리소스 조회
- POST : 요청 내역 처리
요청 메시지 - 요청 대상
요청 메시지 - HTTP 버전
응답 메시지
- 200 : 성공
- 400 : 클라이얹트 요청 오류
- 500 : 서버 내부 오류
URI(Uniform Resource Identifier)
중요한 것은 리소스 식별
A : 안전은 해당 리소스만 고려한다. 그런 부분은 고려하지 않는다.
- GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회
- PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
- DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같다.
- POST : 멱등이 아니다! 두 번 호출하면 같은 결과가 중복해서 발생할 수 있다.
POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데 구현이 쉽지 않음
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
HTTP Status code, 상태 코드는 HTTP 요청이 성공했는지 실패했는지를 서버에서 알려주는 코드다.
4XX의 상태 코드들은 클라이언트의 요청이 유효하지 않아 서버가 해당 요청을 수행하지 않았다는 의미다.
5XX 상태 코드들은 서버 오류로 인해 요청을 수행할 수 없다는 의미다.
클라이언트의 요청은 유효하여 작업을 진행했는데 도중에 오류가 발생한 경우다. 404 오류와 마찬가지로 인터넷을 하다 보면 500, 502, 503 등의 오류를 만나봤을 거다. API 서버의 응답에서 5XX오류가 발생해서는 안된다. 보통 개발 과정에서 유효하지 않은 요청을 사전에 처리하지 않은 경우(400)에 많이 발생한다.
표현 헤더는 전송, 응답 둘다 사용
클라이언트가 선호하는 표현 요청
- 일반적으로 잘 사용안함
- 검색 엔진 같은 곳에서, 주로 사용
- 요청에서 사용
- 현재 요청된 페이지의 이전 웹 페이지 주소
- A → B로 이동하는 경우 B를 요청할 때 Referer : A를 포함해서 요청
- Referer를 사용해서 유입 경로 분석 가능
- 요청에서 사용
- 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등)
- 통계 정보
- 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
- 요청에서 사용
- Server : Apache/2.2.22(Debian)
- server : nginx
- 응답에서 사용
- Date : Tue, 15 Nov 1994 08:12:31 GMT
- 응답에서 사용
Location : 페지이 리다이렉션
- 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)
- 응답코드 3xx에서 설명
- 201(Created) : Location 값은 요청에 의해 생성된 리소스 URI
- 3xx(Redirection) : Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
Allow : 허용 가능한 HTTP 메서드
- 405(Method Not Allowed)에서 응답에 포함해야함
- Allow : GET, HEAD, PUT
Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
- 503(Service Unavailable) : 서비스가 언제까지 불능인지 알려줄 수 있음
- Retry-After : Fri, 31 Dec 1999 23:59:59 GMT(날짜 표기)
- Retry-After: 120(초단위 표기)
인증
- Authorization : 클라이언트 인증 정보를 서버에 전달
- WWW-Authenticate : 리소스 접근시 필요한 인증 방법 정의
Stateless
- HTTP는 무상태(Stateless) 프로토콜이다.
- 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.
- 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
- 클라이언트와 서버는 서로 상태를 유지하지 않는다.
백과 프론트가 나뉘어 작업하는 경우 , 인증은 보통 JWT를 사용합니다. 쿠키와 세션을 사용하지 않는다는건 인증에 한한 이야기 일 수 있습니다. 쿠키는 여전히 임시 데이터를 저장하는데 유효합니다. 즉, REST 방식이라고 쿠키와 세션을 사용하지 못하는 것은 아닙니다.
케시와 조건부 요청
캐시가 없을 때
캐시 적용
캐시 시간 초과
캐시 시간 초과
정리
- 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면 304 Not Modified + 헤더 메타 정보만 응답(바디X)
- 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신
- 클라이언트는 캐시에 저장되어 있는 데이터 재활용
- 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
검증 헤더
- 캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
- Last-Modified, ETag
조건부 요청 헤더
- 검증 헤더로 조건에 따른 분기
- If-Modified-Since : Last_Modified 사용
- IF-None-Match : ETag 사용
조건이 만족하면 200 OK
조건이 만족하지 않으면 Not Modified
예시
- 데이터 미변경 예시
- 캐시 : 2020sus 11월 10일 10:00:00 vs 서버 : 2020년 11월 10일 10:00:00
- 304 Not Modified, 헤더 데이터만 전송(BODY 미포함)
- 전송 용량 0.1M(헤더 0.1M, 바디1.0M)
- 데이터 변경 예시
- 캐시 : 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00
- 200 OK, 모든 데이터 전송(BODY 포함)
- 전송 용량 1.1M (헤더 0.1M, 바디 1.0M)
Last-Modified, If-Modified-Since 단점
- 예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우
ETag, If-None-Match
예) ETag: "v1.0", ETag: "a2jiodwjekjl3"
예) ETag: "aaaaa" -> ETag: "bbbbb"
ETag, If-None-Match 정리
예)
- 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
- 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신
캐시 지시어(directives)
Cache-Control: max-age
캐시 유효 시간, 초 단위
Cache-Control : no-cache
데이터는 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용
Cache-Control : no-store
데이터에 민감한 정보가 있으므로 저장하면 안됨
(메모리에서 사용하고 최대한 빨리 삭제)
캐시 제어(하위 호환)
캐시 만료일 지정(하위 호환)
expires : Mon, 01 Jan 1990 00:00:00 GMT
캐시 만료일을 정확한 날짜로 지정
HTTP 1.0 부터 사용
지금은 더 유연한 Cache-Control : max-age 권장
Cache-Control : max-age와 함께 사용하면 Expires는 무시