lou@blog $ _

HTTP/1.0 HTTP/1.0에서는 클라이언트/서버간 각 요청/응답에 대해 새로운 TCP 연결을 생성한다. 그래서 각 요청전에 TCP 및 TLS 핸드셰이크가 완료되어야 했고, 모든 요청에 대기시간 패널티가 발생했다 HTTP/1.1 한번의 TCP 연결을 유지하고자 Keep-alive가 등장했다. 하지만 HTTP/1.1에서는 클라이언트가 한 번에 하나의 HTTP 요청/응답 교환만 허용했으므로 네트워크 계층에서 동시성을 얻는 유일한 방법은 TCP 연결을 병렬로 사용하는 것인데, Pipelining을 통해 여러 요청을 전송했을때, 첫번째 요청에 대한 응답이 지연되면 뒤에 따라오는 모든 응답도 같이 지연되었는데 이를 “Head of line Blocking”이라고 한다. 이는 RFC 2616에서 서버는 반드시 ..

특정시간 안에 보낸 동일한 Request에 대해서 서버에 요청하지 않고, 이전에 받은 응답값을 그대로 내려주는 Interceptor를 구현해보았다. Response Body를 어떻게 재사용할 것인가 고민을 많이 했는데, ByteArray 형태로 읽어두고 중복된 요청일때 ResponseBody로 만들어주는 방법을 사용해보았다. 이렇게 짧은 시간안에 연속적으로 요청을하더라도, 500ms 이후에만 새로 요청을 하게된다. 개발중인 앱의 Request Method가 전부 POST이기때문에, Request body까지 읽어서 hashing을 하고있는데, 그럴 필요까지 없으신분들은 Request URL 자체를 hash 값으로 잡아도 무방할 것이다. 혹시 유용했다면 Star를~! HTML 삽입 미리보기할 수 없는 소스

ETag란? ETag란 EntityTag의 줄임말로, 웹 캐시 유효성 검증에 사용된다. 리소스의 특정 버전에대한 고유값이 ETag의 값이되고, 리소스의 내용이 업데이트되면 ETag도 바뀐다. 클라이언트에서 캐싱하고 있는 버전과 서버에서 가지고 있는 버전이 동일하다면 서버는 내용없이 304 Not Modified 라는 상태코드로만 응답을 내려주어 response body에 대한 트래픽을 아낄 수 있다. ETag 작동방식 먼저 HTTP Request를 날려보자. 서버는 ETag와 함께 응답 (상태코드 200)을 내려줄 것이다. 이 요청에 대한 응답의 사이즈는 43.9KB였다. ETag의 검사기 종류에는 약한(Weak)과 강한(Strong)검사가 있는데, 약한 검사를 하는 ETag는 W/로 시작하고, 강한 검..

연결 수립 클라이언트와 서버가 HTTP 요청/응답으로 교환하기 전 , TCP 커넥션을 설정해야한다. HTTP/1.0의 기본 동작은 각 요청/응답에 대해 별도의 TCP 커넥션을 여는 것이다. TCP를 이용할 경우, 컴퓨터 상의 HTTP 서버를 위한 기본 포트는 80이다. 요청을 위한 페이지 URL은 도메인 이름과 포트번호 둘 다를 포함하는데, 포트 번호가 80일 경우 생략가능하다. HTTP 흐름 1. TCP 커넥션을 연다. TCP 커넥션은 요청을 보내거나 응답을 받는데 사용된다. 클라이언트는 새로운 커넥션을 열거나, 기존 커넥션을 재사용하거나, 서버에 대한 여러 TCP 커넥션을 열 수 있다. 2. HTTP 메세지를 전송한다. HTTP/2 이전의 메세지는 사람이 읽을 수 있을 정도다. GET / HTTP/1..

HTTP 메세지 HTTP 메세지는 서버와 클라이언트 간 데이터가 교환되는 방식이다. 메세지 타입은 Request와 Response가 있다. HTTP 메세지는 ASCII로 인코딩된 텍스트 정보이며 여러 줄로 되어있다. HTTP/2에와서는 최적화와 성능 향상을 위해 HTTP 프레임으로 나누어지게되었다. Request Request는 클라이언트가 서버로 전달해서 서버의 액션이 일어나게끔하는 메세지이며, 다음 요소들로 구성된다. Method: GET/POST/PUT/DELETE/OPTIONS/HEAD 등 클라이언트가 수행하고자 하는 동작이다. Path: 가져오려는 리소스의 경로다. 프로토콜, 도메인, TCP 포트를 제거한 리소스의 URL이다. Version of protocol: HTTP 프로토콜의 버전 Hea..