[CS] HTTP/네트워크 기초 Day-37

Client Server Architecture

인터넷 연결이 없다면, 앱은 정상적으로 동작할 수 없습니다.
그 이유는 정보를 인터넷 어딘가에 존재하는 서버로부터 받아오기 때문입니다.

특정 서버에 접속하려 할 때 사용이 불가능한 경우 "서버가 죽었다"라고 표현합니다.

앱과 연결된 서버가 존재하지 않을 경우, 정보를 실시간으로 전달하기가 매우 어렵습니다.

클라이언트와 서버는 요청과 응답을 주고 받는 관계이며, 요청하지 않았는데, 응답이 오는 경우는 없습니다.

(일반적으로 서버는 리소스를 전달해주는 역할만 담당하고 리소스를 저장하는 공간을 데이터베이스(DB)라고 부릅니다.)

클라이언트-서버 통신과 API

클라이언트와 서버 간의 통신은 요청과 응답으로 구성됩니다. 요청이 있어야만 응답이 옵니다.

(서버 마음대로 리소스를 전달하지 않습니다.)

클라이언트 서버 통신을 이해하기 위해서는 프로토콜에 대한 이해가 필수적입니다.

프로토콜

통신 규약, 약속을 뜻합니다.
HTTP라는 프로토콜을 이용해서 서로 대화를 나눕니다. HTTP를 이용해 주고 받는 메시지를 HTTP 메시지라고 부릅니다.

API

서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공해줘야 합니다. 이것이 API입니다.

서버가 리소스를 전달하기 위한 API를 구축해놓아야 클라이언트가 이를 활용할 수 있습니다. 보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근합니다.

HTTP 요청에는 메소드라는 것이 존재합니다. GET, POST, PUT, DELETE 등 다양한 메소드가 존재합니다.

HTTP 메소드는 CRUD 행동에 따라 목적에 맞게 사용해야 합니다.

• Read(조회): GET
• Create(추가): POST
• Update(갱신): PUT 또는 PATCH
• DELETE(삭제): DELETE

행동에 맞게 적절하게 사용해야 합니다. 조회를 했을 때 삭제가 된다면 좋은 API디자인이라고 할 수 없습니다.

URL과 URI

• scheme: 통신 프로토콜 (file://, http://, https://)
• hosts: 웹 페이지, 이미지, 동영상 등의 파일이 위치한 웹 서버, 도메인 또는 IP (127.0.0.1, www.kakao.gg)
• port: 웹 서버에 접속하기 위한 통로 (:80, :443, :3000:)
• url-path: 웹 서버의 루트 디렉토리로부터 웹 페이지, 이미지, 동영상 등의 파일이 위치까지의 경로(/search, /Users/username/Desktop)
• query: 웹 서버에 전달하는 추가 질문 (q=JavaScript)

IP와 포트

IP는 인터넷상에서 사용하는 주소체계를 의미합니다. 인터넷에 연결된 모든 PC는 IP 주소체계를 따라 네 덩이의 숫자로 구분됩니다. 이를 IPv4라고 합니다. (version 4를 뜻하는 v4)

현재는 IPv6까지 출시됐습니다.

PORT

0~1024까지의 포트는 주요 통신을 위한 규약에 따라 정해져있습니다.

• 22: SSH
• 80: HTTP
• 443: HTTPS

이미 정해진 포트도 필요에 따라 사용할 수 있지만 약속된 포트 번호를 사용하는 것을 권장하지 않습니다.

도메인과 DNS

한눈에 파악하기 힘든 IP 주소를 대신해 사용하는 것이 도메인입니다.

DNS

Domain Name System의 줄임말로, 도메인 이름을 IP 주소로 변환하거나 그 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템입니다.

HTTP Messages

HyperText Transfer Protocol의 줄임말로, HTML과 같은 문서를 전송하기 위한 프로토콜입니다. 웹 브라우저와 웹 서버의 소통을 위해 디자인됐습니다.

클라이언트-서버 모델에서 클라이언트가 HTTP Messages 양식에 맞춰 요청을 보내면, 서버도 HTTP Messages 양식에 맞춰 응답합니다.

HTTP Messages

• 요청(Requests)
• 응답(Response)
  HTTP Message는 두 가지 유형이 있습니다.
  개발자는 메시지를 직접 작성할 필요가 거의 없습니다.

요청과 응답은 유사한 구조를 가집니다.

• start line: 요청이나 응답 상태를 나타냅니다. 항상 첫 줄에 위치합니다. 응답에서는 status line이라고 부릅니다.
• HTTP headers: 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합입니다.
• empty line: 헤더와 본문을 구분하는 빈 줄
• body: 요청과 관련된 데이터나 응답과 관련된 데이터 또는 문서를 포함합니다.

요청!(Requests)

HTTP 요청은 클라이언트가 서버에 보내는 메시지입니다.

• 수행할 작업(GET, PUT, POST 등) 방식(HEAD or OPTIONS)를 설명하는 HTTP method를 나타냅니다. GET method는 리소스를 받아와야 하고, POST method는 데이터를 서버로 전송합니다.

• 요청 대상 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됩니다. 이 요청 형식은 HTTP method 마다 다릅니다.

Headers

요청의 Headers는 기본 구조를 따릅니다. 헤더 이름, 콜론(:), 값을 입력합니다. 값은 헤더에 따라 다릅니다. 여러 종류의 헤더가 존재합니다.

• General headers: 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.

• Request headers: fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미합니다. User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화합니다.

• Representation headers: body에 담긴 리소스의 정보를 포함하는 헤더입니다.

GET/home.html/HTTP/1.1
POST/index.html/HTTP/1.1
DELETE/query.html/HTTP/1.1

Body

요청의 본문은 HTTP messages 구조 마지막에 위치합니다. 모든 요청에 body가 필요하지는 않습니다. GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않습니다.

POST, PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용됩니다.

• Single-resource bodies(단일-리소스 본문): 헤더 두 개로 정의된 단일 파일로 구성됩니다.
• Multiple-resource bodies(다중-리소스 본문): 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다.

응답!(Responses)

status line

응답의 첫 줄은 Status Line이라고 부르며

• 프로토콜의 버전
• 상태 코드 (200, 302, 404 등)
• 상태 텍스트 (상태에 대한 설명)
  이 포함되어 있습니다.

Headers

응답에 들어가는 HTTP Headers는 요청 헤더와 동일한 구조를 지닙니다. 대소문자 구분 없는 문자열과 콜론(:), 값을 입력합니다. 요청의 헤더와 마찬가지로 몇 그룹으로 나뉩니다.

• General headers: 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더
• Response headers: 위치 또는 서버 자체에 대한 정보와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, 추가 정보를 제공합니다.
• Representation headers: body에 담긴 리소스의 정보를 포함하는 헤더입니다.

Body

응답의 본문은 HTTP messages 구조 마지막에 위치합니다. 모든 응답이 body가 필요하지는 않습니다.

• Single-resource bodies(단일-리소스 본문)
• Multiple-resource bodies(다중-리소스 본문)