[컴퓨터 네트워크] 네트워크의 응용 계층 - HTTP의 특징과 메시지 구조

1. DNS와 URI/URL
2. HTTP의 특징과 메시지 구조
3.  HTTP 메서드와 상태 코드
4. HTTP 주요 헤더

 

2.  HTPP의 특징과 메시지 구조

 

HTTP overview

• Web's application 계층 protocol
• client(browser)/server(web server) model
• 클라이언트는 requests, receives, displays Web objects, 서버는 sends objects in response to requests
• 브라우저에 상관 없이 HTTP 프로토콜 메시지를 만들어야 함. 

web page consists of objects, each of which can be stored on different web servers. obejcts can be HTML file, JPEG image, Java applet, audio file... web page consists of base HTML-file which includes several referenced obejcts. each object is addressableby a URL. 

 

 

 

HTTP의 목적

데이터 형식에 구애 받지 않고 애플리케이션의 다양한 자원을 네트워크를 통해 송수신하는 것

 

HTTP의 특징(기억할 것)

1. 요청 응답 기반 프로토콜
2. 미디어 독립적 프로토콜
3. 스테이트리스 프로토콜
4. 지속 연결 프로토콜

 

1. 요청 응답 기반 프로토콜

• 요청 메시지를 보내는 클라이언트와 이에 대한 응답 메시지를 보내는 서버가 서로 HTTP 요청 메시지와 HTTP 응답 메시지를 주고 받는 구조로 작동합니다. 

▶ Application architectures에는 Client-Server, P2P 구조가 있는데 HTTP는 그 중 Client-Server에 해당한다.

▷ Client-Server 패러다임이란, 서버는 always-on host로서, permanent한 IP 주소를 가진다. 하지만 permanent 하다고 해서 영원하다는게 아니라, '자고 일어났는데 바뀌면 안된다'의 permanent를 말한다. 클라이언트는 서버와 communicate하고 클라이언트끼리는 직접적으로 communicate 하지는 않는다. 또한, dymanic한 IP 주소를 가진다는 점에서 서버와 큰 차이가 있다.(학교에 있으면 학교 IP 주소, LTE 켜면 SKT나 KT가 준 IP 주소...)

 

2. 미디어 독립적 프로토콜

• HTTP의 목적에 걺자게, HTTP는 HTTP 메시지를 통해 HTML, JPEG, PNG, XML 등 다양한 종류의 자원을 주고받을 수 있습니다.
• HTTP는 주고 받을 자원의 특성과 무관하게 자원을 주고 받는 수단(인터페이스) 역할만 수행합니다.

3. 스테이트리스 stateless 프로토콜

• 서버는 HTTP 요청을 보낸 클라이언트 관련 상태를 기억하지 않습니다.
• 따라서 클라이언트의 모든 HTTP 요청은 독립적인 요청으로 간주됩니다. (인터넷 표준 공식 문서인 RFC 9110에 가장 먼저 강조된 특성인 만큼, 꼭 기억할 것!)

HTTP가 상태를 유지하지 않는 이유?
-> HTTP의 중요한 설계 목표 중 확장성scalability, 견고성robustness 을 위해.
(stateless 하면 필요한 경우 언제든 쉽게 서버를 추가할 수 있어 확장성을 높이고, 서버 중 하나에 문제가 생기더라도 쉽게 다른 서버로 대체할 수 있어 견고성을 높일 수 있음.)
많은 클라이언트의 상태 정보를 유지하는 것은 서버에 큰 부담이 되고, 여러 대로 구성된 서버 모두가 모든 클라이언트의 상태를 유지해야 한다면 모든 서버가 모든 클라이언트의 상태 정보를 공유해야 하는 문제가 생긴다. 만일 모든 서버가 클라이언트의 상태 정보를 공유하지 못하면, 클라이언트가 특정 서버에 종속되게 된다. 그러다가 그 서버에 문제가 생기면 해당 서버에 종속된 클라이언트는 직전까지의 HTTP 통신 내역을 잃어버리는 문제가 발생.

 

 

4. 지속 연결 프로토콜 

• HTTP의 많은 버전 중 HTTP 1.1과 2.0은 TCP를 기반으로 작동합니다.
• 그러나 TCP는 연결형 프로토콜, HTTP는 비연결형 프로토콜이기 때문에 지속 연결 기술 제공
• keep-alive 라고도 부릅니다.
• 하나의 TCP 연결 상에서 여러 개의 요청-응답을 주고받을 수 있는 기술입니다. 

 

▶ HTTP 1.1과 2.0은 TCP를 기반으로 작동하지만, HTTP 3.0은 UDP를 기반으로 작동한다.

▶ HTTPS connections에는 non-persistent HTTP 와 persistent HTTP가 있는데, non-persistent HTTP는 Object를 하나 받아올 때마다 새로운 TCP 연결를 열고, 닫아야 한다. 반면 persistent HTTP는 여러개의 Objects가 하나의 TCP 연결에서 보내질 수 있다. 

(아마 학교 교재는 1.1 기준으로 설명해서, 다양하게 얘기한듯...?)

 

---

미디어 타입 media type

• HTTP에서 메시지로 주고받는 자원의 종류로서, MIME 타입이라고도 부릅니다.
• 네트워크 세상의 확장자와 같은 역할을 합니다.
• '타입/서브타입 type/subtype'의 형식으로 구성됩니다.
• 타입 : 데이터의 유형
• 서브타입 : 주어진 타입에 대한 세부 유형

---

HTTP의 버전

 

 

HTTP 1.1

• 현재까지 널리 사용되고 있는 버전입니다.
• HTTP 1.1부터 '지속적 연결' 기능이 공식적으로 지원되었습니다.
• 메시지를 평문으로 주고 받으며, 인터넷에서 자주 사용되는 다양한 편의 기능들이 추가되었습니다.
• 옵션으로 TLS 기능 제공...?(다담주에 추가 예정)
• Server responds in-order(FCFS : first-come-first-served scheduling) to GET requests
• with FCFS, HOL blocking 문제 발생(small object may have to wait for transmission)

 

HTTP 2.0

• HTTP 1.1의 단점을 보완하고 개선하기 위한 버전입니다. 
• methods, status codes, most header fields unchanged from HTTP 1.1
• transmission order of requested objects based on client-specified object priority (FCFS만을 따르지는 않음) 
• objects devided into frames, fram transmission interleaved

HTTP 2.0은 HTTP Multiplexing 과 같은 기능을 통해 HOL 블로킹(Head-Of-Line blocking)이라는 HTTP 1.1의 문제를 완화했습니다. 
**HOL 블로킹이란?
-> 같은 큐에 대기하며 순차적으로 처리되는 여러 패킷이 있을 때, 첫 번째 패킷의 처리 지연으로 인해 나머지 패킷들의 처리도 모두 지연되는 문제 상황

• 바이너리 데이터 기반 송수신
• 헤더 압축 (네트워크 이용 효율 ↑)
• 서버 푸시(server push) : 클라이언트가 요청하지 않아도 미래에 필요할 것으로 예상되는 자원을 미리 전송하는 기능입니다. 예를 들어, 클라리언트가 index.html 만을 요청했더라도 'styles, css, script.js' 파일이 'index.html'과 함께 사용될 것으로 예상되면 이를 미리 함께 응답합니다.
• HTTP Multiplexing 기법 : 여러 개의 독립적인 stream을 바탕으로 요청-응답 메시지를 병렬적으로 주고받는 기술입니다.

 

 

 

 

HTTP 3.0

• 비교적 가장 최근에 등장하여 사용 비중이 점차 높아지고 있습니다.
• UDP를 기반으로 구현된 QUIC(application layer 프로토콜) 라는 프로토콜을 기반으로 동작합니다. (이전까지는 모두 TCP 기반)
• -> UDP는 TCP에 비해 송수신 속도가 빠르기 때문에 HTTP/3.0을 통해 속도 면에서 크게 개선되었습니다.
• HOL 블로킹 문제 해결 
• 데이터를 순서를 유지한채로 No loss 하게 전송 
• key goal : decreased delay in multi-object HTTP requests
• adds security, per object error-and congestion control(more pipelining) over UDP

---

HTTP 메시지 조회

크롬 브라우저에서 [개발자 도구]-[네트워크] 클릭 후, HTTP를 사용하는 특정 웹사이트에 접속

---

 

HTTP 메시지 구조

시작 라인 (줄바꿈)
필드 라인 (줄바꿈)
(줄바꿈)
메시지 본문

• 필드 라인은 여러 개 존재 할 수 있습니다.
• 메시지 본문은 없을 수 있으나, HTTP를 통해 주고 받는 자원이 명시됩니다. 

시작 라인

• 시작 라인으로 HTTP 메시지가 요청 메시지인지 응답 메시지인지 구분할 수 있습니다.
• 요청 메시지인 경우에는 요청 라인request-line 이 되고, 응답 메시지인 경우에는 상태 라인status line 이 됩니다.
• 요청 라인 형식: 메서드 (공백) 요청 대상 (공백) HTTP 버전 (줄바꿈)
• 상태 라인 형식 : HTTP 버전 (공백) 상태 코드 (공백) 이유 구문 (줄바꿈)

HTTP/1.1 200 OK
HTTP/1.1 404 Not Found

구분	필드 이름	설명
요청 라인	메서드	클라이언트가 서버의 자원에 대해 수행할 작업의 종류
상태 라인	상태 코드 (status code)	요청에 대한 결과를 나타내는 3자리 정수
	이유 구문 (reason phrase)	상태 코드에 대한 문자열 형태의 설명

 

*상태코드 200 : 요청이 성공적으로 받아들여지고 수행되었음

*상태코드 404 : 요청한 자원이 존재하지 않음

 

 

 

필드 라인

• HTTP header(HTTP 메시지 전송과 관련한 부가 정보이자 제어 정보) 가 명시됩니다.
• 일반적으로 하나의 HTTP 메시지에는 여러 헤더가 포함되어 있습니다.
• 헤더 구조 : 콜론(:)을 기준으로 header-name 과 그에 대응하는 header-value로 구성됩니다.

Content-type : text/html
Content-length : 648