본문 바로가기

공부일지/CS공부

비전공자의 CS공부 - Web, 패스트캠퍼스

728x90
반응형
반응형
728x90

 CS공부 - Web

 

오늘은 웹브라우저의 동작방식에 대해 공부를 해보려고 한다.

 

우리가 웹사이트 접속할 때는 웹 브라우저 프로그램을 사용하고 웹브라우저는 다음과 같은 기능을 수행한다.

 

  • 웹 페이지를 서버에 요청(request) 하여 서버의 응답(response)을 웹 문서 형태로 받는다.
  • 받은 웹문서(HTML, CSS, JS 등)를 렌더링 하여 모니터 화면에 웹페이지를 표시한다.
  • 대표적인 브라우저 프로그램은 Chrome, Firefox, Safari 가 있습니다.

브라우저가 서버(Server)에서 서비스를 요청하고 사용자(Client)에게 출력을 해준다.

 

내가 생각하는 Server와 Client는 식당과 같다고 생각이 된다.

손님이 음식을 주문하고 요리사가 음식을 만들고 손님에게 전달을 해주는 그 과정에서 서빙을 해주는 직원도 있을 것이고 재료를 제공하는 업체도 있을 거었다. 

우리가 서버에 요청을 보내는 것도 서버에게 클라이언트 요청사항을 전달해 주는 라우트도 있고 서버에서 해당 데이터가 있는지 DB에 검색도 해야 되는 것의 결은 비슷하다는 느낌을 받았다.

 

우리가 서버와 클라이언트를 쉽게 접할 수 있는 방법이 대표적으로 웹사이트이다.

웹사이트는 HTML(Hyper Text Markup Language)인데 브라우저가 요청받은 HTML이라는 문서 읽고 그 문서를 클라이언트에게 출력해 준다.

HTML의 기본구조 화면

위의 이미지는 HTML기본 구조로써 HTML을 작성하기 위해서는 html이라는 태그로 감싸 주어야 한다.

  • HTML : HTML문서라는 것을 정의하기 위한 태그
  • Head : 메타태그, 제목, 뷰포트, CSS, JS 등을 정의하는 영역
  • Body : 실제로 클라이언트 화면에 출력되는 내용의 영역

그럼 클라이언트에서 어떤 방식으로 요청을 하고 그걸 판단하고 출력을 해주는지 알아보자면 HTTP(Hyper Text Transfer Protocol)이라는 Hypertext를 전송하기 위해 개발된 프로콜을 간편하게 데이터를 전송해준다.

우리가 서버를 구축을 하게 되면 기본적으로 서버의 주소는 아이피로 설정이 된다.

우리가 흔히 보는 네이버, 구글, 다음 등의 주소는 도메인을 구매한 후 서버에 적용을 시켜야지만 우리가 흔히 사이트 접속 하기 위해 주소를 입력하는 방식으로 접속이 가능해진다.

 

도메인은 예를 들면 naver.com에서 .com이 도메인이다. .com 앞에는 자기가 원하는 문자나 숫자 조합을 사용해서 네이밍을 정하면 된다.

 

하지만 예를 들어서 naver.com 이 우리가 아는 Naver의 주소이다. 그런데 만약 naver.io를 붙이면 어떻게 될까? 실제로 접속해보진 못했지만 네이버가 해당 도메인을 구매하지 않고 다른 업체에서 해당 도메인을 구매했다고 한다면 네이버가 아닌 다른 사이트로 접속이 될 것이다.

이런 개념은 쉽게 말해서 우리가 아파트에 살고 있는데 아파트의 이름은 동일하지만 동이 나 호수가 다름으로 개인의 집을 판별하는 것처럼 도메인도 . 앞의 문자를 아파를 이름이고 .부터 시작하는 것이 동 이나 호수라고 생각하면 조금이라도 이해하기 쉬울 것 같다.

 

참고로 웹에서는 이걸 URL(Uniform Resource Locator)이라고 한다.

 

그럼 웹브라우저의 구조를 한번 살펴보자

  1. User Interface : 웹 브라우저의 화면(주소창, 새로고침, 설정 등의 기능이 있는 화면)
  2. Browser Engine, Data Storage : UI와 Rendering Engine의 매개체 역할 수행 및 쿠키와 로컬 데이터를 저장소에 저장
  3. Rendering Engine : 웹 서버로부터 받은 응답을 화면에 표현, Html, Css와 같은 코드를 실질적으로 처리하는 부분
  4. Networking : 웹 서버와 통신, JS Engine : JS 코드 파싱/실행, UI Backend : 사이트 UI 구동 역할

 

잠시 Data Storage에 대해 알아볼게요.

 

Cookie

  • 클라이언트(브라우저)에 저장되는 키와 값이 들어있는 데이터 파일
  • 인증 유효 기간을 명시할 수 있으며, 유효 시간을 설정하면 브라우저를 종료해도 해당 시간만큼 데이터가 유지됨
  • 클라이언트에 300개까지 저장이 가능하며 도메인당 20개의 값만 가질 수 있음
  • 쿠키당 4KB까지 저장 가능
  • 서버가 아니라 클라이언트에서도 쿠키를 만들 수 있음
  • 쿠키는 사용자가 요청하지 않아도 브라우저가 Request 하면 Request Header를 넣어서 자동으로 서버에 전송
  • 브라우저에서 아이디 비밀번호를 저장할 때 많이 사용 

 

Session

  • 세션은 쿠키를 기반으로 하고 있지만, 쿠키와 달리 서버에서 관리
  • 서버에서는 클라이언트를 구분하기 위해 세션 ID를 부여하며 웹 브라우저가 종료할 때까지 인증을 유지
  • 시간제한을 적용해서 일정 시간 응답이 없다면 정보를 유지하지 않게 할 수 있음
  • 정보를 서버에 저장해서 쿠키보다 보안에 좋지만 사용자가 많아지면 서버 메모리 사용량이 많아집니다.
  • 세션 ID를 탈취당하면 많은 정보를 해킹당한다.
  • 웹사이트의 자동로그인 기능에서 많이 사용한다.

 

그럼 이어서 HTTP에 대해서 조금만 더 알아볼게요.

  • HTTP란, 웹상에서 데이터를 주고받기 위한 프로토콜이다.
  • 웹 문서를 주고받기 위하여 사용할 수 있다.
  • 웹뿐만 아니라 모바일 앱, 게임 개발에서도 다양한 목적으로 사용되곤 한다.

HTTP는 Method를 요청해 데이터를 주고받는다. 대표적인 4가지 방식이 있다.

  • GET : 데이터를 조회 요청, 사용예시) 특정 페이지 접속, 정보 검색
  • POST : 데이터를 생성 요청, 사용예시) 회원가입, 글 쓰기
  • PUT : 데이터를 수정 요청, 사용예시) 회원 정보 수정, 글 수정
  • DELETE : 데이터를 삭제 요청, 사용예시) 회원정보 삭제, 글 삭제

HTTP의 응답유형

  • 200 : 정상적인 요청
  • 400 : 잘못된 요청 (Bad request)
  • 404 : 리소스를 찾을 수 없음 (Resource not found)
  • 500 : 서버가 처리 방법을 모르는 상황

그 외 다양한 응답유형이 있는데 아래의 링크로 가셔서 확인 하시면 됩니다

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

 

HTTP 상태 코드 - HTTP | MDN

HTTP 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려줍니다. 응답은 5개의 그룹으로 나누어집니다: 정보를 제공하는 응답, 성공적인 응답, 리다이렉트, 클라이언트 에러, 그리고

developer.mozilla.org

 

아래의 이미지는 개발자도구에서 네트워크항목에서 얻을 수 있는 정보이며 그외 다양한 정보들을 볼 수 있습니다.

요청 방식와 코드

네트워크항목에는 위의 기능 말고도 다양한 정보를 제공함으로 한 번쯤 확인해 보시는 걸 추천드려요.

 

 

HTTP의 자세한 정보를 확인하시려면 아래의 주소로 가시면 읽으실 수 있습니다.

https://aws.amazon.com/ko/compare/the-difference-between-https-and-http/

 

HTTP와 HTTPS - 전송 프로토콜 비교 - AWS

1996~1997년에 출시된 최초의 HTTP 버전이 HTTP/1.1입니다. HTTP/2와 HTTP/3은 프로토콜 자체를 업그레이드한 버전입니다. 데이터 전송 시스템을 수정하면서 효율성을 개선했습니다. 예를 들어, HTTP/2는 텍

aws.amazon.com

 

위에서 HTTP의 Method들을 알게 되었으니 어떻게 사용하지 알아볼게요.

서버에서 Method을 사용하기 위한 REST(Representational State Transfer) API를 알아볼게요.

 

  • URI(Uniform Resource Identifier)를 통해 자원(resource)을 명시한다.
  • HTTP Method(Post, Get, Put, Delete)를 통해 해당 자원에 대한 CRUD(Create, Read, Update, Delete) operation을 적용한다.
  • REST 구성요소는 : 자원(Resource) - URI,  행위(Verb) - HTTP Method, 표현(Representations) - 페이로드(payload)

예제를 한번 볼게요.

자원 회원(User)
행위 회원등록
표현 아이디 : "test", 비밀번호 : "1234"

위의 데이터로 서버에 요청으로 보낸다고 하면

 

코드는 아래와 같은 코드가 된다.

URI : https://www.example.com/users
HTTP Method: POST
Payload : {"id" : "text", "password":"1234"}

 

그럼 여기서 REST API가 뭔지 간단히 알아보자면

  • API(Applicaion Programming Interface) : 서로 다른 프로그램이 상호작용하기 위한 인터페이스
  • REST API : REST 아키텍처를 따르는 API
  • REST API 호출 : REST 방식을 따르고 있는 서버에 특정한 요청(request)을 전송하는 행위

위에서 말한 서버와 데이터 통신이 식당과 비슷하다고 했는데 API도 비슷하다 내가 해당 메뉴를 점원에게 요청하고 요리사가 요리를 하고 점원이 다시 음식을 가져다주는 방식이 API의 데이터 통신 방식과 동일하다고 보면 된다.

 

REST API를 연습해 보거나 테스트하기 위해선 mocking이라는 것을 한다.

  • 목킹(mocking)은 어떠한 기능이 있는 것처럼 흉내 내어 구현하는 것을 의미한다.
  • 클라이언트 개발을 위해 간단히 서버 기능을 테스트할 때 사용한다.
  • 처음부터 모든 서버 기능을 개발하고, 클라이언트 개발을 시작하면 개발 일정에 지연이 생길 수 있다.

REST API 목킹 서비스 예시 사이트가 있는데 한번 참고해서 결과물을 만들어 보는 것도 좋을 거 같다.

https://jsonplaceholder.typicode.com/

 

JSONPlaceholder - Free Fake REST API

{JSON} Placeholder Free fake API for testing and prototyping. Powered by JSON Server + LowDB. Tested with XV. Serving ~2 billion requests each month.

jsonplaceholder.typicode.com

 

오늘은 간단히 Web의 통신 방식에 대한 공부를 해보았는데 공부라는 게 배우면 배울수록 끝이 없는 거 같네요.

오늘도 미션 완료~~ 그럼 또 봐요 ㅃㅇ

728x90
반응형