일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- Spring
- 페이징
- GC
- Producer
- Refactoring
- 스프링
- 권한
- load balancing
- 스프링 부트
- 클린코드
- apache
- clean code
- spring boot
- jvm
- java
- 비동기
- g1
- 스프링부트
- Security
- JWT
- gdg
- 페이스북
- tomcat
- JPA
- 리팩토링
- RabbitMQ
- assertj
- 시큐리티
- OAuth
- oauth2
Archives
- Today
- Total
허원철의 개발 블로그
HTTP1.1 Header 본문
이번 글을 HTTP Header에 대한 간략한 내용 정리 입니다.
웹 어플리케이션은 HTTP 프로토콜로 통신하는 네트워크 것으로, 웹 브라우저와 웹 서버 간에 오고 가는 네트워크 패킷 분석을 통해 HTTP 프로토콜을 알 수 있습니다. 그리고 그 HTTP 프로토콜을 Header 와 Body로 구분할 수 있는데, Header는 응답 데이터에 대한 정보, Body는 응답 데이터를 가지고 있습니다.
각 브라우저의 개발자 도구(F12)에서 Network 탭을 통해 HTTP 통신에 대한 내역들을 볼 수 있습니다.
<크롬 개발자도구 Network 탭>
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 으로 압축된 데이터를 받을 수 있습니다,
'web' 카테고리의 다른 글
책 '서블릿 컨테이너의 이해' 후기 (419) | 2016.12.29 |
---|---|
Spring Boot - Resource 개선하기 (414) | 2016.12.25 |
Spring Boot - Redis를 활용한 Session Clustering (423) | 2016.12.13 |
JNDI 살펴보기 (426) | 2016.12.09 |
페이징에 대한 이해 - 2 (396) | 2016.12.08 |
Comments