[Network] HTTP 프로토콜

• 7계층 프로토콜은 매우 다양하다.
• 그 중 하나가 웹 통신을 위한 프로토콜인 HTTP 프로토콜이다.

---

HTTP 프로토콜

• HyperText Transfer Protocol
• 웹 표준 데이터를 받아오는 프로토콜
• 처음엔 Text, Html을 전송하는게 목적이었지만, 현재는 음성, 영상, 이미지, Json 등 거의 모든 형태의 데이터를 전송한다.
• 서버간 데이터를 주고받을 때도 대부분 HTTP를 사용하고 있다.
• Request / Response 동작에 기반해 서비스를 제공

---

HTTP 버전

• HTTP/0.9 1991년 : GET 메소드만 지원, HTTP 헤더X
• HTTP/1.0 1996년 : 메소드, 헤더 추가
• HTTP/1.1 1997년 : 현재 가장 많이 사용 (RFC2068 -> RFC2616 -> RFC7230~7235 (2014))
• HTTP/2.0 2015년 : 성능 개선
• HTTP/3 진행중 : TCP 대신 UDP 주로 사용, 성능 개선

---

Stateless (<-> Stateful)

• HTTP는 무상태 프로토콜을 지향한다. (클라이언트의 상태를 보존하지 않는다.)
• 서버가 상태를 보존하지 않기 때문에 필요한 데이터를 한번에 전송해주어야 한다.
• 하지만 상태를 보존하지 않는만큼 다른 서버로 대체하기 쉽다. (서버를 여러개로 확장하거나 대체하기 용이하다.)
• 장점 : 서버 확장성이 높아짐 (스케일 아웃)
• 단점 : 클라이언트가 추가 데이터를 전송한다.
• 한계 : 로그인 등 상태 유지가 필요한 경우 -> 브라우저의 쿠키와 서버의 세션을 활용해 상태를 유지한다.
• 보통 상태 유지는 꼭 필요할 때만 한다.

---

비연결성 (<-> 연결성)

• HTTP는 비연결성을 가진다.
• 연결성 : 요청을 보내고 응답을 받아서 연결을 유지한다. 이 때 서버는 연결을 계속 유지하기 때문에 서버 자원이 소모된다. 이는 만약 클라이언트가 작업을 하고 있지 않아도 서버가 연결을 계속 유지해야한다는 단점이 있다.
• 비연결성 : 요청을 보내고 응답을 받은 뒤에 연결을 종료한다. 서버가 연결을 유지할 필요가 없기 때문에 최소한의 자원만으로 서버유지가 가능하다.
• 비연결성 장점 : 1시간동안 수천명이 서비스를 사용해도 실제 서버에서 처리하는 요청은 수십개 이하로 매우 작음 (웹에서 계속 연속해서 검색버튼을 누르지는 않음.) / 서버 자원을 매우 효율적으로 사용할 수 있음
• 비연결성 단점 : TCP/IP 연결을 매회 새로 맺어야하므로 이에 대한 시간이 추가된다. 웹브라우저로 사이트를 요청하면 HTML뿐 아니라 자바스크립트, CSS, 추가이미지 등 수많은 자원이 함께 다운로드된다.(지금은 HTTP 지속연결로 문제 해결, HTTP/2, HTTP/3에서 더 많은 최적화)
• HTTP 지속연결 : 내부 메커니즘으로 바로 연결을 종료하지 않고 연결을 지속유지

---

HTTP 요청 프로토콜

Http 요청 프로토콜 예시

• 지금까지 다른 대부분의 프로토콜처럼 16진수 형태로 이루어진 것이 아닌, 글자(영어, 특수문자)로 적어 사용하게 된다.
• 요청하는 방식 및 클라이언트의 정보를 가지고 있다.

Start Line (request line)
Headers
공백
Body

• Start Line (request line) : [ 요청타입 (GET,POST 등) / 공백 / URI (Uniform Resource Identifier, 인터넷 상에서 특정자원을 나타내는 유일한 주소) / 공백 / HTTP버전 ]의 형태로 이루어져 있다. (ex. GET /user/login HTTP/1.1) (method SP request-target SP HTTP-version CRLF)
• Header : 패킷의 헤더와는 다르게 옵션같은 기능을 수행한다. (field-name ":" OWS field-value OWS)
• 공백 : 말그대로 공백으로 주어지는 부분 (CRLF)
• Body : 요청에 필요한 데이터

---

HTTP 응답 프로토콜

http 응답 프로토콜 예시 (공백 지워짐)

• 상태 및 사용자가 볼 웹 페이지를 가지고 있다.

Start Line (status line)
Headers
공백
Body

• SP : 공백 / CRLF : 엔터 / OWS : 띄어쓰기 허용
• Start Line (status line) : [ HTTP 버전 / 공백 / 상태 코드(200, 404, 503 등) / 공백 / 상태 문구 ]의 형태로 이루어져 있다. (ex. HTTP/1.1 200 OK) (HTTP-version SP status-code SP reason-phrase CRLF)
• Header : 패킷의 헤더와는 다르게 옵션같은 기능을 수행한다. (field-name ":" OWS field-value OWS)
• 공백 : 말그대로 공백으로 주어지는 부분 (CRLF)
• Body : 사용자가 요청한 데이터의 내용

---

HTTP 헤더 포맷

• 요청과 응답 프로토콜 모두에 Header가 포함되어 있다.
• 이는 패킷의 헤더와 다른 의미로 옵션과 같은 기능을 수행한다.
• 일반 헤더 : Content-Length (body 길이), Content-Type (body의 컨텐츠 종류)
• 요청 헤더 : Cookie (서버로 부터 받은 쿠키 재전송), Host (호스트명 상세하게 표기, HTTP1.1에는 필수), User-Agent (Client Program 식별 정보)
• 응답 헤더 : Server (사용하고 있는 웹 서버의 소프트웨어에 대한 정보 포함), Set-Cookie (쿠키를 생성하고 브라우저에 보낼 때 사용)

---

URI

• URL은 Uniform Resource Location의 약자이며, URI는 Uniform Resource Identifier의 약자이다.
• URL이 URI에 속하게된다고 생각하면 된다. 그외 URI로는 URN(Uniform Resource Name)이 있지만 거의 쓰이지 않기 때문에 URI와 URL을 거의 동일한 의미로 사용하는 경우가 많다.
• URL의 양식은 아래와 같다.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

• scheme : 주로 프로토콜을 사용, 어떤 방식으로 자원에 접근할 것인지 명시 (http, https, ftp 등), http는 80포트를 https는 443 포트를 주로 사용하기 때문에 포트는 생략이 가능하다.
• userinfo : 사용자정보를 포함해서 인증할 때 사용하지만 거의 사용되지 않는다.
• host : 호스트명으로 ip주소 혹은 도메인 주소를 입력한다.
• port : 접속포트 (일반적으로 생략)
• path : 리소스경로, 계층적구조 (ex. /home/file1.jpg)
• query : key=value형태로 데이터를 전달하며, &로 시작하고 &으로 추가가 가능하다. query parameter, query string 등으로 불린다. 웹서버에 제공하게되는 파라미터로 문자 형태로 전달된다.
• fragment : html 내부 북마크에 사용되며 서버에 전송하는 정보는 아니다.