layout: post
title: "웹을 지탱하는 기술 스터디 - Chapter6"
date: 2022-03-26T00:00:00-00:00
author: sangyeop
categories: Sproutt-2nd
새싹 개발 서적 스터디 - 웹을 지탱하는 기술 Chapter06
Chapter 06. HTTP의 기본
HTTP는 TCP/IP를 베이스로 한 프로토콜이다.
HTTP의 중요성
현재의 웹은 HTTP 1.1이 가장 많이 사용되고 있다. HTTP는 HTML, XML 같은 하이퍼텍스트뿐 아니라, 이미지, 음성, 동영상 등등 모든 데이터를 전달할 수 있다.
HTTP REST의 특징인 Uniform 인터페이스, 무상태 서버, 캐시 등을 구현하고 있는 Web의 기본이 되는 프로토콜이다.
TCP/IP란 무엇일까
계층형 프로토콜
인터넷 프로콜은 계층 구조를 가지고 있는데, 각 계층별로 추상화하여 구현하면 물리적인 하위 계층의 구체적 사항에 좌우되지 않고 상위 계층을 구현할 수 있다.
네트워크 인터페이스 계층(이더넷)
가장 아래의 계층으로 물리적인 케이블이나 네트워크 어댑터에 해당하는 부분이다.
인터넷 계층(IP)
네트워크 인터페이스 계층 위에 존재한다. 네트워크에서 실제로 패킷 단위로 데이터를 주고 받는 부분이고, TCP/IP에서 IP에 해당하는 부분이다.
트랜스포트 계층(UDP, TCP)
인터넷 계층 위에 존재한다. IP가 하지 않았던 데이터의 무결성을 보증하는 역할을 한다. TCP는 사용자의 데이터의 누락을 체크하고, 데이터의 도달을 보장한다.
여기서 데이터가 어느 애플리케이션 전달될지 결정하는 것이 포트번호이다.
애플리케이션 계층(HTTP, NTP, SSH, SMTP, DNS)
트랜스포트 계층 위에 존재한다. TCP로 프로그램을 만들 때는 소켓을 사용한다.
소켓 : 네트워크에서 데이터 교환을 추상화한 API로 접속, 송신, 수신, 전달 등의 기본적인 기능을 갖추고 있다.
HTTP의 버전
HTTP 0.9 - HTTP의 탄생
현재 HTTP와는 다르게 헤더가 없었으며, HTTP 메서드는 GET뿐이었다. 현재는 거의 사용되지 않는다.
HTTP 1.0 - HTTP 최초의 표준화
IETF에서 표준화가 이루어진 최초의 버전이다. 헤더가 도웁되었고 GET이외의 메서드가 추가되어, 현재의 HTTP 1.1로 이어지는 기본적인 요소들이 도입되었다.
HTTP 1.1 - HTTP의 완성
HTTP 1.0의 기능에 더해 채널 전송, Accept 헤더에 의한 콘텐트 네고시에이션, 복잡한 캐시 컨트롤, 지속적 연결 등 기능이 추가 되었다.
클라이언트와 서버
웹은 아키텍처 스타일로 클라이언트/서버를 채용하고 있다. 클라이언트가 정보를 제공하는 서버에 접속해 각종 요청을 보내고 응답을 받는 구조이다.
요청과 응답
앞서 말한것과 같은 프로토콜을 가리켜 요청/응답형 프로토콜이라고 한다. 서버에서 처리 시간이 많이 걸리더라도 요청을 보낸 클라이언트는 응답이 돌아올 때까지 대기한다. 이것은 HTTP가 동기형 프로토콜이기 때문이다.
클라이언트에서 일어나는 일들
- 요청메시지 구축
- 요청메시지 송신
- 응답 수신 대기
- 응답 메시지 수신
- 응답 메시지 해석
- 클라이언트의 목적을 달성하기 위해 필요한 처리
서버에서 일어나는 일들
- 요청 수신 대기
- 요청 메시지 수신
- 요청 메시지 해석
- 적절한 애플리케이션 프로그램으로 처리를 위임
- 애플리케이션 프로그램으로부터 결과를 취득
- 응답 메시지 구축
- 응답 메시지 송신
HTTP 메시지
HTTP 메시지 = 요청 메시지 + 응답 메시지
-
요청 메시지
GET /search?q=test&debug=true#n10 HTTP/1.1 Host: example.com:8080-
요청 라인
요청 메시지의 첫 번째 라인을 의미한다. 메서드, 요청 URI, 프로토콜 버전으로 구성된다. 요청 라인에는 경로 이후의 문자열이 들어가고, 포트 번호는 Host 헤더에서 지정한다. 요청 URI에서 경로를 사용한 경우에는 Host 헤더가 필수적이지만, 절대 URI를 사용한 경우에는 Host 헤더를 생략할 수 있다
GET http://example.com/test HTTP/1.1 -
헤더
헤더는 메시지의 메타 데이터이다. 하나의 헤더는 복수의 헤더를 가질 수 있다.
-
바디
바디에는 메시지를 나타내는 본질적인 정보가 들어간다.
-
응답 메시지
앞서 나온
http://example.com/test로의 요청이 성공하면 다음과 같은 응답을 클라이언트에게 보낸다.HTTP/1.1 200 OK Content-Type:application/xhtml+xml; charset=utf-8 <html xmlns="http://w3.org/1999/xhtml"> ... </html>
-
-
응답 메시지
-
스테이터스 라인
프로토콜 버전(HTTP/1.1), 스테이터스 코드(200), 텍스트 구문(OK)로 구성된다.
-
헤더
응답 메시지의 둘째 줄부터는 요청 메시지와 마찬가지로 헤더이다.
-
바디
헤더와 바디는 빈 줄로 구분된다. 위 예제에서는 바디 HTML이 포함되어 있다.
-
-
HTTP 메시지의 구성요소
첫째 줄은 스타트 라인이라고 총칭한다. 요청 메시지의 경우 요청라인. 응답 메시지의 경우 스테이터스 라인이 된다. 헤더 각 행의 줄 바꿈은 CRLF이다. 헤더의 종료는 빈 줄로 식별하고, 헤더는 생략이 가능하다.
바디에는 텍스트뿐만 아니라, 바잉너리 데이터도 들어갈 수 있다.
HTTP의 스테이트리스성
스테이리스란 서버가 클라이언트의 애플리케이션 상태를 보존하지 않는다는 제약을 말한다. 그렇다면 애플리케이션 상태란 무엇일까?
-
스테이트풀한 대화는 간결함
-
스테이트리스한 대화는 장황함
-
스테이트풀한 대화에서 서버는 클라이언트의 주문 내역을 기억함
-
스테이트리스한 대화에서 클라이언트는 매번 모든 주문을 반복함
-
애플리케이션 상태
-
스테이트풀 : 서버가 클라이언트가 이전에 한 주문을 계속 기억하고 있다.
-
스테이트리스 : 서버가 클라이언트가 이전에 한 주문을 기억하지 못해서 계속해서 이전 정보를 전달해주어야 한다.
애플리케이션 상태는 다른 이름으로 세션 상태라고도 한다.
세션 : 시스템에 로그인하고 로그아웃할 때까지 일련의 조작을 모아 세션이라고 부른다.
이 일련의 조작 중의 상태는 애플리케이션 상태를 말하는 것이므로 애플리케이션 상태는 거의 동일한 의미가 된다.
대표적인 스테이트풀한 프로토콜은 FTP이다. FTP에서는 클라이언트가 FTP 서버에 로그인해서 로그아웃할 때까지 그 클라이언트가 어느 디렉터리에 있는지와 같은 애플리케이션 상태를 서버가 관리한다.
-
-
스테이트풀의 결점
서버가 클라이언트의 상태를 기억하는것은 , 클라이언트의 수가 증가함에 따라서 어려워지게 된다. 즉 스테이트풀 아키텍처에서는 규모를 확장하기가 어렵다.
-
스테이트리스의 이점
스테이트리스는 클라이언트가 요청 메시지에 필요한 정보를 모두 포함한다. 이를 자기 기술적 메시지라고도 한다. 스테이트리스한 서버는 애플리케이션 상태를 기억할 필요가 없기 때문에 서버 시스템이 단순해진다. 이 특성을 이용하면 확장 또한 간단해지기 때문에, 클라이언트가 늘어나면 단순히 서버를 증설하면 된다.
-
스테이트리스의 결점
확장성에 있어서 스테이트리스한 아키텍처는 큰 위력을 발휘하지만 결점도 있다.
-
퍼포먼스의 저하
서버를 스테이트리스로 만들기 위해서는 클라이언트는 매번 필요한 정보를 모두 송신해야 한다. 때문에 다음과 같은 이유로 성능에 영향을 미친다.
- 송신할 데이터의 양이 많아진다.
- 인증 등 서버에 부하가 걸리는 처리를 반복하다.
-
통신 에러에 대한 대처
-
스테이트풀한 대화
애플리케이션 상태를 기억하고 있기 때문에, 요청이 들어오고 네트워크 문제가 생겼을 때 이미 첫 번째 요청이 처리되고 있다는 사실을 클라이언트에게 전달할 수 있다. -> 1개의 요청만 처리
-
스테이트리스한 대화
애플리케이션 상태를 기억하지 못하기 때문에, 요청이 들어오고 네트워크 문제가 생겼을 때, 그 요청이 처리되고 있는지 알 수 없다. -> 2개의 요청이 중복으로 처리 됨
-
-
심플한 프로토콜의 강점
HTTP의 가장 큰 특징은 심플함이다. HHTP가 심플하기 때문에 브라우저는 PC뿐 아니라 다양한 디바이스에서도 구현될 수 있게 되었으며, 웹 서비스와 웹 API가 같은 프로토콜로 실현될 수 있는 것이다.
