HTTP Application Layer에 대해 정리합니다.
HTTP Application Layer에 대해 정리합니다.
9 items under this folder.
HTTP 관련 내용은 사실 읽어도 읽어도 잘 머리에 안남는 것 같다. 사실 전반적인 흐름은 아는데, 뭔가 단어들이 기억에 잘 남는다는 느낌은 안들었었다. 다시한번 정리하면서 반복학습을 할 목적으로 포스팅을 남겨본다.
Request-Line OR Status-Line [Header CRLF] CRLF [ Body ] Start Line Request Response Header 헤더 중 X가 붙은 경우, 커스텀 헤더임 Pragma: 옛날 캐시 정책 Deprecated Cache-Control: 캐시 정책인데, 기능이 추가된 것들 Connection: close, keep-alive 두 개의 옵션이 있음 Stateless Protocol HTTP는 상태가 없는 프로토콜이다.
HTTP 메소드 종류 GET 요청이 캐시된다. 브라우저, 로봇이 임의로 요청이 가능하다.
CodeInfomationRangeDescription1xxInformational100, 101100: Continue 101: Switching Protocols 2xxSuccessful200~206 201: Created 202: Accepted (대기열 긴 경우, 요청은 받았어! ^^ 이 용도..) 3xxRedirection300~307 301: Moved Permanently 302: Found (이전 Moved Temporarily) 307: Temporary Redirect (Recommaned) 308: Perman...
www.example.org/index.html 을 GET 요청 한 상황을 가정해보자. 서버는 80번 포트를 열고 요청을 대기한다. 클라이언트는 웹 브라우저 주소창에 URL을 입력한다. 웹 브라우저는 DNS에 물어보고 해당 URL Host의 아이피를 알아낸다.
언제 사용할까? Conditional GET을 이용하여 트래픽은 줄일 수 있으나, Round Trip은 줄일 수 없다.
HTTP에서 상태가 필요한 이유 로그인이 되게 하고 싶다. 쇼핑몰 로그인이 아니어도 카트 목록을 기억하게 하고 싶다. 해결 방법 Fat URL - URL에 상태 정보를 모두 집어 넣기 - URL을 파싱해서, 사용자의 상태를 확인한다.
TLS 위에서 동작하는 HTTP 종단간 암호화 (E2E 암호화) HTTP 메시지를 암호화하여 주고 받음 보안이란? 서버 인증 클라이언트는 자신이 진짜 서버임을 알 수 있어야 함 클라이언트 인증 서버는 자신이 진짜 사용자임을 알 수 있어야 함 무결성 클라이언트와 서버는 그들의 데이터가 위조되는 것으로 부터 안전해야 함 암호화 클라이언트와 서버는 도청 걱정 없이 대화가 가능해야 함 동작 방식 서버가 클라이언트에게 인증서를 보내어 자신을 증명한다.
HTTP/1.1 보다 빠름 Header Compression Huffman Coding Header Tables Multiplexed Streams 한 커넥션으로 동시에 여러 개의 메세지를 주고 받을 수 있으며, 응답은 순서 상관없이 Stream 으로 주고 받음 HTTP/1.1 TCP 커넥션 1개를 연다.