네트워크 기초 과정과 이어지는 내용이다.

인터넷 프로토콜(IP)

우리가 알다시피 인터넷은 굉장히 복잡하다.

하지만 어떻게 우리는 수많은 노드(컴퓨터)를 지나 어떻게 클라이언트와 서버가 통신을 할 수있을까??

• 이런 점을 해결하기 위해서 IP주소를 이용한다.

IP는 지정한 IP주소에 패킷이라는 통신 단위를 담아서 데이터 전달을 한다.

• IP패킷에는 출발지IP, 목적지 IP와 같은 정보가 담겨 있다.

출발지와 목적지를 알고 통신을 할수 있다는 점에서 적절한 통신 방법 같다고 생각할수 있지만 몇가지 한계가 존재한다.

IP통신 한계

비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송

비신뢰성
- 중간에 패킷이 사라질 수 있음
- 패킷의 순서를 보장할 수 없음

또한 데이터가 클 경우에 패킷 단위로 나눠서 데이터를 전달하는데 이떄 중간에 다른 노드에게 전달이 될 수도 있다.
- 클라이언트가 의도하지 않은 순서로 패킷이 도착할 수 있다.

TCP vs UDP

네트워크 프로토콜 계층을 보면 다음과 같이 OSI 7계층, TCP/IP 4계층으로 나눌 수 있다.

보면 알수 있듯이 TCP,UDP같은 경우에는 IP보다 도 높은 계층에 존재하기 떄문에 앞서 말한 IP의 단점들을 보완할 수 있다.

메시지를 보내는 상황을 상상해 보자.

먼저 HTTP메시지가 생성되면 Socket라이브러리를 통해 전달이 된다.

프로그램이 네트워크에서 데이터를 송신할 수 있도록 하는 연결부가 네트워크 소켈이다.

그리고 IP패킷을 생성하기 전 TCP세그먼트를 생성한다.

이렇게 생성된 TCP, IP패킷은 LAN카드 같은 물리적 계층을 지나기 위해 이더넷 프레임 워크에 포함되어 서버로 전송이 된다.

쉽게 말해 HTTP 메시지를 TCP로 감싸고 그것을 IP로 감싸고 그것을 이더넷 프레임 워크에 감싼다고 생각하면 된다.

TCP/IP패킷에는 IP패킷의 출발지, 목적지, 정보를 보완할 수 있는 PORT등을 포함하고 있다.

TCP

TCP전송 제어 프로토콜은 비교적 신뢰할 수 있는 프로토콜이며 이와 같은 특징을 가지고 있다.

• 연결 지향 (3 way handshake)
• 데이터 전달 보증, 순서 보장
• 신뢰 가능

3 way handshake :논리 적인 접속을 성립하기 위한 프로토콜

먼저 클라이언트는 서버에 접속을 요청하는 SYN패킷을 보낸다.

그후 서버가 요청을 받고 ACK와 SYN이 설정된 패킷을 클라이언트에게 전송한다.

그후 클라이언트 부분에서 ACK을 보내면 연결이 완료가 된다.

만약 서버가 꺼져 있다면 클라이언트가 보낸 SYN이 돌아오지 않으니 데이터를 보내지 않게 된다.
- 이러한 방법으론 IP의 비연결성을 해결 한다.

만약 패킷이 보낸 순서대로 도착하지 않으면 TCP/IP에 있는 정보를 토대로 다시 패킷 전송을 요청한다.
- 이를 통해 비신뢰성을 보완할 수 있다.

UDP

IP프로토콜에 간단한 추가 정보만을 추가한 프로토콜이다.

앞서 본 TCP에 비해서 신뢰성은 떨어지지만 3 way handshake를 사용하지 않기 떄문에 속도는 빠르다.

둘의 차이는 단순하게 생각하면

TCP는 좋은것들이 다담겨 있는 것
UDP는 필요한 것들만 담겨 있는 것

UDP에 대해서 간략하게 알아보면

• 기능이 거의 없음, 비연결 지향
• 순서 보장이 안됨, 데이터 전달 보증이 안됨
• 단순하고 빠름, 신뢰성 보다는 연속성을 중요
• 주로 실시간 스트리밍에 자주 사용됨

HTTP

클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 서버 구조로 이루어져 있다

무상태 프로토콜 HTTP같은 경우에는 서버가 클라이언트의 상태를 보존하지 않기 떄문에 서버 확장성이 뛰어나지만, 반대로 정보가 저장되지 않기 떄문에 반복적으로 데이터를 전송해 주어야 한다.

• 이를 무상태성 이라고도 한다.
• 또한 이를 막기 위해서 쿠키를 사용 하기도 한다.

무상태성이 라는게 꼭 나쁜 것은 아니다

예를 들어 보자

TCP/IP같은 경우에는 기본적으로 연결을 유지를 한다.

그러다 보니 데이터 전송이 이루어지지 않아도 계속해서 서버와 통신을 하고 있고 이러한 경우 서버의 자원이 계속 소모되게 된다.

반대로 무상태성인 HTTP같은 경우에는 상태를 유지할 필요가 없기떄문에 필요한 상황에서만 서버와 통신을 하기 떄문에 사용할떄만 서버의 자원을 사용한다.

앞서 말했듯이 무상태성은 사용할떄만 서버의 자원을 활용한다고 했다.
- 이 부분은 반대로 단점이 될 수도 있다.

데이터가 유지되지 않기 떄문에 통신을 할떄마다 모든 css,js,이미지 등을 통신에 사용하기 때문이다.
- 많은 데이터를 전송을 해야한다;;

이를 보완하기 위해서 요즘에는 HTTP 지속 연결을 사용한다.
- 연결이 이루어 지고 난뒤 각각의 자원들을 모두 응답한후 연결을 종료한다.

HTTP 헤더

HTTP메시지는 헤더와 바디로 구분을 할수가 있다.

알다시피 HTTP바디에서는 데이터 메시지 본문을 통해서 데이터를 전달한다.

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

일반적으로 헤더는 데이터를 해석할 수 있는 정보를 말하고 데이터는 요청,응답 에서 사용하는 데이터를 말한다.

HTTP헤더에는 전송에 필요한 부가 정보를 담게 된다.

• 대소문자 구분이 없다.
• 또한 데이터 바디에 어떤 정보가 담겨있는지 알려주는 영역이다.

이와 같이 기본적인 정보만을 담을수 있지만 필요에 따라서는 임의의 헤더를 추가 할 수도 있다.

• helloworld : hi 같은..??

HTTP주요 헤더

• 이 예시 헤더를 보고 몇가지 주요 헤더를 설명해 보겠다.
• 이곳에 없는 헤더가 있을수도 있다!!

요청에 사용 되는 주요 헤더

Referer : 이전 웹 페이지 주소
- 현재 요청된 페이지의 이전 페이지를 담고 있다
- A-> B로 가는 경우 Referer:A를 포함해서 요청
- 요청에서 사용된다.

User-Agent: 유저 에이전트 애플리케이션 정보
- 클라이언트의 애플리케이션 정보(웹 브라우저 정보 등)
- 통계정보이며 어떤 종류의 브라우저에서 에러가 발생했는지 알수 있음
- 요청에서 사용

Host: 요청한 호스트 정보(도메인)
- 요청에서 사용하며 필수 헤더.
- 하나의 서버가 여러 도메인을 처리해야 할 떄 호스트 정보를 명시하기 위해 사용
- 하나의 IP주소에 여러 도메인이 적용되어 있을 떄 호스트 정보를 명시하기 위해 사용

Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
- 여기에서 요청을 보낸 주소와 받는 주소가 다르면 CORS오류가 난다.

Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더
- 토큰을 보낼떄에는 반드시 형식을 지켜서 보내 주어야 한다.
- Authorization : 토큰의 종류 + 실제 토큰 문자

응답에 사용 되는 주요 헤더

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

Allow: 허용 가능한 HTTP 메서드
- 오류가 발생 했을때 응답에 포함된다.

웹 캐시

쉽게 사용하면 자주 사용되는 요청,데이터를 사용할떄마다 보내는 것이 아니라 캐시 라는 곳에 저장해 두고 사용 하는 것이다.

• 원래 데이터를 접근하는 시간이 오래 걸리는 경우 or 시간을 절약하고 싶은 경우에 사용 된다.

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

이렇게 지정을 하게 되면 우선 캐시를 조회하고 원하는 데이터가 있다면 바로 가져오게 된다.

만약 유효시간이 초과하면 다시 요청을 보내 새로운 데이터로 캐시를 같은 유효시간으로 업데이트 한다.

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

만약 캐시의 유효시간이 지났지만 전과 같은 데이터를 똑같이 캐시로 사용 하고자 한다면 검증 헤더 Last Modified를 통해서 캐시의 수정시간을 알 수가 있다.

• 데이터가 마지막으로 수정된 시간정보를 헤더에 포함하기 떄문에 데이터의 최종 수정일도 저장된다.

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

1. 데이터가 수정되었는지 검증
2. 수정되지 않았다면 바디를 제외한 HTTP헤더만 전송
3. 브라우저 캐시에서 응답결과를 재사용
4. 캐시에서 조회한 데이터를 렌더링

잘 이해가 안가서... 간단하게 정리를 하자면

캐시 유효 시간이 초과, 데이터가 갱신되지 않는다면
- 304응답을 보낸뒤, 헤더만 응답을 한다(바디는x)

클라이언트는 서버가 보낸 응답 헤더 정보로 캐시를 갯인

캐시에 저장되어 있는 데이터 재활용

결과적으로 다운로드가 발생은 하지만 헤더 정보만 다운로드

하지만 일부 단점이 있기 떄문에 좀더 간단한 ETag, If-None-Match를 사용

• 단점은 다루지 않겠다.. 이렇게 까지 알 필요는 없다 생각을 하여

캐시용 데이터에 고유한 버전 이름을 달아두고 만약 데이터가 변경이 되면 이 고유한 이름을 변경하여 전송을 한다.

• 그러면 고유한 이름이 비교를 하여 변경이 이루어 졌으면 다시 받는 방식

마찬가지로 유효시간이 초과되었다면 If-None-Match를 이용해 조건부 요청을 한다.

• 이에 따른 결과는 앞서 말한 것과 같다(304응답, 헤더만 전송)

프록시 캐시

클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 말한다.

• 중계자 역할이다.

한국에 있는 클라이언트가 미국에 있는 서버를 접속하려고 한다.

• 만약 스트리밍하는 곳인 트위치가 한국에 없다면 이런 경우가 될 것이다.

그렇다면 시간이 소요 되게 될것이고 이건 사용자 입장에서 그닥 뜻깊은 경험은 되지 못할 것이다.

이를 방지하기 위해 한국에 있는 프록시 캐시 서버를 이용 하는 것이다.

한국에 있는 프록시 캐시 서버에 클라이언트가 요청을 보내고 프록시 캐시 서버에서 값을 가져 오는 것이다.

사실 말로 설명하면 별 다른점을 느끼지 못할 것 같다.
- 한명이 처리해서 값을 가져오는 거나 개인이 알아서 값을 가져오는 거나 뭐가 다를까??

우리는 캐시라는 용어에 집중을 해야한다

앞서 말했듯이 캐시는 저장 공간으로써 빠르게 데이터를 주고 받을수 있다.

만약 프록시 캐시 서버라는 한곳에서 통신을 제어하게 되면
많은사람들이 그곳을 통해 통신을 보낼 것이고 그러면 내가 원하는 데이터가 서버에 있을 확률이 높아 지게 된다.
- 여러 사람이 찾는 자료일수록 이 확률은 더 높아지게 된다.

이떄 클라이언트에서 사용하고 저장하는 캐시를 private캐시, 프록시 캐시 서버의 캐시를 public캐시 라고 한다.

이러한 요인으로 인해서 우리는 한가지 서버에서 총괄하여 다루게 된다.

CDN

세계 곳곳에 분포하는 데이터 센터에 컨텐츠를 저장하고 요청을 받으면 가장 가까운 곳의 데이터 센터에서 정보를 주는 방법을 말한다.

• 정보를 좀더 빠르고 효율적으로 제공하는 서비스를 말한다.
• 대표적으로 아마존이 있다.

만약 내가 특정 데이터 요청을 하게 된다고 생각을 해보자.

그럼 일단 가장 가까운 중국 데이터 센터에 내가 요청한 정보가 있는 지를 확일 할것이고

없다면 그다음으로 가까운 데이터 센터 이렇게 진행되다가 최종적으로 원본 데이터 센터까지 확인을 할것이다.

이 과정 중에 중간에 내가 요청한 데이터가 잇다면 그곳에서 나에게 응답을 보내 주는 것이다.

CDN이 다룰수 있는 콘텐츠의 종류는 정적,동적으로 구분할 수 있다.

정적 파일 같은 경우에는 변화가 거의 없기 떄문에 캐시 센터에 저장하는 것이 적합하다.

반면에 동적 같은 경우에는 변화가 계속 발생하기 떄문에 CDN서버에서 제공을 하기 어렵다.

• 서버측에서도 변화에 따라서 계속 바뀌어야 하기 떄문에

따라서 동적 컨텐츠 자체를 저장하기 보다는 공통적인 HTML파일 부분을 저장을 한다.

CDN의 장점

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

• 분산 서비스 공격인 DDos는 서버의 수용량보다 더 많은 데이터를 전송해 서버에 에러를 발생시키는 공격이다.
• 하지만 CDN같은 경우에는 다른 데이터 센터는 여전히 작동을 하기 떄문에 다른 센터에서 제공을 하는 방식으로 이를 해결한다.

2. 로딩속도 감소로 인한 사용자 불편 감소

• 앞서 다루었다.

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

• 만약 하나의 서버에서 모든 데이터를 관리한다면 고성능의 서버와 인터넷 수용력이 필요할 것이다.
• 고성능은 어디서든 많은 비용을 발생 시킨다;;
• 그러기 떄문에 분산된 상태에서 데이터를 제공하는 CDN은 비용이 절감될 것이다.

CDN의 서버 분산 방식

1. Scattered방식

• 빠른 응답속도가 목표인 방식이다.
• 세계 곳곳에 낮은 성능의 데이터 센터를 구성하고 연결해 두는 방식이다.
• 하지만 센터의 수가 많아지면 유지 비용이 높아지게 되고 이 비용을 사용자에게 전가하기 떄문에 비싸다.
• 그렇다고 사용은 안되는 방식은 아니고 수요가 적은 지역에서는 이 방식이 유리하다.

2. Consolidated방식

• 데이터 센터를 한곳에 통합시켜 사용하는 방식이다.
• 고성능의 데이터 센터를 운용해야 하며 응답시간이 증가하지만 센터의 수가 적어 비용이 절감한다.
• 수요가 많은 지역에 설치하면 적절한 방법이다.

두가지 방법중 뭐가 더 좋다라고 말할수는 없고 상황에 따라서 사용이 되는 방식이다.

DNS

DNS가 무엇인지는 이미 한번 다루었다.

• 그냥 IP주소를 사용자가 알아보기 쉽게 변환하는 시스템

도메인을 다루는 서버는 하나로 이루 어져 있지 않다.

• 보안상을 위해서

deploy.states.com이라는 url요청을 보내게 되면

1. root서버에서 .com이라는 IP주소 반환
2. name서버에서 states.com이라는 IP주소 반환
3. 권한 서버에서 deploy.states.com이라는 IP주소를 반환

이런식으로 순차적으로 해당 주소를 확인해가면서 최종적으로 도메인 주소를 반환하게 된다.

내가 도메인 서버를 만지고 새로 만들 경험은 거의 없을 것 같기 떄문에 이렇게 이루어 진다만 알고 넘어가겠다.

후기

음.. 이번 블로그는 1~2일?? 정도 걸려가면서 적은 글이다.

하루만에 끝낼수도 있었지만 부가적인 내용이라 시간이 날떄 야금야금 작성을 하였다.. ㅎ

내용 자체는 좀 심화적이고 이정도 까지 알아야 하나?? 내가 이러한 지식을 사용할 일이 있을까?? 라는 생각이 드는 학습 내용이었다.