[Network] IP, IP Packet, TCP, UDP, HTTP Header, Cache

Steve·2021년 7월 5일
0

웹개발 코스

목록 보기
55/59

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 프로토콜의 한계를 보완할 수 있다.

채팅에서 메세지를 보내는 과정

  1. 프로그램이 메세지 생성
  2. HTTP 메세지가 생성되면 socket 라이브러리를 통해 전달됨.
  3. TCP 정보 생성, 메시지 데이터 포함
  4. IP 패킷 생성, TCP 데이터 포함

TCP/IP 패킷

TCP 세그먼트에는 IP 패킷의 출발지 IP, 목적지 IP 정보를 보완할 수 있는 출발지 Port, 도착지 port, 전송 제어, 순서, 검증 정보 등을 포함한다.

TCP

  • 연결 지향 - TCP 3 way handshake (SYN - Synchronize, ACK - Acknowledgment)
      1. 클라가 SYN 패킷을 보네 서버에 접속 요청
      1. 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACK 와 SYN 가 설정된 패킷을 발송
      1. 클라가 다시 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 하위호환

profile
게임과 프론트엔드에 관심이 많습니다.

0개의 댓글