TIL 60: [네트워크] 심화

오늘 배운 내용이 많아 분량 조절 실패했습니다..😂

 

인터넷 프로토콜

IP 정의 및 한계

과거에는 전용선을 통해 회전 교환 방식으로 연결했던 반면, 현재는 패킷 단위로 데이터를 나누어 최저 경로를 통해 전달하는 패킷 통신 방식을 이용합니다.

IP 주소는 네트워크에서 장치들이 서로를 인식하고 통신을 하기 위해서 사용하는 특수한 번호입니다. IP는 지정한 IP 주소에 패킷(Packet = Pack + Bucket)이라는 통신 단위로 데이터를 전달합니다. IP 패킷에는 우체국 송장처럼 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보가 포함되어 있습니다. 패킷 단위로 전송을 하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달합니다. 이렇게만 보면 IP는 적절한 통신 방법으로 보이지만 아래와 같은 한계가 존재합니다.

• 비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 클라이언트는 서버의 상태를 파악할 방법이 없기 때문에 패킷을 전송합니다.
• 비신뢰성: 중간에 패킷이 사라져도 클라이언트는 파악할 수 없습니다. 또한 전달 데이터의 용량이 큰 경우 패킷 단위로 나눠 데이터를 전달하는데 이 때 패킷들은 중간에 서로 다른 노드를 통해 전달될 수 있습니다. 이렇게 되면 패킷의 순서를 보장할 수 없게 됩니다.

 

TCP vs UDP

네트워크 프로토콜 계층은 OSI 7계층과 TCP/IP 4 계층으로 나눌 수 있습니다.

IP 프로토콜보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 앞서 다룬 IP 프로토콜의 한계를 보완할 수 있습니다. 애플리케이션 계층으로 갈수록 높은 계층이며, 네트워크 인터페이스 계층 (물리 계층)으로 갈수록 낮은 계층입니다.

 

TCP (Transmission Control Protocol)

HTTP 메세지가 생성되면 Socket 라이브러리를 통해 전달됩니다. 프로그램이 네트워크에서 데이터를 송수신할 수 있도록, 네트워크 환경에 연결할 수 있게 만들어진 연결부가 네트워크 소켓입니다. IP 패킷의 출발지 IP와 목적지 IP 정보를 보완할 수 있는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 포함한 TCP 세그먼트를 생성한 후에 IP 패킷을 생성합니다. 이 패킷은 LAN 카드와 같은 물리적 계층을 지나기 위해 이더넷 프레임 워크에 포함되어 서버로 전송됩니다.

 

TCP는 3 Way Handshake를 사용하는 연결 지향형 프로토콜입니다.

Handshake 1: 클라이언트는 서버에 접속을 요청하는 SYN(Synchronize) 패킷을 보냅니다.

Handshake 2: 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACK(Acknowledge)와 SYN이 설정된 패킷을 발송하고 클라이언트가 다시 ACK으로 응답하기를 기다립니다.

Handshake 3: 클라이언트가 서버에게 ACK를 보내면 이 이후로부터 연결이 성립되면 데이터를 전송할 수 있습니다.

Wireshark를 통해 본 3 Way Handshake

위의 과정을 거치기 때문에 IP의 한계 중 하나인 비연결성을 보완할 수 있습니다.

또한 만약 패킷이 순서대로 도착하지 않는다면 TCp 세그먼트에 있는 정보를 토대로 서버는 다시 패킷 전송을 요청할 수 있습니다. 이를 통해 순서를 보장하지 않는 IP 패킷의 한계인 신뢰성을 보완할 수 있습니다.

 

UDP (User Datagram Protocol)

UDP는 이미 다양한 기능을 포함하고 있는 TCP와 달리 PORT, 체크섬 피드 정보 정도만 추가된 단순한 프로토콜입니다. 여기서 체크섬은 중복 검사의 한 형태로, 오류 정정을 통해, 공간이나 시간 속에서 송신된 자료의 무결성을 보호하는 단순한 방법입니다.

TCP와 달리 3 Way Handshake 방식을 사용하지 않기 때문에 더 빠른 속도를 보장합니다. 대신 이로 인해 일반적으로 신뢰성이 낮아질 수 있다고 합니다. 하지만 UDP의 특징 중 하나인 커스터마이징을 통해 신뢰성 문제를 해결할 수 있으며, 그 결과 HTTP3는 UDP를 사용하여 인터넷 연결을 하는 프로토콜인 QUIC (Quick UDP Internet Connection)을 사용하고 있습니다.

 

이 부분을 공부하면서 3 Way Handshake 방식을 사용하지 않았는데 보안을 지켜질지 의문이 들었습니다. 좀 더 알아보니 클라이언트가 Handshake 없이 바로 서버로 첫 요청을 보낼 때는 서버의 세션 키를 모르는 상태이기 때문에 목적지인 서버의 Connection ID를 사용하여 생성한 특별한 키인 초기화 키를 이용하여 통신을 암호화한다고 합니다.

 

이는 보안을 높여줄 뿐만 아니라 유저의 편의성도 높여줍니다.

TCP의 경우 소스의 IP 주소와 포트, 연결 대상의 IP 주소와 포트로 연결을 식별하기 때문에 클라이언트의 IP가 바뀌면 연결이 끊깁니다. 연결이 끊기면 다시 연결을 생성하기 위해 3 Way Handshake 과정을 거쳐야 합니다. 최근에는 모바일로 인터넷을 사용하는 경우가 많기 때문에 Wi-fi에서 셀룰러로 전환되거나 그 반대의 경우, 혹은 다른 Wi-fi로 연결되는 경우와 같이 클라이언트의 IP가 변경되는 일이 굉장히 잦아지며 문제 해결의 필요성은 더더욱 커졌습니다.

앞서 말했던 것처럼 QUIC은 Connection ID를 사용하여 서버와 연결을 생성합니다. Connection ID는 랜덤한 값으로, 클라이언트의 IP와는 전혀 무관한 데이터이기 때문에 클라이언트의 IP가 변경되더라도 3 Way Handshake 없이 기존의 연결을 계속 유지할 수 있습니다.

 

HTTP

앞서 배웠던 것처럼 HTTP는 기본적으로 무상태라는 특징을 가집니다. 무상태는 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능합니다. 이는 상태 유지 필요 유무에 따라 장점이자 단점이 될 수 있습니다. TCP/IP의 경우 기본적으로 연결을 유지하기 때문에, 비연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊습니다. 이러한 HTTP의 비연결성은 HTML, CSS, 자바스크립트, 추가 이미지 등 많은 자원들을 각각 보낼 때마다 연결을 끊고 다시 연결하고를 반복하는 비효율성을 초래합니다.

이를 해결하기 위해 HTTP 지속 연결(Persistent Connections)가 나왔습니다. 모든 자원들에 대한 요청과 응답이 있고 나서 연결을 종료합니다. Keep-Alive를 통해 HTTP 지속 연결이 가능해집니다. Keep Alive의 유지 시간은 연결된 Socket에 I/O Access가 마지막으로 종료된 시점부터 정의된 시간까지입니다. Access가 없더라도 세션을 유지합니다. 즉, 정의된 시간 내에 Access가 이루어진다면 계속 연결된 상태를 유지할 수 있습니다.

 

 

 

 

 

HTTP 헤더

표현 헤더 (Representation Headers)

주로 Content로 시작하는 헤더를 표현 헤더라고 합니다. 여기서 표현은 요청이나 응답에서 전달할 실제 데이터를 말합니다. 따라서 표현 헤더는 요청, 응답 둘다 사용합니다. HTTP 헤더에는 HTTP 전송에 필요한 모든 부가 정보를 포함하고 있으며, 필요시 임의의 헤더를 추가할 수도 있습니다. 아래와 같은 표현 헤더가 있습니다.

• Content-Type: 표현 데이터의 형식 (text/html; charset=UTF-8, application/json, Image/png)
• Content-Encoding: 표현 데이터의 압축 방식(gzip, deflate, identity)
• Content-Language: 표현 데이터의 자연 언어 (not 프로그래밍 언어)
• Content-Length: 표현 데이터의 길이

HTTP 바디에서는 데이터 메세지 본문을 통해서 표현 데이터를 전달합니다. 여기서 데이터를 실어 나르는 부분을 페이로드라고 합니다.

 

 

HTTP 주요 헤더

요청(Request)에서 사용되는 헤더

• Referer: 현재 요청된 페이지의 이전 웹 페이지 주소. A에서 B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청합니다.
• User-Agent: 유저 에이전트 애플리케이션 정보로 어떤 종류의 브라우저에서 장애가 발생하는지 파악할 수 있습니다.
• Host: 요청한 호스트 정보(도메인)으로 필수 헤더입니다. 
• Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냅니다. 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생합니다.
• Authorization: JWT와 같은 인증 토큰을 서버로 보낼 때 사용하는 헤더입니다. Authorization: Basic(토큰의 종류) YWxhZGRpbjpvcGVuc2VzYW1l(실제 토큰 문자)
• From: 유저 에이전트의 이메일 정보

응답(Response)에서 사용되는 헤더

• Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보 
  Server: Apache/2.2.22 (Debian)
• Date: 메세지가 발생한 날짜와 시간
• Location: 3xx 응답의 결과에 페이지 리디렉션 하기 위한 대상 리소스를 가리킵니다.
• Allow: 허용 가능한 HTTP 메서드로 405(Method Not Allowed)에서 응답에 포함합니다.
• Retry-After: 유저 에이저트가 다음 요청을 하기까지 기다려야 하는 시간으로 503(Service Unavailable)에서 서비스가 언제까지 불능인지 알려줄 수 있습니다.

 

콘텐츠 협상 헤더

클라이언트가 선호하는 표현 요청을 보여주는 협상 헤더는 정의대로 요청 시에만 사용합니다. 종류는 아래와 같이 있습니다.

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어. 1부터 0까지 우선순위를 부여할 수 있습니다
  Accept-Language: ko-KR(기본 1), ko;q=0.9, en-US;q=0.8, en;q=0.7

콘텐츠 협상 헤더

 

 

 

 

 

웹 캐시

캐시의 기본 원리 및 적용

이전에 배웠던 것처럼 캐시는 데이터나 값을 미리 복사해 놓는 임시 장소를 말합니다. 브라우저에 캐시를 저장할 땐 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있습니다. 

Cache-Control: max-age = 60

이렇게 하면 60초 동안 해당 캐시가 유효하다는 의미입니다. 만약 캐시의 유효시간이 초과한다면 다시 서버에 요청을 하고 60초간 유효한 리소스를 응답받습니다. 이때 다시 네트워크 다운로드가 발생하게 됩니다. 응답 결과를 브라우저가 렌더링 하면 브라우저 캐시는 기존 캐시를 지우고 새 캐시로 데이터를 업데이트합니다. 이 과정에서 캐시 유효 시간이 다시 초기화됩니다.

 

 

캐시 검증 헤더와 조건부 요청

캐시 유효시간이 지났지만 변경이 없어서 해당 데이터를 써도 되는 상황일 때, 다시 다운로드를 하지 않고 검증만으로 끝낼 수 있는 방법이 있습니다. 

Last-Modified와 If-Modified-Since

Last Modified는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함합니다. 캐시 유효시간이 초과되더라도 If Modified Since 헤더를 이용해 조건부 요청을 할 수 있습니다. 데이터가 수정이 안되었을 경우 응답 메시지에 데이터는 없고(비효율성 감소) 상태 코드 304 Not Modified가 전달됩니다.

ETag와 If-None-Match

서버에서 헤더에 ETag를 작성해 응답하고, 클라이언트의 캐시에 해당 ETag 값을 저장합니다. 캐시 유효시간이 초과되어서 다시 요청해야 하는 경우라면 이때 ETag 값을 검증하는 If None Match를 요청 헤더에 작성해서 보냅니다. 데이터가 변경되지 않았을 경우 If None Match가 거짓이 되며 바디 없이 304 Not Modified 상태 코드가 전송됩니다.

토스 페이지 상태코드 200과 304

 

Cache-Control

• Cache-Control: max-age
  캐시 유효 시간으로 초 단위로 설정합니다.
• Cache-Control: no-cache
  데이터는 캐시 해도 되지만, 항상 Origin 서버에 검증하고 사용. 만약 Origin 서버 접근 실패 시 200OK를 응답하며 오래된 데이터라도 보여줍니다.
• Cache-Control: no-store
  데이터에 민감한 정보가 있으므로 저장하면 안 된다는 의미입니다.
• Cache-Control: must-revalidate
  캐시 만료 후, 항상 Origin 서버에 검증하고 사용. 만약 Origin 서버 접근 실패 시 반드시 504(Gateway Timeout) 오류 발생시켜야 하며, 이전의 데이터조차도 전송하지 않습니다.
• Pragma: no-cache
  HTTP 1.0 하위 호환

캐시 무효화를 확실하게 하고 싶으면 Cache-Control: no-cache, no-store, must-revalidate / Pragma: no-cache 모두 적용해야 합니다.

캐시 무효화

 

프록시 캐시 (Proxy Cache)

클라이언트와 서버 사이에 대리로 통신을 수행하는 서버를 프록시 서버라고 합니다. 다른 네트워크에 간접적으로 접속할 수 있기 때문에, 보안, 캐싱을 통한 성능, 트래픽 분산 등의 장점을 가집니다. 클라이언트에서 사용하고 저장하는 캐시를 private 캐시라고 합니다. 프록시 캐시 서버의 캐시를 public 캐시라고 합니다.