출퇴근 지하철을 이용해서 책의 흥미있는 부분만 골라서 읽어보았습니다. 대략적으로 훑어보는것에 그치는 것 같은 아쉬움이 있네요.
리얼월드 HTTP
HTTP/2 의 스트림에 대해서 발췌독을 하려다, HTTP 버전간의 대략적인 변경점에 대해서 간단하게 생각해보게 되었습니다.
semantics are consistent
HTTP 에서 request methods, status codes, message fields 등의 시멘틱스 사양은 HTTP/1.1 이후에 크게 변하지 않았습니다. 이와 관련한 내용을 책과 HTTP/3 자료에서 찾아볼 수 있습니다.
가장 새로운 HTTP/2 의 현재 사양은 주로 통신 고속화 등 저수준 커뮤니케이션 신택스에 특화됐으므로, 통신 내용이나 브라우저와 서버 간의 커뮤니케이션 시멘틱스 사양으로는 지금도 HTTP/1.1 에서 정한 내용이 현역 입니다. - p.133
HTTP semantics are consistent across versions. The differences are in the mapping of these semantics to underlying transports. Both HTTP/1.1 and HTTP/2 use TCP as their transport. HTTP/3 uses QUIC, a transport layer network protocol which uses user space congestion control over the User Datagram Protocol (UDP). - HTTP/3 - Wikipedia
HTTP/2 의 스트림을 이용한 통신 고속화
HTTP/2 의 주된 목적은 통신 고속화에 있습니다. HTTP/2 에서도 TCP 프로토콜을 이용하는데, 하나의 TCP 접속 안에 스트림 이라는 가상의 TCP 소켓을 만들어 통신합니다.
HTTP/2 는 인터넷 4계층 모델 중 애플리케이션 층에 해당하지만, 트랜스포트 층에 가까운 것(스트림*)을 내부에 가지고 있는 게 특징입니다. ...
TCP 소켓과 HTTP/2 스트림의 관계는 OS 스레드와 그린 스레드와 비슷하다고 할 수 있습니다. - p. 258
*그린 스레드: 커널이아니라 사용자 영역에서 만들어지는 유사 스레드, Go 언어의 goroutine 도 이에해당
goroutine 의 배경과 필요성에 대한 자세한 설명을 찾고 싶었으나, 검색을 통해서는 공식적인 자료를 찾기 어려워, Java 의 virtual thread draft 을 통해서, 배경과 필요성을 간략하게 읽어볼 수 있었습니다.
스트림에서 데이터는 프레임 단위로 이동합니다. 이는 HTTP 프로토콜이 고속화를 위해 기존의 텍스트 기반에서 바이너리 기반으로 바뀐것과 관련이 깊습니다.
HTTP/1.1 은 텍스트 프로토콜이었습니다. 헤더의 종단을 찾으려면 빈 줄을 찾을 때까지 1 바이트씩 미리 읽어 발견할 필요가 있습니다. 오류 처리도 있고 서버로서는 해석까지 포함해 순차적으로 처리할 수밖에 없으므로 고급 병렬 처리는 어려울 것입니다. HTTP/2는 바이너리화 되어, 처음에 프레임 크기가 들어갑니다. TCP 소켓 레이어에서는 데이터를 프레임 단위로 쉽게 분리할 수 있으므로, 수신 측 TCP 소켓의 버퍼를 빠르게 비울 수 있고, 통신 상대에게 다음 데이터를 고속으로 요청할 수 있습니다. - p.257
프레임의 크기가 정해지는 것이 병렬 처리를 쉽게 하는 핵심인 것 같으나, 고급 병렬 처리란 무엇인가에 대한 이해가 부족하여, 해당 부분을 다시 읽어보아야 할 것 같습니다.
