BEB Section 2 - HTTP/네트워크 기초

Section 2로 접어들었다. 그래도 많이 본 용어들이고 공부했던 개념들이라 괜찮겠지 했는데 나날이 갈수록 어려워질 것 같아서 그만

 

진짜 어이가 없긴 했어요.

그래요, 그래도 할 건 해야겠죠..

 

 

Client and Server

클라이언트-서버 구조라고 많이 불렸고, 들어봤을 내용일 것이다. 아키텍쳐를 보통 그릴 때 이렇게 그린다.

 

2-Tier Architecture of Client-Server

 

 클라이언트에서 요청(request)하게 되면 서버에서는 응답(response)을 하게 된다. 우리는 이걸 2티어 아키텍쳐로 부르기로 했다.

 

 

+ with Database

3-Tier Architecture including Database

 

 흔히 프로젝트를 하면서 제일 많이 보는 아키텍쳐이다. 클라이언트를 통해 서버로 요청하고, 서버는 클라이언트의 요청을 응답해주기 위해 데이터베이스로 요청하게 된다. 데이터베이스에서 서버가 요청한 데이터를 찾게되면 응답하고, 그렇게 서버는 데이터베이스로 통해 받은 정보를 클라이언트에 응답하게 된다. 우리는 이걸 3티어 아키텍쳐라고 부르기로 했다.

 

 클라이언트는 사용자가 눈으로 확인할 수 있는 서비스를 제공하는 어플이기 때문에 프론트앤드, 서버와 데이터베이스는 사용자가 눈으로 확인하지 못하고, 개발자가 사용자를 위한 서비스를 제공하기 때문에 백앤드라고 부른다.

 

 

프로토콜(Protocol)

 여전히 어려운 용어, 프로토콜이다. 프로토콜은 통신 규약을 의미한다. 클라이언트에서 서버에게 요청할 때 제대로 된 통신 규약을 지키지 않으면 서버에서는 받아들이기 힘들다. 웹 어플리케이션 아키텍쳐에서는 클라이언트와 서버는 HTTP 프로토콜을 이용하여 통신한다. 아래 코드블럭이 그에 대한 예시이다.

 

GET /nameAboutCho HTTP/1.1 Host: cliffclimber.tistory.com // REQUEST

HTTP/1.1 200 OK { "name" : "cho-won-young" }

 

 네트워크를 배우게 되면 주요 프로토콜을 배우게 되는데 이걸 7계층으로 나눈다. 

 

Application Layer

 위 표는 응용 계층에서 나타내는 프로토콜을 나타낸 것이다.

Transport Layer

 위 표는 전송 계층에서 나타내는 프로토콜을 나타낸 것이다.

 

 

API(Application Programming Interface)

 여기서 말하는 interface는 의사소통이 가능하도록 만들어진 접점이다. 클라이언트에서 활용하기 위해서는 API 문서를 작성해야하고, 서버는 리소스를 전달해줘야 한다. HTTP 프로토콜을 사용하여 주소(URL, URI)를 통해 접근할 수 있어야한다. Section 1에서 잠깐 언급했던 CRUD 메소드에 따라 목적에 맞게 써야한다.

 

 

URL & URI

 scheme, hosts, url-path, query.. 예전에 Wireshark로 패킷 분석을 하면서 많이 봤던 용어들이었는데 이제서야 그 뜻들을 알게 되었다.

Information about URL

 

 URL은 네트워크 상에서 웹 페이지, 이미지, 동영상 등 파일이 위치되어있는 정보를 나타낸다. scheme, hosts, url-path로 구분 가능한데, scheme은 통신 프로토콜을 나타낸다. hosts는 웹 서버의 이름이나 도메인, IP 주소를 나타낸다. url-path는 웹 서버에서 지정한 루트 디렉토리로 부터 시작해서 위치 경로와 파일명을 나타낸다.

 

Information about URI

 

 URI는 URL의 기본 요소를 더해 query와 bookmark를 포함한다. query는 웹 서버에 보내는 추가적 질문이다. 보라색 글씨를 보면 물음표 뒤에 Javascript가 보이는데 이 뜻은 Javascript에 대해 검색했다는 것을 알려준다.

 

 

IP and Port Address

• IP(Internet Protocol)

 인터넷 상에서 사용하는 주소 체계를 말한다. 흔히 우리가 아는 127.0.0.1, 192.168.0.x 가 IP 주소를 뜻한다. 0에서 255까지 숫자를 사용하고, 이렇게 된 IP는 IPv4로 IP 주소의 4번째 버전을 말한다. 그리고 2001:db8::ff00:42:8329 로 되어있는 IP 주소는 IPv6로 IP 주소의 6번째 버전을 말한다. macOS에서는 시스템 환경설정 - 네트워크로 들어가면 지금 접속되어있는 와이파이를 통해 IPv4를 확인할 수 있다.

너무 작죠? 그냥 이런 식으로 나온다고요..

• Port

127.0.0.1:3000

 

 볼드체로 되어있는 저 3000은 포트 번호를 의미한다. 포트 번호는 0에서 65535 까지 사용 가능한데, 0번부터 1024번까지는 주요 통신 규약으로 인해 사용 불가하다. 그래도 그 중에 제일 유명한 건 

 

 22 : SSH

 80 : HTTP

 443: HTTPS

 

 이렇게 있다.

 

 

DNS

 DNS는 도메인 이름(naver.com 이런 걸 의미한다.)을 IP 주소로 변환하거나 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템이다. 쉽게 말하면 서로 클라이언트와 서버가 통신할 수 있도록 할 수 있는 것이다.

 

 

에러 메세지를 읽어보자!

 크롬을 열어보면 정말 다양한 에러 메세지를 읽어볼 수 있다. 아래 사진이 그에 대한 에러 메세지이다.

 

에러 메세지 뭐가 이래 많습니다.

 

HTTP Messages 

 HTTP Message는 클라이언트-서버 사이 데이터가 교환되는 방식이다. 앞서 2티어 아키텍쳐에서 설명했던 요청(request)과 응답(response)이 이 유형에 포함된다.

 

출처 : 코드스테이츠 urclass

 

 그림을 기준으로 설명하면

1. start line : request나 response의 상태를 나타낸다. response에선 status line 이라고 부른다.
2. HTTP headers : request을 지정하거나, 전체 헤더의 집합을 의미한다.
3. empty line : 구분하기 위해 빈 줄을 넣는다.
4. body : request 또는 response와 관련된 데이터나 문서를 포함한다. 유형에 따라 선택적으로 사용한다. 흔히 말하는 payload 가 여기에 해당된다.

 

 

• Requests

 수행할 작업이나 방식을 설명하는 메소드이다. 위 그림을 보면 POST 라고 적혀있는데 이건 무조건 요청해야하는 부분에 포함된다. 요청 대상 또는 프로토콜, 포트, 도메인의 절대 경로로 컨텍스트에 작성한다. 4가지 형식이 있다.

 

• origin 형식 : ?와 함께 붙어서 나오는 경로를 의미한다. GET, POST, HEAD, OPTIONS 등이 사용된다.
  • POST / HTTP 1.1
  • GET / picture.png HTTP/1.0
• absolute 형식 : 완전한 URL 형식으로 GET과 함께 사용된다.
  • GET https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
• authority 형식 : 도메인 이름과 포트번호로 이뤄진 URL을 의미한다. CONNECT 와 함께 사용된다.
  • CONNECT developer.mozilla.org:80 HTTP/1.1
• asterisk 형식 : OPTIONS 와 함께 * 로 서버 전체를 표현한다.
  • OPTIONS * HTTP/1.1

 

  ▶ Request : Headers

 대소문자 구분 없이 문자열과 콜론(:), 그리고 값을 입력한다. 값은 헤더에 따라 다르고 종류가 여러 개 있다.

• General headers : 메세지 전체 적용
• Request headers : User-Agent, Accept-Type, Accept-Language를 헤더에 넣어 요청 구체화
• Entity headers : Content-length가 body에 적용되고, 비어있으면 이 헤더는 보내지 않음

 

  ▶ Request : Body

 메세지 구조의 마지막에 위치한다. 모든 요청에 필요하지도 않고, 서버에 리소스를 요청하는 경우에도 필요하지 않다. POST나 PUT과 같은 일부 요청은 데이터 업데이트를 위해 사용한다. 두 종류가 존재한다.

• Single-resource bodies : 헤더 두 개(Content-type, Content-length)로 정의된 단일 파일 구성
• Multiple-resource bodies : 여러 파트로 구성된 본문에서 각 파트마다 다른 정보를 지닌다.

 

Request headers 출처 : 코드스테이츠

 

• Responses

  ▶ Response : Status Line 

응답의 첫 줄은 Status line 으로 표시하고, 다음과 같은 정보를 제공한다.

 

1. 현재 프로토콜의 버전
2. 상태 코드 (200, 300, 404, 500 등)
3. 상태 텍스트 - 상태 코드 설명

 

  ▶ Response : Headers

응답에 들어가는 요청 헤더와 동일한 구조이다. 그 대신 입력된 정보들이 조금 다르다.

• General headers : 메세지 전체 적용
• Request headers : Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보 제공
• Entity headers : Content-length가 body에 적용되고, 비어있으면 이 헤더는 보내지 않음

 

  ▶ Response : Body

 메세지 구조의 마지막에 위치한다. 모든 응답에 필요하지 않으며, 두 종류가 존재한다.

• Single-resource bodies :
  • 길이가 알려진 헤더 두 개(Content-type, Content-length)로 정의
  • 길이가 모르는 단일 파일은 chunked로 설정되어있고, 파일은 chunk으로 나뉘어 인코딩 되어있다.
• Multiple-resource bodies : 서로 다른 정보를 담고 있다.

 

  ▶ Response : Stateless

 상태를 가지지 않는다는 뜻이다. 통신을 주고받는 과정에서 HTTP가 클라이언트 혹은 서버의 상태를 확인하지 않는다. HTTP의 큰 특징이기도 하다.

 

 

What is AJAX?

 AJAX는 Javascript, DOM, Fetch, XMLHttpRequest, HTML 등 다양한 기술을 사용하는 웹 개발 기법이다. 가장 큰 특징은 웹 페이지의 필요한 부분에 대해 필요한 데이터만 비동기적으로 받아와 화면에 보이게 할 수 있다는 것이다. HTML에 의해 사용자에게 필요한 페이지가 렌더링되고, 요구에 따라 반응하고 변화하는 부분이 있다.

 

 AJAX를 구성하는 핵심 기술은 Javascript, DOM, Fetch, 이렇게 3가지가 있다. 앞서 비동기에서 설명했단 fetch를 통해 페이지 이동 없이 서버로부터 필요한 데이터를 받아올 수 있고, 현재 페이지에서 작업하는 동안에도 서버와 통신할 수 있도록 한다.

 

 

 이러한 AJAX에는 장단점이 존재한다.

• 장점
  • 서버에서 HTML을 완성하여 보내주지 않아도 웹 페이지 만들기 가능
  • 어느 브라우저 상관없이 사용 가능
  • 필요한 부분만 렌더링하기 때문에 빠르고 많은 상호작용이 가능한 어플리케이션 개발 가능
  • 더 작은 대역폭
• 단점
  • SEO에 불리
  • 뒤로가기 버튼 문제 : 이전 상태를 기억하지 않는다! 상태를 기억하게 하려면 별도로 History API 사용

 

SSR ? CSR ?

• SSR은 브라우저에서 렌더링하는 대신에, 서버에서 렌더링한다.

 브라우저가 서버로 GET 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 전송한다. 그리고 서버의 웹 페이지가 브라우저에 도착하면 완전히 렌더링된다. 서버에서 웹 페이지를 브라우저로 보내기 전에 서버에서 완전한 렌더링을 했기 때문에 SSR 이라고 불린다. 브라우저가 다른 경로로 이동할 때마다 서버는 작업을 다시 수행해야한다. 

 

• CSR은 SSR의 반대로 여겨지며, 클라이언트에서 렌더링한다.

브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 단일 페이지를 클라이언트로 보낸다. 이때 서버는 웹 페이지와 함께 Javascript 파일을 보낸다. 클라이언트가 받으면, 같이 받은 Javascript 파일은 브라우저에서 웹 페에지를 완전히 렌더링 된 페이지로 바꾼다. SSR과 다르게 서버가 다시 웹 페이지를 보내지 않으며, 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링한다.