CR, LF
와 이 용어들의 조합인 CRLF
는 개행의 방식을 의미합니다.
타자기를 사용하던 시절에는 다음과 같은 방식으로 개행이 동작했었습니다.
- CR : 현재 커서를 줄 올림 없이 가장 앞으로 옮기는 동작
- LF : 커서는 그 자리에 둔 상태로 종이만 한줄 올려 줄을 바꾸는 동작
잠시 캐리지 리턴에 대해서 알아보았습니다. 이어서 HTTP 메세지의 구조에 대해서 알아보겠습니다.
- head
start-line : 실행되어야 할 요청, 또는 요청 수행에 대한 성공, 실패 유무 기록
HTTP headers : 요청에 대한 설명 혹은 메세지 본문에 대한 설명- empty line(CR+LF) : 요청에 대한 메타 정보가 전송되었음을 알림
- body : 전송되는 데이터 그 자체를 의미합니다. payload
HTTP / 2.0 에서는 프레이밍 메커니즘이 추가되어 데이터와 헤더 프레임이 분리되었기 때문에 프레임을 더 쉽게 확인할 수 있습니다.
인코딩(Encoding) : 사용자가 입력한 문자나 기호들을 컴퓨터 신호로 바꾸는 것입니다.
ex) 유니코드, 아스키
디코딩(Decoding) : 인코딩과 반대의 작업을 의미하고 소프트웨어 알고리즘을 의미합니다.
HTTP로 데이터를 그대로 전송할 수도 있지만 전송할 때에 인코딩을 실시함으로 전송 효율을 높일 수 있기 때문입니다.
단, CPU등의 리소스는 보다 많이 소비할 수도 있습니다.
사용자가 광대역의 네트워크를 이용할 수 있기 전에는 대용량의 이미지와 데이터를 다운로드하기 힘들었습니다. 다운로드 중 커넥션이 끊어지면 다시 다운로드를 시작해야 했기 때문입니다.
이를 해결하고자 resume 기능이 필요했고 엔티팉의 범위를 지정해서 다운로드 하는 방식으로 resume 기능을 구현했습니다.
동일한 URI에서 리소스의 서로 다른 버전을 서브하기 위해 사용되는 메커니즘으로, 사용자 에이전트가 사용자에게 제일 잘 맞는 것이 무엇인지(예를 들어, 문서의 언어, 이미지 포맷 혹은 컨텐츠 인코딩에 있어 어떤 것이 적절한지)를 명시할 수 있습니다.
Content Negotiation은 제공하는 리소스를 언어와 문자 세트, 인코딩 방식등을 기준을 판단합니다.
다음과 같은 리퀘스트 헤더 필드가 판단 기준을 제공합니다.
간단하게 말해서 서버 내부의 알고리즘을 통해 자동으로 처리하는 방식입니다.
서버 주도형 협상이 일반적인 방법이긴 하지만, 몇가지 결점을 가지고 있습니다.
서버는 브라우저에 대한 전체적인 지식을 가지고 있지 않습니다. 즉, 서버는 브라우저의 수용 능력에 대한 완벽한 정보를 가지고 있진 않습니다. 클라이언트가 선택하는 에이전트 주도 협상과는 다르게, 서버 선택은 다소 임의적입니다.
클라이언트에 의한 정보는 상당히 장황하며 사생활 침해에 대한 위협을 가지고 있습니다(HTTP 핑거프린팅).
클라이언트 측에서 수동으로 선택하는 방식을 의미합니다.
🎯 HTTP 메세지 구조, 인코딩, 컨텐츠 협상등에 대해 알아보았습니다. 다음 포스팅에서는 HTTP 상태코드에 대해 적어보겠습니다..!