[Network] L4 계층의 TCP/UDP 그리고 웹의 기술

🔊 해당 포스팅은 인프런 강의 널널한개발자님의 외워서 끝내는 네트워크 핵심이론 - 기초 내용을 공부하면서 배운 내용을 저만의 방식으로 재정리하고자 하는 목적 하에 작성되는 포스팅입니다. 아래 포스팅에서 사용되는 모든 자료는 제가 직접 재구성했음을 알립니다.

 

이번 포스팅에서는 OSI 7 계층 중 전송 계층에 해당하는 L4 계층의 TCP/UDP에 대해 알아보고, 웹(Web)이라는 기술이 역사적으로 어떻게 발전해왔는지 살펴보면서 핵심 요소들을 이해해보자.

 

컴퓨터 간에는 어떻게 통신을 가능하게 하는 걸까?

---

1. TCP는 논리적 연결이다

TCP는 물리적인 것이 아닌 논리적 연결이다. 물리적인 연결은 L2 스위치처럼 말 그대로 진짜 물리적인 회선을 가지고 장치 간에 진짜 연결을 하는 것이다. 하지만 TCP는 이러한 물리적 연결이 아닌 마치 가상화된 논리적 연결이다. 그래서 여기서 '연결'이라는 단어를 영어로 하면 Connection 이라고도 하고 Session이라고도 한다. 그리고 연결은 결과적으로 순서번호가 존재한다. 우리가 이전 포스팅에서 잠시 살펴보았던 TCP/IP 송,수신 구조 그림의 일부분을 살펴보자.

 

데이터의 일부를 쪼개어 Segment로 분할 하여 송/수신을 한다

 

분홍색 점선 네모칸으로 표시된 부분을 주목해보자. TCP/IP 송,수신 과정에서 데이터를 Segment라는 단위로 쪼개져서 전달되고, 수신측에서 데이터를 잘 받으면 송신 측으로 잘 받았다고 내용을 전달해줄 때 Segment 번호를 전달해준다고 했다. 이 말은 Segment에 일종의 번호가 붙혀져 있다는 것이고 이것이 곧 TCP 연결의 순서번호를 의미한다. 순서 번호가 1,2,3,4 씩 증가해서 붙는 것은 아니고 순서 번호는 Segment의 데이터 용량 바이트 수만큼 증가한다. 

 

그리고 TCP도 '연결'이라고 한 점에서 알 수 있는 부분은 바로 상태 전이 개념을 동반한다는 것이다. 아래 그림으로 클라이언트, 서버로 구성되는 TCP 연결 과정에 대해 알아보자.

 

TCP 연결시, 클라이언트/서버가 동작하는 순서 과정

(위 그림에서 '데이터 수신 측' 과 '데이터 송신 측' 간의 위치가 서로 바뀌었다는 점 알려드립니다)

 

가장 먼저 클라이언트와 서버 둘다 네트워크 통신을 위한 소켓을 생성하고 개방한다. 이 때 서버 측은 클라이언트의 요청을 받는 역할이므로 대기 상태(Listen)에 돌입한다. 그리고 난 후, 클라이언트와 서버의 커널들 모두 각각 통신 시 식별자인 포트번호를 부여한다. 그리고 라우터와 인터넷 장치들을 통해 통신을 하는 순서이다.

 

다음으로 살펴볼 것은 TCP 연결 자체를 수행하는 과정인 3-way handshaking 과정에 대해 알아보자. 여기서 '연결 자체를 수행'한다는 것은 말 그대로 TCP 연결 상태를 만드는 것이라서 이 과정 중에 데이터(페이로드)가 전송되는 것은 아니다. 데이터는 TCP 연결 상태를 만든 이후에 수행된다고 한다(질문/답변)

 

TCP 연결 시 수행하는 3-way handshaking 과정

 

가장 먼저 클라이언트, 서버 모두 Sequence Number 라는 것을 생성한다. 이 숫자는 랜덤으로 생성된다. 최초로는 클라이언트가 서버 쪽으로 SYN(synchronization) 이라는 메세지와 시퀀스 넘버를 함께 보낸다(이 때 클라이언트 상태는 SYN_SENT). 그 때 동시에 서버는 대기 상태인 LISTEN 상태에 있다가 클라이언트에서 보낸 SYN 메세지를 받으면 SYN_RCVD 상태로 변한다. 

 

그리고 서버는 클라이언트로 받았던 메세지를 잘 수신했다는 ACK(acknowledgement)이라는 메세지를 보내는데, 이 때 클라이언트에서 보낸 시퀀스 넘버에 숫자 1을 더해서 보낸다. 그리고 서버 측에서도 클라이언트와 연결을 확인하기 위해 SYN 메세지와 서버 쪽에서 생성한 시퀀스 넘버(4000)을 함께 보낸다.

 

그러면 서버의 메세지를 받은 클라이언트는 드디어 서버와 TCP 연결이 되었다는 상태인 ESTABLISHED가 되고, 이 연결이 되었다는 상태를 인정하기 위해 서버 측으로 다시 ACK 메세지를 보낸다. 이 때 서버 쪽에서 보낸 시퀀스 넘버 4000에 1을 더한 값도 같이 함께 넣어 보낸다. 

 

클라이언트 측에서 보낸 ACK 메세지를 받은 서버쪽은 그제서야 드디어 클라이언트와 TCP 연결이 완료되었다고 생각하며 ESTABLISHED 상태로 변경된다. 여기서 한가지 주목할 점은 클라이언트와 서버 각각 TCP 연결이 완료되었다는 시점의 차이가 약간 존재한다는 것이다. 아래처럼 말이다. 그래서 클라이언트, 서버 간의 TCP 연결은 동시에 된다기 보다는 클라이언트가 먼저 연결 상태가 되고 약간 시간이 흐른 뒤 서버의 연결 상태가 완료된다.

 

클라이언트와 서버 간의 TCP 연결 완료 상태가 되는 지점에는 약간 시간 차이가 존재

 

위 과정에서 추가적으로 알아둘 점이 있다. 위와 같이 TCP 연결을 수행하는 3-way handshaking 하는 과정에서 주고받는 정보들에 대한 것이다.

 

먼저 Segment 라는 것을 주고 받는데, 바로 L4 계층에서의 데이터 유통 단위인 Segment와 동일하다. 하지만 TCP 연결 과정에서 흐르는 Segment는 사실 실질적인 데이터가 담기는 페이로드 부분은 없고 TCP/IP 헤더 부분만 존재한다. 즉, 이 때 흐르는 Segment는 단순 내수연결을 위한 관리 목적의 특이한 용도의 세그먼트이다.

 

그리고 TCP 연결하는 동안 주고 받는 정보가 여러가지가 있지만, 그중에서도 MSS(Maximum Segment Size)에 대해서도 주고받는다. 왜 이것을 주고 받을까? 만약 클라이언트에서 설정된 MSS가 1.5KB 이고 서버에서 설정된 MSS가 1.3KB 라면 클라이언트에서 1.5KB 용량의 Segment를 전송할 수 없을 것이다. 이러한 경우에는 작은 MSS에 맞추어야 한다. 물론 작은 MSS에 맞추게 되면 전송 효율이 떨어지는 것은 감안해야 한다.(개인적으로 이런 상황에서 클라이언트에서의 MSS를 어떻게 보면 압축하는 것이기 때문에 Segment에 담겨져 있는 헤더 정보에서 데이터 손실이 일어나는 게 아닌가 했는데, 데이터 손실까지는 아니라고 한다. 질문/답변)

 

다음으로 알아볼 내용은 이제 TCP 연결을 했으니, 종료하는 과정인 4-way handshaking 과정에 대해 알아보자. 연결할 때는 3가지 동작이였는데, 1가지가 추가되었다. 아래 그림을 보자.

 

TCP 연결 종료 시 수행하는 4-way handshaking 과정

 

TCP 연결 때와 마찬가지로 종료 시에도 먼저 요청을 하는 주체는 주로 클라이언트이다. 최초에는 클라이언트와 서버 모두 연결 상태(ESTABLISHED)일 것이다. 그리고 클라이언트는 서버 쪽으로 FIN(finish)과 ACK 메세지를 보낸다. 서버는 해당 메세지를 받고 (클라이언트가) 끊자고 한 요청을 받는 상태인 CLOSE_WAIT가 된다.

 

이렇게 서버 쪽으로 메세지를 보낸 클라이언트는 이 순간에 연결 종료 상태를 기다리는 FIN_WAIT 1번 상태로 변하고 서버 측에서 ACK 메세지를 보내면 그 때 FIN_WAIT 2번 상태로 재변경된다. 

 

그런 다음 TCP 연결 때와는 달리 이번엔 서버 측에서 요청을 시작한다. 방금까지는 [클라이언트 → 서버] 쪽으로 연결을 끊자고 한 통신이였다면 지금은 해당 요청을 받고 서버쪽에서도 [서버 → 클라이언트] 쪽으로 연결을 끊자고 하는 통신도 수행하는 것이다. 이 통신을 하는 순간 서버는 LAST_ACK 라는 상태로 변하게 되고 클라이언트 쪽으로 FIN, ACK 메세지를 보낸다. 

 

이를 받은 클라이언트는 상태가 TIME_WAIT로 변하게 된다. 이 TIME_WAIT 키워드를 잘 기억해두자. 해당 키워드의 상태는 반드시 연결을 끊고자 한 주체에서 발생한다. 보통은 클라이언트일 것이고 만약 서버 측에서 해당 키워드의 상태가 발견되면 이는 뭔가 특수한 상황임을 의미한다.

 

마지막으로 클라이언트는 서버 측으로 ACK 메세지를 보냄에 따라 클라이언트, 서버 모두 연결 종료 상태인 CLOSED 상태로 변하게 된다. 이후 TCP 연결 시 사용한 소켓들은 회수된다.(참고로 소켓도 본질적으로 파일의 형태이며 소켓도 유한한 자원이다. 그래서 반드시 TCP 연결이 종료되면 회수해야 한다)

 

그리고 UDP에 대해서는 잘 언급하지 않았는데, UDP는 간단하다. 방금까지 TCP는 서버 측에서의 응답을 받으면서 계속 대기하고 하지만 UDP는 상대의 응답이 오건 안오건 계속 통신하는 것이다. UDP를 사용하는 대표적인 예시는 게임 서버 쪽에서 자주 사용한다고 한다. 만약 게임을 이용하는 유저가 100명인데, 당연히 이 100명의 유저 모두 각기 네트워크 속도가 천차만별일 것이다. 만약에 이럴 때 TCP를 사용한다고 하면 100명 중 가장 느린 네트워크 속도를 갖는 유저 1명 때문에 나머지 99명의 게임 화면이 정지해버리는 상황이 발생한다. 그래서 이럴 때는 UDP를 이용해서 마치 "1명의 느린 네트워크를 갖는 유저는 버리는..?" 셈이다.

2. www.naver.com 을 입력하면 무슨일이 일어날까? DNS

다음은 DNS와 관련된 내용이다. DNS는 간단히 말해서 특정 도메인 주소를 요청하면 www.naver.com  처럼 IP 주소 값을 변환하는 것이다. 먼저 도메인 네임과 호스트 네임에 대해 알아보자. 만약 www.naver.com  이라는 도메인이 있다면 dot($.$)으로 구분된 3개의 키워드 간에는 종속 관계는 아래와 같다.

 

 

 

그러면 어떻게 해서 위와 같은 종속 관계를 갖는걸까? 일단 www.naver.com  에서 도메인 네임과 호스트 네임이 어떤 것을 의미하는지 알아보자.

 

 

가장 하위에 속하는 www는 호스트 네임에 속하고, 나머지 부분이 도메인 네임에 속한다. 그래서 www.naver.com  을 브라우저에 입력하게 되면 뜻은 위와 같다. 이제 위에서 살펴본 종속 관계를 다시 정리하면 아래와 같다.

 

 

그러면 이제 우리가 www.naver.com  을 브라우저에 입력하였을 때 내부적으로 어떤 일이 발생하는지 알아보자. 과정은 다음과 같다.

 

www.naver.com을 웹브라우저에 입력했을 때 일어나는 과정

 

그림에 번호를 달아놓았다. 번호 대로 과정이 진행된다고 보면 된다. 우리가 추가로 알아둘 점이 있는데, 유효기간과 DNS Cache이다. 먼저 유효기간이라는 것은 PC가 DNS 서버로부터 IP 주소를 응답받을 때 같이 응답받는 정보이다. 이 유효기간은 앞으로 $N$ 시간 동안에는 PC가 DNS에 요청한 도메인을 또 요청하면 DNS 서버로 요청하는 데까지 가지 않고 그 전에 응답했던 동일한 IP 주소를 얻을 수 있는 일종의 제한 시간이다. 당연히 이 $N$ 시간이 지나고 난 뒤에는 DNS 서버로 재요청을 한다.

 

다음은 DNS Cache이다. 개인 PC는 DNS 서버에 한 번 요청(질의)을 하면 PC가 RAM에 DNS 서버로부터 응답받은 IP 주소를 가지고 있는 기능을 의미한다.  이건 별개지만 참고로 공유기가 DNS로 포워딩해서 DNS 역할을 대체하기도 한다고 한다. 그리고 hosts 라는 파일에 특정 도메인에 대한 IP 주소가 적혀있다면 해당 도메인으로는 DNS로 요청하지 않는다.

 

자, 그러면 위 그림을 보았을 때는 DNS 서버가 모든 도메인과 IP 주소의 매핑을 관리하고 요청하는 것들에 대해 IP 주소를 찾아서 보내주는 행동을 하는걸까? 사실 저 그림 속의 DNS 서버도 어딘가에 있는 중앙 DNS 서버에 재귀적으로 요청을 보낸다는 점이다. 이게 대체 무슨 말일까? 아래 그림을 보면서 이해해보자. 아래 그림은 위 그림에서 DNS 서버로 요청하는 부분을 좀 확대했다.

 

DNS 서버도 또 다른 DNS 서버로 질의(요청)한다

 

우리에게 IP 주소를 응답해준 DNS 서버도 또 다른 DNS 서버로 질의를 한다. 그것이 바로 전세계에 약 13대 밖에 없은 Root DNS이다. DNS 서버는 트리 구조의 도메인 네임 체계를 가지고 있다. 그래서 위처럼 트리 모양을 하고 있다. Root DNS는 [도메인 네임 → 호스트 네임] 순서를 갖는 계층적인 구조를 갖는데, 마치 깊이 우선 탐색(DFS)처럼 가장 하위 수준의 도메인(여기서는 naver)을 담당하는 DNS 서버들에 도달하면 해당 DNS 서버들에서 www 라는 호스트를 찾게 된다. 그리고 그 호스트의 IP 주소를 (위 그림의 까만색)DNS 서버에 응답해주고, 우리 PC 까지 전달되는 것이다. 

 

실제로 Root DNS 서버들이 어디있는지 보기 위해서는 iana 웹페이지에 들어가면 알 수 있다.

3. 웹의 역사적 발전과 핵심 기술

지금까지 L4 계층에서의 TCP 연결을 살펴보았다. 이제는 좀 더 고수준의 애플리케이션 관련 계층에서 알아둘 내용에 대해 알아보자. 그것은 바로 웹 기술이다. 여기서는 웹이 등장하기 시작한 시기부터 해서 역사적으로 웹의 기술이 어떻게 발전해왔는지, 그러면서 중간에 어떤 기술들이 등장했는지 시간 순서대로 살펴보도록 하자.

 

그 전에 앞서서 기본적인 개념들에 대해 알아보자.

3-1. 웹(WEB) = HTML + HTTP

HTML은 Hypertext 마크다운 언어이긴 하지만 어쨌건 결과적으로는 문서이다. 그리고 HTTP는 이 HTML 문서를 전달하기 위해 등장한 프로토콜(규칙)이다. 그리고 이러한 문서들을 주고받고 할 수 있는 인프라 환경이 TCP/IP 연결이다.

 

HTML 문서를 주고 받는다고 했다. HTML 문서도 어쨌건 원론적으로는 파일이다. 그리고 이러한 파일이 저장된 위치를 Resource Locator 라고 한다. 간단히 말해서 Resource = File 이라고 생각하면 된다. 이러한 개념에 입각해서 등장하는 개념들이 URL, URI 이다.

 

엄밀히 말하면 URI는 URL의 상위 개념이며 URI가 URL을 포괄한다.

 

URI가 URL을 포괄한다

 

URI, URL 형식은 아래와 같으니 참고하자. 아래 예시 중 PORT 번호에 대해서는 웹이 기본적으로 80 포트 번호이기 때문에 포트번호는 생략된다.

 

웹의 포트 번호는 기본적으로 80이다

3-2.웹의 발전을 따라가보자

이제 그러면 웹이 역사적으로 등장할 때부터의 기능에서 현대의 기능까지 발전해오는 과정을 살펴보도록 하자.

 

웹의 초창기

 

웹을 최초로 개발한 팀 버너스리는 단순히 웹을 여러가지 문서를 쉽게 볼 수 있는 뷰어의 목적으로 개발하였다. 그렇기 때문에 위 그림처럼 웹 초창기에는 단순히 웹서버에 요청을 하면 응답이 오는 것은 HTML 문서였다. 

 

시간이 지나면서 텍스트를 조금 더 이쁘게 보여주고 싶었다. 즉, 디자인을 좀 반영하고 싶었다. 그렇기에 등장한 것이 CSS이다. 웹 초창기 때와는 달리 이번엔 CSS 파일도 더 추가로 전달해주는 것으로 아래처럼 발전되었다.

 

이제는 CSS 파일도 전달하여 좀 더 이쁜 문서 뷰어를 완성

 

그런데 사람들은 욕심(?)이 여기서 그치지 않았다. 지금까지는 단순히 움직이지 않는 정적인 특성밖에 구현하지 못하는 문서뷰어였다. 사람들은 이리저리 움직이고 다이나믹한 애니메이션도 넣고 싶어서 동적인 특성을 반영한 문서 뷰어를 만들고 싶었다. 이를 구현하기 위해 2가지 사항이 추가되었다. 먼저 기존에 전달하고 있던 HTML 파일에 태그(tag)라는 요소를 추가해 HTML 구문을 분석하는 Parser를 추가하고 파싱된 문서 내용을 화면에 렌더링하는 기능이 추가되었다. 그리고 동적인 특성을 정의하는 규칙을 스크립트 형태로 정의하는 JavaScript 엔진이 추가되었다.

 

동적 특성을 반영할 수 있는 자바스크립트 엔진이 추가

 

그런데 위 단계까지는 한 가지 한계점이 있다. 바로 클라이언트가 웹서버에서 제공하는 내용을 직접적으로 수정하지는 못하는 상태이다. 예를 들어, 게시판 웹페이지가 있을 때 게시판에 가입한 유저마다 각자 작성한 글만 볼 수 있거나 유저가 비공개 글로 작성한 글들은 해당 유저에게만 보여져야 한다. 하지만 위 단계까지는 이러한 특성을 반영할 수 없다. 결국, 상태를 전이하고 관리할 수 있어야 한다. 

 

하지만 TCP/IP 연결을 기반으로 하는 HTTP 통신은 Stateless 즉, 상태가 없다. 고로 방금 이야기한 특성을 HTTP 통신만으로는 반영할 수 없다는 것이다. 그러면 이런 상태를 어떻게 관리할 수 있을까? 우선 클라이언트 단에서 상태는 쿠키라는 것을 이용해서 관리할 수 있다. 하지만 서버 단에서는 동시에 여러명의 클라이언트의 상태들을 관리해야 하기 때문에 2가지의 추가 서버를 이용해 관리를 한다.

 

첫 번째는 유저들의 상태 값들을 저장해놓고 꺼내올 수 있는 데이터베이스인 DB 서버이고, 두 번째는 WAS(Web Application Server)이다. DB 서버는 필요한 이유를 직관적으로 알 수 있는데, WAS는 왜 필요할까? 예를 들어, 유저의 마이 페이지를 보여주기 이전 화면인 로그인 페이지가 있다고 해보자. 클라이언트는 자신의 id 와 password를 입력할 것이다. 그러면 일단 WAS 서버는 클라이언트가 입력한 id 와 password가 DB에 있는지 조회해볼 것이다. 만약 존재하는 유저라면 그 유저에 맞게 마이페이지를 동적으로 구성해야 한다. 왜냐하면 (만약 구독 기능이 있는 웹페이지라면) 각 유저마다 보여져야 하는 정보들이 서로 달라질 것이기 때문이다. 즉, 이렇게 동적으로 처리하는 동작이 필요하게 그에 맞게 최종적으로 클라이언트에게 보여줄 뷰를 생성하는 것이 바로 WAS 서버의 역할이다. 

 

클라이언트와 서버의 상호작용이 가능해진 단계

 

좀 더 첨언하면 위 그림 기준으로 WAS 서버 입장에서는 왼쪽에서는 클라이언트가 눈으로 보고 입력하는 정보가 온다고 해서 View, 오른쪽으로는 DB와 같은 서버로부터 얻은 정보를 이용해 최종적으로 클라이언트에게 전달할 데이터를 생성한다고 해서 Model, WAS 자체에서 클라이언트가 입력한 정보들에 대한 검증, 기타 비즈니스 로직을 처리하는 Control 해서 MVC 패턴이라고 한다.

3-3. JVM과 Restful API

마지막으로, [목차 3-2]에서 살펴본 그림을 가지고 WAS에 속하는 JVM에 대해 알아보고, Restful API에 대해 이해해보자. 

 

먼저 위 그림에서 클라이언트와 서버 간의 상호작용이 가능해지도록 하기 위해 [클라이언트←→서버←→WAS←→DB] 단계로 구성된다는 것을 살펴보았다. 여기서 [WAS←→DB] 간의 RTT(Round Trip Time)을 모니터링하는 것이 중요하다. 왜냐하면 네트워크 속도가 아무리 빠르다고 한들 해당 단계에서 시간이 오래걸리면 아무 소용이 없기 때문이다. 이를 모니터링하는 것을 APM(Application Performance Monitoring)이라고 한다. APM은 아래의 단계를 모니터링 한다.

 

APM은 WAS와 DB 간의 통신을 모니터링 한다

 

APM은 그럼 정확히 어떤 부분을 모니터링 하는지 JVM을 예시로 들면서 살펴보도록 하자. 우선 JVM에 대해 알아둘 필요가 있다. JVM은 Java Virtual Machine으로 이전 OS 포스팅에서 배웠지만 'Vritual Machine' 이라는 키워드가 붙었다는 것은 CPU(Machine)을 소프트웨어로 구현(Virtual) 했다는 뜻이다. JVM에 대한 아래 그림을 보자.

 

JVM과 Servlet Container, 그리고 Spring

 

먼저 JVM은 하드웨어 CPU를 Java를 이용해서 소프트웨어로 구현한 것이다. 그리고 그 위에는 JVM이 이해할 수 있는 명령체계인 자바 바이트 코드가 존재한다. 그리고 그 위에 미들웨어라는 것이 등장하는데, 이 미들웨어가 WAS라고 생각하면 된다. 미들웨어의 역할은 다른 소프트웨어가 잘 동작하도록 지원해주는 소프트웨어인데 대표적으로 TCP/IP 연결, DB 연결, 파일 등 여러가지 것들을 쉽게 가져다 쓸 수 있도록 해준다. 그래서 미들웨어가 TCP/IP 연결과 같은 것들을 Servlet과 연동해주는 주체가 된다. 이 Servlet이 모여있는 Servlet 컨테이너가 존재하는데, 이를 쉽게 사용할 수 있도록 프레임워크화시킨 것이 우리가 흔히 아는 Spring 프레임워크가 된다. 

 

이제 다시 APM으로 돌아와서 APM은 위 그림에서 JVM과 자바 바이트 코드 부분을 모니터링한다.

 

APM이 모니터링하는 실질적인 부분

 

다음으로 알아볼 개념은 Restful API이다. 일단 다시 [클라이언트←→서버←→WAS←→DB] 간에 통신하는 단계를 다시 살펴보자.

 

 

그런데 요즘 현대에 들어와서 상황이 달라졌다. 상황이 달라진 부분은 클라이언트 쪽이다. 요즘 개인이 소유하는 OS가 탑재된 기기만 하더라도 윈도우 PC, Mac OS PC, 아이패드, 갤럭시 태블릿, 갤럭시 핸드폰, 아이폰, ... 이렇게 OS가 다양해지면서 클라이언트 환경이 다양화되었다. 이 말은 곧 서버 쪽에서 화면을 보여줄 때 클라이언트 환경이 무엇인지에 따라 각각 맞춰서 보여주어야 한다는 것이다. 다시 말해, UI와 데이터를 분리할 수 없다는 것이다.

 

하지만 이것까지 서버에게 위임하기에는 너무 까다롭다. 이러한 문제를 해결하기 위해서 UI와 데이터를 분리하기로 했다. 즉, 서버쪽에서는 단순히 데이터만 전달해주고, 클라이언트 환경에 맞는 UI를 생성하는 것은 각 환경에 맞는 클라이언트가 수행하는 것이다. 그래서 클라이언트 환경에 맞는 UI를 생성하는 과정은 클라이언트의 기기(PC, 핸드폰, 태블릿 등..)에 리액트, 뷰와 같은 프레임워크로 작성된 소스코드 파일들이 다운로드 된 후 실행되는 것이다.

 

클라이언트는 이제 요청에 따라 서버에게 다양한 동작을 수행시킬 수 있다. 클라이언트는 서버로부터 어떤 내용들을 읽어들이거나 생성하기, 업데이트, 삭제하는 동작 등을 수행할 수 있다. 이러한 동작의 종류를 CRUD(Create, Read, Update, Delete) 4가지로 간략하게 표현할 수 있다. 또한 예를 들어 Create 동작을 요청한다는 것은 곧 서버 내에 있는 특정 함수를 호출하는 것인데, 이것을 클라이언트 입장에서 호출하는 것이기 때문에 API(Application Programming Interface)라고 부르며, CRUD 동작을 클라이언트에서 호출할 수 있는 API를 Restful API라고 부르게 된다.

3-4. 웹서버에서의 보안 역할을 하는 것들

마지막으로 간략하게 웹서버 구조에서 보안 역할을 하는 것들에 대해 간략히 알아보자. 방금 살펴본 그림에서 인터넷을 거쳐 나온 뒤 웹서버에 도달하기 전에 3가지 요소들이 추가로 존재한다.

 

IPS, SSL, WAF

 

먼저 IPS는 침입 방지 시스템으로 1차 방어체계에 해당한다. 그런 다음 WAF는 2차방어체계로, 경우에 따라 웹서버와 WAS 서버 사이의 구간으로 이동할 수도 있다. 마지막으로 알아볼 것은 SSL이다. SSL은 웹 서버와 브라우저 사이에서 전송되는 데이터를 암호화해서 인터넷 연결을 보호하기 위한 기술이다. 인터넷을 거쳐가는 동안 전송되는 데이터를 암호화하지 않는다면 중간에 해커가 가로채서 데이터를 가져갈 수 있기 때문이다. 이를 막기 위해 데이터를 암호화 하여 통신한다. 이런 SSL이 적용된 HTTP 통신이 바로 HTTPS이다.

 

SSL을 거치기 전까지는 HTTPS 통신을 하고, SSL 이후에는 HTTP 통신을 하게 된다.

 

 

하지만 현대에 와서는 SSL보다는 더 빠르고 보안이 강화된 TLS를 자주 사용한다. SSL과 TLS에 대한 비교는 추후에 강의를 듣고 다뤄보겠다.