이번 글을 HTTP Header에 대한 간략한 내용 정리 입니다.
웹 어플리케이션은 HTTP 프로토콜로 통신하는 네트워크 것으로, 웹 브라우저와 웹 서버 간에 오고 가는 네트워크 패킷 분석을 통해 HTTP 프로토콜을 알 수 있습니다. 그리고 그 HTTP 프로토콜을 Header 와 Body로 구분할 수 있는데, Header는 응답 데이터에 대한 정보, Body는 응답 데이터를 가지고 있습니다.
각 브라우저의 개발자 도구(F12)에서 Network 탭을 통해 HTTP 통신에 대한 내역들을 볼 수 있습니다.
1. Content-Length
2. Transfer-Encoding
3. Connection
4. Content-Encoding
1. Content-Length
- HTTP 통신에서 반드시 필요한 것은 전송하는 메시지의 끝을 결정하는 것 입니다.
why...?
사람들이 대화를 할때는 질문이 끝나면 그에 대한 답변을 하지만, 컴퓨터에서는 메시지를 전송 받을 때 끝을 알 수 없기 때문입니다.
그래서 일반적으로는, 데이터 크기를 미리 전송하여 크기를 예측하고 크기만큼 데이터를 전달 받습니다.
Content-Length : {num}
2. Transfer-Encoding
- 하지만, Content-Length 가 Header에 존재하지 않는 경우가 보입니다. 지금까지 상황으로 봤을때는 문제가 되리라고 생각이 될 수 있습니다.
이는 HTTP 1.1 에서 추가된 내용으로 전송 버퍼를 이용해 부분적으로 전송하고 버퍼를 재사용하여 데이터를 점진적으로 보내는 방식이 가능 해졌습니다. (CRLF(\r\n)으로 행을 구분)
Transfer-Encoding : chuncked
이는 HTML 문서를 다운 받을 때 유용할 것 입니다.
3. Connection
- HTTP는 특성상 connectionless 방식으로 연결을 매번 끊고 새로 생성하는 구조 입니다. 매번 connection을 해야하기 때문에 비효율적인 방식입니다. 그래서 HTTP 1.1 에서 Keep-Alive 방식이 추가 되면서 connection을 유지 할 수 있게 됩니다.
이는 동일 서버에서 HTML 문서와 리소스를 요청/응답할 경우에 효과적입니다. 예를 들어, HTML 문서에 이미지 2개 CSS 1개, 스크립트 1개가 있다고 가정 해보겠습니다.
1) Connection : close
① 웹서버 연결
② HTML 문서 다운
③ 웹서버 연결 끊음
④ 웹서버 연결
⑤ CSS 다운
⑥ 웹서버 연결 끊음
⑦ 웹서버 연결
⑧ 이미지1 다운
…
2) Connection : Keep Alive
① 웹서버 연결
② HTML 문서 다운
③ CSS, 이미지(1,2), 스크립트 다운
④ 웹서버 연결 끊음
단순히 갯수만 보더라도 자원 낭비가 줄어듬을 볼 수 있습니다.
하지만! 이는 동일 서버에서 리소스를 가져왔을 때의 방식이므로, CDN서버과 같이 또 다른 서버를 통해 리소스를 가져 온다면, 또는 REST API 서버라면 close를 하는 것이 좋을 것 입니다.
※ 서버 설정이나 웹 애플리케이션 설정을 통해 변경(Keep Alive On/Off)이 가능합니다.
4. Content-Encoding
- 네트워크 전송량을 최소화 하기 위해 데이터를 압축하여 전송하는 방식을 추천합니다.
- 종류
① gzip
: 32비트 CRC와 함께 Lempel-Ziv coding(LZ77)를 사용하는 압축 포맷
② compress
: Lempel-Ziv-Welch(LZW) 알고리즘을 사용하는 압축 포맷
③ deflate
: deflate 압축 알고림즘과 함께 zlib 구조를 사용하는 압축 포맷
④ br
: Brotli 알고리즘을 사용하는 압축 포맷
예를 들면, 요청에 대한 응답 데이터가 100KB라면, gzip 압축형태로 받아 30KB의 데이터를 받는 것 입니다.
※ 웹 브라우저에서 Accept-Encoding: gzip를 Header에 포함하여 웹 서버에 요청을 하면 gzip 으로 압축된 데이터를 받을 수 있습니다,
출처: https://heowc.tistory.com/31 [허원철의 개발 블로그]
스프링 부트 / MVC / JavaConfig에서 RESTful을 사용하여 GZIP 압축 사용
일련의 RESTful서비스에 대해 Annotation 기반 java-config와 함께 Spring Boot / MVC를 사용 HTTP GZIP하며 일부 API 응답에서 선택적으로 스트림 압축을 사용하려고합니다 .
내 컨트롤러와 수동으로이 작업을 수동으로 수행 할 수 있다는 것을 알고 byte[] @ResponseBody있지만 SpringMVC 인프라 (필터 등)에 의존하여 JSON 변환 및 압축 (POJO를 반환하는 메서드)을 자동으로 수행하는 것을 선호합니다.
어떻게하면 ResponseBody 또는 임베디드 Tomcat 인스턴스에서 GZIP 압축을 활성화 할 수 있으며 일부 응답 만 선택적으로 압축 할 수 있습니까?
감사!
추신 : 현재 XML 기반 구성이 없습니다.
java rest spring-mvc gzip spring-java-config
163
이 답변의 나머지 부분은 오래된 IMO 또는 IMO (gzip이 얼마나 오래 있었습니까? Java보다 오래 ...)해야하는 무언가에 대해 복잡합니다.
application.properties 1.3+
server.compression.enabled=true server.compression.mime-types=application/json,application/xml,text/html,text/xml,text/plain,application/javascript,text/css
application.properties 1.2.2 - <1.3
server.tomcat.compression: on server.tomcat.compressableMimeTypes=application/json,application/xml,text/html,text/xml,text/plain,application/javascript,text/css
1.2.2 이상 :
@Component
public class TomcatCustomizer implements TomcatConnectorCustomizer {
@Override
public void customize(Connector connector) {
connector.setProperty("compression", "on");
// Add json and xml mime types, as they're not in the mimetype list by default
connector.setProperty("compressableMimeType", "text/html,text/xml,text/plain,application/json,application/xml");
}
}또한 임베디드 바람둥이를 운영하는 경우에만 작동합니다 :
포함되지 않은 Tomcat에 배포하려는 경우 server.xml에서 활성화해야합니다. http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#Standard_Implementation
IRL 생산 노트 :
댓글 ( 5)
댓글 남기기