배운것
HTTP란?
Hyper Text Transfer Protocol의 약자. (Made by Tim Berners - LEE)
HTML과 같은 하이퍼 미디어 문서를 전송하기 위한 Application(응용) Layer(계층) 프로토콜
초기에는 웹 브라우저와 웹 서버간의 커뮤니케이션을 위해 디자인 되었다.
HTTP는 Stateless Protocol이다. 이는 서버가 두 요청간에 어떠한 데이터(상태)도 유지하지 않음을 의미한다.
HTTP / 0.9 - One - Line Protocol
0.9는 매우 단순하다.
요청은 단일 라인으로 구성되며 리소스에 대한 경로로 가능한 request method는 GET이 유일했다.
GET /mypage.html
응답 또한 극도로 단순하다. 아래와 같이 오로지 파일 내용 자체로 구성된다.
<HTML>
A very simple HTML page
</HTML>
그 이후에 진화와는 다르게 HTTP 헤더가 없었는데 이는 HTML 파일만 전송될 수 있으며, 다른 유형의 문서는 전송될 수 없음을 의미한다.
상태 혹은 오류 코드 또한 없었다.
문제가 발생한 경우, 특정 HTML파일이 사람이 처리할 수 있도록, 해당 파일 내부에 문제에 대한 설명과 함께 되돌려 보내졌었다.ㄷ
HTTP / 1.0 - 확장성 만들기 (Create Extensibility)
0.9는 매우 제한적이었으며 브라우저와 서버 모두 좀 더 융퉁성을 가지도록 빠르게 확장되었다.
- 버전 정보가 각 요청 사이내로 전송되기 시작했다.
(HTTP/1.0 이 GET라인에 붙은형태로)
- 상태 코드 라인 또한 응답의 시작 부분에 붙어 전송되어, 브라우저가 요청에 대한 성공과 실패를 알 수 있고, 그 결과에 대한 동작(특정 방법으로 그것의 로컬 캐시를 갱신하거나 사용하는 것과 같은)을 할 수 있게 되었다.
- HTTP 헤더 개념은 요청과 응답 모두를 위해 도입되어, 메타데이터 전송을 허용하고 프로토콜을 극도로 유연하고 확장 가능하도록 만들어 주었다.
- 새로운 HTTP 헤더의 도움으로, 평이한 HTML 파일들 외에 다른 문서들을 전송하는 기능이 추가되었다.
(Content-Type 덕분)
- 3 hand shaking 사용
아래는 일반적인 요청과 응답이다.
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
<IMG SRC="/myimage.gif">
</HTML>
두번째 커넥션에 의한 이미지를 내려받기 위한 요청과 그에 대한 응답이다.
GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)
HTTP 1.0에 대한 자세한 설명
https://datatracker.ietf.org/doc/html/rfc1945
HTTP/1.1 - 표준 프로토콜(Standard Protocol)
1.1은 모호함을 명확하게 하고 많은 개선 사항을 도입했다.
1. 커넥션이 재사용될 수 있게 하여, 탐색된 단일 원본 문서 내로 임베드된 리소스들을 디스플레이하기 위해 사용된 커넥션을 다시 열어 시간을 절약하게 했다.
2. 파이프라이닝을 추가해, 첫번째 요청에 대한 응답이 완전히 전송되기 이전에 두번째 요청 전송을 가능케 하여, 커뮤니케이션 레이턴시를 낮췄다.
3. 청크된 응답 또한 지원된다.
4. 추가적인 캐시 제어 메커니즘이 도입되었다.
5. 언어, 인코딩 혹은 타입을 포함한 컨텐츠 협상이 도입되어, 클라이언트와 서버로 하여금 교환하려는 가장 적합한 컨텐츠에 대한 동의를 가능케 했다.
6. HOST 헤더 덕분에, 동일 IP 주소에 다른 도메인을 호스트하는 기능이 서버 코로케이션을 가능케 했다.
그러나 ! 1.1도 단점은 있다.
1. HTTP의 HOL(Head Of Line)Blocking
2. Header의 중복
이러한 1.1의 단점들을 끆!뽂!하기 위해 2.0이 나왔다.
1.1의 자세한 설명
https://datatracker.ietf.org/doc/html/rfc2068
HTTP/2.0 - 더 나은 성능을 위한 프로토콜
2010년 전반, 구글이 SPDY 프로토콜을 구현해, 클라이언트와 서버간의 데이터 교환을 대체할 수단을 실증했다.
2.0은 1.x버전과 달리 HTTP에 TLS(보안)기능이 추가되었다.
응답성 증가 능력을 입증하고 전송된 데이터 중복에 관한 문제를 해결하면서, SPDY는 HTTP/2.0 프로토콜의 기초로써 기여했다.
2.0은 1.1버전과 근본적인 차이가 있다.
1. HTTP 메시지 전송방식의 변화
2.0은 Text Protocol이라기보다 Binary Protocol이다. 더이상 읽을 수도 없고 수작업을 만들어 낼 수 없다.
(binary protocol의 장점 : text protocol보다 빠르다. 단점 : 사람이 읽기 어렵다)
2. 요청과 응답의 다중화
병렬 요청이 동일한 커넥션 상에서 다루어질 수 있는 다중화 프로토콜로 순서를 제거해주고 HTTP/1.x 프로토콜의 제약사항을 막아준다.
3. Header Comprehension
전송된 데이터의 분명한 중복과 그런 데이터로부터 유발된 불필요한 오버헤드를 제거하면서, 연속된 요청 사이의 매우 유사한 내용으로 존재하는 헤더들을 압축시킨다.
4. 서버로 하여금 사전에 클라이언트 캐시를 "SERVER PUSH"라고 불리는 메커니즘에 의해, 필요하게 될 데이터로 채워넣도록 허용한다.
5. TLS가 필수
당연히 앞의 버전들보다 빠르다는 장점을 가지고 있다.
또한, 높은 트래픽의 웹사이트들은 전송 오버헤드 감소로 많은 돈을 절약할 수 있다.
2.0이 해결하지 못한 문제 -> TCP의 HOL Blocking
HTTP 3.0 - HTTP over QUIC
TCP의 구조상 HOL Blocking을 해결할 방법이 없다고 생각한 (GOD)Google께서는 TCP 대신 UDP를 사용하여
보안 및 혼잡 제어
연결 설정 시간 단축
혼잡 제어 개선(흐름제어)
Head Of Line Blocking 없는 멀티플렉싱
전달 오류 수정
연결 마이그레이션
을 지원해준다.
느낀 점
네트워크가 재밌던 이유가 내가 나중에 쓸거여서 라는 것을 깨달았다.
공부에 흥미와 재미를 더하기 위해 http의 역사를 찾아보았다.
역시나 더 재밌어진 것 같다.
앞으로는 공부하기 전에 내가 이걸 왜 써야하는지, 이 기술이 원래 뭘 지원해주기 위해 만들어졌는지, 내가 어디에 써야하는지에 대해 생각해보고 공부를 하면 흥미와 재미를 더해서 공부할 수 있을 것 같다.
오늘 하루도 열코하자 🔥
'SW정글사관학교' 카테고리의 다른 글
| [SW 정글] 5/20 운영체제 - 스케쥴 (0) | 2022.05.20 |
|---|---|
| [SW 정글] 5/19 운영체제 - 프로세스, 스레드, 스케쥴러 (0) | 2022.05.20 |
| [SW 정글] 5/13 TIL - 웹서버 (0) | 2022.05.14 |
| [SW 정글] 5/12 TIL 네트워크 프로그래밍 (0) | 2022.05.14 |
| [SW 정글] 웹서버 구현 error - 403 Forbidden , Tiny couldn't read the file: ./ (feat, c) (0) | 2022.05.13 |
