IP, IP Packet
IP - Internet Protocol
IP 주소를 부여해 통신
IP는 지정한 IP 주소에 packet 이라는 통신 단위로 데이터 전달
IP packet 에 포함된 정보 - 촐발IP, 도착IP 등
패킷 단위로 전송을 하면 노드(서버)들은 목적지 IP 에 도달하기 위해 서로 데이터를 전달
서버의 응답도 IP packet 을 이용해 클라에게 전달
IP 프로토콜의 한계
비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
비신뢰성
- 중간에 패킷이 사라질 수 있음. (클라이언트는 파악 불가)
- 전달 데이터의 용량이 클 경우 나눠서 전달하게 되는데, 각 패킷이 다른 노드 경로를 통해 전달될 수 있고 도착시간이 다를 수 있음. 그래서 패킷의 순서를 보장할 수 없음.
TCP, UDP
TCP - Transmission Control Protocol
UDP - User Datagram Protocol
네트워크 프로토콜 계층은 OSI 7계층과 TCP/IP 4계층으로 나눌 수 있다.
IP 프로토콜보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 IP 프로토콜의 한계를 보완할 수 있다.
채팅에서 메세지를 보내는 과정
- 프로그램이 메세지 생성
- HTTP 메세지가 생성되면 socket 라이브러리를 통해 전달됨.
- TCP 정보 생성, 메시지 데이터 포함
- IP 패킷 생성, TCP 데이터 포함
TCP/IP 패킷
TCP 세그먼트에는 IP 패킷의 출발지 IP, 목적지 IP 정보를 보완할 수 있는 출발지 Port, 도착지 port, 전송 제어, 순서, 검증 정보 등을 포함한다.
TCP
- 연결 지향 - TCP 3 way handshake (SYN - Synchronize, ACK - Acknowledgment)
- 클라가 SYN 패킷을 보네 서버에 접속 요청
- 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACK 와 SYN 가 설정된 패킷을 발송
- 클라가 다시 ACK 를 보내면 연결 성립, 데이터 전송 가능
- 데이터 전달 보증
- TCP 는 데이터 전송이 성공하면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있음.
- 순서 보장
- 만약 패킷이 순서대로 도착하지 않았다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있음. (IP 패킷의 순서 비신뢰성 보완)
UDP
HTTP3 는 UDP 를 사용하며, 이미 여러 기능이 구현된 TCP 보다는 하얀 도화지처럼 커스터마이징이 가능하다는 장점이 있음.
- 하얀 도화지에 비유 (기능이 거의 없다)
- 비 연결 지향 - TCP 3 way handshake 없음
- 데이터 전달 보증 X
- 순서 보장 X
- 데이터 전달 순서가 보장되지 않지만 단순하고 빠름
- 신뢰성보다는 연속성이 중요한 서비스(ex - 실시간 스트리밍)에 자주 사용됨.
HTTP
HTTP/1.1 - TCP
HTTP/2 - TCP
HTTP/3 - UDP
HTTP 의 특징
- 클라 - 서버 구조
- 클라 요청, 서버 응답
- stateless, connectionless
- 장점: 서버 확장성 높음(서버가 데이터를 저장하지 않기 때문에 응답 서버를 쉽게 바꾸기 가능)
- 단점: 클라가 추가 데이터 전송
- HTTP message
- 단순함, 확장 가능
Stateless 의 한계
- 모든 것을 stateless 로 설계할 수 있는 경우도 있고 없는 경우도 있다.
- 무상태 - 로그인이 필요없는 단순한 서비스 소개 화면
- 상태 유지 - 로그인
- 로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지(브라우저 쿠키, 서버 세션)
- 상태 유지는 최소한만 사용
TCP/IP 의 경우 기본적으로 연결을 유지한다. (Connect oriented)
연결을 유지하는 모델에서는 클라이언트는 요청을 보내지 않더라도 계속 연결을 유지해야 한다.
이러한 경우 연결을 유지하는 서버의 자원이 계속 소모된다.
HTTP 의 경우 요청을 주고받을때만 연결을 유지하고 응답을 주고나면 TCP/IP 연결을 끊는다. (Connection-less)
최소한의 자원을 서버 유지 가능
트래픽이 적고 빠른 응답을 제공할 수 있는 경우 connectionless 가 효율적
한시간동안 수천명이 서비스를 사용해도 실제 서버의 초당 처리 요청갯수는 수십개에 불과
트래픽이 많고 큰 규모의 서비스를 운영할 때는 한계를 보임.
HTTP Header
HTTP 는 header 와 body 로 구분
- Header - body를 해석할 수 있는 정보 (데이터 유형, 데이터 길이, 압축 정보 등)
- Body - 데이터(payload)
Header Attributes (표현 헤더, req/res 둘다 사용)
- Content-Type: 데이터 형식
- Content-Encoding: 압축 방식
- Content-Language: 데이터의 자연 언어
- Content-Length: 데이터의 길이
HTTP 주요 헤더
- From - User Agent 의 email 정보
- Referer - 이전 웹 페이지 주소. 유입경로 수집 가능
- User Agent - 클라의 앱 정보(웹 브라우저 정보, 통계 등)
- Server - 요청을 처리하는 Origin 서버의 소프트웨어 정보
- Date - 메시지가 발생한 날짜/시간
- Host - 요청한 호스트 정보(도메인). 필수 헤더. 하나의 서버가 여러 도메인을 처리해야 할 때
- Location - Page redirection. Location 으로 redirect.
- Allow - Usable HTTP methods
- Retry-After - user agent 가 다음 요청을 하기까지 기다려야 하는 시간 (503 error)
- Authorization - 인증 토큰을 서버로 보낼 때 사용하는 헤더.
토큰 종류+토큰 문자 - Origin - 서버로 POST 요청 시 요청을 시작한 주소. 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러 발생
- Access-Control-Allow-Origin - 요청을 보내는 주소와 받는 주소가 다르면 CORS 에러 발생. 주소를 일일이 지정하기 싫다면 * 로 모든 주소에 CORS 요청을 허용하면 되지만 그만큼 보안이 취약해짐.
Content negotiation
콘텐츠 협상 - 클라가 선호하는 표현 요청
협상헤더는 요청시에만 사용
클라가 선호하는...
- Accept - 미디어 타입
- Accept-Charset - 문자 인코딩
- Accept-Encoding - 압충 인코딩
- Accept-Language - 자연 언어
예) Accept-Language 헤더를 사용하여 유저에게 맞는 언어로 전달 가능.
Browser Cache
HTTP 헤더 - cache
동일한 데이터를 다시 다운받아야 할 경우 캐시를 사용할 수 있다.
Cache-Control 헤더를 통해 cache 가 유효한 시간 지정 가능.
유효시간 이내면 cache 데이터 사용, 유효시간이 다 되면 다시 데이터를 다운로드.
검증 헤더(Validator), 조건부 요청
만약 캐시 유효기간이 지났지만 변경이 없기 때문에 데이터를 다시 써도 되는 상황일 때, 이를 다시 검증하고 사용하는 방법.
Last-Modified 헤더 - 데이터가 마지막으로 수정된 시간.
If-Modified-Since - 캐시 유효시간이 초과되더라도 해당 헤더를 통해 조건부 요청 가능
만약 서버의 해당 데이터의 최종 수정일과 비교하여 데이터 수정이 없었을 경우 304 Not Modified 를 응답.
클라는 해당 응답을 바고 캐시를 갱신, 다시 일정 시간동안 유효.
단점
- 1초 미만 단위로 조정 불가
- 날짜 기반 로직 사용
- 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 같은 경우
- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
ETag(Entity Tag)
ETag
If-None-Match
좀더 간단한 방식
서버에서 완전히 캐시를 컨트롤하고싶은 경우 사용
캐시용 데이터에 임의의 고유한 버전 이름을 달아둠.
데이터가 변경되면 이 이름을 바꾸어서 변경함.
ETag 가 같으면 유지, 다르면 다시 받는 방식
캐시시간이 초과되서 다시 요청을 보내야 하는 경우 If-None-Match를 request 에 작성
데이터를 변경해도 서버에서 ETag 를 수정하지 않다가 앱 배포시 바꾸기 등 가능
Proxy Cache
한국의 클라이언트가 미국 서버의 데이터를 요청할 경우
한국에 'proxy cache server' 를 두어 속도를 높인다.
여러 사람이 찾은 자료일수록 이미 캐시에 등록되어있기 때문에 빠르게 가져올 수 있음.
클라의 캐시를 private cache, proxy cache server 의 cache 를 public cache 라고 함.
Proxy cache headers
Cache-Control: public - 응답이 public 캐시에 저장되어도 됨
Cache-Control: private - 응답이 해당 사용자만을 위한 것으로 private 에 저장되어야 함 (default)
Cache-Control: s-maxage - proxy cache 용 max-age
Age: 60 (HTTP Header) - origin server 에서 응답 후 proxy cache 내에 머문 시간(초)
Cache-control
캐시 무효화
클라가 캐시를 적용하지 않아도 임의로 브라우저가 캐시를 적용하는 경우, 특정 페이지에서 캐시가 되면 안되는 정보(ex-통장 잔고)가 있다면 이를 무효화하는 법
이를 위해 다음 헤더를 모두 넣어야 함 (cache-directives, 캐시 지시어)
Cache-Control: no-cache - 데이터를 캐시해도 됨, 항상 원 서버에 검증. 원 서버 접근 실패 시 예전 캐시 데이터 사용.
Cache-Control: no-store - 데이터에 민감한 정보가 있으므로 저장하면 안됨
Cache-Control: must-revalidate - 캐시 만료 후 최초 조회 시 원 서버에 검증, 원 서버 접근 실패 시 오류 발생(504 Gateway Timeout), 캐시 유효시간이라면 캐시 사용
Pragma: no-cache - HTTP 1.0 하위호환
