TIL - 211129 [네트워크] 심화

Achievement Goals

• HTTP 기반 네트워크 흐름에 대해 이해할 수 있다.
• TCP/IP 기반 네트워크 흐름에 대해 이해할 수 있다.
  • TCP/IP 패킷이 왜 필요한 지 설명할 수 있다.
  • TCP와 UDP의 차이에 대해 설명할 수 있다.
• HTTP 기본 동작과 특징에 대해 이해할 수 있다.
  • 상태유지(Stateful)과 무상태(Stateless)의 개념에 대해 설명할 수 있다.
  • HTTP 메시지 구성에 대해 설명할 수 있다.
• HTTP 헤더의 역할에 대해 이해할 수 있다.
  • 표현, 콘텐츠 협상 등 다양한 헤더의 역할에 대해 알 수 있다.
• 캐시가 왜 필요한 지 알 수 있다.
  • 브라우저 캐시, 프록시 캐시에 대해 설명할 수 있다.
  • 조건부 요청, 캐시 무효화 방법 등을 사용할 수 있다.

CHAPTER -  프로토콜

1. IP와 IP Packet

컴퓨터가 통신을 할 때 IP(인터넷 프로토콜)주소를 컴퓨터 부여해 이를 통신에 이용한다. IP 주소(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터를 전달한다

 

IP Pacekt에는 출발지 IP, 목적지 IP 등 IP정보가 담겨있고 해당 정보를 이용해서 목적지 IP에 데이터를 전달하는 것이다. 이는 서버도 마찬가지이다.

 

2. TCP vs UDP

IP 패킷의 한계를 보완하는 방법을 네트워크 계층 구조에서 어떻게 보완하는지 보자. 

(TCP/IP 4계층은 OSI 7계층보다 먼저 개발되었다)

인터넷으로 메세지를 보낸다고 하면. HTTP 메세지가 생성되면 Socket 라이브러리를 통해 전달.

(프로그램이 네트워크에서 데이터를 송수신할 수 있도록 네트워크 환경 연결부가 네트워크 소켓)

 

TCP에는 IP패킷 저옵를 보완할 수 있는 출발지 port, 목적지 port, 전송 제저, 순서, 검증 정보가 포함

---

SYN : Syncronize, ACK : Acknowledgement 약자

패킷이 순서대로 도착하지 않으면 TCP세크먼트 정보를 토대로 패킷 재전송 요청

UDP는 IP 프로토콜에 port, 체크섬 필드 정보만 추가된 단순한 프로토콜

TCP에 비해 빠른 속도 보장. 체크섬: 중복검사 형태. 오류 정정을 통해 공간(전자통신)이나 시간(기억장치) 속에서 송신된 자료의 무결성을 보호하는 방법

3. HTTP

HTTP/1.1, HTTP/2는 TCP기반. HTTP/3는 UDP기반 프로토콜

무상태성: 서버가 클라이언트 상태를 보존하지 않음

장점: 서버 확장성 높음(스케일 아웃) / 단점: 클라이언트가 추가 데이터 전송

무상태성을 가지고 있으면 응답 서버를 쉽게 바꿀 수 있다.

 

상태유지(stateful)

로그인이 필요없는 단순한 서비스 소개 화면의 경우에는 무상태로 설계

그러나 로그인이 필요한 서비스라면 유저의 상태를 유지해야 하기 때문에

브라우저 쿠키, 서버세션, 토큰 등을 이용해 상태를 유지해야 한다.

 

TCP/IP의 경우 기본적으로 연결을 유지한다. 연결을 유지하는 모델에서 클라이언트에 요청을 보내지 않더라도 계속 연결을 유지해야 한다. 이러한 경우 연결 유지하는 서버의 자원이 소모된다.

HTTP 1.0을 기준으로 HTTP는 연결을 유지하지 않는 모델이다. 하지만 트래픽이 많고 큰 규모의 서비스를 운영할 때 비연결성은 한계를 보인다.

HTTP 지속 연결에서는 연결이 이루어지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결 종료

 

CAHPTER - HTTP 헤더

1.  표현 헤더(Representation Headers)

HTTP 메세지는 헤더와 바디로 구분. HTTP 바디에서는 본문을 통해 표현 데이터 전달.

여기서 데이터를 실어 나르는 부분을 페이로드라고 한다.

 

표준 헤더 : https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용한다. 그런데 헤더의 내용이 너무 많다.

위의 헤더는 표현 데이터의 형식, 압축방식, 자연 언어, 길이 등을 설명하는 헤더이다.

표현

헤더는 요청, 응답 측면에서 모두 사용한다.

현재는 Content-Encoding을 사용하며 Transfer-Encoding을 사용하는 경우 chunked방식으로 사용

chunked방식은 많은 양의 데이터르 분할 송신하기 때문에 전체 데이터 크기 알 수 없어서

Content-Length 헤더와 같이 사용할 수 없다.

 

2. HTTP 주요 헤더

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

From: 유저 에이전트의 이메일 정보

• 일반적으로 잘 사용하지 않음
• 검색 엔진에서 주로 사용
• 요청에서 사용

Referer: 이전 웹 페이지 주소

• 현재 요청된 페이지의 이전 웹 페이지 주소
• A → B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청
• Referer 를 사용하면 유입경로 수집 가능
• 요청에서 사용
• referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐

User-Agent: 유저 에이전트 애플리케이션 정보

• 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
• 통계 정보
• 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• 요청에서 사용
• e.g.
  • user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36

Host: 요청한 호스트 정보(도메인)

• 요청에서 사용
• 필수 헤더
• 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용

Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄

• 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
• 응답 헤더의 Access-Control-Allow-Origin와 관련

Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더

• “토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
• e.g.
  • Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

 

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

Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

• 응답에서 사용
• e.g.
  • Server: Apache/2.2.22 (Debian)
  • Server: nginx

Date: 메시지가 발생한 날짜와 시간

• 응답에서 사용
• e.g.
  • Date: Tue, 15 Nov 1994 08:12:31 GMT

Location: 페이지 리디렉션

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
• 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
• 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴

Allow: 허용 가능한 HTTP 메서드

• 405(Method Not Allowed)에서 응답에 포함
• e.g.
  • Allow: GET, HEAD, PUT

Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

• 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
• e.g.
  • Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
  • Retry-After: 120(초 단위 표기)

3. 콘텐츠 협상 헤더

콘텐츠 협상: 한국어 브라우저에서 특정 웹사이트에 접속했을 때 콘텐츠 협상이 적용되지 않는다면 서버는 기본언어로 설정된 영어로 응답한다. 클라이언트에서 Accept-Language로 KO를 작성해 요청한다면 서버에서는 해당 우선 순위 언어를 지원할 수 있기 때문에 한국어로 된 응답을 돌려준다.

협상 헤더에서는 콘텐츠에 대한 우선 순위를 지정할 수 있다.

 

CAPTER - 웹 캐시

1. 캐시의 기본 원리 및 적용

HTTP 헤더 - 캐시

캐시: 컴퓨터 과학에서 데이터나 값을 미리 복사해놓는 임시 장소

브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있다.

캐시 시간이 초과했을 경우 다시 서버에 요청하고  max-age만큼 유효한 응답 데이터 수신.

브라우저 캐시는 기존 캐시 지우고 새키로 데이터 업데이트

 

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

캐시 유효시간이 지났지만 변경이 없기 때문에 해당 데이터를 써도 되는 상황이라면 이를 검증하고 사용하는 방법

검증 헤더 Last Modified를 이용해 캐시 수정시간 알 수 있음

캐시 유효기간이 초과되더라도 If-Modified-Since 헤더를 이용해 조건부 요청을 할 수 있음

서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정되지 않았을 경우 응답 메세지에 이를 알려줌

HTTP body에 응답 데이터가 없으면 상태 코드 304 Not Modified

서버에서 완전히 캐시를 컨트롤 하고 싶은 경우 ETag사용할 수 있다.

서버에서 헤더에 ETage를 작성해서 응답한다

클라이언트에서 캐시에 해당하는 ETag값을 저장한다.

만약 시간초과되서 다시 요청하는 경우 ETage값을 검증하는 If-None-Match를 요청 헤더에 작성해서 보낸다.

Body가 비어있고 304 상태코드 전송되면 재사용하고 헤더 데이터 갱신한다.

 

3. 프록시 캐시

프록시 서버는 클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 가리켜 프록시 그 중계 기능을 하는 서버를 프록시 서버라고 한다.

클라이언트와 원래의 서버 사이에 거리가 멀다고 할 때 그 사이에 프록시 캐시 서버를 도입한다.

클라이언트는 더 가까운 프록시 캐시 서버에서 자료를 가져오도록 한다. 여러 사람이 찾는 자료일수록 이미 캐시에 등록되었기 때문에 빠른 속도로 가져올 수 있다.

캐시 무효화(웹브라우저가 임의로 캐싱을 할 때 이를 무효화 하는 방법)

캐시 무효화 헤더

no-cache와 must-revalidate 모두 원 서버에서 검증해야 하지만 그에 대한 응답에 대해 다른 점이 있다.

no-cache의 경우 캐시 서버 요청을 하면 원서버에 요청하게 된다. 그리고 원서버에서 검증 후 304 응답을 한다.

만약 프록시 캐시 서버와 원 서버간 네트워크 연결이 단절되면 no-cache에서는 응답으로 오류가 아닌 오래된 데이터라도

보여주자라는 개념을 200OK응답을 한다.

 

하지만 must-revalidate라면 원서버 접근이 불가하면 504 Gateway Timeout오류를 보낸다.(통장잔고)

 

CHAPTER - Content Delivery Network(CDN)

- 콘텐츠를 좀 더 빠르고 효율적으로 제공하기 위해 등장한 서비스

- 세계 곳곳에 분포하는 데이터 센터에 콘텐츠를 저장하고 이후 콘텐츠 요청을 받으면 지리적으로 가장 가까운 데이터 센터에서 콘텐츠를 제공해 주는 방식

CDN 네트워크는 요청한 곳과 가장 가까운 데이터 센터가 해당 콘텐츠를 저장하고 있는지 확인합니다.  그리고 가장 가까운 곳의 CDN 데이터 센터에 콘텐츠가 있는지 확인해서 제공해준다. 만일 CDN IDC에 콘텐츠가 없다면 원본 서버에서 콘텐츠를 제공하게 되고 콘텐츠를 CDN IDC에 저장하게 된다.

 

CDN이 다룰 수 있는 콘텐츠 종류

동적 콘텐츠는 내용이 자주 바뀌기 때문에 CDN 네트워크가 지원하기 어렵다. 따라서 동적 콘텐츠 자체를 저장하기 보다는 공통적인 HTML파일 부분을 저장한다.

 

CDN의 이점

1. DDoS 공격에 대해 어느 정도의 대응이 가능

분산 서비스 거부 공격(Distributed Denial of Service attack, DDoS)는 서버의 수용량 보다 훨씬 많은 요청을 보내 서버 사용이 불가능하게 만드는 것이다. DDoS 공격으로 CDN IDC가 사용하지 못한다고 할지라도 다른 IDC는 작동하고 있다.

 

2. 로딩속도 감소로 인한 사용자 경험 향상

 

3. 트래픽 분산으로 인한 트래픽 관련 비용 절감

하나의 서버에서 모든 요청을 처리한다면 엄청난 비용이 발생하게 된다. 서버들을 세계 곳곳에 분산한다면 지역에 맞게 서버의 성능과 인터넷의 성능을 낮춘다 해도 무리없이 서비스를 제공할 수 있다. 그래서 사용자 경험 향상 및 비용 절감의 효과를 볼 수 있다.

 

네트워크 구성 방법

Scattered 방식은 최대한 빠른 응답 속도를 목표로 하고 있다. 따라서 세계 곳곳에 비교적 낮은 성능의 데이터 센터를 구성하고 연결해두어야 한다. 

기존의 Scattered방식과 다르게 데이터 센터들을 통합하여 운용하는 방식. 비록 응답시간이 증가하지만 데이터 센터 수가 줄어듦으로써 데이터 센터의 관리 및 유지비용을 절감할 수 있다.

 

CDN은 초기에 응답 속도에 중점을 두었다. 따라서 Scattered방식, 정적 콘텐츠 CDN이 주류였다.

하지만 점차 동적 콘텐츠를 지원하고 데이터센터를 통합하기 시작했다.