mellowg

🌐 6장. 네트워크 설계와 구축

6.1. 네트워크를 설계﹒구축할 때 할 일

6.1.1. 시스템 개발과 네트워크 설계﹒구축의 관계

네트워크 설계는 처음에 그 시스템이 무엇을 하는 시스템인지 생각하는 것부터 시작한다. 

대전제는 '그 시스템은 무엇을 하는 시스템인가?'를 생각하는 것이다. 거기에서 더 나아가 어떤 네트워크가 필요한지 생각한다.

시스템 구성에 따라 필요한 네트워크 구성도 달라진다. 예를들어, 웹 브라우저로 조작할 수 있는 일정 관리 앱을 만들고 싶다고 가정한다. 웹 애플리케이션 A를 회사 내에서만 사용하고 싶다면 사내 랜상에 웹 서버와 DB서버를 구축해서 설치해야 한다. 사용자 규모에 따라서는 웹 서버와 DB 서버를 서버 한 대에서 동작시킬 수도 있다. 

웹 애플리케이션 A를 SaaS로 제공하고 여러 회사에서 인터넷으로 이용하려면, 웹 서버는 인터넷에 공개하지만, DB 서버는 보안 관점에서 인터넷을 거치지 않고 웹 서버와 통신해야 한다.

또 SaaS로 제공하는 경우 사내에서 이용할 때보다 부하가 걸려 더 높은 가용성이 요구된다.

따라서 웹 서버는 한 대가 아니라 여러 대를 준비해서 서버에 집중되는 부하를 분배하거나, DB 서버도 여러 대에 동일한 데이터를 보유하여 데이터 손상이 일어나지 않도록 해야 한다.

이처럼 어떤 시스템을 만드는지 어느 정도 규모인지에 따라 필요한 네트워크 형태가 달라진다. 시스템 요구사항에 맞는 네트워크를 결정하고 만드는 것이 네트워크를 설계하고 구축할 때 중요하다고 할 수 있다.

6.1.2. 네트워크 설계와 구축(물리 인프라 편)

네트워크 설계의 각 프로세스는 시스템 설계와 크게 다르지 않다. 먼저 요건을 정의하고 어떤 시스템을 만들지, 그 시스템을 위해 어떤 네트워크를 만들지를 결정한 후 그 내용에 따라 기본 설계와 상세 설계를 한다.

기본 설계에서는 요건 정의에서 결정한 내용을 바탕으로 네트워크를 구축하면서 기본적인 사항을 정리한다. 상세 설계에서는 기본 설계에서 정리한 내용을 기반으로 '어떤 기기(서비스)를 사용하여 만드는가' 처럼 구현 방식의 세부 사항을 담는다. 이들 설계는 설계 리뷰를 거쳐 다듬은 후 구축 단계에 들어간다.

요건 정의 - 기본 설계 - 상세 설계 - 설계 리뷰

웹 애플리케이션 A를 SaaS로 제공하는 경우를 예로 들어 구축해보자.

현재 데이터 센터에 랙(전용 선반)을 빌리고 서버와 네트워크 장비를 구입하고 인터넷 회선도 계약한 상태이다. 대략 네트워크 구성을 정했으면 네트워크 구성도로 나타내본다. 

네트워크 구성도에는 물리 설계도와 논리 설계도가 있다. 물리 설계도에는 네트워크 기기가 포트별로 어디로 접속하는지와 기록한 포트 표나 랙의 어느 위치에 어떤 기기를 넣을지 기록한 랙 구성도, 케이블을 연결할 곳, 종류, 색 등 정보를 정리한 케이블 결선 표 등이 있다. 

물리 설계도에 따라 네트워크 기기와 서버를 랙에 마운트하고 네트워크 케이블이나 전원 케이블 등을 연결한다.

논리 설계도에서는 네트워크 회선의 랜간 라우팅이나 방화벽 규칙 설정, 어드레싱 등을 실시하고, 설계한 내용을 그림으로 나타낸다. 

현장에서 직접 랙에 마운트한 기기에 네트워크를 설정할 수 있고, 네트워크가 미리 설정된 기기를 데이터 센터에 보내고 현장에서는 동작만 확인하는 경우도 있다.

6.1.3. 네트워크 설계와 구축(클라우드 서비스 편)

이번에는 클라우드(IaaS)를 사용하여 같은 방식으로 네트워크를 구축해보자. AWS환경에서 구축하는 경우를 예로든다.

IaaS에서는 사업자가 제공하는 가상화 기반에 시스템을 구축한다. 서버와 네트워크 모두 가상으로 만들어진다. 물리 네트워크는 사람이 기기 설치나 초기 설정 등을 수작업으로 해야 하지만, 클라우드에서는 기기 설치를 대신하여 인스턴스(AWS에서는 가상 서버를 '인스턴스'라고 함) 생성, 초기 설정 같은 모든 작업을 웹 브라우저의 제어판에서 할 수 있다.

IaaS에서 시스템을 구축하는 흐름은 다음과 같다.

1. 서브넷 생성
2. 가상 서버 생성
3. 보안 그룹 설정
4. Elastic IP 설정

차례대로 살펴보자.

1️⃣ 서브넷 생성(퍼블릭 서브넷, 프라이빗 서브넷)

AWS에서는 서브넷 단위로 네트워크 세그먼트를 나누어 작성한다. 구체적으로는 인터넷에 공개한느 서버를 두는 서브넷(퍼블릭 서브넷)과 인터넷에 공개하지 않는 서버를 두는 서브넷(프라이빗 서브넷)을 생성한다.

가용성을 생각해서 각 서버를 가용 영역(availability zone)(데이터 센터에 해당) 2개로 나누어서 배치하고 각 가용 영역에 퍼블릭 서브넷과 프라이빗 서브넷을 2개씩 총 4개를 배피한다.

2️⃣ 가상 서버(인스턴스) 생성

AWS에서는 가상 서버를 인스턴스라고 한다. 여기에서는 EC2 서비스를 이용하여 웹 서버의 인스턴스를 생성한다. 또 RDS라고 하는 DB 서버 전용 인스턴스를 만들 수 있는 서비스도 있기 때문에 DB서버의 인스턴스는 이곳을 통해서 생성한다.

3️⃣ 보안 그룹 설정

AWS에는 보안 그룹이라는 서버에 연결하는 방화벽과 같은 것이 있다. 필요한 포트만 외부에서 보내는 통신을 통과하도록 작성해서 인스턴스에 할당한다.

4️⃣ Elastic IP설정

Elastic IP란 인스턴스에 결합하는 고정 글로벌 IP이다. 외부에 공개할 웹 서버 인스턴스로 설정한다. 

가상화 기반에 설정하는 것이므로 물리적인 작업이 발생하지 않는다. 설정 작업은 웹 브라우저에서 완결된다. 명령어나 정의 파일을 이용함으로써 정형화 및 자동화할 수도 있다.

클라우드는 매우 편리하지만, 물리적인 시스템의 네트워크 구조나 원리 원칙을 이해해야 더욱더 폭넓게 대응하는 엔지니어가 될 수 있다.

6.2. 웹 신뢰성을 높이는 기술

6.2.1. 웹 신뢰성이란?

시스템에 장애가 발생해도 서비스를 지속해서 제공하는 것이 중요하며, 이런 사고방식을 장애 대응 설계(design for failure)라고 한다.

- 로드 밸런싱(처리 분배)

6.2.2. 대칭 키 암호 방식과 공개 키 암호 방식

통신을 할 때 보내는 삶과 받는 사람 사이에서 누군가가 통신 내용을 도청할 수도 있다. 그래서 제삼자가 보더라도 알 수 없도록 암호화할 필요가 있다. 암호화된 것을 원래대로 되돌려서 읽을 수 있는 상태로 만들려면(복호화) 열쇠가 필요하다. 

암호화와 복호화 메커니즘에는 세 가지 방식이 있다.

1️⃣ 대칭 키 암호 방식

대칭 키 암호 방식이란 암호화와 복호화에 같은 키(대칭 키)를 이용하는 방식이다. 이 방식은 집 문을 여닫을 때 같은 키를 사용하는 것과 비슷하다. 파일 암호화 등에 자주 이용되는 방식으로, 프로세스는 아래와 같다.

1. 수신자가 발신자에게 키를 건네주고, 수신자도 같은 키를 가지고 있다.

2. 발신자는 암호 키로 암호화한 파일을 수신자에게 보낸다.

3. 수신자는 가지고 있던 같은 키로 파일을 복호화한다.

대칭 키 암호 방식의 문제점은 키를 안전하게 교환하기가 어렵다는 것이다. 

2️⃣ 공개 키 암호 방식(비대칭키 암호화 방식)

공개 키 암호 방식은 암호화와 복호화에 별도의 키를 사용하는 방식이다.

암호화에 사용되는 것은 공개 키, 복호화에 사용되는 것은 비밀 키라고 한다.

1. 수신자가 발신자에게 공개 키를 건네준다.

2. 발신자는 공개 키로 암호화한 파일을 수신자에게 보낸다.

3. 수신자는 비밀 키로 파일을 복호화한다.

이 방식은 공개 키로 암호화한 데이터를 복호화할 수 잇는 것은 비밀키를 가진 사람뿐이라는 것이 핵심이다. 키 교환이 간편하고, 암호화가 필요한 데이터를 처리하기 전에 키를 배포하고 취득할 수 있다.

3️⃣ 두 가지 방식을 함께 사용

웹 사이트 암호화에 사용되는 SSL/TLS 통신은 대칭 키 암호 방식과 공개 키 암호 방식을 함께 사용한다.

1. 클라이언트가 서버로 접속 요청

2. 서버가 클라이언트에게 공개키 제공

3. 클라이언트에서 통신용 대칭키를 생성

4. 생성된 대칭키를 서버의 공개키를 활용하여 암호화

5. 암호화된 공개키를 서버로 전송

6. 서버에서 비밀키로 복호화

7. 대칭키를 기반으로 암호 통신을 진행

SSL/TLS 통신을 시작할 때 서버가 클라이언트에 공개 키를 전달하는데, 인증 정보나 공개 키 정보를 하나로 모은 것이 SSL/TLS 서버 인증서 이다. 서버는 SSL/TLS 서버 인증서로 클라이언트에 인증 정보나 공개 키 정보를 세트로 건네주고, 클라이언트는 건네받은 SSL/TLS 서버 인증서로 접속 상대의 정보를 확인하고 통신한다. 

6.2.3. 상시 SSL화

상시 SSL/TLS 화란 웹 사이트 전체를 HTTPS화(암호화)하는 것이다. 보통 상시 SSL화라고 하는 경우가 많다.

실제 프로토콜은 SSL의 진화형인 TLS를 상요하지만, 일반적으로 알려진 용어가 SSL이므로 SSL/TLS를 단순히 SSL로 부른다.

이전에는 웹 사이트 전체를 암호화하려면 느려진다는 인식이 일반적이었으나, 최근에는 다음과 같은 이유로 상시 SSL화가 권장되는 추세이다.

1️⃣ HTTP/2에서는 표시 속도가 오히려 빨라진다.

HTTP/2 라는 새로운 프로토콜에서는 이전 HTTP 버전의 문제점이 개선되어 통신 효율이 높아졌다. 클라이언트와 서버 사이의 통신을 암호화하는 사양이 표준으로 정해져 있어 HTTP/2에 대응하려면 상시 SSL화가 필요하고, 이로써 응답 속도 향상을 기대할 수 있다.

2️⃣ SEO의 장점이 있다.

SEO(Search Engine Optimization)는 검색 엔진 최적화로 번역되며, 검색 결과에서 웹 사이트가 좀 더 상위에 표시되게 하는 일련의 대책을 SEO 대책이라고 한다. 오늘날 검색 엔진의 점유율은 구글이 앞도적으로 우위에 있으며, 구글에서는 상시 SSL화를 검색 결과의 평가 기준 중 하나로 삼고 있으며, SEO 대책의 일환으로 상시 SSL화가 되기도 한다.

3️⃣ HTTP일 때 웹 사이트를 열면 현재 웹 브라우저에 경고가 표시된다.

HTTP 웹 사이트를 열면 주소창에 '주의 요함'이라는 경고가 표시된다. 크롬 56부터는 HTTP 페이지에 ID나 패스워드 같은 기밀 정보를 입력하는 폼이 있을 때 보안 경고가 표시되었지만, 지금은 HTTP 웹 사이트 모두에서 경고가 표시된다. 

6.2.4. 부하 분산

웹 사이트의 내장애성이나 처리 능력을 높이고자 웹 서버 한 대가 아니라 여러대로 웹 사이트를 호스팅하기도 한다. 이 경우 액세스를 분산해서 할당하는 것을 부하 분산이라고 한다. 

DNS 서버 설정이나 전용 기기 및 소프트웨어의 도입, 서비스 등을 이용하여 부하 분산할 수 있다.

1️⃣ DNS 라운드 로빈

DNS 라운드 로빈은 DNS 시스템을 사용해서 요청을 서버 여러 개로 분산하는 방식이. 한 호스트 이름에 IP주소를 여러 개 설정함으로써 요청받은 DNS 서버는 차례대로 IP주소를 반환한다.

DNS 라운드 로빈은 특별한 장비나 소프트웨어를 쓰지 않고도 부하를 분산할 수 있다. 그러나 단점도 존재한다. 

DNS 서버가 각 서버를 모니터링해서 동적으로 할당하는 것은 아니기 때문에 다운된 서버의 IP를 반환하는 경우가 있다. 또 서버의 부하 상태와 상관없이 균등하게 할당되므로 처리 능력이 낮은 서버와 처리 능력이 높은 서버에 고르게 할당되면 퍼리 능력이 저하된 서버는 처리 한계에 도달할 가능성도 있다.

2️⃣ NAT형

NAT형이란 VIP라는 가상 IP 주소에 대한 요청을 실제 서버 여러 대에 할당하는 방식이다.

하드웨어/소프트웨어 등으로 제공되는 일반적인 로드 밸런서(L4 스위치/L7 스위치라고도 함)에서 채용된다.

3️⃣ GSLB

글로벌 서버 로드 밸런싱(Global Server Load Balancing)은 여러 위치를 가로지르는 부하 분산을 실현하는 방식이다. 

예를 들어 서울과 부산에 있는 데이터 센터에 서버를 설치하고 정상일 때는 양쪽 모두에 요청을 할당하고, 어느 한쪽에 장애가 발생했을 때는 장애가 일어난 데이터 센터 쪽 서버에는 할당하지 않게 하는 등 DNS 라운드 로빈에서 문제였던 '장애가 발생한 서버에도 할당할 수 있는 문제점'을 해결하였다.

이처럼 여러 서버에서 서비스를 제공함으로써 가용성과 성능을 향상시키거나 재해나 장애를 대비하는 등 부하 분산은 웹 사이트 신뢰성 향상에 연결된다.

6.2.5. 리버스 프록시

리버스 프록시란 웹 서버 대신에 클라이언트의 액세스를 받는 프록시 서버의 일종디ㅏ. 보통 웹 사이트와 동일한 네트워크에 설치된다.

프록시란 대리나 대행이라는 뜻으로, 프록시 서버는 클라이언트 쪽에 설치되어 클라이언트가 웹 서버에 액세스하는 것을 중계하는 역할을 한다. 즉 웹서버에 액세스 하는 것을 대행한다.

리버스 프록시는 서버 쪽에 설치되어 서버에 대한 요청을 받아 배후에 있는 서버에 넘겨주는 데 사용된다. 즉, 웹 서버가 받을 요청을 대신해서 받는다. 

프록시 서버와 리버스 프록시 서버는 모두 캐시 기능을 제공한다. 이미 요청이 있었던 것을 일정 시간 캐시해 두고, 캐시에 일치하는 것은 웹 서버 대신에 프록시 서버(리버스 프록시)가 응답한다. 이렇게 함으로써 웹 서버의 대한 부담을 줄일 수 있다. 

리버스 프록시는 캐시 기능 이외에도 부하 분산 기능, WAF7를 제공하여 웹 사이트의 신뢰성 향상에 기여한다.

6.2.6. CDN

CDN(Content Delivery Network)은 동일한 콘텐츠를 많은 배포처, 예를 들어 많은 사용자의 PC나 휴대 전화에 효율적으로 배포하고자 할 때 사용된다. 주로 웹 사이트에 있는 많은 이미지나 동영상 등 용량이 큰 데이터를 많은 서버와 네트워크 대역을 이용하여 클라이언트에 전달하는 데 사용된다. 또한 윈도우와 휴대 전화 운영 체제 업데이트 등도 CDN을 이용하여 효율적으로 전송할 수 있다.

배포처에 가까운 네트워크(커스터머 에지)에 콘텐츠를 배포하는 서버(에지 서버)를 배치해서 구성한다. 에지 서버는 원본 데이터를 가진 서버(오리진 서버)의 데이터 사본을 캐시로 가지고 있다가, 오리진 서버를 대신해서 클라이언트 요청에 응답한다.

사용자 가까이에 있는 서버에서 배포하고, 또 서버 여러 대에서 배포함으로써 더 빠르고 부하에 강한 시스템을 실현했다.

효율적인 배포 외에 DDos 공격에 대한 대책으로도 사용된다.

아래는 대표적인 CDN 서비스이다.

Akamai

엔터프라이즈급 CDN으로 유명하다. 

Amazon CloudFront

AWS 서비스 중 하나로 제공되는 CDN 서비스이다. 

Cloudflare

주로 개인용으로 무료 플랜이나 소액 플랜을 갖춘 것으로 알려진 CDN 서비스이다. CDN을 기본으로 하면서 보안이나 DDos 공격 대책에 사용한다.

Fastly

다른 CDN에서는 어렵다고 여기는 동적 콘텐츠 캐시 등 독자적인 기능을 제공하는 CDN 서비스이다.

Imperva Incapsula

CDN기능도 있지만, WAF, DDos 공격에 대응하는 측면으로도 강한 서비스이다.

IT(전산) 필기 시험 대비 네트워크 뿌시기👊🏻

1. HTTP의 GET와 POST 비교

둘 다 HTTP 프로토콜을 이용해서 서버에 무엇인가를 요청할 때 사용하는 방식이다. 하지만 둘의 특징을 제대로 이해하여 기술의 목적에 맞게 알맞은 용도에 사용해야한다.

GET

우선 GET방식은 요청하는 데이터가 HTTP Request Message의 Header부분에 url이 담겨서 전공된다. 때문에 url 상에 ? 뒤에 데이터가 붙어 request를 보내게 되는 것이다. 이러한 방식은 url이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다. 또 보안이 필요한 데이터에 대해서는 데이터가 그대로 url에 노출

되므로 GET방식은 적절하지 않다. (ex. password)

POST

POST방식의 request는 HTTP Request Message의 Body부분에 데이터가 담겨서 전송된다. 때문에 바이너리 데이터를 요청하는 경우 POST방식으로 보내야 하는 것처럼 데이터 크기가 GET방식보다 크고 보안면에서 낫다.(하지만 보안적인 측면에서 암호화를 하지 않는 이상 고만고만하다.)

그렇다면 이러한 특성을 이해한 뒤에는 어디에 적용되는지를 알아봐야 그 차이를 극명하게 이해할 수 있다. 우선 GET은 가져오는 것이다. 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태 등을 변경하지 않는다. SELECT적인 성향을 갖고 있다고 볼 수 있는 것이다. 반면에 POST는 서버의 ㄱ밧이나 상태를 변경하기 위해서 또는 추가하기 위해서 사용된다.

부수적인 차이점을 좀 더 살펴보자면 GET방식의 요청은 브라우저에서 Caching할 수 있다. 때문에 POST방식으로 요청해야 할 것을 데이터의 크기가 작고 보안적인 문제가 없다는 이유로 GET방식으로 요청한다면 기존에 caching되었던 데이터가 응답될 가능성이 존재한다. 때문에 목적에 맞는 기술을 사용해야 한다.

2. 3-way-handshake & 4-way-handshake

연결 성립(Connection Establishment)

1) 클라이언트는 서버에 접속을 요청하는 SYN(a) 패킷을 보낸다.

2) 서버는 클라이언트의 요청인 SYN(a)을 받고 클라이언트에게 요청을 수락한다는 ACK(a+1)와 SYN(b)이 설정된 패킷을 발송한다.

3) 클라이언트는 서버의 수락 응답인 ACK(a+1)와 SYN(b) 패킷을 받고 ACK(b+1)를 서버로 보내면 연결이 성립(establish)된다.

연결 해제 (Connection Termination)

1) 클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다.

2) 서버는 클라이언트의 요청(FIN)을 받고 알겠다는 확인 메시지로 ACK 를 보낸다.

2-1) 그리고나서는 데이터를 모두 보낼 때까지 잠깐 TIME_OUT된다.

3) 데이터를 모두 보내고 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN플래그를 전송한다.

4) 클라이언트는 FIN메시지를 확인했다는 메시지(ACK)를 보낸다.

5) 클라이언트의 ACK메시지를 받은 서버는 소켓 연결을 close한다.

6) 클라이언트는 아직 서버로부터 받지 못한 데이터가 있을 것을 대비해 일정 시간 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거친다. (TIME_WAIT)

What is the SYN Packet? ACK Packet?

• SYN: Synchronize sequence number
• ACK: Acknowledgement

TCP Header에는 Code Bit(Flag Bit)라는 부분이 존재한다. 이 부분은 총 6Bit로 이루어져 있으며 각각 한 bit들이 의미를 갖고 있다. Urg-Ack-Psh-Rst-Syn-Fin 순서로 되어 있으며 해당 위치의 비트가 1이면 해당 패킷이 어떠한 내용을 담고 있는 패킷인지를 나타낸다. SYN 패킷일 경우엔 000010이 되고 ACK 패킷일 경우에는 010000이 되는 것이다.

Why two types of packets?

일단 연결을 성립하려면 서로 통신이 가능한지를 먼저 파악하기 위해 패킷을 먼저 주고받아야 한다는 것까지는 이해가 쉽다. 그런데 두 종류의 패킷을 주고 받는다. 요청과 응답에 대한 패킷을 주고 받아야 하기 때문에 두 종류인 것이다.

Why 3-way? Is not enough 2-way?

일단 클라이언트가 자신의 목소리가 들리는지 물어본다.(SYN) 서버는 클라이언트의 목소리가 들린다고 말한다. (SYN +1) 그리고 자신의 목소리가 들리는지 물어본다. (ACK) 클라이언트는 서버의 목소리가 들린다고 말한다. (ACK + 1)이런 과정인 셈이다.

TCP connection은 양방향성(bidirection) conneciton이다. 클라이언트에서 서버에게 존재를 알리고 패킷을 보낼 수 있다는 것을 알리듯, 서버에서도 클라이언트에게 존재를 알리고 패킷을 보낼 수 있다는 신호를 보내야 한다. 그렇기 때문에 2-way handshake로는 부족하다.

Why randomized sequence number?

처음 클라이언트에서 SYN 패킷을 보낼 때 Sequence Number에는 랜덤한 숫자가 담겨간다. 초기 sequence number를 ISN이라고 한다. ISN이 0부터 시작하지 않고 난수를 생성해서 number를 설정하는 이유는 무엇일까?

Connection을 맺을 때 사용하는 포트(port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 number가 전송된다면 이전의 connection으로부터 오는 패킷으로 인식할 수 있다. 이러한 문제가 발생할 가능성을 줄이기 위해서 난수로 ISN을 설정하는 것이다.

3. TCP와 UDP의 비교

UDP

UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)는 비연결형 프로토콜이다. IP 데이터그램을 캡슐화하여 보내는 방법과 연결 설정을 하지 않고 보내는 방법을 제공하낟. UDP는 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않는다. 이 모두가 사용자 프로세스의 몫이다. UDP가 행하는 것은 포트들을 사용하여 IP 프로토콜에 인터페이스를 제공하는 것이다.

종종 클라이언트는 서버로 짧은 요청을 보내고, 짧은 응답을 기대한다. 만약 요청 또는 응답이 손실된다면, 클라이언트는 time out되고 다시 시도할 수 있으면 된다. 코드가 간단할 뿐만 아니라 TCP처럼 초기설정(initial setup)에서 요구되는 프로토콜보다 적은 메시지가 요구된다. 

UDP를 사용한 것들에는 DNS가 있다. 어떤 호스트 네임의 IP주소를 찾을 필요가 있는 프로그램은, DNS서버로 호스트 네임을 포함한 UDP 패킷을 보낸다. 이 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답한다. 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다.

TCP

대부분의 인터넷 응용 분야들은 신뢰성과 순차적인 전달을 필요로 한다. UDP로는 이를 만족시킬 수 없으므로 다른 프로토콜이 필요하여 탄생한 것이 TCP이다. TCP(Transmission Control Protocol, 전송제어 프로토콜)는 신뢰성이 없는 인터넷을 통해 종단간에 신뢰성 있는 바이트 스트림을 전송 하도록 특별히 설계되었다. TCP 서비스는 송신자와 수신자 모두가 소켓이라고 부르는 종단점을 생성함으로써 일어진다. TCP에서 연결 설정(connection establishment)는 3-way handshake를 통해 행해진다.

모든 TCP연결은 전이중(full-duplex), 점대점(point to point)방식이다. 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미하며 점대점이란 각 연결이 정확히 2개의 종단점을 가지고 있음을 의미한다. TCP는 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.

4. HTTP와 HTTPS 

HTTP의 문제점

• HTTP는 평문 통신이기 때문에 도청이 가능하다.
• ㅇ통신 상대를 확인하지 않기 때문에 위장이 가능하다.
• 완전성을 증명할 수 없기 때문에 변조가 가능하다.

위 세가지는 다른 암호화하지 않은 프로토콜에도 공통되는 문제점들이다.

TCP/CP는 도청 가능한 네트워크이다

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.

보완 방법

1. 통신 자체를 암호화 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS(HTTP Secure) or HTTP over SSL이라고 부른다.
2. 콘텐츠르 암호화 말 그대로 HTTP를 사용해서 운반하는 내용인, HTTP메시지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.

통신 상대를 확인하지 않기 때문에 위장이 가능하다

HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 리퀘스트를 보낼 수 있다. IP주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다. 이러한 특징은 여러 문제점을 유발한다.

1. 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다.
2. 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 알 수 없다.
3. 통신하고 있는 상대가 접근이 허가된 상대인지 확인할 수 없다.
4. 어디에서 누가 리퀘스트 했는지 확인할 수 없다.
5. 의미없는 리퀘스트도 수신한다. -> Dos 공격을 방지할 수 없다.

보완방법

위 암호화 방법으로 언급된 SSL로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 된다. 한 가지 이점을 더 꼽자면 클아이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.

완전성을 증명할 수 없기 때문에 변조가 가능하다

여기서 완전성이란 정보의 정확성을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다.

보완 방법

MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다. SSL에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.

5. HTTPS

HTTP에 암호화와 인증, 그리고 완전성 보호를 더한 HTTPS

HTTPS는 SSL의 껍질을 덮어쓴 HTTP라고 할 수 있다. 즉, HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체하는 것 뿐이다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

HTTPS의 SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 고통키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.

모든 웹 페이지에서 HTTPS를 사용해도 될까?

평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소르를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.

하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 시용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.

6. DNS round robin 방식

DNS round robin 방식의 문제점

1. 서버의 수 만큼 공인 IP주소가 필요함.
   • 부하 분산을 위해 서버의 대수를 늘리기 위해서는 그 만큼의 공인 IP가 필요하다.
2. 균등하게 분산되지 않음
   • 모바일 사이트 등에서 문제가 될 수 있는데, 스마트폰의 접속은 캐리어 게이트웨이 라고 하는 프록시 서버를 경유한다. 프록시 서버에서는 이름변환 결과가 일정 시간 동안 캐싱되므로 같은 프록시 서버를 경유하는 경우 접속은 항상 같은 서버로 접속된다. 또한 PC용 웹 브라우저도 DNS 결과를 캐싱하기 때문에 균등하게 부하분산 되지 않는다. DNS레코드의 TTL값을 짧게 설정함으로서 어느 정도 해소가 되지만, TTL에 따라 캐시를 해제하는 것은 아니므로 반드시 주의가 필요하다.
3. 서버가 다운되도 확인 불가
   • DNS서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의 결과를 제어할 수 없다. 웹 서버의 부하가 높아서 응답이 느려지거나 접속수가 꽉 차서 접속을 처리할 수 없는 상황인 지를 전혀 감지할 수가 없기 때문에 어떤 원인으로 다운되더라도 이를 검출하지 못하고 유저들에게 제공한다. 이때문에 유저들은 간혹 다운된 서버로 연결이 되기도 한다. DNS 라운드 로빈은 어디까지나 부하분산을 위한 방법이지 다중화 방법은 아니므로 다른 S/W와 조합해서 관리할 필요가 있다.

Round Robin 방식을 기반으로 단점을 해소하는 DNS 스케줄링 알고리즘이 존재한다. (일부만 소개)

1. Weighted Round Robin(WRR)

- 각각의 웹 서버에 가중치를 가마해서 분산 비율을 변경한다. 물론 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다.

2. Least connection

- 접속 클라이언트 수가 가장 적은 서버를 선택한다. 로드밸런서에서 실시간으로 connection 수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다.

6. 웹 통신의 큰 흐름

우리가 Chrome 을 실행시켜 주소창에 특정 URL 값을 입력시키면 어떤 일이 일어나는가?

in 브라우저

1. url에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사한다.
2. 조사된 의미에 따라 HTTP Request메시지를 만든다.
3. 만들어진 메시지를 웹 서버로 전송한다.

이 때 만들어진 메시지 전송은 브라우저가 직접하는 것이 아니다. 브라우저는 메시지를 네트워크에 송출하는 기능이 없으므로 OS에 의뢰하여 메시지를 전달한다. 우리가 택배를 보낼 때 직접 보내는게 아니라, 이미 서비스가 이루어지고 있는 택배 시스템(택배 회사)을 이용하여 보내는 것과 같은 이치이다. 단, OS에 송신을 의뢰할 때는 도메인명이 아니라 ip주소로 메시지를 받을 상대를 지정해야 하는데, 이 과정에서 DNS서버를 조회해야 한다.

in 프로토콜 스택, LAN 어댑터

1. 프로토콜 스택(운영체제에 내장된 네트워크 제어용 소프트웨어)이 브라우저로부터 메시지를 받는다.
2. 브라우저로부터 받은 메시지를 패킷 속에 저장한다.
3. 그리고 수신처 주소 등의 제어정보를 덧붙인다.
4. 그런 다음, 패킷을 LAN 어댑터에 넘긴다.
5. LAN 어댑터는 다음 Hop의 MAC 주소를 붙인 프레임을 전기신호로 변환한다.
6. 신호를 LAN케이블에 송출시킨다.

프로토콜 스택은 통신 중 오류가 발생했을 때, 이 제어 정보를 사용하여 고쳐 보내거나, 각종 상황을 조절하는 등 다양한 역할을 하게 된다. 네트워크 세계에서는 비서가 있어서 우리가 비서에게 물건만 건네주면, 받는 사람의 주소와 각종 유의사항을 써준다! 여기서는 프로토콜 스택이 비서의 역할을 한다고 볼 수 있다.

in 허브, 스위치, 라우터

1. LAN어댑터가 송신한 프레임은 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착한다.
2. 라우터는 패킷을 프로바이더(통신사)에게 전달한다.
3. 인터넷으로 들어가게 된다.

in 액세스 회선, 프로바이더

1. 패킷은 인터넷의 입구에 있는 액세스 회선(통신 회성)에 의해 POP(Point tOf Presence, 통신사용 라우터)까지 운반된다.
2. POP를 거쳐 인터넷의 핵심부로 들어가게 된다.
3. 수 많은 고속 라우터들 사이로 패킷이 목적지를 향해 흘러가게 된다.

in 방화벽, 캐시서버

1. 패킷은 인터넷 핵심부를 통과하여 웹 서버측의 LAN에 도착한다.
2. 기다리고 있던 방화벽이 도착한 패킷을 검사한다.
3. 패킷이 웹 서버까지 가야하는지 가지 않아도 되는지를 판단하는 캐시서버가 존재한다.

굳이 서버까지 가지 않아도 되는 경우를 골라낸다. 액세스한 페이지의 데이터가 캐시서버에 있으면 웹 서버에 의뢰하지 않고 바로 그 값을 읽을 수 있다. 페이지의 데이터 중에 다시 이용할 수 있는 것이 있으면 캐시 서버에 저장된다.

in 웹 서버

1. 패킷이 물리적인 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘긴다.
2. 메시지를 받은 웹 서버 애플리케이션은 요청 메시지에 따른 데이터를 응답 메시지에 넣어 클라이언트로 회송하낟.
3. 왔던 방식대로 응답 메시지가 클라이언트에게 전달된다.

2022-07-13

SSL

SSL( Secure Sockets Layer ) 프로토콜로 Nescape에 의해서 SSL이 발명되었고, 지금은 TLS라는 이름으로 바뀌었다. 그러나 TLS보다 SSL이라는 이름이 훨씬 더 많이 사용되고 있다.

SSL DIgital Certification

SSL 인증서는 Client와 Server간의 통신을 제3자가 보증해주는 전자화된 문서이다. Client가 Server에 접속한 직후에 서버는 클라이언트에게 이 인증서를 전달한다. Client는 Server로 부터 전달받은 인증서가 신뢰할 수 있는 인증서인지를 검증한다.

SSL Digital Certification을 통해서

1. Client와 Server간의 통신내용을 공격자가 엿듣는 것을 방지할 수 있다.

2. Client가 접속하고자 하는 Server가 신뢰할 수 있는 Server인지 판단할 수 있다.

3. 공격자의 악의적인 통신내용 변경을 방지할 수 있다.

SSL Certification Structure

아래는 Node.js 공식 홈페이지의 인증서를 X509 module을 사용해서 정보를 추출한 것이다.

X509Certificate {
  subject: 'CN=*.nodejs.org',
  subjectAltName: 'DNS:*.nodejs.org, DNS:nodejs.org',
  issuer: 'C=GB\n' +
    'ST=Greater Manchester\n' +
    'L=Salford\n' +
    'O=Sectigo Limited\n' +
    'CN=Sectigo RSA Domain Validation Secure Server CA',
  infoAccess: 'CA Issuers - URI:http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt\n' +
    'OCSP - URI:http://ocsp.sectigo.com\n',
  validFrom: 'Jan 11 00:00:00 2022 GMT',
  validTo: 'Feb 11 23:59:59 2023 GMT',
  fingerprint: '3E:CB:75:F0:77:06:6A:8C:A0:4A:9F:01:6E:EC:1B:0F:98:95:8F:63',
  fingerprint256: '9D:33:45:9A:91:1A:B5:2F:D5:11:01:5F:5E:29:4B:D6:1D:C2:37:5B:4F:46:20:7C:E8:62:D0:30:50:D6:73:5E',
  fingerprint512: '7C:D0:4C:83:B8:D9:B1:7B:1B:74:83:13:D3:F1:98:92:07:EE:7B:79:E8:94:71:83:4D:7D:A3:F8:8C:E1:B4:30:47:47:84:27:AF:4F:9B:4C:41:CA:7A:8F:2B:25:BF:FB:82:94:69:88:CF:90:75:31:BF:CC:92:40:30:B4:79:E1',
  keyUsage: [ '1.3.6.1.5.5.7.3.1', '1.3.6.1.5.5.7.3.2' ],
  serialNumber: '5F6C6A819EFF2783C1DC54DD3502E901'
}

• subject : 소유자 
  • CN ( CommonName ) : 이름
• subjectAltName(SAN) 
  • DNS 
  • IP
  • Email
• issuer : 발행자 
  • ST : StateOrProvinceName
  • L : Locality
  • OU : OrganizationUnit : 부서
  • O : Organization : 회사, 조직
  • C : Country : 나라
  • CN : Common Name : 이름
• validFrom : 인증서 발행일
• validTo : 인증서 만료일
• fingerprint == signature 

2022-07-27

2022-07-28일 Demo 시연과 내용 발표를 준비하다가 블로그에 SSL 인증서 내용을 작성했던게 생각나서 PPT자료에 넣은 것을 추가하게 되었따.