S2U4 [네트워크] 웹 애플리케이션 작동 원리 회고

[웹 애플리케이션]

🏓 웹 애플리케이션은 웹 브라우저를 통해 동적인 응답을 가능하게 하는 애플리케이션이다. 모바일 등 특정 기기에 설치해서 사용해서 사용하는 네이티브 애플리케이션에 비해 유지관리가 쉽고 설치나 다운로드가 필요없다. 하지만 비교적 속도가 느리고 보안적으로 노출되기 쉬운 환경에서 동작한다.

 

처음에는 네이티브라는 용어 조차 몰라서 앱개발자와 소통이 어려웠던 기억이 있다. (진짜 어떻게 일했을까...?) 암튼 서로 장단점을 보완하며 점점 발전해나가고 있으니 두 개념에 대한 이해가 필요할 것 같다고 생각한다. 하이브리드도 많이 만들어지고 있으니 네이티브와의 통신도 조금 더 공부해보고싶다. (이건 나중에)

 

---

[네트워크를 만드는 기술]

🏓 IP는 패킷 교환 네트워크(네트워크 계층)에서 정보를 주고받는 데 사용되는 프로토콜이다. 호스트 주소 지정, 패킷 분할 및 조립 등을 담당한다. 데이터 교환에 있어 컴퓨터를 식별하기 위해 갖는 고유 주소가 IP주소이다. 보통 이러한 주소는 사용하기 어렵기 때문에 DNS를 사용하여 도메인으로 변환해 사용한다. TCP는 전송 계층에서 사용되는 프로토콜로, 가상 회선 위에서 통신의 신뢰성을 보장한다.(3-way-handshake 방식)

TCP/IP는 IP 주소를 사용하여 데이터를 교환하고, 그 신뢰성 보장(흐름, 혼잡 제어)을 가능하게 해주는 일종의 프로토콜 세트이다.연결 지향적인 TCP와 달리 UDP는 비연결형이다. 데이터그램(연결 없는 통신, 기본 전송 단위) 방식으로, TCP와 달리 데이터 수신 여부를 확인하지 않는다. 그렇기 때문에 타겟까지 전송이 보장되지 않고 패킷 순서보장 또한 되지 않는다. 신뢰성은 낮지만 TCP보다 속도가 빨라 연속성 있는 전송이 필요할 때 사용하는 프로토콜이다. (ex 스트리밍)

PORT는 타겟 IP의 특정 애플리케이션을 지정한다. IP 주소만으로는 애플리케이션 특정이 불가능하기때문에, 이 포트 번호를 사용하여 구분한다. 자주 사용되는 포트로는 80(HTTP), HTTPS(443), SMTP(23), SSH(22) 등이 있다.

위에서 나온 DNS의 동작방식을 간단히 서술하자면, 리졸버가 네임 서버에 반복적으로 질의를 하면서 (재귀적으로) 도메인에 알맞는 IP주소를 알아낸다.(=DSN Lookup) 그 전에 도메인 정보가 담긴 캐시 파일을 찾아 즉시 주소를 리턴할 수 있지만, 그렇지 않으면 위 과정을 진행한다. 네임서버는 Root, TLD, 권한있는 네임서버로 이루어져있고 룩업 과정에서 root부터 차례로 접근하며 IP주소를 알아낸다.

 

정처기 공부할 때도 힘들었던 OSI 7계층, TCP/IP 4계층...ㅎㅎㅎ 공부할 때가 많이 생각났다. 처음에 공부하는 데 꽤나 애를 먹었고 지금까지도 확실하게 이해가 된 것은 아니다. 왜냐하면 이 과정은 너무도 추상적이기 때문에 쉽게 이해하기가 어렵기 때문이다ㅠㅠ 그래도 네트워크에서 데이터 전송에 대한 큰 흐름을 이해하고 간다는 건 정말 중요하기 때문에 이렇게라도 다시 상기할 수 있게 되어 다행이다. DNS는 그 개념과 사용에 대해서는 알고 있었는데 동작과정에 대해서는 잘 몰랐다. 일하는 데 그렇게 중요하겠냐 싶어도 기초지식을 알고 가는 건 좀 다른 문제이기 때문에, 이번 챕터가 굉장히 유용했고 어렵지만 개념을 다시 한 번 잡을 수 있어서 좋았다!

---

[웹을 구성하는 기술]

🏓 웹은 운영체제나 애플리케이션에 상관 없이 일정한 형식으로 보여주는 기술이다. 인터넷과 하이퍼텍스트 언어(대표 HTML)이 융합하여 탄생했다. 웹에서 제공되는 서비스는 주로 클라이언트- 서버 아키텍처로 이루어져있다. 리소스를 사용하는 클라이언트와 그 리소스를 제공하는 서버로 구성된다. 주로 이러한 아키텍처는 2티어, 리소스 저장공간 일명 데이터베이스 서버가 분리되어 있는 것을 보통 3티어 아키텍처라고 한다.

웹 애플리케이션을 구현하는 방식은 크게 세 가지가 있다. SPA, MSA, Severless. (이 중 SPA를 구현하기 위해 AJAX라는 기술을 사용한다. 일종의 웹 개발 기법으로, 웹 페이지에 필요한 부분만 비동기적으로 받아와 화면에 그릴 수 있다.) 웹 구현 기술은 HTTP, 쿠키 세션, 사용자 인증 등이 있다. 

웹 페이지 렌더링 방식은 SSR, CSR 두 가지가 있는데 SSR은 요청 받은 페이지를 완전히 렌더링해서 보내주는 것이라고 보면 된다. 그렇기 때문에 경로이동을 할 때마다 서버는 이 작업을 다시 수행한다. CSR은 거의 반대되는 개념이다. 골격이 되는 단일 페이지와 JS 파일을 보내주면 클라이언트 측에서 JS가 페이지를 렌더링한다. 그러므로 서버는 다시 페이지에 대한 렌더링을 진행할 필요 없이 데이터 요청에만 응답하면 된다. 다만 CRS는 서치엔진과 상성이 좋지 않기 때문에 잦은 페이지 요청이 필요하더라도 SSR을 사용하는 경우가 있다고 한다. (네이버 블로그, 뉴욕 타임즈 등)

CORS는 브라우저 보안 측면에서 중요한 역할이다. 한국어로 하면 교차 출처 자원 공유 인데, 다른 origin으로 요청을 보냈을 때 브라우저가 요청 및 응답 데이터가 CORS 정책을 지키는지 검사한다. '브라우저'의 정책이다. Simple request(안전한 요청)을 충족하기 위해서는 몇 가지 정책이 있는데 MDN에 잘 설명되어 있다. 그 조건을 만족하지 못하면 Preflight request라고 해서, 안전한 요청인지 확인하기 위한 사전 요청(OPTIONS 메서드)을 먼저 보내 검사를 한 후에 실제 요청을 전송하는 방식으로 작동한다. 프로토콜, 호스트(도메인), 포트번호가 다를 경우 origin이 다르다고 판단한다.

 

중요하다고 생각하지 않거나 아는 내용은 빼려고 노력했는데도 길어졌다!! 그만큼 내용이 굉장히 방대했던 챕터이다. 웹 개발자로서 꼭 알아야 하는 내용들이라서 앞으로도 주의깊게 살펴보려고 한다. 특히 CORS에 대해서는 잘 몰랐다. 교차 요청이라는 정도만 알고 있었다. 이전에 'CORS 에러인데요?'라는 말을 얼핏 들어본 적이 있었는데 그 때 좀 찾아볼 걸 그랬다😓 이번 기회를 통해서나마 MDN 문서를 읽으면서 한층 더 깊게 알 수 있어서 좋았다. SSC/CSR도 이번에 개념을 제대로 잡고 가는 것도 좋았다! 또 AJAX를 보면서는 동기와 비동기에 대해 다시 한 번 읽어보고 싶어졌다. 딱 몇 문장으로 둘의 차이를 설명할 수 있게 딱 정리해봐야겠다. MSA는... 스프링을 좀 끝내고/하면서 다시 공부해보려고 한다.

---

[HTTP messages]

🏓 HTTP는 응답/요청 메세지를 통해 데이터를 교환한다. 두 응답 메세지는 담고 있는 내용이 좀 다르지만 유사한 구조를 가지고 있다. 앞서 정리한 CORS도 주로 HTTP 메세지의 헤더를 통해 판단이 이루어진다. 요청 메세지는 HTTP 메서드, 대상, HTTP 버전으로 시작하고, 응답 메세지는 HTTP버전, 응답 코드, 텍스트로 시작한다. (외에도 header나 body 등에 차이가 있다!)

HTTP의 가장 주요한 특징은 'Stateless', 상태를 가지지 않는 것이다. 통신 과정에서 HTTP는 서버나 클라이언트의 상태를 확인하지 않는다. 실제로 서버가 죽었을 때도 응답코드를 내어줄 수 있다. 클라이언트에서 발생한 어떤 정보를 추적하며 저장하지도 않기 때문에, 특별히 상태를 저장해야하는 상황에는 쿠키나 세션을 통해 처리해줄 수 있다. 이는 나중에 더 자세히 학습하게 된다.

 

큰 어려움은 없었던 챕터이지만 여전히 모호한 부분은 많이 있다. 응답 메세지의 코드라던가 하는 부분은 자세히 기술하지 않았지만 많은 종류가 있다. 100,200번...대로 큰 흐름을 숙지해 두는 것은 중요한 것 같다. 사실 작업하다가 만나는 코드는 어느정도 한정되어 있지만 한 번 보는 것도 도움이 많이 될 것 같다. 예전에 헷갈렸던 부분은 HTTP 응답 메세지와 서버 응답메세지(로 구현했었다)가 따로였던 것이다. 지금와서 생각해보면 왜 그랬을까 싶지만 이런 HTTP에 대한 지식이 없었기 때문에 당연했던 것 같다. 

---

🖥️ Unit 4. 웹 애플리케이션 작동 원리를 마치고!

챕터는 얼마 안 되지만 챕터 별로 다루는 내용이 많아 작성이 꽤 걸렸다!! CS를 공부하고 싶어서 정보처리기사를 냉큼 도전해버린 것도 있는데 아무래도 시험날짜가 정해져있다보니 마음이 조급해서 개념을 잡고가는 것보다 암기식으로 공부했던 부분이 더 많았다. 물론 시험은 아주 기초적인 부분이라고 하지만, 그리고 이번 학습에서 다루는 내용이 전부는 아니지만 웹 애플리케이션에 대해 한 번 짚고 갈 수 있어서 또 통신에서 중요한 내용이라서 좋았다.(🙂정말 한참 멀었지만...) 정리해두면 좋을 것 같은 주제들이 정말 많이 있는데 이번 주말을 잘 활용하지 못한 것 같아 많이 아쉽다. 그래도 이어지는 유닛에서 HTTP를 더 깊이 다루고 있으니 다음 회고 작성과 함께 복습을 열심히 할 수 있지 않을까 싶다. 재미있다 재미있어 웹 애플리케이션 작동 원리 회고 끝.