개발야옹

🌐 3장. 웹을 구현하는 기술

3.1 웹을 구성하는 구조

3.1.1. 웹과 네트워크

웹(web)은 World Wide Web(WWW)이라는 인터넷에서 제공되는 하이퍼텍스트 시스템이다. 인터넷이라는 표현은 흔히 웹을 가리키지만, 정확히 말해 웹은 인터넷의 한 기능일 뿐이다.

하이퍼텍스트란 문서 안에 다른 문서의 위치 정보를 포함시켜 정보를 서로 연관 지어(하이퍼링크) 참조할 수 있게 만든 문서이다. 이 개념을 인터넷상에서 실현한 것이 웹이다.

웹은 HTML로 대표되는 하이퍼텍스트 언어와 네트워크의 네트워크인 인터넷이 융합되어 탄생하였다.

당초에는 문자 정보만 주고받는 단순한 기술이었지만, 웹 서버에서 동작하는 애플리케이션이나 HTML 언어 자체의 사양이 확장되면서 이용 범위가 확대되었다. 지금은 전자상거래, 온라인 뱅킹, 게임, 동영상 서비스 등 다양한 용도로 활용된다.

3.1.2. 클라이언트와 서버

웹으로 제공되는 서비스 대부분은 서비스를 제공하는 쪽(서버)과 서비스를 받는 쪽(클라이언트)으로 나뉜다. 이를 클라이언트 서버 모델이라고 한다. 서버에 시스템을 설치하고 사용자는 클라이언트에서 서버에 액세스한다.

웹 서비스를 예시로, 서버는 그 역할의 성격상 유지 보수를 해야 하기 때문에 일시적으로 멈출 수 있지만, 기본적으로 언제든지 클라이언트 요구에 대응할 수 있도록 24시간 365일 가동해야 한다.

반면 클라이언트는 서비스를 이용할 때만 동작해야 한다. 사용하지 않을 때는 전원을 끌 수 있으며, 항상 동작하는 것은 아니다. 또 인간이 사용하므로 편의성이나 휴대성 같은 것을 고려해서 만들고 있다.

3.1.3. 웹 서버

웹은 클라이언트 서버 모델을 기반으로 하는 시스템으로, 정보 제공자가 웹 서버를 공개하고 사용자가 웹 브라우저를 통해 웹 서버에 있는 정보에 액세스 하는(브라우징) 형식을 기본으로 한다. 

웹 서버는 정보를 전송하거나 서비스를 제공하려고 365일 계속해서 동작하는 컴퓨터를 의미한다. 아파치(Apache)나 엔진엑스(Nginx)처럼 컴퓨터상에서 웹 서버 기능을 제공하는 구체적인 애플리케이션을 가리켜 웹 서버로 지칭할 때도 있으니 주의해야 한다.

웹 서버의 가장 기본적인 역할은 웹 페이지를 공개하는 것이다. HTML로 작성된 문서를 인터넷에 공개하는 역할을 담당한다. 웹 서버에서 애플리케이션을 실행할 수 있는 CGI(Common Gateway Interface) 기술로 인터넷에서는 정보를 양방향으로 교환하게 되었다. 현재는 서버 사이드 언어나 데이터베이스 등과 연계하여 웹에서 많은 일을 할 수 있게 되었다.

3.1.4. HTTP와 HTTPS

HTTP는 서버와 클라이언트 사이에서 데이터를 주고받는 프로토콜이다. 웹이 처음 만들어질 당시에는 정보 공유를 목적으로 한 시스템이었기 때문에 통신 경로에서 정보를 감출 필요가 없었다. 그러나 이용 범위가 확대되면서 웹 서버에 데이터를 전송할  때는 암호화하여 정보 기밀성을 확보할 필요가 생겼다. 그래서 만들어진 것이 HTTPS 프로토콜이다.

HTTPS는 SSL/TLS 구조로 구현되었다. SSL(Secure Sockets Layers)과 TLS(Transport Layer Security)는 인터넷에서 통신을 암호화하여 제삼자가 통신 내용을 훔쳐보거나 조작할 수 없게 하는 기술이다. 

SSL은 넷스케이프가 개발한 프로토콜이고, TLS는 SSL을 계승하여 IETF라는 표준화 조직의 TLS 워킹 그룹에서 책정한 프로토콜이다. 현재는 SSL 이 아닌 TLS가 사용되고 있어 TLS라고만 표기해도 되지만, 여전히 SSL 지명도가 높기 때문에 SSL/TLS로 병기하거나 그냥 SSL이라고 할 때도 많다.

3.1.5. SSL 인증서

SSL/TLS를 웹 사이트에서 이용하려면 SSL인증서가 필요하다. SSL 인증서란 인증 기관(CA, Certification Authority)이라는 신뢰할 수 있는 제삼자 기관이 이용자(도메인 소유자)에게 발행하는 것이다.

SSL 인증서의 역할

SSL인증서는 다음 세 가지 목적으로 이용한다.

1. 데이터 암호화:
   • SSL 인증서에 포함되는 공개 키를 사용함으로써 암호화 통신을 위한 비밀키를 안전하게 교환할 수 있고, 암호화 통신을 실현할 수 있다.
2. 도메인 소유 증명:
   • SSL 인증서로 해당 도메인은 A가 소유하는 도메인이라는 것을 제삼자인 인증기관에서 보증한다.
3. 데이터 변조 방지:
   • 제삼자 기관이 보증하는 인증서로 암호화된 통신은 변조되지 않고 확실하게 A의 정보임을 보증한다.

인증 기관 신뢰

인증 기관은 인증 기관 운영 규정이라는 문서를 공개하여 보안 정책을 규정하고, 본사를 둔 국가의 정부 등이 이 문서를 인증함으로써 우리는 인증 기관을 신뢰할 수 있다.

인증 레벨에 따른 종류

SSL 인증서는 인증 레벨에 따라 도메인 인증(DV), 기업 인증(OV), EV인증(EV) 세 가지로 나눌 수 있다. 모든 인증서가 SSL/TLS을 이용한 암호화 통신 기능을 제공하지만, 인증서를 발행하는 조직이 실제로 있는지를 증명하는 범위에는 차이가 있다.

• 도메인 인증(DV, Domain Validation)은 도메인에 등록된 등록자를 확인하고 발행하는 인증서이다. 도메인 소유만 확인할 뿐 도메인 및 인증서 소유자를 인증하는 것은 아니다. 발행 속도가 빠르고 가격이 저렴하여 개인 사이트뿐만 아니라, 기업체, 각종 미디어 등에 폭넓게 이용된다. 특히 개인정보나 신용 카드 정보 등 민감한 정보를 주고받지 않고, 검색 엔진 최적화(SEO, Search Engine Optimization) 이유로 항상 SSL을 적용해야 하는 웹 사이트에서 도메인 인증서를 많이 사용한다.
• 기업 인증(OV, Organization Validation)은 도메인과 더불어 웹 사이트를 운영하는 조직의 실재성을 인증하는 인증서이다. 인증서 발행처가 운영 조직의 실재성을 인증하기 때문에 개인 정보나 신용 카드 정보 등 민감한 정보를 주고받는 웹 사이트 등에 이용된다.
• EV 인증(EV, Extrended Validation)은 기업의 실재성과 더불어 소재지를 인증한다. 인증서로 웹 사이트 운영 조직을 확인할 수 있다. 기업의 실재성을 인증한다는 점에서 기업 인증(OV)과 같다고 생각할 수 있다. 그러나 소재지 확인 등 더욱 엄격한 심사를 거치고 시각적으로도 확인할 수 있어 개인 정보나 신용 카드 정보 등 민감한 정보를 주고받는 웹사이트와 온라인 뱅킹 및 금융 기관과 연계되는 핀테크(Fintech) 서비스를 제공하는 웹 사이트 등에 이용된다.

3.1.6. URL과 DNS

URL

URL(Uniform Resource Locator)은 인터넷상에서 HTML이나 이미지 등 리소스 위치를 특정할 수 있는 서식으로 탄생했다. URL의 기본 서식은 스킴(프로토콜 + ://)과 서버 주소(또는 호스트 이름 + 도메인)에 다음 두 가지를 /로 연결한 것이다.

• 디렉터리 이름
• 파일 이름

DNS

웹 사이트 주소를 http://93.184.216.34/news/index.html처럼 IP 주소로 표기하면 기억하기 어렵다. 호스트 이름과 도메인으로 바꾸어 http://www.example.com/news/index.html로 변경하면 기억하기 쉽고 쓰기도 쉽다. 

하지만 인터넷에서는 반드시 IP주소로 접속할 대상을 지정하므로 www.example.com 이 사실을 조회하는 시스템이 필요하다. 이 시스템이 DNS(Domain Name System)이다.

DNS는 인터넷사의 거대한 분산 데이터베이스라고 할 수 있다. DNS는 콘텐츠 DNS서버와 캐시 DNS 서버 두 가지로 구성된다. 

콘텐츠 DNS 서버는 각 도메인의 바탕이 되는 기본 정보를 가지고 있고, 캐시 DNS 서버는 컴퓨터나 휴대전화 등 클라이언트가 문의하면 콘텐츠 DNS 서버를 찾아 정보를 요청한다. 캐시 DNS 서버는 콘텐츠 DNS 서버의 조회 결과를 바탕으로 클라이언트에 정보를 전달한다.

3.2. 도메인

도메인이란 인터넷상 주소로, 글로벌 IP주소를 가진 서버가 어디에 있는지 판단하는 정보로 이용된다. 글로벌 IP 주소가 있는 서버는 일반적으로 웹 사이트를 가리킨다. 

3.2.1. 도메인 관리 기관

도메인을 전 세계적으로 관리하는 곳은 ICANN이라는 비영리 단체이다. 그 밖에도 도메인을 다루는 조직으로 레지스트리와 레지스트가 있다.

레지스트리는 도메인 관리 기관으로, 각 도메인 정보의 데이터베이스를 관리한다. 레지스트리에 따라서 관리하는 도메인이 달라진다.

레지스트라는 도메인 중개 등록 업체로, 레지스트리가 관리하는 데이터베이스에 직접 도메인 정보를 등록할 수 있다. 도메인을 이용하려면 도메인 이름의 소유자가 누구인지, 어느 DNS 서버에서 관리되는지 같은 정보를 레지스트리 데이터베이스에 기록해야 한다. 이용자가 신청한 정보는 레지스트라를 경유하여 레지스트리의 데이터베이스에 기록된다.

도메인은 레지스트라가 판매하는 것 말고도 레지스트라의 대리점이 판매하는 예도 있다. 국내외로 많은 도메인 판매업자가 있는데 레지스트라가 직접 판매하기도 하고, 레지스트라에서 도메인을 도매로 받아 판매하는 대리점도 있다.

레지스트라는 레지트스리가 관리하는 데이터베이스에 직접 액세스 할 수 있지만, 대리점은 레지스트리가 관리하는 데이터베이스에 액세스할 수 없고 레지스트라를 통해서만 정보를 등록해야 한다.

3.2.2. 도메인 종류

도메인은 크게 두 종류로 나뉜다. gTLD(generic Top Level Domain)와 ccTLD(country code Top Level Domain)이다. 둘 다 ICANN이 관리하지만, 도메인 등록 업무 및 데이터베이스 관리 같은 실제 운영 업무는 레지스트리에 위임한다.

gTLD

gTLD는 전 세계에 등록이 개방된. com,. net,. org와 등록 제한이 있는. edu,. gov,. int,. mil 이렇게 일곱 가지 종류로 시작되었다. 2000년에. biz,. info,. name,. pro,. aero,. coop,. museum 일곱 가지 종류가 추가되었고, 2003년에는. asia,. cat,. jobs,. mobi,. post,. tel,. travel,. xxx가 추가되었다.

2012년부터는 새롭게 창설하는 gTLD 수에 제한을 두지 않고 기술적, 재무적 요건을 충족하는 조직이라면 신청이 가능해져 지금은 매우 많은 gTLD가 존재한다.

일반 이용자도 신청할 수 있는 gTLD 이외에 특정 기업이 전용으로 보유한 gTLD도 있다.

gTLD는 베리사인(Verisign)등의 회사가 레지스트리가 된다.

국내 ICANN인증 레지스트라로는 가비아, 예스닉, 후이즈 등이 있다.

ccTLD(국가 코드 최상위 도메인)

ccTLD는. kr,. us,. uk,. tv 등 전 세계에 200가지 이상이 있으며, 원칙적으로 그 나라에 사는 사람을 대상으로 한다. 하지만 어디까지나 원칙이며, 운영은 각국 네트워크 정보 센처(NIC)에 위임하여 다른 나라 사람에게도 도메인을 개방할 수 있다.

대한민국의 ccTLD는. kr이며, 한국인터넷진흥원(KISA)이 레지스트리로서 운영하고 있다.

. kr의 레지스트라는 가비아, 아이네임즈, 후이즈 등이 있다.

3.2.3. DNS 전환

시스템 전환 작업이나 서버 교체 등 IP 주소가 변경되는 사례는 많이 있다. 이때 DNS 설정도 함께 변경해야 한다.

www.example.com의 IP 주소가 203.0.113.1인 상태가 198.51.1090.1인 상태로 변경해야 하는 경우를 생각해 보자.

원본이 되는 정보는 콘텐츠 DNS 서버가 가지고 있지만, 인터넷상에 여러 개 존재하는 DNS 서버에도 복사된 정보가 있다. (가지고 있지 않은 경우도 있다.) 그리고 캐시 DNS 서버는 한 번 문의한 DNS 정보를 캐시로 보관해 둔다.

캐시 DNS 서버에서 캐시가 사라지고 새로운 정보를 다시 취득할 때 시차가 생긴다. DNS 정보는 스위치처럼 바로 전환할 수 있는 것은 아니고, 새로운 정보가 구석구석 도달하기까지 시간이 걸린다. 원래대로 되돌릴 때도 동일하기 때문에 서버 전환에 실패하고 다시 되돌릴 때도 마찬가지로 시차가 발생한다.

3.3. HTTP와 웹 기술

3.3.1. HTTP

HTTP는 웹 브라우저와 웹 서버 간의 상호 작용을 지원하는 프로토콜이다. HTTP는 데이터를 요청하는 HTTP 요청과 그에 응답하여 데이터를 보내는 HTTP 응답이라는 두 가지 상호 작용을 반복하여 웹 페이지를 표시한다.

HTTP 요청에는 하고 싶은 처리를 나타내는 메서드 이름과 대상 이름이 포함된다.

• GET: 리소스를 가져오도록 웹 서버에 요청
• POST: 웹 서버에 데이터를 송신
• PUT: 웹 서버에 파일을 업로드

HTTP 응답에는 처리 결과를 나타내는 상태 코드와 헤더, 실제 처리 결과인 메시지가 포함된다.

3.3.2. 쿠키와 세션

세션은 웹 사이트를 방문해서 수행하는 일련의 행동이다. HTTP는 데이터를 요청하고 전송하는 상태 비저장 프로토콜이다. 사용자의 '상태'의 관한 정보를 알기 위해 사용하는 것이 쿠키(Cookie)이다. 쿠키란 웹 사이트를 열람한 사용자 정보를 클라이언트가 보관하고, 두 번째 액세스부터는 그 정보를 클라이언트가 서버로 보낸다. 이렇게 하면 다시 방문할 때 사용자를 식별할 수 있어 사용자의 브라우징 특성에 맞는 광고를 제공하거나 사이트 기능에 대한 설정을 저장하여 웹 사이트의 편의성을 높일 수 있다.

세션을 실현하려면 웹 사이트에 접속할 때 세션 ID라는 고유 ID가 할당되어야 한다. 세션 ID를 이용하여 사용자가 누구인지 식별하고, 제품을 추가하는 등의 정보는 세션 ID에 대응하는 세션 변수에 기록된다. 쿠키에 세션 정보를 기록하고, 실제 값(세션 변수 정보)은 서버 측에서 관리하는 방법이 널리 이용된다.

3.3.3. 인증

인증은 컴퓨터나 시스템을 사용할 때 필요한 본인 확인 절차이다. 시스템을 사용할 때 제삼자가 마음대로 사용하거나 제삼자에게 보이지 않도록 하는 인증이라는 메커니즘이 필요하다.

웹에서 인증은 개인 정보를 바탕으로 서비스를 이용하는 것이다. ID와 암호로 인증하는 것이 대부분이지만, 최근에는 다요소 인증(MFA) 이라고 하는 ID와 암호 이외에 일시적으로 발행되는 일회용 패스워드(one-time password)를 입력하는 인증 방식도 있다. 인증 요소를 늘리면 보안이 강화된다. 일회용 패스워드에는 휴대전화 SMS 전송, 전용 일회용 패스워드 생성 소프트웨어 사용, 물리적 하드웨어 토큰 기계에 표시된 암호 등 여러 종류가 있다. 

특정 서비스의 자격 증명을 사용하여 다른 서비스에 로그인할 수 있는 위임 인증 메커니즘도 있다. 이 방식에서 사용되는 기술이 OAuth이다.

기업 시스템의 예

한때 기업의 사내 시스템은 시스템마다 ID와 암호 데이터베이스를 가지고 있는 것이 대부분이었다. 그러나 최근에는 Active Directory나 LDAP라는 인증 기반과 연계되어 ID와 암호 하나만 있으면 사내의 어떤 시스템에도 로그인할 수 있다. 물론 시스템마다 권한에 따라 접근을 제한할 필요가 있다.

3.3.4. 새로운 기술: HTTP/2, Ajax, Web API

HTTP/2

HTTP/2는 HTTP의 새로운 규격이다. HTTP의 메이저 버전업으로 기획된 프로토콜로, 그 기반은 구글이 중심이 되어 개발한 SPDY 프로토콜이다.

HTTP/1.1 에서는 동시에 복수의 요청을 보낼 수 있지만, '요청 하나에 응답 하나'라는 기본 구조는 그대로이다. 그래서 HTML 파일 하나와 이미지 파일 여러 개로 구성된 웹 페이지를 표시할 때도 파일 하나마다 GET 요청을 보내야 한다. 이를 포함하여 HTTP/1.1 사양에는 아래와 같은 문제점이 있었다.

• 한 번에 파일 하나밖에 가져올 수 없다: JS, CSS, 이미지 파일 등 많은 리소스를 이용하는 HTML을 로딩하는 데 시간이 걸린다. 
• 프로토콜이 텍스트 기반이다: 텍스트 파일(프로그램에서 다룰 수 있는 데이터로 변환)에 시간이 걸린다.
• 파일을 가져올 때마다 거의 같은 HTTP 헤더를 송수신한다: 같은 내용을 송수신하는 만큼 오버헤드가 커진다.

이런 문제점을 받아들여 HTTP/2는 HTTP와 호환성을 유지하면서 새로운 전송 수단을 제공하여 기존 문제점을 해결하고 좀 더 적은 통신량으로 더 신속하게 주고받을 수 있도록 설계되었다.

HTTP/2는 커넥션 하나로 복수 콘텐츠를 병렬로 전송할 수 있어, HTTP/1.1 보다 효율이 높은 프로토콜이 되었다.

HTTP/2로 웹 콘텐츠를 전달하려면 SSL/TLS가 꼭 필요하다고 할 수 있다.

Ajax

웹의 편의성을 높인 것으로 알려진 Ajax라고 하는 프로그래밍 기법이 있다.

Ajax는 이미 읽은 웹 페이지에서 다시 HTTP 요청을 보내 웹 페이지 전환 없이 데이터를 송수신할 수 있는 기능을 제공하는 XMLHttpRequest 기술을 사용한다. 

또 XMLHttpRequest로 비동기 통신은 구현할 수 있지만 서버 측에서 푸시 통신을 하는 등 양방향 통신은 어려웠는데, 이를 해결하기 위해 웹소켓(Websocket)이라는 기술도 탄생했다.

Web API

최근에는 각사의 웹 애플리케이션 기능이 Web API로 제공된다. Web API는 사용자 조작과 상관없이 어떤 웹 애플리케이션에서 다른 웹 애플리케이션을 조작할 수 있는 인터페이스이다.

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. 왔던 방식대로 응답 메시지가 클라이언트에게 전달된다.