TIL 59일차

시작하며

오늘은 네트워크에서 클라이언트와 서버가 데이터를 주고 받는 방식들과 원리, 각 방식들의 장단점, 세부적인 옵션들을 학습하였다.

네트워크

인터넷 프로토콜

IP와 IP Packet

정의
복잡한 인터넷 망 속 수많은 노드들을 지나 클라이언트와 서버가 통신하기 위해서 IP(인터넷 프로토콜) 주소를 컴퓨터에 부여하게 되는데 IP는 지정한 IP 주소(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터 전달한다.

IP 패킷에서 패킷은 pack과 bucket이 합쳐진 단어로, 우체국 송장처럼 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보가 포함되어 있다.

패킷 단위로 전송을 하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달하는데, 이를 통해 복잡한 인터넷 망 사이에서도 정확한 목적지로 패킷을 전송할 수 있다.

IP 프로토콜의 한계

• 비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성 : 중간에 패킷이 사라질 수 있음, 패킷의 순서를 보장할 수 없음

TCP vs UDP

네트워크 프로토콜 계층은 다음과 같이 OSI 7계층과 TCP/IP 4 계층으로 나눌 수 있는데, IP 프로토콜 보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 앞서 다룬 IP 프로토콜의 한계를 보완할 수 있다.

먼저 HTTP 메시지가 생성되면 Socket 라이브러리를 통해 전달되는데, 프로그램이 네트워크에서 데이터를 송수신할 수 있도록, “네트워크 환경에 연결할 수 있게 만들어진 연결부“가 바로 네트워크 소켓(Socket)이다.

그리고 IP 패킷을 생성하기 전 TCP 세그먼트를 생성하는데, 생성된 TCP/IP 패킷은 LAN 카드와 같은 물리적 계층을 지나기 위해 이더넷 프레임 워크에 포함되어 서버로 전송된다.

TCP/IP 패킷
TCP 세그먼트에는 IP 패킷의 출발지 IP와 목적지 IP 정보를 보완할 수 있는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 포함하고 있다.

• 연결지향
  TCP는 장치들 사이에 논리적인 접속을 성립하기 위하여 3 way handshake를 사용하는 연결지향형 프로토콜이다. 먼저 클라이언트는 서버에 접속을 요청하는 SYN 패킷을 보내고, 서버는 SYN요청을 받고 클라이언트에게 요청을 수락한다는 ACK 와 SYN가 설정된 패킷을 발송하고 클라이언트가 다시 ACK으로 응답하기를 기다린다. 클라이언트가 서버에게 ACK을 보내면 이 이후로부터 연결이 성립되며 데이터를 전송할 수 있고, 만약 서버가 꺼져있다면 클라이언트가 SYN을 보내고 서버에서 응답이 없기 떄문에 데이터를 보내지 않는다. 현재에는 최적화가 이루어져 3번 ACK을 보낼때 데이터를 함께 보내기도 한다.

• 데이터 전달 보증
  TCP는 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다.

• 순서 보장
  만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있다.

• 신뢰할 수 있는 프로토콜

UDP
UDP는 IP 프로토콜에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜로, 앞서 TCP 특징과 비교해보면 신뢰성은 낮지만 3 way handshake 방식을 사용하지 않기 때문에 TCP와 비교해 빠른 속도를 보장한다. HTTP3는 UDP를 사용하며 이미 여러 기능이 구현된 TCP보다는 하얀 도화지처럼 커스터마이징이 가능하다는 장점이 있다.

• 비 연결지향
• 데이터 전달 보증 X
• 순서 보장 X
• 단순하고 빠름
• 신뢰성보다는 연속성이 중요한 서비스(e.g. 실시간 스트리밍)에 자주 사용됨.

HTTP 헤더

HTTP

• 클라이언트 서버 구조

  • Request Response 구조
  • 클라이언트는 서버에 요청을 보내고 응답을 대기
  • 서버가 요청에 대한 결과를 만들어 응답

• 무상태 프로토콜(Stateless), 비연결성(Connectionless)

  • 서버가 클라이언트의 상태를 보존하지 않음
    • 장점 : 서버 확장성 높음(스케일 아웃)
    • 단점 : 클라이언트가 추가 데이터 전송
  • HTTP는 기본이 연결을 유지하지 않는 모델로 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 적음.

표현 헤더

HTTP 메시지는 헤더와 바디로 구분할 수 있는데, HTTP 바디에서는 데이터 메시지 본문(Message body)을 통해서 표현(Representation) 데이터를 전달한다. 여기서 데이터를 실어 나르는 부분을 페이로드(Payload)라 하며, 표현은 요청이나 응답에서 전달할 실제 데이터를 뜻하며 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.

• 헤더 형식 <field-name> : <field-value>

헤더 종류

• 표현 헤더(요청, 응답 둘다 사용)
  • Content-Type : 표현 데이터의 형식
  • Content-Encoding : 표현 데이터의 압축 방식
  • Content-Language : 표현 데이터의 자연 언어
  • Content-Length : 표현 데이터의 길이
    
    
• 요청헤더
  • From : 유저 에이전트의 이메일 정보
  • Referer : 이전 웹 페이지 주소
  • User-Agent : 유저 에이전트 애플리케이션 정보
  • Host : 요청한 호스트 정보
  • Origin : 서버로 POST 요청을 보낼때, 요청을 시작한 주소를 나타냄
  • Authorization : 인증 토큰을 서버로 보낼 때 사용하는 헤더
    
    
• 응답 헤더
  • Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
  • Date : 메세지가 발생한 날짜와 시간
  • Location : 페이지 리디렉션
  • Allow : 허용 가능한 HTTP 메서드
  • Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
    
    
• 콘텐츠 협상 헤더
  • Accept : 클라이언트가 선호하는 미디어 타입 전달
  • Accept-Charset : 클라이언트가 선호하는 문자 인코딩
  • Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
  • Accept-Language : 클라이언트가 선호하는 자연 언어

(Accept-Language: ko-KR;q=1,ko;q=0.9,en-US;q=0.8,en;q=0.7 과 같이 1부터 0까지 우선순위를 부여할 수 있음)

웹 캐시

정의
캐시란 데이터나 값을 미리 복사해 놓는 임시 장소로 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다.

캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있으며, 브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있다.

만약 캐시의 유효시간을 60초로 설정했다면, 60초간은 동일한 요청을 보내더라도 캐시에서 데이터를 가져오고, 그 이후에는 다시 60초간 유효한 데이터를 캐시로 받게 된다.

캐시 검증 헤더

• Last-Modified : 데이터가 마지막에 수정된 시간 정보
• If-Modified-Since : 캐시 유효시간이 초과되더라도 데이터의 최종 수정일이 동일하다면 캐시의 데이터를 사용하게 할 수 있음

• Etag : 캐시용 데이터에 임의의 고유한 버전 이름을 달아둘 수 있음
• If-None-Match : Etag를 비교해서 같으면 유지하고 다르면 새로운 데이터를 보내는 방식

Cache-Control

• Cache-Control: max-age
  • 캐시 유효시간, 초 단위
• Cache-Control: no-cache
  • 데이터는 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용
• Cache-Control: no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안됨

프록시 서버
프록시란, 클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 가리켜 ‘프록시(Proxy)’, 그 중계 기능을 하는 서버를 프록시 서버라고 하며, 클라이언트, 혹은 반대로는 서버가 다른 네트워크에 간접적으로 접속 할 수 있기 때문에, 보안, 캐싱을 통한 성능, 트래픽 분산 등의 장점을 가진다.

미국에 있는 원서버에서 클라이언트가 직접 데이터를 받아오는 것보다 한국에 프록시 캐시 서버를 도입하여 캐시에 저장된 데이터를 받아오는 것이 빠르기 때문에 프록시 서버를 도입하였는데 클라이언트에서 사용하고 저장하는 캐시를 private 캐시, 프록시 캐시 서버의 캐시를 public 캐시라고 한다.

Cache-Control

• Cache-Control: public
  • 응답이 public 캐시에 저장되어도 됨
• Cache-Control: private
  • 응답이 해당 사용자만을 위한 것, private 캐시에 저장해야 함
• Cache-Control: s-maxage
  • 프록시 캐시에만 적용되는 max-age
• Age: 60
  • 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
• Cache-Control: must-revalidate
  • 캐시 만료 후 최초 조회 시 원 서버에 검증해야함
  • 원 서버 접근 실패 시 반드시 오류가 발생해야 함 - 504 Gateway Timeout
  • must-revalidate는 캐시 유효 시간이라면 캐시를 사용해야 함
• Pragma: no-cache
  • Cache-Control: no-cache와 같은 역할을 하나 HTTP 1.0 하위와 호환됨

마치며

그동안 express를 사용하는데 익숙해져서 HTTP 메세지의 다양한 헤더들에 대해서는 학습할 기회가 없었는데 오늘 배운 내용을 복습하고 추가적인 내용을 찾아보면서 다양한 설정들을 알 수 있었다. 자주 이용하던 사이트의 실제 헤더를 보면서 어떤 방식으로 서버와 통신을 하고 있는지 파악하면서 오늘 배운 내용을 이해할 수 있었다.