Http!

들어가기

이번에는 우리가 자주쓰지만 간과하고 넘어가고 있는 부분에대해 이야기 해보려고한다.
바로 http 이다. ajax또는 fetch를 통해 많이들 사용하고 안다고 생각하지만 모르는 부분에 대해 정리하고 넘어가려고한다.

http의 등장배경

http는 CERN(유럽 입자 물리학 연구소)의 팀버너스 리 박사는 멀리떨어저있는 연구자와 지식을 공용할 수 있도록 시스템을 고안했다.
그 이후 1990년 11월에 세계 최초의 웹 서버와 웹 브라우저가 개발되었습니다.

여기서 중요한 점은 http는 지식을 공용하기 위한 목적으로 만들어졌다는 것 입니다.

http ~ tcp/ip

http는 tcp/ip라는 프로토콜에서 움직이고 있습니다. http는 그 중 하나이고 http를 이해하기 위해 tcp/ip 개념만 설명하고 넘어가겠습니다.
tcp/ip 는 4계층으로 이루어져있습니다.
애플리케이션 계층, 트랜스포트 계층, 네트워크 계층,링크 계층 이렇게 4계층으로 나뉘어져 있습니다. tcp/ip가 계층화된 것은 어떤 계층에서 사양이 변경되어있을 때 전체를 바꾸지 않고 해당 계층만 바꾸기 위해서 입니다. 또한 계층화 되어있기 때문에 자신이 담당하는 부분만 고려하게 됩니다.

애플리케이션 계층

애플리케이션 계층은 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정합니다. FTP,DNS 또한 애플리케이션의 한가지 이고 이번에 우리가 알아볼 http도 이 계층에 포함됩니다.

트랜스포트 계층

트랜스포트 계층은 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이터 흐름을 제공합니다. 트랜스포트 계층에서는 서로 다른 성질을 가진 TCP 와 UDP 두 가지 프로토콜이 있습니다.

네트워크 계층

네트워크 계층은 네트워크 상에서 패킷의 이동을 다룹니다. 패킷이란 전송하는 데이터의 최소 단위를 말합니다. 이 계층에서 어떠한 경로를 거쳐 상대의 컴퓨터 까지 패킷을 보낼지를 결정합니다.
인터넷의 경우라면 상대 컴퓨터에 도달하는 동안에 여러 대의 컴퓨터랑 네트워크 기기를 거쳐서 상대방에게 배송됩니다. 그러한 여러가지 선택지 중에서 하나의 길을 결정하는 것이 네트워크 계층의 역할입니다.

링크 계층

네트워크에 접속하는 하드웨어적인 면을 다룹니다. 운영체제가 하드웨어를 제어하기 때문에 디바이스 드라이버랑 네트워크 인터페이스 카드를 포함합니다. 그리고 케이블과 같이 물리적으로 보이는 부분도 포함합니다. 하드웨어적 측면은 모두 링크 계층의 역할입니다.

통신 순서

TCP/IP로 통신을 할 때 계층을 순서대로 거쳐 상대와 통신을 합니다. 송신하는 측은 애플리케이션 계층부터 내려가고 수신하는 측은 애플리케이션 계층으로 올라갑니다.
예를 들어 송신측 클라이언트의 애플리케이션 계층에서 어느 웹 페이지를 보고 싶다라는 http 리퀘스트를 지시하면, 그 다음에 있는 트랜스포트 계층에서는 애플리케이션 계층에서 받은 데이터를 통신하기 쉽게 조각내어 안내번호와 포트번호를 붙여 네트워크 계층에 전달하게 됩니다.
네트워크 게층에서는 수신지 MAC 주소를 추가해서 링크 계층에 전달합니다. 이로써 네트워크를 통해 송신할 준비가 되었습니다.
수신측 서버는 링크 계층에서 데이터를 받아들여 순서대로 위의 계층에 전달하여 애플리케이션 계층까지 도달합니다. 수신측 애플리케이션 계층에 도달하게 되면 송신측에서 발신했던 http 리퀘스트 내용을 수신할 수 있습니다.

Http 동작 방식

송신측에서 데이터를 전달할때 각각의 계층에서 필요에 따른 헤더를 추가하게 됩니다.
어플리케이션 계층에서 http 데이터를 보내면 TCP 세그먼토와 TCP 헤더를 트랜스포트 계층에서 붙이게 됩니다. 네트워크 계층에서는 IP헤더와 IP 데이터 그램을 붙이게 되고 마지막으로 링크 계층에서는 Ethernet헤더 와 네트워크 프레임을 붙이게 됩니다.
반대로 수신측에서는 각각의 계층을 지날때마다 사용한 헤더를 삭제합니다.
이렇게 정보를 감싸는 것을 캡슐화라고합니다.

http/0.9

http가 등장한 때는 1990년인데, 이 당시 http가 정식 사양서는 아니였고, http 1.0 이전이라는 의미에서 http/0.9라고 불렸습니다.
요청은 단일 라인으로 구성되며 리소스에 대한 (프로토콜, 서버 그리고 포트는 서버가 연결되고 나면 불필요로 하므로 URL은 아닌) 경로로 가능한 메서드는 GET이 유일했습니다

http/1.0

http는 1996년 5월에 정식으로 등장했습니다.
이때 http/1.0으로 RFC1945가 발행되었습니다.
버전 정보가 각 요청 사이내로 전송되기 시작했습니다. (HTTP/1.0 이 GET 라인에 붙은 형태로)
상태 코드 라인 또한 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대한 성공과 실패를 알 수 있고 그 결과에 대한 동작(특정 방법으로 그것의 로컬 캐시를 갱신하거나 사용하는 것과 같은)을 할 수 있게 되었습니다.
HTTP 헤더 개념은 요청과 응답 모두를 위해 도입되어, 메타데이터 전송을 허용하고 프로토콜을 극도로 유연하고 확장 가능하도록 만들어주었습니다.
새로운 HTTP 헤더의 도움으로, 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가되었습니다(Content-Type 덕분에).

http/1.1

1997년 1월에 공개되었고 현재 가장 많이 사용되는 버전입니다.
HTTP/1.1은 모호함을 명확하게 하고 많은 개선 사항들을 도입했습니다:

커넥션이 재사용될 수 있게 하여, 탐색된 단일 원본 문서 내로 임베드된 리소스들을 디스플레이하기 위해 사용된 커넥션을 다시 열어 시간을 절약하게 하였습니다.
파이프라이닝을 추가하여, 첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째 요청 전송을 가능케 하여, 커뮤니케이션 레이턴시를 낮췄습니다.
청크된 응답 또한 지원됩니다.
추가적인 캐시 제어 메커니즘이 도입되었습니다.
언어, 인코딩 혹은 타입을 포함한 컨텐츠 협상이 도입되어, 클라이언트와 서버로 하여금 교환하려는 가장 적합한 컨텐츠에 대한 동의를 가능케 했습니다.
Host 헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 기능이 서버 코로케이션을 가능케 합니다

http/2.0

몇 년에 걸쳐, 웹 페이지는 매우 복잡해지면서, 종종 진정한 애플리케이션이 됩니다. 디스플레이되는 시각적 미디어의 양에 덧붙여 상호작용을 추가하기 위한 스크립트의 양과 크기는 점점 더 많이 증가하고 있습니다: 더 많은 데이터들이 더 많은 요청 너머로 전송되고 있습니다. HTTP/1.1 커넥션은 올바른 순서로 전송되는 요청을 필요로 합니다. 또한, 몇몇 병렬 커넥션이 이론적으로 사용 가능한 경우(일반적으로 5와 8 사이에서), 여전히 많은 양의 오버헤드와 복잡도가 남아 있습니다. 예를 들어, HTTP 파이프라이닝은 디플로이 악몽임이 확실해졌습니다.

2010년 전반기에, Google은 실험적인 SPDY 프로토콜을 구현하여, 클라이언트와 서버 간의 데이터 교환을 대체할 수단을 실증하였습니다. 그것은 브라우저와 서버 측 모두에 있어 많은 관심을 불러일으켰습니다. 응답성 증가 능력을 입증하고 전송된 데이터 중복에 관한 문제를 해결하면서, SPDY는 HTTP/2 프로토콜의 기초로써 기여했습니다.

https

보안 전송을 위한 HTTP 사용
HTTP에 일어났던 가장 큰 변화는 1994년 말에 이미 완료되었습니다. 기본적인 TCP/IP 스택을 통해 HTTP를 전송하는 대신에, 넷스케이프 커뮤니케이션은 그것의 토대 위에 추가적인 암호화된 전송 계층인 SSL을 만들어냈습니다. SSL 1.0은 회사 외부로 릴리즈된 적이 없으며, SSL 2.0과 그것의 후계자인 SSL 3.0과 SSL 3.1은 서버와 클라이언트 간에 교환된 메시지 인증을 암호화하고 보장하여 e-커머스 웹 사이트를 만들어내도록 했습니다. SSL은 표준 트랙 상에 놓여져 있었고 마침내 TLS가 되어, 성공적으로 취약성을 종식시키는 1.0, 1.1 그리고 1.2 버전이 나와있습니다. TLS 1.3은 현재 진행 중에 있습니다.

같은 시간 동안, 암호화된 전송 계층에 대한 필요성이 대두되었습니다: 웹은 광고주, 불특정 개인, 혹은 범죄자가 다른 사람인척 가장하거나 전송된 데이터를 수정된 데이터로 대치시키고자, 개인 정보를 빼내려고 경쟁하는 정글 속에, 거의 학문적인 네트워크의 상대적인 신뢰를 남겨두었습니다. HTTP 상에서 만들어진 애플리케이션들이 주소록, 이메일 혹은 사용자의 지리적 위치와 같은 수 많은 개인 정보에 접근하는 등 점점 더 강력해짐에 따라, TLS의 필요성은 e-커머스 사용 케이스 외에 여기 저기서 나타나게 되었습니다.

참고

그림으로 배우는 Http & NetWork Basic
MDN Web Doc