👨🏻💻 HTTP의 중요성
- HTTP란 하이퍼텍스트 전송용 프로토콜, 실제로는 하이퍼텍스트 뿐만 아니라 컴퓨터에서 다룰 수 있는 데이터라면 무엇이든 전송 가능
- HTTP는 REST의 중요한 특징인 Uniform 인터페이스, 스테이트리스 서버, 캐시 등을 구현하고 있는 Web 기반의 프로토콜
👨🏻💻 TCP/IP란 무엇일까
- HTTP는 TCP/IP 기반
- TCP(Transmission Control Protocol)와 IP(Internet Protocol)는 인터넷의 토대를 구성하는 중요한 네트워크 프로토콜
계층형 프로토콜
- 인터넷의 프로토콜을 계층구조를 가짐.
- 각 계층별로 추상화하여 구현하면, 하위 계층의 구체적인 사항에 좌우되지 않고, 상위 계층 구현 가능
네트워크 인터페이스 계층
- 물리적인 케이블이나 네트워크 어댑터에 해당하는 부분
인터넷 계층
- 네트워크에서 데이터를 실제로 주고받는 역할
- IP
- 역할 : IP 어드레스와 패킷 단위로 데이터 통신
- IP에서는 데이터의 기본적인 통신단위를 ‘패킷'이라고 부름
트랜스포트 계층
- 데이터의 무결성 보증
- TCP
- 역할 : 목적지의 상대에 대해서 커넥션을 연결
- 커넥션을 사용해 데이터의 누락을 체크하고, 데이터의 도달을 보증
- TCP로 접속된 커넥션에서 전송하는 데이터가 어느 애플리케이션으로 전달될지 결정하는 것이 포트번호
애플리케이션 계층
- 구체적인 인터넷 애플리케이션, 메일이나 DNS 그리고 HTTP를 실현하는 계층
- 소켓은 네트워크에서의 데이터 교환을 추상화한 API로 접속, 송신, 수신, 절단 등의 기본적인 기능을 갖춤.
👨🏻💻 HTTP의 버전
HTTP 0.9 - HTTP의 탄생
- HTTP 0.9에는 헤더가 없었다.
- 사용할 수 있는 HTTP 메서드는 GET 뿐
HTTP 1.0 - HTTP 최초의 표준화
- IETF에서 표준화가 이루어진 최초의 버전
- 헤더의 도입, GET 이외의 메서드 추가 등 HTTP 1.1로 이어지는 기본적인 요소들이 도입됨.
HTTP 1.1 - HTTP의 완성
- RFC 2616이 현재의 HTTP 1.1 스펙
- 채널 전송, Accept 헤더에 의한 콘텐츠 네고시에이션, 복잡한 캐시 컨트롤, 지속적 연결 등의 기능 추가
👨🏻💻 클라이언트와 서버
- 웹은 아키텍처 스타일로 클라이언트/서버를 채용
- 유저 에이전트(User Agent) 등장
- 요청을 송신할 목적으로 서버와의 커넥션을 확립하는 프로그램이 클라이언트, 서버에 대해 구체적인 요청을 발행하는 것이 유저 에이전트
- 본서에서는 같은 의미로 사용
👨🏻💻 요청과 응답
- 서버에서의 처리에 시간이 많이 걸리는 경우라도 요청을 보낸 클라이언트는 응답이 돌아올 때까지 대기 → HTTP가 동기형 프로토콜임을 의미
클라이언트에서 일어나는 일들
- 요청 메시지 구축
- 요청 메시지 송신
- (응답이 돌아올 때까지 대기)
- 응답 메시지 수신
- 응답 메시지 해석
- 클라이언트의 목적을 달성하기 위해 필요한 처리
- 이미지와 스타일시트로의 링크 등을 포함하기 위해 재요청을 보내기도 함.
서버에서 일어나는 일들
- (요청을 대기)
- 요청 메시지 수신
- 요청 메시지 해석
- 적절한 애플리케이션 프로그램으로 처리를 위임
- 애플리케이션 프로그램으로부터 결과를 취득
- 응답 메시지 구축
- 응답 메시지 송신
👨🏻💻 HTTP 메시지
요청 메시지와 응답 메시지를 합해서 HTTP 메시지라 부른다.
요청 메시지
- http://example.com/test 에 대한 최소한 요청 메시지
GET /test HTTP/1.1 Host: example.com Host: example.com- 요청 라인(Request-Line) : 요청 메시지의 첫 번째 줄
- 메서드 : URI로 식별하는 서버상의 리소스에 대해 수행하고자 하는 처리를 지정
- 요청 URI : 경로 이후의 문자열이 되거나 혹은 절대 URI
- 프로토콜 버전 으로 구성
- 헤더 : 요청 메시지의 둘째 줄부터 시작, 메시지의 메타 데이터, 복수의 헤더를 가질 수 있음. 각 헤더는 ‘이름:값'의 구성
- Host 헤더 : 요청 URI에 경로를 사용한 경우 Host 헤더가 필수적이지만, 절대 URI를 사용한 경우 생략 가능
- 경로
- 포트번호
- 바디 : 헤더 뒤에 이어짐. 해당 메시지가 나타내는 본질적인 정보를 표현
- 요청 라인(Request-Line) : 요청 메시지의 첫 번째 줄
응답 메시지
- http://example.com/test
HTTP/1.1 200 OK Content-Type: application/xhtml + xml; charset=utf-8 <html xmlns="http://www.w3.org/1999/xhtml"> ... </html> Content-Type: application/xhtml + xml; charset=utf-8 <html- 스테이터스 라인(Status Line) : 응답 메시지의 첫째 줄
- 프로토콜 버전
- 스테이터스 코드 : 요청의 결과를 프로그램으로 처리 가능한 수치 코드로 표현
- 텍스트 구문
- 헤더 : 응답 메시지의 둘째 줄부터 시작
- 바디 : 헤더와 바디는 빈 줄(헤더 맨 마지막의 줄 끝에 연속하는 CRLF)로 구분
- 스테이터스 라인(Status Line) : 응답 메시지의 첫째 줄
HTTP 메시지의 구성요소
- 스타트 라인 : 요청 메시지의 경우 요청 라인, 응답 메시지의 경우 스테이터스 라인
- 헤더 : 헤더 각 행의 줄 바꿈은 CRLF, 헤더의 종료는 빈 줄로 식별, 헤더 생략 가능
- 바디 : 텍스트뿐만 아니라, 바이너리 데이터도 포함 가능, 바디 생략 가능
👨🏻💻 HTTP의 스테이트리스성
HTTP는 서버가 애플리케이션의 상태를 보존하지 않는 ‘스테이트리스’한 프로토콜로 설계됨.
- 햄버거 가게의 예
-
스테이트풀한 대화에서는 점원이 손님이 앞서 주문한 상품들을 기억하고 있는다.
-
반면 스테이트리스한 대화에서는 점원이 손님이 앞서 주문한 상품들을 기억하지 않기 때문에 손님이 마지막 주문 때 앞서 주문한 상품들을 나열하면 점원에게 이야기한다.
애플리케이션의 상태가 무엇인가? 애플리케이션의 상태는 다른 이름으로 ‘세션 상태'라고도 한다.
-
그럼 스테이트리스는 손님(클라이언트) 입장에서 불편하지 않냐라는 의문을 갖을 수 있지 않을까?
-
스테이트풀의 결점
- 서버가 클라이언트의 애플리케이션 상태를 기억하는 것은 클라이언트의 수가 증가함에 따라 어려워지게 된다.
- 서버가 동시에 상대할 수 있는 클라이언트 수는 한계가 존재
- 데이터 동기화의 오버헤드 존재
- 스테이트풀한 아키텍처로는 클라이언트의 수가 증가했을 경우 규모 확장이 어려워짐.
-
스테이트리스의 이점
- 서버가 클라이언트의 애플리케이션 상태를 기억하는 대신에 클라이언트가 자신의 애플리케이션 상태를 기억하고 모든 요청을 자기 기술적 메시지로 송신
- 요청을 처리하는 데 필요한 정보가 모두 포함되어 있는 메시지(자기 기술적 메시지)
- 시스템 확장이 쉬워짐
- 서버가 클라이언트의 애플리케이션 상태를 기억하는 대신에 클라이언트가 자신의 애플리케이션 상태를 기억하고 모든 요청을 자기 기술적 메시지로 송신
-
그럼 스테이트리스에는 결점이 없을까?
- 퍼포먼스 저하
- 송신할 데이터의 양이 많아진다.
- 인증 등 서버에 부하가 걸리는 처리를 반복한다.
- 통신 에러에 대한 대처
- 네트워크 트러블이 발생했을 때 요청이 제대로 처리되었는지 알 수 없다.
- 퍼포먼스 저하
-
👨🏻💻 심플한 프로토콜의 강점
HTTP의 가장 큰 특징은 심플함
