Section2 네트워크 기초-2

오늘은 아키텍쳐를 구성하는 요소들에 대해서 학습한당.

어렵당 어려워

---

 

프록시 서버 (Procxy)

 

• 프라이버시 (Privacy) : 웹 서버에서 클라이언트의 IP를 숨길 수 있다.
• 암호화 (Encryption) : 웹사이트에 대한 암호화를 구현한다. (SSL)
• 압축 (Compression) : 서버의 응답을 압축하여 네트워크 대역폭을 줄이고 성능을 향상시킨다.
• 보안 (Security) : 웹서버를 보호한다. (방화벽으로 보호되는 서버와 인터페이스 가능)
• 로드 밸런싱 (Load Balancing): 둘 이상의 서버 간 워크로드를 공유하는 로드밸런싱 구현으로 성능이 향성되고 서버의 장애를 보완할 수 있다. 수평적 구조를 달성한다.
• 캐싱 (Caching) : 캐싱으로 인해 엑세스한 콘텐츠를 빠르게 제공하여 웹 서버의 과부하를 방지한다.
• 콘텐츠 전송 네트워크 (Content Delivery Network) : 사용자에게 가장 가까운 데이터 센터의 콘텐츠를 제공하는 고급 유형의 캐시이다. 가장 가까운 위치에서 수십개의 국가의 수백개의 데이터 센터 사용이 가능하다.
• 필터링 (Filtering) : 구성 정책에 따라 사용자의 웹 사이트나 서비스에 연결이 불가능하게 한다.
• 로깅 (Logging) : 네트워크 트래픽을 기록하여 감사추적이나 도청 사용이 가능하다.
• 성능 (Performance) : 네트워크 서비스의 속도를 높이도록 설계가 가능하다 (DNS 쿼리)
• 조정 (Orchestration):요청을 전달할 위치 결정 설계가 가능하다.

출처 : https://simplicable.com/IT/reverse-proxy , https://simplicable.com/IT/proxy-server

 

로드밸런서 (Load Balancer)

동일한 서비스를 하는 다수의 서버가 등록되고 사용자로부터 서비스 요청이 오면 로드밸런서는 사용자 별로 다수의 서버에 요청을 분산시켜 부하를 분산할 수 있다.

사용자는 로드밸런서의 가상 IP로 접근하여 로드밸런서를 통해 서비스가 가능한 서버로 요청이 분산된다. 따라서 서버에  장애가 발생하더라도 다른서버에 요청되어 서비스를 제공할 수가 있다.

• L4 (Transport Layer) 로드 밸런서 : TCP, UDP 정보 (특히 포트)를 기반으로 로드밸런싱 수행. 부하를 분산하고 TCP 계층에서의 보안기능도 제공한다.
• L7 (Application Layer) 로드 밸런서 : HTTP, SMTP와 같은 애플리케이션 프로토콜 정보를 기반으로 로드 밸런싱을 수행한다. 이를 ADC(Application Delivery Controller)라고 하며 리버스 프록시 역할을 수행한다. 보통 4~7계층까지의 로드밸런싱 기능을 제공하며 장애극복, 리다이렉션 기능도 수행한다.

 

캐시(Cache)

 

같은 요청을 반복하면 같은 응답도 반복된다. 응답의 용량이 클수록 비용이 높아지고 속도가 느려진다.

이를 캐시에 응답을 저장하여 극복할 수 있다.

 

Cache-Control 속성으로 캐시 유효 시간을 지정할 수 있다.

• 캐시 속성이 설정된 요청을 보냈을 경우 : 응답이 네트워크 다운로드 되고 브라우저 캐시에 저장이되고 캐시 유효시간까지 유효하다.
• 유효시간 초과 전 같은 요청이 발생할 경우 : 캐시에 저장된 응답이 네트워크를 사용하지 않고 빠르게 응답을 제공한다.
• 유효시간 초과 후 같은 요청이 발생할 경우 : 다시 서버에 요청을하여 응답을 받고 네트워크 다운로드가 발생한다. 기존의 캐시는 지워지고 새 캐시로 데이터를 업데이트된다. 캐시의 유효시간도 초기화된다.

Last-Modified와 If-Modifed-Since 로 캐시 유효시간이 초화하더라도 캐시에 저장된 데이터를 사용할 수 있다.

• Last Modified 헤더와 If-Modifed-Since 조건부 요청 : 캐시 요청시간이 초과를 했을 경우 데이터의 최종 수정일이 저장이되어 데이터의 수정시간을 비교하여 캐시 요청 시간이 초과되었더라도 데이터의 수정이 없다면 캐시에 저장된 데이터가 전송된다. (304 Mot Modified, 헤더 메타데이터만 응답. 바디X)

ETag와 If-None-Match를 사용해 캐시를 완전히 컨트롤 할 수 있다.

• ETag 헤더와 If-None-Match 조건부 요청 : 요청 시 서버에서 ETag를 작성하 응답하고 클라이언트는 캐시에 해당 ETag를 저장한다. 캐시 시간이 초과된 경우 If-None-Match를 작성하고 요청하 ETag 값을 검증한다.( ETag가 변경되었을 경우 304 Mot Modified, 헤더 메타데이터만 응답. 바디X )

 

프록시 캐시 (Proxy Cache)

 

클라이언트와 원서버 사이에 프록시 캐시 서버를 도입하여 많은 클라이언트들이 원서버에 접속하지 않아도 프록시 캐시 서버에 접근하여 데이터를 가지고 올 수 있다. 많은 클라이언트들이 찾은 데이터일수록 이미 프록시 캐시 서버에 등록되어 있기 때문에 빠르게 데이터를 가지고 올 수 있다,

• Cache-Control: no-cache : 프록시 캐시 서버가 원서버에 검증 요청을 하지만 프록시 캐시와 서버 사이의 네트워크 연결이 단절이 되어도 200OK 응답.
• Cache-Control: must-revalidate : 프록시 캐시 서버가 원서버 검증 요청 시 접근이 불가하는 경우 504 Gateway Timeout (통장 잔고 등)

 

Content Deliery Network(CDN)

 

위치상 가장 가까운 데이터 센터에서 데이터를 제공받는다.

가까운 데이터 센터에 해당 데이터가 없다면 나머지 데이터 센터 중 가장 가까운 데이터 센터에서 데이터 제공을 받는다.

모든 데이터 센터가 콘텐츠가 없다면 원본이 저장된 원본 서버에서 콘텐츠를 제공한다. 해당 콘텐츠는 데이터 센터에 저장된다.

• 정적 콘텐츠 (Static Contents) : 변화가 거의 없고 개인화가 되지않는 대중적인 콘텐츠 (동영상, HTML, 뉴스 기사) 

-> CDN 캐시 센터에 저장하는 것이 적합하다.

• 동적 콘텐츠 (Dynamic Contents) : 접근할 시 내용이 달라지는 콘텐츠 (위치, IP, 카드번호, 전화번호 등)

-> CDN 캐시 센터에 저장하는 것이 부적합하다. 공통적인 HTML 부분을 저장한다.

 

장점

1. DDoS(분산 서비스 거부) 공격에 어느정도 대응이 가능 : 다른 데이터 센터 이용가능.

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

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

 

CDN의 서버 분산 방식

1. Scattered : 최대한 빠른 응답 속도를 목표로 한다. 낮은 성능의 데이터 센터 연결. 데이터 센터 수가 많아 유지 비용이 높다. 따라서 사용 요금이 높다.

2. Consolidated : 고성능의 데이터 센터 운영. 응답시간이 증가하지만 데이터 센터 수가 적어 비용 절감, 사용자들의 부담이 적음.

 

초기에는 응답 속도가 중점이라 센터를 최대한 분산시키는 Scattered 방식을 많이 사용했다. 따라서 비용이 높았다.

현재는 점점 동적 데이터를 CDN이 지원하면서 데이터센터를 통합하면서 Consolidated  방식이 사용되고 비용이 줄어들고 있다. 추가로 보안과 안전성에 집중하고 있다.

 

---

오늘의 발표

 

• [C514] 다음의 헤더를 보고 유추할 수 있는 내용을 모두 작성하세요.

▼응답 헤더 HTTP/1.1 200 OK  HTTP 프로토콜 1.1 버전을 사용하며 응답이 200 OK 로 성공하였다. Server: nginx 서버는 nginx를 사용한다. Date: Tue, 06 Dec 2022 04:41:09 GMT 응답 시간은 2022년 12월 6일 화요일 04:42:09 Content-Type: text/html; charset=utf-8 응답은 html 먼서이며 문자는 utf-8로 인코딩하여 사용한다. Transfer-Encoding: chunked 메시지 본문이 청크*로 나누어 전송되었다. Connection: keep-alive HTTP 응답이 완료된 이후에도 TCP 연결을 유지 Keep-Alive: timeout=60 TCP 연결을 60초동안 하겠다. key-event-id: A6V465X44Q x-toss-event-id: A6V46SX44Q vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers 브라우저가 CORS 요청을 보낼 때, 이 요청이 특정한 origin, method, headers와 일치해야만 캐시된 응답을 사용할 수 있다 x-content-type-options: nosniff 브라우저가 웹 서버에서 받은 MIME 타입을 따르도록 강제, 웹사이트 보안이 강화 referrer-policy: same-origin 이 사이트와 동일한 도메인으로부터 온 Referer 헤더만 허용하겠다 cross-origin-opener-policy: same-origin 동일한 출처의 문서만 로드할 수 있도록 제한 x-envoy-upstream-service-time: 12 요청 처리 시간은 12초 content-encoding: gzip 응답 데이터가 gzip으로 압축되어있다. x-toss-response-code-details: via_upstream toss 서버에서 응답을 생성하기 위해 업스크림 서버로 요청이 전달되었다. X-Frame-Options: ALLOW-FROM https://gather.town 해당 페이지는 https://gather.town의 프레임 내에서만 로드 Content-Security-Policy: frame-ancestors https://gather.town 해당 iframe이 https://gather.town 도메인에 속한 웹 페이지에 의해서만 포함될 수 있음 ▼ 요청 헤더 GET /career/jobs? company-Toss%20Global HTTP/1.1 HTTP 프로토콜로 GET 메서들 사용하여 /career/jobs에 대한 요청을 company-Toss Global이라는 쿼리 매개변수를 포함하여 요청한다. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif, image/webp, image/apng,*/*;q=0.8, application/signed-exchange; v-b3;q=0.9 클라이언트가 처리할 수 있는 응답 Accept-Encoding: gzip, deflate, br 클라이언트가 처리할 수 있는 인코딩 방식 Accept-Language: ko-KR, ko;q=0.9, en-US;q=0.8,en;q=0.7 클라이언트가 처리할 수 있는 언어  순위 차례로 ko-KR, ko, en-US, en Cache-Control: max-age=0 캐시 유효시간은 0초. 무조건 원서버에 접근하여 요청 Connection: keep-alive HTTP 요청이 완료된 이후에도 TCP 연결을 유지 Cookie: wcs_bt=s_12531fa025b4:1678301066; fbp=fb.1.1670301866646.233807232; amp_15e97d-dud-CKYnR3Ykpnv_JnxwEz...1gjir79dg.1gjir79dg.e.e.e; In_o r=d; _gid=GA1.2.1294750112.1670301067; _ga_5LBMWBVL71-GS1.1.1670301066.1.0.1670301066.0.0.0; NTM5YS05NDQOLTMZZDVKMZEOMTceZiIsImNyZWFzWQiOjE2NZAZMDEwNjY200UsImV4aXN0aW5nIjpmYWxzZX0=; hjFirstSeen=1; hjsessionUser_1949956-eyJpZCI6IjZjNDJmMWELTZINGQt hjIncludedInSessionSample=0; _hjsessi on_1949956-eyJpZCI6IjJlNjc2ZmNiLTUzYzctNDhmYS1iZDViLTg2ZDMBOGNjWzioCISIMNYZWFzWQiOjE2NZAZMDEwNjY4MjAsIm1uU2FtcGxlIjpmYWxzZX0=; _hjIncludedInPageviewSample=1; hjAbsoluteSessionInProgress=8; _ga=GA1.2.437173295.1670301867 쿠키정보 Host: toss.im 호스트는 toss.im Sec-Fetch-Dest: document 요청한 자원은  document 유형(HTML, XML, XHTML 등)이다. Sec-Fetch-Mode: navigate 요청한 자원은 navigate 방식, 새로운 문서를 가져오겠다. 새로운 페이지 탐색, 새로고침, 다른 도메인으로 이동 Sec-Fetch-site: same-origin  요청을 보낸 사이트는 페이지의 출처가 같은 경우에만 리소스 공유 가능 Sec-Fetch-User: ?1 브라우저에 식별자가 있음. 보안이 적용된 요청 Upgrade-Insecure-Requests: 1 HTTP 연결을 HTTPS 연결로 업그레이드 하려고 시도한다. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/168.0.0.0 Safari/537.36 sec-ch-ua: "Not?A_Brand"; v="8", "Chromium"; v="108", "Google Chrome"; v="108" 브라우저 정보 sec-ch-ua-mobile: ?0 모바일기기에서 실행되지 않음 sec-ch-ua-platform: "windows" 브라우저가 실행중인 플랫폼은 windows다

• [C513] 리눅스에서 ifconfig 명령의 결과를 먼저 살펴보세요. 결과 중 lo0와 en의 차이가 뭘까요? ifconfig에서 ether, inet6, inet은 무엇을 의미하나요?

lo0 (Loopback Interface) : 로컬 루프백 인터페이스. 즉 자신의 컴퓨터를 나타냄. localhost

en (Ethernet Interface) : 이더넷 인터페이스.

 

즉 lo0 는 컴퓨터 내부에서 통신을 할 경우 사용이되고 en은 컴퓨터와 외부 장치 (인터넷)간 통신을 위해 사용됩니다.

 

ether : 이더넷 주소로 MAC주소로 식별된다.

inet6 : IPv6 주소

inet : IPv4 주소

 

[출처 : https://velog.io/@jingrow/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EB%91%90%EB%B2%88%EC%A7%B8-%EB%B0%9C%ED%91%9C, https://unix.stackexchange.com/questions/148735/what-does-eno1-and-lo-mean, chat GPT]

 

 

---

오늘의 회고

 

프록시와 캐시 개념을 학습했다.

이것저것 읽다보니 조금 재밌는 것 같기도..?

헤더랑 조건식 이런것 까지 다 외워야할까싶었는데

일단 그래도 뭐가 어디에 쓰이는 지는 좀 기억할 필요가 있을 것 같다.

발표준비하다보니 저번에 배운건데 분명배운건데 또 기억이 잘 안나서 다시 찾아봤다.ㅋㅋㅋ

이래서 기초가 중요한가보다

다시 섹션1을 복습해야겠당.