HTTP

HTTP Protocol(동기형 프로토콜 : 요청이 있으면 응답이 있음)

• HTTP(Hyper Text Transfer Protocol) 로 RFC 2616 에서 규정된 Web에서 데이터를 주고 받는 프로토콜

• 이름은 하이퍼텍스트 전송용 프로토콜이지만 실제로는 HTML, XML, JSON, Image, Voice, Javascript, PDF 등 다양한 컴퓨터에서 다룰 수 있는 것은 모두 전송 가능

• 클라이언트와 서버들은 (데이터 스트림과 대조적으로) 개별적인 메시지 교환에 의해 통신함(request와 response 통신)

• HTTP는 애플리케이션 계층의 프로토콜로, 신뢰 가능한 전송 프로토콜이라면 이론상으로는 무엇이든 사용할 수 있으나 TCP 혹은 암호화된 TCP 연결인 TLS를 통해 전송됨

• 원래는 connection 이 바로 끊어지는데 요즘은 keep-alive 를 이용하여 한번 맺고 잘 안 끊으려고 함

• stateless함 — 바로 이전에 request의 내용에 대해서 전혀 기억하지 않음

• 동기형 프로토콜 — 요청이 있으면 응답이 있음

여기서 잠깐. 전송 프로토콜, 애플리케이션 계층 프로토콜.. 좀 헷갈린다

통신 프로토콜

• 1 이상의 실체 간에 무엇을, 언제, 어떻게 통신하는가에 대한 절차/규범/규정/규약/규칙

전송 계층 프로토콜

• 전송 계층에서는 패킷 단위로 데이터를 전송

• 기본 프로토콜은 전송 제어 프로토콜인 TCP와 사용자 데이터그램 프로토콜인 UDP

• UDP는 패킷의 확실한 전송을 보장하지 못하는 반면 TCP는 패킷의 확실한 전송을 보장

응용 계층 프로토콜 및 서비스

• 최종 사용자가 직접 사용할 수 있는 여러가지 프로토콜과 서비스를 정의

• TCP나 UDP가 제공하는 프로세스-프로세스 통신 서비스를 이용하여 유용한 기능을 수행

• 보통 사용자는 TCP/UDP에 직접 접속하지 않고 응용 계층을 이용하여 통신 서비스를 사용하며, 응용 계층 프로그램은 시스템 SW가 아닌 응용 프로그램으로 제공

지원 프로토콜

• TCP 응용 계층 프로토콜 : FTP(20,21), HTTP(80), Telnet(23), SMTP(25), POP3(110), IMAP(143) 등

• UDP 응용 계층 프로토콜 : DNS(53), DHCP(67,68), SNMP(161) 등

HTTP 기반 시스템의 구성요소

• 요청과 응답 사이에는 여러 개체들이 있는데, 예를 들면 다양한 작업을 수행하는 게이트웨이 또는 캐시 역할을 하는 프록시 등이 있음

• 실제로 브라우저와 서버 사이에는 좀 더 많은 컴퓨터들이 존재함(라우터, 모뎀). 웹의 계층적인 설계 덕분에 이들이 네트워크와 전송 계층 내로 숨겨짐

프록시

• 웹 브라우저와 서버 사이에서는 수많은 컴퓨터와 머신이 HTTP 메시지를 이어 받고 전달함

• 여러 계층으로 이루어진 웹 스택 구조에서 이러한 컴퓨터/머신들은 대부분은 전송, 네트워크 혹은 물리 계층에서 동작하며, 성능에 상당히 큰 영향을 주지만 HTTP 계층에서는 이들이 어떻게 동작하는지 눈에 보이지 않습니다.

• 이러한 컴퓨터/머신 중에서도 애플리케이션 계층에서 동작하는 것들을 일반적으로 프록시 라고 부릅니다. 프록시는 눈에 보이거나 그렇지 않을 수도 있으며(프록시를 통해 요청이 변경되거나 변경되지 않는 경우를 말함) 다양한 기능들을 수행할 수 있습니다
• 캐싱 (캐시는 공개 또는 비공개가 될 수 있습니다 (예: 브라우저 캐시))
• 필터링 (바이러스 백신 스캔, 유해 컨텐츠 차단(자녀 보호) 기능)
• 로드 밸런싱 (여러 서버들이 서로 다른 요청을 처리하도록 허용)
• 인증 (다양한 리소스에 대한 접근 제어)
• 로깅 (이력 정보를 저장)

HTTP의 기초

HTTP는 상태가 없지만, 세션은 있음

• stateless 이지만, 상태가 필요할 때 HTTP 쿠키를 이용하여 상태가 있는 세션을 만들 수 있음

• 헤더 확장성을 사용하여, 동일한 컨텍스트 또는 동일한 상태를 공유하기 위해 각각의 요청들에 세션을 만들도록 HTTP 쿠키가 추가됨

HTTP와 연결

• 연결은 전송계층에서 제어되므로 HTTP 영역 바깥임. 주로 TCP 를 이용

• HTTP가 요청/응답으로 교환하기 전 TCP handshake를 통해 연결을 설정해야함
• HTTP/1.0 — 기본 동작은 각 요청/응답에 대해 별도의 TCP 연결을 여는 것 → 비효율적
• HTTP/1.1 — 파이프라이닝 개념, 지속적 연결 개념 도입.
• 파이프라이닝이 활성화되면, 첫 번째 응답을 완전히 수신할 때까지 기다리지 않고 여러 요청을 보낼 수 있음
• HTTP/2 — 연결을 좀 더 지속되고 효율적으로 유지하는데 도움 되도록, 단일 연결 상에서 메시지를 다중 전송(multiplex). HTTP/2 이전에는 메시지를 읽을 수 있지만 이 버전 부터는 메시지가 프레임 속으로 캡슐화되어 직접 읽는게 불가능함

Request와 Response의 형태

Request header의 형태

• General headers : 일반적인 내용이 들어가있는 헤더

• Representation headers : 해당 내용을 어떠한 형태로 표현할지의 정보를 담고 있는 헤더

• Accept : 요청 HTTP 헤더는 MIME 타입으로 표현되는, 클라이언트가 이해 가능한 컨텐츠 타입이 무엇인지를 알려줍니다

• Content-Type 개체 헤더는 리소스의 media type 을 나타내기 위해 사용됩니다.

Response header

HTTP Method

• 멱등성은 계속해서 호출을 해도 같은 결과가 나오는 것

• 안정성은 계속해서 호출을 해도 서버에 있는 데이터가 변화가 생기거나 서버의 데이터가 삭제가 된다거나 그런것이 없음

• PUT은 생성하고 나서는 업데이트 하기 때문에 멱등성은 충족함. 안정성은 안됨. 데이터가 계속 바뀌기 때문에

HTTP Status Code

• 201 : PUT 요청에 성공 응답

HTTP 버전별 차이

HTTP 헤더

• X-Forwarded-For : HTTP 프록시나 로드 밸런서를 통해 웹 서버에 접속하는 클라이언트의 실제 IP 주소를 식별하는 사실상의 표준 헤더

MIME(Multipurpose Internet Mail Extensions) 타입

• MIME 타입이란 클라이언트에게 전송된 문서의 다양성을 알려주기 위한 메커니즘임

• 웹에서 파일의 확장자는 별 의미가 없음. 그 이유는 파일을 텍스트 문자로 전환해서 전달하기 때문
• 텍스트 문자로 전환되었기 때문에 해당 파일이 어떤 문서인지를 알려주기 위해 Content-Type 헤더에 MIME 타입을 명시함

• 이메일과 함께 동봉할 파일을 텍스트 문자로 전환해서 이메일 시스템을 통해 전달하기 위해 개발되었기 때문에 이름에 Internet Mail Extension 이 들어감. 그러나 현재는 웹을 통해 여러 형태의 파일 전달하는데 사용됨

멀티파트 타입

multipart/form-data
multipart/byteranges

• 멀티파트 타입은 일반적으로 다른 MIME 타입들을 지닌 개별적인 파트들로 나누어지는 문서의 카테고리를 가리킴

• 즉 이 타입은 합성된 문서를 나타내는 방법임

웹 개발자들을 위한 중요한 MIME 타입

• text/plain

• text/css

• text/html